Referenzmodell zur zielgruppenspezifischen Entwicklung einer webbasierten Informations- plattform für den technischen Vertrieb Von der Fakultät Konstruktions-, Produktions- und Fahrzeugtechnik der Universität Stuttgart zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung Vorgelegt von Dipl.-Ing. (FH) Dipl.-Wirt.-Ing. (FH) Holger Kett MBA aus Aalen Hauptberichter: Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath Mitberichter: Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper Tag der mündlichen Prüfung: 3. November 2011 Institut für Arbeitswissenschaft und Technologiemanagement IAT der Universität Stuttgart 2011 Berichte aus dem Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart, Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart und Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart Herausgeber: Univ.-Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper und Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger und Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath IPA-IAO Forschung und Praxis Fachverlag · 71296 Heimsheim Referenzmodell zur ziel- gruppenspezifischen Entwick- lung einer webbasierten Informationsplattform für den technischen Vertrieb Nr. 520 Holger Kett D 93 ISBN 978-3-939890-91-1 Jost Jetter Verlag, Heimsheim Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheber- rechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils gültigen Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. © Jost-Jetter Verlag, Heimsheim 2012. Printed in Germany. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, ge- gebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Druck: printsystem GmbH, Heimsheim Dr.-Ing. Dipl.-Wirt.-Ing. (FH) Holger Kett MBA Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger ord. Professor an der Universität Stuttgart Präsident der Fraunhofer-Gesellschaft, München Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart Univ.-Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart Geleitwort der Herausgeber Über den Erfolg und das Bestehen von Unternehmen in einer marktwirtschaftlichen Ordnung entscheidet letztendlich der Absatzmarkt. Das bedeutet, möglichst frühzeitig absatz marktorientierte Anforderungen sowie deren Veränderungen zu erkennen und darauf zu reagieren. Neue Technologien und Werkstoffe ermöglichen neue Produkte und eröffnen neue Märkte. Die neuen Produktions- und Informationstechnologien verwandeln signifikant und nachhaltig unsere industrielle Arbeitswelt. Politische und gesellschaftliche Ver ände run- gen signalisieren und begleiten dabei einen Wertewandel, der auch in unseren Indu strie- betrieben deutlichen Niederschlag findet. Die Aufgaben des Produktionsmanagements sind vielfältiger und anspruchsvoller ge - worden. Die Integration des europäischen Marktes, die Globalisierung vieler Industrien, die zunehmende Innovationsgeschwindigkeit, die Entwicklung zur Freizeitgesellschaft und die übergreifenden ökologischen und sozialen Probleme, zu deren Lösung die Wirt- schaft ihren Beitrag leisten muss, erfordern von den Führungskräften erweiterte Perspek- tiven und Antworten, die über den Fokus traditionellen Produktionsmanagements deutlich hinausgehen. Neue Formen der Arbeitsorganisation im indirekten und direkten Bereich sind heute schon feste Bestandteile innovativer Unternehmen. Die Entkopplung der Arbeitszeit von der Betriebszeit, integrierte Planungsansätze sowie der Aufbau dezentraler Strukturen sind nur einige der Konzepte, welche die aktuellen Entwicklungsrichtungen kennzeich- nen. Erfreulich ist der Trend, immer mehr den Menschen in den Mittelpunkt der Arbeits- gestaltung zu stellen - die traditionell eher technokratisch akzentuierten Ansätze weichen einer stärkeren Human- und Organisationsorientierung. Qualifizierungspro- gramme, Training und andere Formen der Mitarbeiterentwicklung gewinnen als Diffe ren- zierungsmerkmal und als Zukunftsinvestition in Human Resources an strategischer Bedeutung. Von wissenschaftlicher Seite muss dieses Bemühen durch die Entwicklung von Methoden und Vorgehensweisen zur systematischen Analyse und Verbesserung des Systems Pro- duktionsbetrieb einschließlich der erforderlichen Dienstleistungsfunktionen unterstützt werden. Die Ingenieure sind hier gefordert, in enger Zusammenarbeit mit anderen Disziplinen, z. B. der Informatik, der Wirtschaftswissenschaften und der Arbeitswissen- schaft, Lösungen zu erarbeiten, die den veränderten Randbedingungen Rechnung tragen. Die von den Herausgebern langjährig geleiteten Institute, das - Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), - Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), - Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart, - Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart arbeiten in grundlegender und angewandter Forschung intensiv an den oben aufgezeig- ten Entwicklungen mit. Die Ausstattung der Labors und die Qualifikation der Mitarbeiter haben bereits in der Vergangenheit zu Forschungsergebnissen geführt, die für die Praxis von großem Wert waren. Zur Umsetzung gewonnener Erkenntnisse wird die Schriften- reihe „IPA-IAO - Forschung und Praxis“ herausgegeben. Der vorliegende Band setzt diese Reihe fort. Eine Übersicht über bisher erschienene Titel wird am Schluss dieses Buches gegeben. Dem Verfasser sei für die geleistete Arbeit gedankt, dem Jost Jetter Verlag für die Auf- nahme dieser Schriftenreihe in seine Angebotspalette und der Druckerei für saubere und zügige Ausführung. Möge das Buch von der Fachwelt gut aufgenommen werden. Engelbert Westkämper Hans-Jörg Bullinger Dieter Spath Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Institut für Arbeitswissenschaft und Technologiemanagement IAT der Universität Stuttgart und am Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO, Stuttgart. Herrn Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath, Leiter des Instituts für Arbeits- wissenschaft und Technologiemanagement IAT der Universität Stuttgart sowie des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation IAO, danke ich für die wohlwollende Förderung meiner Arbeit und für die Übernahme des Hauptberichts. Ebenfalls gilt mein Dank Herrn Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper, Leiter des Instituts für Industrielle Fertigung und Fabrik- betrieb IFF der Universität Stuttgart sowie des Fraunhofer-Instituts für Produktions- technik und Automatisierung IPA, für die Übernahme des Mitberichts. Für die sehr gute Betreuung der Arbeit möchte ich mich ganz besonders bei Frau apl. Prof. Dr.-Ing. habil. Anette Weisbecker bedanken, die meine Arbeiten immer unterstützt hat und mir jederzeit mit wertvollen Hinweisen und konstruktiver Kritik zur Seite stand. Ich bedanke mich ebenfalls bei den Projektpartnern der Projekte M3V und THESEUS/TEXO sowie bei allen Kolleginnen und Kollegen des Competence Centers Electronic Business, die zum Gelingen der Arbeit beigetragen haben. Mein Dank gilt auch meinen Eltern Uta und Peter Kett, die mich immer unterstützt haben und somit den Grundstein für meinen beruflichen und wissenschaftlichen Werdegang gelegt haben. Meine Schwester Ulrike übernahm die Durchsicht und die Fehlerkorrektur des Manuskripts, wofür ich mich ebenso herzlich bedanke. Vor allem möchte ich mich bei meiner Frau Rebecca und unseren Kindern Leonie, Katharina und Timo bedanken, die mich während des gesamten Promotions- verfahrens unterstützt und motiviert haben. Dabei mussten sie auf viel gemeinsame Zeit verzichten. Ihre große Geduld und ihr Verständnis auch in arbeitsintensiven Zeiten haben die Erstellung meiner Dissertation möglich gemacht. Stuttgart, November 2011 Holger Kett Inhalt 1 Einleitung......................................................................................................................... 15 2 Ausgangssituation, Fokus der Betrachtung und Vorgehen .............................. 17 2.1 Ausgangssituation bei Handelsvertretungen ....................................................... 17 2.2 Fokus und Eingrenzung des Untersuchungsbereichs........................................ 19 2.3 Vorgehensweise und Aufbau der Arbeit ............................................................... 21 3 Stand der Technik und Wissenschaft ...................................................................... 24 3.1 Ergebnisse einer Befragung von Handelsvertretern und -vermittlern .............. 24 3.2 Vertriebssysteme und Web-Plattformen für Handelsvertretungen.................... 29 3.2.1 Drei grundlegende Kategorien von Vertriebslösungen ................................................ 30 3.2.2 Vergleich der drei Kategorien von Vert riebslösungen.................................................. 33 3.3 Referenzmodellierung und Referenzmodell ......................................................... 36 3.3.1 Referenzmodellierung .............................................................................................. 37 3.3.2 Vergleich von Referenzmodellen............................................................................... 39 3.4 Methoden zur Entwicklung elektronischer Dienstleistungen und Dienste....... 44 3.5 Modelle und Vorgehen zur Geschäftsmodellentwicklung .................................. 50 3.6 Schlussfolgerungen aus dem Stand der Technik und Wissenschaft ............... 53 4 Zielsetzung der Arbeit .................................................................................................. 55 5 Anforderungen an das Referenzmodell .................................................................. 57 6 Integrated Service Engineering Methodik (ISE) .................................................... 60 6.1 Sichten und Rollen der Integrated Service Engineering Methodik .................... 61 6.2 Dimensionen des Referenzmodells ....................................................................... 65 6.3 Teilmodelle und die Gesamtsicht........................................................................... 66 7 Referenzmodell einer webbasierten Informationsplattform .............................. 71 7.1 Beschreibungsstruktur des Referenzmodells ...................................................... 76 7.2 Zielgruppenbeschreibung ....................................................................................... 78 7.2.1 Zielgruppe ............................................................................................................... 78 7.2.2 Organisation der Zielgruppe...................................................................................... 80 7.2.3 Produkte der Zielgruppe ........................................................................................... 83 7.2.4 Prozesse der Zielgruppe........................................................................................... 84 7.2.5 IT-Infrastruktur der Zielgruppe................................................................................... 91 7.3 Dienstleistungsbeschreibung................................................................................. 93 7.3.1 Dienstleistungsangebot ............................................................................................ 95 7.3.2 Dienstleistung .......................................................................................................... 95 7.3.3 Nutzen .................................................................................................................. 100 7.3.4 Distributionskanäle................................................................................................. 101 7.3.5 Kundenbeziehung .................................................................................................. 102 7.4 Dienstleistungserstellung ..................................................................................... 104 7.4.1 Dienstleistungserbringung ...................................................................................... 106 7.4.2 Dienstleistungsprozess........................................................................................... 107 7.4.3 Kompetenz und Ressource..................................................................................... 108 7.5 Partner ..................................................................................................................... 111 - 10 - 7.6 Rentabilität .............................................................................................................. 113 7.6.1 Kosten .................................................................................................................. 114 7.6.2 Erlös ..................................................................................................................... 116 7.6.3 Gewinn.................................................................................................................. 118 8 Methodische Hinweise zur Nutzung des Referenzmodells..............................121 9 Umsetzung des Referenzmodells ...........................................................................123 9.1 Anwendungsbeispiel ............................................................................................. 123 9.2 Technische Umsetzung ......................................................................................... 136 9.3 Eclipse Editor zur Nutzung des Referenzmodells ............................................. 137 10 Evaluierung des Referenzmodells ..........................................................................139 10.1 Evaluierung durch Handelsvertretungen ............................................................ 139 10.2 Evaluierung durch IT-Anbieter ............................................................................. 141 10.3 Fazit.......................................................................................................................... 143 11 Ausblick .........................................................................................................................144 12 Zusammenfassung .....................................................................................................145 13 Summary........................................................................................................................147 Anhang A: Gesetzlicher Rahmen von Handelsvertretungen ................................168 Anhang B: Use Cases der Informationsplattform (Beschreibung) ......................169 Anhang C: Anwendungsbeispiel des Referenzmodells .........................................238 - 11 - Abbildungen Abbildung 1: Geschäftsbeziehungen im Vertrieb mit Handelsvertretungen ....................................... 17 Abbildung 2: Geschäftsbeziehungen im Vertrieb mit Händlern ........................................................ 18 Abbildung 3: Ausgangssituation im Vertrieb mit Handelsvertretern (FMC Notation) ........................... 19 Abbildung 4: Vorgehensweise und Aufbau der Arbeit ..................................................................... 23 Abbildung 5: Optimierungspotenziale der Vert riebsprozesse von Handelsvertretern und -vermittlern . 25 Abbildung 6: Verbreitungsgrad von IT-Anwendungen in Handelsvertretungen .................................. 28 Abbildung 7: Vertriebsunterstützung seitens Hersteller ................................................................... 30 Abbildung 8: Vertriebsunterstützung seitens Handelsvertretungen .................................................. 31 Abbildung 9: Vertriebsunterstützung mittels Web-Plattform als Mediator .......................................... 32 Abbildung 10: Bezugsrahmen der Referenzmodellierung (Fettke und Loos 2004) ............................ 37 Abbildung 11: Fachliche Systemsicht der Informationsplattform (FMC Notation) ............................... 55 Abbildung 12: Grundlagen der Integrated Service Engineering Methodik ......................................... 61 Abbildung 13: Rollen im Kontext der Integrated Service Engineering Methodik (Kett 2010) ............... 64 Abbildung 14: Referenzmodell ...................................................................................................... 74 Abbildung 15: Zielgruppenbeschreibung ........................................................................................ 78 Abbildung 16: Dienstleistungsbeschreibung ................................................................................... 94 Abbildung 17: Porter's Wertschöpfungskette (Porter 2000) ........................................................... 105 Abbildung 18: Dienstleistungserstellung ...................................................................................... 105 Abbildung 19: 5 Typen von Wertschöpfungsnetzwerken (Tapscott et al. 2000) ............................... 111 Abbildung 20: Rentabilität ........................................................................................................... 114 Abbildung 21: Zeitliche und sachliche Abgrenzung zur Kostendifferenzierung (Brugger 2005) ......... 115 Abbildung 22: Phasenmodell zur methodischen Anwendung des Referenzmodells ........................ 121 Abbildung 23: Konkretes Geschäftsmodell für ein Netzwerk von 4 Partnern ................................... 124 Abbildung 24: Metamodell des Referenzmodells in Eclipse ........................................................... 137 Abbildung 25: Nutzung des Referenzmodells in Eclipse ................................................................ 138 - 12 - Tabellen Tabelle 1: Systemeinsatz sowie IT-Kenntnisse bei Handelsvertretungen ......................................... 29 Tabelle 2: Plattformen für Handelsvertretungen und Hersteller ........................................................ 32 Tabelle 3: Vergleich der 3 prinzipiellen IT-Lösungen für Handelsvertretungen .................................. 35 Tabelle 4: Zentrale Grundsätze der ordnungsmäßigen Modellierung (Remmert 2001) ...................... 38 Tabelle 5: Ergänzende Grundsätze der ordnungsmäßigen Modellierung (Remmert 2001) ................ 39 Tabelle 6: Vergleich von Referenzmodellen anhand deren Zielsetzung und Aufbau .......................... 43 Tabelle 7: Vergleich von Referenzmodellen anhand deren inhaltlichen Ausrichtung ......................... 44 Tabelle 8: Vergleich von Vorgehensmodellen zur Entwicklung traditioneller Dienstleistungen ............ 48 Tabelle 9: Vergleich von Vorgehensmodellen zur Entwicklung elektronischer Dienste ...................... 49 Tabelle 10: Vergleich von Geschäftsmodellansätzen ...................................................................... 52 Tabelle 11: Anforderungen an das Referenzmodell ........................................................................ 59 Tabelle 12: Vergleich von Sichten und dazugehörende Rollen ........................................................ 62 Tabelle 13: Dimensionen des Referenzmodells .............................................................................. 66 Tabelle 14: Prinzipieller Aufbau des Referenzmodells .................................................................... 70 Tabelle 15: Schlüsselfragen für die geschäftlich-strategische Sicht.................................................. 72 Tabelle 16: Integration des Geschäftsmodells in ISE ...................................................................... 76 Tabelle 17: Beschreibungsstruktur des Referenzmodells ................................................................ 77 Tabelle 18: Beschreibung von Zielgruppen .................................................................................... 79 Tabelle 19: Beschreibung der Organisation einer Zielgruppe .......................................................... 80 Tabelle 20: Kategorien von Kundentypen ...................................................................................... 81 Tabelle 21: Beschreibung von Produkten einer Zielgruppe .............................................................. 83 Tabelle 22: Beschreibung von Prozessen einer Zielgruppe ............................................................. 84 Tabelle 23: Vert riebsprozesse von Handelsvertretern und abgeleitete Anwendungsfälle ................... 87 Tabelle 24: Vert riebsprozesse von Herstellern und abgeleitete Anwendungsfälle ............................. 89 Tabelle 25: Beschreibung der IT-Infrastruktur einer Zielgruppe ....................................................... 91 Tabelle 26: E-Business Standards im Kontext der Arbeit (erweitert Berlecon Research 2010) ........... 93 Tabelle 27: Beschreibung von Dienstleistungsangeboten ............................................................... 95 Tabelle 28: Einteilung der angebotenen Dienstleistungen ............................................................... 96 Tabelle 29: Beschreibung von Dienstleistungen ............................................................................. 97 Tabelle 30: Alleinstellungspotenzial (Osterwalder 2004) ................................................................. 98 Tabelle 31: Preisniveau (Osterwalder 2004)................................................................................... 99 Tabelle 32: Beschreibung des Nutzens ........................................................................................ 100 Tabelle 33: Beschreibung von Distributionskanälen ...................................................................... 101 Tabelle 34: Beschreibung der Kundenbeziehung ......................................................................... 103 Tabelle 35: Beschreibung der Dienstleistungserbringung .............................................................. 106 Tabelle 36: Beschreibung von Dienstleistungsprozessen .............................................................. 107 Tabelle 37: Vier Kompetenzarten und deren Qualifikationsanforderungen(Weisbecker 2002) .......... 109 Tabelle 38: Beschreibung von Kompetenzen und Ressourcen ...................................................... 110 Tabelle 39: Beschreibung von Partnern ....................................................................................... 111 Tabelle 40: Beschreibung der Kosten .......................................................................................... 115 Tabelle 41: Beschreibung Erlös................................................................................................... 116 Tabelle 42: Parameter von Preismodellen für Softwareprodukte (Lehmann und Buxmann 2009) ..... 117 Tabelle 43: Beschreibung Gewinn ............................................................................................... 118 Tabelle 44: Erste Zielgruppe und deren Dienstleistungsangebot ................................................... 125 Tabelle 45: Dienstleistungspakete und deren Nutzen für die erste Zielgruppe ................................ 126 Tabelle 46: Distributionskanäle und angestrebte Kundenbeziehung zur ersten Zielgruppe .............. 127 Tabelle 47: Zweite Zielgruppe und deren Dienstleistungsangebot ................................................. 128 Tabelle 48: Dienstleistungspakete und deren Nutzen für die zweite Zielgruppe .............................. 129 Tabelle 49: Distributionskanäle und angestrebte Kundenbeziehung zur zweiten Zielgruppe ............ 130 - 13 - Tabelle 50: Dienstleistungserbringung und notwendige Dienstleistungsprozesse ........................... 131 Tabelle 51: Ressourcen und Kompetenzen.................................................................................. 132 Tabelle 52: Partner und deren Kurzbeschreibungen ..................................................................... 133 Tabelle 53: Kosten für Erbringung der Dienste und Dienstleistungen ............................................. 134 Tabelle 54: Angestrebte Erlöse aus den Dienstleistungsangeboten (Schätzwerte) ......................... 135 Tabelle 55: Gewinn und Rentabilität der Investition je Partner (Schätzwerte) ................................. 135 Tabelle 56: Eignung von Diensten und Dienstleistungen der webbasierten Informationsplatt form .... 141 Tabelle 57: Bewertung der zentralen Grundsätze der ordnungsmäßigen Modellierung ................... 142 Tabelle 58: Ergänzende Grundsätze der ordnungsmäßigen Modellierung ...................................... 143 - 14 - Abkürzungsverzeichnis BPEL Business Process Execution Language BMM Business Motivation Model BPMN Business Process Modeling Notation CRM Customer Relationship Management DSL Domain-Specific Language EMF Eclipse Modeling Framework EPK Ereignisgesteuerte Prozessketten ERM Entity Relationship Model ERP Enterprise Resource Planning FMC Fundamental Modeling Concepts GMF Graphical Modelling Framework ISE Integrated Service Engineering IT Informationstechnologie MDA Model-Driven Architecture MDD Model-Driven Development MDE Model-Driven Engineering NSD New Service Development OASIS Organization for the Advancement of Structured Information Standards OMG Object Management Group PDA Personal Digital Assistant PIM Produktinformationsmanagement SMART Service-Oriented Migration and Reuse Technique SaaS Software as a Service SOA Service-Orientierte Architekturen SOAD Service-Oriented Analysis and Design SOMA Service-Oriented Modeling and Architecture SOMF Service-Oriented Modeling Framework SWOT Strength Weaknesses Opportunities Threats UML Unified Modeling Language WWS Warenwirtschaftssystem 1 Einleitung Gemäß Statistischem Bundesamt (2009) setzten produzierende Unternehmen im Jahr 2008 innerhalb Deutschlands Waren in einem Wert von 993 Mrd. Euro um. Mit einem Jahresumsatz von 1,7 Bill. Euro in 2008 gehört das verarbeitende Gewerbe zu den umsatzstärksten Wirtschaftszweigen in Deutschland. Dabei nahm dessen Bedeutung kontinuierlich zu. So stieg der Produktionsindex des verarbeitenden Gewerbes seit 2000 stetig auf 121,8 im Jahr 2008 an (2000 = 100). Waren im Wert von 175 Mrd. Euro werden pro Jahr in Deutschland über Handelsvertretungen und -vermittlungen vertrieben, die als eigenständige Vertriebsorganisationen Unternehmen beim Marketing und Vertrieb ihrer Produkte und Dienstleistungen unterstützen (CDH 2009; CDH 2008a; CDH 2008b). Davon sind 66 Prozent des Umsatzes dem verarbeitenden Gewerbe zuzurechnen. Durchschnittlich vertreten diese eigenständigen Vertriebsorganisationen sechs Herstellerunternehmen bei grundlegender IT-Unterstützung (Spath et al. 2008a). Nicht für jedes produzierende Unternehmen ist der Aufbau eines eigenen Vertriebs zur Erschließung und Durchdringung von Märkten wirtschaftlich. In diesem Fall können sie auf externe Vertriebspartner zurückgreifen, wie Handelsvertreter, die entsprechendes Wissen über die jeweiligen Märkte mitbringen und stellvertretend für das Unternehmen dessen Produkte vertreiben (siehe Gabler 2010). Um diesen Vertriebsweg zu etablieren, müssen Handelsvertretungen und -vermittlungen in die Prozesse des zu vertretenden Unternehmens integriert werden (Spath et al. 2008a). Spath et al. (2008b) erwähnt die Bedeutung von Dienstleistungen beim Vertrieb von physikalischen Produkten und in diesem Zusammenhang insbesondere die Entwicklung weg von einem transaktionsorientierten Kunden-Lieferanten-Verhältnis hin zu einer Beziehung zwischen Kunden und Lieferanten zur Erzielung eines nachhaltigen Kundennutzens. Die Zusammenarbeit von Handelsvertretern und Herstellern stellt besondere Anforderungen an eine elektronische Vertriebslösung in Bezug auf mobile Verfügbarkeit von Vertriebsinformationen, Integration von Herstellersystemen und Geschäftsmodellen (Spath et al. 2008a). Neue Lösungsansätze auf der Grundlage von Software as a Service (SaaS) ermöglichen den Einsatz von IT-Lösungen auch für kleinere Unternehmen (Weiner et al. 2010; König et al. 2006). So steigt bei über 30 Prozent kleiner Unternehmen zukünftig die Bedeutung von SaaS (Lorenz 2007). Handelsvertretungen und -vermittlungen sind überwiegend kleine Unternehmen (87 Prozent der Handelsvertretungen beschäftigen bis zu 6 Mitarbeiter), die je nach Wirtschaftsbereich, in dem sie tätig sind, unterschiedliche Anforderungen an die IT- Unterstützung stellen (CDH 2009; CDH 2008b; Spath et al. 2008a). Aktuell existieren keine geeigneten IT-Lösungen, die auf Handelsvertretungen und -vermittlungen zugeschnitten sind und deren Anforderungen abdecken (siehe Kapitel 3.2). Die vorliegende Arbeit hat daher die Entwicklung einer Methodik zum Ziel, die IT- Anbieter basierend auf einem Framework an geeigneten Methoden und Modellen bei - 16 - der Entwicklung dienstbasierter IT-Lösungen für Handelsvertretungen und -vermittlungen im technischen Vertrieb unterstützt. Der ganzheitliche Ansatz berücksichtigt strategische Aspekte im Rahmen eines Referenzgeschäftsmodells und setzt diese in Zusammenhang mit nachfolgenden Entwicklungsphasen, dem fachlichen Detailkonzept, dem IT-Konzept und der technischen Umsetzung. 2 Ausgangssituation, Fokus der Betrachtung und Vorgehen 2.1 Ausgangssituation bei Handelsvertretungen Das Handelsgesetzbuch definiert eine Handelsvertretung bzw. -vermittlung wie folgt: Definition D1: Handelsvertreter ist, wer als selbstständiger Gewerbetreibender ständig damit betraut ist, für einen anderen Unternehmer Geschäfte zu vermitteln (Vermittlungsvertreter) oder in dessen Namen abzuschließen (Abschlussvertreter) (§ 84 I 1 HGB) (Bundesministerium der Justiz 2010). Der gesetzliche Rahmen für Handelsvertreter in Deutschland ist das Handelsvertreterrecht im Handelsgesetzbuch (HGB), in dem implizit und explizit die Rechte und Pflichten von Handelsvermittlern und -vertretern, wie beispielsweise Provisionsanspruch, Anspruch auf Buchauszug, Bemühungs- und Benachrichti- gungspflicht und Wettbewerbsverbot, geregelt sind. Die Gesetzgebung beeinflusst damit die Geschäftsprozesse von Handelsvertretern, was auch Einfluss auf die IT- Unterstützung hat. Eine wichtige Besonderheit im Vertrieb mit Handelsvertretern sind die parallelen Geschäftsbeziehungen von Handelsvertretern und die von ihnen vertretenen Hersteller mit ihren Kunden zu ein und demselben Geschäftsvorfall. Abbildung 1 zeigt die Geschäftsbeziehung zwischen Kunden, Handelsvertretern und Herstellern. Abbildung 1: Geschäftsbeziehungen im Vertrieb mit Handelsvertretungen Dabei wird deutlich, dass die Handelsvertretung sowie die von ihnen vertretenen Hersteller den Vertriebsprozess gemeinsam ausüben und damit direkte Beziehungen bei beiden rechtlich unabhängigen Organisationen zum Kunden bestehen. Im Anhang A sind die gesetzlichen Rahmenbedingungen von Handelsvertretungen und die von ihnen vertretenen Hersteller aufgeführt, die die Rechte und Pflichten beider Parteien regeln. Die gesetzlichen Rahmenbedingungen beeinflussen die geschäftliche Beziehung und damit bspw. auch die Ausgangssituation zwischen Handelsvertretungen und Herstellern. Durchschnittlich vertritt eine Handelsvertretung 6 Hersteller (CDH 2009) und benötigt daher eine multilieferantenfähige IT-Lösung, LieferantLieferant KundeKunde Handelsvertretung Kunde Hersteller - 18 - die die Vorgänge der verschiedenen Hersteller optimal trennt und zusammenführt (siehe Abschnitt 3.2.2). Abbildung 2 stellt zum Vergleich die Geschäftsbeziehungen zwischen Kunden, Händlern und Herstellern bzw. Lieferanten dar. Dabei führen Händler sowie deren Hersteller jeweils ihre eigenen Vertriebsprozesse aus, und die Waren- und Geldströme erfolgen jeweils zwischen Hersteller und Händler sowie anschließend zwischen Händler und Kunden. Abbildung 2: Geschäftsbeziehungen im Vertrieb mit Händlern Traditionelle Electronic Business Lösungen, wie elektronische Marktplätze, e-Shops und Online-Kataloge, sind für lineare Geschäftsbeziehungen mit den eindeutigen Rollen eines Käufers und eines Verkäufers konzipiert (Meier und Stormer 2005) und somit nicht geeignet für die Optimierung von Vertriebsprozessen zwischen Handelsvertretungen und die von ihnen vertretenen Hersteller. Customer Relationship Management Lösungen werden vor allem aus Sicht eines Unternehmens angewendet (siehe z.B. Hippner und Wilde 2007). Bei Untersuchung der eingesetzten IT-Anwendungen in Handelsvertretungen kommen komplexe IT- Anwendungen wie Enterprise Resource Planning bzw. Warenwirtschaftssysteme nur in geringem Maße zum Einsatz. Ganzheitliche IT-Lösungen, die die unternehmensübergreifenden Vertriebsprozesse aus Sicht von Handelsvertretungen unterstützen, konnten im Rahmen einer Studie unter Handelsvertretungen von Spath et al. (2008a) nicht identifiziert werden. In Abbildung 3 ist eine typische Ausgangssituation zwischen einer Handels- vertretung, deren Kunden und Herstellern dargestellt. Dabei kommunizieren Kunden (anders als bei dem in Abbildung 2 dargestellten linearen Kunden-Händler-Hersteller- Beziehung) nicht ausschließlich mit der Handelsvertretung bzw. -vermittlung, sondern führen parallel Geschäftsaktivitäten direkt mit Herstellern durch. Dies führt zu unterschiedlichen Informationsständen zwischen Handelsvertretungen und Herstellern, die mit den eingesetzten IT-Systemen nicht synchronisiert werden (Spath et al. 2008a). Die ungenügende IT-Unterstützung und der fehlende Informationsabgleich führen bei den Handelsvertretungen zu ± einem hohen manuellen Aufwand bei der Pflege und Aktualisierung von Vertriebsinformationen, ± einer fehlenden Aktualität der Informationen, da durch den zeitlichen Versatz der manuellen Pflege und der oft verspäteten Bereitstellung von Vertriebs- informationen durch die Hersteller der aktuelle Stand der Informationen nicht zeitnah in den Systemen (wenn vorhanden) abgebildet wird, LieferantLieferantKundeKunde HändlerKunde Hersteller - 19 - ± geringer Aussagefähigkeit beim Kunden vor Ort, da die Informationen nicht oder nicht mobil zur Verfügung stehen. Diese komplexe Ausgangssituation erschweren Softwareanbietern geeignete IT- Lösungen für Handelsvertretungen und die von ihnen vertretenen Hersteller zu entwickeln. Abbildung 3: Ausgangssituation im Vertrieb mit Handelsvertretern (FMC Notation) 2.2 Fokus und Eingrenzung des Untersuchungsbereichs Die Arbeit beschäftigt sich mit der Entwicklung eines Referenzmodells für IT-Anbieter und Softwareentwickler, die eine webbasierte Informationsplattform für Handelsvertretungen und Hersteller als Software as a Service (SaaS) anbieten möchten. Die konkrete Zielsetzung der Arbeit wird unter Berücksichtigung der Ergebnisse aus der Untersuchung des aktuellen Stands der Technik und Wissenschaft in Kapitel 4 vorgestellt. Dabei werden die im Rahmen der Informationsplattform angebotenen elektronischen Dienste sowie Dienstleistungen berücksichtigt: Definition D2: Ein Dienst ist »a business activity of value exchange that is accessible through an electronic interface« (Riedl et al. 2009). Definition D3: In Abgrenzung zur Warenproduktion (materielle Güter) spricht man bei Dienstleistungen von immateriellen Gütern. Als ein typisches Merkmal von Dienstleistungen wird die Gleichzeitigkeit von Produktion und Verbrauch angesehen. Externe Vertriebsorganisationen Hersteller Kunden Entwickler Einkäufer Externe Vertriebsorganisationen Handelsvertreter/ Handelsvermittler/ Händler Vertriebsinnendienst Support Vertriebs- mitarbeiter Produkt- manager Notebook E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationärer Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Buch- haltung ERP- System CRM- System PIM- System Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung PDA/Smartphone E-Mail Client Kontakt-/ Terminver waltung - 20 - Die personengebundene Arbeitsleistung des Produzenten macht hier den wesentlichen Inhalt der Dienstleistungen aus (Gabler 2010). Das in dieser Arbeit vorgestellte Referenzmodell unterstützt somit IT-Anbieter und Softwareentwickler bei der Konzeption und Erstellung einer zentralen webbasierten Lösung, durch die die Vertriebsprozesse zwischen Handelsvertretungen und Herstellern optimiert ablaufen können. Die Entwicklung des Referenzmodells fokussiert auf die Zielgruppe von Handelsvertretern technischer Produkte und die Erstellung einer geeigneten elektronischen Unterstützung. Die abschließende Evaluierung des Referenzmodells fand daher mit Handelsvertretern als indirekte sowie mit IT-Anbietern und Softwareentwicklern als direkte Nutznießer des Referenzmodells statt. Des Weiteren werden die Schwachstellen und Optimierungspotenziale aktueller Vertriebsprozesse von Handelsvertretern und die von ihnen vertretenen Herstellern betrachtet, um daraus Möglichkeiten der Prozessverbesserung durch den Einsatz einer entsprechenden webbasierten IT-Lösung abzuleiten. Dabei wird eine zentrale Informationsplattform vorgeschlagen, die als SaaS angeboten wird und damit Unternehmen, wie z.B. Handelsvertretungen und Herstellern, die Möglichkeit bietet, IT-Unterstützung einzukaufen ohne selber im Unternehmen notwendige Kompetenzen aufbauen zu müssen. Auf diese Weise sollen vor allem die Initialkosten von IT-Investitionen reduziert werden und die Software auch für Mikro- Unternehmen, wie Handelsvertretungen, wirtschaftlich interessant machen (Weidmann et al. 2010). Um die notwendige Akzeptanz für einen wirtschaftlichen Betrieb der Informationsplattform bei den genannten Zielgruppen zu schaffen, ist zum einen eine Anpassung der IT-Unterstützung auf die jeweiligen Prozesse sowie den spezifischen Hintergrund der Handelsvertretungen von Bedeutung. Zum anderen ist die Erstellung eines aus Sicht aller Beteiligten nachhaltig wirtschaftlichen Geschäftsmodells für die Informationsplattform relevant (Weiner et al. 2010). Der Kern der Arbeit beschäftigt sich daher mit den folgenden vier Themenbereichen: ± Entwicklung eines Metamodells (Integrated Service Engineering Framework) als übergeordnete Struktur, das ein ganzheitliches Vorgehen bei der Konzeption und Umsetzung der Informationsplattform für Handelsvertretungen und von ihnen vertretenen Hersteller auf Basis von Software as a Service unterstützt. ± Geschäftsmodellentwicklung zur Strukturierung von bislang un- bzw. semistrukturierten Informationen zur strategischen, zielgruppenspezifischen Ausrichtung der Informationsplattform innerhalb eines Konsortiums von mehreren Kooperationspartnern. ± Entwicklung eines methodischen Vorgehens zur Nutzung des Referenzmodells (die Integrated Service Engineering Methodik ISE). ± Betrachtung einer IT-technischen Umsetzung zur Anwendungsunterstützung des Referenzmodells. - 21 - Die Innovation dieses Ansatzes liegt insbesondere in der Bereitstellung eines Referenzmodells zur zielgruppenspezifischen Ausrichtung und Entwicklung der Informationsplattform für Handelsvertreter, -vermittler und Hersteller bei möglichst großem Standardisierungsgrad der Bereitstellungsprozesse (in Anlehnung an die Ansätze des kundenindividuellen Massenproduktion/Mass Customization Blecker et al. 2003; Rautenstrauch et al. 2002; Piller 2000; Pine und Davis 1999; Piller 1998). Der Ansatz basiert auf der Erstellung und Modellierung eines nachhaltigen Geschäftsmodells und damit der Möglichkeit einer strukturierten Bereitstellung von strategischen Rahmenparametern in Modellen nachgelagerter Entwicklungsphasen. Viele Handelsvertretungen vertreiben Produkte nicht nur als reine Handelsvertreter, sondern nehmen parallel auch andere Rollen wie Handelsvermittler, Kommissionäre bzw. Händler ein. In Tabelle 20 geht die Arbeit auf die einzelnen Rollen ein und zeigt deren Unterschiede auf. Der Begriff des Handelsvertreters im Rahmen der Arbeit wird in erster Linie im weiteren Sinne verwendet, d.h. neben seiner Rolle als Handelsvertreter kann ein Handelsvertreter auch andere der genannten Rollen innehaben. Sollte die Rolle des Handelsvermittlers von Bedeutung sein, wird dies explizit im Text genannt. Die Rolle des Kommissionärs als spezielle Ausprägung eines Handelsvertreters findet in der Arbeit keine besondere Berücksichtigung. Die Auswirkungen der Rolle des Händlers werden im Verlauf der Arbeit berücksichtigt. Des Weiteren werden die Begriffe der »webbasierten Informationsplattform« und »Vertriebsplattform« für Handelsvertreter und -vermittler synonym verwendet. 2.3 Vorgehensweise und Aufbau der Arbeit Als Ausgangspunkt für die Konkretisierung der Zielsetzung wird in Kapitel 3 der aktuelle Stand der Technik und der Wissenschaft vorgestellt. Neben grundlegenden Begriffsdefinitionen werden in diesem Kapitel die Ausgangssituation bei Handelsvertretungen, aktuelle Vertriebslösungen für Handelsvertretungen und die von ihnen vertretenen Herstellern, die Referenzmodellierung und Methoden der Entwicklung elektronischer Dienstleistungen und Dienste untersucht. Hierbei wird geprüft, welche Lösungen im Rahmen der Arbeit verwendet bzw. erweitert werden können, um die Entwicklung des Referenzmodells zu unterstützen. Auf den Erkenntnissen der Untersuchung aufbauend wird in Kapitel 4 die konkrete Zielsetzung der Arbeit abgeleitet. Ausgehend von dieser Zielsetzung werden im Kapitel 5 die Schwachstellen und Optimierungspotenziale bei Handelsvertretungen dargestellt und funktionale sowie nicht funktionale Anforderungen an ein Referenzmodell einer webbasierten Informationsplattform für Handelsvertretungen und die von ihnen vertretenen Hersteller aus fachlicher sowie technischer Sicht abgeleitet. In Kapitel 6 werden die Beteiligten im Entwicklungsprozess und deren unter- schiedlichen Sichten auf die zu entwickelnde Vertriebslösung betrachtet. Um den verschiedenen Sichten und Dimensionen gerecht zu werden, baut das Metamodell - 22 - auf dem Zachman Framework auf (John F. Sowa und John A. Zachman 1992; Zachman 1987). Dessen Integration und Anwendung im Rahmen der Arbeit wird ebenso in diesem Kapitel dargestellt. Der Schwerpunkt der Arbeit liegt auf der Erstellung eines Referenzmodells zur Entwicklung von Geschäftsmodellen für die webbasierte Informationsplattform für Handelsvertretungen und die von ihnen vertretene Hersteller. Hierbei gilt es mit einem Konsortium von mehreren Partnern durch die Geschäftsmodellentwicklung einen strategischen Rahmen zu schaffen, der es allen Beteiligten ermöglicht, die Informationsplattform fachlich sowie technisch zu konzipieren und zielgruppen- spezifisch umzusetzen. Dieses Referenzmodell wird in Kapitel 7 dokumentiert. Um Softwareanbietern die Nutzung des Referenzmodells zu erleichtern, werden in Kapitel 8 methodische Hinweise zur Anwendung des Referenzmodells gegeben. Die Anwendung erfolgt in einem Phasenmodell. Eine modellbasierte Umsetzung des Referenzmodells als domainspezifische Sprache (DSL) in Eclipse unter Verwendung des Eclipse Modelling Framework (EMF) und Graphical Modelling Framework (GMF) wird in Kapitel 9 aufgeführt. Die technische Umsetzung verwendet dabei die Ergebnisse der vorherigen Kapitel. Die Ergebnisse wurden zum einen unter fachlich-inhaltlichen Aspekten von Handelsvertretern, zum anderen unter methodisch Aspekten von Softwareanbietern evaluiert und in Kapitel 1 dokumentiert. In Kapitel 11 erfolgt die Zusammenfassung der gewonnenen Erkenntnisse sowie der Ausblick. Die Vorgehensweise und der Aufbau der Arbeit ist in Abbildung 4 grafisch dargestellt. - 23 - Abbildung 4: Vorgehensweise und Aufbau der Arbeit Integrated Service Engineering Methodik (ISE) Anforderungen Anforderungen an das Referenzmodell Referenzmodell zur Entwicklung strategischer Aspekte einer webbasierten Informationsplattform für den technischen Vertrieb Vorstellung des zugrunde- liegenden Modellansatzes zur Entwicklung und Visualisierung des Referenzmodells Zielgruppen- beschreibung Dienstleistungs- beschreibung Dienstleistungs- erstellung Partner Methodische Hinweise zur Nutzung des Referenzmodells (Phasenmodell) Identifikation der Zielgruppen Festlegung von Dienstleistungs- angeboten Ableitung von Kompetenzen u. Ressourcen Integration von Partnern Rentabilitäts- betrachtung Evaluation des Referenzmodells mit Handelsvertretern und Softwareanbietern Evaluation mit Handelsvertretern Evaluation mit Softwareanbietern Stand der Praxis, Technik und Wissenschaft Ausgangssituation bei Handelsvertretern und -vermittlern Referenzmodellierung und Referenzmodell Einleitung Einleitung Fokus der Betrachtung Vorgehensweise und Aufbau der Arbeit Vergleich von Vertriebs- informationslösungen Zielsetzung Ableitung der konkreten Ziel- setzung der Arbeit Zusammenfassung und Ausblick Zusammenfassung der Erkenntnisse Ausblick Ausgangsituation von Handelsvertre- tungen Einführung unterschiedlicher Sichten auf das Referenzmodell je nach Rolle der Beteiligung am Entwicklungsprozess Nutzung mehrerer Dimensionen zur Stei- gerung der Transparenz innerhalb der Sichten Technische Umsetzung des Referenzmodells Anwendungs- beispiel Technische Umsetzung in Eclipse Methoden der Entwicklung von Dienstleistungen und Diensten Modelle und Vorgehen zur Geschäftsmodellentwicklung Schlussfolgerungen Rentabilität 3 Stand der Technik und Wissenschaft In diesem Kapitel wird im ersten Schritt geprüft, welche prinzipiellen IT-Lösungen zur Unterstützung der Vertriebsprozesse von Handelsvertretungen und Herstellern existieren. Hierbei werden deren Vor- und Nachteile anhand relevanter Anforderungen gegenüber gestellt. Im zweiten Schritt werden themenrelevante Referenzmodelle identifiziert und deren Eignung für die vorliegende Aufgabenstellung analysiert. Dabei wird untersucht, ob anwendbare Referenzmodelle existieren, die für die beschriebene Aufgabenstellung ganz oder teilweise verwendet werden können. Da das Referenzmodell als Grundlage für ein methodisches Vorgehen zur Entwicklung einer webbasierten Informationsplattform für den technischen Vertrieb bei Handelsvertretern und der von ihnen vertretenen Hersteller dient, werden im dritten Schritt Methoden und Vorgehensweisen untersucht, die auf die elektronische Dienstleistungsentwicklung fokussiert sind. 3.1 Ergebnisse einer Befragung von Handelsvertretern und -vermittlern Im Rahmen einer Umfrage unter 53 Handelsvertretungen in Baden-Württemberg (Spath et al. 2008a) wurde die aktuelle Ausgangssituation mit dem Fokus auf Prozesse und IT-Unterstützung bei Handelsvertretungen aufgenommen und untersucht. In Abbildung 5 sind die Untersuchungsergebnisse für die relevanten Prozesse der fünf Phasen des Vertriebszykluses nach Hinderer (2005) und Schulze (2000) aufgeführt. Ein Handelsvertreter kann neben seiner Rolle als Handelsvertreter auch Rollen als Handelsvermittler und Händler einnehmen (siehe Tabelle 20). Nicht alle Prozesse sind gleichermaßen relevant für die jeweilige Rolle. Daher ist in Abbildung 5 die Relevanz des jeweiligen Prozesses für eine Rolle zugeordnet. Des Weiteren sind die Optimierungspotenziale für den jeweiligen Prozess allgemein (z.B. durch Reduzierung manueller Tätigkeiten, Vermeidung von Medienbrüchen) aufgeführt. Die Bedeutung mobiler Endgeräte und deren Unterstützung bei der Prozessdurchführung sowie die Optimierungspotenziale durch eine verbesserte Prozessunterstützung durch den Einsatz mobiler Endgeräte werden in den nächsten Spalten dargestellt. Bei der Befragung von Handelsvertretern wurden die Schwerpunkte ihrer Tätigkeiten abgefragt, die einen starken Bezug zu Herstellern aufweisen. Dabei stellten sich vor allem Aufgaben des Vertriebs, wie Beratung, Verkauf und Auftragsabwicklung als die zentralen Tätigkeitsbereiche von Handelsvertretungen heraus, begleitend durch einige wenige Aufgaben im Marketing, After Sales und Support (Spath et al. 2008a). - 25 - Abbildung 5: Optimierungspotenziale der Vertriebsprozesse von Handelsvertretern und -vermittlern H V er m itt lu ng H V er tre tu ng H än dl er O pt .P ot en zi al M ob . B ed eu tu ng M ob . P ot en zi al H V er m itt lu ng H V er tre tu ng H än dl er O pt .P ot en zi al M ob . B ed eu tu ng M ob . P ot en zi al H V er m itt lu ng H V er tre tu ng H än dl er O pt .P ot en zi al M ob . B ed eu tu ng M ob . P ot en zi al Gesprächs- vorbereitung z z z z zz z Klärung von Kundenanfragen mit Herstellern z z z zz zz z Versand von bestellten Produkten - | z | | | Bereitstellung von Produktinformationen für Kunden z z z z zz z Entgegennahme von Angebotsanfragen z z z z z | Abfrage von Information über Geschäftgsvorfälle für Kunden z z z z zz z Bereitstellung von Besuchsberichten für Hersteller z z - zz z | Weiterleitung von Angebotsanfragen an Hersteller z - - z z | Abgleich der Status von Geschäftsvor- fällen mit Herstellern z z z zz z z Erstellung von Angeboten - z z z z | Durchführung einer eigenen Lagerverwaltung - | z | | | H än dl e Erstellung/Versand von Rechnungen - | z | | | Vorstellung von Produkten z z z zz zz z Entgegennahme von Bestelländerungen z z z | z z H än dl er Bereitstellung von Produktmustern z z z z z z Bestellung von Produkten für eigene Lagerhaltung beim Hersteller - | z | | | Bearbeitung von Reklamationen z z z z z | Unterstützung und Beratung bei der Produktauswahl z z z zz zz zz Rechnungen von Herstellern bearbeiten/ weiterleiten - | z z | | Konfiguration eines komplexeren Produkts (ggf. mit dem Kunden) z z z z z z Abgleich der Provisionszahlungen mit Herstellern z z - zz z z Kundenspezifische Entwicklung von Produkten z z z z z z H V er m itt lu ng H V er tr et un g H än dl er O pt .P ot en zi al M ob . B ed eu tu ng M ob . P ot en zi al z z z | z z z z z zz zz z z z z z z | | = geringes Potenzial/Bedeutung, z = mittleres Potenzial/Bedeutung, zz= hohes Potenzial/Bedeutung n Werbung und Information q Auftragsabwicklungp Verkauf o Beratung | z z z | Entgegennahme und Bearbeitung von Bestellungen - M ob . P ot en zi al Durchführung der Terminverwaltung r After Sales und Support | - z H V er tre tu ng O pt .P ot en zi al M ob . B ed eu tu n Administration der bestehenden IT-Systeme Durchführung der Kontaktverwaltung (ggf. Customer Relationship Management) z M ob . B ed eu tu ng M ob . P ot en zi al H V er m itt lu ng H V er tre tu ng O pt .P ot en zi al phasenübergreifende Prozesse H V er m itt lu ng | Entgegennahme und Weiterleitung von Bestellungen an Hersteller z - 26 - Die folgenden übergreifenden Schwachstellen (AS) konnten von der ermittelten Ausgangssituation bei den befragten Handelsvermittlungen und -vertretungen abgeleitet werden (Spath et al. 2008a): AS1: Hoher manueller Aufwand seitens der Handelsvertretungen bei der Pflege von Informationen: So wurden die meisten Geschäftstransaktionen noch mit papierbasierten Medien vorgenommen. Oftmals war daher eine manuelle Übernahme der papiergebundenen Informationen in eigene IT- Systeme zur elektronischen Auswertung notwendig. Beispielsweise erhielten Handelsvertreter u. a. Bestellungen von Kunden an den Hersteller als Kopie per Post zugestellt. Um als Handelsvertreter das aktuelle Provisionsvolumen zu berechnen, mussten die Bestellvolumen extrahiert und aufsummiert werden. Dieser Vorgang erfolgte manuell. AS2: Fehlende Aktualität der Informationen: Bei Kundenanfragen waren die befragten Handelsvertreter oft nicht aussagefähig, da aktuelle Informationen z. B. über Geschäftsvorgänge gefehlt haben. So gab es Geschäftsvorfälle, die zwischen Kunden und Lieferant stattfanden, von denen der Handelsvertreter nicht oder erst in einer zeitlichen Verzögerung erfuhr. Die Recherche nach fehlenden Informationen für den Kunden verursachte weiteren Aufwand für den Handelsvertreter und eine negative Wahrnehmung seitens dessen Kunden. AS3: Fehlende Informationen beim Kunden vor Ort: Informationen, die in aktueller Form beim Handelsvertreter in dessen Papierordnern sowie stationären IT-Anwendungen vorlagen, konnten teilweise aufgrund fehlender mobiler IT-Lösungen nicht durch den Handelsvertreter genutzt werden. AS4: Geringe Nutzung von ganzheitlichen IT-Lösungen: Mobile sowie stationäre IT-Lösungen waren überwiegend Insellösungen, ohne tiefere Integration von Systemen intern bei Handelsvertretungen sowie extern bei den Herstellern. Dadurch wurde eine durchgängige medienbruchfreie Unterstützung der Geschäftsprozesse auf Seiten der Handelsvertreter erschwert. AS5: Geringe IT-Kenntnisse bei eigener IT-Administration: Handelsvertreter administrieren oft ihre IT-Systeme persönlich, obwohl im Rahmen der Umfrage festgestellt wurde, dass ein großer Teil die eigenen IT-Kenntnisse als schlecht oder sehr schlecht einschätzte. Die folgenden allgemeinen Optimierungspotenziale (AO) konnten dabei identifiziert werden: AO1: Vorstellung von Produkten durch einen intensiven Einsatz multimedialer Präsentationen von Produkten. AO2: Unterstützung und Beratung bei der Produktauswahl und damit die Aufnahme von Produkten vom Kunden durch den Handelsvermittler bzw. - 27 - -vertreter als Angebotsanfrage bzw. als Bestellung. AO3: Klärung von Kundenanfragen mit Herstellern mit dem Fokus auf die strukturierte Nachverfolgung und Bearbeitung der Aufgaben. AO4: Bereitstellung von Besuchsberichten an Hersteller inklusive einer strukturierten Nachverfolgung und Bearbeitung von Aufgaben durch den Hersteller, aber auch durch Handelsvermittler und -vertreter. AO5: Abgleich der Provisionszahlungen mit Herstellern und einhergehend eine stets aktuelle Aufstellung der abgeschlossenen und offenen Ist- und Soll- Provisionen. AO6: Abgleich der Status von Geschäftsvorfällen mit Herstellern mit möglichst geringem manuellen Aufwand. Des Weiteren konnten die folgenden Optimierungspotenziale auf Basis einer verbesserten mobilen Unterstützung von Geschäftsprozessen (MO) festgestellt werden: MO1: Der Tätigkeitsbereich »Werbung und Information« kann durch die Vorbereitung von Kundengesprächen sowie die Bereitstellung von Produktinformationen mobil unterstützt werden. MO2: Beim Tätigkeitsbereich »Beratung« weisen alle Kernprozesse ein hohes Potenzial durch eine verbesserte mobile Unterstützung auf. Insbesondere sind dabei die Prozesse der Unterstützung und Beratung bei der Produktauswahl und die mobile Erstellung von Angebotsanfragen bzw. Bestellungen durch den Handelsvermittler und -vertreter u. a. beim Kunden vor Ort betroffen. MO3: Beim Tätigkeitsbereich »Verkauf« stehen die Kernprozesse der Klärung von Kundenanfragen mit Lieferanten, die Annahme von Bestelländerungen sowie der Abgleich von Provisionszahlungen im Mittelpunkt der Optimierungs- möglichkeiten durch den Einsatz mobiler Lösungen. MO4: Beim Tätigkeitsbereich »Auftragsabwicklung« können insbesondere die Prozesse der Abfrage und Abgleich von Informationen über Geschäftsvorfälle mobil verbessert werden. Die Untersuchung der IT-Unterstützung zeigt, dass die Verbreitung von komplexen internen IT-Lösungen, wie Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) und Warenwirtschaftssystemen, gering ausfällt. IT- Lösungen zur Unterstützung des zwischenbetrieblichen Geschäftsverkehrs konnten im Rahmen der Umfrage nicht identifiziert werden. So ist die vorhandene IT- Landschaft von Insellösungen geprägt, zwischen denen kein automatisierter Datenaustausch stattfindet. In Abbildung 6 ist der Verbreitungsgrad von IT- Anwendungen in Handelsvertretungen dargestellt. Dabei sind E-Mail- und Office- Anwendungen mit einer Verbreitung in über 80 Prozent der befragten Unternehmen am häufigsten vertreten. IT-Lösungen darüber hinaus fanden keine Anwendung. - 28 - Abbildung 6: Verbreitungsgrad von IT-Anwendungen in Handelsvertretungen 15% 30% 55% 81% 89% 0% 20% 40% 60% 80% 100% Warenwirtschaft Finanzbuchhaltung Kontaktverwaltung Office E-Mail - 29 - Tabelle 1 stellt die zusammenfassenden Untersuchungsergebnisse bzgl. der IT- Unterstützung von Handelsvertretern dar. Aspekt Erkenntnis Systemeinsatz  Neben Office-Anwendungen wie MS-Word, MS-Excel und MS- Outlook existieren u.a. ERP- bzw. CRM-Lösungen. Integrationsgrad  Geringer Integrationsgrad der internen Lösungen, so werden Kontaktdaten und Kundentermine (Verwaltung meist in der Groupware/CRM) oft getrennt von Angebotsanfragen, Bestelldaten und Rechnungen (Verwaltung meist im ERP-System) vorgehalten.  Geringe elektronische Einbindung externer Geschäftspartner. In den meisten Fällen werden die Informationen manuell eingepflegt ohne Nutzung elektronischer Schnittstellen (z.B. Abgleich von Angebots- anfragen, Angebote, Bestellungen, Rechnungen mit dem Lieferant). Genutzte Hardware  Nutzung von Notebooks und Laptops durch die befragten Handelsvertreter ist üblich.  Die Terminplanung und Adressverwaltung erfolgt oft auf PDA und Handy. IT- Administration  Vielfach intensive Einbindung der Handelsvertreter in die Planung und Administration von IT-Anwendungen, bei oftmals geringen IT- Kenntnissen. Tabelle 1: Systemeinsatz sowie IT-Kenntnisse bei Handelsvertretungen Zwei große Probleme für die Einführung von geeigneten IT-Lösungen sind zum einen geringe Budgets für den Kauf von IT-Lösungen und zum anderen die IT-Kenntnisse von Handelsvertretern. So administriert die Hälfte der befragten Handelsvertreter ihre IT-Systeme persönlich, obwohl davon die Hälfte nach eigenen Einschätzungen schlechte bzw. sehr schlechte IT-Kenntnisse besitzt (Spath et al. 2008a). 3.2 Vertriebssysteme und Web-Plattformen für Handelsvertretungen In diesem Abschnitt wird die ganzheitliche informationstechnische Unterstützung der Vertriebsprozesse zwischen Handelsvertretungen und Herstellern eruiert. Dabei stehen die zwei folgenden Fragestellungen im Fokus der Betrachtung: ± Welche prinzipiellen IT-Lösungen existieren, die Vertriebsprozesse zwischen Handelsvertretungen und Herstellern unterstützen? ± Welche Schwachstellen weisen die identifizierten IT-Lösungen hinsichtlich des gegebenen Einsatzbereichs auf? Mit dem Fokus auf Informationsplattformen für Handelsvertretungen wird zum einen die Art der IT-Lösung auf einer webbasierten Plattform und zum anderen der Zweck - 30 - der IT-Lösung auf dem Themenbereich der Vertriebsunterstützung untersucht. Vor diesem Hintergrund werden themenrelevante Web-Plattformen sowie IT-Lösungen der Vertriebsunterstützung seitens Handelsvertretungen und Herstellern nachfolgend auf deren praktischen Einsatz und Eignung geprüft. 3.2.1 Drei grundlegende Kategorien von Vertriebslösungen Es lassen sich drei grundlegend unterschiedliche Lösungsansätze differenzieren, die nachfolgend beschrieben und deren Stärken und Schwächen analysiert werden (siehe Tabelle 3). Vertriebsunterstützung seitens Hersteller (Typ 1) Die Vertriebsunterstützung seitens Hersteller erfolgt durch die Bereitstellung von Vertriebslösungen, wie z.B. Customer Relationship Management Lösungen (CRM), für Handelsvertretungen (siehe Abbildung 7) (vgl. Hippner und Wilde 2007). Der Hersteller oder ein von ihm betreuter IT-Dienstleister betreibt dabei die Vertriebs- unterstützungslösung. Der Handelsvertreter benutzt bei diesem Ansatz für jeden Hersteller eine eigens bereitgestellte Vertriebslösung, auf die er nur unter enger Abstimmung mit seinem Hersteller in geringem Maße Einfluss nehmen kann. Der Hersteller schaltet Handelsvertretungen ausgewählte Funktionalitäten und Vertriebsinformationen seiner Vertriebslösung frei. Hierdurch entfällt eine aufwändige Integration zwischen Systemen auf Handelsvertreter- und Herstellerseite. Sofern schon Funktionalität dem herstellereigenen Vertriebsaußendienst mobil zur Verfügung gestellt wird, kann diese Funktionalität für Handelsvertretungen angepasst und angeboten werden. Abbildung 7: Vertriebsunterstützung seitens Hersteller Hersteller n Hersteller 2 KundeKunde Handelsvertreter Kunden Hersteller 1 ... IT-Lösung 1 zur Vertriebsunterstützung IT-Lösung 2 zur Vertriebsunterstützung IT-Lösung n zur Vertriebsunterstützung ... ... Beteiligte IT-Systeme Unternehmenskontext - 31 - Diese IT-Lösung ist nicht multilieferantenfähig (siehe Abschnitt 3.2.2) und unterstützt damit nicht effizient die Vertriebsprozesse aus Sicht von Handelsvertretungen. Bei durchschnittlich 6 zu vertretenden Herstellern muss sich daher der Handelsvertreter in verschiedene herstellerspezifische Vertriebslösungen einarbeiten. Der Vorteil bei diesem Lösungsansatz liegt darin, dass der Handelsvertreter nicht in die Einführung und den Betrieb der Vertriebslösung involviert ist und damit auch keine tief greifenden IT-Kenntnisse notwendig sind. Vertriebsunterstützung seitens Handelsvertretungen (Typ 2) In diesem Lösungsansatz wird eine Vertriebslösung auf Seite der Handelsvertretung eingeführt und an die vorhandenen Systeme bei Herstellerunternehmen angebunden. Die Handelsvertretung oder ein von der Handelsvertretung beauftragter IT-Dienstleister betreibt die Vertriebslösung. Dies hat den Vorteil, dass die Handelsvertretung die Vertriebslösung nach ihren eigenen Anforderungen anpassen und anwenden kann. Um eine effiziente Nutzung der Vertriebslösung zu gewährleisten, muss die Handelsvertretung allerdings die Integration der Vertriebslösung in die IT-Systeme ihrer Hersteller sowie die mobile Bereitstellung der Informationen aus der Vertriebslösung zur Nutzung beim Kunden vor Ort realisieren. Hippner und Wilde (2007) und Benz et al. (2003) betrachten verschiedene mobile CRM-Lösungen und deren Komplexität bei der Konzeption, Installation, Einführung und Bedienung. Dieser Lösungsansatz besitzt den Nachteil, dass sich die Handelsvertretung trotz ggf. intensiver Unterstützung eines IT-Dienstleisters selber intensiv in die Bereitstellung und Einführung involvieren und sich ggf. in die Integration der Herstellersysteme einbringen muss. Abbildung 8: Vertriebsunterstützung seitens Handelsvertretungen Hersteller n Hersteller 2 KundeKunde Handelsvertreter Kunden Hersteller 1 ... ... IT-Lösung zur Vertriebsunterstützung Beteiligte IT-Systeme Unternehmenskontext - 32 - Vertriebsunterstützung mittels webbasierter Plattform als Mediator (Typ 3) Ein neutraler IT-Dienstleister (Mediator) betreibt die Vertriebslösung als Dienst- leistung. Dabei übernimmt er als Mediator die Integration der Hersteller in die web- basierte Vertriebsplattform und kann mit der Anbindung eines Herstellers ggf. auch mehrere Handelsvertretungen mit Informationen versorgen, sofern für die Nutzer der Plattform keine regionalen Beschränkungen existieren. Auf diese Weise kann der Mediator Skaleneffekte realisieren. Zum Zeitpunkt der Untersuchung existierten zwar einige Plattformen, die insbesondere die Suche nach geeigneten Kooperations- partnern seitens Handelsvertretungen und auch seitens Hersteller unterstützten, aber weitere Vertriebsprozesse beider Parteien wurden nicht berücksichtigt. Plattform Betreiber URL Agent Co Agent Co www.agent-co.de dipeo Marktplatz Mittelstand GmbH & Co. KG www.dipeo.de/handelsvertreter.html Plattform für Handelsvertretung und Vertrieb deutschundfranke mediadesign www.handelsvertrieb.com Plattform für Vertrieb Centralvereinigung Deutscher Wirtschaftsverbände für Handelsvermittlung und Vertrieb CDH www.handelsvertreter.de Tabelle 2: Plattformen für Handelsvertretungen und Hersteller Abbildung 9: Vertriebsunterstützung mittels Web-Plattform als Mediator Hersteller n Hersteller 2 KundeKunde Handelsvertreter Kunden Hersteller 1 Vertriebsplattform ... Beteiligte IT-Systeme Unternehmenskontext - 33 - 3.2.2 Vergleich der drei Kategorien von Vertriebslösungen In Tabelle 3 werden die oben aufgeführten Lösungsansätze anhand funktionaler bzw. weitergehender Anforderungskriterien miteinander verglichen, die sich aus der oben vorgestellten Marktuntersuchung ergaben (Spath et al. 2008a). Zielsetzung hierbei ist es die Stärken und die Schwächen der Ansätze nochmals transparent zu machen. ± Grundlegende funktionale Anforderungen: Anforderungen an die grund- legenden Funktionen der Vertriebslösung (Robertson und Robertson 2006). ± Funktionale Anforderungen der Multilieferantenfähigkeit: Ein Handels- vertreter vertritt durchschnittlich 6 Hersteller. In einzelnen Prozessschritten, wie z.B. bei der Gesprächsvorbereitung, strukturiert der Handelsvertreter diesen Schritt, indem er alle Aktionen, offene Punkte und Fragestellungen für alle zu vertretenden Hersteller zusammenfasst. Nach dem Kundengespräch muss ein Gesprächsprotokoll separat für alle zu vertretenden Hersteller erstellt werden. Hierzu müssen nun die während des Kundengesprächs gemeinsam notierten Informationen nach Herstellern getrennt werden und diesen jeweils zugesendet werden. Ein IT-System, das den Vorgang des Zusammenfassens und Separierens von Vertriebsinformationen nach Herstellern unterstützt, wird in diesem Kontext als multilieferantenfähig bezeichnet (Kett et al. 2009b). ± Funktionale Anforderungen an die Mobilität: Anforderungen, die die mobile Nutzung der Vertriebslösung spezifizieren (siehe z.B. technischer Rahmen mobiler Anwendungen in de Reuver et al. 2008). ± Funktionale Anforderungen an die Systemadministration: Anforderungen an die Funktionen zur Administration der Vertriebslösung. Anforderung Beschreibung Typ 1 Typ 2 Typ 3 F1 Partner suchen Hersteller sucht für ein Produkt(-bereich) eine Handels- vertretung bzw. eine Handels- vertretung sucht weitere Hersteller zur Vertretung in ihrem Gebiet. ż ż ƔƔ F2 Kundenbesuche vorbereiten Handelsvertreter bereitet einen Kundenbesuch vor und muss aktuelle Vertriebsinformationen ab- rufen, z.B. Status Geschäftsvorfälle des Kunden, offene Aufgaben vom letzten Kundengespräch, etc. ż ƔƔ ż F3 Besuchsberichte anlegen und verwalten Während bzw. nach dem Kunden- gespräch werden die Inhalte des Gesprächs in einem Besuchsbericht (Protokoll) festgehalten. Die Inhalte werden je nach Hersteller zusammengefasst und ihnen zur Verfügung gestellt. ƔƔ ƔƔ ż - 34 - Anforderung Beschreibung Typ 1 Typ 2 Typ 3 F4 (multimediale) Produktinformationen bereitstellen Die Hersteller stellen Handels- vertretungen Produktinformationen, wie z.B. technische Spezifikationen, Präsentationen, Gebrauchsanlei- tungen, etc. zur Verfügung. ƔƔ Ɣ ż F5 Funktionen zur Aufnahme von Angebotsanfragen und Bestellungen bei Standard- produkten bereitstellen Im Rahmen eines Kundengesprächs werden Angebotsanfragen bzw. Bestellungen aufgenommen. ƔƔ ƔƔ ż F6 Konfigurator für komplexe Produkte bereitstellen Produkte werden mittels elek- tronischem Konfigurator zusammen- gesetzt. ƔƔ ż ż F7 Projekträume für die kollaborative Entwicklung von Individualprodukten bereitstellen Der Vertrieb von Individualprodukten setzt eine detaillierte Spezifikation der Produkte vor dem Geschäfts- abschluss voraus, auf deren Grund- lage das Produkt anschließend entwickelt und produziert wird. ż ż ż F8 Status und Dokumente von Geschäftsvorgängen verwalten Der Handelsvertreter muss bei Kundenanfragen bzgl. Geschäfts- vorgänge den entsprechenden Status und ggf. dazugehörende Dokumente abrufen können. ƔƔ Ɣ ż F9 Provisionsübersicht abrufen Zur Steigerung der Transparenz bzgl. seiner Provisionseinnahmen benötigt der Handelsvertreter eine Übersicht der aktuellen und der vorhersagbaren Provisionen. Ɣ Ɣ ż F10 Kontakte verwalten Eine zentrale Verwaltung von Kontakten und deren Verknüpfung mit weiteren Vertriebsinformationen. ż ƔƔ ż F11 Termine verwalten Eine zentrale Verwaltung von Terminen und deren Verknüpfung mit weiteren Vertriebsinformationen. ż ƔƔ ż F12 Aufgaben verwalten Eine zentrale Verwaltung von Aufgaben und deren Verknüpfung mit weiteren Vertriebsinformationen. ż ƔƔ ż MU1 Integration in herstellerseitige IT- Lösungen Um Vertriebsinformationen zeitnah bereitstellen zu können, müssen die relevanten IT-Systeme auf Herstellerseite integriert werden. ƔƔ Ɣ ż MU2 Herstellerübergreifende Abfrage von Vertriebsinformationen Bei der Bearbeitung von Geschäfts- vorgängen muss der Handels- vertreter in der Lage sein Hersteller- übergreifende Vertriebsinforma- tionen eines Kunden abrufen zu können. ż Ɣ ż - 35 - Anforderung Beschreibung Typ 1 Typ 2 Typ 3 MU3 Herstellerübergreifende Bearbeitung von Geschäftsvorgängen Der Handelsvertreter muss ebenso in der Lage sein, Herstellerüber- greifend Vertriebsinformationen einpflegen zu können (z.B. Besuchs- berichte). ż Ɣ ż MO1 Ortsunabhängiger Abruf von Vertriebsinformationen Aktuelle Vertriebsinformationen müssen ortsunabhängig abgerufen werden können. ƔƔ Ɣ ż MO2 Ortsunabhängige Pflege von Vertriebsinformationen Vertriebsinformationen müssen orts- unabhängig in die Vertriebsinforma- tionslösung eingepflegt werden können. ƔƔ Ɣ ż A1 Geringe Administration seitens Handels- vertretungen Die Administration von IT-Systemen gehört in den meisten Fällen nicht zu den Kernkompetenzen eines Handelsvertreters und sollte daher weitestgehend minimiert werden. ƔƔ ż ż A2 Geringer Integrations- aufwand seitens Handels- vertretungen Zur Stärkung ihrer Kernkompetenzen sollte sich die Handelsvertretung möglichst wenig mit der Integration von IT-Systemen bei deren Lieferanten beschäftigen. ƔƔ ż ż Legende: Fn = grundlegende funktionale Anforderungen; MUn = Multilieferantenfähigkeit, MOn = Mobilität, An = Administration ƔƔ= Anforderung erfüllt, Ɣ $QIRUGHUXQJ EHGLQJWHUIOOWż $QIRUGHUXQJ QLFKWHUIOOW Typ 1: herstellerseitige Vertriebslösung; Typ 2: handelsvertreterseitige Vertriebslösung; Typ 3: neutrale Vertriebslösung, bereitgestellt durch einen Mediator Tabelle 3: Vergleich der 3 prinzipiellen IT-Lösungen für Handelsvertretungen Das abschließende Ergebnis der Analyse von Vertriebslösungen zeigt, dass die aktuellen, Vertriebslösungen die vertrieblichen Kernkompetenzen von Handels- vertretungen insbesondere die Kommunikation zwischen Handelsvertretung und Hersteller (siehe MU2 und MU3) nicht oder nur unzulänglich unterstützen. - 36 - 3.3 Referenzmodellierung und Referenzmodell Der Begriff des Referenzmodells basiert auf dem Modellbegriff. Hierfür existieren zahlreiche Definitionen, wobei eine in der Forschung häufig auftretende Auffassung von Stachowiak (1973) geliefert wird. Nach Stachowiak (1973) ist der Begriff des Modells durch drei Merkmale gekennzeichnet: 1. Abbildung: Ein Modell ist immer ein Abbild von etwas, eine Repräsentation natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können. 2. Verkürzung: Ein Modell erfasst nicht alle Attribute des Originals, sondern nur diejenigen, die dem Modellschaffer bzw. Modellnutzer relevant erscheinen. 3. Pragmatismus: Pragmatismus bedeutet so viel wie Orientierung am Nützlichen. Ein Modell wird vom Modellschaffer bzw. Modellnutzer innerhalb einer bestimmten Zeitspanne und zu einem bestimmten Zweck für ein Original eingesetzt. Das Modell wird somit interpretiert. Für den erweiterten Begriff des Referenzmodells gelten die aufgeführten Merkmale eines Modells, wobei an ein Referenzmodell zusätzliche Anforderungen gestellt werden. Drei der nach Auffassung von Fettke und Loos (2004) relevanten Explikationen, in denen zusätzliche Anforderungen an ein Referenzmodell gestellt werden, stammen von Hars, Schütte und vom Brocke. Aufbauend auf einem abbildungsorientierten Modellverständnis sieht Hars (1994) als Charakteristikum eines Referenzmodells, dass es nützlich für den Entwurf anderer Modelle ist. Daraus leitet er drei zentrale Anforderungen an ein Referenzmodell ab: Allgemeingültigkeit, Anpassbarkeit und Anwendbarkeit. Schütte (1998) dagegen sieht ein rein abbildungsorientiertes Verständnis eines Modells mit schwerwiegenden Problemen behaftet, da ein Modellierungsträger einen nicht zu vernachlässigenden Einfluss auf die Konstitution der Realität ausübt. In seiner Vorstellung entspricht ein Referenzmodell einer Konstruktion eines Modellierungsträgers und ist damit eine Empfehlung, die als Bezugspunkt bei der Gestaltung von Informationssystemen fungiert. Für Vom Brocke (2003) ist der Modellaspekt nicht das konstitutive Merkmal des Referenzmodellbegriffs, da Referenzmodelle von Menschen zur inhaltlichen Unterstützung bei der Erstellung von Anwendungsmodellen entwickelt und genutzt werden. Daher ist für ihn die potenzielle oder faktische Wiederverwendung in anderen Modellierungskontexten das kennzeichnende Merkmal von Referenz- modellen. Zusammenfassend lässt sich feststellen, dass die ersten beiden Auffassungen auf die Qualitätseigenschaften von Referenzmodellen wie Allgemeingültigkeit und Empfehlungscharakter abheben, die allerdings schwer nachprüfbar sind. Demgegenüber ist die letzte Explikation trennschärfer. Allerdings setzt sie jedes beliebige Modell, das in einem oder mehreren weiteren Kontexten zur Wiederverwendung kommt, mit einem Referenzmodell gleich. Damit fehlt die - 37 - Festlegung von Qualitätsmerkmalen als Mindestvoraussetzung für die Bezeichnung eines Referenzmodells. 3.3.1 Referenzmodellierung Zur Entwicklung bzw. Anwendung eines Referenzmodells stellen Fettke und Loos (2004) den Bezugsrahmen der Referenzmodellierung vor, in dem alle relevanten Elemente und deren Beziehungen untereinander aufgeführt sind. Der Bezugsrahmen besteht aus den folgenden vier Dimensionen, deren Beziehungen in Abbildung 10 dargestellt werden: 1. Sprachen der Referenzmodellierung: Definition einer Menge von sprachlichen Konstrukten zur Repräsentation betrieblicher Systeme sowie Regeln zur Kombination dieser Konstrukte. Beispielsweise sind BPMN (OMG 2010a), EPK (Scheer 1998) und BPEL (OASIS 2007) Sprachen zur Prozessmodellierung. 2. Methoden der Referenzmodellierung: Definition einer Vorgehensweise, um ein Modell durch systematische Anwendung von Konstrukten einer Modellierungssprache zu erstellen und zu verwenden. 3. Referenzmodelle: Ergebnis der Anwendung von Methoden. 4. Kontext der Referenzmodellierung: Festlegung von z. B. psychologischen, sozialen, organisatorischen, technischen und wirtschaftlichen Faktoren, die die realweltliche Modellierungssituation als Grundlage für die Modellierungshandlung beeinflussen. Abbildung 10: Bezugsrahmen der Referenzmodellierung (Fettke und Loos 2004) Kontext der Referenzmodellierung Methoden der Referenzmodellierung Sprachen der Referenzmodellierung Referenzmodell - 38 - Die Elemente des Bezugsrahmens werden zum einen bei der Konstruktion von neuen Referenzmodellen, zum anderen bei der Anwendung von bestehenden Referenzmodellen genutzt. Darüber hinaus sollten bei der Modellierung von Referenzmodellen die Grundsätze der ordnungsmäßigen Modellierung eingehalten werden. Hierzu stellt Remmert (2001) sechs Grundsätze auf, die in Tabelle 4 und Tabelle 5 aufgeführt werden. Bei der Darstellung und Entwicklung des Referenzmodells und der begleitenden Methodik wird nochmals explizit auf die Grundsätze der ordnungsmäßigen Modellierung eingegangen und insbesondere auf die Bedeutung einzelner Grundsätze für das zu entwickelnde Referenzmodell in dieser Arbeit. Dabei wird zwischen zentralen Grundsätzen und ergänzenden Grundsätzen der ordnungsmäßigen Modellierung unterschieden. Grundsatz Subkriterien Erklärung Konstruktions- adäquanz Problemeignung Das Modell (auch mehrere Modelle möglich) liefert einen Lösungsbeitrag zu dem identifizierten Problem. Minimalität Kein Element kann ohne Verlust von Informationen in Bezug auf das Ziel der Modellierung entfernt werden. Intra- Modellkonsistenz Einheitliche Nutzung von Modellierungs- konstrukten innerhalb eines Modells. Inter- Modellkonsistenz Reale Sachverhalte werden in unterschiedlichen Modellen einheitlich dargestellt. Sprachadäquanz Spracheignung Die Spracheignung betrifft die problemorientierte Auswahl einer Sprache. Sprachrichtigkeit Die Sprachrichtigkeit zielt auf die korrekte Verwendung der ausgewählten Sprache ab. Wirtschaftlichkeit Verwendbarkeit Die Verwendbarkeit bezieht sich insbesondere auf der wirtschaftlichen Verwendung einer Sprache (z. B. Anzahl Benutzer, die ohne größere Einarbeitung die Sprache verwenden können und vorhandene technische Modellierungsunterstützung). Robustheit Robustheit gegenüber Änderungen und Flexibilität bei Anpassungen an geänderten Ziel- setzungen des Modells bzw. der Modellierung. Übersetzbarkeit Nutzung der Modelle in anderen ähnlich gelagerten Kontexten. Tabelle 4: Zentrale Grundsätze der ordnungsmäßigen Modellierung (Remmert 2001) Zentrale Grundsätze sollten im Rahmen der ordnungsmäßigen Modellierung eingehalten werden, um die Aussagekraft eines Modells zu gewährleisten. Während die ergänzenden Grundsätze eingehalten werden können, um die Verständlichkeit zu erhöhen. - 39 - Grundsatz Subkriterien Erklärung Systematischer Aufbau Erfassung relevanter Sichten Insbesondere, wenn Mitarbeiter unterschied- licher Fachbereiche und Hierarchiestufen in den Modellierungsprozess involviert sind, ist es wichtig, bei der Modellierung diese unterschied- lichen Hintergründe in Sichten zu berücksich- tigen. Erfassung der Sichtenbeziehungen Verbindung der unterschiedlichen Sichten komplexer Modelle. Klarheit Modell- hierarchisierung Als Ordnungssystem zur Steigerung der Transparenz bei großen Modellen. Filterung Insbesondere die verwenderorientierte Filterung von Modellinhalten steht hier im Mittelpunkt. Vergleichbarkeit - Tabelle 5: Ergänzende Grundsätze der ordnungsmäßigen Modellierung (Remmert 2001) Diese Grundsätze bilden die Grundlage für die Evaluierung des Referenzmodells in Kapitel 1. Eine besondere Sicht auf einen Betrachtungsgegenstand zeigt Zachman (1987) mit dem von ihm entwickelten Zachman Framework. Mit dem Zachman Framework wird ein zu entwickelnder Gegenstand je nach Rolle einer Person im Entwicklungsprozess aus verschiedenen rollenspezifischen Perspektiven betrachtet. Diese Perspektiven und die zu betrachtenden Aspekte werden anhand geeigneter Modelle dargestellt. Die Modelle werden in einer Matrix angeordnet und können zu einem rollenübergreifenden Referenzmodell zusammengeführt werden. 3.3.2 Vergleich von Referenzmodellen Bei der Untersuchung bestehender Referenzmodelle fällt Fettke und Loos (2005) auf, dass die angebotenen Lösungen vielfach isoliert von bereits vorliegenden Referenzmodellen entwickelt worden sind. Um die Möglichkeit der Nutzung geeigneter Modelle im Rahmen dieser Arbeit zu prüfen, wurden themenrelevante Referenzmodelle identifiziert, anhand ausgewählter Kriterien gegenübergestellt und auf deren Eignung für die Themenstellung der Arbeit geprüft. Die im Folgenden aufgeführten Referenzmodelle wurden in die Betrachtung einbezogen: ± Referenzmodell eines Geschäftsprozessmanagements im Vertrieb (Kruse 1996): Auf Basis der ARIS-Architektur (siehe auch Scheer 1998) wird eine Methodik zur modellgestützten Geschäftsprozessgestaltung logistischer Systeme entwickelt. Darauf aufbauend wird ein Vorgehen zum referenzmodellgestützten Geschäftsprozessmanagement am Beispiel der industriellen Vertriebslogistik konkretisiert. Dabei wird u.a. die Möglichkeit der Wiederverwendung konzeptueller Modelle untersucht. ± Referenzmodell Industrieller Geschäftsprozesse (Scheer 1998): Der Kern der Betrachtung liegt hier auf IT-orientierten Rahmenkonzepten, die als - 40 - Ausgangspunkt für spezielle IT-orientierte Problemlösungen in Unternehmen dienen. Eine Realisierung derartiger Rahmenkonzepte erfolgt über Informationssysteme. Informationssysteme sind daher Vermittler zwischen betriebswirtschaftlichen Rahmenkonzepten und der Informationstechnik, die betriebswirtschaftliche sowie informationstechnische Aspekte berücksichtigen und somit eine entsprechende Komplexität aufweisen. Zur Reduktion ihrer Komplexität werden Informationssysteme daher aus Sicht eines Industriebetriebs untergliedert. ± Referenzmodell einer Handelsplattform im Internet (Frank 2000): Aufgrund der steigenden Verbreitung des elektronischen Geschäftsverkehrs u.a. auch über elektronische Marktplätze, werden neue Formen geschäftlicher Transaktionen über das Internet, sowie neue Geschäftsmodelle untersucht und in ein Referenzmodell überführt. ± Referenzmodell elektronischer Handel digitaler Produkte (Luxem 2000): Dieses Referenzmodell bildet ein Rahmenwerk, das auf ausgewählten Forschungsaktivitäten mit Bezug auf den elektronischen Handel digitaler Produkte basiert. U.a. wird hierfür auch das Retail-H-Model (siehe unten) herangezogen. ± Referenzmodell der Handelslogistik (Remmert 2001): Zielsetzung ist die Entwicklung eines Vorgehensmodells der Referenzmodellierung, das sich von den existierenden induktiven Ansätzen durch eine deduktive Art des Modellierens unterscheidet. Es erfolgt eine Eingrenzung auf den Bereich der logistischen Prozesse des stationären Lebensmitteleinzelhandels. Die Anwendbarkeit dieses Verfahrens wird anhand einer exemplarischen Modellierung von Referenzprozessen der Handelslogistik in deduktiver Art evaluiert. ± Referenzmodell elektronischer Geschäftstransaktionen (Kelkar 2002): Die Arbeit beschäftigt sich mit der Entwicklung eines Referenzmodells für elektronische Geschäftsdokumente und Transaktionen. Das Modell dient der Entwicklung von semantisch aufeinander abgestimmten Geschäftsdokumenten sowie deren Übermittlung zwischen zwei und mehreren Geschäftspartnern. ± Referenzmodell einer integrierten Kommunikationsunterstützung kooperierender Partner (Kempf 2003): Die Arbeit fokussiert auf die integrierte Kommunikationsunterstützung von örtlich verteilten Gruppen. Durch die Entwicklung einer ganzheitlichen Lösung wird die vorherrschende Teilfokussierung auf einige wenige Abteilungen von Unternehmen überwunden. In diesem Zusammenhang werden Elemente identifiziert und in das Referenzmodell eingebunden, die die soziale Präsenz von Kommunikationsteilnehmern vermitteln. ± Referenzmodell eines Produktdaten Clearing-Center (Mucha 2004): Der Fokus liegt hierbei auf der Entwicklung eines Referenzmodells für den zwischenbetrieblichen Austausch elektronischer Produktdaten auf Basis eines Produktdaten Clearing Centers. Ein Produktdaten Clearing Center wird hierbei als - 41 - Verarbeitungsinstanz für elektronische Produktdaten im Rahmen des zwischenbetrieblichen Produktdatenaustauschs verstanden. Das Referenzmodell soll dabei als Instrument zur Modellierung und Konzeption von Lösungen für einen qualitätsgesicherten zwischenbetrieblichen Austausch elektronischer Produktdaten dienen. ± Referenzmodell Retail-H-Modell für den Handel (Becker und Schütte 2004): Das Referenzmodell Retail-H-Modell dient als Bezugsrahmen, in den Handels- informationssysteme und die ihnen zu Grunde liegenden Modelle eingeordnet werden können. ± Referenzmodell SCOR für das Supply Chain Management (Supply Chain Council 2010): Das Supply Chain Operations Reference Model SCOR integriert die bekannten Konzepte des Business Reengineering, Benchmarking und Prozess Controlling in ein ganzheitliches Rahmenwerk mit dem Schwerpunkt Supply Chain Management. Die aufgeführten Referenzmodelle wurden anhand der nachfolgend aufgeführten Kriterien gegenübergestellt und auf deren Eignung für die Entwicklung des Referenzmodells in dieser Arbeit geprüft: ± Anwendungsbezug: Da ein Modell eine realweltliche Abbildung von etwas darstellt, ist es sinnvoll, den Kern des Modells zur einfacheren Identifikation und Zuordnung des Modells zu benennen. ± Sprache(n): Unter Sprache(n) werden die Modellierungssprachen aufgelistet, die zur Darstellung des Referenzmodells herangezogen werden. ± Methoden: Nur wenige Referenzmodelle liefern explizite methodische Hinweise, wie das konstruierte Referenzmodell in bestimmten Kontexten verwendet werden kann (Fettke und Loos 2004). Deshalb wird unter diesem Aspekt der Grad der methodischen Unterstützung insbesondere in Hinblick auf die Wiederverwendung des Modells untersucht und aufgezeigt. Die Ergebnisse werden in drei Stufen klassifiziert: Das Referenzmodell stellt umfangreiche Methoden für die WiederYHUZHQGXQJ GHV 0RGHOOV EHUHLW ƔƔ), gibt einige methodische Hinweise zum Thema der Wiederverwendung (Ɣ) oder berücksichtigt Methoden für die WiederYHUZHQGXQJ LQQLFKW QHQQHQVZHUWHP 8PIDQJ ż  ± Kontext: Um die Wiederverwendung von Modellen im Rahmen der Arbeit konkret zu prüfen, werden Kriterien des Anwendungsbezugs ausgewertet und vergleichend aufgeführt. Für diesen Vorgang werden die folgenden sechs Kriterien in drei Stufen klassifiziert: Der betreffende Anwendungsbezug steht im Fokus des Referenzmodells (ƔƔ), wird teilweise im Rahmen des Modells berücksichtigt (Ɣ) oder wird in nicht nennenswertem Umfang beWUDFKWHW ż  ± Vertrieb: Vertrieb hebt insbesondere auf Aspekte wie Verkauf, Warenverteilung (Logistik), Steuerung der Außendienstorganisation und Pflege der Beziehungen eines Herstellers zum Handel bzw. beim Direktvertrieb zum Endkunden ab (Sellien und Sellien 1988). - 42 - ± Handel: Alle Institutionen, die ausschließlich oder überwiegend Handel im funktionellen Sinn betreiben, d. h. die hauptamtlich Waren, an denen mit Ausnahme geringfügiger Veredelungs- und Pflegeleistungen keine grundsätzlichen produktionstechnischen Veränderungen vorgenommen wurden, kollektieren und distribuieren (Sellien und Sellien 1988). ± Electronic Business: Electronic Business bedeutet die teilweise oder vollständige Unterstützung der Anbahnung, Vereinbarung und Abwicklung elektronischer Leistungsaustauschprozesse mit Hilfe öffentlicher oder privater Kommunikationsnetze (z. B. Internet) zur Erzielung einer Wertschöpfung (Kruse 1996), z. B. durch Website, E-Shop, elektronische Märkte und Portale. ± Handelsvertretung: Handelsvertreter ist derjenige, der als selbstständiger Gewerbetreibender ständig damit betraut ist, für einen anderen Unternehmer Geschäfte zu vermitteln oder in dessen Namen abzuschließen (Bundesministerium der Justiz 2010; Sellien und Sellien 1988) (vgl. Definition D1 auf Seite 17). ± Dienstleistungskonzept: Laut Bullinger et al. (2003) ist die Zielsetzung eines Dienstleistungskonzepts die Dienstleistung analog zu Produkten greifbar zu machen. Dazu werden in diesem Konzept die benötigten Ressourcen (Struktur Dimension), die Prozesse (Prozess Dimension), die Dienstleistung als Produkt (Ergebnis Dimension) und der Marketingrahmen definiert und beschrieben. ± Prozesse: Ein Geschäftsprozess ist eine zeitliche und sachlogisch abhängige Menge von Unternehmensaktivitäten, die ein bestimmtes, unternehmens- relevantes Ziel verfolgen und zur Bearbeitung auf Unternehmensressourcen zurückgreifen (Rump 1999). ± Informationssysteme: Computergestützte betriebswirtschaftliche Informa- tionssysteme sind das Vehikel, um betriebswirtschaftliche Anwendungs- konzepte mit der Informationstechnik zu verbinden (Scheer 1998). ± Evaluation: Zu den meisten Referenzmodellen liegen keine gesicherten Erkenntnisse zu ihrer Anwendungshäufigkeit vor. Falls Anwendungsfälle beschrieben werden, handelt es sich um wenige (”3) Fallstudien (Fettke und Loos 2005). Daher wird zwischen folgenden drei Stufen unterschieden: Das Referenzmodell wird vielfach DQJHZHQGHW ƔƔ), wurde anhand von einigen Fallstudien geprüft (Ɣ RGHUZXUGHQLFKW YDOLGLHUW ż  Tabelle 6 und Tabelle 7 stellen die ausgewählten Referenzmodelle im Überblick dar. Bei Betrachtung des wirtschaftlichen Fokus der Modelle, liegen die Schwerpunkte auf Vertrieb und Handel bzw. auf Handel unter Nutzung von Electronic Business Lösungen. Besonderes Augenmerk wird dabei auf Geschäftsbeziehungen zwischen Händlern/Hersteller und deren Kunden gelegt. Hier kommt wieder eine klare Trennung der Organisationen verschiedener Geschäftspartner zum Tragen. Aspekte von Handelsvertretungen, insbesondere deren Geschäftsbeziehungen mit ihren Herstellern, finden keine Berücksichtigung. - 43 - Die inhaltlichen Schwerpunkte der Arbeiten liegen vor allem auf der Betrachtung von Prozessen und einer geeigneten informationstechnischen Unterstützung aus Sicht von Anwenderunternehmen, die die Modelle im eigenen Unternehmen anwenden. Eine Betrachtung des Themas aus Sicht von IT-Dienstleistern erfolgt in keinem der Modelle. Dies wird u.a. durch die Tatsache ersichtlich, dass keines der Modelle das Thema eines Dienstleistungskonzepts aufgreift und diskutiert. Nur ein geringer Teil der Modelle gibt auch methodische Hinweise für deren Anwender, wie das Modell praktisch eingesetzt werden kann. Diese Hinweise sind jedoch notwendig, um die Einführung in die Nutzung des Modells zu vereinfachen. Autor(en) Quelle Anwendungsbezug Sprachen M et ho de n Kruse Kruse 1996 Geschäftsprozess- management im Vertrieb Funktionsbäume, EPK, ERM ƔƔ Scheer Scheer 1998 Industrielle Geschäfts- prozesse Funktionsbäume, EPK, ERM ƔƔ Frank Frank 2000 Handelsplattform im Internet UML Ɣ Luxem Luxem 2000 Elektronischer Handel digitaler Produkte Funktionsbäume ż Remmert Remmert 2001 Handelslogistik EPK Ɣ Kelkar Kelkar 2002 Elektronische Geschäfts- transaktionen XML ż Kempf Kempf 2003 Integrierte Kommunika- tionsunterstützung kooperierender Partner UML ż Mucha Mucha 2004 Produktdaten Clearing- Center UML, XML ż Becker/ Schütte Becker und Schütte 2004 Retail-H-Model Funktionsbäume, EPK, ERM, u.a. ƔƔ SCOR Supply Chain Council 2010 Supply Chain Management Business Scope Diagram, Geographic Map, Thread Diagramm, Workflow Models ż ƔƔ = Aspekt wird vom Modell abgedeckt, Ɣ = Aspekt wird teilweise vom MoGHOO EHUFNVLFKWLJWż  Aspekt findet keine nennenswerte Berücksichtigung im Modell Tabelle 6: Vergleich von Referenzmodellen anhand deren Zielsetzung und Aufbau - 44 - Bei der Untersuchung der eingesetzten Modellierungssprachen, lassen sich zwei grundlegende Gruppen identifizieren: Modelle, die auf EPK (Scheer 1998), ERM (Chen 1977) und Funktionsbäume (Balzert 2000) als Modellierungssprachen basieren, sowie Modelle, die UML (OMG 2010b) für diesen Zweck einsetzen. Lediglich das SCOR-Modell greift auf eigens für den Bereich des Supply Chain Managements entwickelte Modell zurück (Supply Chain Council 2010). Auffällig ist die Intensität der Evaluation der Referenzmodelle. Viele der Modelle wurden nicht oder nur an einigen wenigen Anwendungsfällen evaluiert. Autor(en) Quelle V er tri eb H an de l E le ct ro ni c B us in es s H an de ls - ve rtr et un g D ie ns tle is - tu ng sk on ze pt P ro ze ss e In fo rm at io ns - sy st em e E va lu at io n Kruse Kruse 1996 ƔƔ Ɣ ż ż ż ƔƔ ƔƔ ż Scheer Scheer 1998 Ɣ ż ż ż ż ƔƔ ƔƔ k. A. Frank Frank 2000 Ɣ ƔƔ ƔƔ ż ż ƔƔ ƔƔ Ɣ Luxem Luxem 2000 Ɣ ƔƔ ƔƔ ż ż ż ż ż Remmert Remmert 2001 ż ƔƔ ż ż ż ƔƔ Ɣ Ɣ Kelkar Kelkar 2002 Ɣ ż ƔƔ ż ż ż Ɣ Ɣ Kempf Kempf 2003 ż ż ż ż ż ƔƔ Ɣ Ɣ Mucha Mucha 2004 Ɣ Ɣ Ɣ ż ż ƔƔ ƔƔ Ɣ Becker/ Schütte Becker und Schütte 2004 ƔƔ ƔƔ Ɣ ż ż ƔƔ ƔƔ k. A. SCOR Supply Chain Council 2010 Ɣ Ɣ ż ż ż Ɣ ż ƔƔ ƔƔ = Aspekt wird vom Modell abgedeckt, Ɣ = Aspekt wird teilweise vom Modell beUFNVLFKWLJWż  Aspekt findet keine nennenswerte Berücksichtigung im Modell Tabelle 7: Vergleich von Referenzmodellen anhand deren inhaltlichen Ausrichtung 3.4 Methoden zur Entwicklung elektronischer Dienstleistungen und Dienste Nachdem im vorherigen Abschnitt bei den Referenzmodellen u.a. die fehlende methodische Unterstützung festgestellt wurde, wird in diesem Abschnitt geprüft, welche Methoden die Entwicklung (elektronischer) Dienstleistungen und Dienste geeignet unterstützen können. Die Entwicklung einer webbasierten Vertriebsplattform für Handelsvertreter kann zum einen als Dienstleistung zum anderen als Dienst betrachtet werden (siehe Abschnitt 2.2). - 45 - Grundlage für die betriebswirtschaftlich geprägten Definitionen von Dienstleistungen sind die folgenden Eigenschaften (Corsten 1997; Rai und Sambamurthy 2006; Chesbrough und Spohrer 2006): ± Immaterialität, ± Produktion und Verbrauch erfolgen gleichzeitig (Uno-actu-principle), ± Integration des Kunden als externen Faktor im Dienstleistungserbring- ungsprozess. Aspekte der technischen Umsetzung werden dabei nicht berücksichtigt. Aus technischer Sicht muss vor allem die Funktionalität der Diensteschnittstellen festgelegter technischer Standards der einfachen Integration und Nutzung entsprechen (Papazoglou et al. 2006; Papazoglou 2003): ± Selbstbeschreibend: Die Notation von Meta-Daten erlaubt die Zuordnung von Beschreibungen und bestimmenden Kriterien zu einem Dienst. ± Plattformunabhängig: Der Dienst ist unabhängig von der zugrundeliegenden Hard- und Software. ± Komposition: Verteilte Anwendungen und deren Funktionalität können durch Komposition realisiert werden. ± Nutzung von Standards: Die Funktionalität eines Dienstes wird über ein Netzwerk und standardisierte Sprachen und Protokolle angeboten. ± Lose Koppelung: Weder Hintergrundinformationen noch weitergehende Informationen der internen Funktionalität werden von Diensteanbieter und Kunden benötigt. In diesem Zusammenhang sollte eine dynamische Echtzeitintegration (zum Nutzungszeitpunkt) der Dienste durch die Verwendung anerkannter Aufruf-Mechanismen ausreichend sein. ± Transparente Lokation: Der Dienst kann gefunden und aufgerufen werden durch die Registrierung in einem Diensteverzeichnis unabhängig von der Lokation des Diensteanbieters. Durch die überwiegende Berücksichtigung der aufgeführten technischen Aspekte werden bei der Definition eines Dienstes betriebswirtschaftliche Gesichtspunkte weitestgehend vernachlässigt. Daher stellt sich die Frage, ob Methoden der Dienstleistungs- sowie der Diensteentwicklung existieren, die die Entwicklung einer webbasierten Informationsplattform ganzheitlich unter Einbeziehung strategischer, betriebswirtschaftlicher und technischer Aspekte unterstützen. Daun und Klein (2004) betrachten existierende Vorgehensweisen der Dienstleistungsentwicklung und vergleichen die darin adressierten Aspekte. Basierend auf diesem Vergleich wurden nachfolgend weitere Aspekte abgeleitet, die in Vorgehensweisen zur übergreifenden (strategisch, betriebswirtschaftlich sowie technisch) Dienstleistungs- und Diensteentwicklung Berücksichtigung finden sollten. - 46 - ± Unternehmensstrategie: Die Entwicklung einer Unternehmensstrategie umfasst die langfristige Zielsetzung und Ausrichtung einer Organisation. Dabei werden vorhandene Ressourcen auf das wechselnde Umfeld einer Organisation abgestimmt, wie z.B. Märkte und Kunden, um die Erwartungen der Beteiligten bestmöglich zu erfüllen. (Johnson und Scholes 1997) ± Ideenfindung und -bewertung: Service Innovationen sind für die Entwicklung vieler Unternehmen von zentraler Bedeutung. Hierzu werden neue Ideen identifiziert und für eine Vorauswahl im Rahmen eines Screening-Verfahrens gefiltert. (Nieschlag et al. 1997) ± Service Strategie (mit Fokus auf Geschäftsmodell): Osterwalder (2004) definiert das der Service Strategie zugrundeliegende Geschäftsmodell eines Services als ein konzeptionelles Modell, das die Zusammenhänge des Geschäfts sowie der Gewinnerzielung eines Unternehmens darstellt. Das Geschäftsmodell ist damit Bindeglied zwischen der Unternehmensstrategie und den Geschäftsprozessen. ± Fachliche Konzeption (mit Fokus auf Geschäftsprozesse): Die fachliche Konzeption enthält eine Zusammenfassung aller fachlichen Basisanforderungen, die das zu entwickelnde Software-Produkt erfüllen muss. Dabei findet eine bewusste Konzentration auf die fundamentalen Eigenschaften des Produkts statt. (Balzert 2000) ± Technische Konzeption (mit Fokus auf IT-Architektur für Organisation und Lösung): Eine Software-Architektur (als Schwerpunkt der technischen Konzeption) ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Komponenten. (Balzert 2000) ± Technische Umsetzung (mit Fokus auf Diensten): Bei der technischen Umsetzung steht die Erstellung eines elektronischen Dienstes im Mittelpunkt. Existierende Vorgehensweisen und Methoden sind z.B. Service-Oriented Modeling Framework SOMF(Bell 2010, 2008; Marks und Bell 2006), Service- Oriented Modeling and Architecture SOMA (Zimmermann et al. 2005; Endrei et al. 2004) und Service-Oriented Analysis and Design SOAD (Zimmermann 2009; Zimmermann et al. 2005; Zimmermann et al. 2004). ± (Vorbereitung) Markteinführung: Hierunter sind alle Aspekte und Aktivitäten zu verstehen, die die Vorbereitung und die eigentliche Einführung eines Dienstes auf einem Markt betreffen (Daun und Klein 2004; Bullinger et al. 2003; Bullinger und Schreiner 2003). ± Modellbasierter Lösungsansatz: Im Kern der Arbeit werden Informationen, die aktuell nur un- bzw. semistrukturiert vorliegen, schon in frühen Phasen des Entwicklungsprozesses in Form von Modellen strukturiert erarbeitet, verwaltet und miteinander verknüpft (Ansatz der modellbasierten Entwicklung MDD/MDE), um auf diese Weise die systematische Entwicklung von Dienstleistungen und Diensten zu unterstützen (siehe Abschnitt 2.2 und vergleiche SWOT von - 47 - MDD/MDE in Gholamie und Ramsin 2010 und den Aufbau von MDA in Asadi et al. 2008). Drei unterschiedliche Gruppierungen von Methoden und Vorgehensmodellen der Dienstleistungs- und Diensteentwicklung konnten identifiziert werden: New Service Development (NSD), Service Engineering und die Entwicklung Service-orientierter Architekturen (SOA). Während die Vorgehensmodelle des NSD in den 80er Jahren in der angloamerikanischen Literatur überwiegend mit einem starken Fokus auf den Bereich des Marketings entwickelt wurden, entstanden die Vorgehensmodelle des Service Engineering parallel in Deutschland mit einem stärkeren interdisziplinären Ansatz (Daun und Klein 2004). Letzteres hat die Zielsetzung, vorhandenes ingenieurwissenschaftliches Know-How aus dem Bereich der klassischen Produktentwicklung in den Entwicklungsprozess von Dienstleistungen einzubinden. Die Entwicklung Service-orientierter Architekturen ist wiederum ein softwaretechnischer Ansatz aus der Informatik, bei dem vor allem die flexible softwaretechnische Umsetzung fachlicher Anforderungen im Mittelpunkt steht (Zimmermann et al. 2004). Die Vorgehensmodelle des NSD (siehe Tabelle 8) berücksichtigen bei der Entwicklung traditioneller Dienstleistungen strategische Aspekte des Unternehmens sowie der Dienstleistung, wie z.B. strategische Ziele sowie langfristige Ausrichtung von Unternehmen und deren Dienstleistungen (Daun und Klein 2004). Allerdings wird eine technische Umsetzung der Dienstleistungen nicht unterstützt. Bei den Vorgehensmodellen des Service Engineering (siehe Tabelle 8) stehen die Bereiche der Ideenfindung und -bewertung, die fachliche Konzeption, die Umsetzung und die Markteinführung im Fokus der Betrachtung. Bei der technischen Konzeption und Umsetzung werden teilweise auch technische Aspekte für die Entwicklung traditioneller Dienstleistungen mit direktem Kundenkontakt einbezogen. - 48 - New Service Development Service Engineering Quelle B oo z et a l. 19 68 B oo z et a l. 19 82 B ow er s 19 85 D on ne lly e t a l. 19 85 Jo hn so n et a l. 19 86 D IN D eu ts ch es In st itu t fü r N or m un g e. V . 1 99 8 Fä hn ric h 19 99 R ei ch w al d et a l. 20 00 H al le r 2 00 5 S ch re in er u nd N äg el e 20 02 Anmerkung - - - - - - - - - - Fokus Traditionelle Dienstleistungen Traditionelle Dienstleistungen Unternehmensstrategie ż ż ƔƔ Ɣ Ɣ ż ż ż ż ż Ideenfindung und -bewertung ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ Service Strategie ż ƔƔ ƔƔ Ɣ Ɣ ż ż ż ż ż Fachliche Konzeption ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ Technische Konzeption ż ż ż ż ż ż Ɣ ż ż Ɣ Technische Umsetzung ż ż ż ż ż ż ż ż ż ż (Vorbereitung) Markteinführung ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ Modellbasierter Lösungsansatz ż ż ż ż ż ż ż ż ż ż ƔƔ = Themenbereich wird vom Vorgehensmodell abgedeckt, Ɣ = Themenbereich wird teilweise vom 9RUJHKHQVPRGHOO EHUFNVLFKWLJW ż  7KHPHQEHUHLFh findet keine nennenswerte Berücksichtigung im Vorgehensmodell Tabelle 8: Vergleich von Vorgehensmodellen zur Entwick lung traditioneller Dienstleistungen Die Vorgehensmodelle der Entwicklung Service-orientierter Architekturen (siehe Tabelle 9) bieten meist Methoden und Werkzeuge für die Modellierung fachlicher Prozesse, die Ableitung einer technischen Konzeption und die technische Service- orientierte Umsetzung und dienen zur unternehmensinternen Optimierung der IT- Infrastruktur. Der Vertrieb und das Marketing von Dienstleistungen finden dabei keine Berücksichtigung, so dass Ideenfindung und -bewertung sowie die Service Strategie keine Rolle spielen. - 49 - Entwicklung Service-orientierter Architekturen (SOA) Quelle A rs an ja ni 2 00 4 Zi m m er m an n et al . 2 00 4 Le w is e t a l. 20 05 S eh m i u nd S ch w eg le r 2 00 6 B el l 2 00 8 B er ke m 2 00 8 Anmerkung SOMA SOAD SMART Motion SOMF BMM Fokus Elektronische Dienste/ Dienstleistungen Unternehmensstrategie ż ż ż ż ż ż Ideenfindung und -bewertung ż ż ż ż ż ż Service Strategie ż ż ż ż ż ż Fachliche Konzeption ƔƔ ƔƔ ż ƔƔ ƔƔ ƔƔ Technische Konzeption ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ Technische Umsetzung ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ ƔƔ (Vorbereitung) Markteinführung ż ż ż ż ż ż Modelbasierter Lösungsansatz ż ƔƔ ż ż ż ż ƔƔ = Themenbereich wird vom Vorgehensmodell abgedeckt, Ɣ = Themenbereich wird teilweise vom 9RUJHKHQVPRGHOO EHUFNVLFKWLJWż 7KHPHQEHUHLFK ILQGHWNHLQHQHQQHQVZHUWH %HUFNVLFKWLJXQJ im Vorgehensmodell SOMA = Service-oriented Modeling and Architecture, SOAD = Service-Oriented Analysis and Design, SMART = Service-oriented Migration and Reuse Technique, SOMF = Service-Oriented Modeling Framework, BMM = Business Motivation Model Tabelle 9: Vergleich von Vorgehensmodellen zur Entwick lung elek tronischer Dienste Einige der Vorgehensmodelle zur Entwicklung traditioneller Dienstleistungen gehen auf die Entwicklung einer Service Strategie ein. Dies erfolgt jedoch nicht anhand von konkreten Modellen, sondern mittels Methoden und Vorgehensweisen. Die Vorgehensweisen zur Entwicklung Service-orientierter Architekturen berücksichtigen das Thema Service Strategie und Geschäftsmodelle nicht. Um einen ganzheitlich modellbasierten Ansatz von der strategischen Planung bis zur konkreten Umsetzung von Dienstleistungen und Diensten zu ermöglichen und die Informationsplattform für Handelsvertreter und -vermittler zielgruppenspezifisch auszurichten, ist es daher notwendig im Rahmen dieser Arbeit vorhandene modellbasierte Ansätze der Geschäftsmodellentwicklung auf deren Einsatz- tauglichkeit zu überprüfen. Dies erfolgt im nächsten Abschnitt. - 50 - 3.5 Modelle und Vorgehen zur Geschäftsmodellentwicklung Um die Bedeutung von Geschäftsmodellen bei der zielgruppenspezifischen Ausrichtung der Informationsplattform zu verstehen, sind nachfolgend die Definition und relevante Aspekte über Geschäftsmodelle aufgeführt: Definition D4: Ein Geschäftsmodell ist ein konzeptionelles Werkzeug, das aus einem Set an Elementen und deren Beziehungen zueinander besteht, mit dem es Unternehmen möglich ist festzulegen, auf welche Art und Weise sie ihr Geld verdienen. Es ist eine Beschreibung des Nutzens, den ein Unternehmen ein oder mehreren Kundensegmenten anbietet, der Architektur der Firma und des Netzwerks an Kooperationspartnern diesen Nutzen zu schaffen, zu vermarkten und zu liefern sowie des Kapitals guter Kundenbeziehungen, um nachhaltigen, profitablen Umsatz zu generieren (Osterwalder 2004). Osterwalder et al. (2005) unterscheidet die folgenden drei Kategorien zur Beschreibung von Geschäftsmodellen: Geschäftsmodell- konzept: Geschäftsmodellkonzepte sind Metamodelle (auch Ontologien), die aus einem Set aus Geschäftsmodellelementen bestehen. Mit den Elementen können verschiedene Geschäftsmodelltypen modelliert werden. Dabei werden die einzelnen Elemente miteinander in Verbindung gesetzt und anhand ihrer Attribute beschrieben, wie z.B. in Bullinger et al. (2003), Gordijn und Akkermans (2003) und Osterwalder (2004). Geschäftsmodell- typ: Geschäftsmodelltypen werden in Taxonomien durch die Zuordnung von charakteristischen Geschäftsmodellelementen unterschieden. Dabei stehen Geschäftsmodelltypen für mehrere konkrete Anwendungsfälle. Taxonomien bieten einen Überblick über bestehende Geschäftsmodellalternativen und bieten mögliche Varianten bei der Anwendung eines Geschäftsmodelltyps, z.B. unterschiedliche Preismodelle, Beispiele von Vertriebskanälen, typische Zielkunden, etc. (siehe z.B. Baatz 1996; Timmers 1998; Linder und Cantrell 2000; Weill und Vitale 2001; Afuah und Tucci 2003; Lumpkin und Dess 2004; Kuhn 2007, 2007; Nüttgens und Dirik 2008) Geschäftsmodell- instanz: Die Geschäftsmodellinstanz ist ein Geschäftsmodell für einen konkreten Anwendungsfall, der mittels der charakteristischen Geschäftsmodellelemente beschrieben wird. Dies erfolgt anhand von Good oder Best Practice Fällen, die einerseits den Aufbau eines Geschäftsmodells illustrieren, andererseits die Erfahrungen eines Unternehmens bei der Umsetzung des Geschäftsmodells dokumentieren, wie z.B. Xerox (Chesbrough und Spohrer 2006), Dell (Kraemer und Dedrick 2000) und OnStar Projekt von General Motors (Barabba und Huber 2002). - 51 - Für die vorliegende Arbeit besitzt das Geschäftsmodellkonzept aufgrund seines Modellcharakters eine zentrale Rolle bei der Strukturierung strategischer Informationen der Dienstleistungs- und Dienstentwicklung. Im Rahmen der Literaturrecherche konnten die nachfolgenden drei wesentlichen Ansätze von Geschäftsmodellkonzepten identifiziert, verglichen und auf deren Eignung geprüft werden. Service Konzept Das Service Konzept ist Bestandteil des Service Engineering Prozesses. Bullinger et al. (2003) stellt einen strukturierten Ansatz vor, wie Dienstleistungen in Anlehnung an die technische Disziplin der Produktentwicklung erstellt werden können. Dieser Ansatz umfasst drei Schlüsselmodelle: Ressourcen-, Produkt- und Prozessmodell. Der Markt wird anhand der Zielgruppe und der Vertriebskanäle im Modell berücksichtigt. Allerdings findet keine Betrachtung der Integration von mehreren Kooperationspartnern zur Bereitstellung und Abwicklung der Dienstleistung statt. Ebenso werden finanzielle Aspekte nicht berücksichtigt. Die Elemente des Dienstleistungskonzepts werden nicht durch Attribute näher beschrieben. e3-Value Ontology Im Vergleich zu dem oben aufgeführten Service Konzept berücksichtigt die e3-Value Ontology die Integration von Kooperationspartnern, die bei der Dienstleistungs- erbringung mitwirken (Gordijn und Akkermans 2003). Die Ontologie unterscheidet zwischen einer »Value Web« und einer »Trust« Perspektive. Erstere modelliert die Entwicklung, die Distribution und die Erbringung von Dienstleistungen und deren wirtschaftliche Werte innerhalb eines Netzwerks von mehreren Kooperationspartnern und Endverbrauchern. Das Ziel dieser Perspektive ist es ein gemeinsames Verständnis des Geschäftsmodells bei allen Beteiligten aufzubauen sowie die mögliche Profitabilität abzuschätzen. Die »Trust« Perspektive zeigt auf, wie Value Webs basierend auf vertrauenswürdigen Kontrollprozeduren vergrößert werden können, um auf diese Weise das gegenseitige Vertrauen der Beteiligten zu stärken und eine Kooperation zu ermöglichen (Gordijn und Tan 2005). Business Model Ontology Osterwalder schlägt ein generisches Metamodell für die Modellierung von Geschäftsmodellen vor (Osterwalder 2004). Er analysiert detailliert 14 unterschiedliche Geschäftsmodellansätze und leitet daraus ein generisches Metamodell ab. Für dieses Metamodell hat Osterwalder Elemente ausgewählt, die für das Geschäftsmodell eines Unternehmens inklusive eines Netzwerks an Kooperationspartnern relevant sind und von diesen direkt beeinflusst werden können. Das Metamodell wurde hauptsächlich für die Entwicklung eines Geschäftsmodells aus Sicht einer Organisation erstellt. In Osterwalder und Pigneur (2010) wurde das generische Metamodell durch einen Rahmen (Canvas) mit - 52 - 9 Bereichen für die Geschäftsmodellentwicklung vorgestellt. Die Elemente sowie Attribute werden dabei nicht mehr vorgegeben. Vergleichs- kriterium Erklärung S er vi ce K on ze pt e3 -V al ue O nt ol og y B us in es s M od el O nt ol og y Zielkunden- segment Spezifikation der Zielkundensegmente und deren charakteristischen Eigenschaften Ɣ ż Ɣ Dienstleistung Festlegung der wichtigsten Merkmale der zu entwickelnden Dienstleistung. Ɣ Ɣ Ɣ Dienstleistungs- erbringung Spezifikation der relevanten Elemente des Dienstleistungserbringungsprozesses, wie Schlüsselprozesse, Kompetenzen und Ressourcen. Ɣ Ɣ Ɣ Profitabilität Abschätzung der Kosten, Erlöse und der Gewinne, die mit der Investition in das Geschäftsmodell für jeden Kooperationspartner voraussichtlich anfallen. ż ƔƔ Ɣ Partnerintegration Adressiert Aspekte der Integration von Kooperationspartnern, die Kompetenzen und Ressourcen für die Dienstleistungserbringung beitragen. ż ƔƔ Ɣ ƔƔ Kriterium wird berücksichtigtƔ Kriterium ZLUGEHGLQJWEHUFNVLFKWLJWż Kriterium wird nicht berücksichtigt Tabelle 10: Vergleich von Geschäftsmodellansätzen Die drei Geschäftsmodellansätze wurden in Tabelle 10 gegenübergestellt und anhand der fünf aufgeführten Kriterien verglichen. Um die Vergleichskriterien zu erhalten, wurde ein Workshop mit vier Unternehmen durchgeführt, die Interesse an der Erstellung einer webbasierten Informationsplattform für Handelsvertreter und Hersteller mit weiteren Kooperationspartnern hatten. Mit diesen Unternehmen wurden auf Basis der oben aufgeführten Geschäftsmodellansätzen Fragestellungen erarbeitet, die für die Unternehmen im genannten Kontext relevant waren. In Tabelle 15 sind die aufgenommenen Fragestellungen aufgeführt. Aus diesen Fragestellungen sind die fünf Vergleichskriterien abgeleitet worden. - 53 - Nur der Geschäftsmodellansatz von Osterwalder erfüllte alle der abgeleiteten Kriterien. Daher wurde dieser Ansatz mit einem der oben genannten Unternehmen durchgesprochen. Zwei grundlegende Nachteile sind bei der Prüfung aufgefallen, so dass der Ansatz die vorliegende Zielsetzung nur bedingt erfüllt: ± Die von Osterwalder vorgeschlagenen 20 Elemente zur Modellierung von Geschäftsmodellen sind zu komplex und unübersichtlich in der Anwendung im genannten Unternehmenskontext. ± Die Attribute, die Osterwalder zur detaillierten Beschreibung von Geschäfts- modellen vorschlägt, werden vom Unternehmen für den genannten Kontext nicht als relevant und zielführend erachtet. Als Ergebnis wurde daher aufgenommen: Der Ansatz von Osterwalder zur Modellierung von Geschäftsmodellen ist eine geeignete Grundlage für die weiteren Arbeiten, die jedoch noch maßgeblich an die Anforderungen der vorliegenden Aufgabenstellung angepasst werden muss. 3.6 Schlussfolgerungen aus dem Stand der Technik und Wissenschaft Zusammenfassend lassen sich folgende Erkenntnisse aus den Ergebnissen ableiten: 1. Komplexe Ausgangssituation: Aufgrund der komplexen Ausgangssituation der Zielkunden ± über 87 Prozent der Handelsvertretungen beschäftigen weniger als 6 Mitarbeiter bzw. über 50 Prozent der Handelsvertretungen besitzen schlechte oder sehr schlechte IT-Kenntnisse ± ist die Erschließung dieses Marktes für IT- Lösungsanbieter schwierig (siehe Abschnitt 3.1). 2. Fehlende IT-Unterstützung: Um die Vertriebsprozesse von Handelsvertretern und der zu vertretenen Hersteller zu unterstützen, reichen die existierenden Ansätze nicht aus. Eine entsprechende IT-Lösung muss umfassend die aufgestellten Anforderungen erfüllen (siehe Abschnitt 3.2). 3. Fehlendes Modell zur ganzheitlichen Entwicklung einer webbasierten Informationsplattform: Des Weiteren existiert kein passendes Modell, das die Konzeption, Entwicklung und Umsetzung einer elektronischen Vertriebslösung für Handelsvertretungen und ihrer Hersteller insbesondere unter Berücksichtigung strategischer, betriebswirtschaftlicher, fachlicher und technischer Aspekte unterstützt. Hier ist es notwendig, ein geeignetes, übergreifendes Framework vorzugeben (siehe Abschnitt 3.3). 4. Fehlende Vorgehensweise zur ganzheitlichen Entwicklung einer webbasierten Informationsplattform: Darüber hinaus fehlt eine geeignete methodische Vorgehensweise, die insbesondere die strategischen und marktorientierten Aspekte bei der Umsetzung einer entsprechenden elektronischen Vertriebsunterstützung durchgängig bis zur Umsetzung unterstützt (siehe Abschnitt 3.4). - 54 - 5. Unzureichende Geschäftsmodellansätze: Als Grundlage für die Entwicklung insbesondere der strategischen Aspekte zur zielgruppenspezifischen Ausrichtung der Informationsplattform im Rahmen eines Geschäftsmodells bietet sich der Ansatz von Osterwalder an. Allerdings muss dieser Ansatz auf die Anforderungen von Handelsvertreter und -vermittler sowie IT-Anbieter (siehe Kapitel 5) angepasst werden (siehe Abschnitt 3.5). Auf Basis dieser Erkenntnisse wurde im nachfolgenden Kapitel 4 die Zielsetzung dieser Arbeit abgeleitet. 4 Zielsetzung der Arbeit Ziel der Arbeit ist es ein Referenzmodell zu entwickeln, das IT-Anbietern und Softwareentwicklern bei der Entwicklung einer geeigneten IT-Lösung für Handels- vertreter, -vermittler und ihrer Hersteller unterstützt. Der Lösungsansatz hierfür ist die Einführung einer webbasierte Informationsplattform, die als Software as a Service angeboten wird (siehe Abbildung 11) und im Vergleich zur Ausgangssituation (siehe Abbildung 3) Vertriebsinformationen zwischen den genannten Parteien zeitnah zur Verfügung stellt und Funktionen zur mobilen, multilieferantenfähigen Informations- verwaltung bietet. Abbildung 11: Fachliche Systemsicht der Informationsplattform (FMC Notation) Der hauptsächliche Nutzen dieser Plattform liegt in: ± Der multilieferantenfähigen Unterstützung der Vertriebsprozesse von Handels- vertretern, -vermittlern und Herstellern. ± Der Steigerung der Verfügbarkeit von Vertriebsinformationen durch eine zentrale, mobile Bereitstellung von Vertriebsinformationen über die Informationsplattform. ± Der Reduzierung von Administrationsaufwand seitens der angebundenen Handelsvertreter und -vermittler und dessen Verlagerung auf einen IT-Anbieter, der die Informationsplattform anbietet. ± Der Steigerung der Aktualität der Vertriebsinformationen durch die Nutzung standardisierter Schnittstellen zum Austausch von Vertriebsinformationen Software as a Service-Anbieter Mobile Multilieferanten- Vertriebsplattform Externe Vertriebsorganisationen Hersteller Kunden Entwickler Einkäufer Externe Vertriebsorganisationen Handelsvertreter/ Handelsvermittler/ Händler Vertriebsinnendienst Support Vertriebs- mitarbeiter Produkt- manager Notebook E-Mail Client Office- Anwen- dung Web- Browser Stationärer Rechner E-Mail Client Office- Anwen- dung Web- Browser Buch- haltung ERP- System CRM- System PIM- System Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung Stationäre Rechner E-Mail Client Office- Anwen- dung Kontakt-/ Terminver waltung PDA/Smartphone E-Mail Client Kontakt-/Terminver waltung Administrator Call-Agent(Support/Helpdesk) Web- Browser Integrations- komponente Aufgaben- verwaltung Auftrags- verwaltung Integrations- komponente Integrations- komponente Integrations- komponente Produkt- daten Provisions- verwaltung ... - 56 - zwischen Handelsvertretungen, -vermittlungen und Herstellern. Die System- anbindung erfolgt durch den IT-Anbieter oder einen Kooperationspartner. Das Referenzmodell berücksichtigt schon in frühen Phasen des Entwicklungs- prozesses eine zielgruppenspezifische Ausrichtung der Informationsplattform im Sinne von Mass Customization durch die Erstellung eines Geschäftsmodells und damit die Festlegung der Zielgruppen, Dienstleistungsangebote, Dienstleistungs- erstellungsprozess inklusive der Integration relevanter Kooperationspartner sowie die finanziellen Aspekte. Des Weiteren wird die Integration und Überführung dieser Ergebnisse in nachfolgende Planungs- und Umsetzungsphasen der Dienstleistungs- erstellung aufgezeigt. Die nachfolgenden Kapitel enthalten daher: ± Die Entwicklung eines Metamodells als übergeordnete Struktur des Referenz- modells, das ein ganzheitliches Vorgehen bei der Konzeption und Umsetzung der Informationsplattform für Handelsvertreter, -vermittler und Hersteller auf Basis von Software as a Service unterstützt. Dieses Metamodell berücksichtigt u.a. unterschiedliche Abstraktionsebenen (Sichten) von Beteiligten bei der Entwicklung der Informationsplattform und basiert auf dem Zachman Framework (Zachman 1987) und der Integrated Service Engineering (ISE) Methodik (Einführung siehe Kapitel 6). ± Ein besonderer Fokus liegt dabei auf der Erstellung eines detaillierten Referenz- modells für die Geschäftsmodellentwicklung zur Strukturierung von bislang un- bzw. semistrukturierten Informationen der strategischen Planung und zur zielgruppenspezifischen Ausrichtung der Informationsplattform. ± Entwicklung einer Methodik zur Nutzung des Referenzmodells mit Fokus auf die Geschäftsmodellentwicklung in Form eines Phasenmodells. ± Betrachtung einer IT-technischen Umsetzung des Referenzmodells unter Anwendung des modelbasierten Ansatzes basierend auf dem Eclipse Modeling Framework EMF (Steinberg et al. 2009) und der Entwicklung einer Domain- Specific Language DSL (Gronback 2009). In diesem Kontext wird die webbasierte Informationsplattform als Electronic Business Anwendung betrachtet. Dabei wird Electronic Business als der Oberbegriff für unternehmensübergreifende Geschäftsprozesse in Wirtschaft und öffentlicher Verwaltung definiert, die vollständig oder teilweise auf Basis von netzbasierten Informationstechnologien abgewickelt werden (Wirtz 2000). In diesem Zusammenhang ist es das erklärte Ziel des Electronic Business, sämtliche Geschäftsaktivitäten möglichst medienbruchfrei und automatisiert durchzuführen, soweit dies aus technologischer Sicht möglich ist (Barros und Dumas 2006). Dies wird als untergeordnetes Ziel aufgenommen und in der Arbeit berücksichtigt. 5 Anforderungen an das Referenzmodell Um Anforderungen an die webbasierte Informationsplattform ableiten zu können, wurde eine Untersuchung bei potenziellen Anwendern der Plattform durchgeführt. Die Untersuchung hatte zum Ziel die Ausgangssituation bei Handelsvermittlungen, -vertretungen und Händlern sowie bei deren Herstellern festzustellen, um auf Basis dieser Ergebnisse die Schwachstellen in den Prozessen und der IT-Unterstützung vor allem auf Seiten der Handelsvermittlungen und -vertretungen zu identifizieren. Nach Analyse der in Abschnitt 3.1 aufgeführten Ausgangssituation inklusive deren Schwachstellen und Optimierungspotenziale wurden die folgenden funktionalen (FA) und nicht-funktionalen (NA) Anforderungen an das Referenzmodell einer web- basierten Informationsplattform für Handelsvertreter und Hersteller aufgestellt. Dazu wurden 38 Anwendungsfälle bei Handelsvertretern und -vermittlern sowie 24 Anwendungsfälle bei deren Herstellern (gemäß UML, OMG 2010b) für die Informationsplattform identifiziert, konzipiert und beschrieben (siehe Anhänge B und C). Basierend auf diesen Anwendungsfällen wurden funktionale Anforderungen an die Informationsplattform abgeleitet. Funktionale Anforderungen beschreiben laut Rupp (2007) Aktionen, die von einem System selbstständig ausgeführt werden sollen, Interaktionen des Systems mit menschlichen Nutzern oder Systemen (Eingaben und Ausgaben) und Anforderungen zu allgemeinen, funktionalen Vereinbarungen und Einschränkungen, während nicht- funktionale Anforderungen die Bereiche Technik, Benutzungsschnittstelle, Qualität, sonstige Lieferbestandteile, Durchführung der Entwicklung und Einführung sowie rechtlich-vertragliche Kriterien betreffen. In Tabelle 11 sind die Anforderungen an das Referenzmodell der Informationsplattform aus Sicht der Zielgruppen Handels- vertreter, Hersteller und IT-Anbieter aufgeführt. - 58 - Anforderung Art der Anfor- derung R el ev an z H an de ls ve rtr . R el ev an z H er st el le r R el ev an z IT -A nb ie te r FA1: Die Plattform muss die Kooperationsanbahnung zwischen Handelsvertretungen und Herstellern bzw. zwischen Herstellern und Handelsvertretungen unter- stützen. Funktional ƔƔ ƔƔ Ɣ FA2: Die Plattform soll die Möglichkeit besitzen Gesprächs- vorbereitungen von Handelsvertretungen mit ihren Kunden durchzuführen. Funktional ƔƔ ż Ɣ FA3: Die Plattform muss Handelsvertretungen aktuelle Produktinformationen für die Produktpräsentation und - beratung bereitstellen. Funktional ƔƔ Ɣ Ɣ FA4: Die Plattform muss die Erstellung von Angebotsanfragen und Bestellungen von Standardprodukten durch Handelsvertretungen ermöglichen. Funktional ƔƔ Ɣ Ɣ FA5: Die Plattform kann Konfiguratoren für die Auswahl und die Zusammenstellung von komplexen Produkten anbieten. Funktional ƔƔ Ɣ Ɣ FA6: Die Plattform kann virtuelle Projekträume bereitstellen, anhand derer Individualprodukte gemeinsam mit Kunden entwickelt werden. Funktional ƔƔ ż Ɣ FA7: Die Plattform muss die Bearbeitung von Kunden- anfragen durch die Handelsvertretungen und Herstellern unterstützen. Funktional ƔƔ ƔƔ Ɣ FA8: Die Plattform muss die Auftragsabwicklung zwischen Handelsvertretungen und Herstellern ermöglichen. Dies betrifft die Prozesse der Entgegennahme/ Weiterleitung von Angebotsanfragen, Erstellung von Angeboten, Entgegennahme/ Weiterleitung von Bestellungen bzw. Bestelländerungen, Erstellung von Rechnungen und Aufnahme/Weiterleitung von Reklamationen. Funktional ƔƔ ƔƔ Ɣ FA9: Die Plattform muss die Abfrage von aktuellen Status von Geschäftsvorgängen durch die Handelsvertretungen unterstützen. Funktional ƔƔ Ɣ Ɣ FA10: Die Plattform muss den aktuellen Stand der Provisionen der Handelsvertretung ermöglichen. Funktional ƔƔ Ɣ Ɣ FA11: Die Plattform muss Querschnittsaufgaben, wie die Verwaltung von Kontakten, Terminen und Aufgaben unterstützen. Funktional ƔƔ ż Ɣ FA12: Die Plattform soll die Administration relevanter Inhalte, wie Produktinformationen und Vertriebsinformationen über Geschäftsvorgänge, durch die Handelsvertretung sowie deren Hersteller bereitstellen. Funktional ƔƔ ƔƔ Ɣ - 59 - Anforderung Art der Anfor- derung R el ev an z H an de ls ve rtr . R el ev an z H er st el le r R el ev an z IT -A nb ie te r FA13: Die Plattform soll die manuelle Eingabe von Informationen durch eine Benutzungsschnittstelle unterstützen, sollten keine geeigneten Schnittstellen für eine Handelsvertretung bzw. deren Herstellern angeboten werden können. Funktional ƔƔ ƔƔ Ɣ NA1: Die Plattform muss die Integration von externen Systemen zur Bereitstellung von relevanten Vertriebs- informationen, wie das Einstellen und den Abgleich von Produktinformationen und Informationen über Geschäftsvorgänge, durch geeignete Schnittstellen unterstützen. Technisch ƔƔ ƔƔ Ɣ NA2: Die Plattform muss ausgewählte Vertriebsinformationen auch auf verschiedenen mobilen Geräten zur Verfügung stellen und eine hybride Arbeitsweise mit mobilen sowie stationären Anteilen ermöglichen. Schnitt- stelle ƔƔ ż Ɣ NA3: Die Plattform muss die Anpassung der oben genannten Funktionen an die jeweilige Situation der Handels- vertretungen und Herstellern ermöglichen. Qualität ƔƔ ƔƔ Ɣ NA4: Die Plattform muss den Handelsvertretungen zu jederzeit die benötigten Vertriebsinformationen zur Verfügung stellen. Qualität ƔƔ Ɣ Ɣ NA5: Die Dienstleistungen der Plattform müssen zu einem aus Sicht der Handelsvertretungen und Herstellern wirtschaftlichen Preismodell angeboten werden. Rechtlich- vertraglich ƔƔ ƔƔ ƔƔ NA6: Das Referenzmodell muss strategische Aspekte bzgl. Zielkunden, Dienstleistungsangebot, Dienstleistungs- erbingung, Partner und Rentabilität eines Konsortiums zur Entwicklung eines Geschäftsmodells berück- sichtigen. Ent- wicklung ż ż ƔƔ NA7: Die Modellierung der strategischen Aspekte in Form eines Geschäftsmodells soll technisch durch einen Editor unterstützt werden. Ent- wicklung ż ż ƔƔ NA8: Integration des Geschäftsmodells in ein ganzheitliches methodisches Vorgehen. Ent- wicklung ż ż ƔƔ ƔƔ  GLH $QIRUGHUXQJ ZHLVW HLQH KRKH 5HOHYDQ] IU Gie betreffende Zielgruppe DXIƔ = die Anforderung ist bedingt relevant für die betreffende Zielgruppe ż  GLH $QIRUGHUXQJ WULIIW IU Gie betreffende Zielgruppe nicht zu. Tabelle 11: Anforderungen an das Referenzmodell 6 Integrated Service Engineering Methodik (ISE) In diesem Kapitel wird der Aufbau des Referenzmodells beschrieben, das auf den Erkenntnissen von Zachman (1987) aufbaut. Zachman (1987) stellt fest, dass bei der Entwicklung von Städten und Gebäuden aufgrund der Aufgabenkomplexität verschiedene Personen mit unterschiedlichem Hintergrund und Rollen im Entwicklungsprozess, wie z.B. Eigentümer, Bauträger, Architekt und Bauingenieur, involviert sind. Diese Personen bringen jeweils spezifisches Fachwissen in die Entwicklung ein, was sich in der Verwendung unterschiedlicher Methoden, Modellen und Werkzeugen im Entwicklungsprozess bemerkbar macht. Diese Erkenntnis überträgt er auf andere Disziplinen, u.a. auf IT-Unternehmensarchitekturen, deren Komplexität aufgrund des steigenden Integrationsgrads von IT-Systemen sowie steigender Anforderungen an deren Flexibilität zunimmt. Für die Entwicklung von komplexen IT-Unternehmensarchitekturen wurde das Zachman Framework erstellt, bei dem die Erkenntnisse der unterschiedlichen Sichten auf die Entwicklung von IT-Unternehmensarchitekturen angewendet werden und bei dem den verschiedenen Sichten entsprechende Artefakte zugeordnet werden. Die Sichten legen zum einen den Abstraktionsgrad der eingebrachten Informationen fest, zum anderen beeinflussen sie aber auch die verwendeten Modelle zur Darstellung und Strukturierung dieser Informationen (siehe Abbildung 12). So werden für die fachliche Modellierung von Geschäftsprozessen von einem Business Analysten Modellierungssprachen, wie z.B. ereignisgesteuerte Prozess- ketten (EPK) (Scheer 1998) verwendet, während ein Service Architekt die Prozessunterstützung aus IT-Sicht betrachtet und Anwendungsfalldiagramme in UML modelliert (Bose et al. 2005). Um die Transparenz weiter zu steigern, werden im Zachman Framework die einzelnen Sichten in Dimensionen eingeteilt. Dimensionen sind Teilbereiche einer Sicht, die einheitlich alle Sichten betreffen. Zu jeder Sicht und Dimension wird mindestens ein Modell zugeordnet, mit dem ein Teil des gesamten Referenzmodells dargestellt wird. In den nachfolgenden Abschnitten werden die Sichten und die dazugehörenden Rollen, die Dimensionen und Modelle des Zachman Framework ausgetauscht und auf die vorliegende Aufgabenstellung der Arbeit angepasst. Daraus entwickelte sich die Integrated Service Engineering Methodik ISE für die Entwicklung einer Informationsplattform für Handelsvertreter, -vermittler und Hersteller (siehe auch Kett et al. 2008). - 61 - Abbildung 12: Grundlagen der Integrated Service Engineering Methodik 6.1 Sichten und Rollen der Integrated Service Engineering Methodik Bei Untersuchung der relevanten Rollen im Entwicklungsprozess dienstbasierter Anwendungen existieren vor allem die Arbeiten von Zimmermann et al. (2004) und Bose et al. (2005), die auf die verschiedenen Rollen der am Entwicklungsprozess Beteiligten eingehen. Die Arbeiten basieren auf dem Ansatz von Zachman und der Berücksichtigung getrennter, relevanter Sichten im Entwicklungsprozess. Hierbei unterscheiden sie zwischen Rollen der traditionellen Software- und der SOA- Entwicklung. Die in diesem Zusammenhang aufgeführten Rollen und die dazugehörenden Sichten werden einzelnen Phasen des Entwicklungsprozesses zugeordnet. Jede Sicht detailliert und ergänzt die zuvor erarbeiteten Ergebnisse. In Tabelle 12 werden die unterschiedlichen Sichten und deren Kernergebnisse den Rollenkonzepten von Zachman (1987), Zimmermann et al. (2004), Bose et al. (2005) und der vorliegenden Arbeit zugeordnet. Dabei wird ersichtlich, dass Zimmermann et Sicht Modell Dimension Information Rolle HintergrundHintergrund Rollen Informationen Modelle Sichten Dimensionen Referenzmodell beeinflussen liefern werden unter- gliedert in besitzen spezifische sind Grundlage für beeinflussen untergliedern geben Teilbe- reiche vor für untergliedern bilden legen Abstraktions- grad fest für = Entität = Beziehung - 62 - al. (2004) und Bose et al. (2005) die Sichten nicht so weit detaillieren wie Zachman (1987), dafür jedoch die Sichten des Testens sowie der Bereitstellung der Dienste berücksichtigen. Rollen Zachman Framework SOA Projektplanung Integrated Service Engineering ISE Sichten Zachman 1987 Zimmermann et al. 2004; Bose et al. 2005 Service Innovation - - (Innovationsmanager) Service Strategie - - Stratege Ziel/Rahmen (Contextual) Planner Business Analyst Business Analyst Unternehmen (Conceptual) Owner System (Logical) Designer SOA Architect Service Architekt Technologie (Physical) Builder Service Developer Service Entwickler (Detaillierte) Umsetzung Programmer Test - Tester Bereitstellung - Service Deployer (Administrator) Nutzung User  (Rolle) = Rollen, die in der Integrated Service Engineering Methodik zur Entwick lung einer webbasierten Informationsplattform für Handelsvertreter, -vermittler und Hersteller den Rahmen bilden, aber nicht weitergehend bearbeitet werden.  Grau hinterlegte Rollen sind zentrale Rollen des Entwick lungsprozesses der Informationsplattform Tabelle 12: Vergleich von Sichten und dazugehörende Rollen Die vorliegende Arbeit setzt bei den zentralen Sichten und Rollen von Zimmermann et al. (2004) an, die speziell auf die Entwicklung von Diensten ausgelegt wurden. Um die zielgruppenspezifische Ausrichtung der Informationsplattform für Handels- vertreter und -vermittler stärker in der Entwicklung zu berücksichtigen, wurde die Rolle und Sicht des Strategen ergänzt, der das Service Konzept der Informations- plattform erstellt. In die Erstellung des Service Konzepts kann auch ein Konsortium von mehreren Partnern involviert sein. Diese Sicht wird im Rahmen des Referenz- modells benötigt, um vor allem die funktionalen Anforderungen der angebotenen - 63 - Dienstleistungen der Vertriebsplattform mit den betriebswirtschaftlichen Aspekten der Beteiligten, Handelsvertretungen, deren Herstellern sowie Softwareanbietern ableiten zu können. Abbildung 13 verdeutlicht insbesondere die Sicht des Strategen und dessen Zusammenspiel mit den Zielmärkten und deren Marktteilnehmern, wobei Zielgruppen in diesem Fall Handelsvertretungen bzw. Hersteller sind. Auf vorhergehende und nachfolgende Rollen wird in ISE nicht detailliert eingegangen. So existieren die Rollen des Innovationsmanagers, der neue Ideen für Dienste sucht und die geeignetsten Ideen zur weiteren Bearbeitung herausfiltert (Finzen et al. 2010) und die Rolle des Administrators, der den webbasierten Dienst bereitstellt und administriert. Die Sicht des Strategen gewinnt an Bedeutung, da dieser den strategischen Rahmen der nachfolgenden Dienstleistungsentwicklung vorgibt und damit beeinflusst. Dieser strategische Rahmen in Form des Service Konzepts berücksichtigt und modelliert u.a. die folgenden Aspekte: ± Zielgruppen und deren Eigenschaften, wie Handelsvertreter und der von ihnen vertretenen Hersteller, ± Dienstleistungsangebot, das den Zielkunden angeboten werden soll (im vorliegenden Fall ist es die webbasierte Informationsplattform), ± Vertriebskanäle und Kundenbeziehungen, zur Ansprache und Kommunikation mit den Zielkunden, ± Dienstleistungserbringung und damit die Prozess(-phasen), die hierfür notwendig sind, ± Kompetenzen und Ressourcen, die bei der Bereitstellung und Abwicklung der Dienstleistung benötigt werden, ± Kooperationspartner, die die Ressourcen und Kompetenzen bereitstellen, ± finanzielle Aspekte, mit dem Fokus auf der Berechnung der Rentabilität der Investitionen in eine webbasierte Informationsplattform für alle beteiligten Partner eines Konsortiums. - 64 - Abbildung 13: Rollen im Kontext der Integrated Service Engineering Methodik (Kett 2010) Diese Aspekte der geschäftlich-strategischen Betrachtungsweise des Referenz- modells werden in Form des Service Konzepts weitergegeben an die nachfolgende Sicht des Business Analysten. An dieser Stelle beginnt die fachlich-technische Betrachtungsweise, die vor allem darauf fokussiert, die fachlichen Anforderungen aufzunehmen und ein mit fachlichen Aspekten erweitertes Service Konzept zu erstellen, um im weiteren Verlauf des Entwicklungsprozesses ein technisches SOA Konzept abzuleiten und umzusetzen (Kett et al. 2008). Insbesondere Zimmermann et al. (2004) und Bose et al. (2005) erwähnen weitere untergeordnete Rollen, die jedoch den in Abbildung 13 aufgeführten Kernrollen Mitarbeiter aus Fachabteilungen Partner Zielmarkt Wettbewerber Zielgruppe B Potenzielle Wettbewerber Partner Stratege Business Analyst Service Architekt Service Entwickler Administrator Mitarbeiter aus Fachabteilungen Zielgruppe A Kunde A1 Kunde A2 Kunde Am ... Kunde B1 Kunde B2 Kunde Bn ... ... st el le n A nf or - de ru ng en an st el le n A nf or - de ru ng en an be ob ac ht et / ko m m un iz ie rt be ob ac ht et / ko m m un iz ie rt beobachtet Wettbewerber Direkte ettbewerber analysiert WettbewerberAbsatzmittler ko op er ie re n RückmeldungerweitertesService Konzept RückmeldungSOAKonzept RückmeldungrealisierteSOA kooperieren kooperieren kooperieren liefern fachliche Informationen liefern fachliche Informationen und neue Service Ideen RückmeldungstrategischesService Konzept fa ch lic h- te ch ni sc he B et ra ch tu ng sw ei se ge sc hä ftl ic h- st ra te gi sc he B et ra ch tu ng sw ei se = Rollen = Beziehung = Zielmarkt - 65 - zuarbeiten und somit im weiteren Verlauf der Arbeit nicht gesondert berücksichtigt werden. 6.2 Dimensionen des Referenzmodells Jede der fünf genannten Rollen (Stratege, Business Analyst, Service Architekt, Service Entwickler und Administrator) haben ihre eigene Sicht auf den zu entwickelnden Dienst bzw. Dienstleistung. Aufgrund ihrer Komplexität werden die Sichten in mehrere Dimensionen eingeteilt. Dimensionen sind dabei Teilbereiche des zu entwickelnden Gegenstandes, die eigenständig konzipiert und modelliert werden können (Zachman 1987). Da Zachman von der Erstellung einer Unternehmens- architektur ausgeht, die vorliegende Arbeit allerdings ein Referenzmodell für eine webbasierte Informationsplattform für Handelsvertreter, -vermittler und der von ihnen vertretenen Hersteller zum Fokus hat, wurden die einzelnen Dimensionen des Zachman Frameworks hinterfragt und je nach Eignungsgrad übernommen oder angepasst. Tabelle 13 zeigt die sechs Dimensionen des Zachman Frameworks und die daraus abgeleiteten fünf Dimensionen des Referenzmodells. Beim Referenzmodell der Informationsplattform werden die folgenden Dimensionen zur Unterteilung der oben aufgeführten fünf Sichten herangezogen: ± Dienst/Dienstleistung: Von der geschäftlich-strategischen Sicht bis hin zur technischen Umsetzung werden die Dienstleistungen und die zugrundeliegenden technischen Dienste modelliert. ± Prozess: Als Hilfestellung für die Konzeption des Services und dessen funktionaler Unterstützung durch die webbasierte Informationsplattform dient die Modellierung der Prozesse inklusive der fachlichen, aber auch technischen Aspekte. ± Beteiligte: Diese Dimension setzt den Fokus auf die in die Nutzung der Informationsplattform involvierten Nutzer und sonstigen Beteiligten (wie z.B. Kooperationspartner) bis hin zur Modellierung deren Benutzungsoberflächen. ± IT/Daten: Als Grundlage für den Informationsaustausch und dessen Verwaltung muss eine geeignete IT-Infrastruktur aufgebaut werden, die die benötigten Daten verwaltet. ± Finanzielle Aspekte: Um die Dienstleistung der Informationsplattform für alle Beteiligten anbieten und die benötigte Akzeptanz aufbauen zu können, müssen auch die finanziellen Aspekte, wie Kosten und Umsätze im Rahmen des Referenzmodells berücksichtigt werden. - 66 - Dimensionen Beschreibung Zachman Framework Referenzmodell WAS wird erstellt? - Dienst/Dienstleistung WIE wird erstellt? Function Prozess WO findet der Erstellungsprozess statt? Location - WER ist in die Erstellung involviert? People Beteiligte AUF WAS baut die Erstellung auf? Material IT/Daten WANN finden einzelne Aktivitäten des Erstellungsprozesses statt? Time - WARUM werden Entscheidungen getroffen? Focus - WIEVIEL Ausgaben und Einnahmen werden damit realisiert? - Finanzielle Aspekte Tabelle 13: Dimensionen des Referenzmodells 6.3 Teilmodelle und die Gesamtsicht Mit der Kombination der fünf Sichten und Dimensionen ergibt sich eine Matrix, die in Tabelle 14 dargestellt ist. In dieser Tabelle sind die fünf grundlegenden Rollen im Entwicklungsprozess von Dienstleistungen mit ihren unterschiedlichen Sichten, die Art der Sichten sowie das hauptsächliche Ergebnis der Sichten aufgeführt. Darüber hinaus werden in den weiterführenden Spalten Modelle vorgeschlagen, die die Modellierung sowie die Darstellung der Ergebnisse je Sicht und Dimension unterstützen. Die Auswahl der Modelle erfolgte auf Basis der Integrated Service Engineering Methodik (Kett et al. 2008). Ein zentraler Bestandteil dieser Arbeit ist die zielgruppenspezifische Ausrichtung der webbasierten Informationsplattform im Sinne von Mass Customization anhand eines Modells, um IT-Anbietern bei der Entwicklung eines tragfähigen Geschäftsmodells für die webbasierte Informationsplattform für Handelsvertreter, -vermittler und Hersteller zu entwickeln. Dieses Modell bildet die Grundlage für die nachfolgenden fachlichen und technischen Sichten auf die webbasierte Informationsplattform, die überwiegend mit etablierten Methoden und Modellen des Software- bzw. Service-Engineering bearbeitet wird. Auf - 67 - diese Methoden und Modelle wird im Rahmen der Arbeit der Vollständigkeit halber kurz eingegangen. In Tabelle 14 sind daher die Sichten, Dimensionen und einige beispielhafte Modelle in der Gesamtsicht aufgeführt. Dimensionen Sicht Dienstleistung/ Dienst Prozesse IT/Daten Beteiligte finanzielle Aspekte G es ch äf tli ch - st ra te gi sc h Rolle: Stratege, Ergebnis: Geschäftsmodell Geschäftsmodell (siehe Kapitel 7) Fa ch lic h- ko nz ep tio ne ll Rolle: Business Analyst, Ergebnis: Erweitertes Geschäftsmodell Funktions- baum (Balzert 2000; Wendt 1991) Funktions- umschrei- bung (Wendt 1991) Funktionale Anforde- rungen (Rupp 2009; Pohl und Rupp 2009) Prozess- modelle (z.B. EPK, BPMN) (Scheer 2006; Schneider und Scheer 2003; OMG 2009; OMG 2010a) fachliches System- diagramm (z.B. FMC Block- diagramme) (Keller und Wendt 2003; Gröne und Keller 2004) Anwendungs- falldiagramm (z.B. UML) (OMG 2010b) Service Blueprint (Shostack 1982, 1984) Organi- gramme (Scheer 2006) Kosten-/ Nutzen- betrachtung Prozess- kosten- rechnung Investitions- rechnung (Röthig 2009; Westkämper 2006; Brugger 2005; Gadatsch und Mayer 2005; Hirschmeier 2004; Schäfer 1999) - 68 - Dimensionen Sicht Dienstleistung/ Dienst Prozesse IT/Daten Beteiligte finanzielle Aspekte S er vi ce - ko nz ep tio ne ll Rolle: Service Architekt, Ergebnis: SOA Konzept Service- Oriented Modeling Framework SOMF (Bell 2010, 2008; Marks und Bell 2006) Service- Oriented Modeling and Architecture SOMA (Zimmermann et al. 2005; Endrei et al. 2004) Service- Oriented Analysis and Design SOAD (Zimmermann 2009; Zimmermann et al. 2005; Zimmermann et al. 2004) Unified Service Description Language (USDL) (SAP Research 2009d; SAP Research 2009e; SAP Research 2009c; SAP Research 2009b; SAP Research 2009a) erweiterte Prozess- modelle (Specht et al. 2006) Sequenz- diagramme (OMG 2010b) Business Process Execution Language BPEL (OASIS 2007) technisches Datenmodell (z.B. ER) (Chen 1976; Broy und Denert 2002) Datenfluss- diagramm (Balzert 2000) Kontext- diagramme (Balzert 2000) Benutzer- modelle (Joung et al. 2009; Shahzad et al. 2009; Yang et al. 2009; Mertens et al. 2004) Weitere Detaillierung der Informa- tionen der oben aufgeführten Modelle - 69 - Dimensionen Sicht Dienstleistung/ Dienst Prozesse IT/Daten Beteiligte finanzielle Aspekte S er vi ce - um se tz un gs or ie nt ie rt Rolle: Service Entwickler, Ergebnis: Service Realisierung Service Program- mierung (z.B. Java) (Gosling 2005) Service Beschrei- bung (z.B. WSDL, USDL) (W3C 2007b; SAP Research 2009d; SAP Research 2009e; SAP Research 2009c; SAP Research 2009b; SAP Research 2009a) Service Protokoll (SOAP) (W3C 2007a) Koordination und Trans- aktionen (z.B. WS- Coordination, WS-Atomic- Transaction, WS- Business- Activity, WS- CDL, WS-CI) (OASIS 2009; W3C 2009b; W3C 2009c; W3C 2005; W3C 2002) Datenbe- schreibungen (z.B. OWL, XML-Schema) (W3C 2009a; W3C 2004a; W3C 2004b; W3C 2004c; W3C 2010) Simple Unified Natural Markup Language (SunML) (Picard et al. 2003) TERESA XML, MARIA XML (Paternò et al. 2008b; Paternò et al. 2008a; Paternò und Santoro 2003) User Interface Markup Language (UIML) (Abrams et al. 1999) USer Interface eXtensible Markup Language (UsiXML) (Vanderdonckt 2005) Web Service eXperience Language (WSXL) (IBM 2002) eXtensible Interface Markup Language (XIML) (Eisenstein et al. 2000; Lester 2001) Weitere Detaillierung der Informa- tionen der oben aufgeführten Modelle - 70 - Dimensionen Sicht Dienstleistung/ Dienst Prozesse IT/Daten Beteiligte finanzielle Aspekte B et rie bs - or ie nt ie rt Rolle: Administrator, Ergebnis: Einführung und Nutzung Betriebsmodell Tabelle 14: Prinzipieller Aufbau des Referenzmodells 7 Referenzmodell einer webbasierten Informationsplattform Mit dem Referenzmodell wird die geschäftlich-strategische Sicht des Strategen (siehe Tabelle 14) und damit die zielgruppenspezifische Ausrichtung einer webbasierten Informationsplattform für Handelsvertreter, -vermittler und Hersteller in Form eines Geschäftsmodells entwickelt. Dimension Schlüsselfragen der geschäftlich-strategischen Sicht Dienst- leistung  Welcher Nutzen wird den Zielkunden angeboten? (Nutzen)  Welche Dienstleistungen werden Zielkunden angeboten? (Dienstleistung)  Wie unterscheidet sich der Nutzen der Dienstleistung von dem der Konkurrenten? (Dienstleistung)  Zu welchem Preisniveau wird die Dienstleistung angeboten? (Dienstleistung)  Welche Vertriebskanäle werden für die Kundenansprache genutzt? (Distributionskanal)  Welchen Nutzen bieten die einzelnen Vertriebskanäle den Zielkunden? (Distributionskanal)  Welchen Nutzen bieten die einzelnen Vertriebskanäle den Zielkunden im Vergleich zur Konkurrenz? (Distributionskanal)  Welche Kundenbeziehung wird angestrebt? (Kundenbeziehung)  Welchen Nutzen hat der Kunde von der jeweiligen Kundenbeziehung? (Kundenbeziehung)  Welchen Nutzen hat der Kunde von der jeweiligen Kundenbeziehung im Vergleich zur Konkurrenz? (Kundenbeziehung) Prozess  Welche Prozesse werden für die Bereitstellung und Erbringung der Dienstleistung benötigt? (Prozess) Beteiligte  Welche Zielgruppen werden angesprochen? (Zielgruppe)  Welche Eigenschaften haben diese Zielgruppen? (Zielgruppe)  Welche Kooperationspartner werden benötigt, um die Dienstleistungsprozesse auszuführen? (Partner)  Welche Gründe sprechen für eine Kooperation? (Partner)  Welche Kompetenzen und Ressourcen bringen die Partner ein? (Partner)  Wie wird die strategische Bedeutung der Kooperation eingeschätzt? (Partner)  Wie hoch ist die Wahrscheinlichkeit, dass aus Kooperationspartnern Konkurrenten werden? (Partner)  Wie eng ist die Integration der Kooperationspartner in die eigene IT- Landschaft? (Partner)  Wie leicht kann ein Kooperationspartner ausgetauscht werden? (Partner) - 72 - Dimension Schlüsselfragen der geschäftlich-strategischen Sicht IT/Daten  Welche Kompetenzen bzw. Ressourcen werden zur Durchführung der Dienstleistungsprozesse benötigt? (Kompetenz/Ressource) Finanzielle Aspekte  Welche (geschätzten) Kosten treten für die Bereitstellung von Kompetenzen und Ressourcen zur Dienstleistungserbringung auf? (Kosten)  Wie hoch werden die zukünftigen Erlöse einer Dienstleistung geschätzt? (Erlös)  Mit welchen Preismodellen werden die Dienstleistungen angeboten? (Erlös)  Wie erfolgt die Erlösverteilung je Kooperationspartner? (Erlös)  Wie hoch ist der Gewinn, der mit einer Dienstleistung erzielt werden kann? (Gewinn)  Wie hoch ist der Return-On-Investment? (Gewinn) Tabelle 15: Schlüsselfragen für die geschäftlich-strategische Sicht Bei der Untersuchung vorhandener Geschäftsmodellansätze (siehe Abschnitt 3.5) wurden u.a. die dort berücksichtigten Geschäftsmodellelemente betrachtet, die für diese Sicht relevant sind. Mit drei Experten aus den Bereichen Geschäftsführung, Produktmanagement und Forschung wurden relevante Fragestellungen identifiziert, die im Zusammenhang mit der Entwicklung von Geschäftsmodellen für ein Konsortium von Projektpartnern zur Erstellung eines Dienstleistungsangebots im Internet stehen. Die Fragestellungen sind in Tabelle 15 in der Spalte der geschäftlich-strategischen Sicht aufgeführt. Die fünf hauptsächlichen Frage- stellungen, die es in der geschäftlich-strategischen Sicht zu beantworten gilt, sind: ± Welche Zielgruppen werden adressiert? ± Welche Dienste und Dienstleistungen werden ihnen angeboten? ± Wie werden die Dienste und Dienstleistungen erbracht? ± Welcher Partner ist in den Erbringungsprozess involviert? ± Wie sieht das Kosten-/Nutzenverhältnis bei jedem Partner aus? Diese Fragestellungen wurden den Geschäftsmodellelementen aus der Literatur zugeordnet und auf diese Art und Weise die relevanten Elemente für das in dieser Arbeit entwickelte Referenzmodell herausgefiltert. Die Elemente sind in Tabelle 15 jeweils in Klammern hinter den Fragestellungen aufgeführt. Zur Beantwortung der identifizierten Fragen eignen sich die Dienstleistungskonzepte aus dem Service Engineering (siehe 3.4 Methoden zur Entwicklung elektronischer Dienstleistungen und Dienste) aber auch Ansätze aus der Geschäftsmodell- entwicklung. So entwickelte Bullinger et al. (2003) im Rahmen des Service Engineering ein grundlegendes Service Modell in UML, und Osterwalder (2004) eine - 73 - Geschäftsmodell Ontologie. Beide Ansätze bieten den Vorteil, dass sie modellbasiert aufgebaut sind und damit im Vergleich zu anderen Ansätzen auf die Modellierung von Geschäftsmodellen fokussieren (Osterwalder et al. 2005). Osterwalder (2004) untersucht mehr als 20 Geschäftsmodellansätze und deren Elemente zur Beschreibung und Festlegung von Geschäftsmodellen. Dabei identifiziert Osterwalder 20 Elemente, die er in seiner Ontologie integriert. Im Rahmen der Arbeiten zur Entwicklung der geschäftlich-strategischen Sicht mit den beteiligten IT-Anbietern wurden die Geschäftsmodellelemente von Osterwalder mit den erarbeiteten Fragestellungen abgeglichen. OsteUZDOGHU¶V *eschäftsmodell Ontologie stellte sich dabei als komplex, unübersichtlich bzw. einige Elemente und deren Merkmale als nicht relevant heraus. Daher wurden die Geschäftsmodellelemente von Osterwalder und deren Zusammensetzung in dieser Arbeit angepasst. Die Überarbeitung betraf vor allem eine Reduzierung der Anzahl an Elementen sowie eine Fokussierung der Elemente und deren Merkmale auf die Anforderungen der vorliegenden Aufgabenstellung. Abbildung 14 stellt die neuen, angepassten Geschäftsmodellelemente der Integrated Service Engineering Methodik für die geschäftlich-strategische Sicht vor. - 74 - Abbildung 14: Referenzmodell Dienstleistungs- angebot Zielgruppe Prozess Beteiligte IT/Daten Dienstleistung Finanzielle Aspekte Dienstleistungsbeschreibung Dienstleistungserstellung Rentabilität Zielgruppenbeschreibung besitzt Zielgruppe- IT-Infrastruktur Zielgruppe- Produkte Zielgruppe- Organisation Zielgruppe- Prozesse DienstleistungNutzen Distributions- kanal Kunden- beziehung Dienstleistungs- prozess Dienstleistungs- erbringung Kompetenz Ressource Partner Erlös Gewinn Kosten erhält benötigt bestehtAus be- schreibt vertreibt betrifft bestehtAus bestehtAus wirdErbrachtVon verursacht erzielt erzielt beeinflusst beeinflussen Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich - 75 - Diese neue, angepasste Geschäftsmodell Ontologie teilt die 13 Elemente in vier Bereiche ein: ± Zielgruppenbeschreibung: Mit diesen Elementen werden die unterschiedlichen Zielgruppen und insbesondere deren spezifische Merkmale festgelegt und modelliert. Diese spezifischen Merkmale sind innerhalb einer Zielgruppe homogen und dienen dazu, geeignete und angepasste Dienstleistungen für die jeweilige Zielgruppe zu entwickeln. ± Dienstleistungsbeschreibung: Die Elemente in diesem Bereich ermöglichen die Bestimmung eines oder mehrerer Dienstleistungsangebote. Dabei wurde darauf geachtet, dass alle relevanten Elemente und Merkmale zur trennscharfen Festlegung einer Dienstleistung im Referenzmodell integriert wurden. ± Dienstleistungserstellung: Dieser Bereich und dessen Elemente fokussieren auf der Bestimmung, wie die eigentliche Dienstleistungserbringung aussieht. Neben den Dienstleistungsprozessen spielen dabei die hierfür benötigten Kompetenzen und Ressourcen eine wichtige Rolle. ± Rentabilität: Um festzustellen, ob ein Geschäftsmodell auch finanziell tragfähig ist, wird eine Wirtschaftlichkeitsbetrachtung durchgeführt. Hierzu dienen die Elemente des vierten und letzten Bereichs. Die schwarz dargestellten Elemente sind Pflichtelemente, die bei der Modellierung beschrieben werden müssen. Die anderen Elemente dienen zur Detaillierung und sollten modelliert werden. Die Verbindungen zwischen den Pflichtelementen sind fett dargestellt. Beginnend beim Element der »Zielgruppe« bilden die Pflichtelemente und deren Verbindung den Kern des Geschäftsmodells ab. Die Pflichtelemente und deren Verbindungen bilden darüber hinaus die grundlegende Struktur der methodischen Vorgehensweise bei der Entwicklung des Geschäftsmodells. Tabelle 16 zeigt die Integration der 13 neuen, angepassten Geschäftsmodell- elemente in der Sichten-Dimensions-Matrix der Integrated Service Engineering Methodik (vergleiche Tabelle 14). Um die Konsistenz zwischen der geschäftlich- strategischen Perspektive mit dem Kern der Modellierung von Geschäftsmodellen sowie der nachfolgenden fachlichen Perspektive zu steigern, wurden die Elemente des Referenzmodells den fünf oben beschriebenen Dimensionen zugeordnet. - 76 - Dimensionen Sicht Dienstleistung/ Dienst Prozesse IT/Daten Beteiligte finanzielle Aspekte G es ch äf tli ch - st ra te gi sc h Rolle: Stratege, Ergebnis: Geschäftsmodell Nutzen Dienstleistung Distributions- kanal Kunden- beziehung Zielgruppe Prozesse Dienst- leistungs- prozess Kompetenzen/ Ressourcen Zielgruppe IT- Infrastruktur Zielgruppe Zielgruppe Organisation Zielgruppe Produkte Partner Kosten Erlös Gewinn Ļ Ļ Ļ Ļ Ļ Fa ch lic h- ko nz ep tio ne ll Rolle: Business Analyst, Ergebnis: Erweitertes Geschäftsmodell Funktions- baum (Balzert 2000; Wendt 1991) Funktions- umschrei- bung (Wendt 1991) Funktionale Anforde- rungen (Rupp 2009; Pohl und Rupp 2009) Prozess- modelle (z.B. EPK, BPMN) (Scheer 2006; Schneider und Scheer 2003; OMG 2009; OMG 2010a) fachliches System- diagramm (z.B. FMC Block- diagramme) (Keller und Wendt 2003; Gröne und Keller 2004) Anwendungs- falldiagramm (z.B. UML) (OMG 2010b) Service Blueprint (Shostack 1982, 1984) Organi- gramme (Scheer 2006) Kosten-/ Nutzen- betrachtung Prozess- kosten- rechnung Investitions- rechnung (Röthig 2009; Westkämper 2006; Brugger 2005; Gadatsch und Mayer 2005; Hirschmeier 2004; Schäfer 1999) Tabelle 16: Integration des Geschäftsmodells in ISE 7.1 Beschreibungsstruktur des Referenzmodells Die Elemente des Referenzmodells sind in den nachfolgenden Abschnitten beschrieben. Hierzu wird eine Struktur in Anlehnung an Osterwalder (2004) festgelegt, die in Tabelle 17 erklärt ist. - 77 - Bezeichnung Nennung des zu beschreibenden Elements des Dienstleistungskonzepts Definition Definition des Elements Pflichtelement Modellierung des Elements erfolgt obligatorisch oder optional. Teil von Legt fest, zu welchem Bereich (Zielgruppenbeschreibung, Dienstleistungsbeschreibung, Dienstleistungsprozess bzw. Rentabilität) das Element zugeordnet ist. Kardinalität Beschreibt den Häufigkeitsbereich des Elements im Dienstleistungskonzept. Attribute Eigenschaften des jeweiligen Elements, wobei in geschweiften Klammern {Wert1, Wert2} die möglichen Werte und in runden Klammern (z.B. 1-n) die mögliche Häufigkeit des jeweiligen Attributes spezifiziert werden. Beziehungen Benennt mögliche Beziehungen des zu beschreibenden Elements zu anderen Elementen. Tabelle 17: Beschreibungsstruk tur des Referenzmodells Die Reihenfolge der nachfolgend beschriebenen Elemente entspricht der empfohlenen Reihenfolge zur Modellierung und Entwicklung der webbasierten Infor- mationsplattform für den technischen Vertrieb. Eine Beschreibung methodischer Hinweise und der Vorgehensweise ist in Kapitel 8 aufgeführt. Die Bezeichnungen der einzelnen Elemente müssen zur Unterscheidung eindeutig sein und dürfen nur einmal im Modell verwendet werden. - 78 - 7.2 Zielgruppenbeschreibung Mit diesen Elementen werden die unterschiedlichen Zielgruppen und insbesondere deren spezifische Merkmale festgelegt und modelliert. Diese spezifischen Merkmale dienen dazu, die für die einzelnen Dienstleistungsangebote anvisierten Zielgruppen klar zu trennen. Abbildung 15: Zielgruppenbeschreibung 7.2.1 Zielgruppe Die Entwicklung und Konfiguration der webbasierten Informationsplattform wird an denjenigen Zielgruppen ausgerichtet, deren Geschäftsprozesse direkt durch die Plattform unterstützt werden. Diese Voraussetzung ist bei den Kundengruppen Handelsvermittler, Handelsvertreter, Händler und Hersteller erfüllt. Dazu wurden im Rahmen der oben erwähnten Umfrage (siehe Abschnitt 3.1) und ergänzenden Expertengesprächen mit Handelsvertretern und -vermittlern relevante Eigenschaften der Zielgruppen identifiziert, die Einfluss auf das Geschäftsmodell und damit die zielgruppenspezifische Ausrichtung der Informationsplattform ausüben. Zielgruppe besitzt Zielgruppe- IT-Infrastruktur Zielgruppe- Produkte Zielgruppe- Organisation Zielgruppe- Prozesse erhältDienstleistungs- angebot Zielgruppenbeschreibung Dienstleistungs- beschreibung Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich - 79 - Bezeichnung Zielgruppe Definition Mit diesem Element werden die für die Vertriebsplattform relevante Kundengruppen sowie die für die weitere Spezifikation der Plattform benötigte Attribute dieser Kundengruppen festgelegt. Pflichtelement Obligatorisch Teil von Zielgruppensegmentierung Kardinalität 1-n, wobei n der Anzahl aller relevanten Zielgruppen entspricht Attribute Bezeichnung {ABC} Beschreibung {ABC} AnzahlInsgesamt {123} ErreichbareAnzahl {123} ErreichbarerAnteil {12%} Beziehungen Zielgruppe erhält Dienstleistungsangebot Zielgruppe besitzt ZielgruppeOrganisation Zielgruppe besitzt ZielgruppeProdukte Zielgruppe besitzt ZielgruppeProzesse Zielgruppe besitzt ZielgruppeITInfrastruktur Tabelle 18: Beschreibung von Zielgruppen Bezeichnung Mit diesem Attribut werden die einzelnen Zielgruppen benannt. Beschreibung Dieses Attribut beinhaltet eine Beschreibung der jeweiligen Zielgruppe in Freitextform. AnzahlInsgesamt Um eine zahlenmäßige Festlegung des Nutzungsgrades der Informationsplattform durch die Zielgruppe zu ermitteln, wird die Anzahl potenzieller Kunden der Plattform abgeschätzt, die zu dieser Zielgruppe gehören. ErreichbareAnzahl Hier wird festgelegt, mit wie vielen Kunden der jeweiligen Zielgruppe als Grundlage für die Kosten-/Nutzenrechnung des Geschäftsmodells gerechnet wird. - 80 - ErreichbarerAnteil Alternativ zu der erreichbaren Anzahl von Kunden kann auch ein Anteil der geschätzten (potenziellen) Kunden im Markt in Prozent angegeben werden. Die nachfolgenden Elemente ermöglichen eine Festlegung relevanter Merkmale zur Zielgruppenbeschreibung. Hier werden nur die Merkmale definiert, die charakteris- tisch für diese Zielgruppe sind. Andere Merkmale werden nicht verwendet. 7.2.2 Organisation der Zielgruppe In diesem Element werden die relevanten organisatorischen Merkmale der jeweiligen Zielgruppe bestimmt. Bezeichnung ZielgruppeOrganisation Definition Festlegung der relevanten organisatorischen Merkmale zur Beschreibung einer Zielgruppe. Pflichtelement Optional Teil von Zielgruppe Kardinalität 0-1 Attribute Kundentyp {Handelsvermittlung, Handelsvertretung, Handelsunternehmen, Hersteller} Branche {Maschinen/Apparate, Informations-/Kommunikations- und Medientechnik, Betriebsausstattung/Werkstatteinrichtung und Werkzeug, Bautechnik, Maschinenelement/Befestigungsmittel und Beschlag, Büroeinrichtung/Bürotechnik, Elektro-/Automatisierungs- und Prozessleittechnik, Fahrzeugtechnik, Hauswirtschaftstechnik, Labortechnik, Anlage, Medizintechnik, Rohrleitungstechnik} Geschäftssprache {Deutsch, Englisch, Französisch, Italienisch, Spanisch, Sonstige} Herstelleranzahl {1, 2-3, 4-5, 6-10, größer 10} Beziehungen Zielgruppe besitzt ZielgruppeOrganisation Tabelle 19: Beschreibung der Organisation einer Zielgruppe Kundentyp Beim Vermitteln der Waren nehmen Vertriebsunternehmen verschiedene Rollen ein. Prinzipiell kann zwischen drei Rollen unterschieden werden, die sich vor allem in der Ausprägung der Abschlussvollmacht eines Vertriebsunternehmens unterscheiden (siehe Tabelle 20). Alle Rollen betreffen Handelsvertreter i.w.S. Während die Rolle des Handelsvertreters i.e.S. einen Handelsvertreter kennzeichnet, der die Vollmacht besitzt, stellvertretend für ein anderes Unternehmen einen Vertrag abzuschließen. In Tabelle 20 werden neben der Rolle des Handelsvertreters i.e.S. die Rollen des Handelsvermittlers, des Kommissionärs und des Händlers aufgeführt. 35 Prozent der Handelsvertreter sind zusätzlich zur Vertretung in der Rolle eines Händlers tätig und kaufen und verkaufen Waren für bestimmte Waren-, Zielgruppen oder Lieferanten in - 81 - eigenem Namen (CDH 2009). Damit nimmt der Händler keine Stellvertretung ein und ist als Konsequenz daraus kein Handelsvertreter. Die verschiedenen Rollen, die ein Handelsvertreter im Rahmen seiner Tätigkeiten einnehmen und ausüben kann, haben einen Einfluss auf die zugrundeliegenden Geschäftsprozesse mit Herstellern und Kunden und darüber auch auf deren IT-Anwendungen. Typ Rolle Erklärung Abschluss- vollmacht Handels- vertreter i.w.S. Handels- vermittler Die Dienstleistung des Handelsvermittlers besteht in einem »Zusammenbringen« von vertragsabschlusswilligen Parteien. Keine Handels- vertreter i.e.S. Der Handelsvertreter hat die Vollmacht, selbst, aber eben im Namen eines anderen, als Stellvertreter den Vertrag abzuschließen. Stellvertretung (Abschluss) Kommis- sionär Der Kommissionär ist hingegen bloß als indirekter Stellvertreter tätig, sodass er selbst Vertragspartner wird (indem er z. B. verkauft) und bloß auf fremde Rechnung handelt, d. h. im Innenverhältnis seinem Kommittenten verpflichtet ist, auf dessen Rechnung er tätig ist. Indirekte Stellvertretung Händler Händler Als Händler werden Personen oder Unternehmen bezeichnet, die Handel betreiben, Waren einkaufen und sie wieder verkaufen. Sie erzielen einen Ertrag, indem der Verkaufspreis höher als der Einkaufspreis ist. Abschlussvoll- macht im eigenen Namen Hersteller Lieferant Der Hersteller liefert die technischen Produkte für die oben aufgeführten Vertriebsunternehmen. Abschluss- vollmacht im eigenen Namen bzw. deren Übertrag auf Handels- vertreter Tabelle 20: Kategorien von Kundentypen Neben den Vertriebsunternehmen sind auch deren Hersteller als Zielgruppe der Informationsplattform zu berücksichtigen. Geeignete Plattformfunktionen müssen die Geschäftsprozesse der Hersteller in Abhängigkeit von deren Voraussetzungen unterstützen. Weitere Zielgruppen können ergänzt werden, wie z.B. IT-Anbieter von komplementären Diensten und Funktionen für die Plattform. Branche Die Branchenzugehörigkeit kann festgelegt werden, um erste Anhaltspunkte bzgl. Markt und Produkte zu geben. Hierbei wird auf eine angepasste Einteilung des eCl@ss Standards (www.eclass.de) zurückgegriffen. - 82 - Geschäftssprache Die Festlegung mehrerer Sprachen hängt davon ab, in welchen Sprachregionen die Zielgruppen Handelsvertreter, -vermittler und Hersteller angesprochen werden sollen. 55 Prozent der Handelsvertreter vertreten mindestens ein ausländisches Unternehmen (CDH 2009). Beim Betrieb der Informationsplattform im internationalen Kontext gewinnt die Berücksichtigung der Geschäftssprachen der jeweiligen Zielgruppen eine große Bedeutung. In diesem Zusammenhang ist festzulegen, welche Sprachen die Plattform unterstützt. Herstelleranzahl Die Anzahl an Herstellern, die ein Handelsvermittler vertritt. Je größer diese Anzahl pro Handelsvertretung desto höher die Notwendigkeit der Multilieferantenfähigkeit der Informationsplattform (siehe Abschnitt 3.2.2). In einzelnen Prozessschritten, wie z.B. bei der Gesprächsvorbereitung, strukturiert der Handelsvertreter diesen Schritt, indem er alle Aktionen, offene Punkte und Fragestellungen für alle zu vertretenden Hersteller zusammenfasst. Nach dem Kundengespräch muss ein Gesprächsprotokoll separat für alle zu vertretenden Hersteller erstellt werden. Hierzu müssen die während des Kundengesprächs gemeinsam notierten Informationen nach Herstellern getrennt und diesen jeweils zugesendet werden. Ein IT-System, das den Vorgang des Zusammenfassens und Separierens von Vertriebsinformationen nach Herstellern unterstützt, wird in diesem Kontext als multilieferantenfähig bezeichnet (Kett et al. 2009b). - 83 - 7.2.3 Produkte der Zielgruppe In diesem Element werden die relevanten produktbezogenen Merkmale der jeweiligen Zielgruppe bestimmt. Bezeichnung ZielgruppeProdukte Definition Festlegung der relevanten produktbezogenen Merkmale einer Zielgruppe. Pflichtelement Optional Teil von Zielgruppe Kardinalität 0-1 Attribute Produkttyp {Standardprodukte, Konfigurierbare Produkte, Individualprodukte} Sortimentsgröße {gering (<100), mittel (<500), groß (<10.000), sehr groß (>10.000)} AnzahlNeuerProdukte {gering (<50), mittel (<100), hoch (<1.000), sehr hoch (>1.000)} Beziehungen Zielgruppe besitzt ZielgruppeProdukte Tabelle 21: Beschreibung von Produkten einer Zielgruppe Produkttyp Im Rahmen der Informationsplattform für den technischen Vertrieb wird zwischen drei Produkttypen unterschieden (Dolmetsch 2001): ± Standardprodukte: Standardprodukte sind Güter oder Dienstleistungen, die in einem repetitiven Leistungserstellungsprozess produziert und über vorgegebene Eigenschaften definiert werden können. Ein Hersteller identifiziert ein Produkt eindeutig über eine zugeordnete Produkt- bzw. Materialnummer. Beispiel: elektronische Bauelemente. ± Konfigurierbare Produkte: Der Begriff Konfigurierbarkeit meint in diesem Zusammenhang: Produktvarianten (z.B. Farbe, Größe), optionale Extras (z.B. Lederausstattung, zweites Diskettenlaufwerk), Parametrisierung (z.B. Standardsoftware), Spezialisierung (z.B. Luxusversion einer Limousine), kundenspezifische Erweiterung oder Modifikation (z.B. Tuning eines Autos). ± Individualprodukte: Individualprodukte sind Einzelanfertigungen, die speziellen Kundenanforderungen gerecht werden. Individualprodukte bedürfen einer Reihe von interaktiven Abklärungen zwischen Anbieter und Nachfrager, die nicht über einen Katalog abbildbar sind. Beispiel: Automobilteile. Die Produkttypen wirken sich insbesondere auf Prozesse und damit auch auf Funktionen in der Phase der Produktberatung aus. - 84 - Sortimentsgröße Die Sortimentsgröße ist ein Maß für die Anzahl von Produktinformationen, die zwischen Vertriebsunternehmen und dessen Herstellern ausgetauscht werden müssen. AnzahlNeuerProdukte Die Anzahl an Produkten, die pro Jahr neu ins Sortiment hinzukommen ist ebenso ein Maß dafür, wie viele Produktinformationen pro Jahr zwischen Vertriebs- unternehmen und Herstellern ausgetauscht werden müssen, um den Handelsvertreter auf dem aktuellen Stand zu halten. 7.2.4 Prozesse der Zielgruppe In diesem Element werden die relevanten prozessbezogenen Merkmale der jeweiligen Zielgruppe bestimmt. Bezeichnung ZielgruppeProzesse Definition Festlegung der relevanten prozessbezogenen Merkmale einer Zielgruppe. Pflichtelement Optional Teil von Zielgruppe Kardinalität 0-1 Attribute ArtDerMobilität {keine, Informationsabruf, Informationspräsentation, Informationseingabe} ArtDesBestelleingangs {indirekt bei Vertriebsunternehmen, direkt beim Hersteller} Lagerverwaltung {keine, eigene, fremde} GradITKompetenzEigentümer {keine, geringe, gute, sehr gute} AnzahlBesuchsberichte {gering (<20), mittel (<50), hoch (>50)} AnzahlAngebotsanfragen {gering (<20), mittel (<50), hoch (>50)} AnzahlAngebote {gering (<20), mittel (<50), hoch (>50)} AnzahlBestellungen {gering (<20), mittel (<50), hoch (>50)} AnzahlRechnungen {gering (<20), mittel (<50), hoch (>50)} AnzahlReklamationen {gering (<20), mittel (<50), hoch (>50)} Beziehungen Zielgruppe besitzt ZielgruppeProzesse Tabelle 22: Beschreibung von Prozessen einer Zielgruppe - 85 - In Tabelle 23 sind die für die webbasierte Informationsplattform für Handels- vertretungen und in Tabelle 24 für deren Hersteller relevanten Vertriebsprozesse aufgeführt und die entsprechende funktionale Unterstützung in Form von UML Use Cases (Anwendungsfällen) dem jeweiligen Prozess zugeordnet. Vertriebsphase Vertriebsprozess Anwendungsfälle (Use Cases) Beratung Gesprächsvorbereitung Kundengespräch vorbereiten Gesprächsvorbereitung Informationsausgabe für Kundengespräche konfigurieren Vorstellung von Produkten Produkte suchen Vorstellung von Produkten Multimediale Informationen abrufen und präsentieren Bereitstellung von Produktinformationen für Kunden Produkte suchen (Übersicht) Bereitstellung von Produktinformationen für Kunden Elektronische Produktinformationen abrufen (Detailsicht) Bereitstellung von Produktinformationen für Kunden Produktinformationen ggf. per E-Mail an Kunden versenden Bereitstellung von Produktmustern Antrag Mustervergabe verwalten/versenden Bereitstellung von Produktmustern Kundenfeedback zur Musterprüfung inklusive Statusvergabe verwalten Bereitstellung von Produktmustern Informationen über Mustervergabe abrufen Unterstützung und Beratung bei der Produktauswahl Produkte suchen (Übersicht) Unterstützung und Beratung bei der Produktauswahl Elektronische Produktinformationen abrufen (Detailsicht) Unterstützung und Beratung bei der Produktauswahl Produkte in Warenkorb legen Unterstützung und Beratung bei der Produktauswahl Angebotsanfrage/Bestellung aus Warenkorb erstellen Verkauf Klärung von Kundenanfragen mit Hersteller Korrespondenz zu Kundenanfragen verwalten/versenden/freigeben - 86 - Vertriebsphase Vertriebsprozess Anwendungsfälle (Use Cases) Entgegennahme von Angebotsanfragen Angebotsanfragen eingeben/verwalten Weiterleitung von Angebotsanfragen an Hersteller Angebotsanfragen an Hersteller versenden/freigeben Erstellung von Angeboten Angebote anlegen/verwalten Erstellung von Angeboten Angebote an Kunden versenden Entgegennahme und Weiterleitung von Bestellungen an Hersteller Bestellungen an Hersteller versenden/freigeben Beratung Bereitstellung von Besuchsberichten an Hersteller Besuchsbericht bearbeiten/verwalten Bereitstellung von Besuchsberichten an Hersteller Besuchsbericht für Hersteller versenden/freigeben Verkauf Entgegennahme von Bestelländerungen Bestelländerungen aufnehmen Entgegennahme von Bestelländerungen Bestelländerungen an Hersteller versenden/freigeben Abgleich der Provisionszahlungen mit Hersteller Provisionsvolumen abrufen Abwicklung Abfrage von Information über Geschäftsvorfälle für Kunden Statusinformationen von Geschäftsvorfällen abrufen (Übersicht) Abfrage von Information über Geschäftsvorfälle für Kunden Details über Geschäftsvorfälle abrufen (Detailsicht) Abgleich von elektronischen Geschäftsdokumenten mit Hersteller Elektronische Geschäftsdokumente verwalten (z.B. für Statusabfrage) After Sales und Support Bearbeitung von Reklamationen Reklamation anlegen Bearbeitung von Reklamationen Reklamation prüfen Bearbeitung von Reklamationen Reklamation an Hersteller versenden/freigeben - 87 - Vertriebsphase Vertriebsprozess Anwendungsfälle (Use Cases) Querschnitts- prozesse Systemadministration Registrierung Systemadministration Benutzer verwalten Systemadministration Rechte verwalten Durchführung der Kontaktverwaltung (ggf. Customer Relationship Management) Kontakte verwalten Durchführung der Kontaktverwaltung (ggf. Customer Relationship Management) Korrespondenz verwalten Durchführung der Terminverwaltung Termine verwalten Durchführung der Aufgabenverwaltung Aufgaben verwalten Tabelle 23: Vertriebsprozesse von Handelsvertretern und abgeleitete Anwendungsfälle - 88 - Vertriebsphase Vertriebsprozess Anwendungsfälle (Use Cases) Beratung Bereitstellung von Produktmustern Antrag Mustervergabe empfangen/verwalten Bereitstellung von Produktmustern Kundenfeedback zur Musterprüfung inklusive Statusvergabe verwalten Verkauf Klärung von Kundenanfragen Korrespondenz zu Kundenanfragen verwalten/versenden/freigeben Entgegennahme von Angebotsanfragen Angebotsanfragen empfangen/verwalten Erstellung von Angeboten Angebote versenden/freigeben Entgegennahme und Bearbeitung von Bestellungen Bestellung empfangen/verwalten Bereitstellung von Besuchsberichten an Lieferant Besuchsberichte empfangen/verwalten Entgegennahme von Bestelländerungen Bestelländerungen empfangen/verwalten Erstellung/Versand von Rechnungen Rechnung versenden/freigeben Abgleich der Provisionszahlungen mit Handelsvertreter Provisionsvolumen eines Handelsvertreters abrufen Abwicklung Abfrage von Informationen über Geschäftsvorfälle Statusinformationen von Geschäftsvorfällen abrufen (Übersicht) Abfrage von Informationen über Geschäftsvorfälle Details über Geschäftsvorfälle abrufen (Detailsicht) Abgleich von elektronischen Geschäftsdokumenten mit Handelsvertretern Elektronische Geschäftsdokumente verwalten (z.B. für Statusabfrage) After Sales und Support Bearbeitung von Reklamationen Reklamation empfangen/verwalten Bearbeitung von Reklamationen Status Reklamation versenden/freigeben - 89 - Vertriebsphase Vertriebsprozess Anwendungsfälle (Use Cases) Querschnitts- prozesse Systemadministration Registrierung Systemadministration Benutzer verwalten Systemadministration Rechte verwalten Systemadministration Systemintegration konfigurieren Systemadministration Funktionalität anpassen Management von Produktinformationen Produktinformationen importieren Management von Produktinformationen Produktinformationen einpflegen Durchführung der Kontaktverwaltung (ggf. Customer Relationship Management) Kontakte verwalten Tabelle 24: Vertriebsprozesse von Herstellern und abgeleitete Anwendungsfälle Bei einer Umsetzung der Informationsplattform muss entschieden werden, welche der Anwendungsfälle umgesetzt und zugleich die geeignete Reihenfolge der Umsetzung festgelegt werden. Eine detaillierte Ausarbeitung und Beschreibung der Anwendungsfälle ist in Anhang B aufgeführt. ArtDerMobilität Hier steht die mobile Nutzung der Informationsplattform beim Kunden vor Ort im Mittelpunkt. Dabei werden drei Funktionsarten unterschieden: ± Informationsabruf: Der Vertriebsmitarbeiter ruft benötigte Vertriebsinformationen beim Kunden vor Ort über ein mobiles Gerät und über die elektronische Informationsplattform ab. In diesem Zusammenhang muss die Suche sowie die Darstellung der Informationen vor allem für den Vertriebsmitarbeiter optimiert werden. ± Informationspräsentation: Hierbei werden Kunden multimediale Informationen, wie z.B. Videos und Bilder, über das mobile Gerät und die Informationsplattform präsentiert. Das Gerät muss daher vor allem bzgl. Bildschirmgröße sowie Sichtbarkeit der Bildinformationen auch für Kunden mit schlechtem Sehvermögen und bei ungünstigen Lichtverhältnissen funktionieren. - 90 - ± Informationseingabe: Der Vertriebsmitarbeiter gibt in diesem Fall auch Informationen über ein mobiles Gerät in die Informationsplattform beim Kunden vor Ort ein. Die Mobilität beim Kunden vor Ort beeinflusst diejenigen Prozesse, die zwischen Vertriebsunternehmen und deren Kunden stattfinden. ArtDesBestelleingangs Der Bestelleingang von Kundenunternehmen kann zum einen direkt beim Hersteller erfolgen, so dass in diesem Fall die Bestellinformationen schnellst möglich mit den Vertriebsunternehmen abgeglichen werden müssen, zum anderen indirekt bei den Vertriebsunternehmen eintreffen, so dass diese die Bestellinformationen an den Hersteller weiterleiten müssen. Insbesondere der erste Fall verursacht bei Vertriebsunternehmen inkonsistente Bestellinformationen, wenn der Abgleich der Informationen zwischen Hersteller und Vertriebsunternehmen nicht zeitnah funktioniert. Dies bedeutet, die Aussagefähigkeit gegenüber ihren Kunden sinkt (Spath et al. 2008a). Daher sollte in diesem Fall besonderes Augenmerk auf den zeitnahen Abgleich der Informationen gelegt werden. Lagerverwaltung Handelsvertretungen führen in der Regel kein eigenes Lager. Sind sie jedoch darüber hinaus auch als Händler tätig, betreiben einige von ihnen ein eigenes Lager (Spath et al. 2008a). GradITKompetenzEigentümer Mit diesem Merkmal wird festgelegt, wieviel IT-Kompetenz die angestrebte Zielgruppe besitzt. Bei der in Abschnitt 3.1 beschriebenen Umfrage gaben ca. 50 Prozent der befragten Vertriebsunternehmen an, schlechte oder sehr schlechte IT- Kompetenz zu besitzen. Die Hälfte davon administrieren jedoch ihre IT-Systeme selber (Spath et al. 2008a). Dies ist ein Ansatzpunkt für die Bereitstellung geeigneter Dienste und Dienstleistungen. AnzahlBesuchsberichte Eine Handelsvertretung bzw. -vermittlung muss regelmäßig Besuchsberichte über Kunden an den Hersteller anfertigen und senden, um seine Vertriebsbemühungen zu dokumentieren. Je größer die Anzahl an Besuchsberichten pro Monat, desto mehr Aufwand entsteht seitens der Handelsvertretung bzw. -vermittlung beim Zusammenfassen und Separieren von herstellerspezifischen Kundeninformationen. Dieser manuelle Aufwand kann mittels der Informationsplattform reduziert werden. AnzahlAngebotsanfragen Darunter wird die durchschnittliche Anzahl an Angebotsanfragen pro Monat verstanden, die ein Vertriebsunternehmen selbst bearbeitet bzw. an seine Hersteller weiterleitet. - 91 - AnzahlAngebote Darunter wird die durchschnittliche Anzahl an Angeboten pro Monat verstanden, die ein Vertriebsunternehmen selbst erstellt bzw. von seinen Herstellern erhält und weiterleitet. AnzahlBestellungen Darunter wird die durchschnittliche Anzahl an Bestellungen pro Monat verstanden, die eine Vertriebsorganisation selbst bearbeitet bzw. an seine Hersteller weiterleitet. AnzahlRechnungen Darunter wird die durchschnittliche Anzahl an Rechnungen pro Monat verstanden, die ein Vertriebsunternehmen selbst erstellt bzw. von seinen Herstellern erhält und weiterleitet. AnzahlReklamationen Darunter wird die durchschnittliche Anzahl an Reklamationen pro Monat verstanden, die ein Vertriebsunternehmen entgegennimmt und an seine Hersteller weiterleitet. Diese Informationen sind Grundlage für die Abschätzung des Kommunikations- volumens zwischen Handelsvertreter, -vermittler und Hersteller. 7.2.5 IT-Infrastruktur der Zielgruppe In diesem Element werden die relevanten IT-bezogenen Merkmale der jeweiligen Zielgruppe bestimmt. Diese Informationen beeinflussen Fragestellungen der Schnittstellenanbindung und des Informationsaustauschs zwischen Informations- plattform, Handelsvertretern und Herstellern. Bezeichnung ZielgruppeITInfrastruktur Definition Festlegung der relevanten IT-bezogenen Merkmale einer Zielgruppe. Pflichtelement Optional Teil von Zielgruppe Kardinalität 0-1 Attribute ITInfrastrukturVertriebsunternehmen {ERP, CRM, PIM} ITInfrastrukturHersteller {ERP, CRM, PIM, WWS} Integrationsfähigkeit {Produktinformationen, Transaktionsdaten, Kontaktdaten} EBusinessStandards {ABC} ITAdministration {EigeneDurchEigentümer, EigeneDurchMitarbeiterIT, FremdeDurchDienstleister} Beziehungen Zielgruppe besitzt ZielgruppeITInfrastruktur Tabelle 25: Beschreibung der IT-Infrastruk tur einer Zielgruppe - 92 - ITInfrastrukturVertriebsunternehmen Bei der Entwicklung der Informationsplattform müssen vorhandene IT-Systeme seitens der Vertriebsunternehmen beachtet und ggf. notwendige Schnittstellen angeboten werden. Im Rahmen der oben genannten Umfrage (siehe Abschnitt 3.1) sind vor allem Enterprise Resource Planning Systeme (ERP) sowie Customer Relationship Management Systeme (CRM) zu berücksichtigen. Weitere Systeme sind eher von zweitrangiger Bedeutung für die Befragten (Spath et al. 2008a). ITInfrastrukturHersteller Neben den IT-Systemen der Vertriebsunternehmen besitzen insbesondere die IT- Systeme der Hersteller eine große Bedeutung. In diesem Zusammenhang werden daher ERP-Systeme, CRM-Systeme, Produktinformationsmanagement-Systeme (PIM) sowie Warenwirtschaftssysteme (WWS) zur Anbindung an die Vertriebsplattform berücksichtigt. Hersteller, die nicht in der Lage sind, benötigte Informationen aus vorhandenen IT-Systemen auf der Plattform bereitzustellen, müssen diese Informationen über entsprechende webbasierte Funktionen in die Informationsplattform eingeben und pflegen können. Im ungünstigsten Fall müssen diese Informationen vom Vertriebsunternehmen manuell in die Plattform eingepflegt werden. Integrationsfähigkeit Dieses Merkmal legt fest, ob die Zielgruppe in der Lage ist, die für die Vertriebsprozesse relevanten elektronischen Schnittstellen zu realisieren. Dabei handelt es sich vor allem um die drei wichtigsten Schnittstellen zum Informationsaustausch (vgl. Berlecon Research 2010): ± Produktinformationen: Die Hersteller stellen relevante Produktinformationen für die Vertriebsunternehmen elektronisch bereit. Dies gilt für Standardprodukte in Form von elektronischen Produktkatalogen, wie z.B. BMEcat (Schmitz et al. 2005), sowie bei konfigurierbaren Produkten durch die Bereitstellung von Produktkonfiguratoren. ± Transaktionsdaten: Dies betrifft insbesondere den Austausch von Informationen über Geschäftsvorfälle in elektronischer Form, wie z.B. in openTRANS (Schmitz et al. 2009). ± Kontaktdaten: Austausch von Kontaktdaten von Herstellern zu Vertriebsunter- nehmen, wie z.B. vCard (Perreault und Resnick 2010), sowie umgekehrt zur Synchronisation der Stammdaten. EBusinessStandards In diesem Attribut werden die Standards festgelegt, die eine Zielgruppe unterstützen sollte, um sich mit geringem Aufwand in die Informationsplattform integrieren zu können. Einige der relevanten E-Business Standards sind in Tabelle 26 aufgeführt. - 93 - Produktinformationen Transaktionsdaten Kontaktdaten (Mikrostandards) ± BMEcat (Schmitz et al. 2005) ± PRICAT und PRODAT (GS1 Germany 2002) ± DATANORM (DATANORM- Arbeitskreis 1999) ± Catalog Interchange Format (CIF) (Ariba Technologies 1998) ± Open Catalog Interface (OCI) (SAP 2003) ± openTRANS (Schmitz et al. 2009) ± xCML (cXML.org 2009) ± EDIFICE (EDIFICE 2010) ± EANCOM (GS1 Germany 2002) ± ODETTE (Nash 1997) ± vCard (Perreault und Resnick 2010) ± hCard (Celik und Suda 2005) Tabelle 26: E-Business Standards im Kontext der Arbeit (erweitert Berlecon Research 2010) ITAdministration Die IT-Administration wird gemäß der Umfrage in Abschnitt 3.1 in ca. 25 Prozent der Fällen vom Eigentümer des Vertriebsunternehmens selber durchgeführt. Zielsetzung der webbasierten Informationsplattform ist u.a. die Entlastung der Handelsvertreter von Aufgaben der IT-Administration. Unterschieden wird bei diesem Merkmal zwischen (Spath et al. 2008a): ± Eigene IT-Administration durch Eigentümer: IT-Adminstration wird durch den Eigentümer persönlich durchgeführt. Hier ist es interessant dieses Merkmal mit dem Grad der IT-Kompetenz des Eigentümers gemeinsam zu betrachten. ± Eigene IT-Administration durch IT-Mitarbeiter: Die IT-Administration wird durch einen spezialisierten Mitarbeiter ausgeführt. ± Fremde IT-Administration durch IT-Dienstleister: Die IT-Administration wird durch einen externen Dienstleister erbracht. 7.3 Dienstleistungsbeschreibung Die Elemente in diesem Bereich ermöglichen die Bestimmung eines oder mehrerer Dienstleistungsangebote. Dabei wurde darauf geachtet, dass alle relevanten Elemente und Merkmale zur trennscharfen Festlegung einer Dienstleistung im Referenzmodell integriert wurden. - 94 - Abbildung 16: Dienstleistungsbeschreibung Dienstleistungs- angebot DienstleistungNutzen Distributions- kanal Kunden- beziehung bestehtAus be- schreibt vertreibt betrifft Zielgruppe Dienstleistungs- erbringung Erlös erhält erzielt benötigt Dienstleistungsbeschreibung Zielgruppenbeschreibung Dienstleistungserstellung Rentabilität Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich - 95 - 7.3.1 Dienstleistungsangebot Jede definierte Zielgruppe erhält ein eigens für sie angepasstes Dienstleistungs- angebot. Um ein Dienstleistungsangebot vollständig zu bestimmen, werden der Nutzen, einzelne Dienstleistungen (im Sinne von Dienstleistungspaketen), die Vertriebskanäle und die Kundenbeziehung im Modell hinterlegt. Bezeichnung Dienstleistungsangebot Definition Mit diesem Element wird für jede Zielgruppe ein angepasstes Dienstleistungsangebot erstellt. Pflichtelement Obligatorisch Teil von Dienstleistungsbeschreibung Kardinalität 1-n, wobei n der Anzahl aller Zielgruppen entspricht Attribute Bezeichnung {ABC} Beschreibung {ABC} Beziehungen Zielgruppe erhält Dienstleistungsangebot Dienstleistungsangebot benötigt Dienstleistungserbringung Dienstleistungsangebot bestehtAus Dienstleistung Tabelle 27: Beschreibung von Dienstleistungsangeboten Bezeichnung Mit diesem Attribut wird jedes Dienstleistungsangebot benannt. Beschreibung Dieses Attribut beinhaltet eine Beschreibung des jeweiligen Dienstleistungsangebots. Die nachfolgenden Elemente ermöglichen eine Festlegung relevanter Merkmale zur näheren Beschreibung des Dienstleistungsangebots. Hier werden bei der Modellierung des Geschäftsmodells nur diejenigen Merkmale definiert, die charakteristisch für dieses Dienstleistungsangebot sind. Bei der Definition eines konkreten Geschäftsmodells sollten unbedeutende Merkmale vermieden werden, um nicht den Fokus auf das Wesentliche zu verlieren. 7.3.2 Dienstleistung In diesem Element werden die einzelnen Dienstleistungspakete festgelegt, die einer Zielgruppe angeboten werden sollen. - 96 - Fachlich-inhaltliche Unterstützung D ie ns t/ D ie ns t- le is tu ng d er w eb - ba si er te n In fo r- m at io ns pl at tfo rm A bd ec ku ng d er Fu nk tio na lit ät in be st eh en de n IT -L ös un ge n Grundlegende Funktionen IT-Unterstützung grundlegender Aktivitäten des Vertriebs Ɣ Ɣ Funktionen zur Herstellerkommunikation Integrierte, multilieferantenfähige IT- Unterstützung der Kommunikation zwischen Vertriebsunternehmen und Herstellern Ɣ ż Ergänzende Funktionen Finanzbuchhaltung IT-Unterstützung von Aktivitäten der Finanzbuchhaltung Ɣ Ɣ Ergänzende Funktionen Customer Releationship Management IT-Unterstützung von Aktivitäten des Kundenbeziehungsmanagement Ɣ Ɣ Ergänzende Funktionen Enterprise Resource Planning/Waren- wirtschaft IT-Unterstützung von Aktivitäten der Ressourcen Planung und der Warenwirtschaft Ɣ Ɣ Begleitende Dienstleistungen Dienstleistungen zur Planung, Einführung und Betrieb der elektronischen Vertriebsplattform Ɣ ż Ɣ Kriterium ist erfülltż Kriterium ist nicht erfüllt Tabelle 28: Einteilung der angebotenen Dienstleistungen Aus den Untersuchungsergebnissen und den darauf aufbauenden Schluss- folgerungen lassen sich Dienstleistungen für Vertriebsunternehmen und Hersteller ableiten. Diese Dienstleistungen können in sechs Kategorien eingeteilt werden, wie in Tabelle 28 aufgeführt. Des Weiteren zeigt die Tabelle die fachlich-inhaltliche Unterstützung der Dienste/Dienstleistungen der webbasierten Informationsplattform im Vergleich zu bestehenden IT-Lösungen für die Zielgruppen Handelsvertreter und Hersteller (siehe Abschnitt 3.2). Hier wird deutlich, dass sich die Informationsplattform vor allem über die integrierte, multilieferantenfähige IT- Unterstützung der Kommunikation zwischen Handelsvertretern und Herstellern von bestehenden Lösungen unterscheidet. Hierin liegt die Innovation und damit die Differenzierung zum Wettbewerb. - 97 - Bezeichnung Dienstleistung Definition Festlegung der Dienstleistungspakete, die einer Zielgruppe angeboten werden sollen. Pflichtelement Obligatorisch Teil von Dienstleistungsangebot Kardinalität 1-n, wobei n der Anzahl aller Dienstleistungspakete entspricht Attribute Dienstleistungsbezeichnung {ABC} Dienstleistungsbeschreibung {ABC} Alleinstellungspotenzial {kein, innovative Imitation, Branchenbester, Innovation} Preisniveau {kostenlos, billig, durchschnittlich, hochpreisig} GrundlegendeFunktionen {Terminverwaltung, Adressverwaltung, Aufgabenverwaltung, Dokumentenverwaltung} FunktionenZurKommunikationMitHerstellern {Produktinformationsmanagement (Produktkataloge für Standardprodukte), Produktinformationsmanagement (Erstellung von Produktkatalogen), Konfiguratoren (für zusammengesetzte/kombinierbare Produkte), Unterstützung bei der Entwicklung Kunden-spezifischer Produkte (Individualprodukte), Besuchsvorbereitung (Erstellung, Verwaltung), Besuchsberichtswesen (Erstellung, Versand, Verwaltung), Angebotsanfragen/Angebote, Bestellungen/Rechnungen/Lieferavis, Reklamationen, Reporting (z.B. Umsätze, Provisionen)} ErgänzendeFunktionenFiBu {Einnahmen- und Ausgabenrechnung} ErgänzendeFunktionenCRM {Kampagnenplanung/-durchführung, Leadmanagement} ErgänzendeFunktionenERP {Lagerhaltung} BegleitendeDienstleistungen {Beratung, Konfiguration, Erweiterungen, Integration (Schnittstellen), Hotline/Helpdesk} Beziehungen Dienstleistungsangebot bestehtAus Dienstleistung Nutzen beschreibt Dienstleistung Distributionskanal vertreibt Dienstleistung Kundenbeziehung betrifft Dienstleistung Dienstleistung erzielt Erlös Tabelle 29: Beschreibung von Dienstleistungen - 98 - Dienstleistungsbezeichnung Dieses Merkmal beinhaltet die Bezeichnung des Dienstleistungspakets. Dienstleistungsbeschreibung Hiermit wird das Dienstleistungspaket inhaltlich beschrieben. Zur Erstellung einer Kombination von Dienstleistungspaketen für die Informationsplattform werden die nachfolgenden Kategorien mit Dienstleistungspaketen zur Auswahl vorgeschlagen. Die Kategorien und Dienstleistungspakete des Referenzmodells sollten nach einiger Zeit überprüft und ggf. an die sich verändernden Anforderungen der Zielgruppen angepasst werden. Alleinstellungspotenzial Dieses Merkmal schätzt den Wert einer Dienstleistung im Vergleich zum Wettbewerb ein (siehe Osterwalder 2004). Kein Die Dienstleistung weist keine herausragenden Eigenschaften im Vergleich zum Wettbewerb auf und besitzt daher keine Alleinstellungsmerkmale. Innovative Imitation Die Dienstleistung wurde beim Wettbewerb kopiert, aber mit innovativen Eigenschaften versehen und umgesetzt. Branchenbester Der Wert einer Dienstleistung wurde durch eine optimierte Umsetzung gesteigert und setzt sich damit vom Wettbewerb extrem ab. Innovation Die angebotene Dienstleistung ist neu und wird in dieser Form noch nicht auf dem Markt angeboten. Tabelle 30: Alleinstellungspotenzial (Osterwalder 2004) Preisniveau Gemäß Osterwalder (2004) wird das Preisniveau einer Dienstleistung abgeschätzt und festgehalten. Die Abschätzung erfolgt im Vergleich zu den relevanten Wettbewerbern im jeweiligen Markt. - 99 - Kostenlos Die Dienstleistung wird kostenlos im Markt angeboten. Billig Ein Unternehmen bietet die Dienstleistung tiefpreisig auf dem Markt an und verfolgt damit die Strategie der Preisführerschaft (Johnson und Scholes 1997). Durchschnittlich Der Preis der angebotenen Dienstleistung unterscheidet sich nicht von dem marktüblichen Preisniveau. Damit differenziert sich das Unternehmen nicht von seinen Mitbewerbern im Markt. Hochpreisig Die Dienstleistung wird über dem marktüblichen Preisniveau angeboten. Um sich trotzdem von Mitbewerbern zu differenzieren, müssen für Kunden relevante Dienstleistungs- merkmale im Vergleich zu Mitbewerbern Besonderheiten aufweisen, z.B. höhere Dienstleistungsqualität oder schnellere Dienstleistungserbringung (Johnson und Scholes 1997). Tabelle 31: Preisniveau (Osterwalder 2004) GrundlegendeFunktionen Der Zielgruppe der Vertriebsunternehmen wird eine IT-Unterstützung von grundlegenden Tätigkeiten des Vertriebs angeboten, wie Termin-, Adress-, Aufgaben- und Dokumentenverwaltung. FunktionenZurKommunikationMitHerstellern Diese Funktionen werden bislang von keinem anderen IT-System angeboten und unterstützen insbesondere die Kommunikation der Vertriebsunternehmen mit ihren durchschnittlich sechs Herstellern. Dabei spielt die elektronische und multi- lieferantenfähige Unterstützung der unternehmensübergreifenden Geschäfts- prozesse eine große Rolle. ErgänzendeFunktionenFiBu In diese Kategorie fallen alle Funktionen, die im Zusammenhang mit dem Rechnungswesen von Vertriebsunternehmen stehen. ErgänzendeFunktionenCRM Diese Funktionen unterstützen das Management von Kundenbeziehungen der Vertriebsunternehmen. ErgänzendeFunktionenERP Dies sind IT-Funktionen, die insbesondere mit der Planung von Ressourcen im Rahmen der Warenwirtschaft im Zusammenhang stehen. BegleitendeDienstleistungen Dies sind Dienstleistungen, die nicht elektronisch angeboten werden, sondern in persönlicher Interaktion mit den Zielgruppen. - 100 - 7.3.3 Nutzen In diesem Element werden die grundlegenden Nutzenargumente für eine webbasierte Informationsplattform für Handelsvertretungen und Herstellern als Software as a Service aufgeführt. Die Nutzenargumente sind Untersuchungs- ergebnisse aus der durchgeführten Umfrage (siehe Abschnitt 3.1) und begleitenden Expertengesprächen mit den Zielgruppen. Sie beeinflussen insbesondere die Ableitung geeigneter Dienstleistungen für die Zielgruppen. Bezeichnung Nutzen Definition Mit diesem Element wird die Value Proposition einer Dienstleistung festgelegt, die Zielgruppen angeboten und vermittelt wird. Pflichtelement Optional Teil von Dienstleistung Kardinalität 0-1 Attribute Beschreibung {ABC} KonzentrationAufKernaufgaben {Reduzierung manueller Tätigkeiten, Reduzierung der eigenen Administration von IT-Lösungen} SteigerungDerAussagefähigkeit {Steigerung der Aktualität der Vertriebsinformationen, Ortsunabhängiger Abruf und Bereitstellung von Vertriebsinformationen, Multimediale Aufbereitung von Produktinformationen für die Kundenpräsentation} EffizienzsteigerungDerKernprozesse {Elektronische Unterstützung beim Austausch von Vertriebsinformationen, Elektronische Unterstützung bei der Verwaltung von Vertriebsinformationen, Multilieferantenfähigkeit der IT-Unterstützung} Beziehungen Nutzen beschreibt Dienstleistung Tabelle 32: Beschreibung des Nutzens Beschreibung Dieses Merkmal beinhaltet die Beschreibung des Nutzens einer Dienstleistung. KonzentrationAufKernaufgaben Viele der befragten Vertriebsorganisationen führen ihre Prozesse überwiegend manuell durch, so werden Dokumente mittels Fax oder Post übermittelt und auf Papier abgeheftet. 25 Prozent der Befragten administrieren ihre IT-Systeme selber, obwohl sie nach eigener Einschätzung lediglich geringe oder sogar sehr geringe Kompetenzen auf diesem Gebiet besitzen. Eine Reduzierung derartiger Tätigkeiten soll die Konzentration auf die Kernaufgaben der Vertriebsunternehmen stärken (Spath et al. 2008a). SteigerungDerAussagefähigkeit In vielen der befragten Vertriebsunternehmen liegen Informationen nicht in elektronischer Form vor, so dass nicht über IT-Systeme darauf zugegriffen werden - 101 - kann. So fehlen oft aktuelle (technische) Informationen über die zu vertreibenden Produkte, um diese Kunden besser erklären zu können. Ebenso werden oft Informationen nicht zeitnah aktualisiert, so erhalten Vertriebsunternehmen von ihren Herstellern Dokumente von Geschäftsvorgängen mit einer Verspätung von bis zu vier Wochen. Ein großer Nutzen der Informationsplattform ist die Steigerung der Aussagefähigkeit der Vertriebsunternehmen gegenüber ihren Kunden durch zentrale Datenhaltung und zeitnahe Aktualisierung (Spath et al. 2008a). EffizienzsteigerungDerKernprozesse In diesem Punkt geht es vor allem darum, die Kernprozesse der Vertriebs- unternehmen durch geeignete IT-Unterstützung effizienter zu gestalten. Hierbei spielen die elektronische Datenhaltung, unternehmensübergreifende Unterstützung durch entsprechende IT-Systeme und Schnittstellen zum Informationsaustausch zwischen Vertriebsunternehmen und Herstellern eine Rolle (Spath et al. 2008a). 7.3.4 Distributionskanäle Ergänzend zu den Dienstleistungen muss festgelegt werden, wie die Dienstleistungen vermarktet und vertrieben werden. Hierfür dient das Element des Distributionskanals. Die Ausprägungen wurden basierend auf Speyer et al. (2007) erstellt. Bezeichnung Distributionskanal Definition Mit diesem Element werden die Wege der Vermarktung und des Vertriebs der webbasierten Informationsplattform bestimmt. Pflichtfeld Optional Teil von Dienstleistungsangebot Kardinalität 0-* Attribute Bezeichnung {ABC} Beschreibung {ABC} Marketingkanal {Website, Verband, Fachmagazin, VeranstaltungMesse} Vertriebskanal {EigenerVertrieb, ValueAddedReseller, SystemsIntegrator} BeratungUmsetzung {EigeneBerater, ValueAddedReseller, SystemsIntegrator, IndependantSoftwareVendor} Beziehungen Distributionskanal vertreibt Dienstleistung Tabelle 33: Beschreibung von Distributionskanälen Bezeichnung Dieses Merkmal beinhaltet die Bezeichnung eines Distributionskanals für ein Dienstleistungsangebot oder ein Dienstleistungspaket. - 102 - Beschreibung Dieses Merkmal beinhaltet die Beschreibung des Distributionskanals. Marketingkanal Dieses Merkmal bietet einige Kategorien zur Einordnung eines Marketingkanals. Vertriebskanal Dieses Merkmal bietet einige Kategorien zur Einordnung eines Vertriebskanals. BeratungUmsetzung Dieses Merkmal bietet einige Kategorien zur Einordnung von Kanälen zur Beratung und ggf. Umsetzung der angebotenen Dienstleistungen. 7.3.5 Kundenbeziehung Neben den Dienstleistungen und deren Distributionskanälen muss festgelegt werden, wie die Beziehung zwischen Plattformanbieter mit deren Zielgruppen ausgestaltet wird. Die Merkmale basieren auf Osterwalder (2004). - 103 - Bezeichnung Kundenbeziehung Definition Mit diesem Element wird die Beziehung zu den Zielgruppen festgelegt. Pflichtfeld Optional Teil von Dienstleistungsangebot Kardinalität 0-* Attribute Bezeichnung {ABC} Beschreibung {ABC} Personalisierung {BetreuungDurchKeyAccountManager, inCRMIntegrierterHelpdeskHotline, AnwenderspezifischeWeiterentwicklungDurchBetreiber, AnwenderspezifischeAnpassungDurchDritte} Vertrauen {VertraglichZugesicherteLeistungen, AnwendertageZumErfahrungsaustausch, VeröffentlichungVonBestPracticeCases, Anwenderschulungen, Partnerschulungen, Partnerprogramm, transparentesSicherheitskonzept} Marke {AufbauEinerMarkeFürDieVertriebsplattform, AufbauEinerMarkeFürErweiterungDerPlattformDurchAngeboteDritter, AufbauEinerMarkeFürAngeboteDritterDurchNutzungDerInfrastruktur} AddOnSelling {EntwicklungVonStandardmodulenMitWeitererFunktionalität, AngebotWeitererProduktBegleitenderDienstleistungen, EntwicklungKundenIndividuellerDiensteFunktionalität} Beziehungen Kundenbeziehung betrifft Dienstleistung Tabelle 34: Beschreibung der Kundenbeziehung Bezeichnung Dieses Merkmal beinhaltet die Bezeichnung der Kundenbeziehung zu einem Dienstleistungsangebot bzw. einer Dienstleistung. Beschreibung Dieses Merkmal beinhaltet die Beschreibung der Kundenbeziehung. Personalisierung In diesem Merkmal wird beschrieben, wie eine kundenspezifische Anpassung und Erweiterung der angebotenen Dienstleistungen bzw. des Dienstleistungsangebots ausgestaltet werden. Vertrauen Hiermit werden die vertrauenssteigernden Maßnahmen festgelegt, wie z.B. hohe Ausfallsicherheit der Informationsplattform, hohe Datensicherheit und Reduzierung der Hürden bei möglichen Wechseln des Anbieters. - 104 - Marke Eine Zielsetzung kann darin bestehen, die Informationsplattform und das weiterführende Dienstleistungsangebot als Marke aufzubauen und damit eine Markenbindung der Zielgruppen anzustreben. AddOnSelling Hier werden Maßnahmen beschrieben, die die Weiterentwicklung der Kunden mit der Zielsetzung der Nachfragesteigerung nach weiteren/eigenen Produkten fördern. 7.4 Dienstleistungserstellung Um als IT-Anbieter ein Dienstleistungsangebot anbieten zu können, muss geklärt und festgelegt werden, wie dieses Dienstleistungsangebot erbracht wird. Die Dienstleistungserbringung ist damit dem Dienstleistungsangebot zugeordnet und enthält die Elemente »Dienstleistungsprozess«, »Kompetenzen/Ressourcen« und »Partner«. Diese Elemente basieren auf dem Ansatz der erweiterten Ereignisgesteuerten Prozessketten (eEPK), in denen neben den eigentlichen Prozessabläufen u.a. die Organisations- und Datenmodellierung berücksichtigt werden (Scheer 2006). Bei der Entwicklung der Dienstleistungserstellung müssen daher die folgenden Fragestellungen geklärt werden: ± Welche Prozesse laufen während der Dienstleistungserbringung ab? ± Welche Kompetenzen und Ressourcen werden für den Prozessablauf benötigt? ± Welche Partner (inklusive des eigenen Unternehmens) können die Kompetenzen und Ressourcen erbringen? Zur Strukturierung der Antworten auf diese Fragestellungen findet eine Zuordnung der Antworten auf Organisationsbereiche statt, die bei der Dienstleistungserbringung eine Rolle spielen. Eine Einteilung von Organisationen in primäre und sekundäre Organisationsbereiche basierend auf der Wertschöpfungskette liefert Porter (2000) und wird von Wirtz (2010) weiter detailliert. In Abbildung 17 ist 3RUWHU¶V Wertschöpfungskette aufgeführt. Darüber hinaus wird jeder der Organisations- bereiche auf dessen Bedeutung für die Entwicklung einer webbasierten Informations- plattform untersucht und bewertet. Alle Organisationsbereiche werden in den Elementen der Dienstleistungserbringung aufgeführt, um sie ggf. für einen weiteren Anwendungsfall bzw. auf weitere Anforderungen anzupassen. Allerdings werden die Organisationsbereiche mit geringer Bedeutung für die Entwicklung der webbasierten Informationsplattform nicht weiter detailliert. - 105 - Abbildung 17: Porter's Wertschöpfungskette (Porter 2000) Jeder Zielgruppe wird ein Dienstleistungsangebot zugeordnet. Die Erbringung jedes Dienstleistungsangebots wird in der Dienstleistungserstellung festgelegt, der Dienstleistungsprozesse und Kompetenzen/Ressourcen zugeordnet sind. Beide Elemente können weiteren Elementen der Dienstleistungserstellung zugeordnet werden (siehe Abbildung 18). Abbildung 18: Dienstleistungserstellung Technologieentwicklung z { z z z{ { Beschaffung z { = tendenziell eher geringe Bedeutung im Rahmen des Referenzmodells {z = tendenziell eher hohe Bedeutung im Rahmen des Referenzmodells Dienstleistungserstellung Dienstleistungs- prozess Dienstleistungs- erbringung Kompetenz Ressource Partner benötigt bestehtAus bestehtAus wirdErbrachtVon verursacht erzielt Gewinn Dienstleistungs- angebot Kosten Dienstleistungs- beschreibung Rentabilität Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich - 106 - 7.4.1 Dienstleistungserbringung Dieses Element bildet den Einstieg in die Modellierung der Dienstleistungs- erbringung. Bezeichnung Dienstleistungserbringung Definition Mit diesem Element wird die Erbringung einer Dienstleistung mit Fokus auf einen Prozessablauf sowie dafür benötigte Kompetenzen und Ressourcen modelliert. Pflichtelement Obligatorisch Teil von Dienstleistungserstellung Kardinalität 1-n, wobei n der Anzahl aller notwendigen Variationen der Dienst- leistungserbringung entspricht, die für ein oder mehrere Dienst- leistungsangebote benötigt werden. Attribute Bezeichnung {ABC} Beschreibung {ABC} Beziehungen Dienstleistungsangebot benötigt Dienstleistungserbringung Tabelle 35: Beschreibung der Dienstleistungserbringung Bezeichnung Mit diesem Attribut wird jede Variante einer Dienstleistungserbringung benannt. Beschreibung Dieses Attribut beinhaltet eine Beschreibung der jeweiligen Dienstleistungs- erbringung. - 107 - 7.4.2 Dienstleistungsprozess In diesem Element werden die einzelnen Dienstleistungsprozesse festgelegt, die für ein oder mehrere Dienstleistungsangebote notwendig sind. Bezeichnung Dienstleistungsprozess Definition Festlegung der Dienstleistungsprozesse, die für die Dienstleistungs- erbringung benötigt werden. Pflichtelement Optional Teil von Dienstleistungserstellung Kardinalität 0-* Attribute Bezeichnung {ABC} Beschreibung {ABC} Unternehmensinfrastruktur {Planning_Strategische Planung, Organizing_OrganisierenVonRessourcenUndStrukturen, Staffing_Mitarbeiterauswahl, Directing_HinleitungAufDasZiel, Coordinating_Zusammenspiel, Reporting_Berichtswesen, Budgeting_PlanungDerFinanzen} PersonalentwicklungVerwaltung { } Technologieentwicklung {EntwicklungNeuerServices, OptimierungBestehenderServices, Fehlerkorrekturen, KundenspezifischeAnpassungen, TestenVonSoftwareentwicklungen} Beschaffung { } Eingangslogistik { } Operationen {BereitstellungNeuerServices, AdministrationDerServices, Sicherheitsmanagement, EinführungsunterstützungSchulungen, ProfessionalServices} Ausgangslogistik { } MarketingVertrieb {PlanungUndDurchführungVonPublicRelations, PlanungUndDurchführungVonWerbung, PlanungUndDurchführungVonAktionenEvents, AkquiseBetreuungVonKundenInteressentenDurchAußendienst, AkquiseBetreuungVonKundenInteressentenDurchInnendienst} Kundendienst {FirstLevelSupport, SecondLevelSupport, ThirdLevelSupport} Beziehungen Dienstleistungserbringung bestehtAus Dienstleistungsprozess Tabelle 36: Beschreibung von Dienstleistungsprozessen - 108 - Bezeichnung Dieses Merkmal benennt den jeweiligen Dienstleistungsprozess. Beschreibung Hiermit wird jeder einzelne Dienstleistungsprozess inhaltlich beschrieben. Die nachfolgenden Merkmale stellen Prozesskategorien für die Einteilung der benötigten Dienstleistungsprozesse bereit. Sie dienen als Unterstützung bei der Identifizierung der für die webbasierte Informationsplattform relevanten Prozesse. Die Prozesskategorien besitzen vorschlagenden Charakter und sollten beim Auftreten neuer Anforderungen erweitert werden. 7.4.3 Kompetenz und Ressource In diesem Element werden die für die oben definierten Dienstleistungsprozesse benötigten Kompetenzen und Ressourcen aufgeführt und kategorisiert. Ressourcen sind dabei alle Mittel, die in die Erstellung von Dienstleistungen eingehen (Gabler 2010). Osterwalder (2004) unterscheidet zwischen drei verschiedenen Ressourcenarten: Tangible (materielle), intangible (immaterielle) und Human Resources. Bei der Betrachtung von Kompetenzen unterscheidet Weisbecker (2002) vier unterschiedliche Kompetenzarten, die in Tabelle 37 aufgeführt sind. - 109 - Fachliche Kompetenz Berufsbedingt erworbene Qualifikationen und Erfahrungen sowie das fachspezifische und fachübergreifende Wissen. ± Projektmanagement ± Software-Entwicklung ± Qualitätsmanagement ± Konfigurations- management ± Systemmanagement ± Wiederverwendung ± Kaufmännischer Bereich Methodische Kompetenz Fähigkeit, das Fachwissen zu nutzen, zu kombinieren und zu ergänzen. ± Projektmanagement ± Software-Entwicklung ± Qualitätsmanagement ± Konfigurations- management ± Systemmanagement ± Wiederverwendung ± Kaufmännischer Bereich ± Organisation Soziale Kompetenz Umfasst die persönlichen Ausprägungen bzw. Grundverhaltensmuster und unter- scheidet zwei Ausprägungen: ± Kompetenz im Umgang mit anderen Personen, wie z.B. Teamfähigkeit und Kooperationsfähigkeit, ± rein auf die eigene Person bezogene Kompetenz. ± Intrapersonale Kompetenz ± Interpersonale Kompetenz Medien- kompetenz Nutzung von Informations- und Kom- munikationstechnologien (Beschaffung, Aufbereitung und Darstellung) sowie das Filtern von Informationen nach deren Wichtigkeit sowie Beherrschung verschie- dener Medien. ± Informationsbeschaffung ± Informationsaufbereitung ± Informationsdarstellung ± Wissensmanagement Tabelle 37: Vier Kompetenzarten und deren Qualifikationsanforderungen(Weisbecker 2002) Diese vier Kompetenzarten unterstützen die relevanten Aktivitäten einer Unternehmung (siehe Abbildung 17). Daher findet im Element KompetenzRessource eine Zuordnung zu den relevanten Aktivitäten statt. - 110 - Bezeichnung KompetenzRessource Definition Festlegung der Kompetenzen und Ressourcen, die für die Dienstleistungserbringung benötigt werden. Pflichtelement Obligatorisch Teil von Dienstleistungserstellung Kardinalität 1-n, wobei n der Anzahl aller für die Umsetzung und den Betrieb einer webbasierten Informationsplattform benötigten Kompetenzen und Ressourcen entspricht Attribute Bezeichnung {ABC} Beschreibung {ABC} Unternehmensinfrastruktur { AllgemeineOrganisation, IuKInfrastruktur, Geschäftsräume} PersonalentwicklungVerwaltung { } Technologieentwicklung {KnowHowITArchitektur, KnowHowProgrammierung, KnowHowTesten} Beschaffung { } Eingangslogistik { } Operationen {Rechenzentrum, KnowHowITAdministration, KnowHowITSicherheit, KnowHowSchulung} Ausgangslogistik { } MarketingVertrieb {KnowHowMarketing, KnowHowDesign, KnowHowVertrieb, Fuhrpark} Kundendienst {KnowHowKundenansprache} Beziehungen Dienstleistungserbringung bestehtAus KompetenzRessource KompetenzRessource verursacht Kosten KompetenzRessource wirdErbrachtVon Partner Tabelle 38: Beschreibung von Kompetenzen und Ressourcen Bezeichnung Dieses Merkmal benennt die benötigte Kompetenz bzw. Ressource. Beschreibung Hiermit wird die jeweilige Kompetenz und Ressource inhaltlich beschrieben. Die nachfolgenden Merkmale stellen Kategorien zur Einteilung der benötigten Kompetenzen und Ressourcen bereit. Sie dienen als Unterstützung bei der Identifizierung der für die webbasierte Informationsplattform relevanten Kompetenzen - 111 - und Ressourcen. Die Kategorien besitzen vorschlagenden Charakter und sollten beim Auftreten neuer Anforderungen erweitert werden. 7.5 Partner Dieses Element ermöglicht die Bestimmung und Beschreibung von Partnern, die sich an der Entwicklung und Bereitstellung der Informationsplattform beteiligen. Jeder Kompetenz bzw. Ressource wird ein Partner zugeordnet, der diese bereitstellt bzw. in das Konsortium einbringt. Bezeichnung Partner Definition Festlegung der Kompetenzen und Ressourcen, die für die definierten Dienstleistungsprozesse benötigt werden. Pflichtelement Obligatorisch Teil von Dienstleistungserstellung Kardinalität 1-n, wobei n der Anzahl aller involvierten Partner entspricht Attribute Bezeichnung {ABC} Beschreibung {ABC} Beziehungen KompetenzRessource wirdErbrachtVon Partner Partner erzielt Gewinn Tabelle 39: Beschreibung von Partnern Tapscott et al. (2000) differenzieren zwischen 5 Wertschöpfungsnetzwerke (Value Networks) mit unterschiedlichen Integrationsgrad der Wertschöpfung und Intensität der Netzwerkkontrolle (siehe Abbildung 19). Abbildung 19: 5 Typen von Wertschöpfungsnetzwerken (Tapscott et al. 2000) Agora Aggregation Distributive Network Alliance Value Chain Value Integrationlow high C on tr ol - 112 - Tapscott et al. (2000) und Stähler beschreiben die 5 Wertschöpfungsnetzwerke wie folgt: Agora: Umwandlung von Gütern zu einem gewünschten Preis in Geld und umgekehrt. Das Netzwerk unterstützt den Geschäftsverkehr zwischen Verkäufer und Käufer, die direkte Preisverhandlungen darüber durchführen (z.B. eBay). Aggregation: Optimierung des Angebots, der Organisation, des Preises, der Convenience und der Abwicklung. Ein dominierendes Unternehmen positioniert sich als Intermediär zwischen Hersteller und deren Kunden (z.B. Amazon). Value Chain: Design und Lieferung eines integrierten Produktes oder Dienst- leistungen nach spezifischen Kundenanforderungen. Ein Anbieter organisiert und lenkt eine Wertschöpfungskette zur gemeinsamen, hoch integrierten Erstellung von Produkten bzw. Dienstleistungen (z.B. Dell). Alliance: Kreative Zusammenarbeit zum Erreichen eines gemeinsamen Ziels. Ein Wertschöpfungsnetzwerk mit hohem Integrationsgrad und geringer zentraler Kontrolle (z.B. Linux). Distributive Network: Erleichtern des Austauschs von Informationen, Gütern und Dienstleistungen (z.B. FedEx). Osterwalder (2004) gibt drei Gründe an, warum Partner in ein Geschäftsmodell eingebunden werden: ± Optimierung und Nutzung von Skaleneffekten, ± Reduzierung von Risiken und Unsicherheiten und ± Einkauf von Ressourcen. Bezeichnung Dieses Merkmal enthält den Namen des Partner(-unternehmens). Beschreibung Hiermit wird der jeweilige Partner detaillierter beschrieben. Die nachfolgenden Merkmale stellen Kategorien zur Einteilung der Partner bereit. Sie dienen als Unterstützung bei der Identifizierung und Einordnung der für die webbasierte Informationsplattform relevanten Partner. Die Kategorien besitzen vorschlagenden Charakter und sollten beim Auftreten neuer Anforderungen erweitert werden. - 113 - 7.6 Rentabilität Um die Eignung des Geschäftsmodells festzustellen, müssen die finanziellen Aspekte erarbeitet und verglichen werden. Zielsetzung bei der Modellierung der finanziellen Aspekte ist: ± Abschätzung der Kosten, die je Partner des Konsortiums für die Bereitstellung und Nutzung von Ressourcen und Kompetenzen verursacht werden; ± Abschätzung der Erlöse, die durch die angebotenen Dienstleistungen bzw. Dienstleistungspakete erwirtschaftet werden; ± Aufteilung der Erlöse auf die beteiligten Partner des Konsortiums; ± Ermittlung des Gewinns je Partner des Konsortiums. Hierfür werden zwei einfache und transparente Verfahren der statischen Investitionsrechnung herangezogen: Die Gewinnvergleichs- und die Rentabilitäts- rechnung. Zur Gewinnberechnung von Investitionen nennt Westkämper (2006) folgende Formel: Des Weiteren führt Westkämper (2006) zur Berechnung der Rentabilität folgende Formel auf: In Abbildung 20 werden die Elemente und deren Zusammenhänge aus Sicht der Rentabilität aufgeführt. - 114 - Abbildung 20: Rentabilität 7.6.1 Kosten In diesem Element ist die Abschätzung der Kosten hinterlegt, die für die Bereitstellung und Nutzung einer Ressource bzw. Kompetenz von einem Partner voraussichtlich erbracht werden müssen. Wöhe und Döring (2010) definieren Kosten als »in Geld bewertete Mengen an Produktionsfaktoren (Arbeitsleistungen, Betriebsmittel und Werkstoffe) sowie in Geld bewertete Dienstleistungen Dritter und öffentliche Abgaben, die bei der Erstellung betrieblicher Leistungen verbraucht werden«. Rentabilität Erlös Gewinn Kostenbeeinflusst beeinflussen Dienstleistung Partner KompetenzRessource erzielt verursachterzielt Dienstleistungserstellung Dienstleistungsbeschreibung Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich - 115 - Bezeichnung Kosten Definition Geschätzte Kosten in Euro pro Jahr für die Bereitstellung und Nutzung einer Ressource oder Kompetenz. Pflichtelement Obligatorisch Teil von Finanzielle Aspekte Kardinalität 1-* Attribute Beschreibung {ABC} Kosten {123} Wiederkehrend {einmalig, wiederkehrend} Beziehungen KompetenzRessource verursacht Kosten Kosten beeinflussen Gewinn Tabelle 40: Beschreibung der Kosten In Abbildung 21 führt Brugger (2005) die zeitliche und sachliche Abgrenzung zur Differenzierung der Kostenkategorien auf. Dabei entstehen bei einer IT-Investition einmalige Kosten in der Projektphase (Investitionskosten) und laufende Kosten in der Betriebsphase (Betriebskosten). Abbildung 21: Zeitliche und sachliche Abgrenzung zur Kostendifferenzierung (Brugger 2005) Jeder Ressource bzw. Kompetenz werden Kosten zugeordnet, die ein Partner für deren Bereitstellung bzw. Nutzung erbringen muss. Die Höhe der Kosten wird von den jeweiligen Partnern abgeschätzt, die die Kompetenz bzw. Ressource bereitstellen. Beschreibung Die Beschreibung enthält Details über die Gründe und die Zusammensetzung der Kosten. Investitionskosten (Projektphase) Betriebskosten (Betriebsphase) Kostenkategorien hinsichtlich des zeitlichen Anfalls Externe Kosten - Software-Kosten - Hardware-Kosten - Dienstleistungskosten Interne Kosten - Personalkosten - Infrastrukturkosten Kostenkategorien hinsichtlich der sachlichen Abgrenzung - 116 - Kosten Dieses Attribut beinhaltet eine Abschätzung der Kosten für die Bereitstellung und Nutzung einer Ressource und Kompetenz. Wiederkehrend Mit diesem Attribut wird festgehalten, ob Kosten für die Bereitstellung einer Kompetenz bzw. Ressource einmalig oder wiederkehrend im Betrachtungszeitraum nt (in Jahren) auftreten. Treten Kosten einmalig auf, muss der Betrag auf ein Jahr heruntergebrochen werden: 7.6.2 Erlös Erlöse werden über den Verkauf von Dienstleistungen erzielt. Im Modell können daher jeder Dienstleistung Erlöse zugeordnet werden. Bezeichnung Erlös Definition Über den Vertrieb von Dienstleistungen werden von dem Konsortium Erlöse erzielt. Pflichtelement Obligatorisch Teil von Finanzielle Aspekte Kardinalität 1-* Attribute Beschreibung {ABC} Erlös {123} Wiederkehrend {einmalig, wiederkehrend} Beziehungen Dienstleistung erzielt Erlös Erlös beeinflusst Gewinn Tabelle 41: Beschreibung Erlös Einer Dienstleistung können ein oder mehrere Preismodelle zugrundeliegen. Lehmann und Buxmann (2009) stellen eine Übersicht von Preismodellen für Softwareprodukte vor. Ebenso gehen Lehmann und Buxmann (2009) auf relevante Parameter ein, die die Erstellung von Preismodellen charakterisieren (siehe Tabelle 42) und als Grundlage für die Entwicklung eigener Preismodelle für Dienste und Dienstleistungen eines Geschäftsmodells dienen können. Einer Dienstleistung werden im Geschäftsmodell alle Erlöse zugeordnet, die mit diesem Dienst bzw. dieser Dienstleistung mit einem oder mehreren Preismodellen erzielt werden sollen. - 117 - Preisbildung Struktur des Zahlungs- stroms Bemessungs- grundlage Preis- differen- zierung Preis- bündelung Dynamische Preisstrategie Preis- ermittlung Kostenbasiert Nachfrage- orientiert/wert- basiert wettbewerbs- orientiert Interaktions- grad einseitig, nicht interaktiv interaktiv Einmal- zahlung Regelmäßig wieder- kehrende Zahlungen Frequenz Dauer Hybride Form Anzahl Preiskompo- nenten nutzungs- abhängig Transaktion Speicher- bedarf Zeit « nutzungs- unabhängig Named User Concurrent User Server, Rechner CPU Finanz- kennzahlen « 1. Grad 2. Grad mengen- bezogen zeit- bezogen leistungs- bezogen 3. Grad personen- bezogen regionen- bezogen Angebot reine Bündelung gemischte Bündelung Entbündelung Produktart Software Wartung Service/ Support Integrations- grad komplementär substitutiv unabhängig Preishöhe additiv superadditiv subadditiv Penetrations- strategie Follow-the- free- Strategie Skimming- Strategie Tabelle 42: Parameter von Preismodellen für Softwareprodukte (Lehmann und Buxmann 2009) Beschreibung Die Beschreibung enthält Details über die Gründe und die Zusammensetzung der Erlöse. Erlös Dieses Attribut beinhaltet eine Abschätzung des Erlöses, der beim Verkauf einer Dienstleistung vom Konsortium erzielt wird. - 118 - Wiederkehrend Mit diesem Attribut wird festgehalten, ob ein Erlös für eine Dienstleistung einmalig oder wiederkehrend im Betrachtungszeitraum nt (in Jahren) auftritt. Tritt ein Erlös einmalig auf, muss der Betrag auf ein Jahr heruntergebrochen werden: 7.6.3 Gewinn Um die Profitabilität der Investitionen in das Geschäftsmodell je beteiligtem Partner zu untersuchen, werden Erlös und Kosten je Partner gegenübergestellt und der Gewinn berechnet. Mit der Ermittlung der Rentabilität wird der Gewinn je Partner noch in Bezug zu den jeweiligen Kosten je Partner betrachtet. Bezeichnung Gewinn Definition Je Partner wird die Rentabilität ihres eingebrachten Kapitals berechnet. Pflichtelement Obligatorisch Teil von Finanzielle Aspekte Kardinalität 1-* Attribute Betrachtungszeitraum nt (Anzahl in Jahren) {123} Durchschnittliche Kosten Kp je Partner pro Jahr ¼-DKU ^` Erlösanteil EAp je Partner (%) {123} Durchschnittlicher Erlös Ep je Partner pro Jahr ¼-DKU ^` Durchschnittlicher Gewinn Gp je Partner pro Jahr ¼-DKU ^` Kalkulatorische Zinsen Pp je Partner pro Jahr ¼-DKU ^` Rentabilität Rp je Partner pro Jahr (%/Jahr) {123} Beziehungen Partner erzielt Gewinn Tabelle 43: Beschreibung Gewinn Betrachtungszeitraum nt (Anzahl in Jahren) Dieses Attribut legt den Betrachtungszeitraum der Investition in Anzahl Jahren fest. - 119 - Durchschnittliche Kosten Kp je Partner pro Jahr ¼-DKU Die durchschnittlichen Kosten je Partner ist die Summe aller Kosten, die zur Bereitstellung von Ressourcen und Kompetenzen voraussichtlich von jedem Partner aufgebracht wird: Erlösanteil EAP je Partner (%) Dies ist der Anteil, den ein Partner eines Konsortiums für seine Beteiligung bei der Entwicklung und Bereitstellung der webbasierten Informationsplattform erhält. Zur Vereinfachung wird der Erlösanteil je Partner auf den gesamten Erlös angewendet und wird nicht auf Erlösebene je Dienstleistung festgelegt. In Kapitel 8 wird darauf eingegangen, wie bei der Festlegung des Erlösanteils vorgegangen werden kann. Durchschnittlicher Erlös Ep je Partner pro Jahr ¼-DKU Der voraussichtlich durchschnittliche absolute Erlös je Partner pro Jahr ergibt sich somit aus dem Erlösanteil, angewendet auf die Summe aller Erlöse (Gesamterlös): Durchschnittlicher Gewinn EGp je Partner pro Jahr ¼-DKU Zur Ermittlung des durchschnittlichen absoluten Gewinns eines Partners pro Jahr werden die durchschnittlichen Erlöse den Kosten je Partner gegenübergestellt: Kalkulatorische Zinsen Pp je Partner pro Jahr ¼-DKU Um anschließend die reine Rentabilität RP zu berechnen, werden die kalkulatorischen Zinsen benötigt. Die kalkulatorischen Zinsen sind diejenigen Zinsen, die ein Partner erhalten hätte, wenn er den Betrag anderweitig angelegt hätte. Unter Einbeziehung der kalkulatorischen Zinsen wird nur die wirkliche Rentabilität der Beteiligung im Konsortium ermittelt, abzüglich der Zinserträge, die er durch eine anderweitige Anlage des Geldbetrags erzielt hätte (Westkämper 2006). - 120 - Rentabilität Rp je Partner pro Jahr (%/Jahr) Die Rentabilität RP der Beteiligung eines Partners am Konsortium ergibt sich somit wie folgt: 8 Methodische Hinweise zur Nutzung des Referenzmodells Bei der Anwendung des Referenzmodells wird davon ausgegangen, dass mehrere Partner sich in einem Konsortium zusammenschließen, um die webbasierte Informationsplattform anzubieten. Beim Zusammenfinden der Partner werden diese je nach deren Kompetenzen und Ressourcen eingebunden, die sie zur Erbringung des Dienstleistungsangebots im Rahmen der webbasierten Informationsplattform beitragen. Dabei werden zwei alternative Ausgangssituationen unterschieden: ± Ein starker Partner/Initiator, der das Geschäftsmodell aus seiner Sicht modelliert und je nach fehlender Kompetenz bzw. Ressourcen entsprechende Partnerunternehmen hinzuzieht. ± Mehrere gleichberechtigte/homogene Partner, die das Geschäftsmodell gemeinsam entwickeln und somit das Modell als Diskussionsgrundlage für ihre jeweilige strategische Ausrichtung heranziehen. Im nachfolgenden Abschnitt wird zuerst auf das zweite Szenario eingegangen und anschließend die Unterschiede zum ersten Szenario aufgezeigt. Abbildung 22: Phasenmodell zur methodischen Anwendung des Referenzmodells Festlegung geeigneter Zielgruppensegmente Ableitung segmentspezifischer Dienstleistungsangebote (Zusammensetzung von Dienstleistungskomponenten) Festlegung benötigter Ressourcen und Kompetenzen zur Erbringung der Dienstleistungsangebote Kalkulation der nachhaltigen finanziellen Tragfähigkeit des Geschäftsmodells n Phase o Phase p Phase r Phase Zuordnung von Partnern zu benötigten Ressourcen und Kompetenzenq Phase - 122 - In Abbildung 22 wird ein Phasenmodell dargestellt, das die Vorgehensweise bei der Anwendung des Referenzmodells verdeutlicht. Dieses ist in die folgenden fünf Phasen eingeteilt: 1. Einteilung Zielkundensegmente: In dieser Phase werden die für das zu modellierende Geschäftsmodell relevanten Zielgruppen eingeteilt. Wichtig hierbei ist eine möglichst homogene Segmentierung der Zielgruppen hinsichtlich ihrer Anforderungen an ein konkretes Dienstleistungsangebot. 2. Ableitung segmentspezifischer Dienstleistungsangebote: Auf der Grundlage der eingeteilten Zielgruppensegmente werden Dienstleistungsangebote festgelegt. Bezugnehmend auf die webbasierte Informationsplattform bedeutet dies z. B. konkrete Funktionen, die einer Zielgruppe angeboten werden. Neben den konkreten Dienstleistungsangeboten wird auch der Nutzen herausgearbeitet, um insbesondere den Kundennutzen von einer Dienstleistung transparent kommunizieren zu können. 3. Festlegung benötigter Ressourcen und Kompetenzen: Sind die Dienst- leistungen bekannt, können daraus die Dienstleistungsprozesse sowie die benötigten Ressourcen und Kompetenzen abgeleitet werden. Die Ressourcen können materieller (z. B. Hardware und Netzwerke) und immaterieller (z. B. Lizenzen und Patente) Natur sein. Kompetenzen (z. B. Administration und Programmierung) sind notwendig, um Schritte der Dienstleistungsprozesse ausführen zu können. 4. Zuordnung von Partnern: In dieser Phase werden Kooperationspartnern die benötigten Ressourcen und Kompetenzen zugeordnet. 5. Kalkulation der finanziellen Tragfähigkeit: Um die finanzielle Tragfähigkeit des Geschäftsmodells zu ermitteln, werden in dieser Phase die Kosten und Erlöse für die Bereitstellung von Ressourcen und die Einbringung von Kompetenzen in den Dienstleistungserstellungsprozess je Partner untersucht. Für jeden einzelnen Partner wird die Rentabilität ihrer Beiträge berechnet. Der Anteil eines jeden Partners am Gesamterlös wird anhand verschiedener Kriterien verteilt, wie z.B. strategische Bedeutung eingebrachter Kompetenzen und Ressourcen sowie der jährlichen Kosten pro Partner bei deren Bereitstellung. Besitzt ein Konsortium einen starken Partner/Initiator, dann wird der Initiator den Ressourcen und Kompetenzen erstmals Stellen im eigenen Unternehmen zuordnen. Bei denjenigen Ressourcen und Kompetenzen, die nicht durch unternehmenseigene Stellen abgedeckt werden können, wird eine Bereitstellung durch Partnerunter- nehmen geprüft. Hierzu werden dann den Partnern wieder wie oben beschrieben Ressourcen und Kompetenzen zugeordnet. 9 Umsetzung des Referenzmodells 9.1 Anwendungsbeispiel Das Referenzmodell wurde mit einem Konsortium von 4 Kooperationspartnern ± einem Spezialisten auf dem Gebiet SaaS-CRM (PA1), einem Plattformbetreiber (PA2), einem Anbieter von IT-Systemen zum Produktinformationsmanagement (PA3) sowie einem Unternehmen mit Kernkompetenz in IT-Sicherheit (PA4) ± beispielhaft genutzt, um ein gemeinsames Geschäftsmodell für eine webbasierte Informations- plattform für Handelsvertreter, -vermittler und Hersteller zu entwickeln. Die einzelnen Elemente und deren Merkmalsausprägungen sind im Anhang E für das Anwendungsbeispiel aufgeführt. Dabei ist Partner PA1 der dominante Partner im Netzwerk, der das hauptsächliche Risiko trägt und die Plattform initiiert. Entsprechend liegen viele zentrale Aufgaben des Konsortiums bei ihm. Das im Folgenden aufgeführte Geschäftsmodell stellt eine erste Version der Plattform dar, die für jeden der beteiligten Partner einen Gewinn erzielt und im weiteren Verlauf weiter ausgebaut werden kann. Die angegebenen Zahlen sind Schätzwerte. In Abbildung 23 ist eine Übersicht der modellierten Elemente des Geschäftsmodells dargestellt. Die festgelegten Attribute der jeweiligen Elemente sind im Anhang C aufgeführt. Legende zu Abbildung 23: Beziehung zwischen zwei Elementen Obligatorisches Element Optionales Element Geschäftsmodell- bereich ZG = Zielgruppe; ZOrg = Zielgruppe Organisation; ZProd = Zielgruppe Produkte; ZProz = Zielgruppe Prozesse; ZITInf = Zielgruppe IT-Infrastruktur; DA = Dienstleistungsangebot; DL = Dienstleistung; NU = Nutzen; DK = Distributionskanäle; KB = Kundenbeziehung; DE = Dienstleistungserbringung; DP = Dienstleistungsprozess; KR = KompetenzRessource; PA = Partner; KO = Kosten; ER = Erlös; GE = Gewinn - 124 - Abbildung 23: Konkretes Geschäftsmodell für ein Netzwerk von 4 Partnern Im vorliegenden Anwendungsbeispiel wurde von den Partnern ein Geschäftsmodell entwickelt, das insbesondere für die Zielgruppen, kleine Handelsvertretungen (ZG1) sowie Hersteller (ZG2), Dienste und Dienstleistungen (DL1-4) einer webbasierten Informationsplattform anbietet. Nachfolgend die Beschreibungen der kleinen ZG1 DA1 DL1 DL2 erhält DE1 bestehtAus DE2 PA2 wird Erbracht Von ZOrg1 ZProd1 ZProz1 ZITInf1 KB1 DK1 NU1 besitzt besitzt besitzt besitzt bestehtAus bestehtAus NU2 bestehtAus bestehtAus ZG2 DA2 DL3 DL4 erhält ZOrg2 ZProd2 KB2 DK2 NU3 bestehtAus bestehtAus NU4 bestehtAus besitzt DP1 DP2 DP3 DP4 DP5 DP6 DP7bestehtAus KR2 KR6 KR3 KR4 KR5 bestehtAusbestehtAus PA1 PA3 PA4 KR1 wird Erbracht Von wird Erbracht Von KO2 KO3 KO4 KO5 KO6 KO7 KO8 KO9KO1 GE1 GE2 GE3 GE4 verursacht verursacht verursacht erzielt erzielterzielt erzielt ER1 ER2 erzielt erzielt beeinflusst beeinflusst Dienstleistungserstellung Dienstleistungsangebot Zielgruppen Finanzielle Aspekte ER3 ER4 beeinflusst beeinflusst verursacht wird Erbracht Von benötigt benötigt beeinflusst beeinflusst beeinflusst beeinflusst bestehtAus - 125 - Handelsvertretungen (ZG1) als erste Zielgruppe im Rahmen des Geschäfts- modellbeispiels und das auf diese Zielgruppe zugeschnittene Dienstleistungs- angebot: Kurzz. Bezeichnung Beschreibung ZG1 Kleine Handels- vertretungen Handelsvertretungen mit bis zu 5 Mitarbeitern, die aktuell eine unzureichende IT-Infrastruktur und damit eine geringe IT-Unterstützung ihrer Vertriebsprozesse besitzen. Die Handelsvertretungen sollten möglichst mehr als fünf Hersteller vertreten, um insbesondere die Vorteile der Multilieferantenfähigkeit der webbasierten Informationsplattform nutzen zu können. DA1 PremiumSalesService (Angebot) Der Zielgruppe wird eine webbasierte, mobile IT- Unterstützung ihrer Vertriebsprozesse angeboten. Die Administration wird vom Plattform-Anbieter durch- geführt, um Kunden diesbezüglich zu entlasten, so dass sie sich auf ihre eigentlichen Kernkompetenzen konzentrieren können. Unterstützt wird die Integration in bestehende Backendsysteme der Zielgruppe und Herstellern, wie z.B. ERP, CRM und PIM. Tabelle 44: Erste Zielgruppe und deren Dienstleistungsangebot Es werden zwei Pakete an Diensten und Dienstleistungen (DL1 und DL2) unterschieden, die je Paket folgenden Nutzen (NU1 und NU2) für die Zielgruppe der kleinen Handelsvertretungen (ZG1) bieten: Kurzz. Bezeichnung Beschreibung DL1 BasicSalesPackage Grundlegende Funktionen, die zentrale Vertriebs- prozesse der Zielgruppe unterstützen. Die Administration wird vom Plattform-Anbieter durchge- führt. Dieser stellt darüber hinaus eine 24/7-Hotline zur Verfügung, an die sich Kunden jederzeit wenden können. Nach Vertragsabschluss zwischen Kunde und Plattform-Anbieter findet ein Beratungsgespräch statt, in dem die Anforderungen an die Funktionen der Plattform aufgenommen werden und diese entsprechend konfiguriert wird. Die Innovation dieser Dienstleistung steckt zum einen in der multilieferantenfähigen IT-Untersützung der Vertriebsprozesse der Zielgruppe und zum anderen in der Bereitstellung der Funktionalität über das Internet der Dienste. - 126 - NU1 Der Nutzen des BasicSalesPackage liegt insbesondere darin, dass sich der Kunde auf seine Kernkompetenzen als Handelsvertreter konzentrieren kann. Tätigkeiten, die mit der Administration von IT- Systemen oder der manuellen Bearbeitung von Vertriebsinformationen an mehrere Hersteller zusammenhängen, werden reduziert. DL2 IntegrationSalesPackage Zusätzlich zu dem oben aufgeführten BasicSales- Package können Kunden das IntegrationSales- Package beauftragen. Hier werden die für sie und ihre Hersteller relevanten Schnittstellen zu Backend- systemen, wie ERP, CRM und PIM, aufgenommen und realisiert. Im Rahmen der webbasierten Informationsplattform sollen Standardschnittstellen zu häufig genutzten Backendsystemen angeboten und auf diese Weise die Integration zunehmend vereinfacht werden. NU2 Der Nutzen des IntegrationSalesPackage besteht in der Reduzierung von Tätigkeiten, die mit der manuellen Pflege von Vertriebsinformationen zusammenhängen. Durch die Integration von Backendsystemen auf Seiten der Hersteller und ggf. auch Handelsvertretern werden die Vertriebs- informationen direkt mit der webbasierten Infor- mationsplattform ausgetauscht. Darüber hinaus steigert dies die Aktualität der Vertriebsinformationen und damit auch die Aussage- fähigkeit der Handelsvertreter bei Kunden vor Ort. Ebenso kommt die multilieferantenfähige IT- Unterstützung der Vertriebsprozesse durch den automatisierten Versand von Informationen noch stärker zum Tragen als beim reinen BasicSales- Package. Tabelle 45: Dienstleistungspakete und deren Nutzen für die erste Zielgruppe - 127 - Die Dienstleistungen (DL1 und DL2) für kleine Handelsvertretungen werden über einheitliche Distributionskanäle angeboten und vertrieben. Dabei wird eine intensive Kundenbeziehung angestrebt: Kurzz. Bezeichnung Beschreibung DK1 Ausgewogener Ver- triebsmix für Handels- vertreter Zentrale Ansprache der Zielgruppe, die aus vielen sehr kleinen Handelsvertretungen besteht, erfolgt über einen Multiplikator, wie z.B. einem Verband, in dem viele der Handelsvertretungen organisiert sind. Flankiert wird diese Ansprache mit Informationen im Internet, Fachmagazinen und Veranstaltungen. Der Vertrieb sowie die Beratung und Umsetzung wird zu Beginn eigenständig durch das Konsortium durch- geführt, wobei sukzessive Partner, wie ValueAdded- Reseller aufgebaut werden sollen. KB1 Intensive Kunden- bindung Die Zielgruppe wird rundum betreut. Dies erfolgt durch eine Hotline mit CRM-Unterstützung und durch abgestimmte Weiterentwicklung der Plattform gemäß Kundenanforderungen. Zentrales Element ist das transparente Sicherheits- konzept, um das Vertrauen der Zielgruppe aufzu- bauen. Da die Plattform die zentralen Vertriebs- prozesse der Handelsvertreter unterstützt, würde ein Ausfall der Plattform die Aktivitäten der Kunden stark einschränken. Die webbasierte Informationsplattform soll als Marke aufgebaut und damit sollen auch die Besonderheiten und Alleinstellungsmerkmale herausgestellt werden. Tabelle 46: Distributionskanäle und angestrebte Kundenbeziehung zur ersten Zielgruppe - 128 - Nachfolgend die Beschreibungen der Hersteller (ZG2) als zweite Zielgruppe im Rahmen des Geschäftsmodellbeispiels und das auf diese Zielgruppe zugeschnittene Dienstleistungsangebot:  Kurzz. Bezeichnung Beschreibung ZG2 Hersteller Die zweite Zielgruppe der webbasierten Informations- plattform sind Hersteller, die ihren Vertrieb über Handelsvertreter organisieren. DA2 SupplierPremiumService (Angebot) Um Vertriebsinformationen, wie z.B. Bestellungen, seitens der Hersteller schnellst möglich weiterleiten zu können, ist es notwendig deren IT-Systeme mit den darin verwalteten Vertriebsinformationen in die webbasierte Informationsplattform zu integrieren. Tabelle 47: Zweite Zielgruppe und deren Dienstleistungsangebot - 129 - Es werden zwei Pakete an Diensten und Dienstleistungen (DL3 und DL4) unterschieden, die je Paket folgenden Nutzen (NU3 und NU4) für die Zielgruppe der Hersteller (ZG2) bieten: Kurzz. Bezeichnung Beschreibung DL3 SupplierIntegration- Package PIM Um Herstellern ohne PIM-System die Möglichkeit zu geben Produktinformationen trotzdem elektronisch zur Verfügung zu stellen, werden entsprechende Funktionen zur Eingabe und Pflege webbasiert sowie Schnittstellen zu bestehenden PIM-Systemen bereitgestellt. Mit dem Angebot sollen insbesondere kleinere Hersteller in die Lage versetzt werden, sich an der Informationsplattform zu beteiligen. Daher werden die Funktionen zu marktüblichen Preisen angeboten. NU3 Der Nutzen des SupplierIntegrationPackage PIM liegt insbesondere darin, dass der Handelsvertreter aktuelle Produktinformationen erhält und auf diese Weise Kunden besser informieren kann. DL4 SupplierIntegration- Package ERP Zusätzlich zu dem oben aufgeführten Supplier- IntegrationPackage PIM können Kunden das SupplierIntegrationPackage ERP beauftragen. Hier werden die für sie und ihre Hersteller relevanten Schnittstellen zu Backendsystemen, wie ERP bzw. Warenwirtschaft aufgenommen und realisiert, die bei der Abwicklung von Aufträgen unterstützen. NU4 Der Nutzen des SupplierIntegrationPackage ERP besteht in der Reduzierung von Tätigkeiten, die mit der manuellen Pflege von Vertriebsinformationen zusammenhängen. Durch die Integration von Backendsystemen auf Seiten der Hersteller und ggf. auch Handelsvertretern werden die Vertriebs- informationen direkt mit der webbasierten Informationsplattform ausgetauscht. Darüber hinaus steigert dies die Aktualität der Vertriebsinformationen und damit auch die Aussagefähigkeit der Handelsvertreter bei Kunden vor Ort. Tabelle 48: Dienstleistungspakete und deren Nutzen für die zweite Zielgruppe Die Dienstleistungen (DL3 und DL4) für Hersteller werden über einheitliche Distributionskanäle angeboten und vertrieben. Dabei wird eine intensive Kundenbeziehung angestrebt: - 130 - Kurzz. Bezeichnung Beschreibung DK2 Ausgewogener Vertriebsmix für Hersteller Die Ansprache der Zielgruppe der Hersteller erfolgt überwiegend über Handelsvertreter. Handelsvertreter, die die Informationsplattform nutzen (wollen), werden motiviert ihre Hersteller anzusprechen, sich ebenso zu beteiligen. Ziel ist dabei, die Nutzenpotenziale der Plattform weitestgehend zu realisieren. Flankiert wird diese Ansprache mit Informationen im Internet, Fachmagazinen und Veranstaltungen. Der Vertrieb sowie die Beratung und Umsetzung wird zu Beginn eigenständig durch das Konsortium durch- geführt, wobei sukzessive Partner, wie ValueAdded- Reseller aufgebaut werden. KB2 Intensive Kunden- bindung Die Zielgruppe wird rundum betreut. Dies erfolgt durch eine Hotline mit CRM-Unterstützung und durch abgestimmte Weiterentwicklung der Plattform gemäß Kundenanforderungen. Zentrales Element ist das transparente Sicherheits- konzept, um das Vertrauen der Zielgruppe aufzu- bauen. Da die Plattform die Kommunikation zwischen Handelsvertretern und ihren Herstellern unterstützt, würde ein Ausfall der Plattform die Vertriebsaktivitäten stark einschränken. Die webbasierte Informationsplattform soll als Marke aufgebaut und damit sollen auch die Besonderheiten und Alleinstellungsmerkmale herausgestellt werden. Tabelle 49: Distributionskanäle und angestrebte Kundenbeziehung zur zweiten Zielgruppe Um die angestrebten Dienstleistungsangebote zu erbringen (DE1 und DE2) werden die folgenden Prozesse (DP1-7) benötigt: Kurzz. Bezeichnung Beschreibung DE1 PremiumSalesService (Erbringung) Die Dienstleistungserbringung umfasst allgemeine, organisatorische Abläufe, den Betrieb eines Rechenzentrums, die (Weiter-)Entwicklung der Informationsplattform, die Betreuung von Kunden, die Gewährleistung der IT-Sicherheit, die Durchführung kundenindividueller Leistungen sowie Marketing und Vertrieb. - 131 - Kurzz. Bezeichnung Beschreibung DE2 SupplierPremiumService (Erbringung) Die Dienstleistungserbringung umfasst allgemeine, organisatorische Abläufe, den Betrieb eines Rechenzentrums, die (Weiter-)Entwicklung der Informationsplattform, die Betreuung von Kunden, die Gewährleistung der IT-Sicherheit, die Durchführung kundenindividueller Leistungen sowie Marketing und Vertrieb. Zusätzliche Kompetenzen und Ressourcen zu den schon aufgeführten werden nicht benötigt. DP1 Allgemeine Organisation Darunter fällt die Koordination des Konsortiums und des Dienstleistungsangebots. DP2 Organisation Rechen- zentrum und IT-Infra- struktur Alle Teilprozesse, die nötig sind, um den Betrieb eines Rechenzentrums und der notwendigen IT-Infrastruktur zu planen und durchzuführen. DP3 Systementwicklung Alle Teilprozesse, die nötig sind, um die Plattform zu konzipieren, aufzubauen und kontinuierlich zu verbessern. DP4 Kundenbetreuung Alle Teilprozesse, die nötig sind, um Kunden der webbasierten Informationsplattform bei der Nutzung zu unterstützen. DP5 IT-Sicherheit Alle Teilprozesse, die nötig sind, um ein Sicherheitskonzept für die webbasierte Informations- plattform zu konzipieren, umzusetzen und kontinuierlich zu verbessern. DP6 Integration, kunden- spezifische Beratung und Einführung Alle Teilprozesse, die nötig sind, um die Integration von Backendsystemen zu realisieren, Kunden bei der Umsetzung spezifischer Anforderungen zu unterstützen (Beratung/Umsetzung) und sie in die Nutzung der webbasierten Informationsplattform einzuführen. DP7 Marketing und Vertrieb Alle Teilprozesse, die nötig sind, um die webbasierte Informationsplattform bei der Zielgruppe bekannt zu machen und Kunden zu akquirieren. Tabelle 50: Dienstleistungserbringung und notwendige Dienstleistungsprozesse - 132 - Für die Durchführung der Prozesse (DP1-7) werden die folgenden Ressourcen und Kompetenzen (KR1-6) benötigt, die von den gelisteten Partnern bereitgestellt werden: Kurzz. Bezeichnung Beschreibung Partner KR1 Allgemeine Organisation Bereitstellung derjenigen Kompetenzen und Ressourcen, die zur allgemeinen Organisation des Konsortiums und des Dienstleistungsan- gebots benötigt werden. PA1 KR2 CRM und SaaS Bereitstellung derjenigen Kompetenzen und Ressourcen, die die zentralen Funktionen der webbasierten Plattform ermöglichen. Dazu gehört die Entwicklung und Weiterentwicklung von Diensten, aber auch die Schulung und Betreuung von Kunden. PA1 KR3 Rechenzentrum und IT- Administration Bereitstellung derjenigen Kompetenzen und Ressourcen, die für den sicheren Betrieb und die Administration eines Rechenzentrums notwendig sind. PA2 KR4 Spezial Know-How Produkt- informations- management Bereitstellung derjenigen Kompetenzen und Ressourcen, die für die Unterstützung des Produktinformationsaustauschs und der -verwal- tung benötigt werden. PA3 KR5 Spezial Know-How IT-Sicherheit Bereitstellung derjenigen Kompetenzen und Ressourcen, die notwendig sind, um ein Sicherheitskonzept für die webbasierte Informationsplattform zu konzipieren, umzu- setzen, zu testen und kontinuierlich zu verbessern. PA4 KR6 Marketing Bereitstellung derjenigen Kompetenzen und Ressourcen zur Durchführung der Marketing und Vertriebsprozesse (DP7) PA1 Tabelle 51: Ressourcen und Kompetenzen - 133 - Die Ressourcen und Kompetenzen (KR1-6) werden von den folgenden Partnern (PA1-4) erbracht: Kurzz. Bezeichnung Beschreibung PA1 Anbieter von SaaS-CRM Langjähriger Anbieter einer CRM-Lösung, die als Lizenz- sowie als SaaS-Lösung angeboten wird. Der Anbieter bringt u.a. ein eigenes Netzwerk mit Vertriebspartnern mit, auf das zurückgegriffen werden kann. PA2 Betreiber einer web- basierten Transaktions- plattform Langjähriger Anbieter von webbasierten Transaktions- plattformen als Branchenlösungen. PA3 Anbieter von IT-Sys- temen zum Produktin- formationsmanagement Langjähriger Anbieter von IT-Werkzeugen zur Aufbereitung, Verwaltung und Ausgabe von Produkt- informationen. PA4 Unternehmen mit Kernkompetenz in IT- Sicherheit Anbieter von Sicherheitslösungen für webbasierte IT- Lösungen. Tabelle 52: Partner und deren Kurzbeschreibungen - 134 - Die Durchführung der Dienstleistungsprozesse verursacht die folgenden Kosten (KO1-9) und wird durch den genannten Partner erbracht: Kurzz. Beschreibung Partner KO1 Kosten, die für die Organisation und das Projektmanagement anfallen, u.a. für einen Projektleiter, Räumlichkeiten und für die Verwaltung. Die Ressourcen werden durch Projektpartner PA1 bereitgestellt. PA1 KO2 Eine bestehende Version der CRM-Software des Partners PA1 wird zur Nutzung als SaaS aufbereitet. Hierzu werden Entwickler sowie eine geeignete Entwicklungsumgebung benötigt. PA1 KO3 Die Software wird stetig weiterentwickelt und weitere Funktionalitäten integriert. PA1 KO4 Um die Informationsplattform zu bewerben, wird ein Marketingbudget zur Verfügung gestellt. Darüber hinaus werden für Vertriebspartner Provisionen in Höhe eines Jahreserlöses eines Kunden ausgelobt. PA1 KO5 Das Rechenzentrum wird von einem Administrator verwaltet, die Rechner werden als Dienst von einem IT-Dienstleister gemietet. PA2 KO6 Die PIM-Funktionalitäten werden durch Partner PA3 bereitgestellt. Hierfür ist eine Erstentwicklung der Funktionalitäten notwendig und damit auch der Einrichtung einer geeigneten Entwicklungsumgebung. PA3 KO7 Die PIM-Funktionalitäten werden sukkzessive weiterentwickelt. PA3 KO8 Partner PA4 entwickelt ein IT-Sicherheitskonzept. Dies ist insbesondere notwendig, da die Informationsplattform und ihre Funktionalitäten auf alle Partnern verteilt angeboten und über Web Service Schnittstellen integriert werden. PA4 KO9 Das IT-Sicherheitskonzept wird regelmäßig geprüft und ggf. weiterentwickelt. PA4 Tabelle 53: Kosten für Erbringung der Dienste und Dienstleistungen - 135 - Mit den Dienstleistungsangeboten (DA1 und DA2) werden die folgenden Erlöse (ER1-4) angestrebt: Kurzz. Beschreibung Erlös ER1 Erlöse, die durch Handelsvertreter (Zielgruppe ZG1) mit dem BasisSalesPackage für 100 Euro pro Monat erzielt werden. Hierbei ist Ziel 2.500 Handelsvertreter in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 500 neue Handelsvertreter. 1.500.000 Euro/Jahr ER2 Erlöse, die durch Handelsvertreter (Zielgruppe ZG1) mit dem IntegrationSalesPackage erzielt werden. Hierbei ist Ziel, dass von 2.500 Handelsvertreter in den ersten 5 Jahren des BasisSalesPackage ca. 20 Prozent das IntegrationSales- Package zu 20 Euro pro Monat nutzen 60.000 Euro/Jahr ER3 Erlöse, die durch Hersteller (Zielgruppe ZG2) mit dem SupplierIntegrationPackage PIM zu 20 Euro pro Monat erzielt werden. Hierbei ist Ziel 1.000 Hersteller in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 200 neue Hersteller. 48.000 Euro/Jahr ER4 Erlöse, die durch Hersteller (Zielgruppe ZG2) mit dem SupplierIntegrationPackage ERP zu 20 Euro pro Monat erzielt werden. Hierbei ist Ziel 1.000 Hersteller in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 200 neue Hersteller. 48.000 Euro/Jahr Tabelle 54: Angestrebte Erlöse aus den Dienstleistungsangeboten (Schätzwerte) Die Aufteilung der Erlöse ist in Anhang C aufgeführt. Die Investitionen in die Informationsplattform werden auf 5 Jahre gerechnet. Bei Gegenüberstellung der Kosten (KO1-9) und der Erlöse (ER1-4) ergeben sich folgende Gewinne (G1-4) für die einzelnen Partner (PA1-4): Kurzz. Partner ‡-Kosten pro Jahr ‡-Erlös pro Jahr ‡-Gewinn pro Jahr Rentabilität G1 PA1 1.188.000 EUR 1.387.728 EUR 170.028 EUR 17% G2 PA2 170.000 EUR 198.720 EUR 25.320 EUR 17% G3 PA3 30.000 EUR 33.120 EUR 2.520 EUR 10% G4 PA4 33.000 EUR 36.432 EUR 2.772 EUR 10% Tabelle 55: Gewinn und Rentabilität der Investition je Partner (Schätzwerte) Um die Informationsplattform umzusetzen, müssen diese Informationen nun in einem nächsten Schritt zuerst auf fachlicher dann auf technischer Ebene analog der - 136 - Integrated Service Engineering Methode (siehe Kapitel 6) weiter konkretisiert werden. 9.2 Technische Umsetzung Um die Anwendung des Referenzmodells und die Vorgehensweise zu verbessern, wurde ein Editor zur Modellierung auf Basis des Referenzmodells entwickelt. Mit dem Editor steht dem Anwender (Strategen) ein Werkzeug zur Verfügung, mit dem aus geschäftlich-strategischer Sicht ein zielgruppenspezifisches Geschäftsmodell für eine webbasierte Informationsplattform für Handelsvertreter, -vermittler und Hersteller entwickelt und dokumentiert werden kann. Darüber hinaus bietet das Werkzeug die Möglichkeit, die Informationen in weitere nachgelagerte Modelle der Integrated Service Engineering Methodik ISE durch Transformationen zu übernehmen (Kett et al. 2009a; Kett et al. 2008). Die Umsetzung des Referenzmodells erfolgt in der Eclipse Entwicklungsumgebung1, die mit zusätzlichen Werkzeugen des Dynamic Language Toolkit (DLTK)2 zur besseren Entwicklung domainspezifischer Modelle benutzt werden. Um Geschäftsmodelle auf Basis des vorgestellten Referenzmodells und in Eclipse entwickeln zu können, muss ein Ecore-Modell erstellt werden, das die Elemente des Referenzmodells, deren Attribute sowie deren Beziehungen untereinander definiert (Steinberg et al. 2009; Gronback 2009). Das Ecore-Modell ist somit das Metamodell des Referenzmodells und wurde in Eclipse entwickelt (siehe Abbildung 24). Die XMI- Serialisierung hierzu ist in Anhang F dargestellt. Neben dem Ecore-Modell wurde ein domainspezifisches Modell für die vorliegende Aufgabenstellung in Eclipse entwickelt und folgende Festlegungen getroffen: ± Grafische Attribute der Elemente und deren Referenzen (Graphical Definition Model), ± Benötigte Werkzeuge, um die Elemente und Referenzen im Modell zu benutzen (Tooling Definition Model) ± Map-Dokument (Mapping Model), das die genannten Informationen miteinander verbindet. Gronback (2009) führt auf, wie eine domainspezifische Sprache in Eclipse entwickelt und umgesetzt wird. 1 Siehe http://www.eclipse.org 2 Siehe http://www.eclipse.org/dltk/ - 137 - Abbildung 24: Metamodell des Referenzmodells in Eclipse 9.3 Eclipse Editor zur Nutzung des Referenzmodells Mit den aufgeführten Modellen wurde das Referenzmodell für den Eclipse Editor festgelegt. In Abbildung 25 ist der Editor dargestellt. Der mittlere Bereich stellt die Modellierungssicht und damit das Modell dar. Rechts davon befinden sich die Elemente und Referenzen des Referenzmodells, die zur Modellierung verwendet werden können. Im unteren Bereich befinden sich die Anzeige und Eingabemöglichkeiten von Attributen. Links unten ist eine Übersicht des Modells dargestellt und darüber die Projekte, die in der Eclipse-Umgebung aktuell erstellt und bearbeitet werden. - 138 - Abbildung 25: Nutzung des Referenzmodells in Eclipse Modell- liste Modell(-elemente) Attribute von Modellelementen Modell- übersicht Palette verfügbarer Modellelemente 10 Evaluierung des Referenzmodells Die Bewertung der Arbeitsergebnisse erfolgt anhand zweier Zielgruppen. Zum einen durch die Vertriebsunternehmen, Handelsvertreter, Handelsvermittler und Händler, die insbesondere die webbasierte Informationsplattform und deren Nutzenpotenzial beurteilen, zum anderen durch Softwareanbieter, die das Referenzmodell, dessen Umsetzung und Anwendbarkeit bewerten. 10.1 Evaluierung durch Handelsvertretungen Die Beurteilung der Lösung mittels Vertriebsunternehmen und Hersteller, die ihre Produkte über Handelsvertreter vertreiben, fand anhand von mehreren Workshops statt. Die Workshops wurden teilweise mit einzelnen Unternehmen bzw. in homogenen Gruppen von Vertriebsunternehmen durchgeführt. Hierzu wurde die prinzipielle Idee, die hinter dem Ansatz der webbasierten Informationsplattform steckt, präsentiert. Anschließend wurden die Rahmen- bedingungen bei den jeweiligen Teilnehmern aufgenommen bzgl. deren Organisation, Produkte, Prozesse und IT-Infrastruktur. Basierend auf den gewonnenen Informationen wurde geprüft, welche Dienste und Dienstleistungen die Unternehmen zur Unterstützung ihrer Vertriebsprozesse benötigen. Um die Ergebnisse besser auswerten zu können, wurden Szenarios entwickelt, bei denen die Zielgruppen anhand relevanter Merkmale und deren Ausprägungen ausgewertet werden. Merkmal Szenarios Bewertung Evaluationsergebnisse Kundentyp Handelsvertreter/ -vermittler ƔƔ Für Handelsvertreter und -vermittler waren insbesondere die Funktionen zur Unterstützung der Kommunikation zwischen ihren Unternehmen und Herstellern von großer Bedeutung. Dabei war die Multilieferantenfähigkeit der Informationsplattform und damit der teilautomatischen Aggregation und Separation von Informationen für einen Kunden bzw. einen Hersteller eine große Arbeitserleichterung. - 140 - Merkmal Szenarios Bewertung Evaluationsergebnisse Hersteller Ɣ Die Hersteller sahen den Vorteil der Vertriebsplattform nicht so deutlich wie die Handelsvertreter, da der eigent- liche Nutzen zunächst seitens der Vertriebsunternehmen liegt. Je stärker sie allerdings den Nutzenbeitrag der Vertriebsunternehmen zu ihrem eigenen Nutzen einschätzten, desto wertvoller wurde die Informations- plattform bewertet. Daher wird sich die Informationsplattform vor allem dort durchsetzen, wo Vertriebsunter- nehmen starken Druck auf ihre Hersteller ausüben können. Produkttyp Standard- produkte ƔƔ Die Einbindung von Standardprodukt- katalogen und entsprechende Schnitt- stellen zum Import von Produktinfor- mationen in die Informationsplattform ist stark ausgeprägt. Die Informations- plattform unterstützt daher insbe- sondere Vertriebsunternehmen, die technische Standardprodukte ver- treiben. Konfigurierbare Produkte Ɣ Beim Vertrieb konfigurierbarer, tech- nischer Produkte fehlt heute in vielen Fällen die notwendige elektronische Unterstützung. Daher sind Vertriebs- unternehmen daran interessiert, eine entsprechende Unterstützung zu erhal- ten. Allerdings wird kein generischer Produktkonfigurator auf der Informa- tionsplattform angeboten. Es besteht jedoch die Möglichkeit, Produkt- konfiguratoren der einzelnen Hersteller in die Informationsplattform zu integrieren. - 141 - Merkmal Szenarios Bewertung Evaluationsergebnisse Individual- produkte Ɣ Die Bedeutung von Individualproduk- ten nimmt insbesondere bei Vertriebs- unternehmen aufgrund besserer Differenzierungspotenziale weiter zu. Daher wurden in der Informations- plattform entsprechende Projekträume geplant, in denen die Entwicklung einzelner Produkte projektspezifisch vorangetrieben werden kann. ƔƔ InformationVSODWWIRUP LVWEHVRQGHUVJHHLJQHW IUGLHVHV6]HQDULRƔ Informationsplattform ist bedingt geeignet für dieses Szenario; ż Informationsplattform ist hierfür nicht geeignet Tabelle 56: Eignung von Diensten und Dienstleistungen der webbasierten Informationsplattform Die Eignungsbewertung der webbasierten Informationsplattform je Zielgruppe wurde von den Teilnehmern der Workshops durchgeführt. 10.2 Evaluierung durch IT-Anbieter Die Evaluierung durch IT-Anbieter wurde mit drei IT-Anbietern durchgeführt, die Interesse an der Entwicklung eines Geschäftsmodells, von Diensten und Dienst- leistungen der Informationsplattform für Handelsvertretungen und -vermittlungen und Herstellern bekundet hatten. Hierfür wurden das Referenzmodell und dessen methodische Anwendung den IT- Anbietern vorgestellt und im Rahmen von Workshops zur Entwicklung von Geschäftsmodellen für die Informationsplattform herangezogen und verwendet. Die nachfolgende Bewertung des Referenzmodells wurde von den beteiligten IT- Anbietern durchgeführt und entspricht ihren Einschätzungen. Dabei wurde das Referenzmodell anhand der schon in Kapitel 3 vorgestellten Grundsätze der ordnungsgemäßen Modellierung evaluiert. In Tabelle 57 werden die zentralen, in Tabelle 58 die ergänzenden Grundsätze bewertet. - 142 - Grundsatz Subkriterien Bewertung Evaluierung durch Softwareanbieter Konstruktions- adäquanz Problemeignung ƔƔ Das Referenzmodell unterstützt die Erstellung eines Service Konzepts aus geschäftlich-strategischer Sicht. Minimalität ƔƔ Das Modell ist fokussiert und besitzt eine klare Linie bei der Erstellung des Service Konzepts. Intra- Modellkonsistenz Ɣ Die Konstruktion des Referenzmodells wird als konsistent erachtet. Inter- Modellkonsistenz Ɣ Die Beziehung zwischen den einzelnen Modellen wurde skizziert, aber nicht detailliert ausgearbeitet. Sprachadäquanz Spracheignung ƔƔ Die Modellierungssprache wird als passend eingeschätzt. Sprachrichtigkeit ƔƔ Ebenso wird die Korrektheit der Begrifflichkeiten als geeignet eingeschätzt. Wirtschaftlichkeit Verwendbarkeit ƔƔ Das Referenzmodell unterstützte im Rahmen der Workshops, die Entwicklung von Service Konzepten. Robustheit Ɣ Das Modell kann gegenüber Änderungen flexibel angepasst werden. Allerdings konnte dies nur bedingt im Rahmen der Workshops diskutiert werden. Übersetzbarkeit - Inwieweit das Modell in einem anderen Kontext Verwendung finden kann, hängt von dem jeweiligen Kontext ab. Diese Anforderungen an das Modell wurden im Rahmen der Workshops nicht betont. ƔƔ 5HIHUHQ]PRGHOO HUIOOWGDV6XENULWHULXPEHVRQGHUVJXWƔ 5HIHUHQ]PRGHOO HUIOOW6XENULWHU ium EHGLQJWż 5HIHUHQ]PRGHOO HUIOOWGLHVHV6XEN riterium nicht; - = Grundsatz wurde nicht betrachtet Tabelle 57: Bewertung der zentralen Grundsätze der ordnungsmäßigen Modellierung Während die zentralen Grundsätze der ordnungsmäßigen Modellierung für ein geeignetes Modell erfüllt sein müssen, ist die Hürde für die ergänzenden Grundsätze niedriger. Die ergänzenden Grundsätze sollten durch das Referenzmodell erfüllt werden (siehe Tabelle 58). - 143 - Grundsatz Subkriterien Bewertung Evaluierung durch Softwareanbieter Systematischer Aufbau Erfassung relevanter Sichten Ɣ Verschiedene Sichten wurden im Rahmen des Modells berücksichtigt. Allerdings wurde insbesondere die Sicht des Strategen herausgearbeitet, während bei den anderen Sichten nur die Modelle genannt wurden. Erfassung der Sichten- beziehungen Ɣ Auf die Beziehungen der verschiedenen Sichten untereinander wird im Rahmen dieser Arbeit weniger eingegangen. Allerdings sind die Verbindungen der einzelnen Sichten, z.B. in Form von Modelltransforma- tionen, wichtiger Bestandteil der zugrundeliegenden ISE Methodik. Klarheit Modell- hierarchisierung Ɣ Das Modell ist bzgl. seiner Element- gruppen, Elemente sowie deren Attribute und unter Berücksichtigung seiner Komplexität klar hierachisiert. Filterung ż Die Filterung spezifischer Inhalte wird nicht im Rahmen des Referenzmodells berücksichtigt. Vergleichbarkeit - - - ƔƔ 5HIHUHQ]PRGHOO HUIOOWGDV6XENULWHULXPEHVRQGHUVJXWƔ 5HIHUHQ]PRGHOO HUIOOW6XENULWHU ium EHGLQJWż 5HIHUHQ]PRGHOO HUIOOWGLHVHV6XEkriterium nicht Tabelle 58: Ergänzende Grundsätze der ordnungsmäßigen Modellierung 10.3 Fazit Durch die Nutzung des Referenzmodells für die Geschäftsmodellentwicklung von webbasierten Informationsplattformen für den technischen Vertrieb mit dem besonderen Fokus auf Handelsvertretungen und -vermittlungen ließen sich im Rahmen des aufgeführten Anwendungsbeispiels folgende Nutzen realisieren: ± Strukturierte Entwicklung eines klaren strategischen Konzepts und die zielgruppenspezifische Ausrichtung der Informationsplattform mit allen Beteiligten ± Wesentliche Grundlage und Rahmen für die konkrete Planung und Umsetzung der Informationsplattform für alle Beteiligten ± Vereinfachung der Prüfung, inwieweit die Entwicklung und der Betrieb der Informationsplattform im Rahmen des Konsortiums für jeden Partner wirtschaftlich interessant sind. 11 Ausblick Die zielgruppenspezifische Ausrichtung der Integrated Service Engineering Methodik (ISE) für webbasierte Informationsplattformen für Handelsvertreter, -vermittler und Hersteller wurde mit den Zielgruppen Handelsvertreter, Hersteller und IT-Anbieter evaluiert. Dabei erfüllte das Referenzmodell seine Zielsetzung, die zielgruppenspezifische Entwicklung einer webbasierten Informationsplattform für Handelsvertreter und Hersteller zu unterstützen. Bei Betrachtung der zukünftigen Entwicklungen lassen sich zwei grundlegende Ausrichtungen identifizieren, die zum einen die geschäftlich-strategische Sicht des Strategen, zum anderen die Weiterentwicklung der webbasierten Informations- plattform für Handelsvertreter, -vermittler und Hersteller unter Berücksichtigung der Ansätze des Cloud Computing betrifft: Service Konzept: Da mit neuen Web-Technologien auch neuartige Web- Anwendungen ermöglicht werden, die verschiedenste Beteiligte mittels innovativer Geschäftsmodelle zusammenbringen, spielt eine methodisch strukturierte Entwicklung und Modellierung dieser Geschäftsmodelle zukünftig eine stärkere Rolle. Der in dieser Arbeit vorgeschlagene Geschäftsmodellansatz stellt ein konkretes Fallbeispiel zum Einsatz bei der Entwicklung einer webbasierten Informations- plattform für Handelsvertreter und Hersteller dar. Um zukünftig in beliebigen Domänen Geschäftsmodelle strukturiert entwickeln und in nachgelagerte Modelle einbinden zu können, wird ein generischer Ansatz zur Entwicklung von Geschäfts- modellen benötigt. Cloud Computing: Wenn sich der Ansatz einer webbasierten Informationsplattform als Software as a Service für Handelsvertreter, -vermittler und Hersteller etabliert, wird es ebenso wie in vergleichbaren anderen Fällen (z.B. Salesforce.com) interessant sein, die Plattform für weitere IT-Anbieter zu öffnen und die Möglichkeit zu bieten, ihre elektronischen Dienste auf der Plattform anzubieten und bereitzustellen (PaaS - Platform as a Service). Hierfür sind weitere Mechanismen und Funktionen insbesondere für die Zielgruppe der IT-Anbieter notwendig, wie z.B. Funktionen zur Abrechnungen und Bezahlung der Dienstnutzung, zum Anbieten und Bereitstellen von Diensten, sowie standardisierte Schnittstellen zur Integration von Diensten in die Informationsplattform. Insbesondere für den letztgenannten Trend, ist es unabdingbar, dass sich die webbasierte Informationsplattform für Handelsvertreter und Hersteller als Software as a Service etabliert und damit eine solide Grundlage für die Weiterentwicklung zur Platform as a Service bildet. 12 Zusammenfassung In Deutschland werden jährlich Waren im Wert von 175 Mrd. Euro über Handelsvertretungen und -vermittlungen vertrieben, die Unternehmen als eigenständige Vertriebspartner beim Marketing und Vertrieb ihrer Produkte und Dienstleistungen unterstützen. 66 Prozent dieser Umsätze sind dem verarbeitenden Gewerbe zuzurechnen. Durchschnittlich vertreten diese eigenständigen Organisa- tionen sechs Herstellerunternehmen. Um diesen Vertriebsweg zu etablieren, müssen Handelsvertretungen und -vermittlungen in die Prozesse des zu vertretenden, produzierenden Unternehmens integriert werden. Bei den Handelsvertretern und -vermittlern handelt es sich überwiegend um kleine Unternehmen (87 Prozent der Handelsvertretungen beschäftigen nur bis zu sechs Mitarbeiter), die je nach Wirtschaftsbereich, in dem sie tätig sind, unterschiedliche Anforderungen an die IT-Unterstützung stellen. Aktuell existieren keine geeigneten IT-Lösungen, die auf die Bedürfnisse dieser kleinen Gewerbebetriebe zugeschnitten sind und deren wesentlichen Anforderungen abdecken. Auf dem Konzept Software-as-a-Service (SaaS) basierende Lösungen, wie z. B. webbasierte Informationsplattformen, eröffnen völlig neue Möglichkeiten, da sie den Aufwand für Betrieb und Wartung von IT-Anwendungen bei Herstellern reduzieren helfen. Sie ermöglichen eine flexiblere Nutzung der IT-Infrastruktur und bieten u. a. den Vorteil, dass nur die tatsächlich in Anspruch genommenen Leistungen abgerechnet werden. Die vorliegende Arbeit verfolgt das Ziel, die zielgruppenspezifische Entwicklung webbasierter Lösungen als elektronische Dienstleistung für Handelsvertreter, -vermittler und produzierende Unternehmen methodisch zu unterstützen. Hierfür ist ein interdisziplinäres Vorgehen notwendig, bei dem zu Beginn die Erarbeitung des Dienstleistungsangebots für produzierende Unternehmen und deren Handels- vertreter und -vermittler im Mittelpunkt steht (Sicht 1). Anschließend erfolgt die Konkretisierung des Dienstleistungsangebots in Form eines fachlichen Konzepts (Sicht 2), sodass daraus ein dienstbasiertes IT-Konzept abgeleitet (Sicht 3), softwaretechnisch umgesetzt (Sicht 4) und in Betrieb genommen (Sicht 5) werden kann. Eine durchgehend modellbasierte Entwicklung der webbasierten Lösung erhöht die Transparenz zwischen den genannten Sichten und der dafür erarbeiteten Modelle und steigert die Wiederverwendbarkeit entwickelter Dienste. Ganzheitliche Vorgehensweisen zur modellbasierten Entwicklung elektronischer Dienste existieren in dieser Form bisher nicht. Ebenso konnten keine anwendbaren Metamodelle zur Modellierung von Dienstleistungsangeboten und der zugrunde - liegenden Geschäftsmodelle identifiziert werden. Zur Lösung dieses Defizits stellt die Arbeit ein Referenzmodell vor, das IT-Anbieter bei der zielgruppenspezifischen Entwicklung webbasierter Informationsplattformen für Handelsvertretungen, -vermittlungen und deren zu vertretenen Hersteller im technischen Vertrieb unterstützt. Die Grundlage für das Referenzmodell ist ein - 146 - Metamodell (Integrated Service Engineering Framework), das auf dem Zachman- Framework aufbaut. Das Metamodell ermöglicht die Zuordnung geeigneter Modelle zu den oben genannten Sichten auf einen elektronischen Dienst in Form einer Matrix. Die Arbeit stellt hierfür geeignete Modelle vor und erstellt ein Referenzmodell für die marktorientierte, zielgruppenspezifische Sicht mit Fokus auf die Dienstleistungsangebote und die zugrunde liegenden Geschäftsmodelle. Das Referenzmodell ermöglicht die Strukturierung wirtschaftlich-strategischer Informationen zu Beginn des Entwicklungsprozesses und ordnet diese Modellen und Informationen nachgelagerten Sichten zu. Um die Anwendung des Referenzmodells zu vereinfachen, wird ein methodisches Vorgehen für dessen Nutzung vorgestellt. Das Referenzmodell wurde in Form eines Eclipse-basierten Editors umgesetzt und mit vier Partnerunternehmen evaluiert. Mithilfe des Referenzmodells für die Geschäftsmodellentwicklung von webbasierten Informationsplattformen für den technischen Vertrieb mit besonderem Schwerpunkt auf Handelsvertretungen, -vermittlungen und Herstellerbetriebe konnten in der Evaluation folgende Nutzen realisiert werden: Die strukturierte Entwicklung eines Geschäftsmodells und die zielgruppenspezifische Ausrichtung einer Informationsplattform mit allen Beteiligten, die Erstellung einer wesentlichen Grundlage und eines Rahmens für die konkrete Planung und Umsetzung der Informationsplattform und eine vereinfachte Prüfung der Frage, inwieweit die Entwicklung und der Betrieb der Informationsplattform für jedes Partnerunternehmen wirtschaftlich interessant sind. 13 Summary *RRGV ZRUWK DSSUR[LPDWHO\ ¼ ELOOLRQ DUH GLVWULEXWHG E\ VDOHV DJHQFLHV ZKLFK support the marketing and sales activities of manufacturers as independent partners. 66% of the turnover involved is attributable to manufacturing industry. On average, each sales agency represents six manufacturers. In order to establish this distribution channel, the sales agencies need to be integrated into the business processes of the manufacturers they represent. Sales agencies are predominantly made up of small businesses (87% employ fewer than six employees) which, depending on the sector concerned, have different requirements regarding IT support. Currently, there are no specific IT-solutions which are tailored to small sales agencies and meet their essential requirements. Solutions based on the Software as a Service (SaaS) approach, e.g. web-based information platforms, open up new possibilities for manufacturers by reducing the effort required to operate and maintain IT-applications. They enable a more flexible use of IT-infrastructure and offer the advantage that only those services which have actually been used must be paid for. The aim of this dissertation is to provide methodical support for the target-group- specific development of web-based solutions as electronic services for sales agencies and manufacturers. To that end, an interdisciplinary approach is needed which first focuses on developing a range of services for manufacturers and their sales agencies (stage 1). They are then put into the concrete form of a business- oriented concept (stage 2) so that a service-based IT concept can be derived (stage 3), developed into software (stage 4) and put it into operation (stage 5). A holistic model-based development of the web-based solution increases transparency between the said stages and the models thus developed and improves the reusability of the services developed. Holistic approaches to the model-based development of electronic services have so far not existed in this form. Likewise, it has not been possible to identify applicable meta-models for the modelling of services provided and their underlying business models. To overcome this shortcoming, the dissertation presents a reference model which supports IT-suppliers in developing target-group-specific, web-based information platforms for sales agencies and the manufacturers they represent in technical sales. It is based on a meta-model (integrated service engineering framework) built on the Zachman framework. The meta-model allows appropriate models to be assigned to the above-mentioned stages in respect of an electronic service in the form of a matrix. The dissertation suggests appropriate models and develops a reference model for the market-oriented, target-group-specific stage in question which focuses on the services supplied and the underlying business models. The reference model allows strategic information to be structured at the beginning of the development process and matches the models and information with the appropriate stage. - 148 - To simplify the application of the reference model, a methodical approach for its use is presented. The reference model has been implemented in the form of an Eclipse- based editor and evaluated by four partners firms. With the help of the reference model for developing web-based information platforms for technical sales according to a business model, focussing in particular on sales agencies and the manufacturers they represent, it has been possible to obtain the following benefits in the evaluation: the structured development of a business model and the target-group±specific alignment of the information platform with all partners, the creation of a substantial basis and framework for the concrete planning and implementation of the information platform, and easier assessment of whether the development and operation of the information platform is financially interesting to all partner firms. Literatur und Quellen Abrams et al. 1999 Abrams, M.; Phanouriou, C.; Batongbacal, A. L.; Williams, S. und Shuster, J.: UIML: an appliance-independent XML user interface language. In: Mendelzon, A. (Hrsg.): Proceedings of 8th International World-Wide Web Conferernce WWW'8. Elsevier, Amsterdam, 1999. Afuah und Tucci 2003 Afuah, A. und Tucci, C. L. (Hrsg.): Internet Business Models and Strategies. McGraw-Hill, Boston, 2003. Ariba Technologies 1998 Ariba Technologies: Catalog Interchange Format (CIF): 2.1 Specification, 1998. URL: http://www.gatetrade.net/docs/integration_us/cif2_1spec.pdf ± Überprüfungsdatum: 21.02.2011. Arsanjani 2004 Arsanjani, A.: Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA, 2004. URL: http://www.ibm.com/developerworks/library/ws-soa-design1/ Asadi et al. 2008 Asadi, M.; Ravakhah, M. und Ramsin, R.: An MDA-based System Development Lifecycle. In: Proceedings of the 2nd Asia International Conference on Modelling & Simulation (AICMS), 2008, S. 836±842. Baatz 1996 Baatz, E. B.: Will Your Business Model Float? In: WebMaster Magazin, 1996. Balzert 2000 Balzert, H.: Lehrbuch der Software-Technik. Spektrum, Heidelberg, 2000. Barabba und Huber 2002 Barabba, V. und Huber, C.: A multimethod approach for creating new business models: The General Motors OnStar project, Bd. 1. In: Interfaces, 2002 (32), S. 20±34. Barros und Dumas 2006 Barros, A. P. und Dumas, M.: The Rise of Web Service Ecosystems. In: IT Pro September/Oktober. 2006, S. 19±25. Becker und Schütte 2004 Becker, J. und Schütte, R.: Handelsinformationssysteme. Redline Wirtschaft, Landsberg, 2004. - 150 - Bell 2008 Bell, M.: Service-oriented modeling: Service analysis, design, and architecture. Wiley, Hoboken, 2008. Bell 2010 Bell, M.: SOA modeling patterns for service-oriented discovery and analysis. Wiley, Hoboken, NJ, 2010. Benz et al. 2003 Benz, A.; Ritz, T. und Stender, M.: Marktstudie mobile CRM-Systeme. Fraunhofer IRB, Stuttgart, 2003. Berkem 2008 Berkem, B.: From The Business Motivation Model (BMM) To Service Oriented Architecture (SOA), Vol. 7, No. 8. In: Journal of Object Technology, Zürich, 2008 (7), S. 57±70. Berlecon Research 2010 Berlecon Research: E-Business-Standards in Deutschland: Bestandsaufnahme, Probleme, Perspektiven. Berlecon Research, Berlin, 2010. Blecker et al. 2003 Blecker, T.;Abdelkafi, N.;Kaluza, B. und Friedrich, G.: Variety Steering Concept for Mass Customization, 2003. URL: http://mpra.ub.uni- muenchen.de/5251/1/MPRA_paper_5251.pdf ± Überprüfungsdatum: 25.03.2011. Booz et al. 1968 Booz, E.; Allen, J. und Hamilton, C. (Hrsg.): Management of New Products. Booz Allen & Hamilton, Chicago, 1968. Booz et al. 1982 Booz, E.; Allen, J. und Hamilton, C. (Hrsg.): New Products Management for the 1980s. Booz Allen & Hamilton, New York, 1982. Bose et al. 2005 Bose, S.; Bieberstein, N.; Fiammante, M.; Jones, K. und Shah, R.: SOA Project Planning Aspects. IBMPress, 2005. Bowers 1985 Bowers, M. R.: An Exploration into New Service Development: Process, Structure and Organization. Texas, Texas A&M University, 1985. Broy und Denert 2002 Broy, M. und Denert, E.: Software pioneers. Springer, Berlin, 2002. - 151 - Brugger 2005 Brugger, R.: Der IT Business Case: Kosten erfassen und analysieren, Nutzen erkennen und quantifizieren, Wirtschaftlichkeit nachweisen und realisieren. Springer, Berlin, 2005. Bullinger et al. 2003 Bullinger, H.-J.; Fähnrich, K.-P. und Meiren, T.: Service engineering methodical development of new service products. In: International Journal of Production Economics 85. 2003, S. 275±287. Bullinger und Schreiner 2003 Bullinger, H.-J. und Schreiner, P.: Ein Rahmenkonzept für die systematische Entwicklung von Dienstleistungen. In: Bullinger, H.-J. und Scheer, A.-W. (Hrsg.): Service Engineering: Entwicklung und Gestaltung innovativer Dienstleistungen. Springer, Berlin, 2003, S. 51±82. Bundesministerium der Justiz 2010 Bundesministerium der Justiz: Handelsgesetzbuch. 2010. URL: http://bundesrecht.juris.de/hgb/index.html ± Überprüfungsdatum: 13.02.2011. CDH 2008a CDH: Handelsvertreterrecht: Die Grundzüge im Überblick, 2008. URL: http://www.cdh24.de/user/eesy.de/cdh24.de/dwn/text_handelsvertreterrecht.pdf ± Überprüfungsdatum: 25.03.2011. CDH 2008b CDH: Positive Entwicklung: CDH-Statistik 2008. In: H&V Journal. 2008. Nr. 12, S. 5±8. CDH 2009 CDH: Daten und Fakten, 2009. URL: http://www.cdh.de/verband/datenundfakten ± Überprüfungsdatum: 25.03.2011. Celik und Suda 2005 Celik, T. und Suda, B.: hCard 1.0, 2005. URL: http://microformats.org/wiki/hcard ± Überprüfungsdatum: 21.02.2011. Chen 1976 Chen, P. P.: The Entity-Relationship Model - Toward a Unified View of Data, Bd. 1. In: ACM Transactions on Database Systems, 1976 (1), S. 9±36. Chen 1977 Chen, P. P.: The Entity-Relationship Model - A basis for the Enterprise View of Data. In: AFIPS National Computer Conference, 1977, S. 77±84. - 152 - Chesbrough und Spohrer 2006 Chesbrough, H. und Spohrer, J.: A Research Manifesto for Service Science. In: Communications of ACM 49. 2006, S. 35±40. Corsten 1997 Corsten, H.: Dienstleistungsmanagement. Oldenbourg, München, 1997. cXML.org 2009 cXML.org: cXML User's Guide, 2009. URL: http://xml.cxml.org/current/cXMLUsersGuide.pdf ± Überprüfungsdatum: 21.02.2011. DATANORM-Arbeitskreis 1999 DATANORM-Arbeitskreis: DATANORM: Version 5.0, Standardverfahren für den Datenaustausch. Krammer, Düsseldorf, 1999. Daun und Klein 2004 Daun, C. und Klein, R.: Vorgehensweisen zur systematischen Entwicklung von Dienstleistungen im Überblick - Computer Aided Service Engineering. In: Scheer, A.-W. und Spath, D. (Hrsg.): Computer Aided Service Engineering: Informationssysteme in der Dienstleistungsentwicklung. Springer, Berlin, 2004, S. 43±67. DIN Deutsches Institut für Normung e.V. 1998: Service Engineering: Entwicklungsbegleitende Normung (EBN) für Dienstleistungen Dolmetsch 2001 Dolmetsch, R.: E-Procurement: Sparpotential im Einkauf. Addison-Wesley, München, 2001. Donnelly et al. 1985 Donnelly, J. H.; Berry, L. L. und Thompson, T. W.: Marketing Financial Services: A Strategic Vision. Dow Jones-Irwin, Homewood, Ill, 1985. EDIFICE 2010 EDIFICE: EDIFICE REPOSITORY 2010, 2010. URL: http://repository102.edifice.org/downloads.aspx ± Überprüfungsdatum: 21.02.2011. Eisenstein et al. 2000 Eisenstein, J.; Vanderdonckt, J. und Puerta, A.: Adapting to Mobile Contexts with User-Interface Modeling. In: Proceedings of 3rd IEEE Workshop on Mobile Computing Systems and Applications WMSCA'2000. IEEE Press, Los Alamitos, 2000, S. 83±92. - 153 - Endrei et al. 2004 Endrei, M.;Ang, J.;Arsanjani, A.;Chua, S.;Comte, P.;Krogdahl, P.;Luo, M. und Newling, T.: Patterns: Service-Oriented Architecture and Web Services, 2004. URL: http://www.redbooks.ibm.com/abstracts/SG246303.html ± Überprüfungsdatum: 25.03.2011. Fähnrich 1999 Fähnrich, K.-P.: Service Engineering: Ergebnisse einer empirischen Studie zum Stand der Dienstleistungsentwicklung in Deutschland. Fraunhofer IRB, Stuttgart, 1999. Fettke und Loos 2005 Fettke, P. und Loos, P.: Der Beitrag der Referenzmodellierung zum Business Engineering, Bd. 241. In: Strahringer, S. (Hrsg.): Business Engineering. dpunkt, Heidelberg, 2005 (241), S. 18±26. Fettke und Loos 2004 Fettke, P. und Loos, P.: Referenzmodellierungsforschung: Langfassung eines Aufsatzes, Mainz, 2004. Finzen et al. 2010 Finzen, J.; Kasper, H. und Kintz, M.: Innovation Mining: Effektive Recherche unternehmensstrategisch relevanter Informationen im Internet. Fraunhofer-Verlag, Stuttgart, 2010. Frank 2000 Frank, U.: Entwurf eines Referenzmodells für Handelsplattformen im Internet. In: Knowledge Engineering, Management, Consulting & Training, 2000. Gabler 2010 Gabler: Wirtschaftslexikon, 2010. URL: http://wirtschaftslexikon.gabler.de/Archiv/54578/handelsvertreter-v5.html ± Überprüfungsdatum: 10.01.2010. Gadatsch und Mayer 2005 Gadatsch, A. und Mayer, E.: Masterkurs IT-Controlling: Grundlagen und strategischer Stellenwert , Kosten- und Leistungsrechnung in der Praxis , mit Deckungsbeitrags- und Prozesskostenrechnung. Vieweg, Wiesbaden, 2005. Gholamie und Ramsin 2010 Gholamie, M. F. und Ramsin, R.: Strategies for Improving MDA-Based Development Processes. In: Proceedings of International Conference on Intelligent Systems, Modelling and Simulation (ISMS), 2010, S. 152±157. - 154 - Gordijn und Tan 2005 Gordijn, J. und Tan, Y.-H.: A Design Methodology for Modeling Trustworthy Value Webs, 2005. URL: http://e3value.few.vu.nl/docs/bibtex/pdf/Gordijn2005TrustWorthyWebs.pdf ± Überprüfungsdatum: 02.03.2010. Gordijn und Akkermans 2003 Gordijn, J. und Akkermans, H.: Value Based Requirements Engineering: Exploring Innovative e-Commerce Ideas, Bd. 2. In: Requirements Engineering. Springer, 2003 (8), S. 114±134. Gosling 2005 Gosling, J.: The Java language specification. Addison-Wesley, Upper Saddle River, 2005. Gronback 2009 Gronback, R. C.: Eclipse modeling project: A domain-specific language toolkit. Addison-Wesley, Upper Saddle River, 2009. Gröne und Keller 2004 Gröne, B. und Keller, F.: Conceptual Architecture Patterns: FMC-based Representations, 2004. URL: http://www.fmc- modeling.org/download/publications/groene_keller_2003- Conceptual_Architecture_Patterns_in_POSA.pdf ± Überprüfungsdatum: 29.11.2010. GS1 Germany 2002 GS1 Germany: EANCOM 2002, 2002. URL: http://www.gs1- germany.de/standards/ebusiness/stammdaten/index_ger.html ± Überprüfungsdatum: 21.02.2011. Haller 2005 Haller, S.: Dienstleistungsmanagement: Grundlagen, Konzepte, Instrumente. Gabler, Wiesbaden, 2005. Hars 1994 Hars, A.: Referenzmodelle: Grundlagen effizienter Datenmodellierung. Gabler, Wiesbaden, 1994. Hinderer 2005 Hinderer, H.: Eine Vorgehensweise zur Erstellung von Informationssystemen für die zwischenbetriebliche Zusammenarbeit im Vertrieb technischer Produkte. Universität Stuttgart, Institut für Arbeitswissenschaft und Technologiemanagement IAT, Stuttgart, 2005. - 155 - Hippner und Wilde 2007 Hippner, H. und Wilde, K. D. (Hrsg.): Grundlagen des CRM: Konzepte und Gestaltung. Gabler, Wiesbaden, 2007. Hirschmeier 2004 Hirschmeier, M.: Wirtschaftlichkeitsanalysen für IT-Investitionen. , Stuttgart, Zugl. Erlangen-Nürnberg, 2004. IBM 2002 IBM: (WSXL) Web Service Experience Language Version 2. 2002. URL: http://public.dhe.ibm.com/software/dw/specs/ws-wsxl/ws-wsxl2.pdf John F. Sowa und John A. Zachman 1992 John F. Sowa und John A. Zachman: Extending and Formalizing the Framework for Information Systems Architecture. In: IBM Systems Journal 31. 1992. Nr. 3, S. 590±616. URL: http://www.research.ibm.com/journal/sj/313/sowa.pdf Johnson et al. 1986 Johnson, E. M.; Scheuing, E. E. und Gaida, K. A.: Profitable Service Marketing. Dow Jones-Irwin, Homewood, 1986. Johnson und Scholes 1997 Johnson, G. und Scholes, K.: Exploring corporate strategy: Text and cases. Prentice Hall, London, 1997. Joung et al. 2009 Joung, Y.; El Zarki, M. und Jain, R.: A user model for personalization services. In: Proceedings of 4th International Conference on Digital Information Management ICDIM, 2009, S. 1±6. Kelkar 2002 Kelkar, O.: Ein Referenzmodell für elektronische Geschäftstransaktionen im zwischenbetrieblichen Geschäftsverkehr. Universität Stuttgart, Institut für Arbeitswissenschaft und Technologiemanagement IAT, Stuttgart, 2002. Keller und Wendt 2003 Keller, F. und Wendt, S.: FMC: An Approach Towards Architecture-Centric System Development, 2003. URL: http://www.fmc- modeling.org/download/publications/wendt_keller_2003-FMC_Architecture- Centric_Development.pdf ± Überprüfungsdatum: 29.11.2010. Kempf 2003 Kempf, F.: Referenzmodell zur integrierten Kommunikationsunterstützung von kooperierenden örtlich verteilten Akteuren. Universität Stuttgart, Institut für Arbeitswissenschaft und Technologiemanagement IAT, Stuttgart, 2003. - 156 - Kett 2010 Kett, H.: A business model approach for service engineering in the internet of services. In: K.-P Fähnrich (Hg.): Informatik 2010. Service Science - neue Perspektiven für die Informatik. Leipzig: Gesellschaft für Informatik, 2010, S. 539±544. Kett et al. 2009a Kett, H.; Scheithauer, G.; Weiner, N. und Weisbecker, A.: Integrated Service Engineering (ISE) for Service Ecosystems: An Interdisciplinary Methodology for the Internet of Servcies. In: IIMC International Information Management Corporation (Hrsg.): eChallenges e-2009 Conference Proceedings. IIMC, 2009. Kett et al. 2008 Kett, H.; Voigt, K.; Scheithauer, G. und Cardoso, J.: Service Engineering in Business Ecosystems. In: Ganz, W. et al. (Hrsg.): New horizons for the role and production of services. RESER 2008. : Conference proceedings. Fraunhofer IRB, Stuttgart, 2008, S. 0±22. Kett et al. 2009b Kett, H.; Kokemüller, J. und Weisbecker, A.: Erweiterung von ERP-Systemen zur Anbindung von Handelsvertretungen. In: ERP-Management 5. 2009. Nr. 3, S. 26±28. König et al. 2006 König, M. A.; McNee, W. S.; Guptill, B. T. und Cassell, J. L.: SaaS 2.0: Software-as- a-Service as Next-Gen Business Platform. Saugatuck, Westport, 2006. Kraemer und Dedrick 2000 Kraemer, K. L. und Dedrick, J.: Redefining and extending the business model with information technology: Dell Computer Corporation, Bd. 16. In: The Information Society, 2000, S. 5±21. Kruse 1996 Kruse, C.: Referenzmodellgestütztes Geschäftsprozessmanagement: Ein Ansatz zur prozessorientierten Gestaltung vertriebslogistischer Systeme. Gabler, Wiesbaden, 1996. Kuhn 2007 Kuhn, C.: Web 2.0: Auswirkungen auf internetbasierte Geschäftsmodelle. Diplomica Verlag, Hamburg, 2007. Lehmann und Buxmann 2009 Lehmann, S. und Buxmann, P.: Preisstrategien von Softwareanbietern, (6). In: Wirtschaftsinformatik, 2009 (51), S. 519±529. Lester 2001 Lester, J. (Hrsg.): Proceedings of 5th ACM International Conference on Intelligent User Interfaces IUI'2001. ACM Press, New York, 2001. - 157 - Lewis et al. 2005 /HZLV*$0RUULV(-6PLWK'%XQG2¶%ULHQ/6HUYLFH-Oriented Migration and Reuse Technique (SMART). In: STEP. IEEE Computer Society, 2005, S. 222±229. Linder und Cantrell 2000 Linder, J. und Cantrell, S.: Changing Business Models: Surveying the landscape. , Accenture Institute for Strategic Change, Cambridge, USA, 2000. Lorenz 2007 Lorenz, O. (Hrsg.): eBusiness 2007/2008: Jahrbuch der deutschen Wirtschaft. Wegweiser, Berlin, 2007. Lumpkin und Dess 2004 Lumpkin, G. T. und Dess, G.: E-Business Strategies and Internet Business Models - How the Internet Adds Value, Bd. 2. In: Organizational Dynamics, 2004 (33), S. 161±173. Luxem 2000 Luxem, R.: The Impact of Trading Digital Products on Retail Information Systems. In: Sprague, R. H. (Hrsg.): Proceedings of the 33rd Annual Hawaii International Conference on System Sciences. IEEE Computer Society, Los Alamitos, 2000. Marks und Bell 2006 Marks, E. A. und Bell, M.: Service-oriented architecture: A planning and implementation guide for business and technology. Wiley, Hoboken, 2006. Meier und Stormer 2005 Meier, A. und Stormer, H.: eBusiness & eCommerce: Management der digitalen Wertschöpfungskette. Springer, Berlin, 2005. Mertens et al. 2004 Mertens, P.;Stößlein, M. und Zeller, T.: Personalisierung und Benutzermodellierung in der betrieblichen Informationsverarbeitung ± Stand und Entwicklungsmöglichkeiten, 2004. URL: http://www.prof- mertens.de/veroeffentlichungen/download/Arbeitsbericht_WI_I_2_2004.pdf ± Überprüfungsdatum: 01.12.2010. Mucha 2004 Mucha, M.: Referenzmodell für ein Produktdaten Clearing Center - am Beispiel eines Informationsmodells für die Elektrowirtschaft. Universität Stuttgart, Institut für Arbeitswissenschaft und Technologiemanagement IAT, Stuttgart, 2004. Nash 1997 Nash, D.: ODETTE File Transfer Protocol, 1997. URL: http://www.ietf.org/rfc/rfc2204.txt ± Überprüfungsdatum: 21.02.2011. - 158 - Nieschlag et al. 1997 Nieschlag, R.; Dichtl, E. und Hörschgen, H.: Marketing. Duncker&Humblot, Berlin, 1997. Nüttgens und Dirik 2008 Nüttgens, M. und Dirik, I.: Geschäftsmodelle für dienstebasierte Informationssysteme - Ein strategischer Ansatz zur Vermarktung von Webservices, 2008-1. In: Wirtschaftsinformatik, 2008. OASIS 2007 OASIS: Web Services Business Process Execution Language Version 2.0, 2007. URL: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf ± Überprüfungsdatum: 01.12.2010. OASIS 2009 OASIS: Web Services Coordination (WS-Coordination) Version 1.2, 2009. URL: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec.pdf ± Überprüfungsdatum: 01.12.2010. OMG 2007 OMG: Unified Modeling Language (OMG UML), Superstructure, V2.1.2, 2007. URL: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML ± Überprüfungsdatum: 11.04.2011. OMG 2009 OMG: Business Process Model and Notation (BPMN), V1.2, 2009. URL: http://www.omg.org/spec/BPMN/1.2 ± Überprüfungsdatum: 11.04.2011. OMG 2010a OMG: Business Process Model and Notation (BPMN), V2.0 Beta2, 2010. URL: http://www.omg.org/spec/BPMN/2.0 ± Überprüfungsdatum: 11.04.2011. OMG 2010b OMG: OMG Unified Modeling Language (OMG UML), Infrastructure, 2010. URL: http://www.omg.org/spec/UML/2.3/ ± Überprüfungsdatum: 11.04.2011. Osterwalder 2004 Osterwalder, A.: The Business Model Ontology: A Proposition in a Design Science Approach. Université de Lausanne, Lausanne, 2004. URL: http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf ± Überprüfungsdatum: 11.04.2011. Osterwalder et al. 2005 Osterwalder, A.; Pigneur, Y. und Tucci, C. L.: Clarifyinig Business Models: Origins, Present, and Future of the Concept. In: Communications of AIS 15. 2005. - 159 - Osterwalder und Pigneur 2010 Osterwalder, A. und Pigneur, Y.: Business model generation: A handbook for visionaries, game changers, and challengers. Flash Reproductions, Toronto, 2010. Papazoglou 2003 Papazoglou, M. P.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering, 2003, S. 3±12. Papazoglou et al. 2006 Papazoglou, M. P.; Travero, P.; Dustaar, S.; Leymann, F. und Krämer, B.: Service- Oriented Computing: A Research Roadmap. In: Cubera, F. et al. (Hrsg.): Service Oriented Computing (SOC). Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, 2006, S. 1±29. Paternò und Santoro 2003 Paternò, F. und Santoro, C.: A Unified Method for Designing Interactive Systems Adaptable to Mobile and Stationary Platforms. In: Interacting with Computers, 2003 (15), S. 349±366. Paternò et al. 2008a Paternò, F.; Santoro, C.; Mantyjarvi, J.; Mori, G. und Sansone, S.: Authoring Pervasive MultiModal User Interfaces, Bd. 2. In: International Journal of Web Engineering and Technology, 2008. Paternò et al. 2008b Paternò, F.; Santoro, C. und Spano, L. D.: Designing Usable Applications based on Web Services. In: I-86('¶3LVD Perreault und Resnick 2010 Perreault, S. und Resnick, P.: vCard Format Specification: draft-ietf-vcarddav- vcardrev-15, 2010. URL: http://tools.ietf.org/pdf/draft-ietf-vcarddav-vcardrev-15.pdf ± Überprüfungsdatum: 21.02.2011. Picard et al. 2003 Picard, E.; Fierstone, J.; Pinna-Dery, A.-M. und Riveill, M.: Atelier de composition d'IHM et évaluation du modèle de composants. Livrable No. 3. Université de Nice, Laboratoire I3S, Nice.Livrable No. 3, 2003. URL: http://rainbow.essi.fr/amusing/publis/03-aspect-L3.pdf ± Überprüfungsdatum: 06.12.2010. Piller 1998 Piller, F. T.: Kundenindividuelle Massenproduktion: Die Wettbewerbsstrategie der Zukunft. Hanser, München, 1998. - 160 - Piller 2000 Piller, F. T.: Mass Customization. Picot, A., Reichwald, R. und Franck, E. (Hrsg.). Deutscher Universitäts-Verlag, Wiesbaden, 2000. Pine und Davis 1999 Pine, B. J. und Davis, S.: Mass Customization: The New Frontier in Business Competition. Harvard Business School Press, Boston, 1999. Pohl und Rupp 2009 Pohl, K. und Rupp, C.: Basiswissen Requirements Engineering: Aus- und Weiterbildung zum "Certified Professional for Requirements Engineering" ; Foundation Level nach IREB-Standard. dpunkt-Verl, Heidelberg, 2009. Porter 2000 Porter, M. E.: Wettbewerbsvorteile: Spitzenleistungen erreichen und behaupten (Competitive advantage). Campus-Verlag, Frankfurt/Main, 2000. Rai und Sambamurthy 2006 Rai, A. und Sambamurthy, V.: Editorial Notes - The Growth of Interest in Service Management: Opportunities for Information Systems Scholars. In: Information Systems Research 17. 2006. Nr. 4, S. 327±331. Rautenstrauch et al. 2002 Rautenstrauch, C.; Seelmann-Eggebert, R. und Turowski, K. (Hrsg.): Moving into Mass Customization. Springer, Berlin, 2002. Reichwald et al. 2000 Reichwald, R.; Goecke, R. und Stein, S.: Dienstleistungsengineering: Dienstleistungsvernetzung in Zukunftsmärkten. Verl. TCW Transfer-Centrum, München, 2000. Remmert 2001 Remmert, J.: Referenzmodellierung für die Handelslogistik. Dt. Univ.-Verlag, Wiesbaden, 2001. de Reuver et al. 2008 Reuver, M. de; Bouwman, H. und Koning, T. de: The Mobile Context Explored. In: Bouwman, H. et al. (Hrsg.): Mobile Service Innovation and Business Model. Springer, Berlin, Heidelberg, 2008, S. 89±114. Riedl et al. 2009 Riedl, C.; Leimeister, J. M. und Krcmar, H.: New Service Development for Electronic Services ± A Literature Review. In: Proceedings of the Fifteenth Americas Conference on Information Systems, San Francisco, 2009, S. 1±9. - 161 - Robertson und Robertson 2006 Robertson, S. und Robertson, J.: Mastering the requirements process. Addison- Wesley, Upper Saddle River, 2006. Röthig 2009 Röthig, P.: ICT-Investitionen begründen - Wirtschaftlichkeitsberechnungen mit dem WiBe-Konzept, 2009. URL: http://www.wibe.de/konzept/wibe_ueberblick/WiBe- ICT0902.pdf ± Überprüfungsdatum: 29.11.2010. Rump 1999 Rump, F. J.: Geschäftsprozessmanagement auf der Basis von ereignisgesteuerten Prozessketten: Formalisierung, Analyse und Ausführung von EPKs. Teubner, Stuttgart, 1999. Rupp 2007 Rupp, C.: Requirements-Engineering und -Management. Hanser, München, 2007. Rupp 2009 Rupp, C.: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis. Hanser, München, 2009. SAP 2003 SAP: Open Catalogue Interface (OCI), 2003. URL: http://www.attsuppliers.com/downloads/OCI_40_EN20030611.pdf ± Überprüfungsdatum: 21.02.2011. SAP Research 2009a SAP Research: Unified Service Description Language (USDL) - Core Module, 2009. URL: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0- module-core-M2-20091228.pdf ± Überprüfungsdatum: 01.12.2010. SAP Research 2009b SAP Research: Unified Service Description Language (USDL) - Functional Module, 2009. URL: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0- module-functional-M2-20091228.pdf ± Überprüfungsdatum: 01.12.2010. SAP Research 2009c SAP Research: Unified Service Description Language (USDL) - Interaction Module, 2009. URL: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0- module-interaction-M2-20091228.pdf ± Überprüfungsdatum: 01.12.2010. - 162 - SAP Research 2009d SAP Research: Unified Service Description Language (USDL) - Participants Module, 2009. URL: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0- module-participants-M2-20091228.pdf ± Überprüfungsdatum: 01.12.2010. SAP Research 2009e SAP Research: Unified Service Description Language (USDL) - Pricing Module, 2009. URL: http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0- module-pricing-M2-20091228_01.pdf ± Überprüfungsdatum: 01.12.2010. Schäfer 1999 Schäfer, H.: Unternehmensinvestitionen: Grundzüge in Theorie und Management. Physica-Verlag, Heidelberg, 1999. Scheer 1998 Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. Springer, Berlin, 1998. Scheer 2006 Scheer, A.-W.: ARIS - vom Geschäftsprozess zum Anwendungssystem. Springer, Berlin, 2006. Schmitz et al. 2009 Schmitz, V.;Kelkar, O.;Otto, B. und Weiner, N.: Spezifikation openTRANS V2.1, 2009. URL: www.opentrans.de ± Überprüfungsdatum: 21.02.2011. Schmitz et al. 2005 Schmitz, V.;Leukel, J. und Kelkar, O.: Spezifikation BMEcat 2005, 2005. URL: www.bmecat.org ± Überprüfungsdatum: 21.02.2011. Schneider und Scheer 2003 Schneider, K. und Scheer, A.-W.: Konzept zur systematischen und kundenorientierten Entwicklung von Dienstleistungen. Institut für Wirtschaftsinformatik (IWi), Saarbrücken, 2003. Schreiner und Nägele 2002 Schreiner, P. und Nägele, R.: Methodische Gestaltung kundenorientierter Dienstleistungsprozesse. In: IM - Fachzeitschrift für Information Management & Consulting 17. 2002, S. 72±76. Schulze 2000 Schulze, J.: Prozessorientierte Einführungsmethode für das Customer Relationship Management. Difo-Druck, Bamberg, 2000. - 163 - Schütte 1998 Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung: Konstruktion konfigurations- und anpassungsorientierter Modelle. Gabler, Wiesbaden, 1998. Sehmi und Schwegler 2006 Sehmi, A. und Schwegler, B.: Service-Oriented Modeling for Connected Systems: Service-Oriented Modeling for Connected Systems. 2006. URL: http://download.microsoft.com/download/4/d/a/4da0ddee-77e0-47d1-aaa7- a5dd619b8bca/journal7_english.pdf.zip Sellien und Sellien 1988 Sellien, R. und Sellien, H. (Hrsg.): Wirtschaftslexikon. Gabler, Wiesbaden, 1988. Shahzad et al. 2009 Shahzad, S. K.; Granitzer, M. und Tochterman, K.: Designing User Interfaces through Ontological User Model - Functional Programming Approach. In: Proceedings of 4th International Conference on Computer Sciences and Convergence Information Technology, 2009, S. 99±104. Shostack 1982 Shostack, G. L.: How to Design a Service. In: European Journal of Marketing. 1982. Nr. 161, S. 49±63. Shostack 1984 Shostack, G. L.: Designing Services that Deliver. In: Harvard Business Review. 1984. Nr. 62, S. 133±139. Spath et al. 2008a Spath, D.; Weisbecker, A. und Kett, H. (Hrsg.): Mobile Multilieferanten- Vertriebsinformationssysteme für Handelsvertretungen und -vermittlungen. Fraunhofer IRB, Stuttgart, 2008. Spath et al. 2008b Spath, D.; Ganz, W. und Tombeil, A.-S.: Introduction. In: Spath, D. (Hrsg.): The Future of Services : Trends and Perspectives. Hanser, München, 2008, S. 1±13. Specht et al. 2006 Specht, T.; Drawehn, J. und Höß, O.: Domänenspezifische Modellierung von E- Government-Szenarien. In: Fähnrich, K.-P. (Hrsg.): Integration betrieblicher Informationssysteme : Problemanalysen und Lösungsansätze des Model-Driven- Integration-Engineering. LIV, Leipzig, 2006 (Leipziger Beiträge zur Informatik, 4), S. 80±93. - 164 - Speyer et al. 2007 Speyer, M.; Brown, E. G.; van Metre, E. und Lee, C.: SaaS Economics Will Change ,69V¶6,$QG9$5&KDQQHOV &KDQQHO0DQDJHUV5HWRRO3DUWQHU3URJUDPV7R Prevent SaaS Delivery Disaster. Forrester, Cambridge, USA, 2007. Stachowiak 1973 Stachowiak, H.: Allgemeine Modelltheorie. Springer, Wien, 1973. Stähler Stähler, P.: Geschäftsmodelle in der digitalen Ökonomie. 2. Aufl. Josef Eul Verlag, Lohmar, St.Gallen, Statistisches Bundesamt 2009 Statistisches Bundesamt: Statistisches Jahrbuch für die Bundesrepublik Deutschland 2009. Statistisches Bundesamt, Wiesbaden, 2009. Steinberg et al. 2009 Steinberg, D.; Budinsky, F.; Paternostro, M. und Merks, E.: EMF: Eclipse modeling framework. Addison-Wesley, Upper Saddle River, 2009. Supply Chain Council 2010 Supply Chain Council: SCOR 10.0 Overview Booklet. Supply Chain Council, Cypress, 2010. Tapscott et al. 2000 Tapscott, D.; Ticoll, D. und Lowy, A.: Digital capital: Harnessing the power of business webs. Harvard Business School Press, Boston, 2000. Timmers 1998 Timmers, P.: Business Models for Electronic Markets. In: Electronic Markets, 1998 (8), S. 3±8. Vanderdonckt 2005 Vanderdonckt, J.: A MDA-Compliant Environment for Developing User Interfaces of Information Systems. In: Proceedings of 17th Conference on Advanced Information Systems Engineering CAiSE'05. Springer, Berlin, 2005, S. 16±31. Vom Brocke 2003 Vom Brocke, J.: Referenzmodellierung: Gestaltung und Verteilung von Konstruktionsprozessen. Logos, Berlin, 2003. W3C 2002 W3C: Web Service Choreography Interface (WSCI) 1.0, 2002. URL: http://www.w3.org/TR/wsci/ ± Überprüfungsdatum: 01.12.2010. - 165 - W3C 2004a W3C: XML Schema Part 0: Primer Second Edition, 2004. URL: http://www.w3.org/TR/xmlschema-0/ ± Überprüfungsdatum: 01.12.2010. W3C 2004b W3C: XML Schema Part 1: Structures Second Edition, 2004. URL: http://www.w3.org/TR/xmlschema-1/ ± Überprüfungsdatum: 01.12.2010. W3C 2004c W3C: XML Schema Part 2: Datatypes Second Edition, 2004. URL: http://www.w3.org/TR/xmlschema-2/ ± Überprüfungsdatum: 01.12.2010. W3C 2005 W3C: Web Services Choreography Description Language Version 1.0, 2005. URL: http://www.w3.org/TR/ws-cdl-10/ ± Überprüfungsdatum: 01.12.2010. W3C 2007a W3C: SOAP Version 1.2, 2007. URL: http://www.w3.org/TR/soap/ ± Überprüfungsdatum: 01.12.2010. W3C 2007b W3C: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 2007. URL: http://www.w3.org/TR/wsdl20/ ± Überprüfungsdatum: 01.12.2010. W3C 2009a W3C: OWL 2 Web Ontology Language - Document Overview, 2009. URL: http://www.w3.org/TR/owl2-overview/ ± Überprüfungsdatum: 01.12.2010. W3C 2009b W3C: Web Services Atomic Transaction (WS-AtomicTransaction) Version 1.2, 2009. URL: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec.pdf ± Überprüfungsdatum: 01.12.2010. W3C 2009c W3C: Web Services Business Activity (WS-BusinessActivity) Version 1.2, 2009. URL: http://docs.oasis-open.org/ws-tx/wstx-wsba-1.2-spec.pdf ± Überprüfungsdatum: 01.12.2010. W3C 2010 W3C: W3C XML Schema Definition Language (XSD): Component Designators, 2010. URL: http://www.w3.org/TR/xmlschema-ref/ ± Überprüfungsdatum: 01.12.2010. - 166 - Weidmann et al. 2010 Weidmann, M.; Renner, T. und Rex, S.: Cloud Computing in der Versicherungsbranche: IT-Trends im Internet der Dienste aus der Sicht von Anwendern und Anbietern. Fraunhofer IRB, Stuttgart, 2010. Weill und Vitale 2001 Weill, P. und Vitale, M. R.: Place to space: Migrating to ebusiness models. Harvard Business School Press, Boston, 2001. Weiner et al. 2010 Weiner, N.; Renner, T. und Kett, H.: Geschäftsmodelle im Internet der Dienste: Trends und Entwicklungen auf dem deutschen IT-Markt. Fraunhofer IRB, Stuttgart, 2010. Weisbecker 2002 Weisbecker, A.: Software-Management für komponentenbasierte Software- Entwicklung. Jost Jetter, Heimsheim, 2002. Wendt 1991 Wendt, S.: Nichtphysikalische Grundlagen der Informationstechnik: Interpretierte Formalismen: Nichtphysikalische Grundlagen der Informationstechnik: Interpretierte Formalismen. Potsdam : Hasso-Plattner-Institut für Softwaretechnik, 1991 Westkämper 2006 Westkämper, E.: Einführung in die Organisation der Produktion. Springer, Berlin, Heidelberg, 2006. Wirtz 2000 Wirtz, B. W.: Electronic Business. Gabler, Wiesbaden, 2000. Wirtz 2010 Wirtz, B. W.: Business Model Management: Design - Instrumente - Erfolgsfaktoren von Geschäftsmodellen. Gabler, Wiesbaden, 2010. Wöhe und Döring 2010 Wöhe, G. und Döring, U.: Einführung in die allgemeine Betriebswirtschaftslehre. Vahlen, München, 2010. Yang et al. 2009 Yang, Y.; Aufaure, M.-A. und Claramunt, C.: Towards a DL-based semantic user model for web personalization. In: Proceedings of the 3rd International Conference on Autonomic and Autonomous Systems (ICAS'07), 2009, S. 61-61. - 167 - Zachman 1987 Zachman, J. A.: A Framework for Information Systems Architecture. In: IBM Systems Journal 26. 1987. Nr. 3, S. 276±292. URL: http://www.research.ibm.com/journal/sj/263/ibmsj2603E.pdf Zimmermann 2009 Zimmermann, O.: An architectural decision modeling framework for service-oriented architecture design. Univ, Stuttgart, 2009. URL: http://nbn- resolving.de/urn:nbn:de:bsz:93-opus-52287 Zimmermann et al. 2005 Zimmermann, O.;Schlimm, N.;Waller, G. und Pestel, M.: Analysis and Design Techniques for Service-Oriented Development and Integration, 2005. URL: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.91.3477 ± Überprüfungsdatum: 12.04.2011. Zimmermann et al. 2004 Zimmermann, O.;Krogdahl, P. und Gee, C.: Elements of Service-Oriented Analysis and Design - An interdisciplinary modeling approach for SOA projects, 2004. URL: http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/ ± Überprüfungsdatum: 12.04.2011. Anhang A: Gesetzlicher Rahmen von Handelsvertretungen Für die Arbeiten der Handelsvertretungen und -vermittlungen existiert ein gesetzlicher Rahmen, der die Ausgangssituation beeinflusst. Die folgenden grundlegenden Rechte und Pflichten (R) sind im siebten Abschnitt des ersten Buchs des HGB explizit oder implizit (verdeutlicht durch Gerichtsurteile des BGH) geregelt: R1: Provisionsanspruch: Der Handelsvertreter besitzt einen Provisionsanspruch für alle während des Vertragsverhältnisses abgeschlossenen Geschäfte, die auf seine Tätigkeit zurückzuführen sind (in § 87 HGB geregelt). Die Provisionszahlung bei Reklamationen wurde vom BGH in einigen Urteilen entschieden, u. a. für die Fälle bei verspäteter Lieferung, Schlechtlieferung und Retouren, Wunsch des Kunden nach Stornierung, Risiko der Selbstbelieferung und der Arbeitskräfte. R2: Anspruch auf Buchauszug: Es besteht ein Anspruch des Handelsvertreters auf einen Buchauszug, den er ggf. beim Anbieter einfordern und sogar die Bücher des Anbieters, für den er tätig ist, einsehen kann (in § 87c HGB geregelt). R3: Bemühungs- und Benachrichtigungspflicht: Der Handelsvertreter hat sich um die Vermittlung bzw. um den Abschluss von Geschäften zu bemühen und unverzüglich, d. h. gemäß ständiger Rechtsprechung binnen drei Werktagen von seinen Abschlüssen zu unterrichten sowie in regelmäßigen Abständen (verkehrsüblich wöchentlich bis monatlich) über die Marktentwicklung zu berichten und die Pflichten eines ordentlichen Kaufmannes zu erfüllen. Das Interesse des Unternehmens ist dabei zu berücksichtigen. Dazu gehören die seriöse Beratung der Kunden, die korrekte Benennung von Preisen und Konditionen des Anbieters und ein wettbewerbsrechtlich einwandfreies Verhalten (in § 86 HGB Bemühungs- und Benachrichtigungspflicht geregelt). R4: Wettbewerbsverbot: Ein Wettbewerbsverbot ist nicht ausdrücklich im Gesetz aufgeführt, ergibt sich jedoch aus der allgemeinen Interessenwahrnehmungs- pflicht des Handelsvertreters und ist gem. ständiger Rechtsprechung eng auszulegen. Anhand der identifizierten Optimierungspotenziale konnten Anforderungen an das Referenzmodell erstellt werden, die im nachfolgenden Abschnitt aufgeführt werden. Anhang B: Use Cases der Informationsplattform (Beschreibung) Designprinzipien In diesem Abschnitt wird beschrieben, wie die geeignete IT-technische Unterstützung der Prozesse aus fachlicher Sicht gestaltet sein sollte. Darunter werden vor allem Funktionen verstanden, die durch die webbasierte Informationsplattform bereitgestellt werden. Die Funktionen werden anhand von Use Cases (Anwendungsfällen) beschrieben (OMG 2007). Die Beschreibung der Use Cases basiert auf einer angepassten Struktur von Balzert (Balzert 2000). Zur lückenlosen Ableitung der Use Cases erfolgte eine Zuordnung der Use Cases zu den einzelnen Prozessen der Handelsvertreter basierend auf der Umfrage von Spath et al. (2008a). Hierbei können diesselben Use Cases in mehreren Prozessen auftreten und werden in diesen Fällen nur einmal festgelegt und beschrieben. Ein Hinweis auf die passende Use Case Beschreibung erfolgt in diesen Fällen bei den jeweiligen Prozessen. - 170 - B.1 Darstellung der Use Cases aus Handelsvertretersicht B.1.1 Gesprächsvorbereitung B.1.1.1 Kundengespräch vorbereiten Ziel: Zusammenstellung von Informationen zur erfolgreichen und strukturierten Durchführung eines Kundengesprächs Vorbedingung: - Auslösendes Ereignis: Kundengespräch steht an Beschreibung: Der Handelsvertreter ruft über die Informationsplattform relevante Vertriebsinformationen für den jeweiligen Kunden ab. Dazu gibt er den jeweiligen Kunden bzw. dessen Kundennummer in das System ein. Die entsprechenden Vertriebsinformationen werden dann von der Informationsplattform als druckbarer Bericht (z. B. im PDF-Format) ausgegeben. Akteure: Handelsvertreter Ergebnis: Auflistung aller für das Kundengespräch relevanter Vertriebsinforma- tionen in Form eines druckbaren Reports: ± Planzahlen des Kunden (z. B. geplanter Umsatz je Kunde je Produkt/-gruppe), ± aktuelle Zahlen des Kunden (z. B. aktueller Umsatz je Kunde je Produkt/-gruppe), ± Abgleich Planzahlen mit aktuellen Zahlen des Kunden (z. B. Darstellung der Unter- bzw. Überdeckung), ± Status von aktuellen Geschäftsvorfällen, wie Angebotsanfragen, Angebote, Bestellungen, Lieferung, Rechnungen und Reklamationen, ± Summe aller offenen Rechnungen des Kunden (Rechnung/Lieferung wurde versendet, aber Zahlungstermin noch nicht erreicht. Zahlungstermin hängt von den Zahlungs- bedingungen des Kunden ab. Berechnet wird das Zahlungsziel ab dem späteren Termin von Rechnungs- bzw. Warenversand. Beim Eintreffen der Zahlung beim Hersteller wird die Provision für den Handelsvertreter fällig), ± Summe aller offenen und überfälligen Rechnungen des Kunden (Rechnung/Lieferung wurde versendet und Zahlungstermin wurde - 171 - überschritten), ± Liste aller (neuen) Produkte, die vorgestellt werden sollen (Die Produkte müssen vom Hersteller als neue Produkte gekenn- zeichnet werden. Hierbei wird das jeweilige Produkt mit dem Merkmal »Neuerscheinung« ausgezeichnet) ĺEHVWHQIDOOVIKUHQ diese Produkte direkt in Bestellungen bzw. konkrete Änderungen werden im Gespräch aufgenommen, ± Offene Punkte im Rahmen von Projekten, die mit dem Kunden geklärt werden müssen bzw. mit dem Hersteller geklärt werden mussten, ± Liste aller YHUVHQGHWHQ0XVWHUWHLOHPLWRIIHQHP6WDWXVĺEHVWHQ- falls führen diese Produkte direkt in Bestellungen bzw. konkrete Änderungen werden im Gespräch aufgenommen, ± Aufführen der letzten Besuchsberichte bei dem jeweiligen Kunden und der jeweiligen Aktionspunkte (z. B. Bearbeitungsstatus erledigt bzw. offen), ± Liste aller sonstigen Themen, die im Rahmen des Kundengesprächs durchgesprochen werden sollten. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Gesprächsvorbereitung werden protokolliert. Erweiterungen: Der Bericht wird auf der Plattform zusammengestellt. Die zusammengestellten Punkte können vom Handelsvertreter als Strukturvorgabe für die Erstellung eines Besuchsberichts über- nommen werden. Alternativen: - - 172 - B.1.1.2 Informationsausgabe für Kundengespräche konfigurieren Ziel: Konfiguration der Informationsausgabe für ein Kundengespräch in Inhalten, Struktur und Format. Vorbedingung: - Auslösendes Ereignis: Die aktuelle Informationsausgabe ist nicht geeignet für die Durchführung der Kundengespräche und muss daher abgeändert werden. Beschreibung: Der Handelsvertreter spezifiziert auf der Informationsplattform folgende Parameter: ± Welche Inhalte werden für die Gesprächsvorbereitung im Rahmen einer Zusammenstellung aufgeführt? ± In welcher Struktur werden die Inhalte in der Zusammenstellung dargestellt? ± Welche Formate haben die dargestellten Inhalte? Akteure: Handelsvertreter, Plattformbetreiber Ergebnis: Konfiguration der Informationsausgabe (Zusammenstellung) Nachbedingung Erfolg: Konfiguration ist auf der webbasierten Informationsplattform hinterlegt und wird bei der Vorbereitung von Kundengesprächen zur Festlegung der Informationsausgabe herangezogen. Nachbedingung Fehlschlag: Fehlermeldungen bei der Konfiguration werden protokolliert. Erweiterungen: - Alternativen: - - 173 - B.1.2 Vorstellung von Produkten B.1.2.1 Produkte suchen (Übersicht) Ziel: Suchen von angefragten Produkten Vorbedingung: Kundenanfrage nach einer Lösung oder einem Produkt bzw. Dienstleistung Auslösendes Ereignis: Eingehende Kundenanfrage Beschreibung: Der Handelsvertreter sucht nach dem Produkt durch Spezifikation, Katalogsystem und ggf. Kombination folgender Parameter: ± der Artikelnummer, ± der Produktbezeichnung, ± einer Klassifikation, ± technischer Merkmale. Die gefundenen Produkte werden tabellarisch aufgelistet. Hierzu werden die folgenden Informationen zu den einzelnen Produkten angezeigt: ± Artikelnummer, ± Produktbezeichnung, ± Produktkurzbeschreibung, ± Hersteller, ± ggf. Verfügbarkeit, ± ggf. Lieferzeit/Liefertermin, ± Preis Akteure: Handelsvertreter Ergebnis: Liste eines bzw. mehrerer Produkte bzw. Dienstleistungen, die die Suchkriterien erfüllen Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Produktsuche werden protokolliert. Erweiterungen: - Alternativen: - - 174 - B.1.2.2 Multimediale Informationen abrufen und präsentieren Ziel: Abrufen und präsentieren von multimedialen Produktinformationen Vorbedingung: Handelsvertreter hat das angefragte Produkt gesucht und gefunden (Auswahl liegt vor, siehe Produkte suchen). Auslösendes Ereignis: Kundenanfrage bzw. -wunsch nach der Präsentation eines Produktes Beschreibung: Der Kunde äußert im Rahmen eines Kundengesprächs Interesse an einer Produktvorstellung. Nachdem das betroffene Produkt ausgewählt wurde, ruft der Vertreter die Detaildarstellung des Produkts auf (siehe auch Use Case Produkte suchen (Übersicht)). Als ein Teil der Detaildarstellung von Produkten können Produktpräsentationen abgerufen und abgespielt (z. B. über installierte Media- Player/Präsentationssoftware auf den mobilen sowie stationären Geräten) werden. Akteure: Handelsvertreter, (Kunde) Ergebnis: Abruf und Abspielen von Produktpräsentationen (z. B. elektronische Präsentationen und Videos) Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Abruf einer Produktpräsentation werden protokolliert. Erweiterungen: - Alternativen: - B.1.3 Bereitstellung von Produktinformationen für Kunden B.1.3.1 Produkte suchen (Übersicht) Der Use Case zur Suche nach Produkten ist unter »Produkte suchen« beschrieben. - 175 - B.1.3.1.1 Elektronische Produktinformationen abrufen (Detailsicht) Ziel: Abrufen elektronischer Produktinformationen Vorbedingung: Kundenanfrage nach Details zu einem Produkt bzw. Dienstleistung Auslösendes Ereignis: Eingehende Kundenanfrage Beschreibung: Um weitere Details von Produkten zu erhalten, wählt der Handelsvertreter durch Anklicken ein Produkt aus. Von der tabellarischen Produktübersicht gelangt er dann in die Detailansicht eines einzelnen Produkts bzw. eines Produkttyps. Neben den Produktinformationen, die schon in der tabellarischen Übersicht der Produkte aufgeführt wurden (siehe Produkte suchen), werden weitere Informationen dargestellt: ± (technische) Merkmale, ± Verkaufsvorteile des Produkts, ± Analysen von Konkurrenzprodukten, ± Marketingtexte, ± Dokumente mit weiterführenden Produktinformationen, ± Multimediale Produktpräsentation(en). Akteure: Handelsvertreter Ergebnis: Anzeige und Auswahl von Detailinformationen zu ausgewählten Produkten und Dienstleistungen. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: - Erweiterungen: Ausgewählte Detailinformationen können durch den Handelsvertreter selektiert (in eine Art Warenkorb gelegt) werden. Detailinformationen in diesem Kontext sind z. B. Datenblätter, Ersatzteillisten, sonstige Tabellen, Handbücher, Gebrauchsanweisungen und Approbationen. Alternativen: - - 176 - B.1.3.1.2 Elektronische Produktinformationen an Kunden versenden Ziel: Versenden elektronischer Produktinformationen an Kunden Vorbedingung: Kundenanfrage nach Details zu einem Produkt bzw. einer Dienstleistung, die elektronisch in Form von Dokumenten (z. B. Tabellen, Handbüchern, Gebrauchsanweisungen und Approbationen) zugestellt werden. Auslösendes Ereignis: Eingehende Kundenanfrage Beschreibung: Der Handelsvertreter kann die Auswahl an Detailinformationen an eine E-Mailadresse versenden. Hierzu wird eine E-Mailadresse aus einer Kontaktdatenbank ausgewählt. Diese Informationen können durch ein Anschreiben ergänzt werden. Die Detailinformationen werden als PDF- Dokumente im Anhang der E-Mail versendet. Nach Versand der E-Mail wird diese gespeichert, so dass sie später bei Nachfragen wieder abgerufen und ggf. erneut versendet werden kann. Akteure: Handelsvertreter Ergebnis: Versand von Detailinformationen zu ausgewählten Produkten und Dienstleistungen. Nachbedingung Erfolg: Der erfolgreiche Versand der Detailinformationen wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Versand der Detailinformationen werden protokolliert. Erweiterungen: - Alternativen: - - 177 - B.1.4 Bereitstellung von Produktmustern B.1.4.1 Antrag Mustervergabe verwalten/versenden Ziel: Anlegen eines Antrags für die Mustervergabe Vorbedingung: - Auslösendes Ereignis: Anfrage eines Kunden nach einem Produktmuster Beschreibung: Um als Handelsvertreter den Hintergrund einer Anfrage nach einem Produktmuster zu erfahren, werden vor der Mustervergabe einige Informationen beim Kunden abgefragt. Diese Abfrage erfolgt über ein Formular. Folgende Informationen können für Handelsvertreter interessant sein: ± Produktbezeichnung, ± Grund des Interesses (z. B. Testen des Musters ohne/mit konkreter Projektidee), ± Ggf. Benennung eines Projekts (inkl. Zielsetzung, (geplanter) Beginn/ Fertigstellung der Entwicklung, (geplanter) Beginn/ Fertigstellung einer Vorserie, (geplanter) Beginn der Serien- produktion, (technische) Anforderungen an das Produkt, weitere Hintergrundinformationen), ± Forcast der voraussichtlich benötigten Menge des Produkts für die nächsten drei Jahre Nach Fertigstellung des Antrags kann dieser im Vertriebsinformations- system gespeichert bzw. an einen Hersteller versendet werden. Akteure: Handelsvertreter, (Kunde) Ergebnis: Ausgefüllter Antrag zur Mustervergabe Nachbedingung Erfolg: Die Eingabe/Versand des Antrags wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Eingabe/Versand des Antrags werden protokolliert. Erweiterungen: - Alternativen: - - 178 - B.1.4.2 Kundenfeedback zur Musterprüfung inklusive Statusvergabe verwalten Ziel: Einpflegen des Kundenfeedbacks zur Musterprüfung durch den Handelsvertreter Vorbedingung: Antrag für die Mustervergabe ist angelegt und Muster ausgegeben. Auslösendes Ereignis: Kunde gibt Feedback während/nach der Prüfung eines Musters. Beschreibung: Nach einiger Zeit fragt der Handelsvertreter beim Kunden das Feedback zum Produktmuster an. Das Feedback konkretisiert die im »Antrag Mustervergabe verwalten/versenden« aufgenommenen Informationen und beinhaltet darüber hinaus die Eignung des Produkts für das konkrete Projekt. Des Weiteren werden Gründe aufgenommen, warum ein Produkt für den Einsatz in einem Produkt/Projekt ggf. nicht geeignet ist. Der Mustervergabe kann ein Status zugeordnet werden, wie z. B.: ± Offen, ± Abgeschlossen (mit Auftrag), ± Abgeschlossen (ohne Auftrag). Akteure: Handelsvertreter, (Kunde) Ergebnis: Eingepflegtes Kundenfeedback Nachbedingung Erfolg: Die Eingabe des Kundenfeedbacks wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Eingabe des Kundenfeedback werden protokolliert. Erweiterungen: - Alternativen: - - 179 - B.1.4.3 Informationen über eine Mustervergabe verwalten Ziel: Abrufen von Informationen über Mustervergaben (Antrag/Feedback) Vorbedingung: Antrag einer Mustervergabe muss angelegt sein Auslösendes Ereignis: Verwalten von Informationen der Mustervergabe Beschreibung: Der Handelsvertreter kann nach Mustervergaben anhand verschiedener Kriterien suchen. Die Auswahlkriterien sind: ± Kunde, ± Produkt, ± Datum der Mustervergabe, ± Datum des erwarteten Feedback, ± Projektinformationen. Der Handelsvertreter erhält daraufhin eine Liste der passenden Mustervergaben. Durch die Auswahl einer Mustervergabe gelangt er in die Detailansicht inklusive Antrag und ggf. Feedback, falls vorhanden. Akteure: Handelsvertreter Ergebnis: Liste von Mustervergaben bzw. Detailinformationen einer Mustervergabe Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Auflistung und Darstellung von Mustervergaben werden protokolliert. Erweiterungen: - Alternativen: - - 180 - B.1.5 Unterstützung und Beratung bei der Auswahl von Standardprodukten B.1.5.1 Produkte suchen (Übersicht) Der Use Case zur Suche nach Produkten ist in »Produkte suchen (Übersicht)« beschrieben. B.1.5.2 Elektronische Produktinformationen abrufen (Detailsicht) Der Use Case zum Abruf von Produktinformationen ist in »Produkte suchen« beschrieben. - 181 - B1.5.3 Produkte in Warenkorb legen Ziel: Selektion von Produkten in Warenkorb Vorbedingung: - Auslösendes Ereignis: Ein Kunde fragt ein Angebot über ein oder mehrere Produkte an bzw. möchte eine Bestellung aufgeben. Beschreibung: Die Anfrage kann per Fax, per E-Mail oder persönlich, z. B. im Rahmen eines Kundengesprächs oder per Telefon erfolgen. Der Handelsvertreter wählt die gewünschten Produkte aus und legt diese in den Warenkorb. Zu jeder Position kann der Handelsvertreter die gewünschten Bestellmengen und ergänzende Kommentare aufführen. Akteure: Handelsvertreter, (Kunde) Ergebnis: Ausgewählte Produkte im Warenkorb Nachbedingung Erfolg: Das erfolgreiche Anlegen eines Warenkorbs inklusive dessen Befüllung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Anlegen des Warenkorbs und dessen Befüllung werden protokolliert. Erweiterungen: Der Warenkorb kann einem Kunden zugeordnet und zwischengespeichert werden. Zu einem späteren Zeitpunkt kann der Warenkorb wieder aufgerufen und weiter bearbeitet bzw. als Angebotsanfrage/Bestellung an einen Hersteller versendet werden. Alternativen: - - 182 - B.1.5.4 Angebotsanfrage/Bestellung aus Warenkorb erstellen Ziel: Erstellen einer Angebotsanfrage bzw. einer Bestellung aus dem Warenkorb Vorbedingung: Ausgewählte Produkte liegen im Warenkorb vor. Auslösendes Ereignis: Ein Kunde fragt ein Angebot über ein oder mehrere Produkte an bzw. möchte eine Bestellung aufgeben. Beschreibung: Mit den ausgewählten Produkten im Warenkorb wird eine Angebots- anfrage bzw. eine Bestellung angelegt. Neben ausgewählten Produkten und Bestellmengen muss für die Angebotsanfrage bzw. die Bestellung ein Zieldatum für die Lieferung und der Kunde angegeben werden. Akteure: Handelsvertreter Ergebnis: Angebotsanfrage bzw. Bestellung im Vertriebsinformationssystem angelegt. Inhaltliche Struktur der beiden Dokumente basiert auf RFQ und ORDER von openTRANS (siehe www.opentrans.de). Nachbedingung Erfolg: Die Anlage der Angebotsanfrage bzw. der Bestellung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Anlegen der Angebotsanfrage bzw. der Bestellung werden protokolliert. Erweiterungen: - Alternativen: - - 183 - B.1.6 Konfiguration komplexer Produkte B.1.6.1 Produkt konfigurieren Ziel: Konfigurieren von komplexen Produkten Vorbedingung: - Auslösendes Ereignis: Kunde fragt ein komplexes Produkt an und stellt besondere Anforderungen daran. Beschreibung: Der Handelsvertreter konfiguriert ein Produkt gemäß den Anforderungen eines Kunden. Da die Konfiguration stark vom Produkt selber abhängt, sollten Hersteller hier die Möglichkeit haben ihre eigenen Konfiguratoren in das Vertriebsinformationssystem einzubinden. Akteure: Handelsvertreter, (Kunde) Ergebnis: Fertiggestellte Produktkonfiguration Nachbedingung Erfolg: Die Produktkonfiguration wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Produktkonfiguration werden protokolliert. Erweiterungen: - Alternativen: - - 184 - B.1.6.2 Produktkonfiguration abspeichern/verwalten Ziel: Speichern und verwalten von Produktkonfigurationen Vorbedingung: Produktkonfiguration ist angelegt. Auslösendes Ereignis: Fertigstellung einer Produktkonfiguration Beschreibung: Der Handelsvertreter speichert die Produktkonfiguration im System ab. Die abgespeicherten Produktkonfigurationen kann er einsehen. Hierzu kann er nach Produktkonfiguration anhand folgender Kriterien suchen: ± Kunde, ± Produktbezeichnung, ± Produktgruppe, ± Erstelldatum, ± Anmerkungen. Die den Suchkriterien entsprechenden Produktkonfigurationen werden tabellarisch aufgelistet. Zur Identifikation der Produktkonfigurationen werden die oben aufgeführten Kriterien verwendet und in der Tabelle dargestellt. Akteure: Handelsvertreter Ergebnis: Gespeicherte Produktkonfiguration, auf die der Handelsvertreter wieder zugreifen kann. Nachbedingung Erfolg: Das Abspeichern der Produktkonfiguration wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Speichern der Produktkonfiguration werden protokolliert. Erweiterungen: - Alternativen: - - 185 - B.1.6.3 Produktkonfiguration in Angebotsanfrage/Bestellung überführen Ziel: Überführen einer Produktkonfiguration in eine Angebots- anfrage/Bestellung Vorbedingung: Produktkonfiguration ist angelegt. Auslösendes Ereignis: Eine Angebotsanfrage bzw. eine Bestellung über ein vorher konfiguriertes Produkt liegt vor. Beschreibung: Nach der Konfiguration eines Produktes ist ein Kunde an einem Angebot interessiert bzw. möchte das Produkt sofort bestellen. In diesem Fall überführt der Handelsvertreter die vorliegende Produktkonfiguration in eine Angebotsanfrage bzw. eine Bestellung. Die Bestellposition des Produktes muss eine eindeutige Identifikation erhalten (z. B. Matchcode, einem mehrstelligen Schlüssel, bei dem die einzelnen Ausprägungen eines Produktes eindeutig spezifiziert sind) Akteure: Handelsvertreter Ergebnis: Angebotsanfrage bzw. Bestellung Nachbedingung Erfolg: Die Überführung einer Angebotsanfrage bzw. einer Bestellung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Überführung der Produktkonfiguration in eine Angebotsanfrage bzw. eine Bestellung werden protokolliert. Erweiterungen: - Alternativen: - - 186 - B.1.7 Kundenspezifische Entwicklung von Individualprodukten B.1.7.1 Projekt anlegen Ziel: Anlegen von Projekten Vorbedingung: - Auslösendes Ereignis: Kunde möchte mit dem Handelsvertreter ein Entwicklungsprojekt durchführen Beschreibung: Der Handelsvertreter legt im Vertriebsinformationssystem ein Projekt an und muss dazu folgende Informationen zum Projekt angeben: ± Name des Projekts, ± Akronym, ± Kunde, ± Betroffene Hersteller, ± Projektbeginn, ± Voraussichtliches Projektende, ± Zielsetzung des Projekts, ± Geplantes Budget. Nach Anlage des Projekts steht dem Handelsvertreter ein Projektraum zur Verfügung, der zum einen die Korrespondenz zum Projekt, zum anderen dazugehörende Dokumente verwaltet. Akteure: Handelsvertreter Ergebnis: Angelegtes Projekt Nachbedingung Erfolg: Die Anlage eines neuen Projekts wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Anlage eines Projekts werden protokolliert. Erweiterungen: Der Hersteller hat ebenso Zugriff auf den Projektraum über den Webclient und kann direkt Nachrichten bzw. Dokumente einstellen. Um Nachrichten nicht zu verpassen, werden parallel zur Korrespondenz im System E-Mail-Nachrichten an die Projektteilnehmer versendet. Diese Funktion ist persönlich ein- oder ausschaltbar. Alternativen: - - 187 - B.1.7.2 Korrespondenz zum Projekt verwalten/versenden Ziel: Versenden und verwalten von Korrespondenz zum Projekt Vorbedingung: Projektraum muss angelegt sein Auslösendes Ereignis: Anlass aus dem Projektkontext heraus. Beschreibung: Der Handelsvertreter kann E-Mails aus seiner E-Mailverwaltung einem Projekt zuordnen. Die E-Mails können durch den Handelsvertreter beliebig klassifiziert werden. Ebenso kann er eine Korrespondenz aus dem Vertriebsinformationssystem versenden bzw. einsehen und diese mit weiteren Informationen, z. B. Dokumenten verknüpfen. Akteure: Handelsvertreter, Kunde, Hersteller Ergebnis: Korrespondenz zum Versand bzw. zur Verwaltung Nachbedingung Erfolg: Die erfolgreiche Durchführung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei diesen Vorgängen werden protokolliert. Erweiterungen: - Alternativen: - - 188 - B.1.7.3 Dokumente zum Projekt verwalten Ziel: Verwalten von Projektdokumenten Vorbedingung: Projektraum muss angelegt sein Auslösendes Ereignis: Anlass aus dem Projektkontext heraus. Beschreibung: Handelsvertreter stellt Dokumente oder Links auf Dokumente in einen Projektraum ein und kann diese wieder abrufen. Die Dokumente/Links können durch den Handelsvertreter beliebig klassifiziert werden, z. B. Spezifikation, Taskliste. Akteure: Handelsvertreter, Kunde, Hersteller Ergebnis: Angelegte und einsehbare Dokumente Nachbedingung Erfolg: Die erfolgreiche Durchführung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei diesen Vorgängen werden protokolliert. Erweiterungen: - Alternativen: - - 189 - B.1.8 Klärung von Kundenanfragen mit Herstellern B.1.8.1 Korrespondenz zu Kundenanfragen verwalten/versenden/freigeben Ziel: Verwalten/versenden/freigeben von Korrespondenz zu Kunden- anfragen Vorbedingung: - Auslösendes Ereignis: Kunde hat eine Anfrage für Handelsvertreter bzw. dessen Hersteller Beschreibung: Der Handelsvertreter nimmt eine Kundenanfrage im Vertriebs- informationssystem auf. Hierzu wird eine Kundenanfrage angelegt mit folgenden Informationen: ± Kunde (obligatorisch), ± Hersteller (obligatorisch), ± Anfragentext (obligatorisch), ± Klassifizierung (optional) ± die Klassen können vom Handelsvertreter frei eingetragen werden, wie z. B. technische/wirtschaftliche Fragestellung, betroffene Phasen des Vertriebszykluses, Priorität, etc. ± Multimediadaten, wie z. B. Dokumente, Bilder von Skizzen und Zeichnungen, ± Datum der Wiedervorlage/Klärung Wenn der Handelsvertreter Rückmeldungen per E-Mail vom Hersteller erhält, besteht die Möglichkeit diese und nachfolgende E-Mails der Kundenanfrage zuzuordnen. Ebenso kann der Handelsvertreter weitere Anfragen an den Hersteller versenden, die er der ersten Kundenanfrage zuordnet. Akteure: Handelsvertreter, (Kunde) Ergebnis: Aufgenommene, versendete oder abgerufene Kundenanfrage Nachbedingung Erfolg: Der erfolgreiche Versand/Freigabe wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei diesen Vorgängen werden protokolliert. Erweiterungen: - Alternativen: - - 190 - B.1.9 Entgegennahme von Angebotsanfragen B.1.9.1 Angebotsanfragen eingeben/verwalten Ziel: Eingeben bzw. verwalten von Angebotsanfragen Vorbedingung: - Auslösendes Ereignis: Ein Kunde fragt ein Angebot über ein oder mehrere Produkte an. Beschreibung: Die Anfrage kann per Fax, per E-Mail oder persönlich, z.B. im Rahmen eines Kundengesprächs oder per Telefon erfolgen. Auf Basis der aufgenommenen Informationen erstellt er persönlich ein Angebot oder lässt dieses durch seinen Hersteller erstellen (siehe Angebotsanfrage an Hersteller und Angebote anlegen). Akteure: Handelsvertreter, (Kunde) Ergebnis: Eingegebene bzw. geänderte Angebotsanfrage, die die folgenden Informationen beinhaltet: ± die angefragten Produkte, ± deren Menge, ± der gewünschte Liefertermin, ± angehängtes Dokument (z. B. Zeichnung und Bild) und ± eine Verlinkung mit den Kundendaten im System. Nachbedingung Erfolg: Das erfolgreiche Anlegen einer Angebotsanfrage wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Anlegen einer Angebotsanfrage werden protokolliert. Erweiterungen: - Alternativen: - - 191 - B.1.10 Weiterleitung von Angebotsanfragen an Hersteller B.1.10.1 Angebotsanfragen an Hersteller versenden/freigeben Ziel: Versenden/freigeben von Angebotsanfragen an Hersteller Vorbedingung: Fertiggestellte Angebotsanfrage Auslösendes Ereignis: Fertiggestellte Angebotsanfrage, die der Handelsvertreter aufgrund seiner rechtlichen Stellung zum Hersteller nicht eigenständig bearbeiten darf. Beschreibung: Nach Fertigstellung einer Angebotsanfrage wird diese über das System an den Hersteller weitergeleitet. Dazu ist eine direkte Verbindung in die relevanten Backend-Systeme des Herstellers erforderlich (z. B. Enterprise Resource Planning-Systeme). Akteure: Handelsvertreter ohne Vertretungsvollmacht (betrifft keine Handels- vertreter mit Vertretungsvollmacht oder Händler, die in eigener Sache anbieten). Ergebnis: Versendete/freigegebene Angebotsanfrage an Hersteller Nachbedingung Erfolg: Der erfolgreiche Versand/Freigabe der Angebotsanfrage wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Versand/Freigabe einer Angebotsanfrage werden protokolliert. Erweiterungen: Die Angebotsanfrage wird in das Hersteller-Frontend übertragen. Hier können Hersteller Dokumente abrufen, die keine direkte Verbindung der Plattform in ihre eigenen Backendsysteme (z. B. Enterprise Resource Planning-Systeme) aufbauen möchten/können (siehe Angebotsanfragen empfangen/verwalten). Alternativen: - - 192 - B.1.11 Erstellung von Angeboten B.1.11.1 Angebote anlegen Ziel: Anlegen von neuen Angeboten durch den Handelsvertreter Vorbedingung: Angebotsanfrage durch einen Kunden liegt vor Auslösendes Ereignis: Eingegangene bzw. aufgenommene Angebotsanfrage Beschreibung: ± Standard-/komplexe Produkte: Das Angebot kann direkt im Kundengespräch oder nach einer Kundenanfrage erstellt werden. Dabei wählt der Handelsvertreter die gewünschten Produkte und Dienstleistungen aus einem elektronischen Katalog bzw. Konfigu- rator, der über die Plattform zur Verfügung gestellt wird, aus. Aus der Auswahl wird ein Angebot erstellt, das Standardpreise der Produkte, ggf. deren Verfügbarkeit und das Zahlungsziel enthält. ± Individualprodukte: Der Handelsvertreter erstellt ein Angebot durch eine eindeutige Beschreibung der Individualprodukte und Zuordnung von entsprechenden betriebswirtschaftlichen Informationen, wie z. B. Preis, Verfügbarkeit und Zahlungsziel. Akteure: Handelsvertreter Ergebnis: Elektronisches Angebot. Inhaltliche Struktur des Dokuments basiert auf QUOTATION von openTRANS. Nachbedingung Erfolg: Die Anlage eines neuen Angebots wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Neuanlage eines Angebots werden protokolliert. Erweiterungen: Statt Standardpreise werden im zweiten Fall der Angebotserstellung kundenspezifische Preisinformationen abgerufen und aufgeführt. Alternativen: Der Handelsvertreter ruft eine offene Angebotsanfrage auf, die ausgewählte Produkte und Dienstleistungen enthält. Die Angebots- anfrage wird in ein Angebot überführt. Dabei werden im System hinterlegte vertragliche Rahmendaten der Kunden herangezogen, wie z. B. Adressdaten, Zahlungsziele und Lieferbedingungen. Der Handelsvertreter trägt die entsprechenden Preise je Position in das Angebot ein. - 193 - B.1.11.2 Angebote an Kunden versenden Ziel: Versand von Angeboten an Kunden Vorbedingung: Fertiggestelltes Angebot liegt vor Auslösendes Ereignis: Angebot muss versendet werden Beschreibung: Fertiggestellte Angebote können per E-Mail (Angebot wird als PDF- Dokument an die E-Mail angehängt) oder Fax an Kunden versendet werden. Das Angebot kann hierzu auch ausgedruckt werden, um es anschließend auf dem traditionellen Postweg zu versenden. Akteure: Handelsvertreter Ergebnis: Versendetes Angebot Nachbedingung Erfolg: Der Versand des Angebots wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Versand des Angebots werden protokolliert. Erweiterungen: - Alternativen: - - 194 - B.1.12 Entgegennahme und Bearbeitung von Bestellungen B.1.12.1 Bestellungen bearbeiten/verwalten Ziel: Bearbeiten und verwalten von Bestellungen Vorbedingung: - Auslösendes Ereignis: Eine Bestellung ist per Fax, per E-Mail, per Telefon oder im persönlichen Gespräch eingetroffen Beschreibung: Eine Bestellung kann auf drei verschiedenen Wegen angelegt werden: ± Manuelle Neuanlage einer Bestellung im Vertriebsinformations- system: Die Produkte werden manuell ins System eingepflegt. Hierfür müssen die folgenden Informationen eingegeben werden: ± die angefragten Produkte (mindestens Produktnummer), ± Menge je Bestellposition, ± gewünschter Liefertermin je Bestellposition, ± der erwartete Preis je Bestellposition (optional) und ± eine Verlinkung mit den Kundendaten im System, ± Auswahl von Produkten aus elektronischen Produktkatalogen, ± Überführung eines Angebots in eine Bestellung. Eine Bestellung wird vom Handelsvertreter bearbeitet. Hierzu muss die entsprechende Bestellung aufgerufen werden. Die Suche nach der Bestellung kann nach folgenden Kriterien bzw. Kombinationen hieraus erfolgen: ± Bestellnummer, ± Kunde, ± Status einer offenen Bestellung. Nach Bearbeitung der Bestellung kann ein Bestellstatus vergeben werden: ± in Bearbeitung, ± weitergeleitet an Hersteller, ± Waren versendet, ± Rechnung versendet, ± Zahlung erhalten, ± abgeschlossen. Akteure: Handelsvertreter Ergebnis: Eingepflegte Bestellung im Vertriebsinformationssystem. Inhaltliche Struktur des Dokuments basiert auf ORDER von openTRANS. - 195 - Nachbedingung Erfolg: Die Anlage der Bestellung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Anlage und Bearbeitung der Bestellung werden protokolliert. Erweiterungen: Der Handelsvertreter kann während/nach der Bearbeitung der Bestellung eine Bestellbestätigung an Kunden versenden. Dazu wird aus der vorliegenden Bestellung im Vertriebsinformationssystem eine Bestellbestätigung angelegt. Inhaltliche Struktur des Dokuments basiert auf ORDERRESPONSE von openTRANS. In der Bestellbestätigung kann der Handelsvertreter je Position Anmerkungen einfügen, Lieferdatum ändern und Preisinformationen ändern. Hierbei ist es auch wichtig auf die AGB des Handelsvertreters bzw. des Herstellers zu verweisen. Die Bestellbestätigung wird in ein PDF- Dokument überführt und kann wie folgt dem Kunden zugestellt werden: ± Als Anhang zu einer E-Mail aus dem Vertriebsinformationssystem, ± als Fax aus dem Vertriebsinformationssystem, ± als gedrucktes PDF-Dokument per Post. Der Versand auf allen drei Wegen wird im System protokolliert. Die Bestellbestätigungen werden ebenso wie Bestellungen gespeichert/ archiviert. Alternativen: - - 196 - B.1.13 Entgegennahme und Weiterleitung von Bestellungen an Hersteller B.1.13.1 Bestellungen an Hersteller versenden/freigeben Ziel: Versenden und freigeben von Bestellungen an Hersteller Vorbedingung: Bestellung muss angelegt und ausgewählt sein. Auslösendes Ereignis: Eine Bestellung ist eingegangen und kann an Hersteller versendet bzw. freigegeben werden. Beschreibung: Der Handelsvertreter leitet ausgewählte Bestellungen an die entsprechenden Hersteller weiter. Hierzu werden Bestellungen gesucht und ausgewählt. Die Weiterleitung erfolgt auf Knopfdruck, je nach Einstellung muss ggf. noch der Hersteller angegeben werden, der die Bestellung erhalten soll. Akteure: Handelsvertreter Ergebnis: Versendete/freigegebene Bestellung im Vertriebsinformationssystem. Nachbedingung Erfolg: Die Änderungen der Bestellung werden protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Änderung der Bestellung werden protokolliert. Erweiterungen: - Alternativen: - - 197 - B.1.14 Bereitstellung von Besuchsberichten an Hersteller B.1.14.1 Besuchsbericht bearbeiten/verwalten Ziel: Bearbeiten eines angelegten Besuchsberichts (nach CRUD ± Create, Read, Update and Delete). Vorbedingung: Besuchsbericht muss angelegt sein. Auslösendes Ereignis: Der Handelsvertreter befindet sich entweder in einem Kundengespräch bzw. hat ein Kundengespräch abgeschlossen, das in Form eines Besuchsberichts dokumentiert werden muss und es liegen Informationen vor, die in den Besuchsbericht eingepflegt werden müssen. Beschreibung: Zur Anlage eines neuen Besuchsbericht muss der Handelsvertreter im System einige Metainformationen des Kundenbesuchs angeben: ± Kunde benennen (z. B. durch Angabe der Kundennummer bzw. Kundenname) (Muss-Angabe) ± Termin des Kundengesprächs (Muss-Angabe) ± Ort des Kundengesprächs (Muss-Angabe) ± (Voraussichtliche) Teilnehmer (Kann-Angabe) Mit dem Besuchsbericht erstellt der Handelsvertreter ein Protokoll eines Kundenbesuchs. Das Protokoll untergliedert sich inhaltlich in vier Rubriken. Zu jeder der aufgeführten Rubriken können einzelne Positionen zugeordnet werden: ± Produkte ĺ3RVLWLRQHQ$XIOLVWXQJGHUQHXHQE]ZIUGHQ.XQGHQ interessante Produkte zur Bestellung, zur Angebotsanfrage, mit Änderungsanfrage, mit sonstiger Erklärung (z. B. Gründe, warum das Produkt nicht für den Kunden von Interesse ist) ± Projekte (Auflistung jedes einzelnen Projekts) ĺ3RVLWLRQHQ Auflistung offener Fragestellungen im Projekt inklusive detaillierter Hintergrundinformationen ± Geschäftsvorfälle ĺ3RVLWLRQHQ$XIOLVWXQJGHURIIHQHQ Geschäftsvorfälle mit Klärungsbedarf inklusive detaillierter Hintergrundinformationen (z. B. Beschreibung des Klärungsbedarfs) ± Sonstige Themen ĺ3RVLWLRQHQ8QWHUVFKLHGOLFKH7KHPHQ inklusive detaillierter Hintergrundinformationen Zu jeder Position können mehrere Aktionspunkte (»Was muss getan werden?«) jeweils mit Festlegung eines Verantwortlichen und eines Endtermins zugeordnet werden. - 198 - Jede Position und jeder Aktionspunkt kann einem oder mehreren Herstellern zugeordnet werden. Beim späteren Versand der Besuchsberichte werden dann jeweils nur die Positionen und Aktionspunkte übertragen, die den jeweiligen Herstellern zugeordnet wurden. Der Besuchsbericht muss zur weiteren Bearbeitung abgespeichert werden können. Über entsprechende Suchfunktionalitäten kann auf die Besuchsberichte zugegriffen werden (z. B. Kundenname, Kunden- nummer, Datum des Besuchstermins, Ort des Besuchstermins). So kann der Handelsvertreter einen Besuchsbericht schon während des Kundengesprächs beginnen und diesen dann nach dem Gespräch fertig stellen und versenden (hybride Bearbeitung von Dokumenten - mobil und stationär). Akteure: Handelsvertreter Ergebnis: Teilweise/vollständig ausgefüllter Besuchsbericht in der oben aufgeführten Struktur. Rubriken, die keine Positionen enthalten, werden nicht angezeigt. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Bearbeitung und Verwaltung von Bestellungen werden protokolliert. Erweiterungen: ± Die Anlage eines Besuchsberichts erfolgt aus der Zusammenstellung einer Gesprächsvorbereitung. Einzelne Positionen der Gesprächsvorbereitung können damit bei der Neuanlage in den Besuchsbericht überführt werden. ± Positionen unter der Rubrik Produkte können direkt in Bestellpositionen einer Bestellung überführt werden. D. h. bei Überführung des ersten Produkts in eine Bestellposition wird eine Bestellung angelegt. ± Bei der Rubrik Produkte kann ein Aktionspunkt durchaus die Änderungswünsche eines Standardproduktes beinhalten, verbunden mit einer Angebotsanfrage an den Hersteller. Alternativen: - - 199 - B.1.14.2 Besuchsbericht an Hersteller versenden/freigeben Ziel: Versenden und freigeben des Besuchsberichts an einen oder mehrere Hersteller. Vorbedingung: Besuchsbericht muss angelegt und (final) ausgefüllt sein. Auslösendes Ereignis: Der Handelsvertreter hat einen Besuchsbericht fertig erstellt, der einem oder mehreren Herstellern zugestellt werden muss. Beschreibung: Nach Fertigstellung des Besuchsberichts und inhaltlicher Überprüfung durch den Handelsvertreter wird der Besuchsbericht an einen oder mehrere Herstellern elektronisch versendet/freigegeben. Akteure: Handelsvertreter Ergebnis: Versendeter/freigegebener Besuchsbericht an einen oder mehrere Hersteller. Nachbedingung Erfolg: Erfolgreicher Versand wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Versand/Freigabe von Besuchsberichten werden protokolliert. Erweiterungen: Status und Feedback von Aufgaben können wieder zurück auf die Plattform gespielt werden und somit bei Abruf eines Besuchsberichts angezeigt werden. Alternativen: - - 200 - B.1.15 Erstellung/Versand von Rechnungen B.1.15.1 Rechnung erstellen Ziel: Erstellung einer Rechnung Vorbedingung: Bestellung ist angelegt. Auslösendes Ereignis: Bestellte Ware wird soeben bzw. wurde versendet. Beschreibung: Die für den Vorgang angelegte Auftragsbestätigung (ggf. Bestellung) wird in eine Rechnung überführt. Teillieferungen werden mit angepassten Mengen berücksichtigt. Akteure: Handelsvertreter Ergebnis: Angelegte Rechnung im System. Inhaltliche Struktur des Dokuments basiert auf INVOICE von openTRANS. Nachbedingung Erfolg: Neuanlage der Rechnung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Neuanlage der Rechnung werden protokolliert Erweiterungen: - Alternativen: Alternativ kann die Rechnung auch manuell im System angelegt und eingepflegt werden. - 201 - B.1.15.2 Rechnung ausdrucken Ziel: Ausdrucken von Rechnungen Vorbedingung: Rechnung muss angelegt sein. Auslösendes Ereignis: Rechnung muss versendet werden. Beschreibung: Handelsvertreter ruft die entsprechende Rechnung auf und druckt diese aus. Akteure: Handelsvertreter Ergebnis: Gedruckte Rechnung. Nachbedingung Erfolg: Rechnungsdruck wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Rechnungsdruck werden protokolliert. Erweiterungen: Zukünftig könnte die Plattform elektronische Rechnungen mit Kunden austauschen. Alternativen: - - 202 - B.1.16 Entgegennahme von Bestelländerungen B.1.16.1 Bestellung ändern Ziel: Ändern von Bestellungen Vorbedingung: Bestellung muss angelegt sein. Auslösendes Ereignis: Bestelländerung eines Kunden trifft ein. Beschreibung: Der Handelsvertreter ruft die entsprechende Bestellung auf und gibt die genannten Änderungen ein. Akteure: Handelsvertreter Ergebnis: Geänderte Bestellung Nachbedingung Erfolg: Bestelländerungen werden protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Ändern der Bestellung werden protokolliert. Erweiterungen: - Alternativen: - B.1.16.2 Bestelländerungen an Hersteller versenden/freigeben Dieser Use Case entspricht dem Use Case zum Versenden von Bestellungen, der in »Bestellungen an Hersteller versenden« beschrieben ist. B.1.17 Rechnungen von Herstellern bearbeiten/weiterleiten B.1.17.1 Rechnungen ausdrucken Der Use Case zum Ausdruck von Rechnungen ist in »Rechnung ausdrucken« beschrieben. - 203 - B.1.18 Abgleich der Provisionszahlungen mit Herstellern B.1.18.1 Provisionsstatus abrufen Ziel: Abrufen des aktuellen Provisionsstatus Vorbedingung: Die Geschäftsvorfälle müssen mit dem aktuellen Stand im Vertriebsinformationssystem aufgeführt sein. Auslösendes Ereignis: In regelmäßigen Abständen prüft der Handelsvertreter, welche Provisionszahlungen noch ausstehen. Da die Provision meist von der Zahlung des Kunden an den Hersteller abhängt, ist es für den Handelsvertreter von Bedeutung, dass die Kunden ihre Zahlungsziele einhalten und nicht überziehen. Sollte letzteres der Fall sein, benötigt der Handelsvertreter einen entsprechenden Hinweis, um beim nächsten Gespräch mit dem Kunden diesen darauf aufmerksam zu machen. Beschreibung: Der Handelsvertreter erhält über das System eine Statistik mit folgenden Informationen: ± Soll-/Ist-Provision in diesem Jahr insgesamt (über alle Hersteller), ± Soll-/Ist-Provision in diesem Jahr je Hersteller, ± Soll-/Ist-Provisionen je Monat insgesamt (über alle Hersteller), ± Soll-/Ist-Provisionen je Monat und Hersteller, ± Zu jedem der oben aufgeführten Werte die absolute bzw. relative Unter- bzw. Überdeckung ± Hochrechnung über alle offenen Rechnungen insgesamt, ± Hochrechnungen über alle offenen Rechnungen je Hersteller, ± Hochrechnung über alle offenen Bestellungen insgesamt, ± Hochrechnungen über alle offenen Bestellungen je Hersteller, ± Hochrechnung über alle offenen Angebote insgesamt, ± Hochrechnungen über alle offenen Angebote je Hersteller, ± Anzeige aller offenen Rechnungen, bei denen das Zahlungsziel überzogen wurde (sortiert nach Kunden/Länge der Überziehung) Die Anzeige weiterer Auswertung ist je nach Anforderung seitens des Handelsvertreters notwendig. Akteure: Handelsvertreter Ergebnis: Statistiken der Provisionszahlungen Nachbedingung Erfolg: - - 204 - Nachbedingung Fehlschlag: Fehlermeldungen bei der Berechnung und Darstellung der Provisions- statistik werden protokolliert. Erweiterungen: - Alternativen: - B.1.19 Abfrage von Information über Geschäftsvorfälle für Kunden B.1.19.1 Statusinformationen über Geschäftsvorfälle abrufen (Übersicht) Ziel: Abrufen der aktuellen Status von Geschäftsvorfällen Vorbedingung: Geschäftsvorfälle müssen im System angelegt sein. Auslösendes Ereignis: Kundenanfrage bzw. Vorbereitung eines Gesprächtermins Beschreibung: Der Handelsvertreter ruft die Geschäftsvorfälle eines Kunden auf. Hierzu muss der Kunden benannt werden. Die Geschäftsvorfälle werden mit folgenden Informationen tabellarisch gelistet: ± Nummer des Vorfalls, ± Datum des Angebots, ± Voraussichtliches Bestelldatum (als Reminder für den Handelsvertreter), ± Tatsächliches Bestelldatum, ± Voraussichtliches Lieferdatum, ± Tatsächliches Lieferdatum, ± Geplanter Zahlungstermin, ± Tatsächlicher Zahlungstermin, ± Anzahl der Bestellpositionen, ± Gesamtvolumen der Bestellung, ± Kennzeichen für sonstige Anmerkungen, z. B. bei Teillieferungen liegt das aktuelle Datum der Abfrage durch den Handelsvertreter hinter dem geplanten Lieferdatum bzw. Zahlungstermin werden diese mit einer anderen Farbe oder einem Zeichen gekennzeichnet. Für den Handelsvertreter müssen in der Übersichtstabelle diejenigen Geschäftsvorfälle schnell kenntlich werden, bei denen für ihn (z. B. fehlende Zahlung des Vorgangs) oder aus Sicht des Kunden (z. B. fehlendes Angebot bzw. ausstehende Lieferung der Ware) Probleme auftreten. Um die Darstellung auf die für den Handelsvertreter relevanten Vorfälle - 205 - zu beschränken, können die Vorfälle gefiltert werden. Für das Filtern von Geschäftsvorfällen stehen folgende Parameter zur Verfügung: ± Nummer des Vorfalls, ± Kunde, ± Angabe einer Zeitspanne für das Datum eines Angebots, einer Bestellung, einer Lieferung und/oder einer Zahlung, ± offenes Datum eines Angebots, einer Bestellung, einer Lieferung und einer Zahlung, ± Überschreitung eines Datums bei einer Bestellung, einer Lieferung und/oder einer Zahlung, ± Kennzeichen einer sonstigen Anmerkung. Akteure: Handelsvertreter Ergebnis: Liste aller ggf. gefilterten Geschäftsvorfälle Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Anzeigen der Übersicht werden protokolliert. Erweiterungen: Die Liste kann durch den Handelsvertreter ausgedruckt werden. Alternativen: - - 206 - B.1.19.2 Details über Geschäftsvorfälle abrufen (Detailsicht) Ziel: Abrufen von Details eines Geschäftsvorfalls Vorbedingung: Geschäftsvorfall muss angelegt sein. Auslösendes Ereignis: Kundenanfrage bzw. Vorbereitung eines Gesprächtermins Beschreibung: Der Handelsvertreter ruft den gewünschten Geschäftsvorfall auf. In der Detailansicht werden die Informationen der tabellarischen Übersicht aufgeführt sowie die einzelnen Bestellposition inklusive detaillierter Anmerkungen zu jeder der Bestellpositionen. Über die Detailansicht können alle weiteren Dokumente des Geschäftsvorfalls eingesehen werden, wie z. B. Angebotsanfrage, Angebot, Bestellung, Bestell- änderungen, ggf. Lieferschein, Rechnung und ggf. Reklamationen. Akteure: Handelsvertreter Ergebnis: Details eines Geschäftsvorfalls Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Aufruf der Details eines Geschäftsvorfalls werden protokolliert. Erweiterungen: Die Details eines Geschäftsvorfalls können ausgedruckt werden. Alternativen: - - 207 - B.1.20 Abgleich der Status von Geschäftsvorfällen mit Herstellern B.1.20.1 Elektronische Geschäftsdokumente verwalten Ziel: Verwalten elektronischer Geschäftsdokumente (z. B. im PDF-Format) Vorbedingung: Geschäftsdokumente müssen angelegt sein. Auslösendes Ereignis: Einsicht in ein elektronisches Geschäftsdokument Beschreibung: Der Handelsvertreter soll die Möglichkeit erhalten, direkt auf elektronische Geschäftsdokumente zugreifen zu können. Hierzu kann nach den benötigten Dokumenten gesucht werden: ± Nummer des Geschäftsvorfalls, ± Kunde, ± Typ des Dokuments (z. B. Angebotsanfrage, Angebot, Bestellung, Bestellbestätigung, Lieferschein, Rechnung und Reklamation), ± Datum oder Zeitraum, in dem das Dokument erstellt wurde. Als Ergebnis liefert die Plattform eine tabellarische Auflistung aller Dokumente, die den Suchkriterien entsprechen. Folgende Informationen werden zu den Dokumenten angezeigt: ± Nummer des Geschäftsvorfalls, ± Kunde, ± Typ des Dokuments (siehe oben), ± Datum der Dokumentenerstellung, ± Bezeichnung des Dokuments, ± Link auf das Dokument zum Abruf. Akteure: Handelsvertreter Ergebnis: Auflistung von Dokumenten, die den Suchkriterien entsprechen sowie eine Einsicht in ausgewählte elektronische Geschäftsdokumente Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Einsicht in elektronische Geschäfts- dokumente werden protokolliert. Erweiterungen: - Alternativen: - - 208 - B.1.21 Bearbeitung von Reklamationen B.1.21.1 Reklamation anlegen Ziel: Aufnehmen und anlegen einer Reklamation Vorbedingung: - Auslösendes Ereignis: Handelsvertreter erhält eine Reklamation eines Kunden Beschreibung: Der Handelsvertreter nimmt die Reklamation eines Kunden auf. Hierzu sind die folgenden Informationen notwendig: ± Kunde, ± Hersteller des Produkts, ± Nummer der Produktbestellung, ± Produktnummer(n), ± Anzahl der reklamierten Produkte (je angegebener Produkt- nummer), ± Reklamationsgrund (je angegebener Produktnummer). ± Die Informationen werden im Vertriebsinformationssystem eingegeben. Akteure: Handelsvertreter Ergebnis: Aufgenommene Reklamation Nachbedingung Erfolg: Aufgenommene Reklamation wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Aufnahme der Reklamation werden protokolliert. Erweiterungen: - Alternativen: - - 209 - B.1.21.2 Reklamation prüfen Ziel: Prüfen einer eingegangenen Reklamation auf deren Berechtigung vorab Vorbedingung: Reklamation wurde aufgenommen. Auslösendes Ereignis: Eine Reklamation wurde aufgenommen und muss bearbeitet werden. Beschreibung: Nach Aufnahme einer Reklamation wird diese vorab auf deren Berechtigung geprüft. Hierzu stößt der Handelsvertreter nach Aufnahme der Reklamation den Prüfprozess im Vertriebs- informationssystem an. Das System prüft, ob in den Bestellungen des Kunden das/die angegebene(n) Produkt(e) bestellt wurden. Akteure: Handelsvertreter Ergebnis: Akzeptierte/abgelehnte Reklamation Nachbedingung Erfolg: Prüfung der Reklamation wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Reklamationsprüfung werden protokolliert. Erweiterungen: - Alternativen: - B.1.12.3 Reklamation an Hersteller versenden/freigeben Ziel: Versenden der Reklamation an Hersteller Vorbedingung: Reklamation wurde aufgenommen und nach der Vorabprüfung akzeptiert Auslösendes Ereignis: Geprüfte Reklamation liegt vor und muss weiter bearbeitet werden Beschreibung: Nach erfolgreicher Vorabprüfung der Reklamation leitet der Handelsvertreter die Reklamation über das Vertriebsinformations- system weiter an den Hersteller. Parallel werden die reklamierten - 210 - Produkte an den Hersteller zurückgesendet. Akteure: Handelsvertreter Ergebnis: Versendete/freigegebene Reklamation Nachbedingung Erfolg: Versand/Freigabe der Reklamation wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Versand der Reklamation werden protokolliert. Erweiterungen: - Alternativen: - B.1.22 Systemadministration B.1.22.1 Registrierung Ziel: Eine Handelsvertretung registriert sich auf der Vertriebsinformations- plattform Vorbedingung: - Auslösendes Ereignis: Eine Handelsvertretung, die bislang noch nicht mit der Plattform arbeitet, möchte diese zur Unterstützung ihrer Tätigkeiten nutzen. Beschreibung: Eine Handelsvertretung registriert sich auf der Plattform. Hierzu werden vertragsrelevante Kontaktdaten abgefragt, die der Handelsvertreter im Rahmen des Registrierungsprozesses ins System eingeben muss: ± Firmenname, ± Firmenadresse, ± Name eines rechtlichen Firmenvertreters, ± Telefonnummer des Vertreters, ± Faxnummer des Vertreters, ± E-Mail des Vertreters, ± UStIdentNummer, ± Kontendaten zum Abbuchen von Benutzerbeiträgen. Vor dem Versand der Registrierungsdaten erhält der Handelsvertreter die AGBs der Plattform, die er elektronisch bestätigen muss. Das neu angelegte Benutzerkonto erhält die umfassendsten Rechte eines - 211 - Handelsvertreters, d.h. Nutzung aller Use Cases. Akteure: Handelsvertreter (spezielle Rolle Firmenvertreter) Ergebnis: Handelsvertretung ist mit einem Benutzerkonto inklusive aller Rechte angelegt. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Registrierung werden protokolliert. Erweiterungen: - Alternativen: - B.1.22.2 Benutzer verwalten Ziel: Verwalten von Benutzern der Vertriebsinformationsplattform in der eigenen Organisation Vorbedingung: Der Handelsvertreter hat sich auf der Plattform registriert und wurde vom Betreiber der Plattform freigegeben. Auslösendes Ereignis: Die folgenden Ereignisse können Änderungen in der Benutzerverwaltung notwendig machen: ± Neue Benutzer der Handelsvertretung werden auf der Plattform angelegt, ± Rechte bestehender Benutzer ändern sich, ± Bestehender Benutzer wird von der Plattform entfernt. Beschreibung: Jede Handelsvertretung erhält ein Administratorzugang auf die Vertriebsinformationsplattform. Mit diesem Zugang können alle Use Cases der Systemadministration auf Handelsvertreterseite genutzt werden. Akteure: Handelsvertreter (spezielle Rolle Administrator ) Ergebnis: Aktualisierte Verwaltung von Benutzern einer Handelsvertretung Nachbedingung Erfolg: - Nachbedingung Fehlermeldungen bei der Durchführung der Benutzerverwaltung - 212 - Fehlschlag: werden protokolliert. Erweiterungen: - Alternativen: - B.1.22.3 Rechte verwalten Ziel: Der Handelsvertreter setzt und verwaltet die Rechte von Herstellern und seinen eigenen Mitarbeitern auf Nutzung seiner hinterlegten Informationen. Vorbedingung: - Auslösendes Ereignis: Die folgenden Ereignisse machen eine Aktualisierung von Herstellerrechten notwendig: ± Der Handelsvertreter verbindet sich über die Plattform mit einem Herstellern und gibt diesem Rechte auf ausgewählte Informationen, ± der Handelsvertreter möchte die Rechte eines Herstellers auf seine Informationen erweitern bzw. einschränken, ± der Handelsvertreter löst eine Geschäftsbeziehung mit dem Hersteller auf und entzieht ihm alle Zugriffsrechte auf die Informationen des Handelsvertreters, ± ein neuer Mitarbeiter erhält Rechte für die Plattform, ± Rechte eines bestehenden Mitarbeiters auf der Plattform ändern sich, ± Mitarbeiter verlässt das Unternehmen. Beschreibung: Der Handelsvertreter vergibt je Hersteller Leserechte auf folgende Informationen: ± Kontakte, ± Termine, ± Korrespondenz mit Kunden (z. B. bei Entwicklungsprojekten), ± Geschäftsdokumente. ± Der Handelsvertreter vergibt je Mitarbeiter Schreib-/Leserechte auf folgende Informationen: ± Kontakte, ± Termine, ± Korrespondenz mit Kunden (z. B. bei Entwicklungsprojekten), ± Geschäftsdokumente. ± Die Rechte können z. B. in Abhängigkeit von Kunden, Vertriebs- gebieten, Kundengrößen und Kundenumsätzen gesetzt werden. - 213 - Akteure: Handelsvertreter (spezielle Rolle Administrator) Ergebnis: Neu angelegte, aktualisierte oder entzogene Rechte auf die Informationen des Handelsvertreters. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Rechteverwaltung werden protokolliert. Erweiterungen: Die Rechte werden an dieser Stelle global über die Plattform vergeben. Der Handelsvertreter erhält jedoch die Möglichkeit im Einzelfall je Termin, Korrespondenz und Geschäftsdokument zu entscheiden, ob diese Informationen dem jeweiligen Hersteller freigegeben werden oder nicht. Die Rechtevergabe je Einzelfall kann vom Handelsvertreter auf der Plattform eingestellt werden. Alternativen: - - 214 - B.1.22.4 Systemintegration konfigurieren Ziel: Konfigurieren von anzubindenden Backendsystemen auf Handelsvertreterseite Vorbedingung: - Auslösendes Ereignis: Die folgenden Ereignisse lösen die Konfiguration der Systemintegration aus: ± Nach der Neuanlage einer Handelsvertretung werden die Schnittstellen der in die Vertriebsinformationsplattform zu integrierenden Backendsysteme auf Handelsvertreterseite konfiguriert, ± Anbindung eines neu hinzugekommenen Backendsystems an die Vertriebsinformationsplattform, ± Wegfall eines an die Vertriebsinformationsplattform angebundenen Backendsystem. Beschreibung: Die folgenden Schnittstellen können seitens des Handelsvertreters konfiguriert werden: ± ERP-System: ± Angebotsanfrage, ± Angebot, ± Bestellung/Bestelländerung, ± Bestellbestätigung, ± Lieferschein, ± Rechnung, ± Reklamation. ± CRM-System: ± Kontakte, ± Termine, ± Aufgaben, ± Besuchsberichte. ± Groupware: ± Termine, ± Aufgaben, ± Kontakte. Für die Konfiguration stellt die Plattform Mappingmechanismen zur Verfügung, mit denen die Felder der Backendsysteme sowie der Vertriebsinformationsplattform einander zugeordnet werden können. Des Weiteren werden die Schnittstellen über gängige Formate ausgetauscht, wie z. B. CSV- sowie XML-basierte Datenaustausch- formate. - 215 - Akteure: Handelsvertreter (spezielle Rolle Administrator) Ergebnis: Konfiguration aller angebundenen Schnittstellen der Vertriebs- informationsplattform zu Backendsystemen auf Handelsvertreterseite. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Konfiguration werden protokolliert. Erweiterungen: - Alternativen: - B.1.22.5 Funktionalität anpassen Ziel: Festlegen der funktionalen Unterstützung durch die Vertriebsinformationsplattform. Vorbedingung: - Auslösendes Ereignis: Die folgenden Ereignisse lösen die Anpassung der funktionalen Unterstützung durch die Vertriebsinformationsplattform aus: ± Für einen neuen Mitarbeiter muss die funktionale Unterstützung durch die Vertriebsinformationsplattform angepasst werden, ± Bei einem bestehenden Mitarbeiter muss die funktionale Unterstützung angepasst werden, ± Bei Verlassen eines Mitarbeiters des Unternehmens wird die funktionale Unterstützung zurückgesetzt. Beschreibung: Jeder Use Case kann mitarbeiterspezifisch frei geschaltet werden, so dass dem Mitarbeiter entsprechende Funktionalität bereitgestellt wird. Akteure: Handelsvertreter (spezielle Rolle Administrator) Ergebnis: Anpassung der Use Cases (funktionale Unterstützung durch die Vertriebsinformationsplattform) an die Bedürfnisse eines Mitarbeiters. Nachbedingung Erfolg: Die Benutzeroberfläche eines Mitarbeiters inklusive Navigationsleiste und Inhalte werden über die Einstellungen angepasst. Nachbedingung Fehlschlag: Fehlermeldungen bei der Anpassung werden protokolliert. - 216 - Erweiterungen: Use Cases können zukünftig abhängig von spezifischen Kriterien angepasst werden, z. B. Mitarbeiter, Hersteller und Produkttyp. Ziel hierbei ist es, die Prozesslogik noch intensiver in die Vertriebs- informationsplattform zu integrieren. Alternativen: - B.1.23 Management von Produktinformationen B.1.23.1 Produktinformationen importieren Ziel: Importieren von elektronischen Produktinformationen Vorbedingung: Produktinformationen liegen elektronisch und in einem einfachen oder definierten Format vor (z. B. CSV, XML, BMEcat) Auslösendes Ereignis: Eine Handelsvertretung muss Produktinformationen in die Vertriebs- informationsplattform einspielen. Beschreibung: Der Handelsvertreter wählt einen elektronischen Produktkatalog auf seinem Filesystem aus. Die Vertriebsplattform bietet als Format ein fest definiertes CSV-Format, ggf. XML-Format für den Import an. Akteure: Handelsvertreter (spezielle Rolle Administrator) Ergebnis: Aktualisierte Produktinformationen durch den Import eines elektronischen Produktkatalogs. Nachbedingung Erfolg: Erfolgsmeldung nach Import wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Import werden protokolliert. Erweiterungen: Schnittstellen für komplexe Formate elektronischer Produktkatalogstandards werden umgesetzt und auf der Plattform angeboten. Des Weiteren können Felder einfacher Formate (z. B. CSV- oder XML- Formate) über Mappingmechanismen zu bestehenden Feldern der Vertriebsinformationsplattform zugeordnet werden und dadurch importiert werden. Alternativen: - - 217 - B.1.23.2 Produktinformationen einpflegen Ziel: Manuelles einpflegen von Produktinformationen Vorbedingung: - Auslösendes Ereignis: Eine Handelsvertretung muss Produktinformationen in die Vertriebs- informationsplattform einpflegen, da sie z. B. nicht elektronisch vorliegen. Beschreibung: Der Handelsvertreter erhält Eingabemasken, in die er die notwendigen Produktinformationen einpflegen kann. Einige der wichtigen Produktinformationen sind im Folgenden aufgeführt: ± Produktnummer (Muss-Kriterium), ± Produktbezeichnung (Muss-Kriterium), ± Produktbeschreibung (Muss-Kriterium), ± Produktpreis (Kann-Kriterium), ± Lieferzeit (Kann-Kriterium), ± Lieferdatum (Kann-Kriterium), ± Hersteller (Kann-Kriterium), ± Hersteller (Muss-Kriterium). Akteure: Handelsvertreter (spezielle Rolle Administrator) Ergebnis: Aktualisierte Produktinformationen durch die manuelle Pflege von Produktinformationen. Nachbedingung Erfolg: Erfolgsmeldung nach Einpflege wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Einpflegen werden protokolliert. Erweiterungen: - Alternativen: - - 218 - B.1.24 Verwaltung allgemeiner Vertriebsinformationen B.1.24.1 Kontakte verwalten Ziel: Verwalten von Kontakten Vorbedingung: - Auslösendes Ereignis: Aktualisierung von Kontakten ist notwendig. Beschreibung: Anlegen, ändern und abrufen von Kontakten auf der Plattform durch den Handelsvertreter. Einzelne Kontakte kann der Handelsvertreter für die jeweiligen Hersteller freigeben. Die Kontakte können klassifiziert werden z. B. nach Kunde und potenzieller Kunde (Interessent). Des Weiteren können Aufgaben, Termine, Notizen, Status und Korrespondenz zu einem Kontakt hinzugefügt werden. Akteure: Handelsvertreter Ergebnis: Aktualisierte Kontaktinformationen. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Einpflegen werden protokolliert. Erweiterungen: - Alternativen: - - 219 - B.1.24.2 Korrespondenz verwalten Ziel: Verwalten von Korrespondenz Vorbedingung: - Auslösendes Ereignis: Korrespondenz mit einem Kunden ist erfolgt. Beschreibung: Über die Vertriebsinformationsplattform können E-Mails eingegeben und versendet werden. Die E-Mails können Kunden und Herstellern zugeordnet werden. Des Weiteren können Aufgaben, Termine, Notizen, Dokumenten, etc. mit E-Mails verlinkt werden. Akteure: Handelsvertreter Ergebnis: Aktualisierte Korrespondenz. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Einpflegen und Versenden werden protokolliert. Erweiterungen: - Alternativen: - B.1.24.3 Termine verwalten Ziel: Verwalten von Terminen Vorbedingung: - Auslösendes Ereignis: Termine mit einem Kunden haben sich ergeben/geändert. Beschreibung: Über die Vertriebsinformationsplattform können Termine eingepflegt werden. Die Termine können Kunden und Herstellern zugeordnet werden. Des Weiteren können Aufgaben, Korrespondenz, Notizen, Dokumenten, etc. verlinkt werden. Akteure: Handelsvertreter - 220 - Ergebnis: Aktualisierte Termine. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Pflegen werden protokolliert. Erweiterungen: - Alternativen: - B.1.24.4 Aufgaben verwalten Ziel: Verwalten von Aufgaben Vorbedingung: - Auslösendes Ereignis: Aufgaben haben sich für den Handelsvertreter ergeben Beschreibung: Über die Vertriebsinformationsplattform können Aufgaben eingepflegt werden. Die Aufgaben können Kunden und Herstellern zugeordnet werden. Des Weiteren können Termine, Korrespondenz, Notizen, Dokumenten, etc. verlinkt werden. Akteure: Handelsvertreter Ergebnis: Aktualisierte Aufgaben. Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Pflegen werden protokolliert. Erweiterungen: - Alternativen: - - 221 - B.2 Darstellung der Use Cases aus Herstellersicht B.2.1 Bereitstellung von Produktinformationen für Handelsvertretungen B.2.1.1 Multimediale Produktinformationen bereitstellen Ziel: Bereitstellen von multimedialen Informationen von Produkten Vorbedingung: - Auslösendes Ereignis: Hersteller erstellt neue multimediale Informationen von Produkten, die Handelsvertretungen zur Verfügung gestellt werden sollen. Beschreibung: Der Hersteller kann über ein Webinterface multimediale Informationen von Produkten, wie z. B. Videos, Bilder, Audio, Dokumente auf die Vertriebsinformationsplattform hochladen und Handelsvertretungen bereitstellen. Die multimedialen Informationen können damit Handelsvertretern, Produkten und Produktgruppen zugeordnet werden. Um die Informationen einfacher einordnen zu können, können verschiedenen Merkmale zugewiesen werden: ± Name, ± Kategorien, wie z. B. Einführungen, Produktvorstellungen, Problemlösungen, Handbücher, Gebrauchsanweisungen, Tabellen, Ersatzteillisten, Approbationen, etc., ± Erstellungsdatum, ± Änderungsdatum, ± Hersteller, ± Informationstypen, z. B. Video, Bilder, Audio, Dokument ± Formate, z. B. jpg, mpg, avi, acc, pdf, ppt, xls, etc. Hierbei müssen die multimedialen Informationen an die jeweiligen Ausgabegeräte angepasst werden. Akteure: Hersteller Ergebnis: Handelsvertretung kann multimediale Informationen von Produkten abrufen. Nachbedingung Erfolg: Bereitstellung der multimedialen Informationen wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Bereitstellung der multimedialen Informationen werden protokolliert. - 222 - Erweiterungen: - Alternativen: - B.2.2 Bereitstellung von Produktmustern B.2.2.1 Antrag Mustervergabe empfangen/verwalten Ziel: Empfangen bzw. verwalten eines Antrags für die Mustervergabe Vorbedingung: - Auslösendes Ereignis: Anfrage eines Kunden nach einem Produktmuster wird vom Handelsvertreter an den Hersteller gesendet/freigegeben Beschreibung: Der Hersteller empfängt einen Antrag auf Mustervergabe und verwaltet die erhaltenen Informationen: ± Produktbezeichnung, ± Grund des Interesses (z. B. Testen des Musters ohne/mit konkreter Projektidee), ± Ggf. Benennung eines Projekts (inkl. Zielsetzung, (geplanter) Beginn/ Fertigstellung der Entwicklung, (geplanter) Beginn/Fertigstellung einer Vorserie, (geplanter) Beginn der Serienproduktion, (technische) Anforderungen an das Produkt, weitere Hintergrundinformationen), ± Forcast der voraussichtlich benötigten Menge des Produkts für die nächsten drei Jahre Akteure: Hersteller Ergebnis: Aktuelle Anträge zur Mustervergabe Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung des Antrags werden protokolliert. Erweiterungen: Zukünftig kann Herstellern ein Analysetool zur Verfügung gestellt werden, über das sie die erhaltenen Antrag-Informationen abrufen und untersuchen können, um anschließend geeignete Aktionen zu initiieren. - 223 - Alternativen: - B.2.2.2 Kundenfeedback zur Musterprüfung inkl. Statusvergabe verwalten Ziel: Verwalten des Kundenfeedbacks während/nach der Musterprüfung durch den Hersteller Vorbedingung: Antrag für die Mustervergabe ist vorhanden und Muster ausgegeben. Auslösendes Ereignis: Kunde gibt Feedback während/nach der Prüfung eines Musters über den Handelsvertreter an den Hersteller Beschreibung: Hersteller erhält Feedback eines Kunden, der Musterteile geprüft hat. Das Feedback konkretisiert die im Antrag aufgenommenen Informationen (siehe Use Case »Kundenfeedback zur Musterprüfung inkl. Statusvergabe verwalten«) und beinhaltet darüber hinaus die Eignung der Produkts für das konkrete Projekt. Des Weiteren sind Gründe notiert, warum ein Produkt ggf. nicht geeignet ist. Dem Feedback kann ein Status durch den Handelsvertreter ergänzt werden, wie z. B.: ± Offen, ± Abgeschlossen (mit Auftrag), ± Abgeschlossen (ohne Auftrag). Akteure: Hersteller Ergebnis: Aktualisiertes Kundenfeedback Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung des Kundenfeedback werden protokolliert. Erweiterungen: Zukünftig kann Herstellern ein Analysetool zur Verfügung gestellt werden, über das sie die erhaltenen Antrag-/Feedback-Informationen abrufen und untersuchen können, um anschließend geeignete Aktionen zu initiieren. Alternativen: - - 224 - B.2.3 Beratung Entwicklungsprojekt B.2.3.1 Korrespondenz zum Projekt verwalten/versenden/freigeben Die Use Cases zur Verwaltung/Versand/Freigabe von Korrespondenz zu einem Entwicklungsprojekt von Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist in »Korrespondenz zum Projekt« beschrieben. B.2.3.2 Dokumente zum Projekt verwalten/versenden/freigeben Die Use Cases zur Verwaltung/Versand/Freigabe von Dokumenten zu einem Entwicklungsprojekt von Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist in »Dokumente zum Projekt verwalten« beschrieben. B.2.4 Klärung von Kundenanfragen B.2.4.1 Korrespondenz Kundenanfrage verwalten/versenden/freigeben Die Use Cases zur Verwaltung/Versand/Freigabe von Korrespondenz zu einem Entwicklungsprojekt von Herstellern bzw. Handelsvertretungen sind ähnlich. Der Use Case seitens Handelsvertretungen ist in »Korrespondenz zu Kundenanfragen« beschrieben. Ein Unterschied ist, dass der Hersteller keine Kundenanfragen aufnimmt, sondern diese durch den Handelsvertreter zugestellt bekommt. Diese kann dann bearbeitet werden und eine dazugehörende Antwort zurückgesendet werden. - 225 - B.2.5 Entgegennahme von Angebotsanfragen B.2.5.1 Angebotsanfragen empfangen/verwalten Ziel: Empfangen und verwalten von Angebotsanfragen Vorbedingung: - Auslösendes Ereignis: Ein Handelsvertreter hat eine Angebotsanfrage an den Hersteller übermittelt. Beschreibung: Der Hersteller empfängt über das Vertriebsinformationssystem die Angebotsanfragen vom Handelsvertreter. Diese werden dann auf der Plattform gespeichert und verwaltet, so dass der Hersteller auch zu einem späteren Zeitpunkt die Angebotsanfragen abrufen kann. Akteure: Hersteller Ergebnis: Empfangene und aktualisierte Angebotsanfragen Nachbedingung Erfolg: Der erfolgreiche Empfang einer Angebotsanfrage wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen beim Empfang einer Angebotsanfrage werden protokolliert. Erweiterungen: Eine Informations-E-Mail wird beim Eingang neuer Angebotsanfragen an den Hersteller versendet. Alternativen: - - 226 - B.2.6 Erstellung von Angeboten B.2.6.1 Angebote anlegen/verwalten Ziel: Anlegen und verwalten von Angeboten durch den Hersteller Vorbedingung: Angebotsanfrage durch den Handelsvertreter liegt vor Auslösendes Ereignis: Eingegangene bzw. aufgenommene Angebotsanfrage Beschreibung: Die Angebotsanfrage des Handelsvertreters wird in ein Angebot überführt. Das Angebot wird vom Hersteller bearbeitet, indem u. a. Preise und ggf. Lieferzeiten/-datum ergänzt werden. Das Angebot wird gespeichert und auf der Plattform verwaltet. Zu einem späteren Zeitpunkt kann der Hersteller das Angebot vervollständigen. Akteure: Hersteller Ergebnis: Elektronisches Angebot Nachbedingung Erfolg: Die Anlage eines neuen Angebots wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Neuanlage eines Angebots werden protokolliert. Erweiterungen: - Alternativen: - - 227 - B.2.6.2 Angebot für Handelsvertreter freigeben Ziel: Freigeben eines Angebots für Handelsvertreter Vorbedingung: Fertiggestelltes Angebot Auslösendes Ereignis: Fertiggestelltes Angebot, das der Hersteller dem Handelsvertreter freigibt und damit weiterleitet. Beschreibung: Nach Fertigstellung und Freigabe eines Angebots wird dieses über die Plattform an den Hersteller weitergeleitet. Akteure: Hersteller Ergebnis: Weitergeleitetes Angebot an Handelsvertreter Nachbedingung Erfolg: Die erfolgreiche Freigabe/Weiterleitung des Angebots wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Freigabe/Weiterleiten eines Angebots werden protokolliert. Erweiterungen: - Alternativen: - B.2.7 Entgegennahme und Bearbeitung von Bestellungen B.2.7.1 Bestellungen/Bestelländerungen empfangen/verwalten Ziel: Empfangen und verwalten von Bestellungen Vorbedingung: - Auslösendes Ereignis: Die folgenden Ereignisse lösen diesen Use Case aus: ± Neue Bestellungen treffen ein, ± Änderungen von bestehenden Bestellungen treffen ein, ± eine Bestellung soll abgerufen und bearbeitet werden. Beschreibung: Der Hersteller kann den aktuellen Stand von Bestellungen abrufen und einsehen (Übersichtsliste aller Bestellungen, Detailansicht der Bestellungen). - 228 - Akteure: Hersteller Ergebnis: Aktualisierte Bestellungen im Vertriebsinformationssystem Nachbedingung Erfolg: Der Empfang der Bestellung wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung von Bestellungen werden protokolliert. Erweiterungen: Bestelländerungen werden bestehenden Bestellungen zugeordnet. Da hier die Prozesse oft unterschiedlich ablaufen, ist eine weitere Detaillierung im Rahmen des Projekts nicht vorgesehen. Bei einer weiteren Konkretisierung der Plattformkonzeption müssen Bestelländerungen detaillierter betrachtet werden. Alternativen: - B.2.7.2 Angebot an Handelsvertreter versenden/freigeben Ziel: Freigeben eines Angebots für Handelsvertreter Vorbedingung: Fertiggestelltes Angebot Auslösendes Ereignis: Fertiggestelltes Angebot, das der Hersteller dem Handelsvertreter freigibt und damit weiterleitet. Beschreibung: Nach Fertigstellung und Freigabe eines Angebots wird dieses über die Plattform an den Hersteller weitergeleitet. Akteure: Hersteller Ergebnis: Weitergeleitetes Angebot an Handelsvertreter Nachbedingung Erfolg: Die erfolgreiche Freigabe/Weiterleitung des Angebots wird protokolliert. Nachbedingung Fehlschlag: Fehlermeldungen bei der Freigabe/Weiterleiten eines Angebots werden protokolliert. Erweiterungen: - Alternativen: - - 229 - B.2.8 Bereitstellung von Besuchsberichten an Hersteller B.2.8.1 Besuchsbericht empfangen/verwalten Ziel: Empfangen und verwalten von Besuchsberichten von Handelsvertretern Vorbedingung: - Auslösendes Ereignis: Nach Fertigstellung eines Besuchsberichts versendet der Handelsvertreter den Besuchsbericht an die entsprechenden Hersteller. Beschreibung: Der Hersteller kann den Besuchsbericht über ein Webinterface der Plattform empfangen und dort verwalten. Die folgenden Positionen eines Besuchsbericht können auftreten und müssen vom Hersteller bearbeitet werden können: ± Produkte ĺ3RVLWLRQHQ$XIOLVWXQJGHUQHXHQE]ZIUGHQ.XQGHQ interessanten Produkte zur Bestellung, zur Angebotsanfrage, mit Änderungsanfrage, mit sonstiger Erklärung (z. B. Gründe, warum das Produkt nicht für den Kunden von Interesse ist) ± Projekte (Auflistung jedes einzelnen Projekts) ĺ 3RVLWLRQHQ Auflistung offener Fragestellungen im Projekt inklusive detaillierter Hintergrundinformationen ± Geschäftsvorfälle ĺ 3RVLWLRQHQ $XIOLVWXQJ GHU RIIHQHQ Geschäftsvorfälle mit Klärungsbedarf inklusive detaillierter Hintergrundinformationen (z. B. Beschreibung des Klärungs- bedarfs) ± Sonstige Themen ĺ 3RVLWLRQHQ 8QWHUVFKLHGOLFKH 7KHPHQ inklusive detaillierter Hintergrundinformationen Zu jeder Position können mehrere Aktionspunkte (»Was muss getan werden?«) jeweils mit Festlegung eines Verantwortlichen und eines Endtermins zugeordnet werden. Akteure: Hersteller Ergebnis: Aktualisierte Besuchsberichte Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung von Besuchsberichten werden protokolliert. - 230 - Erweiterungen: Die Aktionspunkte sind weitestgehend Aufgaben, die in die Groupware des Herstellers importiert werden können. Alternativen: - B.2.9 Entgegennahme und Bestelländerungen B.2.9.1 Bestelländerungen empfangen/verwalten Der Use Case zum Empfangen und Verwalten von Bestelländerungen ist u. a. beschrieben in Use Case »Bestellungen/Bestelländerungen empfangen/verwalten« beschrieben. B.2.10 Erstellung/Versand von Rechnungen B.2.10.1 Rechnung erstellen Die Use Cases zum Erstellen von Rechnungen seitens Herstellern bzw. Handelsvertretungen sind ähnlich. Der Use Case seitens Handelsvertretungen ist unter »Rechnung erstellen« beschrieben. Unterschied zwischen den Use Cases seitens Handelsvertretungen und Herstellern ist, dass der Hersteller eine fertig erstellte Rechnung für den jeweiligen Handelsvertreter freigeben kann. B.2.10.2 Rechnungen versenden/freigeben Ziel: Versenden/freigeben einer Rechnung an eine Handelsvertretung Vorbedingung: Bestellung und die Rechnung sind angelegt und fertig gestellt. Auslösendes Ereignis: Bestellte Ware wird soeben bzw. wurde versendet. Beschreibung: Die für den Vorgang angelegte Auftragsbestätigung (ggf. Bestellung) wird in eine Rechnung überführt. Teillieferungen werden mit angepassten Mengen berücksichtigt. Akteure: Handelsvertreter Ergebnis: Angelegte Rechnung im System. Nachbedingung Neuanlage der Rechnung wird protokolliert. - 231 - Erfolg: Nachbedingung Fehlschlag: Fehlermeldungen bei der Neuanlage der Rechnung werden protokolliert Erweiterungen: - Alternativen: Alternativ kann die Rechnung auch manuell im System angelegt und eingepflegt werden. B.2.11 Abgleich der Provisionszahlungen mit Handelsvertretungen B.2.11.1 Provisionsvolumen eines Handelsvertreters abrufen Ziel: Abrufen des aktuellen Provisionsvolumens eines Handelsvertreters Vorbedingung: - Auslösendes Ereignis: Klärung des Provisionsvolumens eines Handelsvertreters Beschreibung: Der Hersteller erhält über das System eine Statistik mit folgenden Informationen: ± Ist-Provision in diesem Jahr (je Handelsvertretung), ± Ist-Provisionen je Monat (je Handelsvertretung), ± Hochrechnung über alle offenen Rechnungen je Handelsvertretung, ± Hochrechnung über alle offenen Bestellungen je Handelsvertretung, ± Hochrechnung über alle offenen Angebote je Handelsvertretung, ± Anzeige aller offenen Rechnungen, bei denen das Zahlungsziel überzogen wurde (sortiert nach Kunden/Handelsvertreter/Länge der Überziehung) Die Anzeige weiterer Auswertung ist je nach Anforderung seitens des Herstellers notwendig. Akteure: Hersteller Ergebnis: Statistiken der Provisionszahlungen Nachbedingung Erfolg: - - 232 - Nachbedingung Fehlschlag: Fehlermeldungen bei der Berechnung und Darstellung der Provisions- statistik werden protokolliert. Erweiterungen: - Alternativen: - B.2.12 Versand von bestellten Produkten B.2.12.1 Elektronische Lieferavis verwalten Ziel: Verwalten elektronischer Lieferavis Vorbedingung: - Auslösendes Ereignis: (Teil-)Lieferungen werden versendet. Beschreibung: Bei Versand einer (Teil-)Lieferung gibt der Hersteller ein Lieferavis ein. Inhalte der Lieferavis sind gemäß openTRANS (Version 2.0). Akteure: Hersteller Ergebnis: Aktualisierte Lieferavis Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung von Lieferavis werden protokolliert. Erweiterungen: - Alternativen: - - 233 - B.2.12.2 Elektronische Lieferavis versenden/freigeben Ziel: Versenden/freigeben elektronischer Lieferavis Vorbedingung: Lieferavis ist angelegt. Auslösendes Ereignis: (Teil-)Lieferungen werden versendet und Lieferavis ist erstellt. Beschreibung: Bei Versand einer (Teil-)Lieferung und nach Fertigstellung der Lieferavis versendet der Hersteller den Lieferavis an den Handelsvertreter. Im Rahmen der Lieferavis wird eine Tracking&Tracing Nummer und eine dazugehörende URL zum Abruf der Tracking&Tracing-Informationen beigefügt. Auf diese Weise kann der Handelsvertreter die Lieferung mitverfolgen und ist gegenüber seinen Kunden aussagekräftig. Akteure: Hersteller Ergebnis: Versendete Lieferavis Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen beim Versand/Freigabe der Lieferavis werden protokolliert. Erweiterungen: - Alternativen: - - 234 - B.2.13 Abfrage von Informationen über Geschäftsvorfälle B.2.13.1 Statusinformationen von Geschäftsvorfällen abrufen (Übersicht) Die Use Cases zum Abruf von Statusinformationen von Geschäftsvorfällen (Übersicht) seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Statusinformationen über Geschäftsvorfälle abrufen (Übersicht)« beschrieben. B.2.13.2 Details über Geschäftsvorfälle abrufen (Detailsicht) Die Use Cases zum Abruf von Details über Geschäftsvorfälle (Detailsicht) seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Details über Geschäftsvorfälle abrufen (Detailsicht)« beschrieben. B.2.14 Abgleich von elektronischen Geschäftsdokumenten mit Handelsvertretern B.2.14.1 Elektronische Geschäftsdokumente verwalten Die Use Cases zur Verwaltung elektronischer Geschäftsdokumente seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Elektronische Geschäftsdokumente verwalten« beschrieben. B.2.15 Bearbeitung von Reklamationen B.2.15.1 Reklamation empfangen/verwalten Ziel: Empfangen und verwalten von Reklamationen Vorbedingung: - Auslösendes Ereignis: Hersteller erhält eine Reklamation eines Kunden vom Handelsvertreter Beschreibung: Der Hersteller erhält ein Webinterface, das die aktuellen Reklamationen eines Handelsvertreters verwaltet. Der Hersteller sieht hierzu alle Reklamationen in einer Übersicht inklusive deren Status und in einer Detailansicht. - 235 - Akteure: Hersteller Ergebnis: Aktuelle Reklamationen Nachbedingung Erfolg: - Nachbedingung Fehlschlag: Fehlermeldungen bei der Verwaltung von Reklamation werden protokolliert. Erweiterungen: - Alternativen: - B.2.15.2 Status Reklamation versenden/freigeben Ziel: Versenden bzw. freigeben von Statusinformationen von Reklamationen Vorbedingung: Hersteller hat Reklamation erhalten. Auslösendes Ereignis: Hersteller hat Reklamation bearbeitet. Beschreibung: Der Hersteller kann über Webinterface Statusinformationen eintragen und diese dann versenden bzw. freigeben für den Handelsvertreter. Die Statusinformationen bestehen aus folgenden Inhalten: ± Statuskategorien: ± In Bearbeitung, ± Reklamation verweigert, ± Reklamation akzeptiert. ± Begründung einer Ablehnung (Textfeld), ± Reklamationshandling (Textfeld), d. h. Informationen, wie mit dem Vorgang umgegangen wird, ± Weitere Anmerkungen (Textfeld) Akteure: Hersteller Ergebnis: Aktueller Status einer Reklamation eintragen und versenden/freigeben Nachbedingung Erfolg: - - 236 - Nachbedingung Fehlschlag: Fehlermeldungen beim Eintragen oder Versenden einer Statusinformation von einer Reklamation werden protokolliert. Erweiterungen: - Alternativen: - B.2.16 Systemadministration B.2.16.1 Registrierung Die Use Cases zur Registrierung von Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Registrierung« beschrieben. B.2.16.1 Benutzer verwalten Die Use Cases zur Verwaltung von Benutzern von Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Benutzer verwalten« beschrieben. B.2.16.2 Rechte verwalten Die Use Cases zur Verwaltung von Rechten seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Rechte verwalten« beschrieben. B.2.16.3 Systemintegration konfigurieren Die Use Cases zur Konfiguration der Systemintegration seitens Herstellern bzw. Handelsvertretungen sind ähnlich. Der Use Case seitens Handelsvertretungen ist unter »Systemintegration konfigurieren« beschrieben. Unterschied zwischen den Use Cases seitens Handelsvertretungen und Herstellern ist die Integration eines möglichen Produktinformationsmanagementsystems, für das die folgenden Schnittstellen relevant sind: ± Import Produktkataloge in das Vertriebsinformationssystem, ± Aktualisierung von Preisinformationen, ± Aktualisierung von Bewegungsdaten. - 237 - B.2.16.4 Use Case anpassen Die Use Cases zur Anpassung der Use Cases für Hersteller bzw. Handelsvertretungen sind ähnlich. Der Use Case seitens Handelsvertretungen ist unter »Funktionalität anpassen« beschrieben. Unterschied zwischen den Use Cases seitens Handelsvertretungen und Herstellern sind die zur Auswahl angebotenen Use Cases. B.2.17 Management von Produktinformationen B.2.17.1 Produktinformationen importieren Die Use Cases für den Import von Produktinformationen seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Produktinformationen importieren« beschrieben. B.2.17.2 Produktinformationen einpflegen Die Use Cases für die Pflege von Produktinformationen seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Produktinformationen einpflegen« beschrieben. B.2.18 Durchführung der Kontaktverwaltung B.2.18.1 Kontakte verwalten Die Use Cases für die Verwaltung von Kontakten seitens Herstellern bzw. Handelsvertretungen sind identisch. Der Use Case seitens Handelsvertretungen ist unter »Kontakte verwalten« beschrieben. Anhang C: Anwendungsbeispiel des Referenzmodells In diesem Anhang sind die Geschäftsmodellelemente des in Abschnitt 9.1 beschriebenen Anwendungsbeispiels im Detail aufgeführt. Zielgruppe 1 (ZG1): Attribut Ausprägung Bezeichnung Kleine Handelsvertretungen Beschreibung Handelsvertretungen mit bis zu 5 Mitarbeitern, die aktuell eine unzureichende IT-Infrastruktur und damit eine geringe IT- Unterstützung ihrer Vertriebsprozesse besitzen. Die Handels- vertretungen sollten möglichst mehr als fünf Hersteller vertreten, um insbesondere die Vorteile der Multilieferantenfähigkeit der webbasierten Informationsplattform nutzen zu können. AnzahlInsgesamt 50.000 (Schätzwert) ErreichbareAnzahl 5.000 (Schätzwert) ErreichbarerAnteil 10 Prozent (Schätzwert) Beziehungen Zielgruppe ZG1 erhält Dienstleistungsangebot DA1 Zielgruppe ZG1 besitzt Organisation ZOrg1 Zielgruppe ZG1 besitzt Produkte ZProd1 Zielgruppe ZG1 besitzt Prozesse ZProz1 Zielgruppe ZG1 besitzt IT-Infrastruktur ZITInf1 ZielgruppeOrganisation 1 (ZOrg1): Attribut Ausprägung Kundentyp : Handelsvermittlung, : Handelsvertretung, † Handelsunternehmen, † Hersteller Herstelleranzahl † 1, † 2-3, † 4-5, : 6-10, : größer 10 ZielgruppeProdukte 1 (ZProd1): Attribut Ausprägung Bezeichnung : Standardprodukte, † konfigurierbare Produkte, † Individualprodukte - 239 - ZielgruppeProzesse 1 (ZProz1): Attribut Ausprägung GradITKompetenzEigentümer : keine, : geringe, † gute, † sehr gute ZielgruppeITInfrastruktur 1 (ZITInf1): Attribut Ausprägung ITAdministration : EigeneDurchEigentümer, † EigenenDurchMitarbeiterIT, (:) FremdeDurchDienstleister Dienstleistungsangebot 1 (DA1): Attribut Ausprägung Bezeichnung PremiumSalesService (Angebot) Beschreibung Der Zielgruppe wird eine webbasierte, mobile IT-Unterstützung ihrer Vertriebsprozesse angeboten. Die Administration wird vom Plattform- Anbieter durchgeführt, um Kunden diesbezüglich zu entlasten, so dass sie sich auf ihre eigentlichen Kernkompetenzen konzentrieren können. Unterstützt wird die Integration in bestehende Backendsysteme der Zielgruppe und Hersteller, wie z.B. ERP, CRM und PIM. Beziehungen Dienstleistungsangebot DA1 benötigt Dienstleistungserbringung DE1 Dienstleistungsangebot DA1 bestehtAus Dienstleistung DL1 Dienstleistungsangebot DA1 bestehtAus Dienstleistung DL2 Dienstleistung 1 (DL1): Attribut Ausprägung Bezeichnung BasicSalesPackage Beschreibung Grundlegende Funktionen, die zentrale Vertriebsprozesse der Zielgruppe unterstützen. Die Administration wird vom Plattform- Anbieter durchgeführt. Dieser stellt darüber hinaus eine 24/7- Hotline zur Verfügung, an die sich Kunden jederzeit wenden können. Nach Vertragsabschluss zwischen Kunde und Plattform-Anbieter findet ein Beratungsgespräch statt, in dem die Anforderungen an die Funktionen der Plattform aufgenommen werden und diese entsprechend konfiguriert wird. Die Innovation dieser Dienstleistung steckt zum einen in der multilieferantenfähigen IT-Untersützung der Vertriebsprozesse der - 240 - Zielgruppe und zum anderen in der Bereitstellung der Funktiona- lität über das Internet der Dienste. Alleinstellungspotenzial † kein, † innovative Imitation, : Branchenbester, : Innovation Preisniveau † kostenlos, † billig, † durchschnittlich, : hochpreisig Grundlegende Funktionen : Terminverwaltung, : Adressverwaltung, : Aufgabenverwaltung, : Dokumentenverwaltung Funktionen zur Kommunikation mit Herstellern : Produktinformationsmanagement (Produktkataloge für Standardprodukte), : Produktinformationsmanagement (Erstellung von Produktkatalogen), † Konfiguratoren (für zusammengesetzte/kombinierbare Produkte), † Unterstützung bei der Entwicklung kundenspezifischer Produkte (Individual- produkte), : Besuchsvorbereitung (Erstellung, Verwaltung), : Besuchsberichtswesen (Erstellung, Versand, Verwaltung), : Angebotsanfragen/Angebote, : Bestellungen/Rechnungen/Liefer- avis, † Reklamationen, : Reporting (z.B. Umsätze, Provisionen) Ergänzende Funktionen Finanzbuchhaltung † Einnahmen- und Ausgabenrechnung Ergänzende Funktionen CRM † Kampagnenplanung/-durchführung, † Leadmanagement Ergänzende Funktionen ERP † Lagerhaltung Begleitende Dienstleistungen : Beratung, : Konfiguration, † Erweiterungen, † Integration (Schnittstellen), : Hotline/Helpdesk Beziehungen Dienstleistung DL1 erzielt Erlös ER1 - 241 - Nutzen der Dienstleistung 1 (NU1): Attribut Ausprägung Beschreibung Der Nutzen des BasicSalesPackage liegt insbesondere darin, dass sich der Kunde auf seine Kernkompetenzen als Handelsvertreter konzentrieren kann. Tätigkeiten, die mit der Administration von IT-Systemen oder der manuellen Bearbeitung von Vertriebsinformationen an mehrere Hersteller zusammen- hängen, werden reduziert. Konzentration auf Kernaufgabe : Reduzierung manueller Tätigkeiten, : Reduzierung der eigenen Administration von IT-Lösungen Steigerung der Aussagefähigkeit † Steigerung der Aktualität der Vertriebsinformationen, : Ortsunabhängiger Abruf und Bereitstellung von Vertriebsinformationen, † Multimediale Aufbereitung von Produktinformationen für die Kundenpräsentation Effizienzsteigerung der Kernprozesse † Elektronische Unterstützung beim Austausch von Vertriebsinformationen, : Elektronische Unterstützung bei der Verwaltung von Vertriebsinformationen, : Multilieferanten- fähigkeit der IT-Unterstützung Beziehungen Nutzen NU1 beschreibt Dienstleistung DL1 Dienstleistung 2 (DL2): Attribut Ausprägung Bezeichnung IntegrationSalesPackage Beschreibung Zusätzlich zu dem oben aufgeführten BasicSalesPackage können Kunden das IntegrationSalesPackage beauftragen. Hier werden die für sie und ihre Hersteller relevanten Schnittstellen zu Backendsystemen, wie ERP, CRM und PIM, aufgenommen und realisiert. Im Rahmen der webbasierten Informationsplattform sollen Standardschnittstellen zu häufig genutzten Backendsystemen angeboten und auf diese Weise die Integration zunehmend vereinfacht werden. Alleinstellungspotenzial † kein, † innovative Imitation, : Branchenbester, † Innovation Preisniveau † kostenlos, † billig, † durchschnittlich, : hochpreisig Grundlegende † Terminverwaltung, † Adressverwaltung, - 242 - Funktionen † Aufgabenverwaltung, † Dokumentenverwaltung Funktionen zur Kommunikation mit Herstellern † Produktinformationsmanagement (Produktkataloge für Standardprodukte), † Produktinformationsmanagement (Erstellung von Produktkatalogen), † Konfiguratoren (für zusammengesetzte/kombinierbare Produkte), † Unterstützung bei der Entwicklung kundenspezifischer Produkte (Individual- produkte), † Besuchsvorbereitung (Erstellung, Verwaltung), † Besuchsberichtswesen (Erstellung, Versand, Verwaltung), † Angebotsanfragen/Angebote, : Bestellungen/Rechnung- en/Lieferavis, † Reklamationen, † Reporting (z.B. Umsätze, Provisionen) Ergänzende Funktionen Finanzbuchhaltung † Einnahmen- und Ausgabenrechnung Ergänzende Funktionen CRM † Kampagnenplanung/-durchführung, † Leadmanagement Ergänzende Funktionen ERP † Lagerhaltung Begleitende Dienstleistungen : Beratung, : Konfiguration, † Erweiterungen, : Integration (Schnittstellen), † Hotline/Helpdesk Beziehungen Dienstleistung DL2 erzielt Erlös ER2 Nutzen der Dienstleistung 2 (NU2): Attribut Ausprägung Beschreibung Der Nutzen des IntegrationSalesPackage besteht in der Reduzierung von Tätigkeiten, die mit der manuellen Pflege von Vertriebsinformationen zusammenhängen. Durch die Integration von Backendsystemen auf Seiten der Hersteller und ggf. auch Handels- vertretern werden die Vertriebsinformationen direkt mit der web- basierten Informationsplattform ausgetauscht. Darüber hinaus steigert dies die Aktualität der Vertriebsinformationen und damit auch die Aussagefähigkeit der Handelsvertreter bei Kunden vor Ort. Ebenso kommt die multilieferantenfähige IT-Unterstützung der Vertriebsprozesse durch den automatisierten Versand von Informa- tionen noch stärker zum Tragen als beim reinen BasicSalesPackage. Konzentration auf Kernaufgabe : Reduzierung manueller Tätigkeiten, † Reduzierung der eigenen Administration von IT-Lösungen - 243 - Steigerung der Aussagefähigkeit : Steigerung der Aktualität der Vertriebsinformationen, † Ortsunabhängiger Abruf und Bereitstellung von Vertriebsinformationen, † Multimediale Aufbereitung von Produktinformationen für die Kundenpräsentation Effizienzsteigerung der Kernprozesse : Elektronische Unterstützung beim Austausch von Vertriebsinformationen, † Elektronische Unterstützung bei der Verwaltung von Vertriebsinformationen, : Multilieferantenfähigkeit der IT-Unterstützung Beziehungen Nutzen NU2 beschreibt Dienstleistung DL2 Distributionskanäle 1 (DK1): Attribut Ausprägung Bezeichnung Ausgewogener Vertriebsmix für Handelsvertreter Beschreibung Zentrale Ansprache der Zielgruppe, die aus vielen sehr kleinen Handelsvertretungen besteht, erfolgt über einen Multiplikator, wie z.B. einem Verband, in dem viele der Handelsvertretungen organisiert sind. Flankiert wird diese Ansprache mit Informationen im Internet, Fachmagazinen und Veranstaltungen. Der Vertrieb sowie die Beratung und Umsetzung wird zu Beginn eigenständig durch das Konsortium durchgeführt, wobei sukzessive Partner, wie ValueAddedReseller aufgebaut werden sollen. Marketingkanal : Website, : Verband, : Fachmagazin, : VeranstaltungMesse Vertriebskanal : EigenerVertrieb, : ValueAddedReseller, † SystemsIntegrator Beratung und Umsetzung : EigeneBerater, : ValueAddedReseller, † SystemsIntegrator, † IndependantSoftwareVendor Beziehungen Distributionskanal DK1 vertreibt Dienstleistung DL1 Distributionskanal DK1 vertreibt Dienstleistung DL2 Kundenbeziehung 1 (KB1): Attribut Ausprägung Bezeichnung Intensive Kundenbindung Beschreibung Die Zielgruppe wird rundum betreut. Dies erfolgt durch eine Hotline mit CRM-Unterstützung und durch abgestimmte Weiterentwicklung der Plattform gemäß Kundenanforderungen. Zentrales Element ist das transparente Sicherheitskonzept, um das - 244 - Vertrauen der Zielgruppe aufzubauen. Da die Plattform die zentralen Vertriebsprozesse der Handelsvertreter unterstützt, würde ein Ausfall der Plattform die Aktivitäten der Kunden stark einschränken. Die webbasierte Informationsplattform soll als Marke aufgebaut und damit auch die Besonderheiten und Alleinstellungsmerkmale heraus- gestellt werden. Personalisierung † BetreuungDurchKeyAccountManager, : inCRMIntegrierter- HelpdeskHotline, : AnwenderspezifischeWeiterentwicklung- DurchBetreiber, † AnwenderspezifischeAnpassungDurchDritte Vertrauen : VertraglichZugesicherteLeistungen, : AnwendertageZum- Erfahrungsaustausch, : VeröffentlichungVonBestPracticeCases, : Anwenderschulungen, : Partnerschulungen, Partnerprogramm, : transparentesSicherheitskonzept Marke : AufbauEinerMarkeFürDieVertriebsplattform, † AufbauEinerMarke- FürErweiterungDerPlattformDurchAngeboteDritter, † AufbauEiner- MarkeFürAngeboteDritterDurchNutzungDerInfrastruktur AddOn Selling † EntwicklungVonStandardmodulenMitWeitererFunktionalität, † AngebotWeitererProduktBegleitenderDienstleistungen, † EntwicklungKundenIndividuellerDiensteFunktionalität Beziehungen Kundenbeziehung KB1 betrifft Dienstleistung DL1 Kundenbeziehung KB1 betrifft Dienstleistung DL2 Dienstleistungserbringung 1 (DE1): Attribut Ausprägung Bezeichnung PremiumSalesService (Erbringung) Beschreibung Die Dienstleistungserbringung umfasst allgemeine, organisatorische Abläufe, den Betrieb eines Rechenzentrums, die (Weiter-)Entwicklung der Informationsplattform, die Betreuung von Kunden, die Gewährleistung der IT-Sicherheit, die Durchführung kundenindividueller Leistungen sowie Marketing und Vertrieb. Beziehungen Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP1 Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP2 Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP3 Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP4 Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP5 Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP6 - 245 - Dienstleistungserbringung DE1 bestehtAus Dienstleistungsprozesse DP7 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR1 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR2 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR3 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR4 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR5 Dienstleistungserbringung DE1 bestehtAus KompetenzRessource KR6 Dienstleistungsprozesse 1 (DP1): Attribut Ausprägung Bezeichnung Allgemeine Organisation Beschreibung Darunter fällt die Koordination des Konsortiums und des Dienst- leistungsangebots. Unternehmens- infrastruktur : Planning_StrategischePlanung, : Organizing_OrganisierenVon- RessourcenUndStrukturen, : Staffing_Mitarbeiterauswahl, : Directing_HinleitungAufDasZiel, : Coordinating_Zusammenspiel, : Reporting_Berichtswesen, : Budgeting_PlanungDerFinanzen Technologie- entwicklung † EntwicklungNeuerServices, † OptimierungBestehenderServices, † Fehlerkorrekturen, † KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen † BereitstellungNeuerServices, † AdministrationDerServices, † Sicherheitsmanagement, † EinführungsunterstützungSchulungen, † ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst † FirstLevelSupport, † SecondLevelSupport, † ThirdLevelSupport Dienstleistungsprozesse 2 (DP2): Attribut Ausprägung Bezeichnung Organisation Rechenzentrum und IT-Infrastruktur Beschreibung Alle Teilprozesse, die nötig sind, um den Betrieb eines Rechenzentrums und der notwendigen IT-Infrastruktur zu planen und - 246 - durchzuführen. Unternehmens- infrastruktur † Planning_StrategischePlanung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- entwicklung † EntwicklungNeuerServices, † OptimierungBestehenderServices, † Fehlerkorrekturen, † KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen : BereitstellungNeuerServices, : AdministrationDerServices, † Sicherheitsmanagement, † EinführungsunterstützungSchulungen, † ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst † FirstLevelSupport, † SecondLevelSupport, : ThirdLevelSupport Dienstleistungsprozesse 3 (DP3): Attribut Ausprägung Bezeichnung Systementwicklung Beschreibung Alle Teilprozesse, die nötig sind, um die Plattform zu konzipieren, aufzubauen und kontinuierlich zu verbessern. Unternehmens- infrastruktur † Planning_Strategische Planung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- entwicklung : EntwicklungNeuerServices, : OptimierungBestehenderServices, : Fehlerkorrekturen, : KundenspezifischeAnpassungen, : TestenVonSoftwareentwicklungen Operationen : BereitstellungNeuerServices, † AdministrationDerServices, † Sicherheitsmanagement, † EinführungsunterstützungSchulungen, : ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- - 247 - Innendienst Kundendienst † FirstLevelSupport, † SecondLevelSupport, † ThirdLevelSupport Dienstleistungsprozesse 4 (DP4): Attribut Ausprägung Bezeichnung Kundenbetreuung Beschreibung Alle Teilprozesse, die nötig sind, um Kunden der webbasierten Informationsplattform bei der Nutzung zu unterstützen. Unternehmens- infrastruktur † Planning_StrategischePlanung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- entwicklung † EntwicklungNeuerServices, † OptimierungBestehenderServices, † Fehlerkorrekturen, † KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen † BereitstellungNeuerServices, † AdministrationDerServices, † Sicherheitsmanagement, † EinführungsunterstützungSchulungen, † ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst : FirstLevelSupport, : SecondLevelSupport, † ThirdLevelSupport Dienstleistungsprozesse 5 (DP5): Attribut Ausprägung Bezeichnung IT-Sicherheit Beschreibung Alle Teilprozesse, die nötig sind, um ein Sicherheitskonzept für die webbasierte Informationsplattform zu konzipieren, umzusetzen und kontinuierlich zu verbessern. Unternehmens- infrastruktur † Planning_StrategischePlanung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- : EntwicklungNeuerServices, : OptimierungBestehenderServices, - 248 - entwicklung † Fehlerkorrekturen, † KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen † BereitstellungNeuerServices, † AdministrationDerServices, : Sicherheitsmanagement, † EinführungsunterstützungSchulungen, † ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst : FirstLevelSupport, : SecondLevelSupport, : ThirdLevelSupport Dienstleistungsprozesse 6 (DP6): Attribut Ausprägung Bezeichnung Integration, kundenspezifische Beratung und Einführung Beschreibung Alle Teilprozesse, die nötig sind, um die Integration von Backendsystemen zu realisieren, Kunden bei der Umsetzung spezifischer Anforderungen zu unterstützen (Beratung/Umsetzung) und sie in die Nutzung der webbasierten Informationsplattform einzuführen. Unternehmens- infrastruktur † Planning_StrategischePlanung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- entwicklung † EntwicklungNeuerServices, † OptimierungBestehenderServices, † Fehlerkorrekturen, : KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen † BereitstellungNeuerServices, † AdministrationDerServices, † Sicherheitsmanagement, : EinführungsunterstützungSchulungen, : ProfessionalServices MarketingVertrieb † PlanungUndDurchführungVonPublicRelations, † PlanungUnd- DurchführungVonWerbung, † PlanungUndDurchführungVonAktionen- Events, † AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, † AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst † FirstLevelSupport, † SecondLevelSupport, † ThirdLevelSupport - 249 - Dienstleistungsprozesse 7 (DP7): Attribut Ausprägung Bezeichnung Marketing und Vertrieb Beschreibung Alle Teilprozesse, die nötig sind, um die webbasierte Informationsplattform bei der Zielgruppe bekannt zu machen und Kunden zu akquirieren. Unternehmens- infrastruktur † Planning_StrategischePlanung, † Organizing_OrganisierenVon- RessourcenUndStrukturen, † Staffing_Mitarbeiterauswahl, † Directing_HinleitungAufDasZiel, † Coordinating_Zusammenspiel, † Reporting_Berichtswesen, † Budgeting_PlanungDerFinanzen Technologie- entwicklung † EntwicklungNeuerServices, † OptimierungBestehenderServices, † Fehlerkorrekturen, † KundenspezifischeAnpassungen, † TestenVonSoftwareentwicklungen Operationen † BereitstellungNeuerServices, † AdministrationDerServices, † Sicherheitsmanagement, † EinführungsunterstützungSchulungen, † ProfessionalServices MarketingVertrieb : PlanungUndDurchführungVonPublicRelations, : PlanungUnd- DurchführungVonWerbung, : PlanungUndDurchführungVonAktionen- Events, : AkquiseBetreuungVonKundenInteressentenDurch- Außendienst, : AkquiseBetreuungVonKundenInteressentenDurch- Innendienst Kundendienst † FirstLevelSupport, † SecondLevelSupport, † ThirdLevelSupport Kompetenzen und Ressourcen 1 (KR1): Attribut Ausprägung Bezeichnung Allgemeine Organisation Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen, die zur allgemeinen Organisation des Konsortiums und des Dienstleistungs- angebots benötigt werden. Unternehmens- infrastruktur : AllgemeineOrganisation, † IuKInfrastruktur, : Geschäftsräume Technologie- entwicklung † KnowHowITArchitektur, † KnowHowProgrammierung, † KnowHowTesten Operationen † Rechenzentrum, † KnowHowITAdministration, - 250 - † KnowHowITSicherheit, † KnowHowSchulung MarketingVertrieb † KnowHowMarketing, † KnowHowDesign, † KnowHowVertrieb, : Fuhrpark Kundendienst † KnowHowKundenansprache Beziehungen KompetenzRessource KR1 verursacht Kosten KO1 Kompetenzen und Ressourcen 2 (KR2): Attribut Ausprägung Bezeichnung CRM und SaaS Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen, die die zentralen Funktionen der webbasierten Plattform ermöglichen. Dazu gehört die Entwicklung und Weiterentwicklung von Diensten, aber auch die Schulung und Betreuung von Kunden. Unternehmens- infrastruktur † AllgemeineOrganisation, : IuKInfrastruktur, † Geschäftsräume Technologie- entwicklung : KnowHowITArchitektur, : KnowHowProgrammierung, † KnowHowTesten Operationen † Rechenzentrum, † KnowHowITAdministration, † KnowHowITSicherheit, : KnowHowSchulung MarketingVertrieb † KnowHowMarketing, † KnowHowDesign, † KnowHowVertrieb, † Fuhrpark Kundendienst : KnowHowKundenansprache Beziehungen KompetenzRessource KR2 verursacht Kosten KO2 KompetenzRessource KR2 verursacht Kosten KO3 - 251 - Kompetenzen und Ressourcen 3 (KR3): Attribut Ausprägung Bezeichnung Rechenzentrum und IT-Administration Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen, die für den sicheren Betrieb und die Administration eines Rechenzentrums notwendig sind. Unternehmens- infrastruktur † AllgemeineOrganisation, : IuKInfrastruktur, † Geschäftsräume Technologie- entwicklung : KnowHowITArchitektur, : KnowHowProgrammierung, : KnowHowTesten Operationen : Rechenzentrum, : KnowHowITAdministration, : KnowHowITSicherheit, † KnowHowSchulung MarketingVertrieb † KnowHowMarketing, † KnowHowDesign, † KnowHowVertrieb, † Fuhrpark Kundendienst : KnowHowKundenansprache Beziehungen KompetenzRessource KR3 verursacht Kosten KO5 Kompetenzen und Ressourcen 4 (KR4): Attribut Ausprägung Bezeichnung Spezial Know-How Produktinformationsmanagement Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen, die für die Unterstützung des Produktinformationsaustauschs und der ±verwaltung benötigt werden. Unternehmens- infrastruktur † IuKInfrastruktur, † Geschäftsräume Technologie- entwicklung † KnowHowITArchitektur, : KnowHowProgrammierung, † KnowHowTesten Operationen † Rechenzentrum, † KnowHowITAdministration, † KnowHowITSicherheit, : KnowHowSchulung MarketingVertrieb † KnowHowMarketing, † KnowHowDesign, † KnowHowVertrieb, † Fuhrpark - 252 - Kundendienst : KnowHowKundenansprache Beziehungen KompetenzRessource KR4 verursacht Kosten KO6 KompetenzRessource KR4 verursacht Kosten KO7 Kompetenzen und Ressourcen 5 (KR5): Attribut Ausprägung Bezeichnung Spezial Know-How IT-Sicherheit Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen, die notwendig sind, um ein Sicherheitskonzept für die webbasierte Informationsplattform zu konzipieren, umzusetzen, testen und kontinuierlich zu verbessern. Unternehmens- infrastruktur † IuKInfrastruktur, † Geschäftsräume Technologie- entwicklung : KnowHowITArchitektur, : KnowHowProgrammierung, † KnowHowTesten Operationen † Rechenzentrum, † KnowHowITAdministration, : KnowHowITSicherheit, † KnowHowSchulung MarketingVertrieb † KnowHowMarketing, † KnowHowDesign, † KnowHowVertrieb, † Fuhrpark Kundendienst † KnowHowKundenansprache Beziehungen KompetenzRessource KR5 verursacht Kosten KO8 KompetenzRessource KR5 verursacht Kosten KO9 - 253 - Kompetenzen und Ressourcen 6 (KR6): Attribut Ausprägung Bezeichnung Marketing Beschreibung Bereitstellung derjenigen Kompetenzen und Ressourcen zur Durchführung der Marketing und Vertriebsprozesse (DP7) Unternehmens- infrastruktur † AllgemeineOrganisation, † IuKInfrastruktur, † Geschäftsräume Technologie- entwicklung † KnowHowITArchitektur, † KnowHowProgrammierung, † KnowHowTesten Operationen † Rechenzentrum, † KnowHowITAdministration, † KnowHowITSicherheit, † KnowHowSchulung MarketingVertrieb : KnowHowMarketing, : KnowHowDesign, : KnowHowVertrieb, † Fuhrpark Kundendienst : KnowHowKundenansprache Beziehungen KompetenzRessource KR6 verursacht Kosten KO4 Zielgruppe 2 (ZG2): Attribut Ausprägung Bezeichnung Hersteller Beschreibung Die zweite Zielgruppe der webbasierten Informationsplattform sind Hersteller, die ihren Vertrieb über Handelsvertreter organisieren. AnzahlInsgesamt 100.000 (bei einem geschätzten Durchschnitt von 2 Herstellern je Handelsvertreter ggfs. Berücksichtigung einer Beauftragung von teilweise mehreren Handelsvertretungen in Deutschland je Hersteller) ErreichbareAnzahl 10.000 (Schätzwert) ErreichbarerAnteil 10 Prozent (Schätzwert) Beziehungen Zielgruppe ZG2 erhält Dienstleistungsangebot DA2 Zielgruppe ZG2 besitzt Organisation ZOrg2 Zielgruppe ZG2 besitzt Produkte ZProd2 - 254 - ZielgruppeOrganisation 2 (ZOrg2): Attribut Ausprägung Kundentyp † Handelsvermittlung, † Handelsvertretung, † Handelsunternehmen, : Hersteller Herstelleranzahl † 1, † 2-3, † 4-5, † 6-10, : größer 10 ZielgruppeProdukte 2 (ZProd2): Attribut Ausprägung Bezeichnung : Standardprodukte, † konfigurierbare Produkte, † Individualprodukte Dienstleistungsangebot 2 (DA2): Attribut Ausprägung Bezeichnung SupplierPremiumService (Angebot) Beschreibung Um Vertriebsinformationen, wie z.B. Bestellungen, seitens der Hersteller schnellst möglich weiterleiten zu können, ist es notwendig deren IT-Systeme mit den darin verwalteten Vertriebsinformationen in die webbasierte Informationsplattform zu integrieren. Beziehungen Dienstleistungsangebot DA2 benötigt Dienstleistungserbringung DE2 Dienstleistungsangebot DA2 bestehtAus Dienstleistung DL3 Dienstleistungsangebot DA2 bestehtAus Dienstleistung DL4 Dienstleistung 3 (DL3): Attribut Ausprägung Bezeichnung SupplierIntegrationPackage PIM Beschreibung Um Herstellern ohne PIM-System die Möglichkeit zu geben Produktinformationen trotzdem elektronisch zur Verfügung zu stellen, werden entsprechende Funktionen zur Eingabe und Pflege webbasiert sowie Schnittstellen zu bestehenden PIM- Systemen bereitgestellt. Mit dem Angebot sollen insbesondere kleinere Hersteller in die Lage versetzt werden, sich an der Informationsplattform zu beteiligen. Daher werden die Funktionen zu marktüblichen Preisen angeboten. Alleinstellungspotenzial † kein, : innovative Imitation, † Branchenbester, † Innovation Preisniveau † kostenlos, † billig, : durchschnittlich, † hochpreisig - 255 - Grundlegende Funktionen † Terminverwaltung, † Adressverwaltung, † Aufgabenverwaltung, † Dokumentenverwaltung Funktionen zur Kommunikation mit Herstellern † Produktinformationsmanagement (Produktkataloge für Standardprodukte), : Produktinformationsmanagement (Erstellung von Produktkatalogen), † Konfiguratoren (für zusammengesetzte/kombinierbare Produkte), † Unterstützung bei der Entwicklung kundenspezifischer Produkte (Individual- produkte), † Besuchsvorbereitung (Erstellung, Verwaltung), † Besuchsberichtswesen (Erstellung, Versand, Verwaltung), † Angebotsanfragen/Angebote, † Bestellungen/Rech- nungen/Lieferavis, † Reklamationen, † Reporting (z.B. Umsätze, Provisionen) Ergänzende Funktionen Finanzbuchhaltung † Einnahmen- und Ausgabenrechnung Ergänzende Funktionen CRM † Kampagnenplanung/-durchführung, † Leadmanagement Ergänzende Funktionen ERP † Lagerhaltung Begleitende Dienstleistungen : Beratung, : Konfiguration, : Erweiterungen, : Integration (Schnittstellen), : Hotline/Helpdesk Beziehungen Dienstleistung DL3 bestehtAus Nutzen NU3 Dienstleistung DL3 bestehtAus Distributionskanälen DK2 Dienstleistung DL3 bestehtAus Kundenbeziehung KB2 Nutzen der Dienstleistung 3 (NU3): Attribut Ausprägung Beschreibung Der Nutzen des SupplierIntegrationPackage PIM liegt insbesondere darin, dass der Handelsvertreter aktuelle Produktinformationen erhält und auf diese Weise Kunden besser informieren kann. Konzentration auf Kernaufgabe : Reduzierung manueller Tätigkeiten, † Reduzierung der eigenen Administration von IT-Lösungen Steigerung der Aussagefähigkeit : Steigerung der Aktualität der Vertriebsinformationen, † Ortsunabhängiger Abruf und Bereitstellung von Vertriebsinformationen, † Multimediale Aufbereitung von - 256 - Produktinformationen für die Kundenpräsentation Effizienzsteigerung der Kernprozesse : Elektronische Unterstützung beim Austausch von Vertriebsinformationen, † Elektronische Unterstützung bei der Verwaltung von Vertriebsinformationen, † Multilieferantenfähigkeit der IT-Unterstützung Dienstleistung 4 (DL4): Attribut Ausprägung Bezeichnung SupplierIntegrationPackage ERP Beschreibung Zusätzlich zu dem oben aufgeführten SupplierIntegrationPackage PIM können Kunden das SupplierIntegrationPackage ERP be- auftragen. Hier werden die für sie und ihre Hersteller relevanten Schnittstellen zu Backendsystemen, wie ERP bzw. Warenwirt- schaft aufgenommen und realisiert, die bei der Abwicklung von Aufträgen unterstützen. Alleinstellungspotenzial † kein, : innovative Imitation, † Branchenbester, † Innovation Preisniveau † kostenlos, † billig, : durchschnittlich, † hochpreisig Grundlegende Funktionen † Terminverwaltung, † Adressverwaltung, † Aufgabenverwaltung, † Dokumentenverwaltung Funktionen zur Kommunikation mit Herstellern † Produktinformationsmanagement (Produktkataloge für Standardprodukte), † Produktinformationsmanagement (Erstellung von Produktkatalogen), † Konfiguratoren (für zusammengesetzte/kombinierbare Produkte), † Unterstützung bei der Entwicklung kundenspezifischer Produkte (Individual- produkte), † Besuchsvorbereitung (Erstellung, Verwaltung), † Besuchsberichtswesen (Erstellung, Versand, Verwaltung), † Angebotsanfragen/Angebote, : Bestellungen/Rechnung- en/Lieferavis, † Reklamationen, † Reporting (z.B. Umsätze, Provisionen) Ergänzende Funktionen Finanzbuchhaltung † Einnahmen- und Ausgabenrechnung Ergänzende Funktionen CRM † Kampagnenplanung/-durchführung, † Leadmanagement Ergänzende † Lagerhaltung - 257 - Funktionen ERP Begleitende Dienstleistungen : Beratung, : Konfiguration, † Erweiterungen, : Integration (Schnittstellen), † Hotline/Helpdesk Beziehungen Dienstleistung DL4 bestehtAus Nutzen NU4 Dienstleistung DL4 bestehtAus Distributionskanälen DK2 Dienstleistung DL4 bestehtAus Kundenbeziehung KB2 Nutzen der Dienstleistung 4 (NU4): Attribut Ausprägung Beschreibung Der Nutzen des SupplierIntegrationPackage ERP besteht in der Reduzierung von Tätigkeiten, die mit der manuellen Pflege von Vertriebsinformationen zusammenhängen. Durch die Integration von Backendsystemen auf Seiten der Hersteller und ggf. auch Handelsvertretern werden die Vertriebsinformationen direkt mit der webbasierten Informationsplattform ausgetauscht. Darüber hinaus steigert dies die Aktualität der Vertriebsinformationen und damit auch die Aussagefähigkeit der Handelsvertreter bei Kunden vor Ort. Konzentration auf Kernaufgabe : Reduzierung manueller Tätigkeiten, † Reduzierung der eigenen Administration von IT-Lösungen Steigerung der Aussagefähigkeit : Steigerung der Aktualität der Vertriebsinformationen, † Ortsunabhängiger Abruf und Bereitstellung von Vertriebsinformationen, † Multimediale Aufbereitung von Produktinformationen für die Kundenpräsentation Effizienzsteigerung der Kernprozesse : Elektronische Unterstützung beim Austausch von Vertriebsinformationen, † Elektronische Unterstützung bei der Verwaltung von Vertriebsinformationen, † Multilieferantenfähigkeit der IT-Unterstützung - 258 - Distributionskanäle 2 (DK2): Attribut Ausprägung Bezeichnung Ausgewogener Vertriebsmix für Hersteller Beschreibung Die Ansprache der Zielgruppe der Hersteller erfolgt überwiegend über Handelsvertreter. Handelsvertreter, die die Informationsplattform nutzen (wollen), werden motiviert ihre Hersteller anzusprechen, sich ebenso zu beteiligen. Ziel ist dabei, die Nutzenpotenziale der Plattform weitestgehend zu realisieren. Flankiert wird diese Ansprache mit Informationen im Internet, Fach- magazinen und Veranstaltungen. Der Vertrieb sowie die Beratung und Umsetzung werden zu Beginn eigenständig durch das Konsortium durchgeführt, wobei sukzessive Partner, wie ValueAddedReseller aufgebaut werden. Marketingkanal : Website, † Verband, : Fachmagazin, : VeranstaltungMesse Vertriebskanal : EigenerVertrieb, : ValueAddedReseller, † SystemsIntegrator Beratung und Umsetzung : EigeneBerater, : ValueAddedReseller, † SystemsIntegrator, † IndependantSoftwareVendor Kundenbeziehung 2 (KB2): Attribut Ausprägung Bezeichnung Intensive Kundenbindung Beschreibung Die Zielgruppe wird rundum betreut. Dies erfolgt durch eine Hotline mit CRM-Unterstützung und durch abgestimmte Weiterentwicklung der Plattform gemäß Kundenanforderungen. Zentrales Element ist das transparente Sicherheitskonzept, um das Vertrauen der Zielgruppe aufzubauen. Da die Plattform die Kommunikation zwischen Handelsvertretern und ihren Herstellern unterstützt, würde ein Ausfall der Plattform die Vertriebsaktivitäten stark einschränken. Die webbasierte Informationsplattform soll als Marke aufgebaut und damit auch die Besonderheiten und Alleinstellungsmerkmale heraus- gestellt werden. Personalisierung † BetreuungDurchKeyAccountManager, : inCRMIntegrierter- HelpdeskHotline, : AnwenderspezifischeWeiterentwicklung- - 259 - DurchBetreiber, † AnwenderspezifischeAnpassungDurchDritte Vertrauen : VertraglichZugesicherteLeistungen, : AnwendertageZum- Erfahrungsaustausch, : VeröffentlichungVonBestPracticeCases, : Anwenderschulungen, : Partnerschulungen, Partnerprogramm, : transparentesSicherheitskonzept Marke : AufbauEinerMarkeFürDieVertriebsplattform, † AufbauEinerMarke- FürErweiterungDerPlattformDurchAngeboteDritter, † AufbauEiner- MarkeFürAngeboteDritterDurchNutzungDerInfrastruktur AddOn Selling † EntwicklungVonStandardmodulenMitWeitererFunktionalität, † AngebotWeitererProduktBegleitenderDienstleistungen, † EntwicklungKundenIndividuellerDiensteFunktionalität Dienstleistungserbringung 2 (DE2): Attribut Ausprägung Bezeichnung SupplierPremiumService (Erbringung) Beschreibung Die Dienstleistungserbringung umfasst allgemeine, organisatorische Abläufe, den Betrieb eines Rechenzentrums, die (Weiter-)Entwicklung der Informationsplattform, die Betreuung von Kunden, die Gewährleistung der IT-Sicherheit, die Durchführung kundenindividueller Leistungen sowie Marketing und Vertrieb. Zusätzliche Kompetenzen und Ressourcen zu den schon aufgeführten werden nicht benötigt. Beziehungen Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP1 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP2 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP3 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP4 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP5 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP6 Dienstleistungserbringung DE2 bestehtAus Dienstleistungsprozesse DP7 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR1 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR2 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR3 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR4 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR5 Dienstleistungserbringung DE2 bestehtAus KompetenzRessource KR6 - 260 - Partner 1 (PA1): Attribut Ausprägung Bezeichnung Anbieter von SaaS-CRM Beschreibung Langjähriger Anbieter einer CRM-Lösung, die als Lizenz- sowie als SaaS-Lösung angeboten wird. Der Anbieter bringt u.a. ein eigenes Netzwerk mit Vertriebspartnern mit, auf das zurückgegriffen werden kann. Beziehungen Partner PA1 erzielt Gewinn EG1 Partner 2 (PA2): Attribut Ausprägung Bezeichnung Betreiber einer webbasierten Transaktionsplattform Beschreibung Langjähriger Anbieter von webbasierten Transaktionsplattformen als Branchenlösungen. Beziehungen Partner PA2 erzielt Gewinn EG2 Partner 3 (PA3): Attribut Ausprägung Bezeichnung Anbieter von IT-Systemen zum Produktinformationsmanagement Beschreibung Langjähriger Anbieter von IT-Werkzeugen zur Aufbereitung, Verwaltung und Ausgabe von Produktinformationen. Beziehungen Partner PA3 erzielt Gewinn EG3 Partner 4 (PA4): Attribut Ausprägung Bezeichnung Unternehmen mit Kernkompetenz in IT-Sicherheit Beschreibung Anbieter von Sicherheitslösungen für webbasierte IT-Lösungen. Beziehungen Partner PA4 erzielt Gewinn EG4 - 261 - Kosten 1 (KO1): Attribut Ausprägung Beschreibung Kosten, die für die Organisation und das Projektmanagement anfallen, u.a. für einen Projektleiter, Räumlichkeiten und Kosten für Verwaltung. Die Ressourcen werden durch Projektpartner PA1 bereitgestellt. Kosten 300.000 Euro/Jahr (Schätzwert) Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO1 beeinflussen Gewinn EG1 Kosten 2 (KO2): Attribut Ausprägung Beschreibung Eine bestehende Version der CRM-Software des Partners PA1 wird zur Nutzung als SaaS aufbereitet. Hierzu werden Entwickler sowie eine geeignete Entwicklungsumgebung benötigt. Kosten 300.000 Euro (Schätzwert) Wiederkehrend : Einmalig, † wiederkehrend Beziehungen Kosten KO2 beeinflussen Gewinn EG1 Kosten 3 (KO3): Attribut Ausprägung Beschreibung Die Software wird stetig weiterentwickelt und weitere Funktionalitäten integriert. Kosten 100.000 Euro/Jahr (Schätzwert) Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO3 beeinflussen Gewinn EG1 Kosten 4 (KO4): Attribut Ausprägung Beschreibung Um die Informationsplattform zu bewerben, wird ein Marketingbudget zur Verfügung gestellt. Darüber hinaus werden für Vertriebspartner Provisionen in Höhe eines Jahreserlöses eines Kunden ausgelobt. Kosten 728.000 Euro/Jahr (Schätzwert) - 262 - Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO4 beeinflussen Gewinn EG1 Kosten 5 (KO5): Attribut Ausprägung Beschreibung Das Rechenzentrum wird von einem Administrator verwaltet, die Rechner werden als Dienst von einem IT-Dienstleister gemietet. Kosten 170.000 Euro/Jahr (Schätzwert) Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO5 beeinflussen Gewinn EG2 Kosten 6 (KO6): Attribut Ausprägung Beschreibung Die PIM-Funktionalitäten werden durch Partner PA3 bereitgestellt. Hierfür ist eine Erstentwicklung der Funktionalitäten notwendig und damit auch der Einrichtung einer geeigneten Entwicklungsumgebung. Kosten 50.000 Euro (Schätzwert) Wiederkehrend : Einmalig, † wiederkehrend Beziehungen Kosten KO6 beeinflussen Gewinn EG3 Kosten 7 (KO7): Attribut Ausprägung Beschreibung Die PIM-Funktionalitäten werden sukzessive weiterentwickelt. Kosten 20.000 Euro/Jahr (Schätzwert) Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO7 beeinflussen Gewinn EG3 - 263 - Kosten 8 (KO8): Attribut Ausprägung Beschreibung Partner PA4 entwickelt ein IT-Sicherheitskonzept. Dies ist insbesondere notwendig, da die Informationsplattform und ihre Funktionalitäten verteilt von allen Partnern angeboten und über Web Service Schnittstellen integriert werden. Kosten 65.000 Euro (Schätzwert) Wiederkehrend : Einmalig, † wiederkehrend Beziehungen Kosten KO8 beeinflussen Gewinn EG4 Kosten 9 (KO9): Attribut Ausprägung Beschreibung Das IT-Sicherheitskonzept wird regelmäßig geprüft und ggf. weiterentwickelt. Kosten 20.000 Euro/Jahr (Schätzwert) Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Kosten KO9 beeinflussen Gewinn EG4 Erlös 1 (ER1): Attribut Ausprägung Beschreibung Erlöse, die durch Handelsvertreter (Zielgruppe ZG1) mit dem BasisSalesPackage für 100 Euro pro Monat erzielt werden. Hierbei ist Ziel 2.500 Handelsvertreter in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 500 neue Handelsvertreter. Erlös 1.500.000 Euro/Jahr Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Erlös ER1 beeinflusst Gewinn EG1 Erlös ER1 beeinflusst Gewinn EG2 Erlös ER1 beeinflusst Gewinn EG3 Erlös ER1 beeinflusst Gewinn EG4 Erlös 2 (ER2): - 264 - Attribut Ausprägung Beschreibung Erlöse, die durch Handelsvertreter (Zielgruppe ZG1) mit dem IntegrationSalesPackage erzielt werden. Hierbei ist Ziel, dass von 2.500 Handelsvertreter in den ersten 5 Jahren des BasisSalesPackage ca. 20 Prozent das IntegrationSalesPackage zu 20 Euro pro Monat nutzen. Erlös 60.000 Euro/Jahr Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Erlös ER2 beeinflusst Gewinn EG1 Erlös ER2 beeinflusst Gewinn EG2 Erlös ER2 beeinflusst Gewinn EG3 Erlös ER2 beeinflusst Gewinn EG4 Erlös 3 (ER3): Attribut Ausprägung Beschreibung Erlöse, die durch Hersteller (Zielgruppe ZG2) mit dem SupplierIntegrationPackage PIM zu 20 Euro pro Monat erzielt werden. Hierbei ist Ziel 1.000 Hersteller in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 200 neue Hersteller. Erlös 48.000 Euro/Jahr Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Erlös ER3 beeinflusst Gewinn EG1 Erlös ER3 beeinflusst Gewinn EG2 Erlös ER3 beeinflusst Gewinn EG3 Erlös ER3 beeinflusst Gewinn EG4 - 265 - Erlös 4 (ER4): Attribut Ausprägung Beschreibung Erlöse, die durch Hersteller (Zielgruppe ZG2) mit dem SupplierIntegrationPackage ERP zu 20 Euro pro Monat erzielt werden. Hierbei ist Ziel 1.000 Hersteller in den ersten 5 Jahren zu akquirieren. Durchschnittlich pro Jahr also 200 neue Hersteller. Erlös 48.000 Euro/Jahr Wiederkehrend † Einmalig, : wiederkehrend Beziehungen Erlös ER4 beeinflusst Gewinn EG1 Erlös ER4 beeinflusst Gewinn EG2 Erlös ER4 beeinflusst Gewinn EG3 Erlös ER4 beeinflusst Gewinn EG4 Gewinn 1 für Partner PA1 (EG1): Attribut Ausprägung Betrachtungszeitraum (in Jahren) 5 Durchschnittliche Kosten je 3DUWQHUSUR-DKU ¼-DKU 1.188.000 Erlösanteil je Partner (%) 83,8 Durschnittlicher Erlös je 3DUWQHUSUR-DKU ¼-DKU 1.387.728 Durchschnittlicher Gewinn je 3DUWQHUSUR-DKU ¼-DKU 170.028 Kalkulatorische Zinsen je 3DUWQHUSUR-DKU ¼-DKU 29.700 Rentabilität je Partner pro Jahr (%/Jahr) 17 - 266 - Gewinn 2 für Partner PA2 (EG2): Attribut Ausprägung Betrachtungszeitraum (in Jahren) 5 Durchschnittliche Kosten je 3DUWQHUSUR-DKU ¼-DKU 170.000 Erlösanteil je Partner (%) 12,0 Durchschnittlicher Erlös je 3DUWQHUSUR-DKU ¼-DKU 198.720 Durchschnittlicher Gewinn je 3DUWQHUSUR-DKU ¼-DKU 25.320 Kalkulatorische Zinsen je 3DUWQHUSUR-DKU ¼-DKU 3.400 Rentabilität je Partner pro Jahr (%/Jahr) 17 - 267 - Gewinn 3 für Partner PA3 (EG3): Attribut Ausprägung Betrachtungszeitraum (in Jahren) 5 Durchschnittliche Kosten je 3DUWQHUSUR-DKU ¼-DKU 30.000 Erlösanteil je Partner (%) 2,0 Durchschnittlicher Erlös je 3DUWQHUSUR-DKU ¼-DKU 33.120 Durchschnittlicher Gewinn je 3DUWQHUSUR-DKU ¼-DKU 2.520 Kalkulatorische Zinsen je 3DUWQHUSUR-DKU ¼-DKU 600 Rentabilität je Partner pro Jahr (%/Jahr) 10 - 268 - Gewinn 4 für Partner PA4 (EG4): Attribut Ausprägung Betrachtungszeitraum (in Jahren) 5 Durchschnittlicher Kosten je 3DUWQHUSUR-DKU ¼-DKU 33.000 Erlösanteil je Partner (%) 2,2 Durchschnittlicher Erlös je 3DUWQHUSUR-DKU ¼-DKU 36.432 Durchschnittlicher Gewinn je 3DUWQHUSUR-DKU ¼-DKU 2.772 Kalkulatorische Zinsen je 3DUWQHUSUR-DKU ¼-DKU 660 Rentabilität je Partner pro Jahr (%/Jahr) 10