Elektronisches Wertschriftenportfoliomanagementsystem

Inhaltsverzeichnis

Management Summery

Abbildungsverzeichnis

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

Literaturverzeichnis

Bücher und Zeitschriftenartikel

Online-Quellen

Anhang

A. Projektplan

B. Nicht-funktionale / attributive Anforderungen

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.

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 ITSysteme 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 BusinessProzesse 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.

Abbildung in dieser Leseprobe nicht enthalten

2.1.2 APMS - Asset Portfolio Management System

Die im Nachfolgenden verwendete Abkürzung APMS steht für den Kunstbegriff Asset Portfolio Management System und ist im Grunde schlicht eine Anglifizierung des Titels dieser Arbeit im Angesicht der heute in der Branche dominierenden Englischen Sprache.

Die Bedeutung des Kompositums leitet sich aus obigen Begriffserklärungen ab und meint ein Softwaresystem für Finanzintermediäre zur elektronischen Verwaltung und dem automatisierten Handel von Wertschriften.

Das Hauptanliegen dieser Arbeit, das sich in dieser Sichtweise aus den in Kapitel 1.3 definierten Fragestellungen ableitet, ist es, die Voraussetzungen für die Entwicklung eines APMS zu schaffen. Die eigentliche Systemherstellung ist allerdings wie bereits gesagt kein unmittelbares Thema.

2.2 Standards

Neben den rechtlichen Rahmenbedingungen des Schweizerischen Bankengesetzes ist im Bereich der Vermögensverwaltung und des Wertschriftenhandels in erster Linie der GIPS-Standard von Bedeutung. Da dieser die nachfolgend entwickelten konzeptuellen Ansätze wenig berührt, jedoch im Rahmen einer nachfolgenden technischen Systemrealisierung eine bedeutende Tragweite erlangen dürfte, soll eine kurze Betrachtung erfolgen.

2.2.1 Der GIPS-Standard

Die Global Investment Performance Standards (GIPS, häufig im Singular verwendet) definieren ethische Grundsätze für Vermögensverwalter, die eine faire Präsentation und eine transparente Offenlegung der Anlageperformance unter Einhaltung des Datenschutzes gewährleisten sollen. Bis vor kurzem war GIPS in der Schweiz unter der Bezeichnung SPPS bekannt (vgl. Klemm 2006, s. 34).

Institute müssen diverse Anforderungen erfüllen, um GIPS-konform zu sein (siehe unten). Der Standard basiert auf Selbstregulierung und freiwilliger Einhaltung der Anforderungen. Diese können allerdings durch einen unabhängigen Dritten verifiziert werden.

2.2.2 Anforderungen und Relevanz

Investoren können dank GIPS die Anlageperformance der verschiedenen Vermögensverwalter besser miteinander vergleichen - das war auch das Hauptziel der ursprünglichen Norm. Die heute gültige Fassung von 2005 ist eine Erweiterung des Originalstandards aus dem Jahr 1999: Um die Transparenz der dargestellten Anlageperformance für einen weiten Kreis von Adressaten sicherzustellen, verlangt die aktuelle Version von GIPS-konformen Vermögensverwaltern unter anderem, dass diese

- eine GIPS-konforme Präsentation allen potenziellen Kunden vorlegen
- auf Anfrage einem potenziellen Kunden eine Liste sämtlicher Depots abgeben
- einem potenziellen Kunden auf Anfrage eine GIPS-konforme Performance-Präsentation für alle aufgelisteten Depots zur Verfügung stellen.

Viele Vermögensverwalter haben die Vorzüge von GIPS bei der Optimierung der internen Prozesse und Kontrollen als auch im Risikomanagement erkannt und schaffen dadurch unterdessen auch vermehrt firmeninterne Transparenz.

Durch diesen Umstand erhält eine Softwarelösung für Vermögensverwalter mit GIPS-Konformität einen speziellen USP (Unique Selling Proposition) und damit ein deutlich höheres Absatzpotential.

Da sich diese Arbeit allerdings auf die wirtschaftlichen Vorteile des Betreibers und nicht des Anbieters einer solchen Software konzentriert und sich zudem nicht mit den technischen Implementierungsdetails befasst, welche für die Erreichung der GIPS-Konformität entscheidend sind, wird auf eine detaillierte Diskussion des Standards an dieser Stelle verzichtet (mehr zum Thema findet sich bei Klemm 2006 sowie GIPS 2008, online).

3 Methodik

3.1 Ausrichtung und empirische Überlegungen

Da diese Arbeit einen eher praxismotivierten als streng wissenschaftlichen Ansatz verfolgt, fällt die Auswahl der verfolgten Methodiken mehr aus ökonomischen denn forschungsbezogenen Gründen.

Die verwendeten Vorgehensmodelle sollen samt ihren Vor- und Nachteilen kurz beschrieben werden. Dabei kommen verschiedene Sichtweisen und damit Methodiken zur Anwendung:

- Vorgehensmodell zur Projektdurchführung: Hermes
- Vorgehensmodelle zur Systemkonzipierung und -realisierung: OOA/OOD und Quasar.

3.2 Vorgehensmodell zur Projektdurchführung

Als grundsätzliche Methodik für die Planung und Durchführung des Gesamtvorhabens wird der 6-Phasen-Prozess des Hermes-Projektmodells „ Systementwicklung “ (siehe ISB 2004) gewählt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Hermes Projekt-Phasen

3.2.1 Beschreibung und Diskussion

Die Hermes-Methodik des Bundes betrachtet Systementwicklung ganzheitlich als Prozess von der Beantragung eines Informatikprojekts bis zu dessen Abschluss inklusive Nachbearbeitung.

Das Kernthema Projektdurchführung wird dabei als Richtschnur und Rahmen verstanden, in den nach Bedarf an bestimmten Fixpunkten andere Vorgehensmodelle, zum Beispiel für die eigentliche Systemrealisierung, integriert werden können: „Da Hermes in erster Linie als Methode zur Projektführung konzipiert ist, wird es je nach den Erfordernissen eines Projekts notwendig, den Arbeitsstrukturplan um neue Aktivitäten, Arbeitstechniken und mit den Werkzeugen eines spezifischen Vorgehensmodells zu erweitern“ (ISB 2004, s.16).

Die skalierbare Methode legt das generische Wasserfallmodell nach Royce (1970) zugrunde, welches als lineares (nicht-iteratives) Vorgehensmodell eine Unterteilung des gesamten (Software-) Projekts in eine Kaskade aus mehreren aufeinander aufbauenden Teilschritten propagiert (in allgemeinerer Form wird daher oft von Phasenmodell gesprochen, vgl. Wikipedia 2008-a, online). Diese Phasenbildung entspricht im Wesentlichen dem „natürlichen“ Lebenszyklus von Software-Projekten, was dem Modell nebst seiner Einfachheit trotz seines Alters auch heute noch seine zumindest mehrheitliche Gültigkeit zuspricht und seine grosse Verbreitung in Literatur und Praxis erklärt.

Dank der Linearität liegt der Vorteil von Hermes vor allem in seiner guten Plan- und Dokumentierbarkeit sowie seiner Ausrichtung auf die Qualitätsaspekte eines Projekts. Des Weiteren spricht die Herausgeberschaft des Bundes und die damit verbundene jahrelange, methodologisch ausgereifte Ausarbeitung für den Einsatz des Modells.

Aus diesen Gründen hat sich beim Auftraggeber das Vorgehensmodell als Standardmethode für Organisations-, Evaluations- und Entwicklungsprojekte bewährt und kommt ebenfalls in der vorliegenden Arbeit zur Anwendung.

3.2.2 Projektcharakter, Scope und Phasen

Im Rahmen des vor Projektbeginn durchgeführten Tailorings wird bestimmt, inwiefern sich das Projekt von seinen Charakteristiken her mit dem Standardmodell der gewählten Methodik deckt und wo es allenfalls davon abweicht. Entsprechend den inhaltlichen Schwerpunkten werden die Teilschritte und Ergebnisse der einzelnen Projektphasen partiell verschoben, ergänzt, begrenzt oder weggelassen.

Diese Arbeit entspricht thematisch weitgehend dem Idealfall und wird deshalb grundsätzlich nach dem erklärten Verfahren als Projekt geführt und strukturiert. Da das Endziel im vorliegenden Fall jedoch nicht ein fertig entwickeltes und eingeführtes System, sondern ein Systemdesign ist, werden bezüglich der einzelnen Phasenergebnisse folgende Spezifizierungen und Einschränkungen vorgenommen.

3.2.2.1 Initialisierung

Als erster Projektschritt wurde der Projektantrag bzw. -auftrag zusammen mit dem Auftraggeber sowie die Projektzeitplanung bzw. kurz Projektplan erstellt (siehe Anhang A).

3.2.2.2 Voranalyse

Die Voranalyse (Kapitel 4) umfasst, basierend auf dem Projektauftrag, einerseits die Zielvereinbarung bestehend aus Situationsanalyse und Definition der Systemziele sowie anderseits die L ö sungsauswahl bestehend aus Systemanforderungen und Lösungsvorschlägen.

3.2.2.3 Konzept

In der Konzeptphase (Kapitel 5) wird eine Kurzevaluation von Fertigprodukten durchgeführt und im Rahmen der sogenannten Detailstudie die noch realisierungs- bzw. technikneutrale Systemarchitektur entwickelt.

Die Positionierung der Architektur im Konzept anstatt in der Realisierungsphase mag auf den ersten Blick erstaunen, lässt sich jedoch plausibel begründen: In der Detailstudie wird nach Hermes eine weitere Abgrenzung vorgenommen, in der die effektiv zu realisierenden Teilsysteme bzw. Systemkomponenten bestimmt werden - und um diese zu ermitteln, wird eine zumindest grob formulierte Architektur benötigt.

Die Entwicklung von konzeptuellen Prototypen entfällt aufgrund des Projektcharakters.

3.2.2.4 Realisierung

Die Realisierungsphase (Kapitel 6) endet beim Entscheidungspunkt Systemspezifikation mit dem Systemdesign, also der Modellierung von Klassenstrukturen und des Verhaltens der Anwendung. Im Rahmen dieser Arbeit werden keine Realisierungsprototypen entwickelt. Die Systemfertigstellung erfolgt erst in einem Anschlussprojekt, ist hier daher out-of-scope.

3.2.2.5 Einführung

Die Einführungsphase beinhaltet Fertigstellung, Abnahme und Druck der Arbeit, wobei der PhasenEntscheidungspunkt Abschluss dem Abgabetermin der Arbeit entspricht.

3.2.2.6 Abschluss

Die eigentliche Abschluss-Phase liegt out-of-scope, d.h. ist nicht Bestandteil der nachfolgenden Abhandlung, wird im Anschluss an diese Arbeit aber dennoch beim Auftraggeber im Sinne der Wissens- und Qualitätssicherung durchgeführt und ist daher auch in der Projektplanung enthalten.

3.2.2.7 Phasen-Entscheidungspunkte

Mit dem Abschluss jeder Phase wird ein Meilenstein erreicht und die bisherigen Ergebnisse seitens des Auftraggebers abgenommen, bevor die jeweils nächste Phase in Angriff genommen wird. Im Einzelfall ist jedoch ein phasenübergreifendes Vorgehen und damit ein Abweichen von der linearen Idealabfolge unvermeidlich und wird gebilligt, sofern der Gesamtprozess dadurch nicht gefährdet wird.

3.3 Alternativmethoden zur Projektdurchführung

Der linear kaskadierten Abfolge wasserfallbasierter Methoden widerspricht die heute zunehmend komplexe, häufig in mehrere Iterationen unterteilte Systementwicklung. Die Schwäche des HermesModells liegt demnach in seiner Starrheit im Sinne fehlender Agilität, die einen evolutionären, etwa spiralförmigen Software-Prozess signifikant erschwert (vgl. Glinz 2006, s.13.33).

Die Konzentration auf die Systemkonzeption anstelle der eigentlichen Realisierung rechtfertigt die Anwendung eines phasenorientierten Vorgehens, wogegen die technische Umsetzung im engeren Sinne, welche hier nicht Thema ist, vorzugsweise unter Verwendung iterativer bzw. agiler Methoden durchgeführt werden sollte, so etwa Rational Unified Process (RUP, vgl. Kruchten 2003), Extreme Programming (XP, vgl. Beck 2000), Scrum (vgl. Horsten 2008) oder S=k*c ² (vgl. Andresen 2004).

Neben der besseren Abbildungsmöglichkeit komplexer Szenarien durch die Fokussierung auf den eigentlichen Entwicklungsprozess liegen die Vorteile dieser Modelle in der höheren Flexibilität des meist nicht-linearen Projektverlaufs und in der Verfügbarkeit spezialisierter Anwendungssoftware zur Prozessunterstützung (zum Beispiel Rational Software Produkte oder automatisierte Testläufe in XP).

Aufgrund des Konzept-Fokus kommt in dieser Arbeit keine der genannten Methoden zur Anwendung.

3.4 Vorgehensmodelle zur Systemrealisierung

3.4.1 Objektorientierte Analyse / objektorientiertes Design

Bei softwarelastigen Projekten hat sich in den letzten rund zehn Jahren die Methodik „Objektorientierte Analyse und Design“ (OOA/OOD oder OOAD) stark verbreitet. Gemäss Wikipedia handelt es sich dabei um „eine Phase der objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der Domänenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs (Objektorientiertes Design) aufgliedert.“ (Wikipedia 2008-e, online). Zur Modellierung wird häufig UML (Unified Modelling Language, siehe Andresen 2004) herangezogen.

Kurz gesagt, meint in dieser Terminologie der Begriff „Analyse“ die Erhebung der Anforderungen, die das zu entwickelnde Softwaresystem erfüllen soll, im Sinne einer fachlichen Beschreibung mit objektorientierten Konzepten (das sogenannte Domänenmodell). Dagegen bedeutet „Design“ oder im

Deutschen „Entwurf“ - nach Meinung des Autors eine etwas unglückliche, da irreführende Übersetzung, besser wäre vermutlich „Gestaltung“ oder „Modellierung“ - die Verfeinerung und technische Ausgestaltung des in der Analyse erstellten Domänenmodells (Wikipedia 2008-e, online).

Die Trennung der beiden Phasen ist jedoch nicht absolut trennscharf definiert und wird dementsprechend in Literatur und Praxis auch unterschiedlich beschrieben. Nach den Erfahrungen des Autors hat der Ansatz zwei gravierende Nachteile:

1. Die in der OOA propagierte „Suche nach den Objekten“ der Anwendungsdomäne ist bereits zu technisch. Dadurch besteht die Gefahr, dass die in der Analysephase sehr entscheidende fachliche Perspektive zugunsten technikorientierter Überlegungen zu wenig Berücksichtigung findet. Zudem handelt es sich bei der Festlegung auf bestimmte Objekttypen bereits um Design-Entscheidungen, wodurch zu früh auf das „WIE“ (=Umsetzung) statt auf das „WAS“ (=Spezifikation) fokussiert wird.

2. Das durchgängige Denken in Objekten bzw. Klassen von der Analyse bis zur Implementierung unterbindet einen entscheidenden Aspekt des System-Designs: Die Gestaltung der Software- Architektur im Sinne der Unterteilung des Gesamtsystems in spezialisierte, zweckgebundene, entkoppelte und damit austauschbare Komponenten wird vernachlässigt. Dieser Konzeptionsschritt müsste zwischen der Analyse und dem Klassenentwurf (oder noch früher) ansetzen, um ein (insbesondere grösseres) System überschau-, wart- und weiterentwickelbar zu halten. Architektonische Aspekte im Sinne von Komponentenorientierung werden beim klassischen OOAD kaum betont, stattdessen wird Software-Architektur quasi mit Klassenstruktur gleichgesetzt. Neuere, erweiterte Varianten streben dagegen erfreulicherweise die vorgängige Modellierung der Komponentenstruktur an.

3.4.2 Quasar

Qualitätsorientierte Softwarearchitektur oder einfach Qualitätssoftwarearchitektur (abgekürzt als Quasar) ist ein Konzept, das von der deutschen Softwarefirma sd&m ins Leben gerufen wurde mit dem Ziel, die bewährten, über dreissig Jahre lang stetig verbesserten Architekturansätze und Gestaltungsphilosophien der Firma in eine aggregierte, wiederverwendbare Form zu bringen (siehe Siedersleben 2004, s.VII).

Es handelt sich dabei weniger um ein integrales Vorgehens- oder Realisierungsmodell wie die oben beschriebenen Methoden, sondern eher um eine Sammlung aufeinander abgestimmter Regeln, Empfehlungen und Muster zur praktischen Handhabe der „Königsdisziplin des Software-Engineering“.

Die betriebswirtschaftlich orientierte Grundannahme lautet, dass die Softwarearchitektur unmittelbare Auswirkungen auf Qualität und Kosten eines Systems hat. Dementsprechend verpflichtet sich Quasar auch selber zu Praxistauglichkeit, Wirtschaftlich und Einfachheit: „Quasar ist nicht gedacht als theoretischer Ballast […], sondern als Hilfe bei der Frage, wie man gegebene Anforderungen so einfach wie möglich in Software umsetzt“ (ebenda, s. 4).

Das Denkmodell, das von seinen Begründern gerne zum neuen Standard der Softwareentwicklung erklärt würde, umfasst Begriffsdefinitionen, Ideen und Konzepte ebenso wie empfohlene Standardarchitekturen, -schnittstellen und -komponenten, und ist damit deutlich auf die konkrete Anwendung im Projekt ausgerichtet. Dies macht es für die vorliegende Arbeit besonders interessant.

3.5 Systementwicklung als Kombination mehrerer Methodiken

Als Konklusion obiger Diskussion erscheint für den Gesamtprozess der Systementwicklung nur eine Kombination verschiedener Methoden zielführend, wie dies einleitend bereits angetönt wurde: Hermes als Gesamtvorgehensmodell der Projektdurchführung, Quasar innerhalb der Konzeptionsphase als architekturfokussierte Methode und OOA/OOD zur Modellierung innerhalb der Systemrealisierung. Die drei Hauptkapitel Voranalyse, Konzept und Realisierung sollen dies praxisbezogen verdeutlichen.

3.6 Empirische Überlegungen

Obige Ausführungen machen deutlich, dass empirische Untersuchungen wie etwa Befragungen für das vorliegende Problemfeld wenig zweckdienlich wären. Neben der Unmöglichkeit, im heterogenen Finanzmarkt eine repräsentative Stichprobe zu erheben, kommt erschwerend hinzu, dass die betroffenen Unternehmen nur selten Auskunft zu geben bereit sind. Zudem würde eine methodisch fundierte Erhebung den Umfang der vorliegenden Arbeit sprengen. Stattdessen wird im Angesicht der Marktorientierung nur eine Kurzevaluation bestehender Angebote durchgeführt (siehe Kapitel 5.1).

4 Voranalyse

In der Voranalyse werden anhand fachlicher, nicht-formaler Problembeschreibungen die Funktionalitäten, Qualitäten und Randbedingungen des zu entwickelnden Systems definiert und in konkrete Systemziele und Anforderungen überführt. Das Ziel ist, alle fachlichen Erfordernisse zu erheben und damit klare Voraussetzungen für die nachfolgende Konzept und die eigentliche Realisierungsphase zu schaffen.

Hermes versteht die Phase als „ein Klärungsprozess, der mit vertretbarem Aufwand eine Entscheidung über die grundsätzliche Art der Systemrealisierung herbeiführt“ (ISB 2004, s.60).

Unwirtschaftliche oder nicht realisierbare Vorhaben sollen somit bereits in einer frühen Projektphase erkannt und ausgeschlossen werden.

Der Untersuchungsbereich wird entsprechend weit gefasst: Um Informationsverluste an dieser Stelle zu vermeiden, welche in der Praxis häufig durch den zu frühen Einsatz formaler Methoden und/oder technischer Hilfsmittel wie etwa CASE-Software entstehen, soll dieser Analyseschritt noch allgemein gehalten im Sinne einer generischen Problem- und Lösungsumschreibung durchgeführt werden.

4.1 Zielvereinbarung

4.1.1 Situationsanalyse

In der Situationsanalyse wird das gegenwärtige und zukünftige Anwendungsgebiet (nach Hermes: Untersuchungsfeld) skizziert, die Ist-Situation beurteilt und ein Überblick über die zentralen Funktionen gegeben, die das zu entwickelnde System beinhalten soll.

Die hier beschriebenen Erkenntnisse bauen auf der in der Einleitung dargestellten Ausführung zur Grundproblematik auf. Die folgende Strukturierung ist an die Hermes-Vorlagen angelehnt.

4.1.1.1 Beschreibung des Ist-Systems

4.1.1.1.1 Prozesse

Gemäss der Analyse der realen Abläufe in der im Vorprojekt untersuchten Vermögensverwaltung läuft der Wertpapierhandel grob skizziert typischerweise folgendermassen ab:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Gesamtprozess Handel

Die einzelnen in Beziehung zu einander stehenden Aktivitäten im Handelsprozess sehen exemplarisch wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Detail-IST-Prozess Handel

Der dargestellte Prozess ist realtypisch und soll daher als Grundlage für nachfolgende Überlegungen hinsichtlich Optimierung und Überführung in ein informationstechnisches System dienen:

Bei der Durchführung des eigentlichen Kerngeschäfts wird in einem bestimmten Kunden-Depot ein Handel mit einem Wertpapier mit der entsprechenden Bank durchgeführt. Der Handelsprozess besteht heute bei den meisten kleinen bis mittelgrossen Vermögensverwaltern aus mehreren vorwiegend manuellen Tätigkeiten, die im Rahmen der durchgeführten Fallstudie erhoben wurden. Je nach Institution liegt ein unterschiedlicher Elektronifizierungs- bzw. Automatisierungsgrad vor, jedoch findet höchstens bei den Grossinstituten eine annähernd durchgängig elektronische Abwicklung statt.

4.1.1.1.2 Akteure

Im heutigen Handelsablauf können folgende Prozessbeteiligte bzw. fachliche Akteure ermittelt werden:

Abbildung in dieser Leseprobe nicht enthalten

4.1.1.1.3 Mengen und Häufigkeiten

Untenstehend werden alle wiederkehrenden Tätigkeiten aufgeführt, welche bei einer kleinen bis mittelgrossen Vermögensverwaltungsfirma typischerweise anfallen, ergänzt durch das im Rahmen der durchgeführten Fallstudie untersuchten Vermögensverwalters exemplarisch berechneten Einsparungspotentials, welches durch den Wegfall der heute noch manuellen Abläufe nach Systemeinführung möglich wird.

Der Tatsache, dass manche Tätigkeiten nach der Einführung des elektronischen Systems anders abgewickelt werden, wurde mit der Berechnung einer reduzierten Einsparung Rechnung getragen.

Abbildung in dieser Leseprobe nicht enthalten

Ziel der Erhebung des für den Anwendungsbereich typischen Mengengerüsts bzw. -profils ist es, einerseits das mögliche Einsparungspotential aufzuzeigen, welches durch den zielgerichteten Einsatz von Informationstechnologie anstelle von manuellen Verarbeitungsprozessen erreicht werden kann, und daraus die erfolgversprechendsten Ansatzpunkte für Effizienzsteigerungen abzuleiten (Wirtschaftsinformatiker- bzw. Rationalisierungsoptik), und anderseits bei der Umsetzung eines entsprechenden IT-Systems Anhaltspunkte für dessen Dimensionierung, also die Skalierung seiner technischen Bestandteile wie Web-, Datenbank- und Applikationsserver, zu erhalten (Softwareingenieur- bzw. Projektmanagementoptik).

4.1.1.1.4 IT-Landschaft

Wie eingangs erwähnt, kommen in den kleineren Institutionen sehr heterogene IT-Anwendungen und Infrastrukturen mit unterschiedlichem, generell jedoch eher tiefem Automatisierungsgrad zum Einsatz.

Im untersuchten Betrieb sind dies beispielsweise drei eigenständige, als Individualsystem realisierte MS Access Anwendungen sowie mehrere Standard-Office-Produkte.

Die verfügbaren Angaben lassen zwar keine repräsentative Aussage über die „im Normalfall“ verwendete Soft- und Hardware bei den kleinen und mittleren Vermögensverwaltern zu, es hat sich jedoch gezeigt, dass Gesamtsysteme mit durchgängiger Prozessunterstützung in der Regel fehlen.

4.1.1.2 Schwachstellenanalyse

In der Schwachstellenanalyse geht es darum, die ermittelten Schwächen des Ist-Systems sowie deren Ursachen und Auswirkungen aus fachlicher, technischer und finanzieller Sicht zu beurteilen, zu priorisieren und über die Aufnahme allfälliger Lösungsmöglichkeiten als Systemziel zu entscheiden.

Auf der Grundlage des beschriebenen Ist-Systems können nachfolgend die gravierendsten Schwachstellen zusammengefasst werden:

1. Medienbrüche: Der vorhandene, teils manuell und teils elektronisch abgewickelte Handelsprozess erzeugt an mehreren Stellen Medienbrüche, welche zu Mehraufwand, längeren Durchlaufzeiten und Fehleranfälligkeiten bei der (teilweise mehrfach durchgeführten) Erfassung von Fichen führt.
2. Manuelle Prüfungen: Die internen und externen Handelsdaten (z.B. von den Banken) müssen von Hand hinsichtlich Übereinstimmung kontrolliert werden, entsprechende Korrekturmeldungen erfolgten ebenfalls manuell, etwa mittels Telefonaten mit der Bank. Wiederum sind höhere Bearbeitungsaufwände und -zeiten sowie potentielle Fehler die Folge.
3. Hohe Betriebskosten: Die bestehenden, dezentralen Einzelsysteme und deren Administration schaffen, zusammen mit den erforderlichen manuellen Aktivitäten, hohe Personal- und Infrastrukturkosten.
4. Begrenzte Revisionstauglichkeit: Die in verschiedenen IT-Systemen sowie papiermässig vorhandenen Belege und Dokumente müssen für die Revision zusammengetragen werden, wobei es zu Unvollständigkeiten und damit Problemen mit der Revisionsstelle kommen kann.

Es wurde entschieden, die Punkte 1-3 als Ansatz für mögliche Einsparungen bzw. Verbesserungen als Systemziel aufzunehmen, während Punkt 4 in einer ersten Phase ausser Acht gelassen wird.

[...]