Eine Architektur für Customer Relationship Management und Prozessportale bei Banken

Transkript

1 Eine Architektur für Customer Relationship Management und Prozessportale bei Banken DISSERTATION der Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG) zur Erlangung der Würde eines Doktors der Wirtschaftswissenschaften vorgelegt von Roland Schmid aus Österreich Genehmigt auf Antrag der Herren Prof. Dr. Hubert Österle und Prof. Dr. Torsten Tomczak Dissertation Nr Difo-Druck GmbH, Bamberg 2001

2 Die Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG), gestattet hiermit die Drucklegung der vorliegenden Dissertation, ohne damit zu den darin ausgesprochenen Anschauungen Stellung zu nehmen. St. Gallen, den 26. Juni 2001 Der Rektor: Prof. Dr. Peter Gomez

3 Vorwort Kundenorientierung ist bei den meisten Unternehmen ein aktuelles Thema. Die technologischen Entwicklungen der letzten Jahre insbesondere das World Wide Web haben eine Vielzahl neuer Möglichkeiten geschaffen. Die Herausforderung für den Unternehmer besteht nun darin, dieses Potenzial zielgerichtet zu nutzen, um die Leistungen des eigenen Unternehmens verstärkt auf die Kundenbedürfnisse auszurichten. Die vorliegende Arbeit beschreibt eine Prozess- und Systemarchitektur für den Aufbau von Prozessportalen und den Einsatz von Massnahmen des Customer Relationship Managements und leistet damit einen Beitrag zur Bewältigung dieser aktuellen Herausforderung. Die Arbeit entstand im Rahmen des Kompetenzzentrums Customer Relationship Management des Forschungsprogramms Business Engineering Universität St. Gallen (BE HSG) am Institut für Wirtschaftsinformatik der Universität St. Gallen. Die Kompetenzzentren des Forschungsprogramms BE HSG forschen anwendungsorientiert auf strategischen Gebieten der Wirtschaftsinformatik in enger Kooperation mit der Praxis. Zusätzlichen Einfluss auf die Arbeit hatte die Mitarbeit im Kompetenzzentrum Business Knowledge Management. An dieser Stelle möchte ich allen danken, die zum Gelingen dieser Arbeit beigetragen haben. In erster Linie danke ich Herrn Prof. Dr. Hubert Österle für die wissenschaftliche Betreuung und für die ausgezeichneten, praxisnahen Arbeitsbedingungen. Herrn Prof. Dr. Torsten Tomczak danke ich für die Übernahme des Korreferats und für die wertvollen Anregungen. Mein besonderer Dank gilt Herrn Dr. Volker Bach für die fachliche Unterstützung und für die angenehme Zusammenarbeit. Des Weiteren bedanke ich mich bei meinen Kollegen am Institut insbesondere bei Dieter Blessing, Oliver Christ, Christoph Jansen, Sandra Gronover, Jens Schulze und Frédéric Thiesse für die kollegiale Zusammenarbeit und für die gute Arbeitsatmosphäre. Auch danke ich allen studentischen Mitarbeitern insbesondere Adrian Büren und Martin Spalinger für die tatkräftige Unterstützung. Weiteren Dank schulde ich allen Vertretern der Partnerunternehmen, die durch ihren Praxisinput wesentlich zum Gelingen der Arbeit beigetragen haben. Ausserdem danke ich Frau Annette Glaus für die stilistische und orthografische Qualitätssicherung. Von ganzem Herzen danke ich meiner Frau Bettina, die mir stets mit viel Verständnis beigestanden ist. Ganz besonders danke ich meinen Eltern, die mir meine gesamte Ausbildung ermöglicht haben und die mich auf meinem Weg immer unterstützt haben. Ihnen widme ich diese Arbeit. St. Gallen, im April 2001 Roland Schmid

4

5 Inhaltsübersicht i Inhaltsübersicht 1 Einführung Problemstellung Ziele und Adressaten der Arbeit Einordnung der Arbeit Forschungsmethodik Aufbau der Arbeit Grundlagen Customer Relationship Management Internetportale Prozessportale Geschäftsmodell des Informationszeitalters Entwicklungen in der Bankenbranche Erfolgsfaktoren für Prozessportale Kriterien Fallbeispiel: yourhome.ch Analyse von yourhome.ch Anforderungen an eine Architektur Architekturbegriff Kategorisierung von Prozessen und Funktionen Nutzungsprozess der Architektur Geschäftsarchitektur Prozessarchitektur Fallbeispiel: Customer Management Prozesse bei der Credit Suisse Leistungen an den Kundenprozess Prozesse des Prozessportalbetreibers Vertriebskanäle Gestaltungsdeterminanten... 91

6 ii Inhaltsübersicht 6.6 Konzeption eines Prozessportals für Erbschaft und Bestattung IS-Architektur Funktionen und Daten Gestaltungsdeterminanten Applikationen IS-Architektur des Prozessportals für Erbschaft und Bestattung Fazit und Ausblick Zusammenfassung der Ergebnisse Herausforderungen und Potenziale Ausblick Anhang A: Prozessarchitektur Aufgabenbeschreibungen Anhang B: Prozessportal für Erbschaft und Bestattung Anhang C: Funktionen der IS-Architektur Anhang D: Verzeichnis der Gespräche mit Herstellern und Anwendern Literaturverzeichnis

7 Inhaltsverzeichnis iii Inhaltsverzeichnis 1 Einführung Problemstellung Ziele und Adressaten der Arbeit Einordnung der Arbeit Forschungsmethodik Aufbau der Arbeit Grundlagen Customer Relationship Management Begriffsdefinition Ziele und Instrumente Internetportale Prozessportale Geschäftsmodell des Informationszeitalters Entwicklungen in der Bankenbranche Die Finanzbranche im Wandel Entstehung eines Wertschöpfungsnetzwerkes Rollen im Wertschöpfungsnetzwerk und Begriffe Erfolgsfaktoren für Prozessportale Kriterien Kosten- und Zeitersparnis Zusatznutzen Vertrauen Zufriedenheit Fallbeispiel: yourhome.ch Inhalte von yourhome.ch Ausgangslage und Ziele Business Case und Ertragskonzept Prozesse... 44

8 iv Inhaltsverzeichnis Kundenprozess Geschäftsprozess Verkauf von Hypotheken Content Management Anbindung der externen Partner auf Prozessebene Architektur Projektverlauf und aktueller Stand Ausblick Analyse von yourhome.ch Anforderungen an eine Architektur Architekturbegriff Kategorisierung von Prozessen und Funktionen Nutzungsprozess der Architektur Analyse des Potenzials zum Betrieb eines Prozessportals Überprüfen der Realisierbarkeit neuer Prozessportale Konzeption eines Prozessportals Systemevaluation Assessment bestehender Portale Geschäftsarchitektur Prozessarchitektur Fallbeispiel: Customer Management Prozesse bei der Credit Suisse Leistungen an den Kundenprozess Kernleistungen Zusatzleistungen Infrastrukturleistungen Prozesse des Prozessportalbetreibers Customer Relationship Managementprozesse Prozessmodell für Banken im Privatkundengeschäft Prozesslandkarte Marketingprozess... 80

9 Inhaltsverzeichnis v Verkaufsprozess Serviceprozess Kundenprozessunterstützungs-Prozess Portalbetriebsprozess Produktentwicklungsprozess Leistungserstellungsprozess Führungsprozess Unterstützungsprozesse Vertriebskanäle Gestaltungsdeterminanten Kernleistungen über herkömmliche Mensch-Mensch-Kanäle Kernleistungen über neue Kanäle Standardisierte Zusatz- und Infrastrukturleistungen über neue Kanäle Individualisierte Zusatz- und Infrastrukturleistungen Konzeption eines Prozessportals für Erbschaft und Bestattung Kundenprozess des Erblassers Kundenprozess des Erben Übersicht über Aufgaben und Leistungen Leistungen des Prozessportals Prozesse des Portalbetreibers IS-Architektur Funktionen und Daten Beschreibungsraster Datenbestände Kategorisierung der Datenzugriffe IS-Funktionen Marketingfunktionen Verkaufsfunktionen Servicefunktionen Kundenprozessunterstützungs-Funktionen

10 vi Inhaltsverzeichnis Portalbetriebsfunktionen Prozessübergreifende Funktionen Unterstützungsfunktionen Gestaltungsdeterminanten Kernleistungen über herkömmliche Mensch-Mensch-Kanäle Kernleistungen über neue Kanäle Standardisierte Zusatz- und Infrastrukturleistungen über neue Kanäle Individualisierte Zusatz- und Infrastrukturleistungen Applikationen Applikationstypen Anforderungen an eine Applikationsarchitektur Applikationsarchitekturen ausgewählter Hersteller SAP Oracle Siebel Uniquare Fallbeispiel: Applikationslandschaft bei Microsoft Deutschland GmbH IS-Architektur des Prozessportals für Erbschaft und Bestattung Kernleistungen Zusatzleistungen Infrastrukturleistungen Weitere Leistungen und Basisfunktionen Applikationen Fazit und Ausblick Zusammenfassung der Ergebnisse Herausforderungen und Potenziale Ausblick Internet Appliances Mobile Endgeräte Der Kunde als Portalbetreiber

11 Inhaltsverzeichnis vii The Grid Anhang A: Prozessarchitektur Aufgabenbeschreibungen A.1 Aufgaben des Marketingprozesses A.2 Aufgaben des Verkaufsprozesses A.3 Aufgaben des Serviceprozesses A.4 Aufgaben des Kundenprozessunterstützungs-Prozesses A.5 Aufgaben des Portalbetriebsprozesses A.6 Aufgaben des Produktentwicklungsprozesses A.7 Aufgaben des Leistungserstellungsprozesses A.8 Aufgaben des Führungsprozesses Anhang B: Prozessportal für Erbschaft und Bestattung B.1 Aufgaben im Kundenprozess des Erblassers B.2 Aufgaben im Kundenprozess des Erben B.3 Leistungen des Prozessportals Anhang C: Funktionen der IS-Architektur C.1 Marketingfunktionen C.2 Verkaufsfunktionen C.3 Servicefunktionen C.4 Portalbetriebsfunktionen C.5 Kanalunabhängige, prozessübergreifende Funktionen C.6 Kanalspezifische, prozessübergreifende Funktionen Anhang D: Verzeichnis der Gespräche mit Herstellern und Anwendern D.1 Hersteller D.2 Anwender Literaturverzeichnis

12

13 Abkürzungsverzeichnis ix Abkürzungsverzeichnis ATM B2B B2C CAS CRM CSS E-CRM EIP EMA ERM erm ICE IS IT POS PRM SFA WAP WWW XML Automatic Teller Machine Business-to-Business Business-to-Consumer Computer Aided Selling Customer Relationship Management (deutsch: Kundenbeziehungsmanagement) Customer Service and Support Electronic Customer Relationship Management Enterprise Information Portal Enterprise Marketing Automation Enterprise Relationship Management erelationship Management Information and Content Exchange Protocol Informationssystem Informationstechnologie Point of Sales Partner Relationship Management Sales Force Automation Wireless Application Protocol World Wide Web Extensible Markup Language

14

15 Einführung 1 1 Einführung 1.1 Problemstellung Die Credit Suisse verfolgt verschiedene Aktivitäten zur Neugestaltung der Kundenbeziehung: Zur Realisierung von Relationship-Management-Ansätzen gestaltet sie die Prozesse und Informationssysteme am Arbeitsplatz des Kundenberaters neu [Jaeger et al. 2000] und führt eine umfassende Data Warehousing-Lösung ein. Das Potenzial elektronischer Kundenschnittstellen nutzt sie mit einem modernen Internet-Banking ( und Online-Brokerage ( Ein Komplettangebot aus eigenen und branchenfremden Leistungen bietet sie im Immobilienbereich mit an (s. Kapitel 3.2). Die meisten Banken verfolgen derzeit ähnliche Ansätze wie die Credit Suisse. Sie reagieren damit auf eine Wettbewerbsdynamik, die in den letzten Jahren stark gestiegen ist. Besonders im Privatkundengeschäft verschärft sich die Konkurrenzsituation: Deregulierungen und Internationalisierung verstärken den Wettbewerb unter bisherigen Konkurrenten, Nearbanks wie beispielsweise Versicherungen bieten vermehrt Bankdienstleistungen an (z.b. Zürich Financial Services), und auch branchenfremde Anbieter sogenannte Nonbanks wie etwa Kaufhauskonzerne, Tankstellenorganisationen und Versandhäuser bieten klassische Bankdienstleistungen an [Bernet 1995, S.32f.; vgl. Koch 2000]. Gleichzeitig verändert sich auch der typische Privatkunde: Er ist nicht zuletzt durch das Informationsangebot im Internet besser informiert, vergleicht Bankleistungen nach sachlichen Kriterien und fordert ein adäquates Preis- Leistungs-Verhältnis. Durch den verstärkten Technologieeinsatz verlieren viele Kunden ihre persönliche Beziehung zur Bank; die Kundenloyalität nimmt ab, parallele Beziehungen zu mehreren Banken werden zur Regel [Held 1998, S.37f.]. Da die Bankdienstleistungen verschiedener Anbieter immer weniger qualitative Unterscheidungsmerkmale bieten und auch der Wettbewerb über den Preis aufgrund stetig sinkender Margen schnell an seine Grenzen stösst, versuchen die Institute zunehmend, sich durch die Gestaltung der Kundenbeziehung zu differenzieren [Bernet 1995, S.42ff.; Ernst & Young 1999, S.23]. Aus dieser Situation heraus sind verschiedene Ansatzpunkte entstanden: einerseits das Customer Relationship Management (CRM, s. Kapitel 2.1) oder bezogen auf die Bankenbranche das Relationship Banking [vgl. Bernet/Held 1998]. Mit diesen Begriffen werden verschiedene Aktivitäten bezeichnet, die möglichst langfristige und profitable Kundenbeziehungen zum Ziel haben [vgl. Tomczak/Dittrich 1997, S.9f.]. Andererseits haben die Banken begonnen, durch eine Bündelung der Finanzdienstleistungen mit branchenfremden Leistungen [Bernet 1995, S.44] (z.b. Immobilien-

16 2 Einführung vermittlung) und durch die Nutzung neuer technischer Potenziale (v.a. des World Wide Web) die eigenen Leistungen wieder attraktiver zu machen. Die meisten dieser Ansätze sind nur mit Hilfe moderner Informationstechnologie realisierbar [Fischer 1998; Siebel 1999, S.263ff.]. Eine Vielzahl von Softwareprodukten ist in den letzten Jahren auf den Markt gekommen, wobei sich die kundenkontaktorientierten CRM-Lösungen, die analyseorientierten Data-Warehousing-Produkte und die internetorientierten E-Business-Anwendungen parallel entwickelt haben und erst in letzter Zeit beginnen, zu integrierten Lösungen zusammenzuwachsen (s. Kapitel 7.2). Unternehmen, die zur Unterstützung der Kundenbeziehung neue organisatorische und technische Massnahmen einführen wollen, können bisher auf wenig Erfahrung zurückgreifen. Für ein systematisches Vorgehen im Sinne des Business Engineering [vgl. Österle/Winter 2000] existiert zwar ein Methodenvorschlag [Schulze 2000], es fehlt aber bisher eine Prozess- und Systemarchitektur, die als Referenz herangezogen werden kann. Insbesondere ist eine integrierte Betrachtung herkömmlicher und elektronischer Kundenschnittstellen erforderlich. 1.2 Ziele und Adressaten der Arbeit Das Institut für Wirtschaftsinformatik der Universität St. Gallen hat aktuelle Trends in Technik, Gesellschaft und Politik analysiert und eine mögliche Struktur der zukünftigen wirtschaftlichen Zusammenhänge entwickelt. Im Vordergrund steht dabei die Nutzung neuer technischer Potenziale in Form des E-Business. Diese möglichen Entwicklungen wurden im sogenannten Geschäftsmodell des Informationszeitalters beschrieben (s. Kapitel 2.4). Es dient als Bezugsrahmen für die vorliegende Arbeit. Forschungsgegenstand der Arbeit ist die Schnittstelle zum Kunden. Ausgangspunkt bildet die Feststellung, dass der Grad der Kundenorientierung in Zukunft ein wesentlicher Wettbewerbsfaktor sein wird. Eine wichtige Aufgabe der Unternehmen ist demnach das Management der Kundenbeziehungen, das Customer Relationship Management (s. Kapitel 2.1). Ein hohes Potenzial für die Neugestaltung der Kundenschnittstelle bietet der Einsatz von Internetportalen (s. Kapitel 2.2). Ein Mittel zur Verbesserung der Kundenorientierung ist die Ausrichtung der Leistungen auf die Prozesse des Kunden. Verbindet man die Kundenprozessorientierung mit Customer Relationship Management und Internetportalen, so ergibt sich das Konzept der Prozessportale (s. Kapitel 2.3). Das Ziel der vorliegenden Arbeit ist die Beschreibung einer Architektur, die im oben erläuterten Kontext des Geschäftsmodells des Informationszeitalters Aufbau und Betrieb von Prozessportalen sowie die organisatorische und technische Umsetzung von Customer Relationship Management-Konzepten ermöglicht. Weiteres Ziel in diesem Zusammenhang ist eine Zusammenstellung von Kriterien, die beim Aufbau und Be-

17 Einführung 3 trieb eines Prozessportals beachtet werden müssen, um möglichst gute Erfolgsaussichten zu haben. Um das Thema im Rahmen einer Dissertation handhabbar zu machen, hat der Autor folgende Fokussierungen vorgenommen: Die Ergebnisse richten sich an Banken im Privatkundengeschäft. Der Grund für diese Wahl des Branchenfokus liegt einerseits in der Aktualität des Themas für die Branche (s. Kapitel 2.5) und andererseits in der Zusammensetzung des Kompetenzzentrums Customer Relationship Management aus fünf Banken und einer Versicherung. Die Einschränkung auf das Privatkundengeschäft der Banken impliziert eine Fokussierung auf den Business-to-Consumer-Bereich (B2C) bei der Kundenschnittstelle. Eine Architektur kann auf den vier Ebenen Geschäft, Prozess, Informationssystem und Informationstechnik beschrieben werden (s. Kapitel 4.1). Die Arbeit beschränkt sich auf die Ebenen Prozess und Informationssystem. Einen kurzen Überblick über die Geschäftsebene gibt Kapitel 5. Die Ebene der Informationstechnik ist sehr stark abhängig von den Gegebenheiten des einzelnen Unternehmens, so dass die Beschreibung einer generalisierten Architektur nicht sinnvoll erscheint. Bei der Prozessarchitektur wird zwischen Geschäfts- und Unterstützungsprozessen unterschieden (s. Kapitel 4.2). Die in der vorliegenden Arbeit beschriebene Architektur konzentriert sich auf Geschäftsprozesse und -funktionen. Wichtige Unterstützungsprozesse und -funktionen werden in den Kapiteln und erläutert, detailliert werden diese in anderen Arbeiten am selben Lehrstuhl behandelt (s. Kapitel 1.3). Die Dissertation wendet sich gleichermassen an Adressaten aus Wissenschaft und Praxis. Im wissenschaftlichen Bereich richtet sich die Arbeit in erster Linie an Forscher aus den Fachgebieten Betriebswirtschaftslehre und Wirtschaftsinformatik, denen sie in folgenden Bereichen einen Erkenntniszuwachs bringt: Die Arbeit leistet einen Beitrag zur Strukturierung der uneinheitlichen Begriffswelt im Bereich E-Business. Verschiedene Begriffe wie z.b. Customer Relationship Management werden definiert sowie das Konzept der Prozessportale erläutert und in den Kontext bekannter Konzepte eingeordnet. Bisher verfügbare Modelle des Verkaufsprozesses umfassen vorwiegend Aspekte der Verkaufsabwicklung [vgl. z.b. Scheer 1997, S.455ff.; SAP AG 2000b]. Die vorliegende Arbeit bezieht sämtliche Kundenkontakte in Marketing, Kundenberatung, Verkauf und After-Sales-Service ein und entwickelt daraus ein integriertes Prozessmodell für das Customer Relationship Management bei Banken.

18 4 Einführung Mit dem Entwurf eines Architekturvorschlages für CRM und Prozessportale wendet die Arbeit das Konzept der Informationssystem-Architekturen an. Die Veranschaulichung an konkreten Beispielen ermöglicht dem Wissenschaftler ein besseres Verständnis des Architekturkonzeptes und dient als Beleg für dessen Praxistauglichkeit. Der konkrete Architekturvorschlag auf Prozess- und Informationssystem-Ebene bringt Wirtschaftsinformatikern vor allem in den Bereichen des Prozessentwurfs und der Systementwicklung eine Erweiterung der bestehenden Erkenntnisse. In der Praxis richtet sich die Arbeit einerseits an Business Engineers [zum Begriff vgl. Baumöl/Winter 2000], also z.b. an Projektleiter oder an Unternehmensberater, und andererseits an Hersteller von Standardsoftware. Dieser Zielgruppe bringt die Arbeit folgenden Nutzen: Business Engineers können die Architektur zur Unterstützung eigener Projekte verwenden. Die in der Architektur spezifizierten Komponenten können als Ausgangspunkt dienen und eigenen Gegebenheiten angepasst werden. Da die Architektur in Kooperation mit Praxispartnern entwickelt wurde und somit konsolidierte Praxiserfahrungen beinhaltet, ermöglicht sie eine Verkürzung der Projektdauer und eine Reduktion des Projektrisikos. Das genaue Vorgehen bei der Anwendung der Architektur ist in Kapitel 4.3 beschrieben. Bestehende Portale können anhand der Kriterien in Kapitel 3 überprüft werden, um Verbesserungspotenziale zu identifizieren. Durch Anwendung dieser Kriterien können möglicherweise die Nutzerzahlen erhöht oder die Kundenbindung verbessert werden. Softwarehersteller können die Architektur nutzen, um Funktionsumfang und Strukturierung der eigenen Produkte zu überprüfen und zu verbessern. Durch eine Orientierung an der Architektur kann die Vollständigkeit der realisierten Funktionalitäten verbessert werden. Der detaillierte Nutzungsprozess der Architektur ( Kundenprozess der Dissertation ) ist in Kapitel 4.3 ausführlich beschrieben. 1.3 Einordnung der Arbeit Die Arbeit entstand im Rahmen des Kompetenzzentrums Customer Relationship Management (CC CRM) des Forschungsprogramms Business Engineering Universität St. Gallen (BE HSG) am Institut für Wirtschaftsinformatik der Universität St. Gallen. Die Kompetenzzentren des Programms BE HSG forschen anwendungsorientiert auf strategischen Gebieten der Wirtschaftsinformatik in enger Kooperation mit der Praxis. Zusätzlichen Einfluss auf die Arbeit hatte die Mitarbeit im Kompetenzzentrum Busi-

19 Einführung 5 ness Knowledge Management (CC BKM). Die folgenden Partnerunternehmen waren in den Kompetenzzentren CC CRM und CC BKM vertreten: ABB Business Services AGI IT Services Bank Austria Credit Suisse Helsana Landesbank Baden-Württemberg Deutsche Telekom Union Investment Verschiedene abgeschlossene und laufende Dissertationen sowie Forschungsprojekte an der Universität St. Gallen stehen in engem thematischem Zusammenhang mit der vorliegenden Arbeit: Die Grundlagen zu Prozessanalyse und -entwurf basieren im Wesentlichen auf der Dissertation von Thomas Hess zum Prozessentwurf [Hess 1996]. Die Dissertation von Andreas Muther zum Thema Electronic Customer Care [Muther 1999] liefert verschiedene Grundlagen in Bezug auf Customer Relationship Management und elektronische Kundenschnittstellen. Jens Schulze beschreibt in seiner Dissertation eine Methode zur Einführung von Customer Relationship Management [Schulze 2000]. Die in der vorliegenden Arbeit beschriebene Architektur kann im Rahmen der Methode als Referenzlösung eingesetzt werden (s. Kapitel 4.3). Oliver Christ verfasst derzeit eine Dissertation zum Thema Prozess- und Systemarchitektur für das Content Management. Das Content Management umfasst verschiedene Unterstützungsprozesse, die im Zusammenhang mit Portalen wesentlich sind. Die bei Christ beschriebene Architektur ergänzt daher die vorliegende Arbeit. Die Kundenschnittstelle im Business-to-Business-Bereich (B2B) ist Thema der laufenden Forschungsarbeit von Thomas Puschmann. Diese kann als Ergänzung zur vorliegenden Arbeit betrachtet werden, die sich auf den Business-to-Consumer- Bereich konzentriert. Die laufenden Dissertationen von Veith Körner (Institut für Medien und Kommunikationsmanagement MCM, Prof. Dr. Beat Schmid) und Claudio Deplazes (Zuger Kantonalbank, Doktorand am Schweizerischen Institut für Banken und Finanzen s/bf-hsg, Lehrstuhl Prof. Dr. Beat Bernet) beschäftigen sich mit verwandten Themen im Bereich Customer Relationship Management.

20 6 Einführung Das Kompetenzzentrum Bankenarchitekturen im Informationszeitalter (CC BAI) am Lehrstuhl von Prof. Dr. Robert Winter entwickelt ausgehend vom Geschäftsmodell des Informationszeitalters (s.o.) eine Referenzarchitektur für Banken auf allen Ebenen. Zwischen Mitarbeitern des Kompetenzzentrums und dem Autor fand eine Zusammenarbeit statt. Die Ergebnisse der vorliegenden Arbeit fliessen auch in das CC BAI ein. Das Kompetenzzentrum Data Warehousing Strategie (CC DWH) am Lehrstuhl von Prof. Dr. Robert Winter behandelt Themen, die in engem Zusammenhang mit Customer Relationship Management stehen (s. Kapitel 6.4 und 7.3.1) [vgl. Jung/Winter 2000]. Das Institut für Marketing und Handel (IMH-HSG), Lehrstuhl von Prof. Dr. Torsten Tomczak, führt verschiedene Projekte in für die vorliegende Arbeit relevanten Teilgebieten des Marketings durch. Insbesondere die Dissertation von Sabine Dittrich zum Thema Kundenbindung [Dittrich 2000] lieferte wertvolle Grundlagen für die Arbeit. Eine Vielzahl von Arbeiten beschäftigt sich mit Informationssystem-Architekturen; die meisten davon beschränken sich jedoch auf eine Architektur auf IT-Ebene und haben daher einen anderen Fokus als die vorliegende Arbeit, die sich auf die Prozess- und IS- Ebenen konzentriert (s. Kapitel 4). Die folgenden Arbeiten stehen in engem thematischem Zusammenhang mit der vorliegenden Arbeit: [Rahm 1999] diskutiert Informationssystem-Architekturen bei Banken. Er beschreibt verschiedene Architekturkonzepte, die sich auf die gesamte Applikationslandschaft der Banken beziehen und stellt einen Ansatz zur Entwicklung einer bankindividuellen Architektur dar. [Schmalzl 1995] behandelt Architekturmodelle für Informationssysteme bei Kreditinstituten. Er betrachtet die Ebenen Prozess, IS und IT, wobei der Schwerpunkt auf IS- und IT-Ebene liegt. Er beschreibt Referenzmodelle für die Architektur anhand verschiedener Geschäftssituationen, entwirft dabei aber keine konkreten Lösungsvorschläge, sondern beschränkt sich auf die Darstellung der Einflussfaktoren beim Architekturentwurf. [Hoque 2000] beschreibt eine E-Business-Architektur auf den Ebenen Strategie, Prozess, Informationssystem und Informationstechnologie. Der Schwerpunkt der Ausführungen liegt auf strategischen Aspekten; Prozessanforderungen sind nicht im Detail ausgearbeitet. Die IS- und IT-Architekturen beinhalten die verschiedenen erforderlichen Komponenten und deren Zusammenhang, stellen aber keinen direkten Prozessbezug her. [Kalakota/Robinson 1999] konzipieren eine umfassende E-Business-Architektur auf Prozess- und IS-Ebene. Dabei werden sowohl die Einkaufsseite und die Ver-

21 Einführung 7 kaufsseite als auch die Schnittstellen zu Angestellten und zum Management betrachtet. Auf der IS-Ebene werden Applikationen zur Prozessunterstützung erläutert. Ein weiterer Fokus sind unterstützende Prozesse und Applikationen (z.b. Knowledge Management) und Integrationsaspekte. [Rajput 2000] führt kurz in Aspekte des E-Commerce auf Strategie- und Prozessebene ein, konzentriert sich aber im Detail auf die IT-Ebene. Die einzelnen technischen Komponenten und deren Zusammenspiel werden sehr detailliert analysiert und erläutert. [Ovum 2000, S.42ff.] beschreibt funktionale Aspekte von Portalen und stellt verschiedene Standardprodukte vor. Der Schwerpunkt der Betrachtung liegt auf der IS-Ebene. In [McCullough et al. 2000, S.11] ist eine E-Business-Architektur dargestellt. Diese fokussiert sich jedoch auf emarketplaces und beschränkt sich auf die Beschreibung von Funktionen auf IS-Ebene. Die vorliegende Arbeit weist folgende Charakteristika auf, die in dieser Kombination keine dem Autor bekannte Arbeit bietet: Die entwickelte Architektur bezieht sich auf die Kundenschnittstelle auf Prozessund Informationssystemebene. Der Branchenfokus liegt bei Banken und konzentriert sich dort auf den Businessto-Consumer-Bereich. Diese enge Fokussierung erlaubt einen hohen Detaillierungsgrad der spezifizierten Prozesse und Funktionalitäten. Die Architektur verbindet die externe Sicht auf die Kundenschnittstelle (Kundenprozess, Portale etc.) mit den internen, organisatorischen Aspekten der Kundenbeziehung (Customer Relationship Management). Durch die Berücksichtigung verschiedener Vertriebskanäle wird eine Verbindung zwischen E-Business und herkömmlichem Business hergestellt. 1.4 Forschungsmethodik Die Wirtschaftsinformatik ist eine praxisorientierte Wissenschaft. Sie befasst sich mit Informationssystemen und Informationsinfrastrukturen von Organisationen in Wirtschaft und Verwaltung. Ihre Aufgabe ist die Erklärung, die Prognose des Verhaltens und die Gestaltung dieser Systeme, wobei die meisten der bisher vorhandenen Ergebnisse der Gestaltungsaufgabe zuzuordnen sind [Heinrich/Sinz 1999, S.1017]. Als angewandte Wissenschaft bezieht die Wirtschaftsinformatik wie die Betriebswirtschaftslehre die Problemstellungen aus der Praxis. Gemäss [Ulrich 1984, S ] trifft die Betriebswirtschaftslehre wertende und normative Aussagen und versucht, die betrieb-

22 8 Einführung liche Wirklichkeit aktiv zu gestalten. Die praktische Problemlösungskraft ihrer Modelle und Handlungsempfehlungen ist dabei der Massstab für die Qualität der Arbeit. Auf dieser Grundlage haben [Österle et al. 1991, S.35ff.] einen Forschungsprozess definiert, der diese Grundsätze auf die Wirtschaftsinformatik als Teilgebiet der Betriebswirtschaftslehre anwendet. Wissenschaft und Praxis definieren gemeinsam die Probleme. Die Wissenschaft strukturiert die Probleme und entwickelt Vorschläge zur Gestaltung der betrieblichen Wirklichkeit. Sie bringt dabei theoretisches Wissen, Beobachtungen in der Praxis und eigene Erfahrungen mit ein. Die Vorschläge werden zusammen mit der Praxis überprüft und verfeinert. Die Praxis wendet die Vorschläge selbst an, gestaltet also die betriebliche Wirklichkeit gemäss den Vorschlägen. Anschliessend werden die Ergebnisse überprüft und die Vorschläge entsprechend weiterentwickelt [vgl. Ulrich 1984, S ]. Dieser Ansatz entspricht dem Vorgehen beim Action Research [vgl. Avison et al. 1999]. Der Forschungsprozess wird dabei iterativ angewendet und stellt so die unmittelbare Relevanz der Forschungsergebnisse in der Praxis sicher [s. Stringer 1996]. Die vorliegende Arbeit stützt sich auf diesen Forschungsprozess. Sie verwendet ausschliesslich Mittel, welche den qualitativen Forschungsansatz repräsentieren [vgl. Tomczak 1992; Mayring 1996]: Desk Research Der Desk Research diente zur Erarbeitung der Grundlagen und des Bezugsrahmens für die Arbeit. Berücksichtigt wurde wissenschaftliche und populärwissenschaftliche Literatur aus den Bereichen der Marketingforschung, der Wirtschaftsinformatik, der Informatik und der Managementlehre. Ausserdem untersuchte der Autor die Funktionalitäten und Architekturen verschiedener Standardsoftware- Produkte. Projektmitarbeit Die Mitarbeit des Autors in konkreten Projekten bei Partnerunternehmen des Instituts für Wirtschaftsinformatik (s. Kapitel 1.3) war eine wesentliche Informationsquelle für die Ausführungen in dieser Arbeit. Gemäss dem oben beschriebenen Forschungsprozess konnte der Autor Teile der entwickelten theoretischen Konzepte in die Projekte einbringen und die Umsetzung beobachten. Expertengespräche Interviews mit Vertretern von Anwendern (i.d.r. Projektleiter) und von Softwareherstellern dienten dem Autor als Informationsquelle über bestehende Lösungen und Probleme in der Praxis sowie über verfügbare Standardsoftware-Produkte. Die Expertengespräche (s. Anhang D) wurden zur Ergänzung der durch Projektmitarbeit gewonnenen Erkenntnisse geführt. Fallbeispiele Die Fallbeispiele basieren auf den Expertengesprächen, auf der Projektmitarbeit

23 Einführung 9 und auf den Ergebnissen des Desk Research. Sie dienen dem Autor zur Veranschaulichung theoretischer Konzepte anhand konkreter Praxisbeispiele. Damit wird auch die Praxisrelevanz der Forschungsergebnisse belegt. Bei der Beschreibung der Fallbeispiele kommen auch Ansätze der qualitativen Evaluationsforschung zum Einsatz [s. Mayring 1996, S.45ff.]. Workshops Die Workshops mit den Vertretern der Partnerunternehmen im Rahmen der Kompetenzzentren CC CRM und CC BKM (s. Kapitel 1.3) boten eine ideale Gelegenheit, um die theoretischen Konzepte mit Projektleitern und Führungskräften zu diskutieren, weiterzuentwickeln und zu verifizieren. Die in der vorliegenden Arbeit beschriebene Architektur (s. Kapitel 5 und 7) ist als generisches Modell zu verstehen, das in einer konkreten Problemstellung als Referenz herangezogen werden kann. Der Autor orientiert sich an dem konstruktivistischen Modellbegriff, bei dem das Modell nicht als Abbild, sondern als (Re-)Konstruktion der Realität betrachtet wird. Die mit der Modellierung geleistete Strukturierung wird dabei als konstruktiver Akt verstanden. Die erstellte Struktur ist an der Zweckdienlichkeit für das verfolgte Ziel die Problemlösung zu messen. Bereits durch die Strukturierung kann ein solches Modell einen wesentlichen Beitrag zur Problemlösung leisten, da ein echtes Problem gerade durch eine fehlende Struktur gekennzeichnet ist [ vgl. Thommen 1996, Kap.4; Dresbach 1997]. Die Architektur wurde nach der induktiven Methode hergeleitet [vgl. Balzer 1997, S.260ff.]: Untersucht wurden bestehende Prozessarchitekturen, Informationssystemarchitekturen und Softwareprodukte, aus denen die generische Architektur abgeleitet wurde (s. Kapitel 5 und 7). Im Sinne des Action Research (s.o.) wurden wesentliche Teile der Architektur erfolgreich in Projekten der Partnerunternehmen des CC CRM eingesetzt. Ausserdem wurden die Architekturbestandteile in gemeinsamen Workshops mit den Partnerunternehmen verifiziert. Daraus lassen sich aber keine verlässlichen Aussagen über die Leistungsfähigkeit der Architektur ableiten; über ihre Problemlösungskraft kann letztlich nur die praktische Anwendung entscheiden. Daher lässt sich die Leistungsfähigkeit erst in einigen Jahren retrospektiv beurteilen. Die hier beschriebene generische Architektur soll somit als Vorschlag für ein Architekturreferenzmodell betrachtet werden [zum Begriff des Referenzmodells vgl. Scholz-Reiter 1990, S.30]. 1.5 Aufbau der Arbeit Abb. 1-1 illustriert den Aufbau der vorliegenden Arbeit. Das erste Kapitel führt in die Thematik der Dissertation ein und erläutert Problemstellung, Ziele und Adressaten der Arbeit. Ausserdem wird die Arbeit in die Forschungslandschaft eingeordnet sowie die zugrunde liegende Forschungsmethodik dargestellt. Kapitel zwei fasst die wesentli-

24 10 Einführung chen Grundlagen zusammen und erläutert die wichtigsten Begriffe und die relevanten Entwicklungen in der Bankenbranche. Kapitel drei stellt die Kriterien dar, die bei Aufbau und Betrieb eines erfolgreichen Prozessportals beachtet werden müssen und illustriert diese anhand eines konkreten Fallbeispiels. Den Kern der Arbeit bilden die Kapitel vier bis sieben mit der Beschreibung einer Architektur für Customer Relationship Management und Prozessportale. Kapitel vier führt in den Architekturbegriff ein und erläutert die Strukturierung, welche der Architekturbeschreibung zugrunde liegt. Kapitel fünf gibt einen kurzen Überblick über die Architektur auf Geschäftsebene. Kapitel sechs beschreibt die Architektur auf Prozessebene mit Leistungen, Prozessen und Aufgaben. Kapitel sieben behandelt die IS-Ebene der Architektur und erläutert Funktionen, Daten und Applikationen. Schliesslich fasst Kapitel acht die Ergebnisse der Dissertation zusammen und gibt einen Ausblick auf mögliche zukünftige Entwicklungen. 1. Einführung 2. Grundlagen 4. Anforderungen an eine Architektur 5. Geschäftsarchitektur 6. Prozessarchitektur Leistungen Prozesse Aufgaben 7. IS-Architektur 3. Erfolgsfaktoren für Prozessportale Funktionen Daten Applikationen 8. Zusammenfassung und Ausblick Abb. 1-1: Aufbau der Dissertation

25 Grundlagen 11 2 Grundlagen 2.1 Customer Relationship Management Begriffsdefinition Es existiert keine allgemein anerkannte Definition des Begriffs Customer Relationship Management (CRM). Der Begriff und das zugehörige Konzept sind entstanden durch das Zusammenwachsen verschiedener anderer Konzepte wie Beziehungsmarketing (Relationship Marketing), Marketingautomatisierung (Enterprise Marketing Automation), Verkaufsautomatisierung (Sales Force Automation) und Serviceautomatisierung (vgl. Kapitel 7.3.1). [Mogicato 2000, S.11ff.] erläutert die verschiedenen Begriffe und deren Zusammenhang zu CRM. Die Entwicklung des CRM aus den genannten Konzepten ist in [Schulze 2000, S.10ff.] dargestellt. Dort wird auch CRM definiert als ( ) kundenorientierter Managementansatz, bei dem Informationssysteme das erforderliche Wissen zur Unterstützung der Frontoffice-Prozesse im Marketing, Verkauf und Service sammeln, analysieren und integriert bereitstellen. ( ) [Schulze 2000, S.18]. Während bei dieser Definition klar die Unterstützung durch Informationssysteme im Vordergrund steht, definiert Kunz den deutschen Begriff Kundenbeziehungsmanagement allgemeiner: Kundenbeziehungsmanagement ist die Summe aller unternehmerischen Entscheidungen und Handlungen, die auf den Aufbau und die Erhaltung von längerdauernden Beziehungen zwischen dem Unternehmen und seinen Kunden abzielen. [Kunz 1996]. Verschiedene gängige Definitionen aus Wissenschaft, Literatur und Beratung sind in [ECCS 2000] zusammengefasst. Die Mehrzahl der Definitionen beschränkt CRM auf Marketingaspekte im Sinne des Beziehungsmarketings. Dabei werden jedoch die Aspekte der Kundenbeziehung vernachlässigt, die z.b. in den Bereichen Verkauf und Service liegen. Eine detailliertere und sehr praxisnahe Definition stammt von Robert Shaw: "Customer relationship management is an interactive process achieving the optimum balance between corporate investments and the satisfaction of customer needs to generate the maximum profit. CRM involves: measuring both inputs across all functions including marketing, sales and service costs and outputs in terms of customer revenue, profit and value.

26 12 Grundlagen acquiring and continuously updating knowledge about customer needs, motivation and behaviour over the lifetime of the relationship. applying customer knowledge to continuously improve performance through a process of learning from successes and failures. integrating the activities of marketing, sales and service to achieve a common goal. the implementation of appropriate systems to support customer knowledge acquisition, sharing and the measurement of CRM effectiveness. constantly flexing the balance between marketing, sales and service inputs against changing customer needs to maximize profits" [ECCS 2000]. In Anlehnung an die Definition von Robert Shaw dient die folgende Definition des Begriffs Kundenbeziehungsmanagement bzw. Customer Relationship Management als Grundlage für die vorliegende Arbeit: Customer Relationship Management (CRM, Kundenbeziehungsmanagement) bezeichnet ein kundenorientiertes Managementkonzept mit dem Ziel, das Gleichgewicht zwischen unternehmensseitigen Investitionen und der Befriedigung von Kundenbedürfnissen zu erreichen, um so die Profitabilität zu maximieren. Die wesentlichen Aufgaben von Customer Relationship Management sind: Messung der Aufwendungen für alle Aktivitäten einschliesslich der Marketing-, Verkaufs- und Service-Kosten und der Erträge in Form von Kundenumsatz, Kundengewinn und Kundenwert Gewinnung und laufende Aktualisierung von Wissen über Kunden (Bedürfnisse, Motivation und Verhalten), Produkte und Umfeld (Märkte, Konkurrenten, ) Laufende Anwendung dieses Wissens in allen Unternehmensprozessen, insbesondere in Marketing, Verkauf und Service mit dem Ziel, für jede individuelle Kundenbeziehung das oben beschriebene Gleichgewicht zu finden Integration der Aktivitäten in Marketing, Verkauf und Service zur Erreichung gemeinsamer Ziele Etablierung und zielgerichteter Einsatz verschiedener Vertriebskanäle und Sicherstellung der Konsistenz zwischen den einzelnen Kanälen Laufende Anpassung der CRM-Aktivitäten an sich ändernde Kundenbedürfnisse Einsatz von Informationssystemen zur Unterstützung aller genannten Aufgaben von CRM, insbesondere der Wissensgewinnung und der Wissensnutzung sowie der Integration und der Messung der Effektivität von Customer Relationship Management

27 Grundlagen Ziele und Instrumente Nach dem aufgabenorientierten Ansatz umfasst das Marketing die vier Kernaufgaben Kundenakquisition und Kundenbindung sowie Leistungsinnovation und Leistungspflege [s. Tomczak/Reinecke 1996]. Customer Relationship Management unterstützt die Aufgaben Kundenakquisition und Kundenbindung, indem es die Schnittstelle vom Unternehmen zum Kunden so gestaltet, dass die Kundenbedürfnisse möglichst gut befriedigt werden (vgl. Definition in Kapitel 2.1.1). Im klassischen Transaktionsmarketing wurde jeder Kauf als isoliertes, unabhängiges Ereignis betrachtet. Der Schwerpunkt der Marketingaktivitäten lag daher in der Kundenakquisition, in die Kundenbindung wurde wenig investiert. Im heute aktuellen Beziehungsmarketing strebt ein Unternehmen eine möglichst lang andauernde Kundenbeziehung an, während der ein Kunde wiederholt Käufe tätigt [vgl. Schulze 2000, S.12f.]. Dieser Trend wird dadurch begründet, dass es fünf- bis siebenmal teurer ist, einen Neukunden zu gewinnen als einen bestehenden Kunden zu halten. Die Profitabilität eines Kunden steigt mit der Dauer der Kundenbeziehung [Kunz 1996, S.17f.]. Sowohl bei der Kundenakquisition als auch bei der Kundenbindung müssen sich die Aktivitäten auf diejenigen (potenziellen) Kunden konzentrieren, die zur Erhöhung der Profitabilität beitragen. Während bei der Kundenakquisition nur auf der Basis von Erfahrungswerten extrapoliert werden kann, welche Marktsegmente potenziell profitabel sind, besitzt ein Unternehmen über bestehende Kunden meist Daten, die zu einer Kundenbewertung herangezogen werden können. Verschiedene Bewertungskriterien und Ansätze zur Kundenbewertung sind in [Tomczak/Dittrich 1997, S.18ff.] dargestellt. Neben den Möglichkeiten der faktischen Kundenbindung durch ökonomische oder rechtliche Bindungen [s. Tomczak/Dittrich 1997, S.24f.] zielen die meisten Kundenbindungsmassnahmen auf die Erhöhung der Kundenzufriedenheit und auf die Steigerung des Vertrauens des Kunden gegenüber dem Unternehmen ab [s. Tomczak/Dittrich 1997, S.26ff.]. Die einzelnen Massnahmen sind in [Dittrich 2000, S.144ff.] detailliert beschrieben. Voraussetzung für die Umsetzung der verschiedenen Massnahmen ist die Verfügbarkeit des vorhandenen Wissens über Kunden aus allen Unternehmensbereichen und über alle Prozesse hinweg. Um die Erfassung und Nutzung dieses Wissens zu strukturieren, gestaltet man beim Customer Relationship Management die Prozesse an der Kundenschnittstelle neu. Sie orientieren sich an den vier Phasen Anregung, Evaluation, Kauf und After-Sales des Customer Buying Cycles [vgl. Mauch 1990; s. Muther 1999, S.14ff.] oder an spezifischen Kundenprozessen (s. Abschnitt 2.3). Unternehmensseitig gehören die Prozesse Marketing, Verkauf und Service zu den CRM- Prozessen. Jeder Kundenkontakt kann einem dieser Prozesse zugeordnet werden [vgl. Schmid/Bach 2000a, S.34]. Der Marketingprozess deckt dabei im Wesentlichen Aufgaben des Kampagnenmanagements im Sinne des Direktmarketings ab. Er repräsen-

28 14 Grundlagen tiert somit nur einen kleinen Ausschnitt des gesamten Marketing-Aufgabengebietes (s.o.). Die Prozesssicht wird in Kapitel 5 detailliert behandelt. Erst die Unterstützung der CRM-Prozesse durch geeignete Informationssysteme ermöglicht die Umsetzung des CRM. [Schulze 2000, S.19]. Auch wenn die oben beschriebenen Konzepte der Kundenbindung und des Customer Relationship Managements prinzipiell unabhängig vom Einsatz bestimmter Informationssysteme sind, ist die Umsetzung der Konzepte in der Praxis ohne IT-Unterstützung in der Regel nicht möglich. Dies liegt vor allem daran, dass CRM einen Umgang mit grossen Datenmengen erfordert, die normalerweise auf verschiedene Informationssysteme verteilt sind und manuell nicht mehr sinnvoll verwaltet werden können. Neben den oben genannten Zielen von CRM spielt also auch die Effizienzsteigerung in den CRM-Prozessen durch den Einsatz einer geeigneten IT-Lösung eine wesentliche Rolle [vgl. Emmert et al. 2000]. Die Aufgaben eines Informationssystems (IS) zur Unterstützung von CRM beschreibt [Mogicato 2000, S.11] folgendermassen: CRM wird ( ) als Front-end-System wahrgenommen, welches einerseits Verkaufsberater, Aussendienstmitarbeiter sowie interne Helpdesk- und Marketing-Mitarbeiter mit Informationen über die eigenen Produkte und Dienstleistungen, über Kunden und die Konkurrenz versorgt und andererseits den Input und das Feedback der Angestellten und Kunden verarbeitet.. Die typischen Funktionen eines CRM-Systems sind in [Schulze 2000, S.20] zusammengefasst. Kapitel 7 enthält eine ausführliche Beschreibung der informationssystemspezifischen Aspekte. 2.2 Internetportale Ein durch die dezentrale Organisation des Internets bedingtes Grundproblem ist das Auffinden benötigter Informationen. Um die Informationssuche zu unterstützen, sind zunächst Suchmaschinen wie Altavista und Verzeichnisse wie Yahoo! entstanden, die zum Ziel haben, einen möglichst grossen Teil aller Informationsangebote im Internet zu erfassen. Zur weiteren Erleichterung der Orientierung im Internet begannen Informationsanbieter wie Yahoo! und Netscape, Einstiegsseiten mit thematisch geordneten Listen ausgewählter Links von allgemeinem Interesse zu erstellen. Im Zusammenhang mit diesen Einstiegsseiten tauchte der Portalbegriff erstmals im Internetkontext auf [Kappe 2000, S.37]. In der Folge haben viele Informationsanbieter im Internet den Portalbegriff aufgegriffen und ihre eigenen Websites als Portale bezeichnet. Auch wenn z.b. [de Bakker/Seebacher 2000] das Portal definieren als Internetseite, die Nutzer als Startseite verwenden, von der aus sie sich im Internet bewegen oder die sie als wesentlichen Ankerpunkt benutzen, zu dem sie immer wieder zurückkehren, hat der Portalbegriff in

29 Grundlagen 15 der Praxis heute eine wesentlich breitere Bedeutung. [Pils 2000] definiert Internetportale über die folgenden charakteristischen Eigenschaften: Sie versuchen, den Anwender gezielt in seinem Bedürfnis nach Information zu unterstützen. Sie bieten verschiedene Funktionalitäten für bestimmte Zielgruppen, basierend auf Businessprozessen oder persönlichen Präferenzen. Sie bündeln die Kunden- und Anwenderinteressen, indem sie unterschiedliche Datenquellen an einem zentralen Ort zusammenziehen und hierdurch aggregierte Informationen bereitstellen. Sie bilden damit eine einheitliche Oberfläche für unterschiedliche Daten und Systemplattformen. Diese Definition beinhaltet zwei wesentliche Aspekte, die Internetportale charakterisieren und durch die sich Internetportale von anderen Websites abgrenzen lassen: Internetportale integrieren Leistungen aus verschiedenen Quellen. Die Auswahl und Aufbereitung der Leistungen erfolgt ausgerichtet auf die Bedürfnisse der Zielgruppe des Internetportals. Die Integration kann dabei auf verschiedenen Stufen erfolgen. Im einfachsten Fall stellt das Internetportal nur kategorisierte Linklisten zur Verfügung, auf der höchsten Stufe werden alle Leistungen in einer einheitlichen Oberfläche integriert, so dass es für den Benutzer nicht mehr direkt ersichtlich ist, aus welchen Quellen die einzelnen Inhalte stammen. Die Leistungen umfassen sowohl Informationen als auch beliebige Anwendungen wie z.b. Diskussionsforen, Auktionsplattformen, Bestellsysteme oder Abwicklungssysteme für Banktransaktionen. Bei den verschiedenen Quellen kann es sich um unterschiedliche Systeme im eigenen Unternehmen des Portalbetreibers handeln oder um verschiedene Anbieter, die Leistungen über das Portal anbieten [vgl. Hess/Herwig 1999]. Zur Kategorisierung der verschiedenen Portaltypen existieren in der Literatur unzählige Ansätze. Häufig werden die Zielgruppen der Portale und/oder die dem Portal zugrunde liegenden Geschäftsmodelle als Kriterien verwendet [s. z.b. Hoffmann/Wolf 2000; Pils 2000, S.15f.]. 2.3 Prozessportale Obwohl Kundenorientierung bereits seit Jahren propagiert wird und ein Leitsatz vieler Unternehmen ist, steht nach wie vor das angebotene Produkt meist im Mittelpunkt der Marketing- und Verkaufsaktivitäten. Die Kundenorientierung erschöpft sich in der Regel darin, den Kunden zuvorkommend und zügig zu bedienen und ihm auch nach dem Kauf bei Fragen und Problemen zur Verfügung zu stehen. Der Kunde hat jedoch

30 16 Grundlagen normalerweise ein weiter gehendes Bedürfnis. Er befindet sich mitten in einem Kundenprozess wie zum Beispiel dem Autobesitz oder dem Immobilienerwerb. Im Rahmen dieses Prozesses benötigt er eine Vielzahl von Produkten und Dienstleistungen, die er sich selbst zusammensucht. Dazu muss er in der Regel mehrere Anbieter von Produkten und Dienstleistungen kontaktieren, die Angebote evaluieren und die Koordination des Prozesses übernehmen. Es handelt sich häufig um Prozesse wie z.b. den Immobilienerwerb, die der Kunde vielleicht nur einmal im Leben durchläuft und mit denen er daher sicher wenig Erfahrung hat. Ein Anbieter, der den Kundenprozess vollständig unterstützt, also alle benötigten Leistungen aus einer Hand anbietet und den Kunden in seinem Prozess führt, schafft für ihn einen erheblichen Zusatznutzen [vgl. Kühn/Grandke 1997]. Ein möglicher Ausgangspunkt zur Identifikation von Kundenprozessen ist die Betrachtung von Life Events wie z.b. Heirat, Erwerbsaufnahme, Erwerb von Wohneigentum, Pensionierung, Erbschaft etc. [s. Fey et al. 2000]. Einige innovative Unternehmen sind bereits dazu übergegangen, den gesamten Kundenprozess zu unterstützen. Sie bieten dem Kunden aus einer Hand jedes Produkt, jede Dienstleistung und jede Information, die er braucht, und führen ihn in diesem Prozess. Sie werden zum Leistungsintegrator und Spezialisten für diesen Prozess. Dem Kunden bieten sie diese Leistungen in einem sogenannten Prozessportal an. In diesem Prozessportal fasst das Unternehmen alle Dienstleistungen und Informationen für einen bestimmten Kundenprozess zusammen. Dabei werden sowohl eigene Leistungen als auch solche von Kooperationspartnern gebündelt [vgl. Massfeller 1999; s. Österle 1999, S.45-51; vgl. Österle 2000a, S.28ff.; vgl. Österle 2000b; vgl. Schmid/Bach 2000b]. Die Ausrichtung auf die Kundenbedürfnisse kann weiter verbessert werden, indem die Leistungen den individuellen Bedürfnissen der einzelnen Kunden angepasst werden ( One-to-one-Marketing ). Dies ist erst durch den Einsatz von Internettechnologie wie z.b. personalisierten Homepages und automatischen -Benachrichtigungen mit wirtschaftlich vertretbarem Aufwand möglich geworden [vgl. Peppers/Rogers 1993; Peppers/Rogers 1999; Reichardt 2000]. Die konzeptionellen Grundlagen für Prozessportale bilden Internetportale, Leistungssysteme und Customer Relationship Management. Der beim Prozessportal benutzte Portalbegriff stammt aus dem Bereich der Internetportale (s. Abschnitt 2.2). Wie in einem Internetportal werden in einem Prozessportal Informationen und Leistungen aus verschiedenen Quellen integriert und dem Benutzer aus einer Hand zur Verfügung gestellt. Während ein Internetportal nichts anderes ist als eine Website mit bestimmten Eigenschaften, ist ein Prozessportal ein betriebswirtschaftliches Konzept, das durch den Einsatz eines Internetportals die Kundenprozessorientierung umsetzt. Die Leistungen eines Prozessportals werden nicht ausschliesslich über das Internet erbracht, je nach Eignung der Leistung kön-

31 Grundlagen 17 nen beliebige Vertriebskanäle zum Einsatz kommen. In der Regel wird jedoch ein Grossteil der Leistungen und Informationen vor allem aus Gründen der Wirtschaftlichkeit direkt über das Internet angeboten. Die zentrale Komponente eines Prozessportals ist daher immer eine Website. Diese dient dem Kunden, welcher die Leistungen des Prozessportals in Anspruch nehmen möchte, als Einstiegspunkt. Leistungen, die über andere Kanäle erbracht werden, sind dort zumindest dokumentiert. Meist werden auch individualisierte Leistungen über diese Website angeboten. Betriebswirtschaftlich gesehen liegt einem Prozessportal ein kooperatives Leistungssystem zugrunde. Leistungssysteme lösen die Probleme für ausgewählte Kunden umfassend und wirtschaftlich [Belz 1997, S.12]. Dazu werden bisher isolierte Einzelleistungen zu integrierten Lösungen kombiniert, die auf die Bedürfnisse des Kunden ausgerichtet sind. Im Prozessportal wird dieses Kundenbedürfnis über den Kundenprozess definiert [vgl. Belz 1997, S.27]. Meist kann ein Unternehmen nicht alle Einzelleistungen selbst erstellen, die für eine integrierte Problemlösung erforderlich sind. Für die Gestaltung von Leistungssystemen werden daher häufig Kooperationen mit externen Partnern eingegangen [s. Schögel et al. 1999]. Eine wesentliche Leistung des Betreibers eines Prozessportals ist es daher, die eigenen Produkte und Leistungen und diejenigen der Kooperationspartner zu integrieren. Prozessportal CRM- Prozesse Kundenprozess Lieferant Lieferant Drittanbieter Marketing Verkauf News Produktinformation Beratung Verkaufsabwicklung Auktionen Informieren Evaluieren Kaufen Drittanbieter Drittanbieter Service Support Reparaturservice Supply Chain Service Nutzen Verkaufen Personalisierung Abb. 2-1: Die CRM-Prozesse stellen die Leistungen eines Prozessportals bereit Im Customer Relationship Management werden sämtliche Kundenkontakte einem der CRM-Prozesse Marketing, Verkauf oder Service zugeordnet. Diese Prozesse richten sich am Kundenprozess oder im allgemeineren Fall am Customer Buying Cycle aus (s. Abschnitt 2.1.2). Besteht die Kundenschnittstelle aus einem Prozess-

32 18 Grundlagen portal, sind demnach die CRM-Prozesse dafür verantwortlich, für den Kunden die im Prozessportal angebotenen Leistungen zu erbringen (s. Abb. 2-1). 2.4 Geschäftsmodell des Informationszeitalters Prozessportale spielen eine zentrale Rolle in einem neuen Geschäftsmodell des Informationszeitalters [s. Österle 1999]. Dieses Modell wurde am Institut für Wirtschaftsinformatik der Universität St. Gallen entwickelt und beschreibt mögliche wirtschaftliche Strukturen, die sich in Zukunft aufgrund aktueller Trends in Technik, Gesellschaft und Politik ergeben können. Im Rahmen dieses Geschäftsmodells (s. Abb. 2-2) bilden sich verschiedene neue Rollen heraus. Das Prozessportal bildet die Schnittstelle zum Kunden. Der Prozessportalbetreiber bezieht die benötigten Produkte und Dienstleistungen von verschiedenen Lieferanten und Drittanbietern, mit denen er Kooperationen eingeht. Diese sind darauf spezialisiert, konkurrenzfähige Produkte zu erstellen und über Prozessportale zu vertreiben. Ist der Prozessportal-Betreiber selbst Ersteller von Produkten und Dienstleistungen, kombiniert er die eigenen Leistungen mit denen der externen Partner und vertreibt die Gesamtleistung über sein Prozessportal. Unternehmensentwicklung und -führung Anbieter Anbieter Beschaffung Personal & Wissensentw. Anbieter Produktion Marketing & Verkauf Portal Kundenprozess Verteilung Innovation & Entwicklung Anbieter Unterstützungsprozesse Personal Finanz Anlage IS/IT Business Bus eservices Business Support Information Networking Abb. 2-2: Geschäftsmodell des Informationszeitalters [Österle 2000a, S.39] Weitere, meist hoch standardisierte Dienstleistungen bezieht der Prozessportalbetreiber von sogenannten e-service-providern. Dies ist beispielsweise die Transakti-

33 Grundlagen 19 onsabwicklung im Zahlungsverkehr, die Durchführung von Logistikleistungen oder die Bereitstellung von herstellerübergreifenden Produktkatalogen. E-Service-Anbieter sind darauf spezialisiert, diese Leistungen kosteneffizient und in großem Volumen zu erbringen. Die Kommunikation zwischen den einzelnen Partnern in dem neuen Wertschöpfungsnetzwerk erfolgt über den sogenannten Business Bus. Dieser umfasst Protokolle und Schnittstellen, die auf semantischer Ebene standardisiert sind. Die Existenz eines Business Bus als standardisierte Kommunikationsmöglichkeit erlaubt den einfachen Aufbau von Kooperationsnetzwerken und die einfache Einbindung neuer Partner. Vom einem geschäftlichen Standpunkt aus betrachtet sind die zahlreichen IT- Entwicklungen für sieben fundamentale Trends der Geschäftstransformation verantwortlich (s. Abb. 2-3) [s. Österle 1999]: Das Enterprise Resource Planning, also die operative Abwicklung des Geschäfts, läuft im Hintergrund. Integrierte Applikationen für die Administration sowie für die Produktentwicklung und Technik erlauben eine Konzentration auf das Geschäft anstatt auf die Administration. Customer Process Support Elektronische Dienste Geschäftsvernetzung Wissensmanagement Enterprise Resource Planning Wertemanagement Intelligente Geräte Abb. 2-3: Sieben Trends auf dem Weg zum Unternehmen des Informationszeitalters [Österle 1999] Wissensmanagement versorgt jede Aufgabe innerhalb eines Prozesses mit dem nötigen Wissen über Kunden, Konkurrenten, Produkte usw., vor allem auch über den Prozess selbst. Intelligente Geräte bringen die Informationsverarbeitung an den Ort des Geschehens. Die Verkehrsinformation kommt über das Navigationssystem (GPS) zum Fahrer, die Point-of-Sales-Information aus der Ladenkasse zum Produkthersteller und die Maschinenstörungen von den Sensoren zum Servicemitarbeiter. Geschäftsvernetzung macht die Zusammenarbeit zwischen zwei Unternehmen so einfach, als ob es sich um ein einziges Unternehmen handelte. So steht die Information über einen Verkauf des Endproduktes ohne Verzögerung allen Unternehmen dieser Supply Chain zur Verfügung.

34 20 Grundlagen Viele Teilprozesse, die heute jedes Unternehmen individuell betreibt, werden als elektronische Dienste vom Netz bezogen oder dort angeboten. Ein Beispiel könnte Kundenprofiling sein. Zusätzlich zum Lieferanten kann ein Online- Datenbankanbieter als Dritter sowie der Kunde selbst die Verantwortung für sein Profil übernehmen und es über einen elektronischen Dienst anbieten. Unternehmen verkaufen nicht einzelne Produkte oder Dienstleistungen, sondern unterstützen ganze Kundenprozesse. Transportunternehmen übernehmen den Logistikprozess, Ärzte unterstützen den gesamten Therapieprozess, und Versicherungen betreuen an Stelle des Kunden den Prozess der Schadensabwicklung. Die Unternehmensführung orientiert sich nicht nur an den finanziellen Ergebnissen, sondern an den Faktoren, welche zu diesen Ergebnissen führen. Aus dem finanziellen Management wird ein Wertemanagement, das die Schlüsselfaktoren für den Unternehmenserfolg im Auge behält. 2.5 Entwicklungen in der Bankenbranche Die Finanzbranche im Wandel Die Finanzbranche befindet sich in einem radikalen Wandel. Seit über 20 Jahren ist ein kontinuierlicher Rückgang der Marktanteile von Banken im Vermögensverwaltungsgeschäft zu beobachten. Während 1976 noch 25% des Gesamtvermögens amerikanischer Haushalte den Banken anvertraut wurden, waren es 1997 nur noch 12%. Im gleichen Zeitraum konnten Vermögensverwalter ihren Anteil von 37% auf 67% erhöhen (vgl. Abb. 2-4). Vermögensverwalter, welche die Kundenbeziehung in den Vordergrund stellen, anstatt wie die meisten Banken in erster Linie eigene Finanzprodukte zu verkaufen, verzeichneten einen signifikanten Zuwachs an Umsatz und Gewinn [Ernst & Young 1998, S.1]. Branchenfremde Unternehmen und Nischenanbieter dringen in klassische Geschäftsfelder von Banken vor. Versicherungen bieten beispielsweise immer mehr Investmentfonds und andere Anlageprodukte zur Altersvorsorge an. Direktbanken und Discount Broker spezialisieren sich auf moderne elektronische Vertriebskanäle (Internet, Telefon) und haben so deutliche Kostenvorteile gegenüber etablierten Banken mit grossen Filialnetzen. Softwarehäuser wie Microsoft oder Intuit haben populäre Home- Banking-Software entwickelt und sich so den Einstieg in das Geschäft mit Finanzdienstleistungen geebnet. Kreditkartenunternehmen wie American Express verkaufen ihre Finanzprodukte gekoppelt mit umfangreichen Servicepaketen direkt an die Endkunden. Und nicht zuletzt gründen Unternehmen ganz anderer Branchen spezialisierte Banken, so zum Beispiel die BMW Bank zur Vergabe von Krediten an Autokäufer.

35 Grundlagen 21 80% 70% 60% 50% 40% 37% 37% 41% 47% 49% 52% 59% 64% 66% 67% 30% 20% 25% 25% 23% 23% 22% 20% 17% 14% 13% 12% 10% 0% Banken Vermögensverwalter Abb. 2-4: Verteilung der Vermögenswerte der US-Haushalte [Ernst & Young 1998] [Lehmann 2000] sieht die Ursachen für diesen Wandel in rechtlichen Deregulierungsund Liberalisierungsschritten, Veränderungen im Kundenverhalten, strukturellen Verschiebungen in der Geld- und Vermögensbildung privater Haushalte, im Zusammenrücken der Finanz- und Risikomärkte, in technologischen Innovationen und in anhaltenden Internationalisierungs- und Globalisierungstendenzen. Als eigentlichen Schlüsselfaktor für die funktionellen und strukturellen Veränderungen im Bankwesen sieht [Bernet 1997] die Technologie. Abb. 2-5 illustriert die Zusammenhänge: Die Technologie erlaubt den Vertrieb von Bankprodukten über neue, kostengünstigere Vertriebskanäle. Dies ermöglicht einerseits wirtschaftlichere Prozesse und Strukturen, verlangt aber andererseits Produktspezifikationen, die einen Vertrieb mit wenig menschlicher Interaktion erlauben. Die Eintrittsbarrieren in das Finanzgeschäft sinken, da die Abhängigkeit von der physischen Präsenz abnimmt. Neue Anbieter mit günstigeren Kostenstrukturen bringen preisgünstigere Produkte auf den Markt. Es entsteht ein Konkurrenzkampf, der zu sinkenden Preisen und trotz ebenfalls rückläufiger Transaktionskosten zu sinkenden Margen führt.

36 22 Grundlagen Die moderne Technologie neue Produktspezifikationen verlangt entwickeln ermöglichen alternative Distribution ermöglicht reduziert Eintrittsbarrieren für neue Anbieter haben ermöglicht wirtschaft. Prozesse und Strukturen haben in Produktion und Verkauf tiefere Kosten/ tiefere Preise führen zu Revolution im Bankwesen führen zur Abb. 2-5: Bedeutung der Technologie für Veränderungen im Bankwesen [Bernet 1997, S.337] Entstehung eines Wertschöpfungsnetzwerkes In der Wertschöpfungskette klassischer Banken werden dem Kunden Produkte verkauft, welche die eigene Bank erstellt und für die auch die Transaktionsabwicklung im eigenen Haus stattfindet. Ernst & Young beschreibt in einer Studie [Ernst & Young 1997] die Aufspaltung dieser Wertschöpfungskette und die Entwicklung von drei spezialisierten Rollen, die in einem wechselseitigen Geschäftsverhältnis stehen und so ein Wertschöpfungsnetzwerk bilden. Gemäss Ernst & Young wird es neu die Rollen des Relationship Managers, des Product Providers und des Transaction Processors geben. Die Kernkompetenz des Relationship Managers ist die Beziehung zum Kunden. Er ist für die Beratung und Zufriedenstellung des Kunden verantwortlich, bezieht die Produkte dafür aber über das Netzwerk von verschiedenen Product Providern. Dabei ist er nicht mehr an die Produkte einer bestimmten Bank gebunden. Der Product Provider bietet verschiedene Finanzprodukte an und verschafft sich einen Wettbewerbsvorteil durch die Kreation neuer, innovativer Produkte. Die eigentliche Abwicklung wird dem Transaction Processor überlassen, der sich auf eine kosteneffiziente Durchführung der erforderlichen Transaktionen spezialisiert.

37 Grundlagen 23 Tendenz 2: Desintegration auf der Angebotsseite Tendenz 1: Integration auf der Kundenseite Zulieferer (intern, extern) Zulieferer (intern, extern) Zulieferer (intern, extern) Unbundling und Rebundling Finanzdienstleister Kunde Kunde Kunde Gezieltes Servicemanagement Abb. 2-6: Tendenzen in den Wertschöpfungsprozessen von Finanzdienstleistern [Lehmann 2000, S.27] Dieselbe Entwicklung beschreibt [Lehmann 2000, S.26] in Form von zwei Trends: die Integration auf der Kundenseite und die Desintegration auf der Angebotsseite (s. Abb. 2-6). Die Integration auf der Kundenseite bedeutet, dass der Kunde immer mehr Leistungen aus einer Hand bezieht. Der Erbringer dieser Leistungen wird jedoch immer seltener in der Lage sein, alle Leistungen selbst zu erstellen; es entsteht daher eine Kooperation verschiedener Anbieter, welche gemeinsam die benötigten Leistungen erbringen (Desintegration). Die Tendenz zur Integration auf Kundenseite resultiert in einem gezielten Servicemanagement, das die Aufrechterhaltung einer langfristigen Kundenbeziehung in den Vordergrund stellt. Die Tendenz zur Desintegration auf der Angebotsseite führt zu vertikal desintegrierten Unternehmensformen. Demnach werden Finanzdienstleister vielfach Leistungselemente anderer Anbieter zukaufen und zu einem Leistungspaket für den Kunden zusammensetzen Rollen im Wertschöpfungsnetzwerk und Begriffe Diese strukturellen Veränderungen in der Bankenbranche weisen auffällige Parallelen zu dem in Abschnitt 2.4 beschriebenen Geschäftsmodell des Informationszeitalters auf. Die bei Ernst & Young genannten Product Provider entsprechen den Drittanbietern und Lieferanten im Geschäftsmodell des Informationszeitalters, die Transaction Processors sind mit den e-services gleichzusetzen. Beide Rollen sind das Ergebnis der bei Lehmann genannten Desintegration auf der Angebotsseite. An der Kundenschnittstelle beschreibt Lehmann den Trend zu langfristiger Kundenbindung und die Erstellung bedürfnisgerechter Leistungspakete. Ernst & Young definiert den Relationship Manager etwas genauer:

38 24 Grundlagen Relationship managers are the customer service giants that own the customers, know everything about them, manage that knowledge as an asset, and are able to meet the full complement of financial needs. [Ernst & Young 1997, S.12] Alle bei Lehmann und bei Ernst & Young beschriebenen Eigenschaften der Kundenschnittstelle tauchen auch im Geschäftsmodell des Informationszeitalters auf. Die Kundenschnittstelle bildet dort das Prozessportal, das die Ausrichtung auf die Kundenbedürfnisse noch mehr in den Vordergrund stellt, indem es sich direkt am Kundenprozess orientiert. Für die vorliegende Arbeit dient das in Abschnitt 2.4 beschriebene Geschäftsmodell des Informationszeitalters und die dort verwendete Terminologie als Grundlage.

39 Erfolgsfaktoren für Prozessportale 25 3 Erfolgsfaktoren für Prozessportale In den letzten Jahren sind unzählige Internetportale im Business-to-Consumer-Bereich entstanden. Viele davon können gemäss Kapitel 2.3 als Prozessportale bezeichnet werden, z.b. oder Es stellt sich nun die Frage, wie sich die verschiedenen Portale voneinander unterscheiden und welche Kriterien Prozessportale erfüllen müssen, um gute Erfolgsaussichten zu haben. 3.1 Kriterien Das Ziel der meisten kommerziellen Portale ist ein möglichst hoher Ertrag. Je nach Geschäftsmodell, welches dem Portal zugrunde liegt, werden die Einnahmen aus unterschiedlichen Quellen erzielt, z.b. durch Werbeeinnahmen, durch Beiträge von Kooperationspartnern, die in das Portal eingebunden sind, und durch den Verkauf kostenpflichtiger Leistungen an die Portalnutzer. Alle diese Einnahmen sind abhängig von der Anzahl der Portalbenutzer: Je mehr Nutzer ein Portal hat, desto attraktiver ist es für Firmen, Werbung in diesem Portal zu machen oder eigene Leistungen über das Portal abzusetzen und desto höher ist auch die Anzahl potenzieller Kunden, die kostenpflichtige Leistungen in Anspruch nehmen. Als Messgrösse für den Erfolg eines Portals kann demnach der Traffic herangezogen werden, der Informationen über Nutzerzahl, Nutzungsdauer, Nutzungshäufigkeit etc. gibt [Hartmann 2000, S.10; vgl. Kuß/Tomczak 2000, S.161ff.]. In Einklang mit den in Kapitel 2.1 dargestellten Zielen von Customer Relationship Management gilt also auch für Portale das Ziel, möglichst viele möglichst profitable Kunden zu gewinnen und diese möglichst lange zu binden. Werbemassnahmen Person mit Kundenbedürfnis Kosten-/Zeitersparnis Zusatznutzen Kundennutzen Portalbesucher Kundenvertrauen Portalkunde Portalprofitabilität Kundenzufriedenheit Regelmässiger Portalkunde Abb. 3-1: Kundenanforderungen und Portalprofitabilität Die Kundengewinnung erfolgt i.d.r durch gezielte Werbemassnahmen wie z.b. die Platzierung von Werbebannern und Links auf anderen populären Websites, Eintragun-

40 26 Erfolgsfaktoren für Prozessportale gen in Suchmaschinen und Verzeichnisse oder Werbung in klassischen Medien wie Zeitung, Fernsehen, Radio, Plakaten etc. [vgl. Bellizzi 2000]. Besucht eine Person das Portal erstmals, erhöht sie den Traffic des Portals und kann damit z.b. über Werbeeinnahmen bereits zum Portalerfolg beitragen. Geht man von Portalen aus, die nicht rein werbefinanziert sind, sondern den Nutzern kostenpflichtige Leistungen anbieten, so hat das Portal nun zwei Aufgaben: Erstens soll der Besucher vom Nutzen der angebotenen Leistungen überzeugt werden, Vertrauen in das Portal gewinnen und so zum Kunden werden und zweitens sollen die Leistungen den Kunden zufrieden stellen. Dadurch kann möglicherweise ein freiwilliges Commitment des Kunden erreicht werden, dass er auch zukünftige Bedürfnisse über dieses Portal befriedigen wird [vgl. Dittrich 2000, S.74ff.]. Abb. 3-1 illustriert diese Zusammenhänge [vgl. Ennew/McKechnie 1998, S.187ff.; vgl. Gabbott/Hogg 1998, S.15]. Das Kundenverhalten in Bezug auf Kundenbindung wird im Wesentlichen durch die drei genannten Grössen Vertrauen, Zufriedenheit und Commitment beeinflusst. Im allgemeinen Fall werden diese Grössen neben dem Nutzen noch durch weitere Faktoren bestimmt, z.b. spielen direkte Wechselkosten oder vertragliche Bindungen eine Rolle. Für eine detaillierte Darstellung der komplexen Zusammenhänge sei auf [Dittrich 2000, S.56ff.] verwiesen. Die weiteren Betrachtungen konzentrieren sich auf den Nutzenaspekt als Einflussfaktor. Den Ausgangspunkt bilden die Kundenanforderungen, welche den Nutzen des Kunden durch das Portal, das Vertrauen des Kunden in das Portal und die Zufriedenheit des Kunden mit den Portalleistungen beeinflussen. Aus den Kundenanforderungen werden Massnahmen abgeleitet, die der Portalbetreiber berücksichtigen sollte, um die Anforderungen möglichst gut zu erfüllen. Die Anforderungen und Massnahmen wurden aus verschiedenen Beispielen sowie aus der Literatur abgeleitet. Die einzelnen Beispiele dienen im Folgenden zur Illustration der Kriterien, die Literaturquellen sind bei den Kriterienbeschreibungen referenziert. Ein wesentlicher Nutzenaspekt ist die Kosten- oder Zeitersparnis, welche der Kunde durch die Nutzung des Portals hat. Die Kundenanforderungen werden daher im Folgenden den vier Bereichen Kosten-/Zeitersparnis, Zusatznutzen, Vertrauen und Zufriedenheit zugeordnet. Die folgende Tabelle gibt einen Überblick über die Anforderungen und die zugehörigen Massnahmen des Portalbetreibers. Die einzelnen Punkte werden anschliessend detailliert erläutert. Die verschiedenen Massnahmen haben Auswirkungen auf unterschiedlichen Architekturebenen. Auf strategische Konsequenzen wird in Kapitel 5 eingegangen, Auswirkungen auf Prozessebene werden in den Kapiteln und 6.5 behandelt, und Einflüsse auf die IS-Architektur sind in Kapitel 7.2 beschrieben.

41 Erfolgsfaktoren für Prozessportale 27 Anforderung des Kunden Kosten-/Zeitersparnis Prozessunterstützung Vollständigkeit Konkurrenzfähigkeit Neutralität Vollständige Abwicklung Einheitliche Bedienung Zusatznutzen Orts- und Zeitunabhängigkeit Freie Wahl des Zugangsmediums Individuelle Behandlung Zusatzleistungen Vertrauen Rechtsklarheit Risikominimierung Datenschutz Vertrauenswürdige Partner Zufriedenheit Qualität Zuverlässigkeit und Geschwindigkeit Transparenz Datensicherheit Massnahme des Portalbetreibers Abnahme von Aufgaben Kundenprozessorientierung Kritische Masse der Anbieter Informationsfülle Attraktive Konditionen Ausgleich von Nachteilen Einbezug von Konkurrenzanbietern Integration aller Geschäftsvorgänge Volle Integration der Partnerleistungen Benutzerfreundliche Portaloberfläche Trennung von Inhalt und Layout 24h Verfügbarkeit Weltweite Logistikleistungen Umfassende Unterstützung von Zugangsmedien Volle Kanalintegration Personalisierung und Kundenprofile Bereitstellung von Wissen und Kommunikationsmöglichkeiten Klare Geschäftsbedingungen Kundenfreundliche Rücktrittsrechte Datenschutzgarantien Bekannte Namen einsetzen Sorgfältige Partnerauswahl Verpflichtende Partnereinbindung Kritische Masse der Kunden Prozess- und Systemintegration Auftragsverfolgung Hoher Sicherheitsstandard Tabelle 3-1: Kundenanforderungen und Massnahmen des Portalbetreibers

42 28 Erfolgsfaktoren für Prozessportale Kosten- und Zeitersparnis Eine Reduktion der zur Lösung eines Kundenproblems erforderlichen Kosten oder des notwendigen Zeitaufwandes stellt für die Kunden meist einen wesentlichen Nutzenfaktor dar. Die folgenden Anforderungen und Massnahmen sind dabei relevant: Prozessunterstützung Der Kunde möchte in seinem Prozess geführt werden. Ihm reicht eine Sammlung von Einzelleistungen zu einem bestimmten Thema nicht, sondern er möchte angeleitet werden, wie er den Prozess am besten gestaltet, welche Leistungen er von welchen Partnern zu welchem Zeitpunkt beziehen muss, um sein persönliches Bedürfnis bestmöglich zu befriedigen. Er spart so den zeitlichen Aufwand, sich selbst in die Thematik detailliert einzuarbeiten. Abnahme von Aufgaben Der Portalbetreiber muss dem Kunden die Prozessführung und möglichst viele Aufgaben abnehmen. Denkbar wäre z.b. eine Lösung, die dem Kunden gezielt Fragen stellt und ihn so zu einer auf ihn abgestimmten Lösung führt. Beispiel: Die deutsche Direkt Anlage Bank ( bietet auf ihrer Website einen Zukunfts-Planer (s. Abb. 3-2), der den Kunden z.b. durch den Prozess der Vorsorgeplanung führt. Schrittweise werden die erforderlichen Angaben zu Einkommens- und Vermögenssituation erfragt, am Ende erhält der Kunde einen konkreten Vorschlag für einen persönlichen Vorsorgeplan. Abb. 3-2: Der Zukunfts-Planer der Direkt Anlage Bank führt den Kunden durch den Vorsorgeplanungsprozess. Vollständigkeit Der Kunde erwartet, dass er sein konkretes Bedürfnis vollständig über das Portal

43 Erfolgsfaktoren für Prozessportale 29 befriedigen kann. Diese Anforderung wird auch mit dem Stichwort Everything bezeichnet [Österle 2000a, S.26]. Er möchte dabei nur mit dem Portalbetreiber eine Geschäftsbeziehung unterhalten, gleichzeitig aber Zugang zu den Leistungen möglichst vieler Anbieter haben. Dadurch spart er den Aufwand, zu jedem einzelnen Anbieter Beziehungen aufzubauen und zu unterhalten. Kundenprozessorientierung Um der Vollständigkeit möglichst nahe zu kommen, muss sich der Portalbetreiber am Kundenprozess orientieren. Er baut ein umfassendes Prozesswissen auf und beherrscht den Prozess besser als der Kunde selbst. Im Sinne des Customer Resource Life Cycle [s. Ives/Learmonth 1984] versucht er, das Kundenproblem zu lösen und dafür möglicht viele Produkte, Dienstleistungen und Informationen zu verbinden. Des Weiteren sollten die Kundeninteressen in den Vordergrund gestellt werden (Affiliation). So haben z.b. Amazon-Kunden nicht lange akzeptiert, dass Verlage Amazon für gute Platzierungen ihrer Bücher bezahlten [Evans/Wurster 2000, S.87ff.]. Beispiel: Die amerikanische Website autobytel.com unterstützt den Autobesitz vom Kauf (Modellwahl, Gebrauchtwagensuche, Finanzierung) über Besitz (Versicherung, Wartung) bis zum Verkauf (s. Abb. 3-3) und deckt so den Kundenprozess möglichst vollständig ab. Abb. 3-3: autobytel.com deckt den vollständigen Kundenprozess Autobesitz ab. Informationsfülle Die angebotenen Informationen, z.b. über angebotene Produkte und Dienstleistungen, müssen möglichst umfassend und detailliert sein [Evans/Wurster 2000, S.89ff.]. Hier sind Hersteller und herkömmliche Händler gegenüber neuen E-Business-Unternehmen als Portalbetreiber im Vorteil, da sie leichten Zu-

44 30 Erfolgsfaktoren für Prozessportale gang zu Produkt- und Kundeninformationen haben. Ein Kunde wird z.b. eher einen Autovergleich benutzen, bei dem er sämtliche technische Daten vergleichen kann, als einen, bei dem ihm nur Modellbezeichnung und Preis als Kriterien zur Verfügung stehen. Kritische Masse der Anbieter Der Anbieter muss die Lieferanten der benötigten Leistungen überzeugen, ihre Leistungen über ihn auf dem Markt anzubieten. Der Kunde wird mit dem Leistungsintegrator zusammenarbeiten, zu dem er das grösste Vertrauen hat und der ihm den Zugang zu den meisten Lieferanten bietet [s. Hagel/Singer 1999, S. 169ff]. Konkurrenzfähigkeit Der Kunde bezieht Leistungen nur zu konkurrenzfähigen Konditionen. Konkurrenten sind nicht nur andere Portale, sondern auch herkömmliche Anbieter wie z.b. der lokale Einzelhandel oder die Bankfiliale. Attraktive Konditionen Gleiche Leistungen dürfen nicht teurer sein als bei der Konkurrenz. Um einen Wettbewerbsvorteil zu schaffen, sollten sie entweder günstiger sein oder andere Vorteile wie z.b. ein grosszügiges Rückgaberecht bieten. Beispiel: Amazon.de bietet Bücher zum selben Preis wie im Buchladen an, der Versand zum Besteller erfolgt gratis. Der Kunde bekommt die Bücher also zu denselben Konditionen wie im herkömmlichen Buchladen. Zusätzlich hat er den Vorteil, die Bücher nach Hause geliefert zu bekommen. Ausserdem kann er die Bücher innerhalb einer bestimmten Frist ohne Begründung zurückgeben und erhält den Kaufpreis erstattet. Diese Regelung ist ein zusätzlicher Vorteil für den Kunden und gleicht gleichzeitig den Nachteil aus (vgl. unten), dass er das Buch vor dem Kauf nicht begutachten kann. Ausgleich von Nachteilen Dem Kunden entstehen häufig Nachteile, wenn er Leistungen über ein Portal im Internet bezieht. Dazu gehören z.b. Lieferzeiten, Lieferkosten, die fehlende Möglichkeit, die Ware vor dem Kauf zu begutachten oder die fehlende persönliche Beratung. Diese Nachteile muss der Anbieter ausgleichen, z.b. durch Übernahme von Lieferkosten, Rückgaberechte oder durch die Möglichkeit einer telefonischen Beratung. Vorteile des Portals müssen gleichzeitig deutlich kommuniziert werden. Beispiel: Ein Nachteil beim Onlinekauf von Kleidern ist die fehlende Möglichkeit, die Kleider anzuprobieren. Der deutsche Otto-Versand ( bietet die Möglichkeit, die Kleider aus dem Katalog online anzuprobieren (s. Abb. 3-4). Dazu kann man auch ein Foto von sich selbst auf dem Server ablegen und so die Kleider am eigenen Körper sehen.

45 Erfolgsfaktoren für Prozessportale 31 Abb. 3-4: Der Otto-Versand gleicht Nachteile durch die Online-Anprobe aus. Neutralität Vielfach erwartet der Kunde die Neutralität des Portalbetreibers gegenüber den Leistungserbringern. Diese Neutralität erlaubt zum Beispiel einen umfassenden und objektiven Vergleich der Leistungen verschiedener Anbieter. Der Kunde spart Zeit, da er den Vergleich sonst selbst durchführen müsste, oder Kosten, da er ohne Vergleich wahrscheinlich nicht den günstigsten Anbieter finden würde. Einbezug von Konkurrenzanbietern Der Portalbetreiber sollte konkurrierende Anbieter in das Portal einbeziehen und einen Vergleich ermöglichen. Dies stellt in der Regel kein Problem in Bereichen dar, in denen der Portalbetreiber keine eigenen Leistungen erbringt. Unter Umständen kann aber auch der Einbezug eines Vergleichs von eigenen Leistungen mit den Konkurrenzleistungen oder das Angebot von Konkurrenzleistungen im eigenen Portal eine Erfolg versprechende Strategie darstellen. Eine Möglichkeit ist auch ein Joint Venture mit direkten Konkurrenten [Evans/Wurster 2000, S.84f.]. Beschränkt sich der Portalbetreiber auf ein Angebot der eigenen Leistungen, so läuft er Gefahr, die Portalnutzer an einen neutralen Portalbetreiber zu verlieren, da dieser ihm durch die Neutralität einen zusätzlichen Nutzen bieten kann. Beispiel: Der neutrale Portalbetreiber comparis.ch bietet einen Vergleich verschiedener Versicherungs- und Bankkonditionen (s. Abb. 3-5). Durch die Neutralität erhält der Kunde hier einen fast vollständigen Marktüberblick. Ein weiteres Beispiel ist GetMusic.com, ein Joint Venture von Universal und BMG, zwei der weltweit grössten Musikfirmen. GetMusic.com bietet eine voll-

46 32 Erfolgsfaktoren für Prozessportale ständige Auswahl von Musikalben an, die sowohl aus der eigenen Produktion wie aus der anderer Firmen stammen [Evans/Wurster 2000, S.86]. Abb. 3-5: Comparis.ch bietet einen neutralen Krankenversicherungs-Vergleich. Vollständige Abwicklung Diese auch als One-stop bezeichnete Forderung bedeutet, dass der Kunde das gesamte Geschäft in einem einzigen Vorgang erledigen kann [Österle 2000a, S.26]. Er muss abgesehen von einem physischen Warentransport nie auf die Leistungen warten. Der Kundenprozess wird so durch die Leistungserbringer nicht unterbrochen. Integration aller Geschäftsvorgänge Der Portalbetreiber muss alle notwendigen Geschäftsvorgänge in sein Portal integrieren [vgl. Fellenstein/Wood 2000, S.33ff.]. Insbesondere dürfen keine Verträge o.ä. mehr auf Papier abgeschlossen werden, da dies durch den Postweg zu unnötigen Verzögerungen führt und zu einem Medienbruch, der die automatische Verarbeitung erschwert. Die rechtlichen Grundlagen für eine Abwicklung sämtlicher Geschäftsvorgänge über Internet werden derzeit in den meisten Industrieländern geschaffen. Dazu gehören vor allem eine Gesetzgebung zur Anerkennung digitaler Unterschriften sowie die dafür notwendige Infrastruktur. Beispiel: Die Webinsurance ( der Winterthur Versicherungen erlaubt es, den Abschluss verschiedener Versicherungen vollständig online vorzunehmen (s. Abb. 3-6). Nach erfolgtem Abschluss kann man sich eine (vorläufige) Police selbst ausdrucken. Nach geltendem Recht kommt zwar kein rechtsgültiger Vertrag zustande, das Risiko des Zahlungsausfalls trägt die Winterthur.

47 Erfolgsfaktoren für Prozessportale 33 Abb. 3-6: Die Webinsurance der Winterthur ermöglicht den Online-Abschluss von Versicherungen. Einheitliche Bedienung Eine einheitliche und intuitive Bedienung des gesamten Portals erleichtert es dem Kunden, sich zurechtzufinden. Die Einheitlichkeit sollte über alle Portalinhalte hinweg gegeben sein, unabhängig davon, welcher Partner die Inhalte bereitstellt. Erfordert die Bedienung erst eine langwierige Einarbeitung oder Gewöhnung, so können Zeitersparnisse aus anderen Vorteilen hier wieder verloren gehen. Volle Integration der Partnerleistungen Die Portalpartner sollen soweit integriert sein, dass dem Kunden das Portal als einheitlicher Anbieter erscheint. Dies bezieht sich auf verschiedene Aspekte wie Darstellung der Inhalte, Auftrags- und Zahlungsmöglichkeiten, Abwicklung und Kontaktmöglichkeiten über andere Vertriebskanäle. Beispiel: Das amerikanische Hochzeitsportal theknot.com (s. Abb. 3-7) unterstützt den Prozess der Hochzeitsvorbereitung. Die Leistungen werden von verschiedenen Anbietern erbracht (Online-Shops für Geschenke und Kleidung, Online-Reiseanbieter, Online-Betreiber von Diskussionsforen und persönlichen Hochzeitswebsites etc.). In der Regel merkt der Benutzer dies nicht, da alle Anbieter nahtlos in eine einheitliche Portaloberfläche integriert sind.

48 34 Erfolgsfaktoren für Prozessportale Abb. 3-7: The Knot integriert die Leistungen vieler Anbieter in einer einheitlichen Oberfläche. Benutzerfreundliche Portaloberfläche Die Gestaltung der Portaloberfläche sollte modernen Kriterien der Ergonomie genügen. Das Portal sollte vor allem übersichtlich, gut strukturiert, nicht überladen und einfach zu bedienen sein. Hinweise zur Oberflächengestaltung geben sogenannte Style Guides [s. z.b. Lynch/Horton 1999]. Wichtig ist auch eine gute Performance mit kurzen Antwortzeiten. Trennung von Inhalt und Layout Erreicht werden kann eine einheitliche Oberfläche über alle Partner hinweg am einfachsten durch eine Trennung von Inhalt und Layout. Voraussetzung dafür ist, dass alle Partner die reinen Portalinhalte in strukturierter Form bereitstellen. Dies ist oft schwierig zu erreichen, da viele Anbieter die Kontrolle über die Darstellung der Inhalte behalten wollen. Die Integration von Inhalten verschiedener Anbieter in einer Website bezeichnet man als Content Syndication [s. whatis?com 2000, Stichwort Syndication]. Zur Standardisierung und Automatisierung von Content Syndication sind in letzter Zeit verschiedene Dokumentstandards und Protokolle entwickelt worden, die einen einfachen, layoutunabhängigen Austausch von Inhalten ermöglichen, z.b. das standardisierte Information and Content Exchange Protocol (ICE) [vgl. Greening 1999; ICE

49 Erfolgsfaktoren für Prozessportale 35 Authoring Group 2000]. Anbieter wie z.b. isyndicate ( haben sich darauf spezialisiert, strukturierte Inhalte anzubieten und stellen auch die Technologie zur Content Syndication zur Verfügung Zusatznutzen Weitere Merkmale tragen nicht oder nur indirekt zu Kosten- oder Zeitreduktion bei, stiften für Kunden aber einen klaren Zusatznutzen: Orts- und Zeitunabhängigkeit Der Kunde möchte die Leistungen des Prozessportals jederzeit und an jedem Ort der Welt in Anspruch nehmen können ( Non-stop und Everywhere [Österle 2000a], S.26). 24h Verfügbarkeit Die Portalleistungen müssen 24 Stunden am Tag, an allen Tagen im Jahr verfügbar sein. Die Verfügbarkeit muss durch entsprechend redundant ausgelegte Systeme sichergestellt sein. Weltweite Logistikleistungen Während die Erbringung elektronischer Leistungen ortsunabhängig ist, muss bei physischen Warentransporten eine weltweit funktionierende Logistik sichergestellt werden. Freie Wahl des Zugangsmediums Der Kunde bestimmt, über welches Zugangsmedium (z.b. Internet, Telefon, Fax, Geschäft/Filiale, ) er die Leistungen des Portals nutzen möchte ( Anyhow [Österle 2000a, S.26]). Die Wahl des Mediums erfolgt häufig nach sehr subjektiven Kriterien [vgl. Black et al. ]. Umfassende Unterstützung von Zugangsmedien Der Portalbetreiber sollte die Leistungen über möglichst viele Zugangsmedien erbringen [vgl. Fellenstein/Wood 2000, S.46f.]. Hauptzugangsmedium ist i.d.r. das Web, andere Medien werden meist ergänzend eingesetzt. Z.B. bei kann sich der Kunde per Telefon an ein Call Center wenden, wenn er Probleme mit dem Leistungsangebot hat. Bei kann der Kunde jederzeit in eine Filiale gehen, wenn er eine weiter gehende persönliche Beratung wünscht. Bei der Auswahl der unterstützten Zugangsmedien müssen auch Wirtschaftlichkeitskriterien berücksichtigt werden. Meist ist es beispielsweise nicht sinnvoll, qualifizierte Bankberater im Sinne der Kundenprozessunterstützung für Beratungstätigkeiten einzusetzen, die ausserhalb ihrer Kernkompetenz liegen. Beispiel: Die Autoversicherung der Zürich ( nutzt verschiedene Kanäle für den Kundenkontakt (s. Abb. 3-8). Versicherungsantrag

50 36 Erfolgsfaktoren für Prozessportale und weitere Zusatzleistungen wie ein Fahrzeugmarkt sind online verfügbar. Ebenfalls kann eine Schadenmeldung online erfolgen. Im Schadenfall steht aber auch eine Support-Telefonnummer zur Verfügung, über die der Kunde Unterstützung bei der Schadenabwicklung erhält. Bringt er sein defektes Fahrzeug zu einem physischen Help Point, so wird ihm die Abwicklung vollständig abgenommen. Abb. 3-8: Multikanal-Kundenschnittstelle der Zürich Autoversicherung Volle Kanalintegration Die verschiedenen Vertriebskanäle müssen auf Prozess- und auf Systemebene vollständig integriert sein, d.h. alle Kundeninformationen sind an einer Stelle verfügbar, egal welchen Kanal der Kunde nutzt. Individuelle Behandlung Die Kommunikation des Kunden mit dem Portal ist in allen Belangen vom Marketing bis zum After-Sales-Service auf seine persönlichen Bedürfnisse abgestimmt ( One-to-one [Österle 2000a, S.26]). Insbesondere sollten die Portaloberfläche und die Portalinhalte individuellen Präferenzen angepasst werden können [vgl. Hoque 2000, S.76ff.]. Personalisierung und Kundenprofile Der Portalbetreiber speichert Verhalten und Präferenzen des Kunden in Kundenprofilen. Diese Informationen nutzt er zum Aufbau von persönlichen Homepages für den Kunden und zur Individualisierung von Leistungen.

51 Erfolgsfaktoren für Prozessportale 37 Zusatzleistungen Der Kunde erwartet eine Nutzung der Möglichkeiten des Internets zur Realisierung von Zusatzleistungen, die so über herkömmliche Vertriebskanäle nicht möglich wären. Bereitstellung von Wissen und Kommunikationsmöglichkeiten Der Portalbetreiber stellt Kommunikationsmöglichkeiten wie Diskussionsforen und Chat, multimediale Informationsangebote etc. im Portal zur Verfügung. Solche Leistungen bieten einen erheblichen Mehrwert, da sie z.b. den ortsunabhängigen Austausch mit Gleichgesinnten ermöglichen oder Expertenwissen verfügbar machen, das sonst nur schwer zugänglich wäre [vgl. Hoque 2000, S.83ff.] Vertrauen Bevor ein Kunde erstmals ein Vertragsverhältnis mit dem Portalbetreiber oder mit einem der Portalpartner eingeht und z.b. persönliche Daten preisgibt, muss er Vertrauen in das Portal gewinnen. Dazu sind entsprechende Zusicherungen des Portalbetreibers erforderlich: Rechtsklarheit Der Kunde muss sich informieren können, mit wem er ein Vertragsverhältnis eingeht und welche Bedingungen damit verknüpft sind. Insbesondere möchte er wissen, welche Rechte und Pflichten er hat und welche Risiken er tragen muss. Klare Geschäftsbedingungen Der Portalbetreiber verfasst klare und verständliche Geschäftsbedingungen, die er dem Kunden leicht auffindbar im Portal zugänglich macht. Insbesondere vor einem Vertragsabschluss muss darauf hingewiesen werden, dass er die Geschäftsbedingungen nachlesen kann. der Kunde auf die Möglichkeit hingewiesen werden, diese Geschäftsbedingungen zu lesen. Risikominimierung Beim Bezug von Dienstleistungen über ein Portal geht der Kunde in der Regel gewisse Risiken ein, z.b. kann die Ware nicht den Vorstellungen entsprechen oder beim Transport beschädigt werden. Er verlangt daher vom Portalbetreiber, dass dieser durch entsprechende Vereinbarungen und Garantien die Risiken für den Kunden minimiert. Kundenfreundliche Rücktrittsrechte Der Portalbetreiber sollte dem Kunden kundenfreundliche Rechte einräumen, die Ware zurückzugeben oder vom Vertrag zurückzutreten. Ausserdem sollten

52 38 Erfolgsfaktoren für Prozessportale risikoarme Bezahlungsmöglichkeiten z.b. per Rechnung oder per Lastschrift möglich sein. Datenschutz Der Kunde erwartet, dass persönliche Daten, die z.b. in Kundenprofilen gespeichert werden, vertraulich behandelt werden. Datenschutzgarantien Der Portalbetreiber gibt entsprechende Datenschutzgarantien und schliesst insbesondere den Verkauf von Kundendaten an Dritte aus. Beispiel: Die Winterthur Webinsurance hat klare Datensicherheits- und Datenschutzrichtlinien, die auf der Homepage leicht auffindbar und gut verständlich sind (s. Abb. 3-9). Abb. 3-9: Datenschutzzusicherungen bei der Winterthur Webinsurance Vertrauenswürdiger Partner Ein Kunde baut leichter Vertrauen zu einem Portal auf, wenn eine bekannte, vertrauenswürdige Marke als Portalbetreiber auftritt [Black et al., S.14f.]. Bekannte Namen einsetzen Ist der Portalbetreiber selbst ein bekanntes Unternehmen oder ein Unternehmen mit bekannten Marken, so sollten diese Namen auch im Portal eingesetzt werden. In beispielsweise stellt sich die Credit Suisse als Portalbetreiber auch explizit im Portal dar. Ist ein solcher bekannter Name im eigenen Unternehmen nicht verfügbar, so kann evtl. eine Kooperation mit einem entsprechenden Unternehmen eingegangen werden. Denkbar wäre auch eine Institution, die Portale zertifiziert und Gütesiegel vergibt.

53 Erfolgsfaktoren für Prozessportale Zufriedenheit Einen wesentlichen Beitrag zur Kundenzufriedenheit leistet eine reibungslose und effiziente Abwicklung. Ebenfalls muss die Leistungsqualität den Kundenerwartungen entsprechen. Die folgenden Aspekte sind dabei relevant: Qualität Der Kunde erwartet eine angemessene und gleich bleibende Qualität der angebotenen Leistungen und der Leistungserbringer. Vor allem muss die im Portal angebotene Qualität mit der Qualität der tatsächlich erbrachten Leistung übereinstimmen, und die Qualitätsstandards der verschiedenen kooperierenden Anbieter müssen sich auf einem einheitlichen Niveau befinden. Sorgfältige Partnerauswahl Der Portalbetreiber sollte die Kooperationspartner sorgfältig und frühzeitig auswählen. Die Leistungen des Partners müssen zum Leistungsangebot des Portals passen, die Partner müssen in der Lage sein, die Leistungen langfristig und korrekt zu erbringen. Sowohl der Portalbetreiber als auch die Partner dürfen nur Leistungen erbringen, die zu den eigenen Kernkompetenzen gehören. Verpflichtende Partnereinbindung Die Partner müssen vertraglich zur Leistungserbringung verpflichtet werden. Für die Kooperation zwischen jedem einzelnen Partner und dem Portalbetreiber ist ein für beide Seiten attraktives Geschäftsmodell notwendig. Kritische Masse der Kunden Je höher die Anzahl der Portalnutzer ist, desto leichter wird der Portalbetreiber Partner für die Leistungserbringung finden [s. Hagel/Singer 1999, S. 169ff]. In diesem Zusammenhang ist es erforderlich, über eine möglichst grosse Reichweite zu verfügen [Evans/Wurster 2000, S.83ff.]. Zuverlässigkeit und Geschwindigkeit Der Kunde erwartet eine zuverlässige und möglichst schnelle Erbringung der benötigten Leistungen, unabhängig davon, ob die Leistung vom Portalbetreiber selbst oder von einem seiner Partner erbracht wird [Fellenstein/Wood 2000, S.30ff.]. Prozess- und Systemintegration Frontend, Backend und Kooperationspartner müssen sowohl auf Prozess- als auch auf Systemebene voll integriert sein. Das heisst, dass ein im Frontend erfasster Auftrag ohne manuelle Zwischenschritte die Leistungserbringung im Backend und/oder beim Partner auslösen muss. Zur Erleichterung der Integration sollten bei der Anbindung der Partner gängige Standards eingehalten werden [vgl. Fellenstein/Wood 2000, S.84ff.]. Transparenz Der Kunde möchte jederzeit über den Status seines Auftrages informiert sein und

54 40 Erfolgsfaktoren für Prozessportale die Möglichkeit haben, den Auftrag zu ändern oder zu stornieren [Fellenstein/Wood 2000, S.41]. Auftragsverfolgung Der Portalbetreiber implementiert in seinem System die Möglichkeit für den Kunden, jederzeit den genauen Status abfragen zu können und Änderungen vornehmen zu können. Auch hierfür ist eine volle Integration erforderlich (s.o.). Beispiel: Beim internationalen PC-Hersteller Dell ( kann der Kunde jederzeit den Status seiner Bestellung und den voraussichtlichen Liefertermin abfragen (s. Abb. 3-10). Abb. 3-10: Abfrage des Bestellstatus bei Dell Datensicherheit Der Kunde erwartet, dass bei der Abwicklung alle anfallenden Transaktionen sicher abgewickelt werden. Hoher Sicherheitsstandard Der Portalbetreiber setzt moderne kryptographische Massnahmen zur Gewährleistung der Datensicherheit ein. Dazu gehören Verschlüsselungs- und Signaturverfahren sowie Standards für sichere Zahlungstransaktionen. 3.2 Fallbeispiel: yourhome.ch Die folgenden Ausführungen beschreiben Realisierung und Betrieb des Prozessportales yourhome.ch, das den Kundenprozess Immobilienerwerb unterstützt. Das Ziel dieses Fallbeispieles ist es, die oben beschriebenen theoretischen Aspekte zu illustrie-

55 Erfolgsfaktoren für Prozessportale 41 ren. Die Angaben basieren auf einem Interview mit der Projektleitung von yourhome.ch (s. Anhang D.2) Inhalte von yourhome.ch Die Credit Suisse betreibt mit yourhome.ch eine Website, die Informationen und Dienstleistungen rund um den Immobilienerwerb anbietet. Eine Kernfunktion ist die Möglichkeit, online Hypotheken zu beantragen. Ergänzend bietet yourhome.ch Funktionalitäten, die den Kunden zu jedem Zeitpunkt in seinem Prozess des Immobilienerwerbs ansprechen sollen von den ersten Überlegungen bis zu Gartengestaltung, Inneneinrichtung und Umzug. Abb. 3-11: Der Kunde kann sich in der Rubrik Was muss ich wissen? zunächst grundlegend informieren. Hier findet er Hintergrundinformationen über die Bedarfsermittlung, die Objektsuche sowie über Rechtsfragen, Steuerthemen, Finanzierungsmöglichkeiten und Versicherungsfragen. Des Weiteren besteht die Möglichkeit, sich die Attraktivität der gewünschten Wohngemeinde anzeigen zu lassen und zwar bezüglich Steuersituation, Verkehrslage, Ausbildungsstand der Bevölkerung usw. Diese Informationen helfen dem Kunden, seinen persönlichen Immobilienerwerbsprozess zu organisieren. Checklisten und Hinweise, was bei den einzelnen Aktivitäten zu beachten ist, erlauben es ihm, auf einfache Weise Know-how über diesen Prozess aufzubauen. Konkrete Unterstützung bei der Suche nach einem geeigneten Objekt findet man in der Rubrik Was gibt es auf dem Markt?. Der Kunde kann hier in mehreren von Drittan-

56 42 Erfolgsfaktoren für Prozessportale bietern zur Verfügung gestellten Immobiliendatenbanken nach geeigneten Objekten suchen. Außerdem hat er Zugriff auf Kartenmaterial, das ihm Auskunft über die Wohnlage und die Umgebung eines gefundenen Objektes gibt. Eine weitere Funktion bietet Unterstützung, wenn der Kunde ein Objekt individuell bewerten lassen möchte. Ausserdem besteht Zugriff auf nützliche Adressen zum Beispiel von Immobilienmaklern und Liegenschaftsbewertern. Geht es um die Finanzierung der Immobilie, bietet yourhome.ch unter der Rubrik Online-Finanzierung die Möglichkeiten, ein persönliches Budget zu planen, Konditionen für Hypotheken der Credit Suisse zu ermitteln und steuerliche Auswirkungen sowie Versicherungsvarianten zu berechnen. Einige Versicherungen können auch online abgeschlossen werden. Natürlich kann der Kunde online einen Hypothekarkredit beantragen. Die Rubrik Rund ums Wohnen bietet eine weiter gehende Unterstützung des Kundenprozesses. Unter Bau/Umbau/Renovation findet man Informationen über einen typischen Bauablauf sowie diverse Checklisten. Der Umzug wird durch Informationen über Umzugsmöglichkeiten und -kosten sowie durch einen Link auf ein Speditionsunternehmen unterstützt. Zur Planung der Inneneinrichtung stehen Checklisten sowie eine kostenlose Möblierungssoftware zum Download zur Verfügung. Auch für den Gartenbau findet man ausführliches Informationsmaterial. Im Marktplatz sind die Links zu allen yourhome-partnern zusammengefasst, die Produkte oder Dienstleistungen rund um die Immobilie anbieten. Mein Folder bietet die Möglichkeit, yourhome.ch zu personalisieren. Dabei werden persönliche Einstellungen, Links und Eingaben bei Modellrechnungen gespeichert und können später wieder abgerufen werden. Auch dient Mein Folder dazu, den Status eines online erfassten Kreditantrages zu verfolgen. Unter Tools findet man nochmals alle Checklisten, Online-Rechner, Links usw. an einem Ort zusammengefasst. News beinhaltet aktuelle Informationen, Angebote und einen Tipp des Monats. Um das umfassende Informations- und Dienstleistungsangebot zum Thema Immobilie bereitstellen zu können, arbeitet die Credit Suisse mit verschiedenen externen Partnern zusammen, deren Kernkompetenzen in den einzelnen Themengebieten liegen (z.b. Makler, Umzugsunternehmen, Gartenbauunternehmen etc.). Auf der Website yourhome.ch werden die Inhalte der verschiedenen Partner und der Credit Suisse zu einem umfassenden Angebot zusammengefügt, das auf die Bedürfnisse des Kunden ausgerichtet ist. Abb illustriert diese Struktur.

57 Erfolgsfaktoren für Prozessportale 43 ETH Archithema Etzel yourhome.ch Kundenprozess IAZI CIFI ImmoPool ImmoTax Limmatdruck MVS Baumarketing Nägeli-Umzüge Rodrigo & Abegg Schweizer Garten SwissClick SwissTax Symplan Map AG Winkler&Richard News, Checklisten Finanzierungsoptionen Objektsuche Geogr. Informationen Online-Finanzierung Umzug Inneneinrichtung Gartenbau... Informieren Finanzplanung Objekt suchen Finanzierung Umzug Einrichtung... Wüest&Partner Abb. 3-12: Struktur von yourhome.ch Ausgangslage und Ziele Ausgangspunkt für die Entwicklung von yourhome.ch war die Geschäftsidee, eine Internet-Homepage zu entwickeln, die Informationen über Hypothekar-Finanzierungen bieten und den Verkauf von Hypotheken ermöglichen sollte. Zusätzlich plante man, weitere Informationen und Produkte zu Themen rund um die Immobilie wie z.b. Kauf, Verkauf, Bau, Umbau, Umzug und Einrichtung zu integrieren. Damit ein möglichst breites Themenspektrum abgedeckt werden kann, sollten erstklassige externe Partner eingebunden werden. Das primäre Ziel, welches die Credit Suisse mit dem Projekt verfolgte, war der Ertrag durch den Verkauf von Hypotheken, sei es online oder bei einer Geschäftsstelle. Im Vordergrund stand dabei die Gewinnung von Neukunden für die Credit Suisse. Durch das umfassende Informationsangebot auf yourhome.ch sollte der Kunde auf seinem Entscheidungsweg in jedem Stadium angesprochen werden, also z.b. bei Budgetüberlegungen, bei der Klärung von Finanzierungsfragen, bei der Suche eines geeigneten Objektes, bei Einrichtungsfragen etc. Ein weiteres Ziel war die Verstärkung des positiven Images der Credit Suisse im Bereich der Web-Auftritte. Als first mover strebte sie eine führende Position im Hypothekenverkauf via Internet an. Ausserdem wollte man mit yourhome.ch eine Plattform schaffen, die eine systematische Einbindung von Maklern ermöglicht. Diese sollten einerseits als Absatzmittler für Hypotheken fungieren und andererseits Inhalte für yourhome.ch zur Verfügung stellen wie z.b. Informationen über verfügbare oder gesuchte Kaufobjekte.

58 44 Erfolgsfaktoren für Prozessportale Während der kurzen Projektentwicklungsphase standen Einsparungen bei der Abwicklung der Hypothekaranträge durch Optimierungen auf Prozessebene nicht im Vordergrund. Es ist jedoch wahrscheinlich, dass das Ausschöpfen dieses Optimierungspotenzials in Zukunft stark an Bedeutung gewinnen wird Business Case und Ertragskonzept Zu Projektbeginn wurde ein Business Case erstellt. Da kein Schweizer Referenzmarkt vorhanden war, mussten viele Annahmen getroffen werden und Angaben aus dem Online-Markt der USA übernommen werden. Aus diesen Gründen war der Business Case von Anfang an mit einer hohen Unsicherheit behaftet. Für das Projekt yourhome.ch galt, dass der über einen Zeitraum von fünf Jahren berechnete Kapitalwert (Net Present Value) positiv sein muss. Die Einnahmequellen von yourhome.ch sind der Verkauf von Hypotheken und die durch die Einbindung externer Partner erzielten Erlöse. Für die Kooperation mit jedem einzelnen externen Partner wird ein eigener Vertrag ausgehandelt und abgeschlossen. Häufig sind Ideen oder Vorschläge für Inhalte vorhanden, für die dann nach einem sowohl für die Credit Suisse als auch für den Partner attraktiven Ertragskonzept gesucht werden muss Prozesse Auf Prozessebene unterscheidet man zwischen dem Kundenprozess, den Geschäftsprozessen und den Unterstützungsprozessen. Der Kundenprozess läuft beim Kunden ab und umfasst im Fall von yourhome.ch alle Aktivitäten rund um den Erwerb einer Immobilie. Die Geschäftsprozesse sind diejenigen Prozesse bei der Credit Suisse und ihren externen Partnern, die im Rahmen von yourhome.ch Leistungen an den Kunden erbringen wie z.b. der Prozess Verkauf von Hypotheken. Die Leistungen der Unterstützungsprozesse richten sich nicht direkt an den Kunden, sondern nur an die Geschäftsprozesse. Ein wichtiger Unterstützungsprozess bei yourhome.ch ist z.b. das Content Management. Die Analyse und Anpassung der Geschäftsprozesse wurde im Projekt yourhome.ch als sehr wichtig eingestuft und in einem eigenen Teilprojekt durchgeführt Kundenprozess Die Abläufe beim Kunden im Zusammenhang mit dem Immobilienerwerb wurden in Form eines Kundenprozesses analysiert. Art und Strukturierung der in yourhome.ch bereitgestellten Inhalte basieren auf den Erfahrungen der Kundenberater im Hypothekarbereich und auf den bestehenden Kundenprozessen der Credit Suisse. Sie wurden vom Projektteam gemeinsam festgelegt. Die wichtigsten Kriterien für die Integration neuer Inhalte sind folgende:

59 Erfolgsfaktoren für Prozessportale 45 Sind die Inhalte für den Kunden im Zusammenhang mit Immobilien / Hypotheken relevant? Gibt es ein geeignetes Geschäftsmodell für die Kooperation mit dem externen Partner, der die Inhalte bereitstellt? Folgen Partner und Inhalte dem Leitsatz Best Service and Advice? Oft werden neue Inhalte aufgrund der Vorschläge von (potenziellen) externen Partnern eingebunden Geschäftsprozess Verkauf von Hypotheken Der wichtigste von yourhome.ch betroffene Geschäftsprozess ist der Verkauf von Hypotheken einschliesslich der Bearbeitung der Kreditanträge. Dieser Prozess ist wenig standardisiert, da z.b. jeder Kanton der Schweiz ein eigenes Grundpfandrecht hat. Der bestehende, auf den Verkauf in der Bankfiliale ausgerichtete Prozess wurde analysiert und konnte weitgehend übernommen werden. Es sind die folgenden kleineren Anpassungen an die speziellen Anforderungen von yourhome.ch vorgenommen worden: Für den Verkauf von Hypotheken über yourhome.ch wurde ein eigenes Verkaufsteam im Call Center in Horgen angesiedelt. Dieses Team verfügt über die gleichen Kompetenzen wie Privatkundenberater in der Bankfiliale, ist aber für die gesamte Schweiz zuständig und muss daher in allen Landessprachen beraten können und alle regionalen Besonderheiten berücksichtigen. Ein online ausgefüllter Kreditantrag wird diesem Team zur Weiterbearbeitung automatisch übermittelt. Die anschliessende Erfassung der Daten im Host erfolgt manuell. Eine Schnittstelle zwischen yourhome.ch und dem Host zur automatischen Datenübernahme konnte bisher nicht realisiert werden, wird aber momentan geplant. Im Gegensatz zum herkömmlichen Verkaufsprozess sichert die Credit Suisse bei einem Kreditantrag über yourhome.ch im Normalfall eine Bearbeitung und einen Entscheid innerhalb von 24 Stunden zu. Diese Zusicherung erforderte während des Projektes einige Gespräche mit den für die Kreditsprechung zuständigen Krediteinheiten. In der Praxis hat sich aber die Einhaltung der Frist als unproblematisch erwiesen. Um die 24 Stunden-Frist einhalten zu können, musste der Postweg zwischen dem yourhome-verkaufsteam und den Krediteinheiten eliminiert werden. Heute werden die Dokumente per Fax übermittelt und die Originale per Post nachgereicht. Für das 4. Quartal 2000 ist die Einführung eines Dokumentenmanagement-Systems geplant, an das alle betroffenen Einheiten angeschlossen werden. Alle erforderlichen Dokumente werden dann eingescannt und intern auf elektronischem Weg verteilt. Die interne Kommunikation per Fax und Post kann somit grösstenteils eliminiert werden.

60 46 Erfolgsfaktoren für Prozessportale Gegenüber dem Hypothekenkauf in der Filiale hat der Kunde bei yourhome.ch die Möglichkeit, jederzeit den Status seines Antrags zu überprüfen ( Tracking ). Bei jedem Bearbeitungsschritt wird dem Kunden eine Nachricht in seinem persönlichen, geschützten Nachrichtenbereich in Mein Folder abgespeichert. Er erhält zudem eine , die ihn über die Existenz der neuen Mitteilung informiert (aus Sicherheitsgründen nicht aber die Mitteilung selbst). Für den Kunden sind die Kanäle durchlässig gestaltet. D.h. er kann jederzeit von den yourhome-kanälen Internet und Call Center zur Filiale wechseln, um dort Beratung und Vertragsabschluss fortzusetzen. Abb zeigt den Ablauf beim Verkauf von Hypotheken über yourhome.ch. Links im Bild sind die einzelnen Aufgaben des Prozesses aufgeführt, auf der rechten Seite sieht man die einzelnen Aktivitäten, die im Administrationssystem durchgeführt werden müssen.

61 Erfolgsfaktoren für Prozessportale 47 Kunde startet Online-Finanzierung, erhält positiven Score mit unverbindlichem Finanzierungsvorschlag 1. Kunde hat unverbindlichen Kreditantrag online übermittelt und schickt Kreditantrag und Beilagen ans yourhome.ch Hypo-Team 2. Das yourhome.ch Hypo-Team überprüft erhaltene Unterlagen auf Vollständigkeit 3. Das yourhome.ch Hypo-Team bereitet Kreditentscheid vor und informiert Krediteinheit (Originalunterlagen FAXEN und schicken) 4. Krediteinheit fällt Kreditentscheid und informiert das yourhome.ch Hypo-Team 5. Das yourhome.ch Hypo-Team übermittelt Kreditentscheid an Kunden, schickt Neukunden VSB Unterlagen und fordert bei Krediteinheit Kreditformalitäten an 6. Das yourhome.ch Hypo-Team stellt dem Kunden Vertragsunterlagen zu (bei Neukunden erst nach Rückerhalt der Basisformalitäten) 7. Kunde hat unterschriebene Vertragsformalitäten zurückgeschickt 1. Elektronisch übermittelter Kreditantrag beim yourhome.ch Hypo-Team 2. Überprüfen der Unterlagen auf Vollständigkeit / erste Kreditprüfung 3. Kreditaufbereitung / Unterlagen an Krediteinheit 4. Kreditbewilligung / Information ans yourhome.ch Hypo-Team 8. Das yourhome.ch Hypo-Team zusammen mit Krediteinheit zahlen Kredit aus 5. Mitteilung Kreditentscheid an Kunden / Versand VSB-Unterlagen an Neukunden 6. Vertragsunterlagen an Kunden 7. Unterschriebene Vertragsformalitäten beim yourhome.ch Hypo-Team 8. Kreditabwicklung: Vorgehen klären und Kreditauszahlung begleiten Status-Box / Admin-Tool Kunde identifiziert sich, indem er sich einloggt Kundendaten werden fortlaufend gespeichert Kunde hat den Kreditantrag elektronisch übermittelt Track 1 wird automatisch ausgelöst yourhome.ch Hypo-Team löst Track 2 aus Direkten Ansprechpartner angeben Fehlende Unterlagen einfordern Zeitpunkt des definitiven Entscheides mitteilen (im Normalfall innert 24h) yourhome.ch Hypo-Team löst Track 3 aus Bei Neukunden zuerst Basisformalitäten (VSB) zustellen Entscheid mitteilen yourhome.ch Hypo-Team löst Track 4 aus Kreditformalitäten werden per Post zugestellt yourhome.ch Hypo-Team löst Track 5 aus Unterzeichnete Kreditformalitäten vollständig zurückerhalten Weiteres Vorgehen klären Tracking abschliessen Das yourhome.ch Hypo-Team betreut SEINE Kunden (Kundenverantwortung) Abb. 3-13: Verkaufsprozess für Hypotheken über yourhome.ch Content Management Für die Erstellung neuer Inhalte und für die Aktualisierung bestehender Inhalte ist das Content Management verantwortlich. Derzeit ist keine Software zur Unterstützung des Content Managements im Einsatz, die Einführung einer solchen Lösung ist aber für 2001 geplant.

62 48 Erfolgsfaktoren für Prozessportale Content Management-Prozess für neue Inhalte Der Idee für einen neu in yourhome.ch zu integrierenden Inhalt folgt eine Abklärung, ob dieser Inhalt intern d.h. innerhalb der CS Group bereitgestellt und gepflegt werden kann, oder ob dafür externe Partner erforderlich sind. In diesem Fall wird ein Account Manager beauftragt, einen geeigneten externen Partner zu suchen und zu evaluieren. Dann wird ein individuelles Designkonzept für die neuen Inhalte entworfen. Im Fall der Kooperation mit externen Partnern finden Vertragsverhandlungen und Vertragsabschluss statt. Anschliessend werden die Inhalte erstellt. Zu einem geeigneten Zeitpunkt folgt ein Content Freeze, d.h. der aktuelle Stand der Inhalte wird ab diesem Zeitpunkt nicht mehr verändert. Die Inhalte werden dann in die verschiedenen Sprachen übersetzt und regionalen Gegebenheiten angepasst. Anschliessend erfolgt die technische Entwicklung der Webseiten. Handelt es sich um rein statische HTML-Seiten, so erstellt sie die Webfactory der Business Unit Credit Suisse e-business. Sind hingegen dynamische Inhalte und Applikationen involviert, so realisiert sie die zentrale IT der Credit Suisse. Schliesslich folgen Tests, die Integration in die Produktivumgebung und die Freischaltung. Aktualisierung bestehender Inhalte Für die inhaltliche Pflege von yourhome.ch sind Content Manager verantwortlich. Diese erstellen bzw. aktualisieren die einzelnen Inhalte und koordinieren die Bereitstellung von Inhalten durch die externen Partner. Den Content Managern und Partnern stehen vordefinierte HTML-Templates zur Verfügung. Dadurch werden die Content Manager nicht mit Layout- und Designfragen konfrontiert, und die Einhaltung einer einheitlichen Design-Richtlinie kann garantiert werden. Die Projektleitung von yourhome.ch gibt die neuen bzw. aktualisierten Inhalte frei. Die Web Factory oder bei Bedarf die zentrale IT der Credit Suisse implementiert die Inhalte und integriert sie in die Produktivplattform von yourhome.ch Anbindung der externen Partner auf Prozessebene Es existieren keine standardisierten Prozesse zur Anbindung der externen Partner. Ein Partnerprospekt zeigt die wichtigsten Anforderungskriterien an den Partner und das Vorgehen bei der Zusammenarbeit auf. Die Abläufe und vor allem die Zeitpunkte der Inhaltserstellung bestimmen die Partner häufig selbst. Dadurch erweist sich für das yourhome.ch-team die Koordination der Inhaltserstellung durch die Partner und der Implementierung durch die IT als problematisch, da die Termine und Kapazitäten der IT nur schwer darauf abgestimmt werden können.

63 Erfolgsfaktoren für Prozessportale Architektur Die verschiedenen Applikationsteile wurden durch externe Software-Firmen hergestellt. Die Sicherheits- und Architekturanforderungen sowie die gesamte Koordination im IT-Bereich war jedoch in der Zuständigkeit der Credit Suisse-eigenen IT. Auf technischer Ebene sind verschiedene Standardkomponenten zum Einsatz gekommen, z.b. im Bereich Datenbank, Webserver, Servlet Engine, Produktionsüberwachung usw. Externe Partner werden auf zwei verschiedene Arten eingebunden: Bei den Informationsangeboten der meisten Partner (z.b. Swisscom Branchenverzeichnis, Nägeli Umzüge, geografisches Informationssystem) greift der Webbrowser direkt auf den Webserver des Anbieters zu. Die Systeme der Credit Suisse sind bei dieser Zugriffsart nicht involviert. Bei anderen Partnern (z.b. Swissclick und Immopool) greift yourhome.ch auf die Objekt-Datenbanken der Anbieter zu. Die Systeme der Credit Suisse sind zuständig für die Aufbereitung der Informationen in Form von HTML-Seiten und für die Übermittlung an den Webbrowser des Benutzers Projektverlauf und aktueller Stand yourhome.ch wurde in sehr kurzer Zeit realisiert: Projektstart war im August 1999, eine erste, rein statische Version schaltete man am 19. Januar 2000 frei, die zweite Version folgte am 4. April Derzeit 1 sind 18 externe Partner eingebunden, seit der Lancierung sind etwa 140 Anfragen von weiteren an einer Partnerschaft interessierten Unternehmen eingegangen. Die Zugriffszahlen beliefen sich nach der Lancierung auf rund 3000 Besuche pro Tag, sanken im Sommer 2000 auf unter 1000 Zugriffe pro Tag und sind jetzt wieder steigend. Gegenüber dem zu Projektbeginn erstellten Business Case (s.o.) sind bisher folgende Beobachtungen gemacht worden: Im Business Case hat man sich stark an den Volumen im Online-Markt der USA orientieren müssen, was teilweise nicht den europäischen Verhältnissen entspricht. Die Erwartungen an Online-Abschlüsse über yourhome.ch sind bisher noch nicht erfüllt worden. Der Beobachtungszeitraum (7 Monate) ist jedoch noch zu kurz, um verlässliche Aussagen zu machen. Insbesondere mit Hilfe des Internets ist ein Vergleich der Konditionen für die Kunden leichter möglich. Die Bank muss somit bestrebt sein, konkurrenzfähige Hypothekar-Konditionen anzubieten. 1 September 2000

64 50 Erfolgsfaktoren für Prozessportale Viele Kunden und Nichtkunden eignen sich mit yourhome.ch Detailkenntnisse über die Produkte, Konditionen und den Immobilienmarkt an. Dies beweisen auch die guten Traffic-Zahlen. Es ist anzunehmen, dass viele Hypothekarsuchende für den effektiven Abschluss nach wie vor das Gespräch mit ihrem Kundenberater in einer Geschäftsstelle suchen und dort abschliessen. yourhome.ch als weiterer Vertriebs- und Informationskanal spielt somit im Rahmen des Multichannel- Ansatzes der Credit Suisse eine wichtige Rolle. Die Einnahmen durch Kooperationen mit externen Partnern wurden im Business Case tiefer eingeschätzt. Als wichtigsten Wettbewerbsvorteil von yourhome.ch sieht die Credit Suisse die Geschwindigkeit an, mit welcher der Auftritt lanciert wurde. Als first mover ist die Credit Suisse der Konkurrenz zeitlich einen Schritt voraus Ausblick In Bezug auf die Weiterentwicklung von yourhome.ch werden derzeit verschiedene Fragestellungen diskutiert. Dabei hat yourhome.ch zwei Optionen: Als Attacking Business zu operieren und evtl. vollständig aus der Credit Suisse ausgegliedert zu werden oder als Enabling Business integrierter Bestandteil der Credit Suisse zu bleiben. Ausserdem wird diskutiert, ob yourhome.ch auf die Schweiz beschränkt bleibt oder ob die Aktivitäten auf das europäische Ausland ausgedehnt werden. Denkbar wäre z.b. yourhome.ch in der Schweiz als Enabling Business zu betreiben und im Ausland als Attacking Business aufzubauen. Grundsätzlich wäre es auch möglich, neben den Hypotheken der Credit Suisse über yourhome.ch auch Hypotheken von anderen Banken oder Versicherungen zu vertreiben. Ein solches Vorgehen passt vor allem zu einer Attacking Business -Strategie. Im Enabling Business käme ein Verkauf von Konkurrenzprodukten nur dann in Frage, wenn der Vertriebskanal Geschäftsstelle diese auch vertreiben würde. Inhaltlich soll yourhome.ch mit einem umfassenden Marktplatz für Produkte verschiedener Anbieter rund um das Thema Wohnen weiter ausgebaut werden. 3.3 Analyse von yourhome.ch Bei yourhome.ch handelt es sich um ein Prozessportal, da es einen konkreten Kundenprozess den Immobilienerwerb unterstützt, dazu Kooperationen mit verschiedenen Partnern eingeht und das Web als wichtigsten Vertriebskanal nutzt (vgl. Kapitel 2.3). Die folgende Aufstellung analysiert nun, welche der in Kapitel 3.1 definierten Kriterien für yourhome.ch zutreffen. Die Angaben zu yourhome.ch beziehen sich auf September Da yourhome.ch laufend weiterentwickelt wird, können die Angaben bereits zum Zeitpunkt des Erscheinens der vorliegenden Arbeit überholt sein. Über den

65 Erfolgsfaktoren für Prozessportale 51 Erfolg von yourhome.ch können noch keine Aussagen gemacht werden, da der Beobachtungszeitraum von sieben Monaten seit der ersten Lancierung des Portals zu kurz ist. Anforderung des Kunden Kosten-/Zeitersparnis Massnahme des Portalbetreibers Erfüllung bei yourhome.ch + = vollständig o = teilweise oder geplant - = unzureichend Prozessunterstützung Abnahme von Aufgaben o Es stehen umfassende Informationen zur Verfügung, der Kunde muss sich aber selbst einarbeiten und wird nicht durch Prozesse wie z.b. Standortwahl oder Kauf-/Miet-Entscheidung geführt. Vollständigkeit Kundenprozessorientierung o Der Kundenprozess Immobilienerwerb wird umfassend unterstützt. Zu vielen Kooperationspartnern muss der Kunde aber eine eigene Geschäftsbeziehung aufbauen. Kritische Masse der Anbieter Beobachtungszeitraum ist noch zu kurz, Anbieterkooperationen werden laufend erweitert. Konkurrenzfähigkeit Neutralität Informationsfülle Attraktive Konditionen Ausgleich von Nachteilen Einbezug von Konkurrenzanbietern + Die angebotenen Produkte und Dienstleistungen sind im Allgemeinen detailliert beschrieben. - Einzelne Konkurrenten bieten bessere Konditionen an. + Es sind keine Nachteile erkennbar. o Derzeit nicht, in Zukunft geplant.

66 52 Erfolgsfaktoren für Prozessportale Anforderung des Kunden Vollständige Abwicklung Einheitliche Bedienung Zusatznutzen Orts- und Zeitunabhängigkeit Freie Wahl des Zugangsmediums Individuelle Behandlung Zusatzleistungen Massnahme des Portalbetreibers Integration aller Geschäftsvorgänge Volle Integration der Partnerleistungen Benutzerfreundliche Portaloberfläche Trennung von Inhalt und Layout 24h Verfügbarkeit Weltweite Logistikleistungen Umfassende Unterstützung von Zugangsmedien Volle Kanalintegration Personalisierung und Kundenprofile Bereitstellung moderner Portalfunktionen Erfüllung bei yourhome.ch + = vollständig o = teilweise oder geplant - = unzureichend o Aus rechtlichen Gründen sind einige Papierunterlagen noch erforderlich, alle anderen Vorgänge sind im Portal möglich. - Viele Partner sind nur durch Links auf deren Website eingebunden. + Klares, einfach zu bedienendes Layout - Viele Partner haben eigenes Layout. o Portal ist über das Internet immer verfügbar, Abwicklung erfolgt nur zu normalen Geschäftszeiten. Das Angebot beschränkt sich auf den Schweizer Markt. o Beratung und Abschluss von Hypotheken ist über das Web, im Call Center und in der Filiale möglich. Leistungen der Partner sind nur übers Web und direkt bei den Partnern möglich. + Ein im Web begonnener Vorgang kann z.b. auch in der Filiale fortgeführt werden. + Mit Mein Folder bietet yourhome einen personalisierten Bereich. + Es stehen z.b. Funktionen zur Durchführung von Steu-

67 Erfolgsfaktoren für Prozessportale 53 Anforderung des Kunden Vertrauen Rechtsklarheit Risikominimierung Massnahme des Portalbetreibers Klare Geschäftsbedingungen Kundenfreundliche Rücktrittsrechte Erfüllung bei yourhome.ch + = vollständig o = teilweise oder geplant - = unzureichend er- und Budgetberechnungen zur Verfügung, eine Software zur Planung der Einrichtung kann heruntergeladen werden. o Die Anwendungsbedingungen und rechtlichen Informationen beziehen sich auf alle Webangebote der Credit Suisse und dienen ausschliesslich zur Absicherung der Credit Suisse. + Der Kunde trägt kein Risiko, solange er den schriftlichen Hypothekarvertrag nicht unterschreibt. Datenschutz Datenschutzgarantien - Der Kunde muss in eine Weitergabe der persönlichen Daten innerhalb der Credit Suisse Group einwilligen. Vertrauenswürdige Partner Zufriedenheit Qualität Bekannte Namen einsetzen Sorgfältige Partnerauswahl Verpflichtende Partnereinbindung + Die Credit Suisse tritt als Betreiber des Portals auf. + Die Partnerauswahl folgt dem Leitsatz Best Service and Advice und wird sehr sorgfältig durchgeführt. + Die Partner werden vertraglich verpflichtet. Kritische Masse der Kunden Kann aufgrund des kurzen Beobachtungszeitraums noch nicht beurteilt werden. Zuverlässigkeit und Prozess- und Systeminteg- o Die internen Prozesse bei

68 54 Erfolgsfaktoren für Prozessportale Anforderung des Kunden Massnahme des Portalbetreibers Erfüllung bei yourhome.ch + = vollständig o = teilweise oder geplant - = unzureichend Geschwindigkeit ration der Credit Suisse sind durchgängig, eine vollständige Systemunterstützung wird in Kürze realisiert sein. Die Prozesse bei der Partnereinbindung sind nur wenig standardisiert und kaum systemunterstützt. Transparenz Auftragsverfolgung + Der Kunde wird über jeden Bearbeitungsschritt des Hypothekarantrags informiert. Datensicherheit Hoher Sicherheitsstandard o Es werden nicht die höchstmöglichen Sicherheitsstandards eingehalten. Tabelle 3-2: Analyse der Portaleigenschaften bei yourhome.ch

69 Anforderungen an eine Architektur 55 4 Anforderungen an eine Architektur 4.1 Architekturbegriff Der Architekturbegriff wird in der Wirtschaftsinformatik verwendet, um Strukturen von Informationssystemen formal zu beschreiben. Die Architekturbeschreibungen können sich dabei auf verschiedene Gestaltungsbereiche beziehen. In der Literatur sind eine Vielzahl von Quellen zu finden [vgl. z.b. Zachman 1987; Heinrich 1992, S.68ff.; Schmalzl 1995, S.13ff.; Cook 1996, S.41ff.; Magee 1997; Scheer 1998; The Open Group 1999; Goodyear 2000, S.3-5ff.], die sich mit dem Architekturbegriff auseinandersetzen. Eine Darstellung der theoretischen Grundlagen des Architekturbegriffs und ausgewählter Architekturkonzepte findet man z.b. in [Sinz 1999a]. Für weitere Beschreibungen und Vergleiche verschiedener Architekturkonzepte sei z.b. auf [Huber 2000b, S. 40ff.; Pohland 2000, S.46ff.] verwiesen. Die verschiedenen Ansätze unterscheiden sich in Anzahl und Abgrenzung der Gestaltungsbereiche und in der verwendeten Terminologie. Die vorliegende Arbeit stützt sich auf einen Architekturbegriff, der mit den Konzepten und mit der Terminologie des Business Engineering kompatibel ist [s. Österle 1995; vgl. Sinz 1999a, S.1040f.]. Die Abgrenzung der Gestaltungsbereiche der Architektur orientiert sich an den drei Ebenen der Gestaltung eines Unternehmens: Geschäftsstrategie, Prozess und Informationssystem [s. Österle 1995, S.16f.]. Die Gestaltungselemente der Architektur (Architekturkomponenten) ergeben sich aus dem Metamodell des Business Engineering. Abb. 4-1 zeigt einige wichtige Objekte des Business Engineering und ihre Zusammenhänge [vgl. zur Metamodellierung Ferstl/Sinz 1998, S.117ff.]. Die einzelnen Gestaltungsebenen der Architektur werden im Folgenden näher beschrieben:! Die Geschäftsarchitektur beschreibt strategische Komponenten wie z.b. angebotene Marktleistungen, strategische Geschäftsfelder, Allianzen, Kooperationen etc. [vgl. Österle 1995, S.16].! Die Prozessarchitektur umfasst die betriebliche Aufbau- und Ablauforganisation. Die Gestaltung findet dabei auf der Prozessebene des Business Engineering statt [vgl. Österle 1995, S.16ff.]. Auf Prozessebene werden die Architekturkomponenten Rolle und organisatorische Einheit (einschliesslich Vertriebskanal) als Bestandteile der Aufbauorganisation und Prozess, Aufgabe, Leistung und Prozessführungsgrösse als Bestandteil der Ablauforganisation betrachtet.! Die IS-Architektur beschreibt den logischen Aufbau des Informationssystems. Die Architekturkomponenten auf IS-Ebene sind Funktionen, Applikationen und Daten:

70 56 Anforderungen an eine Architektur! Die einzelnen Aufgaben der Prozesse werden durch die Funktionen des Informationssystems direkt unterstützt [vgl. Österle 1995, S.289; Schulze 2000, S.172ff.].! Applikationen führen mehrere Funktionen aus, die meist in einem logischen Zusammenhang zueinander stehen.! Bei der Ausführung von Funktionen greifen die Applikationen auf Daten(sammlungen) zu. Daten sind funktionsübergreifend, häufig auch applikationsübergreifend verfügbar. Markt beeinflusst Strategisches Geschäftsfeld bietet an Marktleistung Strategie verwendet kann sein Aufgabe besteht aus Prozess produziert / konsumiert Leistung Prozess unterstützt Funktion führt aus Applikation greift zu auf Datensammlung läuft auf System IT-Komponente Abb. 4-1: Metamodell des Business Engineering [Österle/Blessing 2000, S.77]! Die IT-Architektur beschreibt den technischen Aufbau des Informationssystems. Als Gestaltungselemente werden IT-Komponenten betrachtet. Dazu gehören:! Middleware ist eine Softwareschicht, welche auf Basis standardisierter Schnittstellen und Protokolle Dienste für eine transparente Kommunikation verteilter Anwendungen bereitstellt. Middlewaredienste stellen eine Infrastruktur für die Integration von Anwendungen und Daten in einem heterogenen und verteilten Umfeld zur Verfügung [Riehm/Vogler 1996, S.28].! Systemsoftware stellt die Basis für den Betrieb von Applikationen dar. Systemsoftware umfasst sowohl Betriebssysteme als auch systemnahe Standardkomponenten wie z.b. Datenbanken.

71 Anforderungen an eine Architektur 57! Hardware umfasst z.b. Clients, Server, Mainframes, Netzwerkinfrastruktur etc. Die Betrachtungen im Rahmen der vorliegenden Arbeit beziehen sich auf Aspekte der Prozessebene (Leistung, Prozess, Aufgabe) und der Informationssystem-Ebene (Funktion, Applikation, Daten). Abb. 4-2 illustriert den Architekturbegriff auf diesen Ebenen anhand eines schematischen Beispiels aus dem Bereich CRM. Das Beispiel dient nur der Illustration der erläuterten Begriffe. Die Inhalte der Grafik erheben keinen Anspruch auf Vollständigkeit. Aspekte auf Strategieebene sind nicht Fokus dieser Arbeit, werden aber in Kapitel 5 kurz erläutert. Prozess Leistungen Prozessarchitektur Aufgaben Kampagne planen Kampagne durchführen Kampagne auswerten Kunden im Prozess führen Kundenbedarf analysieren Kunden beraten CRM Produkt konfigurieren Angebot erstellen Vertrag abschliessen Kundenproblem lösen Beschwerde bearbeiten... Produktinformation Checkliste Beratung Vertrag... IS-Architektur Funktionen Applikationen Beschwerdemanagement Opportunitymanagement Anbieter- Verzeichnis Kampagnenmanagement Marktanalyse Produktkatalog Kontaktmanagement Aktivitätenmanagement Offertmanagement Bedarfsanalyse Servicemanagement... Kunden Produkte Enterprise Marketing Automation Sales Force Automation Daten Abb. 4-2: Architekturkomponenten auf den Ebenen Prozess und Informationssystem 4.2 Kategorisierung von Prozessen und Funktionen Innerhalb der Funktionsarchitektur auf IS-Ebene unterscheidet man grundsätzlich zwischen Geschäftsfunktionen und Unterstützungsfunktionen (s. Abb. 4-3). Geschäftsfunktionen unterstützen die Aufgaben der Geschäftsprozesse. Dabei handelt es sich um Prozesse, die ihre Leistungen unmittelbar an den Kunden erbringen und damit direkt zum Geschäftserfolg beitragen. Die Leistungen der Geschäftsprozesse konsumiert der Kundenprozess. Im Gegensatz zu den Geschäftsprozessen tragen die Leistungen der Unterstützungsprozesse nur indirekt zum Erfolg bei, indem sie die Geschäftsprozesse unterstützen. Die Leistungen der Unterstützungsprozesse konsumieren Geschäftsprozesse oder an-

72 58 Anforderungen an eine Architektur dere Unterstützungsprozesse. Diejenigen IS-Funktionen, welche auf die Aufgaben der Unterstützungsprozesse ausgerichtet sind, heissen Unterstützungsfunktionen. Geschäftsprozess 1 Geschäftsprozess 2 Unterstützungsprozess Geschäftsfunktion 1 Geschäftsfunktion 2 Unterstützungsfunktion A Unterstützungsfunktion B Daten Abb. 4-3: Geschäftsfunktionen und Unterstützungsfunktionen Ein Beispiel soll diese Zusammenhänge verdeutlichen: Die Aufgabe Kundenberatung des Geschäftsprozesses Verkauf verwendet u.a. die Geschäftsfunktion Bereitstellung von Fachwissen. Dieses Fachwissen wird im Unterstützungsprozess Content- Management erstellt und gepflegt. Dieser nutzt verschiedene Unterstützungsfunktionen wie z.b. Texterfassung. 4.3 Nutzungsprozess der Architektur Planung Projektplanung Kundenpotenzialanalyse Vorstudie Konzeption Multi Channel Management Kundenprozessanalyse CRM-Prozessentwicklung Führungssystemplanung Systemplanung Organisationsentwicklung Systemeinführung Umsetzung Realisierung Abb. 4-4: Phasenmodell für die CRM-Einführung [Schulze 2000, S. 118] Die in der vorliegenden Arbeit beschriebene Architektur richtet sich in erster Linie an Business Engineers, welche Unterstützung beim Aufbau oder bei der Weiterentwicklung einer CRM-Lösung bzw. eines Prozessportals benötigen. Bei der Einführung einer neuen CRM- oder Prozessportallösung stösst man immer wieder auf Architekturfragen, in denen die hier beschriebene Architektur bzw. Teile davon unterstützend

73 Anforderungen an eine Architektur 59 herangezogen werden können. Einige denkbare Szenarien werden im Folgenden näher erläutert. Zur Veranschaulichung dient die prozessorientierte Einführungsmethode für das Customer Relationship Management nach Schulze [Schulze 2000]: Analyse des Potenzials zum Betrieb eines Prozessportals Im Rahmen der Vorstudie beschäftigen sich die Kundenpotenzialanalyse und die Kundenprozessanalyse mit der Erhebung von Kundenprozessen, die im Rahmen eines Prozessportals unterstützt werden sollen, sowie mit der Definition der Leistungen, die für die Kundenprozessunterstützung erbracht werden müssen. Die im Folgenden beschriebene Architektur beinhaltet einen Katalog allgemeiner Leistungen, die ein Prozessportal an den Kundenprozess erbringt (s. Kapitel 6.2). Dieser Katalog kann als Ausgangspunkt für die Definition der kundenprozessspezifischen Leistungen dienen. Ausserdem hilfreich ist das Beispiel eines konkreten Prozessportals für den Kundenprozess Erbschaft und Bestattung, dessen Leistungen (s. Kapitel 6.6.3) zum Vergleich herangezogen werden können Überprüfen der Realisierbarkeit neuer Prozessportale Ausgehend von einem erhobenen Kundenprozess und von den Leistungen, die zur Unterstützung dieses Kundenprozesses erforderlich sind, muss überprüft werden, welche Leistungen der Portalbetreiber selbst erbringen kann und ob aus dem Betrieb des Prozessportals ein ausreichender Nutzen für den Portalbetreiber entsteht. Einen Anhaltspunkt für diese Betrachtungen bietet die beispielhafte Beschreibung von Aufwand und Nutzen der einzelnen Leistungen beim Prozessportal für Erbschaft und Bestattung (s. Kapitel 6.6.3) Konzeption eines Prozessportals Bei der Konzeption eines Prozessportals muss das Projektteam sowohl die Prozesse des Portalbetreibers anpassen bzw. neu entwickeln als auch die Anforderungen an die unterstützenden Informationssysteme definieren. Die zugehörigen Aktivitäten im obigen Phasenmodell sind hauptsächlich die CRM Prozessentwicklung und die Systemplanung. Die im Folgenden beschriebene Prozessarchitektur (s. Kapitel 5) enthält Musterprozesse für CRM, die den Ausgangspunkt für die Definition unternehmensspezifischer Prozesse bilden können. Gleichermassen kann das Projektteam die im Rahmen der IS-Architektur (s. Kapitel 6.4) beschriebenen IS-Funktionen verwenden, um die eigenen Anforderungen an die IS-Unterstützung zu definieren Systemevaluation Die IS-Architektur (s. Kapitel 6.4) sowie die unternehmensspezifischen IS- Anforderungen können verwendet werden, um konkrete Softwarelösungen zu evaluie-

74 60 Anforderungen an eine Architektur ren. Die detailliert beschriebenen IS-Funktionen erlauben es, auf dem Markt erhältliche Softwarelösungen auf die Vollständigkeit der enthaltenen Leistungen zu überprüfen und durch einen Abgleich mit den individuellen Anforderungen eine geeignete Lösung auszuwählen. Die Systemevaluation gehört ebenfalls zur Systemplanung im Rahmen des obigen Phasenmodells Assessment bestehender Portale Analog zur Entwicklung neuer Prozessportale kann die vorliegende Architektur auch verwendet werden, um bestehende Portale zu überprüfen. Mögliche Aspekte sind hier die Vollständigkeit der angebotenen Leistungen, Aufwand und Nutzen für den Portalbetreiber, Prozesse beim Portalbetreiber und die IS/IT-Architektur. Zur Überprüfung werden die in der vorliegenden Architektur beschriebenen Elemente mit denen des Prozessportals verglichen und eventuelle Unterschiede identifiziert. Bei den Unterschieden kann es sich entweder um Schwächen der bestehenden Lösung oder auch um kundenprozess- bzw. unternehmensspezifische Besonderheiten handeln.

75 Geschäftsarchitektur 61 5 Geschäftsarchitektur Im Rahmen der Geschäftsarchitektur werden strategische Komponenten wie z.b. Marktleistungen und Kooperationen gestaltet (s. Kapitel 4.1). Die folgenden Ausführungen geben einen Überblick über strategische Fragestellungen und Optionen für Prozessportal-Betreiber. Von grundlegender Bedeutung ist die Positionierung des eigenen Unternehmens im Wertschöpfungsnetzwerk (s. Kapitel 2.5.3). In der Sprache des in Kapitel 2.4 erläuterten Modells hat ein Unternehmen folgende Optionen: Es kann sich auf die Kundenbeziehung konzentrieren und als Prozessportal-Betreiber auftreten, es kann als Anbieter und Partner anderer Prozessportale eigene Produkte und Dienstleistungen vertreiben oder es kann als eservice-anbieter anderen Teilnehmern des Wertschöpfungsnetzwerkes standardisierte Leistungen anbieten. Die weiteren Ausführungen konzentrieren sich gemäss dem Fokus der vorliegenden Arbeit auf die strategischen Optionen eines Prozessportal-Betreibers. Dieser ist gleichzusetzen mit einem Relationship Manager (s. Kapitel 2.5.3) oder beschränkt auf das Web mit einem sogenannten Navigator [s. Evans/Wurster 2000]. Viele der in Kapitel 3.1 erläuterten Kriterien für den Betrieb eines Prozessportals sind strategische Massnahmen, welche die Gestaltung der im Folgenden beschriebenen strategischen Merkmale beeinflussen. Je nach Ausgangssituation des Unternehmens bestehen bezüglich der Erfüllung der einzelnen Massnahmen Vor- bzw. Nachteile. Ein Unternehmen, das keine eigenen Produkte oder Dienstleistungen anbietet, hat es i.d.r. leicht, eine glaubhafte Neutralität und Kundennähe zu erreichen. Möglicherweise hat es jedoch Schwierigkeiten, detaillierte Produktinformationen der verschiedenen Anbieter zu bekommen und kann nur auf wenige Kundendaten zugreifen. Hingegen kann beispielsweise eine etablierte Bank auf umfangreiche Kundendatenbestände und zumindest auf die eigenen Produktinformationen unbeschränkt zugreifen. Um eine Neutralität zu erreichen, muss sie jedoch meist aufwändige Massnahmen ergreifen wie z.b. die organisatorische und/oder rechtliche Trennung des Prozessportals von der Leistungserstellung oder die Kooperation mit direkten Konkurrenten. Für eine detaillierte Darstellung der verschiedenen Ausgangslagen und Konsequenzen sei auf [Evans/Wurster 2000, S.90] verwiesen. Ein Prozessportal-Betreiber muss definieren, welche Leistungen er am Markt anbietet. Im Sinne der Kundenprozessorientierung (vgl. Kapitel 2.3 und 3.1.1) stellt er sich dazu die Frage, welche(n) Kundenprozess(e) er unterstützen möchte [vgl. Fellenstein/Wood 2000, S.59ff.]. Geeignet sind in der Regel Prozesse, in denen er Prozesskompetenz besitzt oder leicht aufbauen kann. Für Banken eignen sich besonders Prozesse, in denen Finanzdienstleistungen eine zentrale Rolle spielen. Ausgehend vom Kundenprozess wird definiert, welche Einzelleistungen angeboten werden, welche davon selbst

76 62 Geschäftsarchitektur erbracht werden können (eigene Kernkompetenz) und welche von externen Partnern bezogen werden müssen. Bei der Abgrenzung des Leistungsangebotes ist wiederum von der Kundensicht auszugehen. Es sollten diejenigen Leistungen gebündelt werden, die aus Sicht des Kunden in engem Zusammenhang stehen [Evans/Wurster 2000, S.84]. Dazu ist es möglicherweise erforderlich, mit direkten Konkurrenten zu kooperieren (s.o.). Ein weiterer Aspekt ist der Markenname, unter dem der Betreiber auftritt [vgl. Hoque 2000, S.74ff.]. Kunden haben ein grösseres Vertrauen in Portale, die unter bekannten Namen betrieben werden (vgl. bekannte Namen einsetzen, Kapitel 3.1.3) [vgl. Fellenstein/Wood 2000, S.89f.]. Da die in Frage kommenden bekannten Namen (z.b. Credit Suisse bei yourhome.ch) häufig Leistungsersteller sind, steht diese Forderung oft in Konflikt mit der nach Neutralität (vgl. Neutralität, Kapitel 3.1.1). Im engen Zusammenhang mit dem Leistungsangebot steht auch die Definition der Zielgruppe. Diese hängt i.d.r. vom Kundenprozess ab, z.b. richtet sich der Kundenprozess Erbschaft und Bestattung (vgl. Kapitel 6.6) sicher vorwiegend an Personen im Rentenalter. Einen wichtigen Wettbewerbsfaktor stellt die Reichweite dar. Gerade durch den Einsatz des Webs als Vertriebskanal ist die potenzielle Reichweite um Grössenordnungen gestiegen. Ein Unternehmen, dem es gelingt, dieses Potenzial in eine tatsächliche Reichweite des eigenen Prozessportals umzusetzen, hat dadurch einen Wettbewerbsvorteil (vgl. Kritische Masse der Kunden, Kapitel 3.1.4) [Evans/Wurster 2000, S.83ff.]. Die angesprochenen Kunden sind normalerweise in Bezug auf ihre Bedürfnisse nicht homogen. Abhängig von Alter, Familiensituation, Vermögen, Einkommen, Wohnort, etc. haben sie unterschiedliche Anforderungen und sind auch für den Prozessportal- Betreiber unterschiedlich profitabel. Die Zielgruppe wird daher in einzelne Kundensegmente unterteilt, für die das angebotene Leistungsspektrum einzeln festgelegt wird. Für eine ausführliche Behandlung des Themas Kundensegmentierung und eine Darstellung der möglichen Kriterien sei auf [Gronover/Bach 2000] verwiesen. Die dritte Dimension neben Leistungen und Kunden bilden die Vertriebskanäle. Während der Kunde eine umfassende Unterstützung von Zugangsmedien fordert (vgl. Kapitel 3.1.2), muss das Unternehmen im Rahmen einer Kanalstrategie definieren, welche Vertriebskanäle zum Einsatz kommen. Dabei spielen die Anforderungen des Kundenprozesses (z.b. möchte ein Autofahrer, der gerade einen Umfall hatte, sicher am liebsten per Telefon Hilfe anfordern), die Eignung der Leistungen für bestimmte Kanäle und die Wirtschaftlichkeit des Einsatzes der einzelnen Kanäle eine Rolle. Im Rahmen der Kanalstrategie muss weiter festgelegt werden, wie die Vertriebskanäle gesteuert und koordiniert werden. [Holmsen et al. 1998] unterscheidet drei Varianten der Kanalsteuerung: Im koordinierten Kanalmodell gibt es eine zentrale Stelle, welche die Zuordnung von Kanälen, Produkten und Kundensegmenten vornimmt. Im ge-

77 Geschäftsarchitektur 63 steuerten Konkurrenzmodell werden an einer zentralen Stelle klare Verantwortlichkeiten und Richtlinien, insbesondere für einige kritische Produkt-Kanal-Zuordnungen, getroffen. Für die detaillierte Kanalsteuerung gibt es jedoch mehrere dezentrale verantwortliche Stellen. Im Modell der konkurrierenden Kanäle findet überhaupt keine zentrale Steuerung mehr statt. Es wird dezentral entschieden, welche Produkte über die einzelnen Kanäle angeboten werden und der Markt entscheidet über den Erfolg. Für eine detaillierte Beschreibung und Beurteilung dieser Varianten sei auf [Holmsen et al. 1998] verwiesen. Im koordinierten Kanalmodell muss schliesslich festgelegt werden, welche Leistungen welchen Kundensegmenten über welche Kanäle angeboten werden. Hier können z.b. Überlegungen eine Rolle spielen, dass profitablere Kunden auch Vertriebskanäle benutzen dürfen, die höhere Kosten verursachen. Eine detailliertere Darstellung von Aspekten der Kanalstrategie ist in [Schmid/Bach 2000a, S.27ff.] zu finden. Weiterführende Darstellungen zum Thema Multi Channel Management findet man z.b. in [Stäger 1999]. Da ein Prozessportal-Betreiber i.d.r. nicht alle Leistungen selbst erbringen kann, ist ein Kooperationskonzept erforderlich, in dem die Zusammenarbeit mit Partnern geregelt wird. Zur Kooperation kommen verschiedene Modelle oder Kombinationen daraus in Frage. Ein neutraler Prozessportal-Betreiber kann seinen Nutzern Zugang zu verschiedenen Anbietern verschaffen, ohne mit diesen direkt zu kooperieren. comparis.ch (s. Kapitel 3.1.1) z.b. vergleicht Krankenversicherungsprämien aller Anbieter unabhängig von deren Kooperationsbereitschaft. Die Informationsbeschaffung ist in diesem Fall möglicherweise schwierig, wird aber durch die Möglichkeiten des Internets erleichtert [Evans/Wurster 2000, S.89ff.]. Bindet man die Partner vertraglich ein, werden diese meist verpflichtet, Informationen bereitzustellen und Leistungen zu erbringen. Informationsfülle und Leistungsqualität können so leichter sichergestellt werden. Jedoch besteht die Gefahr, dass man durch die Auswahl der Partner die Neutralität verliert. In jedem Fall sind Exklusivverträge mit einzelnen Partnern zu vermeiden [Evans/Wurster 2000, S.90]. Weitere Kooperationsmöglichkeiten sind die Gründung eines Joint Ventures mit möglichen Partnern, die auch direkte Konkurrenten sein können (s.o.). Auch eine Fusion oder eine Übernahme sind mögliche Optionen. Eine detaillierte Behandlung von Aspekten des Partnermanagements findet man z.b. in [Friese 1998]. Bezieht ein Unternehmen Leistungen von Partnern, die es zu Leistungsbündeln kombiniert und den Kunden aus eigener Hand anbietet, bezeichnet man das Geschäftskonzept mit Syndication. Dies kommt besonders dann in Frage, wenn die Leistungen ausschliesslich aus Informationen bestehen, da sich diese im Gegensatz zu materiellen Gütern leicht verteilen und verarbeiten lassen [Werbach 2000].

78 64 Geschäftsarchitektur Ein weiteres wesentliches Element der Prozessportal-Strategie ist ein Ertragskonzept. Mögliche Einnahmequellen des Portals sind Werbeeinnahmen, Beiträge eingebundener Partner, Nutzungsgebühren der Portalkunden, Provisionen von Partnern für vermittelte Geschäfte und Einnahmen durch die eigene Erbringung kostenpflichtiger Leistungen [vgl. Hoffmann/Wolf 2000]. Je nach Gestaltung des Leistungssystems nehmen die einzelnen Ertragskomponenten unterschiedliche Gewichte ein. Weitere strategische Überlegungen betreffen z.b. die kommunikative Verankerung der Leistungen im Markt sowie Wachstumsstrategien. Eine abschliessende Behandlung strategischer Fragestellungen ist nicht das Ziel der vorliegenden Arbeit. Weiterführende Informationen zum Thema E-Business-Strategie findet man z.b. in [Hagel/Singer 1999; Kalakota/Robinson 1999; Fellenstein/Wood 2000; Harmon et al. 2000; Hoque 2000].

79 Prozessarchitektur 65 6 Prozessarchitektur Die in der Prozessarchitektur gestalteten Elemente sind die Prozesse, die zugehörigen Aufgaben und die von ihnen erbrachten Leistungen (s. Kapitel 4.1). Ausgangspunkt der Betrachtungen ist der Kundenprozess. Dieser beschreibt die Abläufe beim Kunden und bestimmt so, welche Leistungen er in seinem Prozess benötigt. Auf dieser Basis werden die Leistungen definiert, die das Prozessportal erbringen soll. Schliesslich werden die Prozesse des Portalbetreibers und die dazugehörigen Aufgaben entworfen, welche die definierten Leistungen erbringen (s. Abb. 6-1). 3. Marketing Portalbetreiber Verkauf Service 2. Leistungen Produktinformation 1. Kunde Kundenprozess Kampagne planen Kampagne durchführen Kampagne auswerten Kunden im Prozess führen Kundenbedarf analysieren Kunden beraten Produkt konfigurieren Angebot erstellen Vertrag abschliessen Kundenproblem lösen Beschwerde bearbeiten... Checkliste Beratung Vertrag... Informieren Evaluieren Kaufen Nutzen Verkaufen Abb. 6-1: Gestaltungselemente der Prozessarchitektur Im Folgenden wird eine generische Architektur beschrieben, die sich nicht an einem konkreten Kundenprozess orientiert. Die Basis bildet ein Katalog generischer Leistungen, aus denen konkrete Leistungen zur Unterstützung eines beliebigen Kundenprozesses konstruiert werden können. Als Kundenprozess können dabei sowohl konkrete Kundenprozesse eingesetzt werden (z.b. auf der Basis von Life-Events wie Heirat, Immobilienerwerb, Pensionierung etc.) als auch allgemeinere, die sich im Wesentlichen auf den Customer Buying Cycle reduzieren (s. Kapitel 6.3.1). So dient die beschriebene Architektur sowohl als Grundlage für eine Prozessportal-Architektur als auch für eine CRM-Architektur zur Unterstützung des klassischen produktorientierten Geschäfts. Grundlage für die Entwicklung der generischen Prozessarchitektur bildete die Analyse bestehender Prozessarchitekturen bei den Partnerunternehmen im CC BKM und CC CRM (s. Kapitel 1.3), namentlich bei der Credit Suisse und der Landesbank Baden- Württemberg. Die analysierte Prozessarchitektur der Credit Suisse ist als Fallbeispiel in Kapitel 6.1 dargestellt. Detaillierte Unterlagen über die analysierten Fälle liegen dem Autor vor, dürfen aber aus Gründen der Vertraulichkeit hier nicht wiedergegeben werden.

80 66 Prozessarchitektur Die Analyse bestehender Prozessarchitekturen führte im Wesentlichen zu den Kernleistungen (s. Kapitel 6.2) und den dazugehörigen Prozessen und Aufgaben. Weitere typische Leistungen (Zusatz- und Infrastrukturleistungen, s.u.) wurden durch die Analyse verschiedener bestehender (Prozess-)Portale u.a. yourhome.ch (s. Kapitel 3.2) bestimmt. Die analysierten Architekturen wurden in Workshops mit den Vertretern der Partnerunternehmen verallgemeinert und weiterentwickelt. Ausserdem flossen im Sinne des Action Research wesentliche Teile der verallgemeinerten Architektur in ein Praxisprojekt der AGI IT Services ein, wo sie konkreten Praxisanforderungen angepasst und verfeinert wurden. Die resultierenden Prozesse dienten wiederum zur Weiterentwicklung der generischen Prozessarchitektur. 6.1 Fallbeispiel: Customer Management Prozesse bei der Credit Suisse Dieses Beispiel wurde erstmals veröffentlicht in [Jaeger et al. 2000]. Es gibt einen Überblick über die CRM-Prozessarchitektur der Credit Suisse, die eine der Grundlagen für die in der vorliegenden Arbeit beschriebene generische Prozessarchitektur bildet. Das folgende Beispiel ist Bestandteil des Projektes Customer Management Processes and Systems (CM-PS). Dieses Projekt ist eine von mehreren parallel betriebenen CRM-Initiativen der Business Unit Credit Suisse, die den Retailbereich für den Schweizer Heimmarkt der Credit Suisse Group abdeckt. Ausgangspunkt für dieses Projekt war eine grundlegende Neuausrichtung der Credit Suisse: Finanzdienstleistungen sollen nicht mehr produktorientiert, sondern kundenorientiert angeboten werden. Jeder Kunde soll einen optimalen, auf seine individuellen Bedürfnisse zugeschnittenen Service erhalten. Im Rahmen dieser Neuausrichtung wurde unter anderem das Projekt CM-PS gestartet, dessen wesentliches Ziel es war, Front-End-Prozesse zur Abwicklung der Kundenkontakte zu definieren und ein Informationssystem zur Unterstützung dieser Prozesse zu evaluieren, zu beschaffen und zu integrieren. Die im Teilprojekt Customer Management Processes (CMP) definierten Prozesse werden im Folgenden näher beschrieben. Primäres Ziel des Teilprojekts CMP war die Entwicklung von effizienten Prozessen im Bereich Verkauf / Beratung auf der Basis der geschäftsstrategischen Stossrichtungen. Die Kernleistungen wurden entlang dem Kaufzyklus des Kunden und dem Verkaufszyklus der Bank identifiziert. Die Beziehungen der Sollprozesse wurden in Form einer Prozesslandkarte (s. Abb. 6-2) visualisiert und anschliessend auf Makroebene in 23 Prozessen von Vertretern aus dem Verkaufs- und Beratungsbereich in Zusammenarbeit mit Prozessspezialisten detailliert beschrieben. Die komplette Landkarte enthält neben den Verkaufs- und Bera-

81 Prozessarchitektur 67 tungsprozessen auch die Führungs- und Unterstützungsprozesse und die Beziehungen zu Kunden und Dritten. Kunde Kontaktierung Beratung/Abschluss Produktabwicklung Dritte Operations Kundenkontaktierung Basisprodukte Zahlungen Sparen Cash Service Basisversicherungen Vorsorge Investment / Treasury Konto/Depot Kreditkarten Dienstl. Cash Service Versicherungen Lebensversicherungen Kredite Privatkredite Leasing Krediteinheiten DLZ ZV Swisscard DLZ CIS Andere Business Units Anzeige Kundenpotenzial Kampagneninitialisierung Konsumfinanzierung Immobilienfinanzierung Kommerz. Finanzierung Spezialfinanzierung Produktnutzung Auskunft Produktinformationen Transaktionsinformationen Reklamationsauskunft etc. Kundenbenachrichtigung Anzeigen Belege Auszüge Warnungen Winterthur... Kampagnenauswertung Umfassende Finanzberatung Auftragsausführung Zahlungsaufträge Börsenaufträge Mutation/Storno Bestellungen (Prospekte, Formulare,...) Führungs -/Unterstützungsprozesse Marketing Services Loyalty Based Management Controlling Verkaufsführung Verkaufsunterstützung Personalausbildung Kundensegment-/ Kanalmanagement Produktmanagement Unternehmenskommunikation Economic Research IT-Unterstützung Abb. 6-2: Landkarte der Soll-Prozesse der Credit Suisse Die Tätigkeiten von der Kundenkontaktierung bis zur Nutzung der verkauften Produkte wurden in verschiedene Teilbereiche zerlegt: Die Kontaktierungsprozesse beschreiben den Anstoss zur aktiven Kontaktaufnahme zu bestehenden und potenziellen Kunden durch die Bank, die eigentliche Kontaktierung sowie das Anstossen der Beratungsprozesse. Die Kundenbedürfnisse (z.b. Zahlen und Sparen, Vermögensanlage und Vorsorge, Wohneigentum sowie Konsumfinanzierung für Privatkunden) bestimmen die Gliederung der Beratungsprozesse. Die Produktabwicklungsprozesse beschreiben die Bereit- und Zustellung der einzelnen Produkte an den Kunden. Während bei den Beratungsprozessen das Kundenbedürfnis im Zentrum steht, dominiert bei den Produktabwicklungsprozessen die Abwicklungseffizienz. Die Produktnutzungsprozesse zeigen die Tätigkeiten auf, welche sich aus der Nutzung der an den Kunden verkauften Produkte oder aus Anfragen ergeben.

82 68 Prozessarchitektur Da bei der Entwicklung der generischen Architektur eine einheitliche Terminologie bestimmt werden musste, unterscheiden sich die in diesem Beispiel verwendeten Prozessbezeichnungen von denjenigen der unten beschriebenen generischen Prozessarchitektur. Betrachtet man die Prozessinhalte, kann man folgende Zuordnung vornehmen: Der Kontaktierungsprozess der Credit Suisse entspricht dem Marketingprozess im generischen Prozessmodell. Die Beratungsprozesse der Credit Suisse können mit dem Verkaufsprozess gleichgesetzt werden. Je nach Kundenbedürfnis existiert der Prozess bei der Credit Suisse in verschiedenen Ausprägungen. Gemeinsam ist den Beratungsprozessen aber, dass der Vertragsabschluss das Ziel ist. Der Leistungserstellungsprozess wird bei der Credit Suisse durch die Produktabwicklungsprozesse abgedeckt. Diese gliedern sich wiederum in verschiedene Prozesse für die einzelnen Produkte. Der Produktnutzungsprozess der Credit Suisse mit Auskunft, Kundenbenachrichtigung und Auftragsausführung entspricht dem Serviceprozess. Die Prozesse Portalbetrieb und Kundenprozessunterstützung finden bei den Customer Management Prozessen der Credit Suisse keine Entsprechung, da sich die konzipierten Prozesse ausschliesslich auf den Verkauf von Bankprodukten beziehen. Es war nicht im Fokus des Projektes CM-PS, ein Prozessportal aufzubauen und damit Zusatz- oder Infrastrukturleistungen (s. Kapitel 6.2) zu erbringen. 6.2 Leistungen an den Kundenprozess Die Leistungen eines Prozessportals sind in der Regel auf konkrete Kundenprozesse ausgerichtet, sie lassen sich aber auf verallgemeinerte, kundenprozessunabhängige Leistungen zurückführen. So ist z.b. eine Checkliste für die Auswahl einer Immobilie eine konkrete Leistung für den Kundenprozess Immobilienerwerb, welche auf die verallgemeinerte Leistung Checkliste zurückgeführt werden kann. Auf Basis dieser allgemeinen Leistung können nun beliebige andere Checklisten konstruiert werden, z.b. eine Checkliste für die Autoauswahl, die den Kundenprozess Autobesitz unterstützt. Prinzipiell können die Leistungen über beliebige Vertriebskanäle (s. Kapitel 6.4) erbracht werden. Zum Beispiel kann eine Checkliste im Internet zur Verfügung stehen, vom Kundenberater auf Papier bereitgestellt werden oder per Faxabruf bezogen werden. Nicht alle Vertriebskanäle eignen sich jedoch für alle Leistungen, z.b. ist es nicht sehr sinnvoll, sich eine Checkliste am Telefon vorlesen zu lassen. Oft werden aus wirtschaftlichen Gründen viele Leistungen nur über kostengünstige Vertriebskanäle wie das Internet erbracht insbesondere Zusatzleistungen im Sinne einer Kundenprozessunterstützung, die nicht direkt zum Geschäftserfolg beitragen.

83 Prozessarchitektur 69 Die verschiedenen Leistungen unterscheiden sich in ihren Eigenschaften sehr stark. Beispielsweise ist es sehr viel komplexer, einen Online-Marktplatz zu realisieren, als im Prozessportal eine Checkliste bereitzustellen. Die unterschiedlichen Eigenschaften bei den einzelnen Leistungen führen zu uneinheitlichen Anforderungen an die Prozesse und Informationssysteme, welche die Leistungserbringung unterstützen. Zur Vereinfachung der weiteren Architekturbetrachtung werden die einzelnen Leistungen kategorisiert. Die einzelnen Kategorien können bestimmten Prozessen zugeordnet werden, die für ihre Erbringung verantwortlich sind (s. Kapitel 6.3.2). Ausserdem werden die einzelnen Leistungskategorien typischerweise in verschiedenen Projektphasen umgesetzt (s. Kapitel 6.5). Die einzelnen Leistungen werden zu bestimmten Kategorien einerseits anhand des Individualisierungsgrades der einzelnen Leistungen und andererseits durch eine Einteilung in Kernleistungen, Zusatzleistungen und Infrastrukturleistungen zugeordnet (s. Abb. 6-3). Bezüglich des Individualisierungsgrades wird unterschieden zwischen standardisierten Leistungen, die allen Kunden oder ganzen Kundensegmenten einheitlich zur Verfügung stehen, und individualisierten Leistungen, die inhaltlich auf die Bedürfnisse eines Einzelkunden ausgerichtet sind und somit für jeden Kunden individuell erbracht werden müssen. Zu den Kernleistungen zählen die Leistungen, die zur Kernkompetenz der Banken gehören. Dies sind Leistungen, die im Privatkundengeschäft der Banken traditionell erbracht werden unabhängig vom Betrieb eines Prozessportals oder von einer Ausrichtung auf Kundenprozesse. Zusatzleistungen sind Leistungen, die eine Bank im Rahmen eines Prozessportals anbietet, die aber nicht in den eigentlichen Kompetenzbereich der Bank fallen. Solche Leistungen werden häufig von externen Partnern bezogen. Stellt die Bank als Prozessportalbetreiber lediglich eine Plattform zur Verfügung, z.b. für einen Marktplatz, für Auktionen oder für ein schwarzes Brett im Internet, so zählen diese Leistungen zu den Infrastrukturleistungen. Die Inhalte dieser Plattformen kommen von den Nutzern, die Bank übernimmt höchstens die Moderation oder die Überwachung der Einhaltung bestimmter Regeln und inhaltlicher Kriterien. Die Bank muss nicht zwangsläufig alle Leistungen selbst erstellen. Insbesondere Zusatz- und Infrastrukturleistungen, die nicht in ihren Kernkompetenzbereich fallen, wird sie häufig von externen Partnern beziehen. Im Falle hoch standardisierter Leistungen wie z.b. Marktplatz, Auktion, Communities etc. können diese Partner e-service- Provider sein (s. Kapitel 2.4). E-Services sind aber nicht grundsätzlich mit den Leistungen an den Kundenprozess gleichzusetzen.

84 70 Prozessarchitektur Kernleistungen Zusatzleistungen Infrastrukturleistungen Marktplatz Auktion Inserate / schwarzes Brett Informationsaustausch zw. Kunden (Communities) Checkliste Kundenprozessspezifische Fachinformationen Verzeichnis externer Partner Produktinformationen von Drittanbietern Musterverträge, Musterdokumente Formulare Software zum Download Verweise, Links Kampagnenunabhängige Marketinginformationen Produktinformationen Bankprodukte Kampagnenspezifisches Werbematerial Verwahrung persönlicher Unterlagen Persönliche Einstellungen (pers. Homepage) Ereignisgesteuerte Benachrichtigung Beratung, individuelle Empfehlung Individuelle Berechnungen, Modellrechnungen Angebot Vertrag Allgemeine Auskunft Auftragsbestätigung Belege über in Anspruch genommene Dienstleistungen Standardisiert Individualisiert Abb. 6-3: Kategorisierung generischer Leistungen Die einzelnen generischen Leistungen werden im Folgenden näher beschrieben. Die Beschreibung jeder Leistung enthält einen Verweis auf den Prozess und die Aufgabe, welche die Leistung erbringen. Diese Angaben beziehen sich auf die Prozessbeschreibung in Kapitel Kernleistungen Die folgende Tabelle führt in verallgemeinerter Form die Kernleistungen auf, die eine Bank typischerweise erbringt. Die Kernleistungen sind beim klassischen produktorientierten Vertrieb identisch mit dem Betrieb eines Prozessportals. Die hier aufgeführten Leistungen abstrahieren sowohl vom konkreten Kundenprozess (s.o.) als auch vom einzelnen Bankprodukt. D.h. die eigentlichen Bankdienstleistungen wie z.b. Vermögensverwaltung oder Kontoführung werden hier nicht betrachtet [vgl. hierzu z.b. Polan 1995], ein Beispiel für eine typische hier betrachtete Leistung ist der Vertrag, der sich im konkreten Anwendungsfall sowohl auf eine Vermögensverwaltung als auch auf eine Kontoführung beziehen kann.

85 Prozessarchitektur 71 Standardisierte Leistung Kampagnenunabhängige Marketinginformationen Allgemeine Informationen zum Unternehmen, zu Produkt- und Dienstleistungsangebot, Kontaktinformationen, Geschäftsberichte etc., die z.b. auf der Unternehmenshomepage oder in Broschüren verfügbar sind. Produktinformationen Bankprodukte Detaillierte Informationen zu allen Produkten und Dienstleistungen der Bank, ggf. kunden(prozess)- spezifisch aufbereitet. Kampagnenspezifisches Werbematerial Konkrete Werbung für bestimmte Produkte oder Dienstleistungen, die dem Kunden im Rahmen von Marketingkampagnen übermittelt werden. Prozess / Aufgabe Marketing / Informationsbereitstellung Marketing / Informationsbereitstellung Marketing / Kampagnendurchführung Tabelle 6-1: Standardisierte Kernleistungen Individualisierte Leistung Beratung / individuelle Empfehlungen Auf den individuellen Kunden bezogene Beratungsleistungen und Empfehlungen bzgl. Produkten und Dienstleistungen der Bank, Ablauf des Kundenprozesses, Rechts- und Steuerfragen sowie spezifischen Fachfragen. Individuelle Berechnungen, Modellrechnungen Kundenspezifische Berechnungen, z.b. zu Finanzierungs-, Anlage und Steuerfragen Angebot Kundenindividuelles Angebot für bestimmte Produkte / Dienstleistungen Vertrag Vertrag über den Kauf bzw. die Nutzung von bestimmten Produkten/Dienstleistungen Allgemeine Auskunft Antwort auf eine Anfrage bestehender Kunden Auftragsbestätigung Bestätigung eines Nutzungsauftrages von einem bestehenden Kunden in Bezug auf eine von ihm genutzte Dienstleistung, z.b. Bestätigung eines Zah- Prozess / Aufgabe Verkauf / Beratungsempfehlung oder direkt durch Drittanbieter erbracht Verkauf / Beratungsempfehlung Verkauf / Individuelles Angebot erstellen oder direkt durch Drittanbieter erbracht Verkauf / Vertrag abschliessen oder direkt durch Drittanbieter erbracht Service / Auskunft erteilen Service / Kunden benachrichtigen

86 72 Prozessarchitektur Individualisierte Leistung lungsauftrages oder einer Wertpapierorder. Belege über in Anspruch genommene Dienstleistungen Kontoauszüge, Depotauszüge, Prozess / Aufgabe Service / Kunden benachrichtigen Tabelle 6-2: Individualisierte Kernleistungen Zusatzleistungen Zusatzleistungen fallen nicht in den klassischen Kompetenzbereich der Bank. Sie werden daher häufig von externen Partnern bezogen oder in Zusammenarbeit erbracht. Diese Partner können auch andere Bereiche des eigenen Konzerns sein. Die folgende Tabelle führt die Zusatzleistungen auf, die typischerweise im Rahmen eines Prozessportals erbracht werden müssen. Standardisierte Leistung Checkliste Informationen über den Ablauf des Kundenprozesses in Form einer Checkliste für den gesamten Prozess oder für einzelne Aufgaben. Kundenprozessspezifische Fachinformationen Auf den Kundenprozess bezogene Hintergrundinformationen, Fachinformationen, Erläuterungen, aktuelle Informationen (News): u.a. Rechtsinformationen, Finanzdaten, Marktinformationen, Verzeichnisse externer Partner Verzeichnisse von Drittanbietern, Amtsstellen etc. inkl. Beschreibung des Leistungsangebotes und Bewertung des Anbieters. Produktinformationen von Drittanbietern Informationen zu Produkten von Drittanbietern inkl. Produktvergleichen und -bewertungen. Musterverträge, Musterdokumente Beispiele und Vorlagen für Verträge und Dokumente, die der Kunde im Kundenprozess benötigt. Formulare Formulare, die der Kunde z.b. bei Amtsstellen benötigt inkl. Ausfüllhilfen bzw. Beispielen für ausgefüllte Formulare Prozess / Aufgabe Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen

87 Prozessarchitektur 73 Standardisierte Leistung Software zum Download Software, die den Kunden bei bestimmten Aufgaben im Kundenprozess unterstützt. Die Leistung besteht in der Bereitstellung der Software zum Download. Die Software selbst wird i.d.r. von externen Partnern bezogen. Verweise, Links Hinweise auf verwandte Informations- und Leistungsangebote, welche die Kundenprozessunterstützung ergänzen können. Prozess / Aufgabe Portalbetrieb / Portalinhalte bereitstellen Portalbetrieb / Portalinhalte bereitstellen Tabelle 6-3:Standardisierte Zusatzleistungen Individualisierte Leistung Prozess / Aufgabe Persönliche Einstellungen (pers. Homepage) Aufbereitung der Informationen im Internet gemäss kundenindividuellen Präferenzen. Auf Basis eines gespeicherten Kundenprofils wird i.d.r. eine persönliche Homepage zusammengestellt. Ereignisgesteuerte Benachrichtigung Mitteilungen an den Kunden, die durch bestimmte Ereignisse ausgelöst werden, z.b. bestimmte Termine, Kursentwicklungen, Verfügbarkeit von Produkten, rechtliche Änderungen, Tabelle 6-4: Individualisierte Zusatzleistungen Kundenprozessunterstützung / Persönliche Informationen bereitstellen Kundenprozessunterstützung / Kunden benachrichtigen Infrastrukturleistungen Bei Infrastrukturleistungen stellt die Bank lediglich eine Plattform i.d.r im Internet zur Verfügung. Die Inhalte der Plattform werden von den Nutzern erstellt, das können sowohl Kunden als auch andere Geschäftspartner der Bank sein. Die Bank übernimmt ggf. die Moderation der Plattform bzw. die Überwachung der Einhaltung bestimmter Regeln bezüglich der Inhalte. Die folgende Tabelle listet die Infrastrukturleistungen auf, die meist Bestandteil von Prozessportalen sind.

88 74 Prozessarchitektur Standardisierte Leistung Marktplatz In einem elektronischen Marktplatz bieten verschiedene Anbieter ihre Produkte und Dienstleistungen an. Der Kunde kann aus dem Angebot auswählen und über den Marktplatz direkt beim Anbieter bestellen. Im Gegensatz zum Produktkatalog nimmt die Bank keine inhaltliche Gestaltung oder Bewertung vor. Auktion Bei Auktionen bieten die Teilnehmer Produkte und Dienstleistungen an, wobei sich der Preis dynamisch durch die Gebote der Interessenten entwickelt. Jeder Nutzer der Plattform kann Anbieter werden, also sowohl Bankkunden als auch externe Partner. Inserate / schwarzes Brett Produkte und Dienstleistungen können in Form von Inseraten angeboten werden. Diese Plattform richtet sich in erster Linie an Kunden, die gebrauchte Produkte oder private Dienstleistungen anbieten wollen. Informationsaustausch zwischen Kunden (Communities) Medium zum synchronen oder asynchronen Informationsaustausch zwischen Kunden zu bestimmten, i.d.r. kundenprozessspezifischen Themen, z.b. Chatmöglichkeiten, Diskussionsforen etc. Prozess / Aufgabe Portalbetrieb / Portalinhalte pflegen Portalbetrieb / Portalinhalte pflegen Portalbetrieb / Portalinhalte pflegen Portalbetrieb / Portalinhalte pflegen Tabelle 6-5: Standardisierte Infrastruktur-Leistungen Individualisierte Leistung Persönliche Einstellungen und Unterlagen Kundenindividuelle Informationen und Dokumente, die der Bank im Rahmen der Kundenprozessunterstützung zur Verwahrung gegeben wurden. Prozess / Aufgabe Kundenprozessunterstützung / Persönliche Informationen bereitstellen Tabelle 6-6: Individualisierte Infrastruktur-Leistungen

89 Prozessarchitektur Prozesse des Prozessportalbetreibers Eine wesentliche Rolle beim Erbringen der Leistungen eines Prozessportals spielen die Customer Relationship Managementprozesse, da diesen sämtliche Kundenkontakte zugeordnet werden. Im folgenden Abschnitt werden diese Prozesse daher zunächst allgemein erläutert. Der Rest des Kapitels beschreibt typische Prozesse und Aufgaben für Banken im Privatkundengeschäft. Die Prozessarchitektur kann sowohl als Grundlage für den Betrieb eines Prozessportals als auch für ein Customer Relationship Management im klassischen Produktverkauf dienen Customer Relationship Managementprozesse Customer Relationship Management findet in den Prozessen Marketing, Verkauf und Service statt. In der Regel können alle Kundenkontakte unternehmensseitig einem dieser drei Prozesse zugeordnet werden [vgl. ECCS 2000]. Auf der Kundenseite ist jeder Kundenkontakt im Customer-Buying-Cycle einer der Phasen Anregung, Evaluation, Kauf und After-Sales zuzuordnen [s. Muther 1999, S.14ff]. Eine eindeutige Zuordnung dieser Phasen zu den Prozessen Marketing, Verkauf und Service ist nicht möglich. Im Wesentlichen wird der Kunde aber in der Anregungsphase durch den Marketingprozess bedient, die Kontakte während der Evaluationsphase und der Kaufphase finden im Verkaufsprozess statt, einen Teil der Kaufphase sowie die After-Sales-Phase deckt der Serviceprozess ab (s. Abb. 6-4). Einkauf Service After-Sales Anregung Marketing Kauf Evaluation Verkauf Leistungserstellung Qualitätsmanagement Produktentwicklung Abb. 6-4: Prozesse im Customer Relationship Management In einem vollständigen Kundenprozess wird der Customer-Buying-Cycle normalerweise mehrfach durchlaufen. Betrachtet man zum Beispiel den Kundenprozess Autobesitz, so durchläuft der Kunde einen Buying-Cycle beim eigentlichen Autokauf, weitere Buying-Cycles betreffen den Abschluss einer Haftpflichtversicherung, einer Finanzierung, den Kauf von Zubehör etc. Demzufolge werden auch in einem Prozess-

90 76 Prozessarchitektur portal, das einen vollständigen Kundenprozess unterstützt, die CRM-Prozesse Marketing, Verkauf und Service bzw. einzelne Aufgaben dieser Prozesse i.d.r. mehrfach durchgeführt. Prozesse wie z.b. Einkauf, Produktentwicklung, Qualitätsmanagement und Leistungserstellung sind im Zusammenhang mit Customer Relationship Management ebenfalls relevant. Hier finden zwar normalerweise keine direkten Kundenkontakte statt, ein Informationsaustausch mit den CRM-Prozessen ist jedoch unbedingt notwendig. So müssen zum Beispiel alle relevanten Produktinformationen aus der Produktentwicklung den Mitarbeitern in Marketing, Verkauf und Service zur Verfügung stehen. Umgekehrt müssen Beschwerden und Anregungen der Kunden aus dem Serviceprozess an die Produktentwicklung weitergeleitet werden. CRM- Prozesse Vertragsabschluss Zielgruppen Kontakt vorhanden Marketing Verkauf Service Markt Interessent Kunde Abb. 6-5: Abgrenzung der CRM-Prozesse Zur Abgrenzung der Prozesse Marketing, Verkauf und Service werden einerseits die Zielgruppen der Prozessaktivitäten und andererseits die Ereignisse Kundenkontakt und Vertragsabschluss betrachtet (s. Abb. 6-5), [vgl. Stender/Schulz-Klein 1998, S.11ff]. Der Marketingprozess 1 hat prinzipiell den gesamten Markt als Zielgruppe. In der Regel wird diese Zielgruppe anhand verschiedener Kriterien eingegrenzt, um einen Kreis potenzieller Kunden mit hoher Erfolgswahrscheinlichkeit anzusprechen. Für die Abgrenzung ist es irrelevant, ob ein breites Massenmarketing oder ein stark individualisiertes Marketing durchgeführt wird. Ziel des Marketingprozesses ist es in jedem Fall, beim potenziellen Kunden Interesse für ein bestimmtes Produkt zu wecken. Die Zielgruppe kann dabei durchaus bestehende Kunden umfassen, welchen ein zusätzliches Produkt angeboten wird. Marketingaktivitäten können auch allein auf die Bindung bestehender Kunden abzielen (sog. Kundenbindungsmarketing). Sobald ein Kunde in 1 Zum Begriff des Marketingprozesses s. Kapitel 2.1.2

91 Prozessarchitektur 77 einem individuellen Kontakt konkretes Interesse an dem angebotenen Produkt bekundet, geht der Marketingprozess in den Verkaufsprozess über. Der Verkaufsprozess umfasst alle Aktivitäten, die im Kontakt mit einem interessierten Kunden zu einem Vertragsabschluss führen sollen. Diese können zum Beispiel Beratungsgespräche oder die Bereitstellung von Informationsmaterial sein. Mit dem Vertragsabschluss endet der Verkaufsprozess. Es schliessen sich einerseits der Serviceprozess und andererseits der Prozess Leistungserstellung an. Die Leistungserstellung ist ein Back-Office-Prozess ohne direkten Kundenkontakt. Hier werden die vertraglich vereinbarten Leistungen erbracht und z.b. im Falle eines Bankkontos die Transaktionen abgewickelt. Alle weiteren Kundenkontakte finden im Serviceprozess statt, über den der Kunde Auskunft und Hilfestellung erhält, aber er kann beispielsweise auch Transaktionsaufträge erteilen. Aus dem Serviceprozess heraus kann ein Potenzial für den Verkauf eines weiteren Produktes entstehen, welches dann wiederum vom Marketing- oder Verkaufsprozess weiterverfolgt wird. Ein wesentlicher Bestandteil des Customer Relationship Managements ist die integrierte Betrachtung der Prozesse Marketing, Verkauf und Service. Damit das volle Potenzial von CRM ausgeschöpft werden kann, muss der Informationsfluss zwischen diesen Prozessen sichergestellt werden. In jedem dieser drei Prozesse müssen den Mitarbeitern alle relevanten Kundeninformationen zur Verfügung stehen Prozessmodell für Banken im Privatkundengeschäft Im Gegensatz zum klassischen Produktverkauf können beim Betrieb eines Prozessportals nicht mehr alle Leistungen den Prozessen Marketing, Verkauf und Service zugeordnet werden, sondern bezogen auf die Typisierung der Leistungen (s. Kapitel 6.2) lediglich die Kernleistungen. Für die Zusatzleistungen und für die Infrastrukturleistungen müssen weitere Prozesse eingeführt werden: Der Prozess Portalbetrieb erbringt die standardisierten Leistungen, der Prozess Kundenprozessunterstützung die individualisierten Leistungen (s. Abb. 6-6). Die Prozesse Marketing und Portalbetrieb sind bankgesteuert, während die Prozesse Verkauf, Service und Kundenprozessunterstützung kundengesteuert sind. Konkret bedeutet das Folgendes: Die Erbringung von standardisierten Leistungen in den Marketing- und Portalbetriebsprozessen ist unabhängig von Kundenkontakten. Die Bank bestimmt, wann und wie oft die Leistungen erbracht und damit die Prozesse durchlaufen werden. Beispielsweise werden Portalinhalte einmal bereitgestellt und sind dann für den Kunden verfügbar, wann immer er darauf zugreifen möchte. Auch Marketingkampagnen werden zu von der Bank bestimmten Zeitpunkten durchgeführt. Die individualisierten Leistungen hingegen werden explizit für bestimmte Kunden erbracht. Interesse und Anforderungen des Kunden bestimmen daher stark Zeitpunkt und Ablauf der

92 78 Prozessarchitektur zugehörigen Prozesse bei der Bank. Für den Verkaufsprozess z.b. ist ein konkretes Kaufinteresse eines Kunden notwendig. Die Bank weiss nicht, wann dieses eintritt und wie der Kunde im Verlauf des Prozesses auf Beratung und Produktempfehlungen reagiert. Auch in den Prozessen Service und Kundenprozessunterstützung bestimmt der Kunde, wann er eine Anfrage stellt, einen Auftrag erteilt oder eine Unterstützungsleistung in Anspruch nimmt. Kernleistungen Zusatzleistungen Infrastrukturleistungen Portalbetrieb Portalbetrieb Marketing Kundenprozessunterstützung Kundenprozessunterstützung Verkauf, Service Standardisiert Individualisiert Abb. 6-6: Zuordnung der Leistungstypen zu Prozessen Als Konsequenz aus diesem Sachverhalt können die Prozesse Marketing und Portalbetrieb gut standardisiert werden, sie müssen gegebenenfalls den Anforderungen konkreter Kundenprozesse oder -segmente angepasst werden, laufen dann aber jedes Mal weitgehend unverändert ab. Für die kundengesteuerten Prozesse hingegen können nur typische Standardabläufe angegeben werden, die in jedem Einzelfall abgewandelt werden. Die Prozesse werden im Folgenden in ihrer speziellen Ausprägung für das Privatkundengeschäft der Banken näher spezifiziert. Es handelt sich dabei um generalisierte Prozessmodelle, bei denen unternehmensindividuelle Besonderheiten nicht berücksichtigt sind. Der Detaillierungsgrad ist so gestaltet, dass eine unternehmensübergreifende Verallgemeinerung möglich ist.

93 Prozessarchitektur Prozesslandkarte Abb. 6-7 zeigt die Prozesslandkarte der Prozessarchitektur, bei der die spezifischen Anforderungen des Bankgeschäfts im Privatkundenbereich berücksichtigt sind. Die Notation folgt der Darstellungsweise in [Österle 1995, S. 61f.]. Enthalten sind die CRM-Kernprozesse Marketing, Verkauf und Service, die Portalprozesse Portalbetrieb und Kundenprozessunterstützung sowie weitere wichtige Prozesse der Bank und des Kunden, sofern diese direkt Leistungen mit den CRM-Prozessen oder mit den Portalprozessen austauschen. Auf der Bankseite sind dies Produktentwicklung, Führung und Leistungserstellung. Auf der Kundenseite sind die vier Phasen des Customer-Buying-Cycle (Anregung, Evaluation, Kauf, Nutzung) aufgeführt. Dabei ist zu beachten, dass der Customer-Buying-Cycle lediglich ein Ausschnitt aus dem gesamten, anwendungsspezifischen Kundenprozess ist. Die Pfeile zwischen den Prozessen bezeichnen die ausgetauschten Leistungen. Die einzelnen Prozesse und Leistungen werden in den folgenden Abschnitten näher spezifiziert. Zur Darstellung werden Aufgabenkettendiagramme verwendet [vgl. Österle 1995, S. 95f.]. Partner Bank Kunde Cross-Selling-Informationen Produktvorschlag, Kundenwunsch Produktentwicklung Leistungserstellung Portalinhalte Produktinformationen Kundenprozessunterstützung Strat. Vorgaben, Pläne, Berichte Führung Produktvorschlag Produktinformationen Strat. Vorgaben, Pläne, Berichte Strat. Vorgaben, Pläne, Berichte Anweisung zur Produktbereitstellung Auftrag, Beschwerde Benachrichtigung Persönl. Informationen, Dokumente Marketing Verkauf Service Leistungserstellung Kundeninformationen Produktinformationen Portalbetrieb Kundeninformationen Kundeninformationen Informationsmaterial Kampagnenreaktion Informationen, Beratungsempfehlungen, Angebot, Vertrag Kundeninformationen, Vertrag Anfrage, Nutzungsauftrag, Beschwerde Auskunft, Benachrichtigung Einstellungen, Persönl. Informationen, Dokumente Personalisierung, Benachrichtigung, Dokumente Anregung, Evaluation, Kauf Nutzung Kundenprozess Kundenprozessspezifische Portalinhalte Betrieb von Infrastrukturleistungen Prozess Leistung Abb. 6-7: Prozesslandkarte

94 80 Prozessarchitektur Marketingprozess Nach dem aufgabenorientierten Ansatz umfasst das Marketing die vier Kernaufgaben Kundenakquisition, Kundenbindung, Leistungsinnovation und Leistungspflege [vgl. Tomczak/Reinecke 1996]. Im Zusammenhang mit Customer Relationship Management sind davon die Kundenakquisition und die Kundenbindung relevant (vgl. Kapitel 2.1.2). In [Tomczak/Reinecke 1998, S.10] werden diese wie folgt definiert: Kundenakquisition: sämtliche Massnahmen, die dazu führen, dass ein Kunde erstmalig beim betreffenden Anbieter kauft. Kundenbindung: sämtliche Massnahmen, die zu kontinuierlichen oder vermehrten Wieder- und Folgekäufen führen bzw. verhindern, dass Kunden abwandern. Der im Folgenden beschriebene Marketingprozess im Sinnes des CRM unterstützt sowohl Kundenakquisition als auch Kundenbindung. Dazu stellt er einerseits allgemeine Informationen zu Produkten und Dienstleistungen sowie zum Unternehmen selbst bereit. Diese Informationsbereitstellung erfolgt über die Website des Unternehmens sowie über Broschüren, Inserate, Plakate, Radio- und Fernsehwerbung etc. Andererseits werden Marketing-Kampagnen durchgeführt, in denen bestimmte Adressaten gezielt angesprochen werden. Neben klassischen Mailingaktionen sind auch Kampagnen über andere Medien wie , Telefon, Websites, Inserate etc. möglich. Die Planung, Durchführung und Auswertung dieser Kampagnen sowie die Herstellung des Kontaktes zu potenziellen Kunden sind die zentralen Aufgaben des Marketingprozesses. Der Marketingprozess im vorliegenden Kontext deckt im Wesentlichen Aufgaben des Kampagnenmanagements im Sinne des Direktmarketings ab und repräsentiert somit nur einen kleinen Teil des gesamten Marketingaufgabengebietes. Der Marketingprozess richtet sich sowohl an potenzielle Neukunden (Kundenakquisition) als auch an bestehende Kunden, denen zusätzliche Produkte und Dienstleistungen angeboten werden (Kundenbindung, Cross-Selling ). Seltener dienen Kampagnen lediglich dazu, eine Abwanderung der Kunden zu verhindern, ohne dem Kunden zusätzliche Leistungen anzubieten. Nicht Bestandteil des hier beschriebenen Marketingprozesses sind Aufgaben, die zwar zum Marketingaufgabengebiet gehören, bei denen aber i.d.r. kein direkter Kundenkontakt stattfindet. Diese Aufgaben betreffen die Erstellung strategischer Vorgaben und die Konzeption neuer Produkte und Dienstleistungen, also hauptsächlich Leistungsinnovation und Leistungspflege. Einige dieser Aufgaben sind in den weiter unten beschriebenen Prozessen Führung und Produktentwicklung enthalten. Das Aufgabenkettendiagramm in Abb. 6-8 zeigt einen typischen Ablauf des Marketingprozesses. Die einzelnen Aufgaben und Leistungen werden in Anhang A.1 näher erläutert.

95 Prozessarchitektur 81 Bank Prozess Führung Bank Prozess Marketing Kundenkontaktierung Informationsbereitstellung Kunde Anregung, Evaluation, Kauf Pläne, Berichte bereitstellen Berichte auswerten Bank Prozess Produktentwicklung Produktvorschlag auswerten Kampagnenauswertung Kampagneninitialisierung Kampagnendurchführung Cross-Selling- u. Event-Auswertung Informieren über Produkte und Unternehmen Bank kontaktieren Produktinfos bereitstellen Bank Prozess Verkauf Vorbereitung auf Kundenberatung Abb. 6-8: Aufgabenkettendiagramm des Marketingprozesses Verkaufsprozess Der Verkaufsprozess beginnt mit der erfolgreichen Kundenkontaktierung und endet mit dem Vertragsabschluss im positiven Fall oder mit dem Abbruch der Verkaufsaktivitäten im negativen Fall. Die wesentliche Aufgabe ist die Kundenberatung mit dem Ziel, dem Kunden ein oder mehrere Produkte zu verkaufen. Nicht Bestandteil des Verkaufsprozesses im Sinne des Customer Relationship Managements ist die operative Abwicklung des Verkaufs wie z.b. Rechnungsstellung etc. Ein Prozessportal, das von einer Bank betrieben wird, greift in der Regel immer wieder auf den Verkaufsprozess oder auf einzelne Aufgaben des Verkaufsprozesses zu, um die Leistungen des Prozessportals zu erbringen. Im unten ausgeführten Beispiel des Prozessportals für Erbschaft und Bestattung dient z.b. die Aufgabe Kundenbedarf analysieren zur Ermittlung der Vermögenssituation des Erblassers, der Verkaufsprozess wird aber auch bei der Anlage eines ererbten Vermögens durch den Erben wieder durchlaufen. Im Rahmen eines Prozessportals erbringt der Verkaufsprozess die individualisierten Kernleistungen. Insbesondere die Beratungsleistung geht hier über eine reine Produktberatung hinaus und richtet sich auf den Kundenprozess aus. Befindet sich der Kunde beispielsweise im Kundenprozess Immobilienerwerb, so bezieht sich die Beratung nicht nur auf die Konditionen verschiedener Hypothekarmodelle, sondern sie berück-

96 82 Prozessarchitektur sichtigt die gesamte Kundensituation und kümmert sich z.b. auch um Fragen der Standortwahl oder der Objektsuche. Das Aufgabenkettendiagramm in Abb. 6-9 zeigt einen typischen Ablauf des Verkaufsprozesses. Die einzelnen Aufgaben und Leistungen werden in Anhang A.2 näher erläutert. Beim Verkaufsprozess handelt es sich um einen schwach strukturierten Prozess. Die einzelnen Aufgaben laufen meist nicht exakt in der hier dargestellten Reihenfolge ab und sind auch nicht immer klar voneinander abgrenzbar. Grundsätzlich sind Überlappungen sowie Rücksprünge jederzeit möglich und zulässig. Dies ist abhängig vom Kundenprozess und vom individuellen Kundenverhalten. Abb. 6-9 stellt eine typische, generalisierte Ausprägung des Prozesses dar. Bank Prozess Marketing Beratungsempfehlung Kundenkontaktierung Bank Prozess Führung Pläne, Berichte bereitstellen Berichte auswerten Bank Prozess Leistungserstellung Bank Prozess Verkauf Vorbereitung auf Kundenberatung Kundenbedarf analysieren Produkte präsentieren Individuelles Angebot erstellen Konditionen vereinbaren Kunde Anregung, Evaluation, Kauf Bank kontaktieren Beraten lassen Kunde Entscheiden Konditionen vereinbaren Produkt bereitstellen Vertrag abschliessen Vertrag abschliessen Nachbearbeitung u. Datenpflege Abb. 6-9: Aufgabenkettendiagramm des Verkaufsprozesses Serviceprozess Der Serviceprozess deckt sämtliche Kontakte zu bestehenden Kunden in Bezug auf einen abgeschlossenen Vertrag ab. Werden hingegen einem bestehenden Kunden im Sinne des Cross-Selling zusätzliche Produkte verkauft, so decken die Prozesse Marketing und Verkauf diesen Vorgang ab. Im Serviceprozess werden grob zwei Fälle unterschieden. Einerseits dient er dazu, allgemeine Anfragen und Beschwerden zu bearbeiten, andererseits ist der Serviceprozess auch für die Entgegennahme von Nutzungsaufträgen (z.b. Überweisungsaufträgen

97 Prozessarchitektur 83 oder Wertpapierorders) und für die Weiterleitung von Benachrichtigungen (z.b. Kontoauszügen) an den Kunden zuständig. Bank Prozess Produktentwicklung Produktvorschlag auswerten Bank Prozess Führung Berichte auswerten Beschwerde bearbeiten Beschwerden auswerten Bank Prozess Service Anfrage entgegennehmen P Auskunft erteilen/ Servicetätigkeit durchführen Kunde Nutzung Anfrage stellen / beschweren Auskunft entgegennehmen Bank Prozess Leistungserstellung Auftrag ausführen Benachrichtigung erstellen Auftrag entgegennehmen Auftragsausführung auslösen Benachrichtigung entgegennehmen Kunden benachrichtigen Nutzungsauftrag erteilen Benachrichtigung entgegennehmen Abb. 6-10: Aufgabenkettendiagramm des Serviceprozesses Das Aufgabenkettendiagramm in Abb zeigt typische Abläufe im Serviceprozess. Detailliert werden die Aufgaben in Anhang A.3 beschrieben Kundenprozessunterstützungs-Prozess Der Prozess Kundenprozessunterstützung erbringt die individualisierten Zusatz- und Infrastrukturleistungen im Rahmen eines Prozessportals. Im Wesentlichen ist er dafür zuständig, kundenspezifische Informationen entgegenzunehmen, abzulegen und wieder bereitzustellen. Dabei handelt es sich einerseits um Kundenprofile, die zur Personalisierung des Leistungsangebotes in Form einer persönlichen Homepage dienen, und andererseits um Informationen und Dokumente, die der Kunde der Bank im Rahmen der Kundenprozessunterstützung zur Verwahrung gibt. Schliesslich ist der Prozess dafür verantwortlich, den Kunden bei bestimmten Ereignissen (Termine, Kursschwankungen etc.) zu benachrichtigen. Das Aufgabenkettendiagramm in Abb zeigt den Ablauf des Prozesses Kundenprozessunterstützung in generischer Form. Die einzelnen Aufgaben werden normalerweise mehrfach und in verschiedenen Reihenfolgen durchlaufen. Eine detaillierte Aufgabenbeschreibung findet sich in Anhang A.4.

98 84 Prozessarchitektur Bank Bank Kunde Prozess Leistungserstellung Produkt bereitstellen Prozess Kundenprozessunterstützung Präferenzen u. Dokumente speichern Persönliche Informationen bereitstellen Kundenprozess Präferenzen u. Dokumente übermitteln Persönl. Homepage abrufen Persönl. Homepage nutzen Regelmässig Ereignisse prüfen Kunden benachrichtigen Benachrichtigung entgegennehmen Abb. 6-11: Aufgabenkettendiagramm des Kundenprozessunterstützungs-Prozesses Portalbetriebsprozess Der Portalbetriebsprozess erbringt die standardisierten Zusatz- und Infrastrukturleistungen. Die Aufgaben umfassen im Wesentlichen die Erstellung der kundenprozessspezifischen Portalinhalte sowie die Bereitstellung und Moderation von Kommunikationsplattformen im Portal wie z.b. Diskussionsforen, Online-Auktionen etc. Eine weitere Aufgabe ist die Koordination der Inhaltserstellung durch die externen Partner. Das Aufgabenkettendiagramm in Abb zeigt einen groben Ablauf des Prozesses Portalbetrieb. Der Prozess ist lediglich für die inhaltliche Erstellung, Pflege und Koordination der Portalinhalte zuständig. Für die verschiedenen administrativen Aufgaben, die im Rahmen von Erstellung, Verteilung, Pflege und Entfernung der Portalinhalte anfallen, sind die Content Management Prozesse zuständig (s. Kapitel 6.3.3). Die einzelnen Aufgaben des Portalbetriebsprozesses werden in Anhang A.5 näher beschrieben.

99 Prozessarchitektur 85 Bank Prozess Produktentwicklung Bank Prozess Portalbetrieb Kunde Kundenprozess Produktinfos bereitstellen Interne Erstellungsmöglichkeit prüfen Portalinhalte extern beschaffen Portalinhalte erstellen Partner Prozess Leistungserstellung Portalinhalte erstellen Portalinhalte bereitstellen Portal nutzen Portalinhalte pflegen Portalinhalte pflegen Abb. 6-12: Aufgabenkettendiagramm des Portalbetriebsprozesses Produktentwicklungsprozess Im Produktentwicklungsprozess finden keine direkten Kundenkontakte statt. Ausnahmen sind mögliche Marktbefragungen oder Pretests für neue Produkte. Bank Prozess Service Bank Prozess Produktentwicklung Bank Prozess Marketing Beschwerde bearbeiten Produktvorschlag auswerten Bank Prozess Führung Pläne, Berichte bereitstellen Produkt spezifizieren Pretest durchführen Vermarktung planen Controlling planen Kampagneninitialisierung Kampagnenauswertung Informationsbereitstellung Bank Prozess Portalbetrieb Berichte auswerten Produktinfos bereitstellen Interne Erstellungsmöglichkeit prüfen Abb. 6-13: Aufgabenkettendiagramm des Produktentwicklungsprozesses

100 86 Prozessarchitektur Der Produktentwicklungsprozess zählt also nicht zu den CRM-Kernprozessen, steht damit aber in engem Zusammenhang. Ersichtlich ist dies vor allem daran, dass in den CRM-Prozessen umfassende Produktinformationen erforderlich sind und andererseits aus den CRM-Prozessen heraus Anforderungen an die Produktentwicklung entstehen können. Im Sinne einer ganzheitlichen Kundenprozessunterstützung beschränkt sich die Produktentwicklung nicht auf klassische Bankprodukte, sondern entwickelt auch Informationsmaterial und andere Leistungen für Prozessportale. Das Aufgabenkettendiagramm in Abb zeigt einen typischen Ablauf des Produktentwicklungsprozesses. Die einzelnen Aufgaben und Leistungen werden in Anhang A.6 näher erläutert Leistungserstellungsprozess Der Leistungserstellungsprozess ist für die initiale Produktbereitstellung nach Vertragsabschluss sowie für die Auftragsausführung während der Produktnutzung und für die zugehörige Kundenbenachrichtigung zuständig. Die Kundenkontakte werden über die CRM-Prozesse vor allem über den Serviceprozess sowie über den Prozess Kundenprozessunterstützung abgewickelt. Bank Prozess Verkauf Vertrag abschliessen Bank Prozess Leistungserstellung Produkt bereitstellen Bank Prozess Kundenprozessunterstützung Präferenzen u. Dokumente speichern Bank Prozess Service Auftrag ausführen Auftragsausführung auslösen Benachrichtigung erstellen Benachrichtigung entgegennehmen Abb. 6-14: Aufgabenkettendiagramm des Leistungserstellungsprozesses Das Aufgabenkettendiagramm in Abb zeigt einen typischen Ablauf des Leistungserstellungsprozesses. Die einzelnen Aufgaben und Leistungen werden in Anhang A.7 näher erläutert Führungsprozess Der Führungsprozess umfasst die Erstellung übergeordneter, produktübergreifender Vorgaben und die Auswertung der Erfolgszahlen. Mit Ausnahme allfälliger Marktanalysen finden im Führungsprozess keine Kundenkontakte statt. Die Leistungen des Füh-

101 Prozessarchitektur 87 rungsprozesses bilden die Vorgaben und Rahmenbedingungen für alle anderen hier beschriebenen Prozesse. Bank Prozess Service Beschwerden auswerten Bank Prozess Produktentwicklung Bank Prozess Führung Vision, Strategie, Ziele vorgeben Budgetierung durchführen Marktanalyse durchführen Absatzplanung durchführen Bank Prozess Marketing Nachbearbeitung Kampagnenauswertung Bank Prozess Verkauf Produktvorschlag auswerten Pläne, Berichte bereitstellen Vorbereitung auf Kundenberatung Produktinfos bereitstellen Berichte auswerten Kampagneninitialisierung Abb. 6-15: Aufgabenkettendiagramm des Führungsprozesses Das Aufgabenkettendiagramm in Abb zeigt einen typischen Ablauf des Führungsprozesses. Die einzelnen Aufgaben und Leistungen werden in Anhang A.8 näher erläutert Unterstützungsprozesse Im Zusammenhang mit den oben beschriebenen Geschäftsprozessen sind eine Vielzahl von Unterstützungsprozessen erforderlich (s. Kapitel 4.2). Dazu gehören viele Prozesse, die in Unternehmen bereits vorhanden sind und die im Zusammenhang mit Customer Relationship Management nicht umgestaltet werden müssen, z.b. Personalmanagement, Economic Research, Controlling oder IT-Betrieb. Eine vollständige und detaillierte Darstellung der Unterstützungsprozesse ist nicht Bestandteil der vorliegenden Arbeit. Um dennoch einen Überblick zu geben, beschreibt die folgende Aufstellung die im Zusammenhang mit CRM wichtigsten Unterstützungsprozesse: Verkaufsunterstützung Die Verkaufsunterstützung ist zuständig für verschiedene administrative Tätigkeiten der Verkaufsmitarbeiter. Dazu gehören z.b. die Spesenabrechnung, die Verwaltung von Terminen und Aktivitäten, die Zuordnung von Verkaufsgebieten zu Aussendienst-Mitarbeitern etc.

102 88 Prozessarchitektur Content Management Überall in den Geschäftsprozessen werden Inhalte konsumiert und produziert. Dazu gehören z.b. Abwicklungs- oder Fachinformationen für den Kundenberater genauso wie Produktinformationen, die dem Kunden über ein Portal zur Verfügung gestellt werden. Für Bereitstellung, Verteilung und Entfernung der Inhalte sind die Content Management-Prozesse verantwortlich. Sie garantieren so die Aktualität und die Konsistenz aller verfügbaren Informationen [vgl. Schmid et al. 1999; Kaiser 2000, S.139ff.; Christ 2001]. Die Content Management-Prozesse sind auch erforderlich, damit die Kundenanforderung der einheitlichen Bedienung erfüllt werden kann (vgl. Volle Integration der Partnerleistungen und Trennung von Inhalt und Layout, Kapitel 3.1.1). Kundensegmentmanagement Die Aufteilung des Gesamtmarktes in möglichst homogene Kundensegmente ist Voraussetzung für Kampagnenmanagement, Produktentwicklung, Personalisierung von Portalinhalten und andere Aufgaben in verschiedenen Geschäftsprozessen. Zur Segmentierung stehen verschiedene Kriterien zur Verfügung [Gabler 1997, Stichwort Marktsegmentierung; Nitsche 1998, S.19f.]. Meist werden demographische und sozio-ökonomische Kriterien verwendet [Nitsche 1998, S.40], die sich jedoch aufgrund veränderter Gegebenheiten (s. Kapitel 2.5) mehr und mehr als ungeeignet erweisen [Grebe/Kreuzer 1997] und um neuere Ansätze wie die Segmentierung nach Loyalität und Rentabilität [Bernet 1998, S.26ff.] ergänzt werden müssen. Eine weitere Herausforderung ist die Bestimmung der vorteilhaftesten Grösse der Kundensegmente [s. Wayland/Cole 1997, S.132ff.]. Das Kundensegmentmanagement ist ein kontinuierlicher Prozess, der die Segmentierung regelmässig überprüft und neuen Gegebenheiten anpasst [vgl. Schmid et al. 2000b]. Für eine ausführlichere Darstellung dieses Themengebietes sei auf [Schmid et al. 2000a, S.34ff.] verwiesen. Kanalmanagement Durch die Etablierung neuer, meist elektronischer Vertriebskanäle (vgl. Kapitel 6.4) ist die Koordination der einzelnen Vertriebskanäle zu einer komplexen Managementaufgabe geworden. Das Kanalmanagement hat die Aufgabe, für die Konsumenten denjenigen Absatzmix, d.h. die optimale Allokation der Produkte und Kanäle, bereitzustellen, der von den Kunden gewünscht wird, gleichzeitig aber die Kostenstruktur der Bank so wenig wie nötig belastet [Stäger 1999, S.11f.]. Um diese Aufgabe zu erfüllen, muss der Einsatz der Kanäle gesteuert werden. Die Steuerung kann entweder zentral oder dezentral erfolgen (s. Kapitel 5). Schliesslich muss durch organisatorische und durch technische Massnahmen sichergestellt werden, dass sowohl der Kunde über alle Kanäle eine einheitliche Sicht auf die Bank hat, als auch die Bankmitarbeiter über alle Kanäle eine einheitliche Sicht auf den

103 Prozessarchitektur 89 Kunden haben. Für eine ausführlichere Darstellung dieses Themengebietes sei auf [Schmid et al. 2000a, S.41ff.] verwiesen. Data Mining Der Data Mining-Prozess wertet grosse Datenbestände, die meist in einem Data Warehouse vorliegen, nach bestimmten Kriterien aus. In den operativen Datenbeständen vorhandene Informationen werden so für die verschiedenen Geschäftsprozesse nutzbar gemacht. Das Data Mining kann z.b. die Grundlage bilden für das Kampagnenmanagement und für die Kundensegmentierung [vgl. Berson/Smith 1997]. 6.4 Vertriebskanäle Viele Aspekte der Aufbauorganisation sind stark von den individuellen Gegebenheiten des einzelnen Unternehmens abhängig und werden daher in der vorliegenden Arbeit nicht näher betrachtet. Von besonderer Bedeutung sind aber Betrieb und Koordination verschiedener Vertriebskanäle: Je nach Anzahl und Art der eingesetzten Kanäle muss die Prozessarchitektur den spezifischen Anforderungen angepasst werden und auch die IS-Architektur (s. Kapitel 7) wird von den Vertriebskanälen beeinflusst. Viele Funktionen sind vollkommen unabhängig von den eingesetzten Vertriebskanälen während andere nur für bestimmte Kanäle relevant sind. Im Folgenden werden die verschiedenen, für Banken relevanten Vertriebskanäle näher erläutert. Dabei erfolgt eine Unterscheidung zwischen den vier Kanaltypen Mensch-Mensch, Mensch-Maschine, Maschine-Maschine und Mehrstufen-Kanäle [vgl. Stäger 1999; Schmid/Bach 2000a, S.47ff.]. Diese vier Kanaltypen wurden gewählt, da sie sich in ihren Anforderungen an die unterstützenden Informationssysteme stark unterscheiden (s. Kapitel 7). Die relevanten Vertriebskanäle wurden durch Befragung von Experten bei verschiedenen Banken ermittelt [Schmid et al. 2000b, S.20ff.]. Bei Mensch-Mensch-Kanälen kommuniziert der Kunde persönlich mit Vertretern des Unternehmens. Dazu zählen die folgenden Vertriebskanäle: Filiale Die Bankfiliale ermöglicht dem Kunden den persönlichen Kontakt zu seiner Bank. Während Standardtransaktionen zunehmend über andere Kanäle statt am Bankschalter abgewickelt werden, spezialisiert sich die Filiale immer mehr auf Beratungsleistungen. Neben dem persönlichen Besuch hat der Kunde prinzipiell auch die Möglichkeit, per Brief, Fax, Telefon oder mit der Filiale in Kontakt zu treten. Aussendienst Der mobile Aussendienst ist vorwiegend im Firmenkundengeschäft und im Private

104 90 Prozessarchitektur Banking anzutreffen, vermehrt aber auch im Retail Banking [vgl. Klimpke 1998; vgl. Schmid et al. 2000b]. Auch hier ist ein persönlicher Kontakt des Kunden zu seiner Bank vorhanden. Den Aussendienstmitarbeiter kann der Kunde möglicherweise auch über Telefon oder kontaktieren. Contact Center Ein Contact Center kann der Kunde in der Regel per Telefon erreichen. Ist dies die einzige Möglichkeit, so handelt es sich um ein Call Center. Häufig werden in einem Contact Center auch eingehende Briefe, Faxe und s bearbeitet. Charakteristisch für ein Contact Center ist, dass es nur an einem oder an wenigen zentralen Orten angesiedelt ist und von dort aus eine grosse Zahl von Kunden bedient. Der Kunde kann ein Contact Center nicht wie eine Filiale physisch besuchen. Unterscheidungsmerkmale verschiedener Contact Center sind die Verfügbarkeit (z.b. 7x24h oder zu Bürozeiten), die Erreichbarkeit (mit welcher Wahrscheinlichkeit ist besetzt, wenn der Kunde anruft) und das Leistungsspektrum, das über Telefon angeboten wird. Mensch-Maschine-Kanäle zeichnen sich dadurch aus, dass der Kunde manuell auf eine elektronische Schnittstelle der Bank zugreift. Dazu gehören die folgenden Vertriebskanäle: Web Beim Online-Banking greift der Kunde heute in der Regel über das World Wide Web (WWW) auf die Banksysteme zu, um bestimmte Transaktionen durchzuführen. Der Kunde kann dabei den Web Browser auf seinem stationären PC oder Notebook verwenden, oder z.b. mittels WAP (Wireless Application Protocol) von seinem Mobiltelefon aus die Verbindung herstellen [vgl. Lerner/Diederich 2000]. Proprietäres Electronic Banking Der Vorläufer des Internet-Banking über WWW waren verschiedene proprietäre Lösungen für electronic Banking. Der Kunde greift dabei mit seinem PC entweder über ein Netz wie T-Online in Deutschland oder per Modem direkt auf den Server der Bank zu. Sind bankseitig der Server für das Electronic Banking und der Server für Internet-Banking integriert, so handelt es sich dabei nur um einen Vertriebskanal. Selbstbedienung Als erste Selbstbedienungslösung im Bankenbereich haben sich die Geldausgabeautomaten (ATM) durchgesetzt. Der Kunde kann dort unabhängig von Schalteröffnungszeiten Bargeld beziehen. Diese Automaten wurden teilweise zu multifunktionalen Kundenterminals erweitert, an denen auch z.b. Überweisungen getätigt und Kontostände abgefragt werden können [s. z.b. Walter/Disterer 2000]. Während die Geldausgabeautomaten ursprünglich vorwiegend in den Bankfilialen selbst zu finden waren, werden sie heute immer mehr an anderen Orten wie z.b. Bahnhöfen

105 Prozessarchitektur 91 oder Einkaufszentren platziert. Der Kunde hat so die Möglichkeit, das Geld dort zu beziehen, wo er es braucht. Eine weitere Möglichkeit der Selbstbedienung sind Kassenterminals (POS), die es dem Kunden erlauben, direkt an der Kasse im Geschäft mit seiner Kreditkarte, Debitkarte oder elektronischen Geldbörse zu bezahlen, ohne dazu Bargeld oder Schecks zu benötigen. Der Kunde spart sich dadurch den Vorgang des Bargeldbezuges, dem Verkäufer wird die Kassenabrechnung erleichtert, da er weniger Bargeldbestände verwalten muss. Durch internationale Netzwerke kann man viele Karten heute weltweit an POS-Kassen einsetzen. Bei Maschine-Maschine-Kanälen greift die Software des Kunden direkt auf die Software des Unternehmens zu. Während man diese Form der direkten Anbindung im Business-to-Business-Bereich häufig findet, ist sie im Privatkundengeschäft eher die Ausnahme. Ein Beispiel ist der Einsatz von Homebanking-Software, die Kontoauszüge, Zahlungsaufträge etc. automatisch mit dem Electronic Banking-Server der Bank austauscht. Bei Mehrstufen-Kanälen sind zwischen dem Kunden und der Bank ein oder mehrere Intermediäre (Vertriebspartner) vorhanden. Als Beispiel seien Fond-Shops genannt, welche die Investmentfonds verschiedener Banken vertreiben. Auf jeder einzelnen Stufe kann wiederum über beliebige andere Vertriebskanäle kommuniziert werden. 6.5 Gestaltungsdeterminanten Die in Kapitel 6.3 beschriebenen Prozesse sind soweit generalisiert, dass sie unabhängig von unternehmens- oder projektspezifischen Gegebenheiten sind. In einem konkreten Anwendungsfall können diese Prozessmodelle als Basis verwendet und den individuellen Gegebenheiten angepasst werden. In der Regel wird eine Bank nicht sämtliche neuen Vertriebskanäle und Leistungen gleichzeitig einführen und demzufolge auch nicht das vollständige Prozessmodell in einem einzelnen Projekt umsetzen. Die folgenden Ausführungen beschreiben einen Vorschlag, in welche einzelne Projektszenarien das Gesamtvorhaben zerlegt werden kann, um so zu einem schrittweisen Vorgehen und zu überschaubaren Teilprojekten zu gelangen. Dieser Vorschlag ist nicht als Methodenvorschlag im Sinnes des Methoden-Engineerings [Gutzwiller 1994, S.12-14] zu verstehen, sondern als Hilfestellung bei der Anwendung der generischen Prozessarchitektur in Praxisprojekten. Als Parameter zur Charakterisierung der einzelnen Projektszenarien dienen einerseits die in Kapitel 6.2 definierten Leistungskategorien und andererseits die in Kapitel 6.4 beschriebenen Vertriebskanäle. Bei den Leistungen werden Kernleistungen, Zusatzleistungen und Infrastrukturleistungen unterschieden, welche die Bank jeweils standardisiert oder individualisiert erbringt (s. Kapitel 6.2). Bei den Vertriebskanälen wird die Kategorisierung aus Kapitel 6.4 mit leichten Anpassungen verwendet: Die Mensch-Mensch-Kanäle werden unterteilt in die klassischen und die neuen Mensch-

106 92 Prozessarchitektur Mensch-Kanäle. Die klassischen Mensch-Mensch-Kanäle umfassen die ehemals einzigen Kanäle etablierter Banken. In der Regel ist das die Filiale, im Privatkundengeschäft teilweise auch der mobile Aussendienst. Die neuen Mensch-Mensch-Kanäle setzen moderne Informationstechnologien ein, um die persönliche Kommunikation zu unterstützen. Am weitesten verbreitet sind dabei Call Center bzw. Contact Center. Die Mensch-Maschine-Kanäle werden unverändert übernommen. Bei ihnen greift der Kunde direkt auf elektronische Schnittstellen der Bank wie z.b. das World Wide Web oder Selbstbedienungsautomaten zu. Maschine-Maschine-Kanäle werden in den Projektszenarien nicht berücksichtigt, da sie im Privatkundengeschäft der Banken nur eine untergeordnete Rolle spielen (s. Kapitel 6.4). Die folgende Beschreibung der Gestaltungsdeterminanten orientiert sich an einer typischen Entwicklung der meisten etablierten Banken: Den Ausgangspunkt bildet ein Angebot standardisierter und individualisierter Kernleistungen über die klassischen Mensch-Mensch-Kanäle, meist die Filiale. In einem ersten Entwicklungsschritt werden neue Mensch-Mensch-Kanäle und Mensch-Maschine-Kanäle erschlossen, über die ebenfalls Kernleistungen erbracht werden. Dazu gehören vor allem die Einrichtung eines Contact Centers sowie die Nutzung des Webs zunächst für Marketingzwecke, später auch für Verkauf, Abwicklung und Service. Diesen Entwicklungsschritt haben die meisten Banken bereits vollzogen [vgl. Schmid et al. 2000b]. Der nächste Schritt besteht typischerweise im Angebot von standardisierten Zusatzleistungen (z.b. Checklisten, Anbieterverzeichnisse etc.), die aus Kosten- und Effizienzgründen vorwiegend über Mensch-Maschine-Kanäle erbracht werden. Ein Contact Center kann unterstützend zum Einsatz kommen. Ergänzt werden diese Leistungen als nächstes um standardisierte Infrastrukturleistungen über Mensch- Maschine-Kanäle (z.b. Diskussionsforen, Marktplätze etc.), um den Kunden ein höheres Mass an Interaktivität zu bieten und damit auch eine bessere Kundenbindung zu erreichen. In einem (vorläufig) letzten Entwicklungsschritt werden die standardisierten Leistungen um individualisierte Zusatz- und Infrastrukturleistungen erweitert (z.b. Personalisierung, Verwahrung persönliche Unterlagen etc.). Die beschriebenen Schritte beziehen sich auf eine typische Entwicklung. Im Einzelfall kann die Reihenfolge variieren, verschiedene Schritte können parallel erfolgen, oder einzelne Vertriebskanäle oder Leistungstypen werden gar nicht implementiert. Des Weiteren geht der Autor von einer klassischen, etablierten Bank aus. Spezialisierte Banken wie z.b. Direktbanken durchlaufen eine andere Entwicklung, die häufig von einem Contact Center als ersten Vertriebskanal ausgeht. Die folgenden Ausführungen können auf alle individuellen Situationen übertragen werden und geben Hinweise auf die konkrete Ausgestaltung der Prozesse.

107 Prozessarchitektur Kernleistungen über herkömmliche Mensch-Mensch-Kanäle Infrastrukturleistungen Standardisiert Individualisiert Leistungen Kernleistungen Zusatzleistungen Mensch-Mensch herkömmlich (z.b. Filiale) Mensch-Mensch neu (z.b. Call Center) Vertriebskanäle Mensch-Maschine (z.b. Web) Abb. 6-16: Kernleistungen über herkömmliche Mensch-Mensch-Kanäle Den einfachsten Fall stellt die klassische Bank dar, die ausschliesslich Kernleistungen über herkömmliche Mensch-Mensch-Kanäle erbringt (s. Abb. 6-16). Hier müssen nur die Geschäftsprozesse Marketing, Verkauf und Service gestaltet werden, Kundenprozessunterstützung und Portalbetrieb spielen keine Rolle. Die Koordination verschiedener Vertriebskanäle ist nur dann erforderlich, wenn mehrere Mensch-Mensch- Kanäle parallel eingesetzt werden, z.b. Filiale und mobiler Aussendienst.

108 94 Prozessarchitektur Kernleistungen über neue Kanäle Infrastrukturleistungen Standardisiert Individualisiert Leistungen Kernleistungen Zusatzleistungen Mensch-Mensch herkömmlich (z.b. Filiale) Mensch-Mensch neu (z.b. Call Center) Vertriebskanäle Mensch-Maschine (z.b. Web) Abb. 6-17: Kernleistungen über neue Kanäle Erschliesst die Bank zusätzlich neue Vertriebskanäle, um ihre Kernleistungen zu erbringen (s. Abb. 6-17), so spielt die Koordination der verschiedenen Vertriebskanäle eine wichtige Rolle. Die eigentlichen Leistungen werden weiterhin von den Geschäftsprozessen Marketing, Verkauf und Service erbracht, die jedoch an die spezifischen Gegebenheiten der einzelnen Kanäle angepasst werden müssen. Die Informationsbereitstellung im Marketingprozess muss nun auch die Mensch- Maschine-Kanäle bedienen. Da die Nutzer des Webs hohe Anforderungen an die Aktualität der publizierten Informationen stellen, ist eine Aktualisierung der bereitgestellten Informationen häufiger notwendig als dies z.b. für gedruckte Broschüren erforderlich ist. Beim Kampagnenmanagement kann das Contact Center zur telefonischen Kundenkontaktierung und zur Verarbeitung von Rückläufen eingesetzt werden. Die eingesetzten Werbeinformationen müssen für das jeweilige Medium aufbereitet werden, z.b. als Broschüre für den Postversand oder als Call Center Skript für die telefonische Kontaktierung. Damit eine effektive Kundenberatung gewährleistet werden kann, muss ein reibungsloser und verzögerungsfreier Informationsaustausch zwischen Contact Center und Filiale garantiert werden. Dies kann erreicht werden, indem die kanalunterstützenden Informationssysteme voll mit den Abwicklungssystemen integriert werden (s. Kapitel 7.2.1) und indem kanalunabhängig einheitliche Prozesse ein-

109 Prozessarchitektur 95 gesetzt werden, die nur im Detail den spezifischen Kanalanforderungen angepasst werden (vgl. Volle Kanalintegration, Kapitel 3.1.2). Die eingesetzten Vertriebskanäle beeinflussen den Verkaufsprozess vor allem in Bezug auf den Grad der Standardisierung. Dem Kundenberater in herkömmlichen Mensch-Mensch-Kanälen wird meist nur ein grober Ablauf vorgegeben, die konkreten Schritte bei Vorbereitung, Beratung und Verkauf gestaltet er aufgrund seines Fachwissens und seiner Erfahrung im Detail selbst. Dieses Vorgehen ist prinzipiell auch im Contact Center möglich, wobei entsprechend qualifiziertes Personal eingesetzt werden muss. Aus Kostengründen wird häufig mit weniger qualifiziertem Personal gearbeitet, dem konkrete Gesprächsleitfäden (Skripts) für verschiedene standardisierte Beratungsfälle und Produkte vorgegeben wird. Für Mensch-Maschine-Kanäle müssen die Abläufe den Anforderungen der elektronischen Schnittstelle angepasst und so gestaltet werden, dass der Kunde als vollständiger Laie den Prozess ohne Probleme durchlaufen kann. In der Regel ist das nur für stark standardisierte Vorgänge wie z.b. Konto- oder Depoteröffnung möglich. Der Vorgang der Kundenidentifikation muss für jeden Kanal individuell gestaltet werden. Während in der Filiale die Vorlage eines Ausweises genügt, müssen im Call Center und im Web andere Mechanismen zum Einsatz kommen z.b. durch Verwendung des Postweges und durch den Einsatz elektronischer Signaturen. Die Anfragen- und Beschwerdebearbeitung im Serviceprozess verläuft in herkömmlichen und neuen Mensch-Mensch-Kanälen ähnlich. In Mensch-Maschine-Kanälen kann der Ablauf dadurch ergänzt werden, dass der Kunde zunächst selbst auf eine Wissensdatenbank zugreifen kann, bevor er die Anfrage an einen Mitarbeiter richtet. Die Abläufe bei der Auftragsabwicklung sind stark abhängig von den spezifischen Eigenschaften der einzelnen Vertriebskanäle. Während in der Filiale meist mit geeigneten Formularen gearbeitet wird, muss für die Auftragsentgegennahme im Contact Center der Gesprächsablauf detailliert strukturiert und durch Rückbestätigungen im Gespräch die Fehlerfreiheit sichergestellt werden. Für Mensch-Maschine-Kanäle muss der Ablauf so vorstrukturiert werden, dass eine intuitiv bedienbare Oberfläche implementiert werden kann. Die verschiedenen Vertriebskanäle erfordern die Einführung eines Unterstützungsprozesses für das Kanalmanagement (s. Kapitel 6.3.3). Die kanalspezifischen Ausprägungen der Geschäftsprozesse müssen zueinander kompatibel sein. In der Regel wechselt ein Kunde die von ihm genutzten Kanäle nach Belieben. Ein im Call Center begonnener Verkaufsvorgang sollte z.b. auch in der Filiale fortgesetzt werden können, oder ein Call Back-Button im Web könnte es dem Benutzer ermöglichen, einen dort begonnenen Vorgang ins Call Center zu transferieren. Diese Kanaltransparenz kann durch die Definition von Synchronisationspunkten in allen Ausprägungen der einzelnen Prozesse erreicht werden.

110 96 Prozessarchitektur Für die Informationsbereitstellung im Vertriebskanal Web ist zudem ein Content Management erforderlich, um die Aktualität und Konsistenz der publizierten Inhalte sicherzustellen (s. Kapitel 6.3.3) Standardisierte Zusatz- und Infrastrukturleistungen über neue Kanäle Infrastrukturleistungen Standardisiert Individualisiert Leistungen Kernleistungen Zusatzleistungen Mensch-Mensch herkömmlich (z.b. Filiale) Mensch-Mensch neu (z.b. Call Center) Vertriebskanäle Mensch-Maschine (z.b. Web) Abb. 6-18: Standardisierte Zusatz- und Infrastrukturleistungen über neue Kanäle Beim Aufbau eines Prozessportals erbringt die Bank zunächst standardisierte Zusatzund Infrastrukturleistungen (s. Abb. 6-19). Diese werden durch den Portalbetriebsprozess abgedeckt. Bei der konkreten Ausgestaltung dieses Prozesses müssen vor allem die Anforderungen des eigenen Content Managements (s. Kapitel 6.3.3) berücksichtigt werden und es ist auf saubere Schnittstellen zu den Prozessen der Kooperationspartner zu achten. Der wichtigste Vertriebskanal, auf den der Portalbetriebsprozess ausgerichtet werden muss, ist das Web. Zusatzleistungen werden aus Kosten- und Effizienzgründen in der Regel darüber erbracht. Ein Contact Center kann unterstützend eingesetzt werden, insbesondere da die Möglichkeit besteht, Spezialisten der Kooperationspartner in das Contact Center einzubinden. Diese Abläufe müssen für das Contact Center spezifiziert werden. Zusatzleistungen in der Filiale sind selten, z.b. könnte der Kundenberater Checklisten auf Papier vorrätig haben und sie dem Kunden auf Wunsch abgeben.

111 Prozessarchitektur 97 Kooperationspartner der Bank sind in den Portalbetriebsprozess sowohl bei der Erstellung als auch bei der Pflege bzw. Aktualisierung von Inhalten involviert. Um die Zuverlässigkeit der Informationsbereitstellung und die Informationsqualität garantieren zu können (vgl. Kapitel 3.1), müssen die Partner vollständig in den Portalbetriebsprozess integriert werden. Die Prozessspezifikation muss gemeinsam mit den Partnern erfolgen, um nahtlose Prozessübergänge zu ermöglichen (vgl. Volle Integration der Partnerleistungen, Kapitel 3.1.1). Werden Infrastrukturleistungen wie z.b. Diskussionsforen oder Auktionen angeboten, so müssen für jede dieser Leistungen die detaillierten Abläufe für Pflege und Administration spezifiziert werden. Soll ein Diskussionsforum z.b. moderiert sein, muss ein entsprechender Teilprozess für die Entgegennahmen, Überprüfung und Freigabe von Diskussionsbeiträgen vorhanden sein. Ausserdem muss z.b. durch geeignete Überwachungsprozesse sichergestellt werden, dass die Benutzer nicht illegale Inhalte erzeugen oder gegen die Geschäftsinteressen des Portalbetreibers handeln Individualisierte Zusatz- und Infrastrukturleistungen Infrastrukturleistungen Standardisiert Individualisiert Leistungen Kernleistungen Zusatzleistungen Mensch-Mensch herkömmlich (z.b. Filiale) Mensch-Mensch neu (z.b. Call Center) Vertriebskanäle Mensch-Maschine (z.b. Web) Abb. 6-19: Individualisierte Zusatz- und Infrastrukturleistungen Individualisierte Zusatz- und Infrastrukturleistungen erlauben es dem Portalbetreiber, besser auf die Bedürfnisse der einzelnen Kunden einzugehen. Dies ist vor allem bei den Mensch-Maschine-Kanälen relevant, wo der Kunde normalerweise auf eine stan-

112 98 Prozessarchitektur dardisierte Schnittstelle zugreift. Für die Erbringung dieser Leistungen ist der Kundenprozessunterstützungs-Prozess verantwortlich. Eine wesentliche Aufgabe dieses Prozesses ist die personalisierte Bereitstellung von Informationen über das Web. Die beiden involvierten Abläufe, welche bei der Ausgestaltung des Prozesses näher spezifiziert werden müssen, sind die Gewinnung von Personalisierungsinformationen über den Kunden, z.b. durch Abfrage von Präferenzen, durch Analyse des Kauf- oder Surfverhaltens etc. und die Personalisierung der verfügbaren Inhalte, die wiederum von der Art der Inhalte und von den verfügbaren Kriterien abhängen (vgl. Personalisierung und Kundenprofile, Kapitel 3.1.2). Weitere individualisierte Leistungen sind stark abhängig vom konkret unterstützten Kundenprozess. Eine enge Abstimmung der detaillierten Abläufe auf die Abläufe im Kundenprozess ist hier erforderlich. 6.6 Konzeption eines Prozessportals für Erbschaft und Bestattung Der Kundenprozess Erbschaft und Bestattung dient im Folgenden als fiktives Beispiel, um das Konzept der Kundenprozesszentrierung und der Prozessportale näher zu erläutern. Das Konzept der Kundenprozessorientierung bedingt, dass der Kundenprozess möglichst vollständig unterstützt wird. Im hier betrachteten Fall umfasst der Prozess daher sowohl Aufgaben, die der Erblasser zu Lebzeiten durchführt, um die Erbschaft möglichst gut vorzubereiten, als auch Aufgaben, welche die Erben bzw. die Angehörigen im Zusammenhang mit der Bestattung des Erblassers und mit der Erbschaft durchzuführen haben. Die folgenden Abschnitte beschreiben ein vollständiges Konzept zur Realisierung eines Prozessportals für die Unterstützung des Kundenprozesses Erbschaft und Bestattung auf Prozessebene. Die zugehörige IS-Architektur ist in Kapitel 7.4 dargestellt. Als Ausgangspunkt dient die Zerlegung des Prozesses in einzelne Aufgaben, wobei zwischen Aufgaben des Erblassers vor seinem Tod und Aufgaben des Erben nach dem Tod des Erblassers unterschieden wird (s. Abb. 6-20). Jede Aufgabe konsumiert und produziert bestimmte Leistungen, die bei der Beschreibung der einzelnen Aufgaben erläutert werden. Die Informationen über den Kundenprozess sind [Grün 1999; Rix/Grümmer 1999] entnommen. Ein Prozessportal muss diejenigen Leistungen erbringen, welche der Kundenprozess konsumiert. Die Leistungen sind also die Grundlage für die Beschreibung des Prozessportals. Aus Sicht einer Bank, die ein solches Prozessportal betreiben könnte, wird für die einzelnen Leistungen angegeben, ob die Bank die Leistung selbst erbringen kann bzw. welche Partner erforderlich sind, um einzelne Leistungen zu erbringen. In jedem Fall wird analysiert, welchen Aufwand und welchen Nutzen die Erbringung einzelner Leistungen für die beteiligten Partner bedeutet.

113 Prozessarchitektur 99 Der Kundenprozess Erbschaft und Bestattung wurde als Beispielprozess ausgewählt, da die häufig nach einer Erbschaft anfallenden Fragen der Geldanlage oder Vermögensverwaltung in jedem Fall in den Kompetenzbereich der Banken fallen. Diese können somit beim Betrieb eines Erbschaftsportals einen klaren Nutzen durch den Verkauf von Anlageprodukten erwarten. Der konkrete Aufwand und Nutzen für die Bank als Portalbetreiber wird unten bei der Beschreibung der einzelnen Leistungen angegeben. Erblasser Kundenprozess Erbschaft und Bestattung Beliebiger Auslöser Erbe(n) Kundenprozess Erbschaft und Bestattung Todesfall des Erblassers Vermögenssituation analysieren Arzt und Angehörige benachrichtigen Erbschaft/Schenkungen steueroptimiert planen Bestatter mit Überführung beauftragen Testament / Erbvertrag erstellen Sterbeurkunde beantragen Bestattung planen Bank, Arbeitgeber, Versicherungen informieren Finanzierung der Bestattung sicherstellen Bestattung und Trauerfeier organisieren Schenkungsplan durchführen Gedenkstein anf. lassen, Grabpflege organisieren Veränderungen in Planung einbeziehen Testament beim Amtsgericht einreichen Todesfall Prüfen, ob Erbschaft angetreten werden soll Erbschein beantragen Bankverbindungen regeln Haushalt auflösen, Verträge kündigen Erbschaft antreten Vermögen anlegen Abb. 6-20: Kundenprozess Erbschaft und Bestattung

114 100 Prozessarchitektur Die konkrete Realisierbarkeit eines Prozessportals für Erbschaft und Bestattung ist abhängig von der Bank, die als Portalbetreiber auftritt, und von deren Umfeld. Wesentlichen Einfluss haben z.b. die Struktur des vorhandenen Kundenstamms, die Verfügbarkeit potenzieller Partner, die vorhandene Infrastruktur etc. Zur Überprüfung der Machbarkeit müsste ein detaillierter Businessplan ausgearbeitet werden. Darauf hat der Autor im vorliegenden Kontext verzichtet, da das Beispiel lediglich zur Illustration des Konzeptes der Kundenprozessorientierung dient. Der derzeit relativ geringe Anteil der Senioren an den Internetnutzern könnte ein Argument gegen die Wahl des Kundenprozesses Erbschaft und Bestattung sein. Dem ist erstens entgegenzuhalten, dass der Anteil der Senioren im Web laufend steigt. Bereits heute sind 13,9% der Internetnutzer über 50 Jahre alt [Fittkau & Maaß 2000]. Zweitens ist das Beispiel rein konzeptioneller Art und kann leicht auf andere Kundenprozesse übertragen werden Kundenprozess des Erblassers Der Kundenprozess kann bereits lange vor dem Tod des Erblassers beginnen, nämlich zu dem Zeitpunkt, zu dem dieser sich erstmals über seinen Nachlass Gedanken macht. Eine Vielzahl von Auslösern ist hier möglich: Der Eintritt in den Ruhestand kann etwa den Erblasser dazu bewegen, sich über seine Hinterlassenschaft Gedanken zu machen, oder der Tod eines Angehörigen oder eines guten Freundes oder ein anderes Ereignis. Auch kann z.b. die Bank den Erblasser im Rahmen seiner Vermögensplanung auf das Thema Erbschaft ansprechen. In seinem Kundenprozess kann der Erblasser Vorkehrungen treffen, um die Erbschaft möglichst steuergünstig zu gestalten, um den Angehörigen die organisatorischen und administrativen Aufgaben nach seinem Tod zu erleichtern und um sicherzustellen, dass den Angehörigen seine Wünsche bezüglich Bestattung und Trauerfeier bekannt sind. Die einzelnen Aufgaben im Kundenprozess des Erblassers werden in Anhang B.1 detailliert beschrieben Kundenprozess des Erben Wenn auch der Erbe bereits im Kundenprozess des Erblassers in einzelnen Aufgaben involviert sein kann, so beginnt der eigentliche Kundenprozess des Erben mit dem Tod des Erblassers. Es fallen eine Vielzahl von organisatorischen und administrativen Aufgaben an, die in der Regel von einem nahen Angehörigen des Verstorbenen durchgeführt werden. Meist wird dieser Angehörige gleichzeitig Erbe bzw. einer der Erben sein, so dass im Folgenden vom Kundenprozess des Erben gesprochen wird und der Erbe als Aufgabenträger auftritt. Die einzelnen Aufgaben im Kundenprozess des Erben werden in Anhang B.2 detailliert beschrieben.

115 Prozessarchitektur Übersicht über Aufgaben und Leistungen Die oben beschriebenen Aufgaben des Kundenprozesses sowie die von diesen Aufgaben konsumierten Leistungen werden in der folgenden Tabelle zusammengefasst dargestellt. Die einzelnen Leistungen werden in Abschnitt detailliert beschrieben. Aufgabe im Kundenprozess des Erblassers Vermögenssituation analysieren Erbschaft und Schenkungen steueroptimiert planen Testament / Erbvertrag erstellen Bestattung planen Finanzierung der Bestattung sicherstellen Schenkungsplan durchführen Veränderungen in Pla- Konsumierte Leistungen Checkliste und Strukturierungshilfe zur Vermögensaufstellung Kontoauszüge, Depotauszüge, Versicherungspolicen, andere Belege über extern verwaltete Vermögenswerte Rechnungen, Wertschätzungen Vermögensübersicht Checkliste zur Erbschaftsplanung Informationen über rechtliche Rahmenbedingungen (gesetzliche Erbfolge, Pflichtteile, Erbschaftssteuer/Freibeträge etc.) Informationen über steuerliche Optimierungsmöglichkeiten Steuerrechtliche Beratung Erbschaftsplan Checkliste zur Erstellung von Testamenten und Erbverträgen Informationen über rechtliche Rahmenbedingungen (Pflichtteile, eigenhändiges Testament, öffentliches Testament) Mustertestamente Verzeichnis zuständiger Notare Notarielle Dienstleistungen Checkliste zur Bestattungsplanung Verzeichnis von Friedhöfen, Kapellen, Kirchen und Orten für weltliche Trauerfeiern, Rednern Verzeichnis von Bestattungsunternehmen Katalog von Särgen, Urnen etc. Plan für Bestattung und Trauerfeier Angebot oder Kostenaufstellung für Bestattung Finanzprodukte (Anlageprodukt, Versicherung) Schenkungsplan Erinnerung an Schenkungstermin Vermögensübersicht

116 102 Prozessarchitektur Aufgabe im Kundenprozess des Erblassers nung einbeziehen Konsumierte Leistungen Erbschaftsplan Schenkungsplan Testament / Erbvertrag Plan für Bestattung und Trauerfeier Informationen über rechtliche Änderungen Tabelle 6-7: Aufgaben und Leistungen im Kundenprozess des Erblassers Aufgabe im Kundenprozess des Erben Arzt und Angehörige benachrichtigen Bestatter mit Überführung beauftragen Sterbeurkunde beantragen Bank, Arbeitgeber, Versicherung informieren Bestattung und Trauerfeier organisieren Gedenkstein anfertigen lassen, Grabpflege organisieren Konsumierte Leistungen Telefonnummer des Hausarztes oder Notarztes Checkliste für Bestattung Plan für Bestattung und Trauerfeier Verzeichnis von Bestattungsunternehmen Checkliste für Bestattung Plan für Bestattung und Trauerfeier Adresse des zuständigen Standesamtes Totenschein Dokumente des Verstorbenen (Personalausweis, Geburtsurkunde etc.) Checkliste für Bestattung Plan für Bestattung und Trauerfeier Bankverbindungen und Versicherungsverträge des Erblassers Adresse des Arbeitsgebers Sterbeurkunde Checkliste für Bestattung Plan für Bestattung und Trauerfeier Verzeichnis von Bestattungsunternehmen Katalog von Särgen, Urnen etc. Adressen der Empfänger der Trauerbriefe Verzeichnis von Tageszeitungen für Traueranzeigen Checkliste für Bestattung Plan für Bestattung und Trauerfeier Verzeichnis von Steinmetzen Verzeichnis von Grabpflege-Dienstleistern

117 Prozessarchitektur 103 Aufgabe im Kundenprozess des Erben Testament beim Amtsgericht einreichen Prüfen, ob Erbschaft angetreten werden soll Erbschein beantragen Konsumierte Leistungen Checkliste für Erbschaften Testament Checkliste für Erbschaften Testament Unterlagen über die Vermögenssituation des Erblassers Checkliste für Erbschaften Bankverbindungen regeln Checkliste für Erbschaften Erbschein Haushalt auflösen, Verträge kündigen Erbschaft antreten Vermögen anlegen Checkliste für Bestattung Plan für Bestattung und Trauerfeier Bestehende Verträge etc. des Erblassers Verzeichnis von Unternehmen für die Haushaltsauflösung Checkliste für Erbschaften Erbschein Testament Erbvertrag Checkliste zur Anlage von Erbschaften Beratungsleistungen zur Geldanlage Tabelle 6-8: Aufgaben und Leistungen im Kundenprozess des Erben

118 104 Prozessarchitektur Leistungen des Prozessportals Partner Bank Kunde Notar Rechtl. Informationen und Checklisten Rechtsberatung Notarielle Dienstleistungen CRM Marketing Verkauf Service Portalbetrieb Rechtliche Informationen Rechts- und Steuerberatung Musterverträge und -testamente Verzeichnisse v. Dienstleistern Notarielle Dienstleistungen Produktkataloge (Särge, Urnen...) Pers. Informationen des Erblassers Anlageberatung und -produkte Anwaltsbüro Checklisten zu Bestattungsfragen... Verzeichnisse und Kataloge Bestattungsdienstleistungen Bestattungsunternehmen Leistungserstellung Produktentwicklung Kundenprozessunterstützung Checklisten Erbschaft & Bestattung Erbschaft planen Bestattung planen Tod des Erblassers Bestattung organisieren Erbschaft antreten Vermögen anlegen Abb. 6-21: Prozessportal für Erbschaft und Bestattung Ein Prozessportal, das den oben beschriebenen Kundenprozess unterstützen soll, muss alle Leistungen erbringen, die von diesem Kundenprozess konsumiert werden. In der Regel verfügt der Betreiber eines Prozessportals nicht über alle Kompetenzen, die zur Erbringung dieser Leistungen erforderlich sind. Aus diesem Grund bindet der Betreiber verschiedene spezialisierte Partner als Leistungserbringer in das Prozessportal ein. Abb enthält eine vereinfachte schematische Darstellung der Prozessarchitektur. Abb zeigt einen Überblick über die Leistungen, die ein Prozessportal für Erbschaft und Bestattung an den Kundenprozess erbringt. Die Leistungen sind gemäss der Klassifikation in Kapitel 6.2 in Kern-, Zusatz- und Infrastrukturleistungen sowie in standardisierte und individualisierte Leistungen gegliedert.

119 Prozessarchitektur 105 Kernleistungen Zusatzleistungen Infrastrukturleistungen Kundenprozessspezifische Fachinformationen: Rechtliche Rahmenbedingungen Steuerliche Optimierungsmöglichkeiten Checklisten: Vermögensaufstellung Erbschaftsplanung Erstellung von Testamenten und Erbverträgen Bestattungsplanung, Bestattung Erbschaften, Anlage von Erbschaften Verzeichnisse externer Partner: Zuständige Notare, Zuständige Standesämter Bestattungsunternehmen Friedhöfe, Kapellen, Kirchen, Orte für weltliche Trauerfeiern, Redner Tageszeitungen f. Traueranzeigen Steinmetze, Grabpflege-Dienstleister Unternehmen für die Haushaltsauflösung Musterverträge, Musterdokumente: Mustertestamente Produktinformationen von Drittanbietern: Katalog von Särgen, Urnen etc. Finanzprodukte Produktinformationen Standardisiert Verwahrung persönlicher Unterlagen: Plan für Bestattung und Trauerfeier Telefonnummer des Hausarztes oder Notarztes Bankverbindung und Versicherungsverträge des Erblassers Adresse des Arbeitgebers Adressen der Empfänger der Trauerbriefe Bestehende Verträge des Erblassers Ereignisgesteuerte Benachrichtigung: Erinnerung an Schenkungstermin Informationen über rechtliche Änderungen Beratung, Angebot, Vertrag: Finanzprodukte (Finanzierung der Bestattung) Anlageprodukte Belege: Kontoauszüge Depotauszüge Versicherungspolicen Belege über extern verwaltete Vermögenswerte Rechnungen Wertschätzungen Individualisiert Abb. 6-22:Leistungen des Prozessportals für Erbschaft und Bestattung Die einzelnen Leistungen werden in Anhang B.3 beschrieben. Portalbetreiber ist bei diesen Betrachtungen eine im Privatkundengeschäft tätige Bank. Leistungen, die vom Kundenprozess produziert und wieder konsumiert werden, sind in der Aufstellung nicht berücksichtigt Prozesse des Portalbetreibers Bei der Bank als Portalbetreiber sind die Customer Relationship Managementprozesse Marketing, Verkauf und Service sowie die Prozesse Portalbetrieb, Kundenprozessunterstützung und Produktentwicklung für die Erbringung bzw. Bereitstellung der Leistungen verantwortlich. Neben der Bereitstellung allgemeiner Produktinformationen dient der Marketingprozess dazu, Kunden für das Prozessportal zu gewinnen. Diese Aufgabe der Kundengewinnung wird im Folgenden nicht näher betrachtet, weil dies keine direkte Leistung zur Unterstützung des Kundenprozesses darstellt.

120 106 Prozessarchitektur Anwaltsbüro Verschiedene Prozesse Notar Diverse Checklisten, Mustertestamente und -verträge Rechts- und Steuerinformationen Checklisten, Verzeichnisse, Kataloge Inhaltliche Portalanfordrungen Bank Portalbetrieb Checklisten und Basisinformationen Verzeichnisse versch. Anbieter und Ämter Kunde Verschiedene Prozesse Kundenprozess Bestattungsunternehmen Verschiedene Prozesse Marketing Produktinformationen Verkauf Service Unterstützung f. Vermögensaufstellung Vermögensaufstellung Anlageberatung Anlageprodukte Belege über Vermögenswerte Kunden- Erinnerung an Schenkungstermin prozess- unterstützung Persönliche Informationen Produktentwicklung Erbschaft & Bestattung Prozess Leistung Dienstleistungen für Bestattung und Trauerfeier Notarielle Dienstleistungen Steuer- und erbschaftsrechtliche Beratung Abb. 6-23: Prozessarchitektur des Prozessportals für Erbschaft und Bestattung Teilweise erstellt die Bank die Leistungen des Prozessportals selbst, weil sie entweder zu den Kernkompetenzen der Bank gehören oder weil die Neutralität der Bank gegenüber Drittanbietern erforderlich ist. Dies ist zum Beispiel bei verschiedenen Anbieterverzeichnissen relevant. Andere Leistungen bezieht die Bank von spezialisierten Drittanbietern, im hier betrachteten Kundenprozess zum Beispiel von Anwaltsbüros oder Bestattungsunternehmen. Die Drittanbieter erbringen diese Leistungen entweder über das Prozessportal oder direkt an den Endkunden, wobei das Prozessportal die Vermittlerrolle innehat. Checklisten und andere Informationsangebote zum Beispiel werden in der Regel direkt im Prozessportal bereitgestellt, während individuelle Beratungsleistungen vom Prozessportal nur vermittelt werden können, aber direkt erbracht werden müssen. Abb zeigt die wichtigsten Prozesse und Leistungen aller am Prozessportal beteiligten Partner. Während die Prozesse Marketing und Portalbetrieb als bankgesteuerte Prozesse aus dem Prozessmodell weitgehend unverändert übernommen werden können, müssen die kundengesteuerten Prozesse Verkauf, Service und Kundenprozessunterstützung dem konkreten Kundenprozess angepasst werden (vgl. Kapitel 6.3.2). Sowohl beim Kundenprozess als auch bei den bankseitigen Prozessen handelt es sich um schwach strukturierte, wissensintensive Prozesse. Die einzelnen Aufgaben stehen daher nicht in einer eindeutigen Reihenfolge. Die Aufgabenkette ist als typischer Ablauf zu verstehen, der in den meisten Einzelfällen modifiziert wird. Die Darstellung

121 Prozessarchitektur 107 der Prozesse erfolgt dennoch mit Aufgabenkettendiagrammen, wobei die Pfeile keine strenge zeitliche Abfolge bezeichnen, sondern typische Pfade und Abhängigkeiten angeben. Abb zeigt ein Aufgabenkettendiagramm des Verkaufsprozesses, welches für die Unterstützung des Kundenprozesses Erbschaft und Bestattung angepasst wurde. Die Aufgaben des Verkaufsprozesses von Kundenbedarf analysieren bis Vertrag abschliessen werden in etwa zweimal durchlaufen: Einmal im Prozess des Erblassers, der Finanzprodukte für Schenkungen und zur Vorsorge für die Bestattungskosten benötigt, und einmal im Prozess des Erben, der sein ererbtes Vermögen anlegen möchte.

122 108 Prozessarchitektur Bank Prozess Verkauf Kundenbedarf analysieren Beratungsempfehlung Produkte präsentieren Individuelles Angebot erstellen Konditionen vereinbaren Vertrag abschliessen Erblasser und Erben Erbschaft und Bestattung Vermögenssituation analysieren Erbschaft/Schenkungen steueroptimiert planen Testament / Erbvertrag erstellen Bestattung planen Finanzierung der Bestattung sicherstellen Schenkungsplan durchführen Veränderungen in Planung einbeziehen Todesfall des Erblassers Arzt und Angehörige benachrichtigen Bestatter mit Überführung beauftragen Sterbeurkunde beantragen Bank, Arbeitgeber, Versicherungen informieren Bestattung und Trauerfeier organisieren Gedenkstein anf. lassen, Grabpflege organisieren Testament beim Amtsgericht einreichen Prüfen, ob Erbschaft angetreten werden soll Erbschein beantragen Bankverbindungen regeln Haushalt auflösen, Verträge kündigen Erbschaft antreten Vermögen anlegen Abb. 6-24: Verkaufsprozess im Prozessportal für Erbschaft und Bestattung Abb illustriert den Serviceprozess und den Kundenprozessunterstützungs- Prozess im Zusammenhang mit dem Kundenprozess Erbschaft und Bestattung. Der Serviceprozess unterstützt den Kundenprozess des Erblassers durch die Bereitstellung von Belegen, die zur Vermögensaufstellung benötigt werden. Für den Erben übernimmt er die Aufgaben der Kontensperrung und Kontenübertragung, die im Rahmen der Erbschaft anfallen. Diese Aufgaben wurden gegenüber dem allgemeinen Prozess-

123 Prozessarchitektur 109 modell ergänzt. Die Kundenprozessunterstützung verwaltet die Erbschafts- und Bestattungsplanung des Erblassers und informiert diesen über fällige Schenkungstermine sowie über Änderungen der rechtlichen Rahmenbedingungen. Ausserdem ist die Kundenprozessunterstützung für die Verwahrung von persönlichen Dokumenten des Erblassers zuständig, die dann nach seinem Tod dem Erben zur Verfügung gestellt werden. Dies sind z.b. ein persönlicher Plan für Bestattung und Trauerfeier und die Telefonnummer des Hausarztes.

124 110 Prozessarchitektur Bank Prozess Leistungserstellung Belege bereitstellen Bank Prozess Kundenprozessunterstützung Bank Prozess Service Auftrag entgegennehmen Auftragsausführung auslösen Benachrichtigung entgegennehmen Erblasser und Erben Erbschaft und Bestattung Vermögenssituation analysieren Erbschaft/Schenkungen steueroptimiert planen Testament / Erbvertrag erstellen Bestattung planen Präferenzen u. Dokumente speichern Kunden benachrichtigen Finanzierung der Bestattung sicherstellen Schenkungsplan durchführen Persönliche Informationen bereitstellen Termin gemäss Schenkungsplan Veränderungen in Planung einbeziehen Todesfall des Erblassers Arzt und Angehörige benachrichtigen Regelmässig Ereignisse prüfen Bestatter mit Überführung beauftragen Anwaltsbüro Erinnerung an Schenkungsplan Sterbeurkunde beantragen Über rechtliche Änderungen informieren Information über Änderungen Konten sperren Bank, Arbeitgeber, Versicherungen informieren Bestattung und Trauerfeier organisieren Gedenkstein anf. lassen, Grabpflege organisieren Testament beim Amtsgericht einreichen Prüfen, ob Erbschaft angetreten werden soll Erbschein beantragen Konten übertragen Bankverbindungen regeln Haushalt auflösen, Verträge kündigen Erbschaft antreten Vermögen anlegen Abb. 6-25: Prozesse Service und Kundenprozessunterstützung im Prozessportal für Erbschaft und Bestattung Der weitgehend standardisierte Portalbetriebsprozess ist in Abb dargestellt. Er ist für die Beschaffung, Erstellung und Bereitstellung der Portalinhalte zuständig. Dazu koordiniert er einerseits die Inhaltserstellung externer Partner und veranlasst andererseits die interne Erstellung von Inhalten. Die vom Marketingprozess bereitgestellten Produktinformationen bzgl. Bankprodukten werden dabei aus Prozesssicht wie die

125 Prozessarchitektur 111 Informationen der externen Partner behandelt. Einmal erstellte Inhalte werden im Portal bereitgestellt und stehen dem Kunden zu beliebigen Zeitpunkten zur Verfügung. Die Nutzung des Portals durch den Kunden erfordert bei der Bank keine weiteren Aktivitäten. Der Portalbetriebsprozess ist zusätzlich dafür verantwortlich, die Inhalte zu pflegen und so die Aktualität sicherzustellen. Auch bei der Pflege ist die Koordination der externen Partner und die interne Pflege der eigenen Inhalte erforderlich. Bank Prozess Produktentwicklung Bank Prozess Portalbetrieb Kunde Kundenprozess Portalvorgaben bereitstellen Interne Erstellungsmöglichkeit prüfen Bank Prozess Marketing Portalinhalte extern beschaffen Portalinhalte erstellen Informationsbereitstellung Anwaltsbüro Checklisten, Informationsmaterial bereitstellen Portal nutzen Checklisten, Informationsmaterial pflegen Bestattungsunternehmen Checklisten, Verzeichnisse, Kataloge bereitstellen Portalinhalte bereitstellen Checklisten, Verzeichnisse, Kataloge pflegen Portalinhalte pflegen Abb. 6-26: Portalbetriebsprozess im Prozessportal für Erbschaft und Bestattung

126 112 IS-Architektur 7 IS-Architektur Die IS-Architektur beschreibt Funktionen, Daten und Applikationen (s. Kapitel 4.1). Die meisten Funktionen sind vom konkreten Kundenprozess abhängig, z.b. könnte der Kundenprozess Immobilienerwerb Checklisten für die Immobilienauswahl und ein Verzeichnis von Hypotheken erfordern. Diese kundenprozessabhängigen Funktionen können jedoch verallgemeinert werden, indem z.b. eine generische Checklistenfunktion bereitgestellt wird, welche die Immobilienauswahl genauso unterstützen kann wie etwa die Autoauswahl; ein allgemeiner Produktkatalog kann genauso für Hypotheken wie z.b. für Autozubehör eingesetzt werden. Die Anforderungen an eine IS- Architektur für CRM und Prozessportale werden im Folgenden kundenprozessunabhängig spezifiziert. Als Grundlage für die Spezifikation der Anforderungen dient die Analyse von verfügbarer Standardsoftware sowie von Lösungen bei Anwendern. Die in Kapitel beschriebenen Standardapplikationen der Hersteller SAP, Oracle, Siebel und Uniquare wurden als Beispiele für typische Vertreter von CRM-Standardsoftware ausgewählt und auf funktionaler Ebene analysiert. Ausserdem flossen die funktionalen Betrachtungen aus [Wilde/Hippner 2000] und aus [Jansen 2000, S.96ff.] in die Analyse ein. Auf Anwenderseite wurden geplante und bestehende Lösungen bei Partnerunternehmen des CC BKM und CC CRM (s. Kapitel 1.3) betrachtet. Die verschiedenen resultierenden Funktionsarchitekturen wurden konsolidiert und mit einer einheitlichen Terminologie versehen. Unabhängig von der Softwareanalyse wurden von den in Kapitel 5 beschriebenen Leistungen und Prozessen die Anforderungen an die unterstützenden IS-Funktionen abgeleitet. Die konsolidierte Funktionsarchitektur wurde nun so ergänzt, dass sie alle diese Anforderungen abdeckt. Kapitel 7.1 beschreibt die Funktionen und Daten der resultierenden Funktionsarchitektur allgemein, ohne auf konkrete Applikationen einzugehen. Kapitel 7.2 zeigt den Einfluss typischer Projektszenarien auf die Gestaltung der Funktionsarchitektur beim Einsatz in Praxisprojekten. Kapitel 7.3 stellt verschiedene Applikationstypen vor, welche die beschriebenen Funktionen abdecken. Schliesslich werden die Applikationslandschaften verschiedener Hersteller und Anwender exemplarisch beschrieben. 7.1 Funktionen und Daten Beschreibungsraster Das einheitliche Beschreibungsraster für die Funktionen der IS-Architektur beinhaltet die folgenden Elemente: Verbale Beschreibung der Funktion

127 IS-Architektur 113 Spezifikation der Datenbestände, auf welche die Funktion zugreift Zuordnung der Datenzugriffe zu den Kategorien analytisch, operativ und kollaborativ Spezifikation der unterstützten Prozesse Nennung der Vertriebskanäle, für welche die Funktion relevant ist (vgl. Kapitel 6.4) Datenbestände Die IS-Funktionen greifen auf verschiedene Datenbestände zu. Die Funktionen sind dabei nicht auf die Daten ausgerichtet (z.b. Kundendaten lesen, erfassen, ändern, löschen), sondern sie orientieren sich an den Prozessen, die sie unterstützen. Beispielsweise benötigt eine Funktion zur Unterstützung der Planung von Marketingkampagnen Zugriff sowohl auf Kundendaten zur Selektion der Adressaten der Kampagnen als auch auf Produktdaten zur Erstellung des Werbematerials für die Kampagne sowie ggf. auf Marktdaten zur Berücksichtigung von Konkurrenten und anderen externen Rahmenbedingungen. Die folgende Auflistung beschreibt eine grobe Gruppierung der benötigten Datenbestände. Die einzelnen Bestände sind nicht als Entitäten oder Objekte im Sinne eines Datenmodells zu verstehen, sondern als übergeordnete, logische Zusammenfassung verschiedener solcher Einzelelemente. Kundendaten: Kundendaten beinhalten kundenbezogene Stammdaten (Name, Adresse, Zusatzinformationen, ), Transaktionsdaten (Käufe, Zahlungen, Kontobewegungen, ) und Kontaktdaten (Telefonate, Vertreterbesuche, Briefe, ) [vgl. Davenport 1998]. Transaktionsdaten und ein Teil der Stammdaten werden i.d.r. aus operativen Systemen (z.b. SAP R/3 oder hostbasiertes Bankenabwicklungssystem) bezogen. Produktdaten: Produktdaten beinhalten vollständige Informationen über angebotene Produkte und Dienstleistungen. Dazu gehören Produktbeschreibungen für Kunden und für Mitarbeiter, Verkaufsargumente, Abwicklungsinformationen, Konditionen und Preise etc. Kampagnendaten: Kampagnendaten beinhalten Informationen über Marketingkampagnen. Dazu gehören Listen der Adressaten, Kampagnenunterlagen, Zielvorgaben, Angaben über Rückläufe und Ergebnisse statistischer Auswertungen. Partnerdaten: Partnerdaten beinhalten Adressen und weitere Informationen über Geschäftspartner. Dazu gehören sowohl Lieferanten als auch andere Partner, z.b. Vertriebspartner oder Partner im Rahmen eines Prozessportals. Mitarbeiterdaten: Mitarbeiterdaten beinhalten Informationen über Mitarbeiter in CRM-bezogenen Bereichen (Marketing, Vertrieb, Service). Dazu gehören Mitar-

128 114 IS-Architektur beiterstammdaten, die i.d.r. aus operativen Systemen bezogen werden, sowie Informationen über Zuständigkeiten (Kunden, Regionen), Aktivitäten, Termine etc. Marktdaten: Marktdaten beinhalten Informationen über das wirtschaftliche Umfeld, z.b. Börsenkurse, Unternehmensportraits, Konkurrenteninformationen, Marktstudien etc. Fachwissen: Fachwissen beinhaltet Basisinformationen, die zur Abwicklung des täglichen Geschäfts erforderlich sind. Dazu gehören allgemeine fachliche Hintergrundinformationen, Wissen über den Kundenprozess, Informationen über mögliche Probleme und Lösungen, Informationen zu Marketing- und Verkaufstechniken, etc. Kommunikationsdaten: Kommunikationsdaten fassen meist temporäre Datenbestände zusammen, welche die Kommunikation zwischen Kunden und Mitarbeitern unterstützen. Dazu gehört z.b. die Speicherung von s, Diskussionsbeiträgen oder Chatbeiträgen während des eigentlichen Kommunikationsvorganges Kategorisierung der Datenzugriffe Die Datenzugriffe können den drei Bereichen Operatives CRM, Analytisches CRM und Kollaboratives CRM zugeordnet werden [vgl. Schwede 2000, S.8]: Operative Datenzugriffe lesen, erzeugen und verändern CRM-bezogene Datenbestände wie z.b. Kundendaten (Kontakte, Stammdaten) oder Aktivitäten. Analytische Datenzugriffe greifen lesend auf operative Datenbestände zu (z.b. Transaktionsdaten), entweder direkt auf operative Systeme oder auf ein Data Warehouse, die dann den Anforderungen der unterstützten Aufgabe entsprechend analysiert werden. Die Analyseergebnisse werden wiederum abgelegt, z.b. in Data Marts. Kollaborative Datenzugriffe greifen lesend und schreibend auf Kommunikationsdaten zu und unterstützen somit die Kommunikation zwischen den verschiedenen beteiligten Personen. IS-Funktionen können meist nicht direkt einer der drei Kategorien zugeordnet werden. Im Bereich der Marketing Automation erfolgen beispielsweise sowohl analytische Zugriffe (z.b. zur Auswertung der operativen Daten und Generierung von Adressatenlisten) als auch operative Zugriffe (z.b. zur Verwaltung der Kampagne) [vgl. Schwede 2000, Abb. 1]. Aus diesem Grund werden im Folgenden nicht die Funktionen selbst, sondern die einzelnen Datenzugriffe den Kategorien zugeordnet.

129 IS-Architektur IS-Funktionen Kanäle Prozesse Marketing Verkauf Service Service Request Management Andere Service-Logistik Kanalunabhängige Funktionen Die folgende Aufstellung enthält diejenigen Funktionen, welche die CRM-Prozesse Marketing, Verkauf und Service sowie die Portalprozesse Kundenprozessunterstützung und Portalbetrieb unterstützen (vgl. Kapitel 6.3). Bei den IS-Funktionen kann man grundsätzlich unterscheiden zwischen kanalunabhängigen und kanalspezifischen Funktionen: Kanalunabhängige Funktionen unterstützen die Prozesse unabhängig davon, welcher Vertriebskanal für den Kundenkontakt genutzt wird. Ein Beispiel für eine solche Funktion ist das Kundenmanagement, auf das in allen Prozessen und Kanälen zugegriffen wird. Kanalspezifische Funktionen unterstützen die Prozesse nur beim Einsatz bestimmter Vertriebskanäle. Zum Beispiel stellt die Call Center- Unterstützung Funktionen bereit, die der Call Center-Mitarbeiter bei der Durchführung der Telefongespräche nutzen kann. Abb. 7-1 gibt einen Überblick über den kanalunabhängigen Teil der IS-Funktionsarchitektur, Abb. 7-2 zeigt die kanalspezifischen Funktionen. Kampagnenmanagement Kundensegmentierung Kundenbedarfsanalyse Produktkonfiguration Angebotsmanagement Auftrags-/Vertragsmanagement Servicevertragsverwaltung Beschwerdemanagement Kundentransaktionen Verwaltung von Basisinformationen Kundenmanagement Opportunitymanagement Produktkatalog Analysen und Berichte Abb. 7-1: Übersicht über kanalunabhängige Funktionen

130 116 IS-Architektur Kanäle Prozesse Alle Service Portalbetrieb Mehrstufen- Kanäle Partner Relationship Management Mensch- Mensch Call Center- Unterstützung Beraterarbeitsplatz Mailing- Unterstützung Maschine- Mensch Web Publishing Personalisierte Informationen Electronic Banking Community- Funktionen Auktionen, Marktplatz Elektronischer Auftrag u. Zahlung Linksammlungen Maschine- Maschine Homebanking- Unterstützung Abb. 7-2: Übersicht über kanalspezifische Funktionen Anhand der oben spezifizierten Kriterien werden im Folgenden die einzelnen IS- Funktionen detailliert beschrieben. Zunächst werden diejenigen Funktionen betrachtet, die einen bestimmten Prozess unterstützen. Anschliessend folgt eine Beschreibung der Funktionen, die zur Unterstützung mehrerer Prozesse dienen. Zur Charakterisierung wird bei jeder Funktion angegeben, in welcher Art die Funktionen auf die einzelnen Datenbestände zugreifen. Ein mit X markierter Zugriff bezeichnet dabei eine verändernde Transaktion, während ein mit x markierter Zugriff eine ausschliesslich lesende Transaktion bedeutet Marketingfunktionen Abb. 7-3 illustriert die IS-Unterstützung des Marketingprozesses. Jeder einzelnen Aufgabe des Prozesses sind die unterstützenden IS-Funktionen zugeordnet. Die Funktionen Kampagnenmanagement und Kundensegmentierung unterstützen ausschliesslich den Marketingprozess. Sie sind in Anhang C.1 detailliert beschrieben.

131 IS-Architektur 117 Kanalunabhängige Funktionen Verwaltung von Basisinformationen Analysen und Berichte Kampagnenmanagement Kundensegmentierung Informationsbereitstellung Analysen und Berichte Bank Prozess Marketing Kundenkontaktierung Cross-Selling- u. Event-Auswertung Kampagnenauswertung Kampagneninitialisierung Kampagnendurchführung Kanalspezifische Funktionen Web Publishing Opportunitymanagement Kundenmanagement Produktkatalog Beraterarbeitsplatz Mailing- Unterstützung Call Center- Unterstützung Abb. 7-3: IS-Unterstützung des Marketingprozesses:

132 118 IS-Architektur Verkaufsfunktionen Abb. 7-4 illustriert die IS-Unterstützung des Verkaufsprozesses. Die kanalspezifischen Funktionen unterstützen die Kundenkommunikation in allen Aufgaben des Prozesses. Sie sind daher nicht einzelnen Aufgaben zugeordnet. Spezifisch für den Verkaufsprozess sind die Funktionen Kundenbedarfsanalyse, Produktkonfiguration, Angebotsmanagement und Auftrags-/Vertragsmanagement, deren Beschreibungen sich in Anhang C.2 finden. Kanalunabhängige Funktionen Verwaltung von Basisinformationen Beraterarbeitsplatz Produktkatalog Beratungsempfehlung Kundenbedarfsanalyse Produktkonfiguration Angebotsmanagement Auftrags-/Vertragsmanagement Kundenmanagement Opportunitymanagement Kundenmanagement Opportunitymanagement Bank Prozess Verkauf Vorbereitung auf Kundenberatung Kundenbedarf analysieren Produkte präsentieren Individuelles Angebot erstellen Konditionen vereinbaren Vertrag abschliessen Nachbearbeitung u. Datenpflege Kanalspezifische Funktionen Web Publishing Personalisierte Informationen Call Center- Unterstützung Elektronische Auftragserteilung Elektronische Zahlungsabwicklung Abb. 7-4: IS-Unterstützung des Verkaufsprozesses

133 IS-Architektur Servicefunktionen Abb. 7-5 illustriert die IS-Unterstützung des Serviceprozesses. Einige der kanalspezifischen Funktionen unterstützen die Kundenkommunikation in allen Aufgaben des Prozesses und sind daher nicht einzelnen Aufgaben zugeordnet. Kanalunabhängige Funktionen Kundentransaktionen Kundenmanagement Service Request Management Servicelogistik Verwaltung von Basisinformationen Produktkatalog Analysen und Berichte Servicevertragsverwaltung Beschwerdemanagement Bank Prozess Service Anfrage entgegennehmen P Auskunft erteilen/ Servicetätigkeit durchführen Beschwerde bearbeiten Beschwerden auswerten Auftrag entgegennehmen Ausschliesslich den Serviceprozess unterstützen die Funktionen Service Request Management, Servicelogistik, Servicevertragsverwaltung, Beschwerdemanagement und Kundentransaktionen sowie die kanalspezifischen Funktionen Electronic Banking und Homebanking-Unterstützung. Die Funktionen sind in Anhang C.3 ausführlich beschrieben. Auftragsausführung auslösen Benachrichtigung entgegennehmen Kunden benachrichtigen Kanalspezifische Funktionen Web Publishing Personalisierte Informationen Call Center- Unterstützung Electronic Banking Beraterarbeitsplatz Homebanking- Unterstützung Abb. 7-5: IS-Unterstützung des Serviceprozesses

134 120 IS-Architektur Kundenprozessunterstützungs-Funktionen Abb. 7-6 illustriert die IS-Unterstützung des Prozesses Kundenprozessunterstützung. Keine der Funktionen unterstützt ausschliesslich diesen Prozess. Die prozessübergreifenden Funktionen sind in Anhang C.5 und C.6 beschrieben. Kanalunabhängige Funktionen Kundenmanagement Bank Prozess Kundenprozessunterstützung Präferenzen u. Dokumente speichern Persönliche Informationen bereitstellen Kanalspezifische Funktionen Personalisierte Informationen Regelmässig Ereignisse prüfen Kunden benachrichtigen Mailing- Unterstützung Call Center- Unterstützung Abb. 7-6: IS-Unterstützung des Prozesses Kundenprozessunterstützung

135 IS-Architektur Portalbetriebsfunktionen Abb. 7-7 illustriert die IS-Unterstützung des Portalbetriebsprozesses. Die verschiedenen kanalspezifischen Funktionen unterstützen sowohl Erstellung als auch Bereitstellung und Pflege der Portalinhalte. Sie sind daher nicht den einzelnen Aufgaben zugeordnet. Spezifisch zur Unterstützung des Portalbetriebsprozesses dienen die IS-Funktionen Linksammlungen, Community-Funktionen, Internetauktionen und Marktplatz. Sie sind in Anhang C.4 näher beschrieben. Kanalunabhängige Funktionen Internetauktionen Produktkatalog Verwaltung von Basisinformationen Bank Prozess Portalbetrieb Interne Erstellungsmöglichkeit prüfen Portalinhalte erstellen Portalinhalte extern beschaffen Portalinhalte bereitstellen Portalinhalte pflegen Kanalspezifische Funktionen Web Publishing Linksammlungen Community- Funktionen Marktplatz Elektronische Auftragserteilung Elektronische Zahlungsabwicklung Abb. 7-7: IS-Unterstützung des Portalbetriebsprozesses Prozessübergreifende Funktionen Einige wichtige IS-Funktionen unterstützen mehrere Prozesse sowie verschiedene Vertriebskanäle. Dies ist eine wesentliche Voraussetzung, damit man die Ziele des Customer Relationship Management (vgl. Kapitel 2.1) erreichen kann, die eine Integration der Prozesse und der Vertriebskanäle beinhalten. Zu den kanalunabhängigen, prozessübergreifenden Funktionen gehören Kundenmanagement, Opportunity-Management, Verwaltung von Basisinformationen, Produktkatalog sowie Analysen und Berichte, siehe Anhang C.5. Die kanalspezifischen, prozessübergreifenden Funktionen sind Call Center-Unterstützung, Beraterarbeitsplatz, Mailing-Unterstützung, Web Publishing, Personalisierte Informationsbereitstellung, elektronische Auftragserteilung, elektronische Zahlungs-

136 122 IS-Architektur abwicklung und Partner Relationship Management. Sie sind in Anhang C.6 näher erläutert Unterstützungsfunktionen Gemäss der in Kapitel 4.2 dargestellten Kategorisierung von Prozessen und Funktionen werden die oben beschriebenen Geschäftsfunktionen ergänzt um Unterstützungsfunktionen, auf welche die Unterstützungsprozesse (s. Kapitel 6.3.3) zugreifen. Analog zu den Unterstützungsprozessen ist es nicht Bestandteil der Arbeit, die Unterstützungsfunktionen detailliert und vollständig zu beschreiben. Im Folgenden werden aber einige wichtige Unterstützungsfunktionen erläutert, wie sie auch häufig in CRM- Standardsoftware zu finden sind. Der Prozess Verkaufsunterstützung setzt u.a. folgende Funktionen ein: Verkaufsführung Die Verkaufsführung beinhaltet die Erstellung von Verkaufsstatistiken und -berichten, die Überwachung von Zielvorgaben, das Management von Anreizen und Provisionen und das Forecasting. Aktivitätenmanagement Das Aktivitätenmanagement ist zuständig für das Führen von Terminen in Einzelund Gruppenkalendern, für die Verwaltung von To-Do-Listen und für die Zuordnung und Delegation von Aktivitäten. Gebietsmanagement Das Gebietsmanagement erlaubt eine Zuordnung von Kunden oder Aktivitäten zu Mitarbeitern nach geographischen Kriterien. Spesenverwaltung Die Spesenverwaltung ermöglicht den Mitarbeitern im Aussendienst eine einfache Abrechnung der angefallenen Spesen. Funktionen zur Unterstützung der Front-Office-Mitarbeiter in den CRM-Prozessen werden meist in einem integrierten Beraterarbeitsplatz zusammengefasst. Der Beraterarbeitsplatz selbst zählt zwar zu den Geschäftsfunktionen, da er die Geschäftsprozesse direkt unterstützt (s. Kapitel ), er integriert aber Geschäfts- und Unterstützungsfunktionen und stellt diese dem Mitarbeiter strukturiert zur Verfügung. Die wesentliche Aufgabe des Beraterarbeitsplatzes ist es, dem Mitarbeiter Zugang zu allen relevanten Funktionen und Applikationen zu gewähren und ihm durch eine geeignete Strukturierung die Navigation zu erleichtern. Die Bildschirmmaske des Prototyps eines Beraterarbeitsplatzes für Banken ist in Abb. 7-8 abgebildet. Die Bildschirmmaske zeigt dem Benutzer alle relevanten Kundendaten auf einen Blick (Stammdaten, Kontostände, Pendenzen, History, Produktnutzungsstatistik, ). Über die horizontale Navigationsleiste am oberen Rand kann der Berater

137 IS-Architektur 123 in verschiedene Teilprozesse wie z.b. Kundenanalyse oder Service-Anfrage direkt einsteigen. Das vertikale Menü am linken Rand erlaubt einen schnellen, direkten Sprung zu verschiedenen Funktionen wie z.b. Produktinformationen oder Kampagnenmanagement. Der Beraterarbeitsplatz-Prototyp ist im Detail in [Schmid/Bach 2000c] dokumentiert. Im weitesten Sinne handelt es sich bei einem Beraterarbeitsplatz um eine Wissensplattform. Das Thema Wissensplattformen wird in [Jansen 2000] detailliert behandelt. Abb. 7-8: Prototyp eines CRM-Beraterarbeitsplatzes bei Banken Einige Unterstützungsprozesse wie z.b. das Content Management, das Kundensegmentmanagement und das Kanalmanagement werden i.d.r. durch speziell dafür konzipierte Anwendungen unterstützt. Ein Content Managementsystem stellt z.b. Funktionen für Versionskontrolle, Archivierung, Metadatenverwaltung, Workflow- Unterstützung des Redaktionsprozesses, Content-Strukturierung etc. zur Verfügung [vgl. Christ 2001]. Ebenfalls zu den Unterstützungsfunktionen zählen allgemeine, prozessunabhängige Funktionen wie Suche, Site Map, Stichwortverzeichnis, Feedback-Formular etc. Diese Funktionen können auf beliebigen Oberflächen eingesetzt werden, also z.b. im Beraterarbeitsplatz oder in einem Internetportal für die Kunden. Prozessübergreifende Unterstützung bieten die Workflow-Funktionalitäten. Sie dienen dazu, Prozessabläufe zu automatisieren und die standardisierte Durchführung der Ab-

138 124 IS-Architektur läufe sicherzustellen [vgl. Österle/Vogler 1996]. Als Beispiel für eine Workflow- Funktion mit grafischer Oberfläche zeigt Abb. 7-9 die Workflow-Komponente der Siebel-Standardsoftware (vgl. Kapitel 0). Abb. 7-9: Workflow-Funktion von Siebel Weitere Unterstützungsfunktionen technischer Art sind z.b. Synchronisations- und Replikationsmechanismen, Computer Telephony Integration, Integration von Office- Anwendungen und Upgrade-Funktionen. Neben den rein technischen Unterstützungsfunktionen auf IS-Ebene kommen auch organisatorische Instrumente zum Einsatz, um Effizienz oder Qualität der Geschäftsprozesse zu verbessern. Aus dem Bereich des Wissensmanagements seien hier zum Beispiel Knowledge Networks genannt, die den direkten Austausch zu bestimmten Themen (z.b. Verkaufswissen) oder bestimmten Fachfragen unterstützen. Das Thema Wissensmanagement wird in [Bach 2000; Thiesse 2001] ausführlich behandelt.

139 IS-Architektur Gestaltungsdeterminanten Wie bei der Prozessarchitektur handelt es sich auch bei der oben beschriebenen Funktionsarchitektur um ein generisches Modell, das nicht auf unternehmens- oder projektspezifische Besonderheiten eingeht. Analog den Gestaltungsdeterminanten auf Prozessebene (s. Kapitel 6.5) werden im Folgenden ein Vorschlag für Gestaltungsdeterminanten auf IS-Ebene dargestellt. Diese sollen den Zusammenhang zwischen typischen Projektszenarien und den Anforderungen an die IS-Architektur darstellen. Die IS-Funktionen zur Unterstützung von Mensch-Maschine-Kanälen werden auch durch die in Kapitel 3.1 definierten Portalkriterien beeinflusst. Die Darstellung orientiert sich an möglichen Projektschritten einer Bank auf dem Weg zum Prozessportalbetreiber, wie sie in Kapitel 6.5 beschrieben sind. Die Basis für die IS-Architektur bilden die in Abb. 7-1 aufgeführten kanalunabhängigen Funktionen. Diese unterstützen die grundlegenden CRM-Prozesse und sind in allen Entwicklungsstufen erforderlich. Unterschiedliche Anforderungen sind vor allem bei den kanalspezifischen Funktionen erkennbar Kernleistungen über herkömmliche Mensch-Mensch-Kanäle Eine klassische Bank, die ausschliesslich Kernleistungen über herkömmliche Mensch- Mensch-Kanäle anbietet, benötigt im Wesentlichen einen Beraterarbeitsplatz, welcher den Mitarbeitern den Zugriff auf alle kanalunabhängigen Funktionen und damit auch auf alle Datenbestände ermöglicht (vgl. auch Kapitel 7.1.3). Der Beraterarbeitsplatz sollte prozessorientiert gestaltet sein und den Benutzer durch die verschiedenen Abläufe führen. Zur Unterstützung des Kampagnenmanagements kann zusätzlich die Funktion Mailing-Unterstützung zum Einsatz kommen, damit die Aussendung von Werbesendungen auf dem Postweg im Rahmen von Marketing-Kampagenen erleichtert wird Kernleistungen über neue Kanäle Erweitert die Bank ihre Kernleistungen auf neue Mensch-Mensch-Kanäle (Contact Center) und auf Mensch-Maschine-Kanäle, so sind zusätzliche kanalspezifische Funktionen erforderlich. Die Call Center-Unterstützung ähnelt dem Beraterarbeitsplatz, ist jedoch den spezifischen Gegebenheiten des Call Centers angepasst. Insbesondere beinhaltet sie Funktionen zur detaillierten Gesprächsführung (Call Scripting). Wird eine Unterstützung des Web realisiert, so sind die IS-Funktionen Web Publishing, Elektronische Auftragserteilung und Electronic Banking erforderlich. Das Web Publishing unterstützt die Bereitstellung von Informationen im Web und damit in erster Linie den Marketingprozess. Die elektronische Auftragsterteilung dient der Unterstützung des Verkaufsprozesses z.b. durch die Möglichkeit, ein Konto via Web zu eröffnen. Die Auftragsabwicklung im Serviceprozess wird durch Electronic Banking realisiert. Hier kann der Kunde Aufträge erteilen und Kontoinformationen abrufen.

140 126 IS-Architektur Damit beim späteren Betrieb eines Prozessportals die Erfolgskriterien (s. Kapitel 3.1) berücksichtigt werden können, müssen einige davon bereits bei diesem Entwicklungsschritt beachtet werden: Die geforderte einheitliche Bedienung (vgl. Kapitel 3.1.1) sollte durch eine benutzerfreundliche und einheitlich gestaltete Portaloberfläche über den gesamten Webauftritt hinweg realisiert werden. Dem Kunden sollte insbesondere das Informationsangebot und das Electronic Banking als ein System erscheinen. Eine klare Trennung von Inhalt und Layout sollte auch bei zu Beginn wenigen Inhalten befolgt werden. Verfügbarkeit und Performance der Infrastruktur sollte so ausgelegt werden, dass der Kunde das Angebot zu beliebigen Zeitpunkten nutzen kann (vgl. 24h Verfügbarkeit, Kapitel 3.1.2) und dass er keine langen Antwortzeiten in Kauf nehmen muss. Dabei ist zu beachten, dass interaktive Webanwendungen wie z.b. das Electronic Banking deutlich höhere Performanceanforderungen stellen als der reine Abruf standardisierter Webseiten. Die Systeme und Kanäle müssen bankweit integriert sein (vgl. Volle Kanalintegration, Kapitel und Prozess- und Systemintegration, Kapitel 3.1.4). Ein via Web erteilter Auftrag muss auch im Call Center oder in der Filiale bearbeitet werden können; ein erteilter Zahlungsauftrag muss automatisch an die Abwicklungssysteme im Backoffice übergeben werden. Die Datensicherheit beim Umgang mit Kundendaten muss gewährleistet sein (vgl. Hoher Sicherheitsstandard, Kapitel 3.1.4). Electronic Banking und elektronische Auftragserteilung müssen auf der Basis moderner Sicherheitsstandards implementiert werden Standardisierte Zusatz- und Infrastrukturleistungen über neue Kanäle Für die Realisierung standardisierter Zusatzleistungen sind die bereits oben genannten IS-Funktionen Web Publishing und Elektronische Auftragserteilung sowie die elektronische Zahlungsabwicklung erforderlich. Ausserdem können anwendungsspezifische Funktionen wie z.b. Linksammlungen zum Einsatz kommen. Zusätzliche Anforderungen an die Infrastruktur entstehen vor allem durch die Einbindung von Kooperationspartnern: Die Inhalte der Kooperationspartner müssen ebenfalls den einheitlichen Oberflächenstandards genügen und nahtlos in die Oberfläche integriert werden (vgl. Volle Integration der Partnerleistungen, Kapitel 3.1.1). Dazu ist es auch erforderlich, dass der Partner ebenfalls konsequent Inhalt und Layout trennt. Wo auf Prozessebene Schnittstellen zwischen der Bank und den Partnern bestehen, müssen auch die Systeme integriert sein (vgl. Prozess- und Systemintegration,

141 IS-Architektur 127 Kapitel 3.1.4). Insbesondere sollten die Partner direkt in das Content Management des Portals eingebunden sein, um eine zuverlässige und schnelle Veröffentlichung neuer Inhalte zu ermöglichen. Werden elektronische Auftragserteilung und Zahlungsabwicklung im Rahmen des E-Commerce zur Bestellung von Produkten oder Dienstleistungen bei Partnern eingesetzt, so müssen die Aufträge ohne manuelle Intervention die entsprechende Abwicklung bei den Partnern auslösen. Dies erfordert ebenfalls eine volle Integration der Prozesse und der Systeme (vgl. Prozess- und Systemintegration, Kapitel 3.1.4). Für elektronische Auftragserteilung und Zahlungsabwicklung gelten wie beim Electronic Banking höchste Sicherheitsstandards (vgl. Hoher Sicherheitsstandard, Kapitel 3.1.4). Für die Realisierung standardisierter Infrastrukturleistungen werden spezifische IS- Funktionen für den jeweiligen Zweck eingesetzt, z.b. Marktplatz, Auktionen, und Community-Funktionen. Neben den bereits genannten Anforderungen sind hier besonders die hohen Performance-Anforderungen zu beachten, da es sich um interaktive Anwendungen handelt. Auch wenn diese von den Benutzern intensiv genutzt werden, darf die Zufriedenheit der Kunden nicht durch lange Antwortzeiten aufs Spiel gesetzt werden Individualisierte Zusatz- und Infrastrukturleistungen Damit das Prozessportal vervollständigt werden kann, ist die Bereitstellung individualisierter Zusatz- und Infrastrukturleistungen erforderlich. Diese ermöglichen eine individuelle Behandlung der Kunden auch im Web und stellen weitere Zusatzleistungen bereit, welche als Annehmlichkeiten im Sinne der Erfolgskriterien betrachtet werden können. Personalisierungsfunktionen und weitere spezifische Funktionen unterstützen diese Leistungen. Während alle bereits genannten Anforderungen auch in diesem Bereich gelten, sind einige zusätzliche Massnahmen zu treffen: Mit der Implementierung individualisierter Leistungen steigen die Anforderungen an die Performance der Infrastruktur nochmals. Für jeden Benutzer müssen individuelle Berechnungen durchgeführt werden und individuelle Daten gespeichert werden. Dies ist bei der Dimensionierung der Server und der Netzwerkkomponenten zu berücksichtigen. Um das Vertrauen der Kunden zu behalten, müssen umfassende Massnahmen im Bereich Datenschutz getroffen werden, sobald kundenindividuelle Daten gespeichert und verarbeitet werden. Dies betrifft sowohl die Abgabe von Datenschutzgarantien (z.b. Daten werden keinesfalls weitergegeben ) als auch die Realisierung hoher Sicherheitsstandards (vgl. Datenschutzgarantien, Kapitel und Hoher Sicherheitsstandard, Kapitel 3.1.4).

142 128 IS-Architektur Die individualisierten Funktionen des Portals müssen nahtlos mit allen anderen Funktionen zusammenarbeiten. Insbesondere muss eine personalisierte Homepage auch die selektive Bereitstellung sämtlicher standardisierter Leistungen beinhalten. Eine vollständige Systemintegration und ein klares Personalisierungskonzept sind hierfür Voraussetzung (vgl. Personalisierung und Kundenprofile, Kapitel.3.1.2). 7.3 Applikationen Nach der Definition in Kapitel 4.1 führen Applikationen Funktionen aus, die meist in einem logischen Zusammenhang zueinander stehen. Der genaue Funktionsumfang einer Applikation wird vom Hersteller bzw. Entwickler festgelegt, der Funktionsumfang einer Applikation kann daher nur herstellerabhängig angegeben werden. Ein detaillierter Vergleich der Funktionalitäten verschiedener Lösungen ist nicht Bestandteil der vorliegenden Arbeit. Detaillierte Marktübersichten findet man z.b. in [Schulze/Bach 1999; Wilde/Hippner 2000]. Die nachfolgend beschriebene Applikationsarchitektur bezieht sich auf den oben definierten Funktionsumfang in den Bereichen Customer Relationship Management und Portale. Eine umfassende e-business Applikationsarchitektur ist z.b. in [Kalakota/Robinson 1999] beschrieben. Verschiedene e-businessbezogene Architekturaspekte werden auch in [Treese/Stewart 1998, S.83ff.] behandelt. Im Folgenden wird zunächst eine Applikationstypologie vorgestellt, anhand der die gängigen Applikationstypen und die zugehörigen Begriffe strukturiert werden. Ausserdem werden Anforderungen an eine Applikationsarchitektur definiert. Anhand der vorgestellten Typologie werden die Softwareprodukte ausgewählter Hersteller vorgestellt und eingeordnet. Die Einbettung einzelner Produkte in die gesamte Applikationsarchitektur wird anschliessend anhand von Fallbeispielen einzelner Anwender dargestellt Applikationstypen Für den im Rahmen der hier beschriebenen Architektur definierten Funktionsumfang (s. Kapitel 7.1.2) haben sich verschiedene Applikationstypen etabliert (s. Abb. 7-10), die jeweils durch einen charakteristischen Funktionsumfang gekennzeichnet sind [vgl. Ernst & Young 1999, S.77ff.]. Den Kern der Typologie bilden die folgenden drei Applikationstypen: Enterprise Marketing Automation -Applikationen (EMA) unterstützen das Kampagnenmanagement im Marketingprozess. Sales Force Automation (SFA) bzw. Computer Aided Selling (CAS) Anwendungen unterstützen den Verkaufsprozess [vgl. Schulze 2000, S.10f.]. Die wichtigsten Funktionen sind Kunden- und Opportunity-Management sowie die Verkaufsführung.

143 IS-Architektur 129 Customer service and support -Applikationen (CSS) unterstützen den Serviceprozess und umfassen Funktionen wie Service Request Management, Service-Logistik und Servicevertragsverwaltung. Diese drei Applikationstypen (CSS, SFA, EMA) bilden zusammen die sogenannten Front-Office-Anwendungen. Seit etwa 1998 ist ein Zusammenwachsen von CSS-, SFA- und EMA-Software zu beobachten. Der neu entstandene Applikationstyp, der die drei CRM-Prozesse Marketing, Verkauf und Service integriert unterstützt, wird als Customer Relationship Management -Applikation (CRM) oder Enterprise Relationship Management -Applikation (ERM) bezeichnet. Allen bisher genannten Applikationstypen ist gemeinsam, dass sie sich auf Mensch- Mensch-Vertriebskanäle konzentrieren. Die Funktionalitäten unterstützen v.a. den stationären und mobilen Vertrieb und Service sowie das Call-Center. Erst neuerdings integrieren die Hersteller von CRM- und ERM-Software Funktionalitäten zur Unterstützung von Maschine-Mensch-Kanälen, insbesondere des World Wide Web. Diese Applikationen werden mit E-CRM oder erelationship management bezeichnet [vgl. Gormley 1999]. Der Begriff CRM-Applikation wird im Folgenden als Überbegriff für CRM, ERM, E-CRM und erm verwendet. Prozesse Marketing Verkauf Service andere Kanäle Mehrstufen- Kanäle Partner Relationship Management Mensch- Mensch CRM/ ERM Enterprise Marketing Automation E-CRM/ erm Sales Force Automation / Computer Aided Selling Customer Service and Support Abwicklungs- Systeme (Host, ERP) Data Warehouse Data Marts Maschine- Mensch Portalsoftware Data Mining Internet-Banking Maschine- Maschine Abb. 7-10: Applikationstypologie Unter dem Namen Partner Relationship Management (PRM) versteht man Lösungen, die es erlauben, CRM-bezogene Daten mit Kooperationspartnern auszutauschen,

144 130 IS-Architektur um so z.b. eine unternehmensübergreifende Kundensicht zu ermöglichen. Insbesondere dienen PRM-Komponenten dazu, Mehrstufen-Kanäle zu vereinfachen, indem die Vertriebspartner direkten Zugriff auf Kundeninformationen erhalten. PRM kann nicht als eigener Applikationstyp angesehen werden, da er die CRM-Applikationen nur um eine weitere Vertriebskanalunterstützung ergänzt. Vielmehr ist PRM eine Funktion, die von Herstellern oft als eigenes Modul verkauft wird [vgl. Aberdeen Group 2000]. Vielfach realisieren Unternehmen keinen direkten Datenaustausch zwischen den Front-Office-Systemen und den Abwicklungssystemen bzw. operativen Datenbeständen. Stattdessen wird ein Data Warehouse eingesetzt, das die Daten aller angeschlossenen Systeme sammelt und in konsistenter Form für Abfragen bereitstellt. Oft werden abteilungs- oder themenbezogene Ausschnitte des gesamten Datenbestandes in sogenannten Data Marts organisiert. Diese sind übersichtlicher und leichter handhabbar als ein gesamtes Data Warehouse. Zur Analyse der Datenbestände werden Data Mining-Applikationen eingesetzt. Diese analysieren grosse Datenbestände nach gegebenen Mustern, um so bestimmte Zusammenhänge ersichtlich zu machen. Für weiterführende Informationen zum Thema Data Warehousing und Data Mining sei auf [Inmon 1996; Berson/Smith 1997; Chaudhuri/Dayal 1997; Jung/Winter 2000] verwiesen. Die in E-CRM-Applikationen vorhandenen Funktionen zur Unterstützung von Maschine-Mensch-Kanälen decken meist nur einen Teil der Portalfunktionen ab. Sie beschränken sich im Wesentlichen auf die Bereitstellung von Informationen über Produkte und Dienstleistungen, auf die elektronische Bestellabwicklung und auf den Zugriff auf Supportdatenbanken. Weitergehende Funktionen, die zur Realisierung von Prozessportalen erforderlich sind, wie virtuelle Communities (Diskussionsforen, Chat), Auktionen, personalisierte Informationsangebote etc., erfordern den Einsatz von Portal-Standardsoftware oder von spezialisierten Anwendungen. Neben den eigentlichen Funktionen zur Serviceunterstützung sind dem Serviceprozess auch die Entgegennahme und Bestätigung von Kundentransaktionen zugeordnet. Im Privatkundengeschäft bei Banken gehören dazu z.b. die Entgegennahme von Überweisungsaufträgen und Wertpapierorders sowie die Übermittlung von Auftragsbestätigungen und Kontoauszügen. Diese Funktionen werden von vielen CRM-Lösungen bisher nicht abgedeckt. In den Mensch-Mensch-Kanälen erfassen die Mitarbeiter die Daten in speziellen Bankapplikationen, häufig direkt im Abwicklungssystem. In den Maschine-Mensch- und Maschine-Maschine-Kanälen werden diese Funktionen unter dem Begriff Internet-Banking zusammengefasst. Diese werden ebenfalls durch spezielle, meist eigenentwickelte Lösungen realisiert. In der Regel bieten CRM-Lösungen im Bereich der Maschine-Maschine-Schnittstellen keine Funktionalität an.

145 IS-Architektur Anforderungen an eine Applikationsarchitektur Eine Applikationsarchitektur soll die betrieblichen Abläufe effizient und reibungslos unterstützen. Beim Applikationsentwurf und bei der Architekturplanung sollten daher die folgenden Eigenschaften berücksichtigt werden. Je nach Art und Charakteristika der einzelnen Anwendungen müssen nicht grundsätzlich alle Anforderungen vollumfänglich erfüllt werden. Aufwand-Nutzen-Analysen können hier dazu dienen, die geeigneten Massnahmen zu identifizieren. Die folgenden Architekturanforderungen wurden aus Darstellungen in [Cook 1996; Riehm/Vogler 1996; Sinz 1999b, S.1060ff.; Huber 2000b, S.143ff.] hergeleitet. Redundanzfreie Datenhaltung: Für jeden Datenbestand (z.b. Kundendaten, Produktdaten etc., s. Kapitel ) muss im Unternehmen genau eine massgebliche Datenbasis vorhanden sein. Alle Anwendungen müssen auf diese Datenbasen Zugriff haben. In der Regel ist es nicht möglich, jeden Datenbestand auf genau ein System zu beschränken, da verschiedene Anwendungen im Einsatz sind, die über eigene Datenhaltungen überlappender Datenbestände verfügen. Z.B. verwalten sowohl ERP- als auch CRM-Systeme bestimmte Kundendaten. Oft ist auch aus Verfügbarkeitsgründen eine verteilte oder redundante Datenhaltung erforderlich. In diesen Fällen muss die Konsistenz der einzelnen Datenbestände durch Integrations-, Replikations- und Synchronisationsmechanismen garantiert werden. Volle Integration: Alle Anwendungen müssen sowohl lesend als auch schreibend auf die unternehmensweiten Datenbestände zugreifen können. Z.B. muss eine im CRM-System vorgenommene Kundenadressänderung auch im ERP-System wirksam werden und umgekehrt. Integration in Echtzeit: Allen Anwendungen müssen jederzeit die aktuellen Daten zur Verfügung stehen, d.h. Änderungen müssen möglichst schnell in den unternehmensweiten Datenbeständen wirksam werden (Schreibzugriff). Für den rein lesenden Datenzugriff bestimmt jede Anwendung selbst die Anforderungen an die Aktualität der Daten. Vermeidung von Medienbrüchen: Es sollten möglichst wenige Konvertierungsschritte von einem Medium in ein anderes erforderlich sein. Z.B. sollten via Internet eingehende Aufträge nicht manuell im Abwicklungssystem erfasst werden, sondern automatisch übernommen werden. Konvertierungen sollten ausschliesslich direkt an der Kundenschnittstelle erfolgen, z.b. durch sofortiges Digitalisieren eingehender Briefe und Faxe. Minimierung der Anzahl von Schnittstellen: Sollen alle Systeme direkt miteinander verbunden werden, so steigt der Integrationsaufwand quadratisch mit der Anzahl der Systeme. Durch den Einsatz von Middleware kann dies auf einen linearen Aufwand reduziert werden, dennoch ist pro System eine Schnittstelle zu realisieren [s. Cook 1996, S.137ff.; vgl. Rajput 2000, S.232ff.]. Um den Integrationsaufwand

146 132 IS-Architektur zu minimieren, sollte also die Anzahl der eingesetzten Systeme minimiert werden. Da der Aufwand für die Integration verschiedener Hersteller meist höher ist als derjenige für die Integration verschiedener Systeme eines Herstellers, ist es zudem sinnvoll, die eingesetzten Systeme von möglichst wenigen Herstellern zu beziehen Applikationsarchitekturen ausgewählter Hersteller Die folgenden Abschnitte veranschaulichen die Applikationsarchitekturen ausgewählter CRM-Anbieter. Das Ziel ist dabei, die Architekturen einiger bekannter und verbreiteter Hersteller beispielhaft aufzuzeigen und die einzelnen Komponenten in die oben beschriebene Applikationstypologie einzuordnen. Es ist nicht das Ziel, einen vollständigen Marktüberblick zu geben [vgl. Wilde/Hippner 2000] oder Bewertungen der einzelnen Lösungen vorzunehmen, da diese Informationen sich sehr schnell ändern und bereits beim Erscheinen der Dissertation veraltet wären. Die Auswahl der Anbieter erfolgte nicht nach formalen Kriterien. Die Berücksichtigung oder Nichtberücksichtigung in den folgenden Darstellungen lassen keine Rückschlüsse auf Marktanteile, Qualität etc. zu. Es werden ausschliesslich Anbieter von E- CRM-Lösungen betrachtet. Für einen Überblick über Anbieter von Portallösungen sei auf [Jansen 2000, S.96ff.] verwiesen SAP SAP bezeichnet sich als der weltweit führende Anbieter von E-Business-Softwarelösungen. Das 1972 gegründete Unternehmen zählt mittlerweile etwa Beschäftigte. Neben seinem Haupt-Entwicklungszentrum am Stammsitz in Walldorf unterhält SAP Entwicklungslabors in Palo Alto (USA), Tokio, Bangalore (Indien) und Sophia Antipolis (Frankreich) sowie in Berlin, Karlsruhe und Saarbrücken. Mit Niederlassungen in mehr als 50 Ländern erzielte die SAP im Geschäftsjahr 1999 einen Umsatz von 5,11 Milliarden Euro. Die Aktien der SAP werden unter anderem an den Börsen in Frankfurt am Main und New York gehandelt.

147 IS-Architektur 133 Kanäle Prozesse Marketing Verkauf Service andere Mehrstufen- Kanäle Mensch- Mensch Maschine- Mensch Customer Relationship Management ecommerce Workplace Core Banking Business Intelligence & Data Warehousing Maschine- Maschine Abb. 7-11: Bankenspezifische Applikationsarchitektur von SAP mysap.com ist die e-business-plattform der SAP für die Integration aller relevanten Geschäftsprozesse über das Internet. Die mysap.com e-business Solutions umfassen folgende Lösungen: Customer Relationship Management, E-Commerce, Supply Chain Management, Product Lifecycle Management, Business Intelligence, Financials, Human Resources. Abb zeigt die verschiedenen Applikationskomponenten, die zur Abdeckung des in Kapitel beschriebenen Funktionsumfangs erforderlich sind. Die Architektur bezieht sich auf die bankspezifischen Lösungen von SAP. Die beteiligten SAP- Produkte sind Customer Relationship Management, ecommerce, Workplace, Core Banking und Enterprise Management. Diese werden im Folgenden einzeln beschrieben: Das Standardprodukt Customer Relationship Management ist im Rahmen der SAP Banking-Lösungen branchenspezifisch angepasst verfügbar. Es deckt die Unterstützung der Front-Office-Prozesse Marketing, Verkauf und Service über Mensch-Mensch, Mensch-Maschine und Mehrstufen-Kanäle ab. SAP Banking CRM gliedert sich in die funktionalen Bereiche Marketing Program Management, Sales Management, Customer Service, Market Research & Analysis und Product / Brand Marketing. Neben den Front-Office-Prozessen wird damit auch der Produktentwicklungsprozess unterstützt.

148 134 IS-Architektur MySAP e-commerce unterstützt Einkauf und Verkauf über Internet. Die Verkaufsseite mysap Selling umfasst die Produkte SAP Internet Sales und SAP Online Store. Diese bieten Funktionalitäten zur internetbasierten Unterstützung des Verkaufsprozesses im Rahmen des CRM und für den Produktverkauf über Internet. Dazu gehören Funktionen wie Produktkatalog, One-to-one-Marketing, Online- Produktkonfiguration und Verfügbarkeitsprüfung. SAP Workplace ist ein Produkt zur Realisierung von Portalen. Es erlaubt die Erstellung einer personalisierten Oberfläche auf Basis eines Rollenmodells. Abhängig von der jeweiligen Rolle, die der Nutzer von SAP Workplace einnimmt (z.b. Key Account Manager, Einkäufer, Sachbearbeiter oder auch Kunde), stellt ihm SAP Workplace den Zugang zu den passenden Applikationen und Inhalten zur Verfügung [vgl. Jansen et al. 2000, S.122f.]. Abb zeigt den Bildschirmaufbau von SAP Workplace, wie er sich dem Nutzer darstellt. Auf der linken Seite steht eine Navigationsleiste zur Verfügung, die den Zugang zu verschiedenen Funktionen ermöglicht. Es stehen sowohl die Funktionen der SAP-Applikationen zur Verfügung als auch Funktionen anderer Anwendungen und Inhalte aus dem Internet. Auf der rechten Seite kann der Nutzer häufig genutzte Funktionen und Inhalte in Form von sogenannten Mini-Apps direkt in den Workplace integrieren. Da SAP Workplace nur den Zugang zu anderen Applikationen ermöglicht, selbst aber keine der spezifizierten IS-Funktionen abdeckt, ist SAP Workplace keine Portalsoftware im Sinne der oben dargestellten Applikationstypologie. SAP Workplace stellt hingegen verschiedene Unterstützungsfunktionen bereit.

149 IS-Architektur 135 Abb. 7-12: SAP Workplace (Quelle: [SAP AG 2000a]) SAP Core Banking deckt verschiedene Back-Office-Prozesse der Banken ab. Es unterteilt sich in die Bestandteile Bank Customer Accounts (BCA) und Core Banking Mortgage Loans (CML). BCA umfasst Funktionen wie Konto- und Vertragsmanagement, Posten- und Saldenmanagement, Kontoabschluss, Kontoauszug, Scheckmanagement, Dauerauftragsmanagement etc. CML deckt Hypothekenkredite und Baufinanzierungen für Privatkunden ab. Der Funktionsbereich Business Intelligence & Data Warehousing ist Bestandteil des Enterprise Managements. Es deckt die Zusammenführung von Daten in einem Datawarehouse, die Auswertung mit Data Mining und die Generierung von Berichten ab. Mit der SAP Applikationsarchitektur kann ein Grossteil der funktionalen Anforderungen im Front-Office-Bereich abgedeckt werden. Eine Lücke stellt der Bereich Internet- Banking dar, wo mit Fremdprodukten gearbeitet wird. Die Architektur aus der Sicht von SAP ist in Abb dargestellt.

150 136 IS-Architektur Bank Branch Internet Call Center Other Service Providers B u s i n e s s P a r t n e r Collaterals Application Customer Relationship Management Interest Income Tax Account Management Allocation of Funds WP Contracts Items/Balances Requests Cards Settlement Reporting Enterprise Management Business Support Payment Transactions Clearing Routing Abb. 7-13: Bankenarchitektur von SAP (Quelle: [SAP AG 2000a]) Oracle Oracle ist das zweitgrößte Software-Unternehmen der Welt und bezeichnet sich als der führende Anbieter von E-Business-Lösungen für das Internet. Oracle ist in über 145 Ländern vertreten und hat mehr als Beschäftigte. Im Fiskaljahr 2000 (Geschäftsjahresende: 31. Mai 2000) hat das Unternehmen insgesamt einen Umsatz von 10,1 Milliarden US-Dollar erwirtschaftet. Das entspricht einem Wachstum gegenüber dem Vorjahr von rund 15 Prozent. Zur Produktpalette von Oracle zählen Datenbanken, Server und Enterprise Business Applications inkl. Tools. Oracle bietet mit der E-Business Suite eine Applikationsarchitektur an, welche die gesamte Wertschöpfungskette vom Front-Office bis zum Back-Office abdeckt. Diese Architektur ist in Abb dargestellt, wobei nur der Front-Office-Bereich in einzelne Komponenten aufgegliedert ist. Neben der nachfolgend beschriebenen CRM- Lösung bietet Oracle Applikationen in den Bereichen ERP, Enterprise Management, Supply Chain Management und Procurement an (s. Abb. 7-15). Dieses umfassende Leistungsspektrum ermöglicht es, eine gesamte Unternehmensarchitektur nahezu vollständig aus einer Hand zu beziehen und so die Anzahl der Integrationspunkte auf ein Minimum zu reduzieren.

151 IS-Architektur 137 Kanäle Prozesse Marketing Verkauf Service Andere Mehrstufen- Kanäle Mensch- Mensch Maschine- Mensch Marketing Online, Telemarketing, Marketing Encyclopedia (MES) imarketing Partner Relationship Management Sales Online, Telesales istore, ipay Customer Support, Field Service, Scheduler isupport, Center Spares Mgmt, Depot Repair, ServiceContracts Business Intelligence Supply Chain Management Enterprise Management Procurement ERP Maschine- Maschine Abb. 7-14: Applikationsarchitektur der Oracle E-Business Suite Business Intelligence Marketing Sales Service Strategic Enterprise Management Supply Chain Internet Procurement Financials Human resources Projects Travel Management Common Application Architecture & Schema ebusiness Platform Abb. 7-15:E-Business-Architektur von Oracle (Quelle: [Huber 2000a]) Die folgende Aufstellung beschreibt die einzelnen Komponenten der Front-Office- Applikationen im Detail: Der Marketingprozess wird mit den Komponenten Marketing Online, Telemarketing, Marketing Encyclopedia und imarketing unterstützt. Marketing Online stellt

152 138 IS-Architektur kanalübergreifende Marketingfunktionen, v.a. Kampagnenmanagement zur Verfügung. Telemarketing unterstützt das Call Center bei der Kampagnendurchführung. In der Marketing Encyclopedia werden sämtliche marketingrelevanten Informationen zusammengefasst. imarketing ermöglicht personalisierte Online- Marketingkampagnen. Sales Online unterstützt stationäre und mobile Mitarbeiter im Verkaufsprozess. Mobile Sales erweitert die Unterstützung für mobile Mitarbeiter auf Handheld- Geräte wie z.b. Palmtops. Telesales unterstützt den Verkauf im Call Center. Order Capture ist für die Erfassung von Aufträgen verantwortlich und der Configurator erlaubt die individuelle Konfiguration von Produkten und Dienstleistungen. istore und ipay nutzen das Web als Vertriebskanal für Verkauf und Bezahlung. Customer Support unterstützt den Serviceprozess im Call Center, Field Service unterstützt den mobilen Aussendienst, Scheduler ist für die zeitliche Planung der Serviceeinsätze verantwortlich. Über das Internet ermöglicht isupport Serviceleistungen, und das Center erlaubt eine automatische Beantwortung und Weiterleitung von -Anfragen. Spares Management und Depot Repair sind kanalunabhängig für die Ersatzteil-Logistik zuständig, Service Contracts übernimmt die Servicevertragsverwaltung. Partner Relationship Management unterstützt Mehrstufen-Kanäle durch Weiterleitung von Opportunities, Zugriff der Partner auf Kundendaten etc. Unter Business Intelligence ist die Bereitstellung und Auswertung von Informationen in den Bereichen Marketing, Verkauf und Service zusammengefasst. Analytical Applications Marketing Intelligence Sales Intelligence Customer Intelligence Call center Intelligence Business Applications Marketing imarketing MES istore ipay Sales Online Field Sales TeleSales Sales Comp Partner (PRM) isupport Customer Support Field Service Mobile Field Service Depot Repair Spares Mgt Contracts Scheduler Service Collections Contracts CRM Foundation Universal Work Queue Tasks Resources Notes Territories Calendar Assignment Engine 1-on on-1 1 Fulfillment MES Interaction History Interaction Blending Order Capture Interaction Channels E-Business Foundation E-Business Platform Call Center Telephony Manager Scripting Predictive Dialer Center ebusiness Platform Web Common Application Architecture & Schema Mobile Abb. 7-16: CRM-Applikationsarchitektur von Oracle (Quelle: [Huber 2000a])

153 IS-Architektur 139 Oracle erfüllt die funktionalen Anforderungen des Front-Office-Bereiches weitgehend. Portalfunktionalitäten, welche durch die Komponenten der E-Business Suite nicht abgedeckt werden, können mit Hilfe der Entwicklungsumgebung Oracle Portal realisiert werden. Von der Oracle E-Business Suite sind keine speziellen Branchenlösungen verfügbar. Somit fehlen auch bankspezifische Funktionalitäten wie z.b. Online- Kontoeröffnung oder Internet Banking. Abb stellt die CRM- Applikationsarchitektur aus Sicht von Oracle dar Siebel Siebel Systems Inc. wurde 1993 gegründet. Heute beschäftigt Siebel Systems etwa 4500 Personen in mehr als 28 Ländern und bezeichnet sich als weltweiten Marktführer bei ebusiness Applications. In den ersten drei Quartalen erzielte Siebel Systems einen Umsatz von 1,18 Milliarde US-Dollar. Siebel Systems ist Anbieter von E-Business- Lösungen, welche das Marketing, den Verkauf und den Service über verschiedene Vertriebskanäle unterstützen. Einziges Produkt von Siebel Systems ist Siebel 2000, das sich aus einer Vielzahl von Anwendungen zusammensetzt. Kanäle Prozesse Marketing Verkauf Service Andere Mehrstufen- Kanäle Mensch- Mensch Maschine- Mensch Maschine- Maschine Marketing emarketing econfigurator, epricer echannel Sales, Telesales esales Call Center Service, Field Service eservice eauction, ecollaboration, Response, etraining Business Analysis: OLAP Data Mart, Report Server Abb. 7-17: Applikationsarchitektur von Siebel Die verschiedenen Applikationen von Siebel 2000 sind in Abb dargestellt. Für Finanzdienstleister bietet Siebel die Branchenlösung efinance an. Diese basiert auf den branchenübergreifenden Applikationen und passt sie den spezifischen Anforde-

154 140 IS-Architektur rungen der Banken und Versicherungen an. Die folgende Beschreibung stellt die Funktionalitäten der einzelnen Applikationen dar: Siebel Marketing und Siebel emarketing unterstützen den Marketingprozess. Siebel Marketing stellt dazu im Wesentlichen verschiedene Analysefunktionen (Kunden, Produkte, Verkäufe etc.) bereit und bietet Funktionen zur Unterstützung des Kampagnenmanagements. Siebel emarketing erweitert diese Funktionalitäten auf Maschine-Mensch-Kanäle. Es ermöglicht die Erstellung personalisierter Homepages zu Marketingzwecken, unterstützt Kampagnen und Newsletters per und stellt Marketinginformationen zum Download auf der Homepage bereit. Zur Unterstützung des Verkaufsprozesses dienen Siebel Sales, Siebel Telesales und Siebel esales. Siebel Sales unterstützt den Verkauf mit Funktionen wie Opportunity Management, Kontaktmanagement, Angebotserstellung, Produktpräsentationen etc. Es richtet sich dabei an den stationären und mobilen Vertrieb. Die speziellen Anforderungen des Vertriebs via Call Center deckt Siebel Telesales ab. Siebel esales ermöglicht den Verkauf über das Web als Vertriebskanal. Bei der Branchenlösung efinance ist dies auch speziell den Anforderungen von Finanzprodukten angepasst. Abb. 7-18:Oberfläche von Siebel Call Center (Quelle: [Siebel Systems 2000])

155 IS-Architektur 141 Den Serviceprozess unterstützen Siebel Service, Siebel Field Service und Siebel eservice. Siebel Service richtet sich an ein Service Call Center und bietet die typischen Servicefunktionen wie z.b. Service Request Management oder Servicevertragsverwaltung. Siebel Field Service unterstützt die mobilen Servicemitarbeiter und die zugehörige Service-Logistik. Siebel eservice ermöglicht Serviceleistungen über das Web. Dazu gehören eine personalisierte Service-Homepage, die Bereitstellung von Servicewissen und die Übermittlung und Verfolgung von Service Requests. Siebel Call Center bietet eine allgemeine Call Center-Unterstützung für Marketing, Verkauf und Service und bildet die Basis für Siebel Service und für Siebel Telesales. Die Oberfläche von Siebel Call Center, wie sie sich dem Benutzer darstellt, ist in Abb dargestellt. Die Applikationen Siebel econfigurator und Siebel epricer werden vertriebskanalübergreifend eingesetzt. Sie erlauben eine individuelle Produktkonfiguration und Preisfindung im Verkaufsprozess. Siebel echannel unterstützt die Kooperation mit Vertriebspartnern. Diese können über eine personalisierte Partner-Homepage auf verschiedene Datenbestände zugreifen (Kunden, Kontakte, Opportunities, Service Requests etc.). Mehrere Applikationen unterstützen Maschine-Mensch-Kanäle prozessübergreifend: Siebel eauction ermöglicht Online-Auktionen auf der Website. Siebel ecollaboration bietet internetbasierte Kommunikationsmöglichkeiten wie Call Me Now, Application Sharing, Chat und Voice over IP. Siebel Response ermöglicht die automatische Beantwortung bzw. Weiterleitung von s. Siebel etraining unterstützt die Verwaltung und Durchführung von Schulungen über das Web. Den Bereich Data Mart und Data Mining deckt Siebel mit seinen Business Analysis Komponenten OLAP Data Mart und Report Server ab. Siebel deckt die funktionalen Anforderungen des Front-Office-Bereiches vollständig ab. Auch Portale mit allgemeinen und personalisierten Bereichen können realisiert werden. Speziell für Banken ist es auch möglich, Funktionen zur Auftragserteilung und Kundenbenachrichtigung in die Oberfläche zu integrieren; die Abwicklung erfolgt über entsprechende Backend-Systeme. Die Applikationsarchitektur aus Sicht von Siebel ist in Abb dargestellt.

156 142 IS-Architektur Siebel Industry Applications Siebel efinance Siebel einsurance Siebel ecommunications Siebel eautomotive Siebel eenergy Siebel epharma Siebel epublic Sector Siebel econsumer Goods Siebel eapparel & Footwear Siebel etechnology.com Applications Call Center Field Channel Siebel esales Siebel Call Center Siebel Sales Siebel echannel Siebel emarketing Siebel Service Siebel Field Service Siebel eservice Siebel ebriefings Siebel econtent Svcs Siebel Telesales Siebel ecollaboration Siebel Configurator Siebel Handheld Siebel Phone Marketing Siebel Marketing Siebel Response Siebel ebusiness Architecture Security Data Visibility Workflow Transaction Management Data Synchronization & Replication Data Analysis / Data Mart Customization Software Distribution Personalization Content Management Routing and Assignment Dynamic Load Balancing Multilanguage / Multicurrency Data Movement Application Upgrades EAI Abb. 7-19: Applikationsarchitektur von Siebel 2000 (Quelle: [Siebel Systems 2000]) Uniquare Uniquare Financial Solutions wurde 1988 unter dem Namen Genesis gegründet. Das Softwarehaus mit Sitz in Österreich beschäftigt derzeit etwa 160 Mitarbeiter. Als Branchenspezialist realisiert Uniquare Individual- und Standardlösungen sowie Software-Grossprojekte für die Finanzindustrie mit dem Schwerpunkt bei Banken. Neben Individuallösungen, Entwicklungsplattformen und spezifischen Tools bietet Uniquare bankenspezifische Standardlösungen für Marketing, Verkauf, Service und Sachbearbeitung an. Gemäss [Schwetz 2000] gehört Uniquare zu den führenden CRM- Branchenanbietern für die Bankenbranche. Zentrales Produkt von Uniquare ist das Bank-System. Es integriert die Prozessunterstützung für Marketing, Verkauf und Service mit den fachlichen Finanzberatungsprozessen und löst in den Back-Office-Systemen die nach Vertragsabschluss erforderlichen Transaktionen aus. Wichtigste Komponente des Bank-Systems ist die CRM-Lösung Business-Management (s. Abb. 7-21).

157 IS-Architektur 143 Kanäle Prozesse Marketing Verkauf Service Andere Mehrstufen- Kanäle Call Center Mensch- Mensch Finanzanalyse, Produktberatung Transaktionsabwicklung am Front-End Sachbearbeitung Business-Management (CRM) Maschine- Mensch ebusiness, mbusiness Maschine- Maschine Abb. 7-20: Applikationsarchitektur des UNiQUARE Bank-Systems Filiale Außendienst Call Center Internet zusätzliche Produkt-Beratungs-Software Host KIS Kunden- informations- System PIS Produkt- informations- System Regel-System UNIQUARE Business-Management Aktivitäten Management Terminplaner, Aufgabenliste, Verkaufschancen-Management, Kalender etc. Kampagnen- Management Schnittstellen Administrationsunterstützung (Briefe, Angebote etc.) Historie Statistik-MIS (Management- Informations- System) Transaktion Gesamtbankstrategie Produktmanagement Vorstand / Geschäftsführung Multi-Channel- Management Abb. 7-21: Architektur von UNiQUARE Business-Management (Quelle: Das Business-Management enthält ein Kundeninformationssystem und ein Produktinformationssystem sowie ein Regelwerk zur Selektion für Marketingkampagnen. Die-

158 144 IS-Architektur se werden durch das Kampagnen-Management unterstützt. Ausserdem generiert das System automatisiert Ansprachehinweise und Aktivitäten und liefert auf Knopfdruck kundenindividuelle Produktvorschläge sowie Cross-Selling-Hinweise. Des Weiteren bietet das Business-Management verschiedene Unterstützungsfunktionen an. Abb zeigt eine typische Bildschirmmaske von Business-Management, in welcher der Berater Termine und Aufgaben verwalten sowie auf andere Funktionen zugreifen kann. Ein Beispiel für den Einsatz des Vorgängerproduktes Genesis Micro-Marketing bei bayerischen Volks- und Raiffeisenbanken ist in [Schmid 2000] beschrieben. Abb. 7-22: UNiQUARE Business-Management: Desktop für den Bankmitarbeiter Call Center, ebusiness und mbusiness sind Erweiterungskomponenten, um Funktionen von Business-Management kanalübergreifend und -optimiert zu nutzen bzw. kanalspezifisch zu ergänzen. Die Applikation Call Center unterstützt das Call Center als Vertriebskanal für das Bank-System. Die Funktionen umfassen alle Front-Office- Prozesse und beinhalten z.b. Kampagnendurchführung, Kundenberatung, Kundenservice und die Abwicklung von Geldtransaktionen.

159 IS-Architektur 145 Mensch-Maschine-Kanäle werden durch ebusiness und mbusiness unterstützt, wobei sich ebusiness auf das Web und mbusiness auf Mobiltelefone als Endgeräte konzentriert. Diese Applikationen ermöglichen Marketing, Verkauf und Service über elektronische Vertriebskanäle. Abb zeigt eine WAP-Oberfläche, über die Kunden und Interessenten mit dem Mobiltelefon auf das Business-Management zugreifen können. Abb. 7-23: WAP-Zugang zu UNiQUARE Business-Management Das Bank-System umfasst neben der CRM-Applikation Business-Management auch Komponenten zur Finanzanalyse, zur produktbezogenen Beratung, zur Sachbearbeitung und für die Transaktionsabwicklung am Front-End. Der Funktionsumfang des Uniquare Bank-Systems deckt die meisten funktionalen Anforderungen im Front-Office-Bereich ab und stellt die Funktionen in einer bankspezifischen Ausprägung zur Verfügung. Eine spezielle Unterstützung für Mehrstufen- Kanäle ist nicht vorhanden, ist aber für die nächste Version geplant. Es ist jedoch möglich, Kunden- und Produktdaten von Vertriebspartnern zu integrieren und für Auswertungen zu nutzen Fallbeispiel: Applikationslandschaft bei Microsoft Deutschland GmbH In der Praxis ist es meistens nicht möglich, eine einzige Applikation zu betreiben, die alle benötigten Funktionalitäten bereitstellt. Um den in Kapitel beschriebenen Anforderungen an eine Applikationsarchitektur gerecht zu werden, müssen Unternehmen Verbindungen zwischen den einzelnen Anwendungen herstellen und für eine konsistente Datenhaltung sorgen. Das folgende Fallbeispiel illustriert einen Lösungsansatz für diese Integrationsproblematik, den die Firma Microsoft im Zusammenhang mit der Einführung eines neuen CRM-Systems gewählt hat. Das Beispiel stammt zwar aus der Softwarebranche, die hier beschriebenen Aspekte sind jedoch branchenunabhängig gültig und auch auf die Situation von Banken übertragbar. Das Fallbeispiel basiert auf einem Interview mit dem Projektleiter für die Siebel-Einführung bei der Microsoft Deutschland GmbH (s. Anhang D.2). Die Microsoft Corporation ist der führende Anbieter von PC-Software. Das 1975 gegründete Unternehmen erwirtschaftete im Geschäftsjahr 1999/2000 einen Umsatz von etwas weniger als 23 Milliarden US-Dollar. Der Gewinn belief sich auf 9,42 Milliar-