Enterprise 2.0: Konzeption eines Wikis im Sinne des prozessorientierten Wissensmanagements

Forschung am IVW Köln, 7/2015 Institut für Versicherungswesen Enterprise 2.0: Konzeption eines Wikis im Sinne des prozessorientierten Wissensmanagements Michaele Völler, Lilli Wunder Forschung am IVW Köln, 7 / 2015 Wählen Sie ein Element aus. Michaele Völler, Lilli Wunder Enterprise 2.0: Konzeption eines Wikis im Sinne des prozessorientierten Wissensmanagements Zusammenfassung Ein Wiki ist eine Form von Social Software, die sich insbesondere zur Unterstützung der kollaborativen Wissensverarbeitung eignet und zunehmend im Unternehmenskontext eingesetzt wird. Ein Wiki lebt vom Prinzip der kollektiven Intelligenz. Somit wird die Schaffung einer kritischen Masse an Nutzern zum Erfolgsfaktor. Erkennt der Nutzer einen echten Mehrwert, so ist er gewillt, die Anwendung zu nutzen. Um diesen Mehrwert zu generieren, erfordert es eine funktionale Integration in die Arbeitsprozesse und die Systemlandschaft des Unternehmens. Um dies zu gewährleisten, wird in der vorliegenden Veröffentlichung eine idealtypische Vorgehensweise zur Einführung eines Wikis entwickelt. Es wird gezeigt, wie sich der Grundgedanke des prozessorientierten Wissensmanagements auf die Konzeption eines Wikis übertragen lässt. Die erarbeiteten theoretischen Grundlagen werden an der beispielhaften fachlichen Konzeption eines Wikis zur Unterstützung des Wissensmanagements im Produktentwicklungsprozess eines Lebensversicherers angewendet. Zu diesem Zweck werden Anwendungsszenarien entwickelt, in denen die Nutzer durch den Einsatz des Wikis profitieren. Abstract A wiki is a social software which is suitable for collaborative knowledge processing. Wikis are increasingly used within and by enterprises. They rely on the concept of collective intelligence and therefore a critical number of users is a key success factor. End users who realize the benefits of a wiki are willing to use this application. A functional integration into organizational processes and into the system landscape of the enterprise is required in order to create a clear added value. This paper presents an ideal-typical approach for the implementation of a wiki which adopts the basic principle of process-oriented knowledge management. The final chapter gives a practical example as it describes the design of a wiki which supports the product development process of a life insurer. Schlagwörter: Digitalisierung, Enterprise 2.0, Forschungsstelle Versicherungsmarkt, Produktentwicklungsprozess, prozessorientiertes Wissensmanagement, Social Software, Wiki, Wissensmanagement, Wissensmanagement in der Versicherungsbranche - 1 - Inhaltsverzeichnis ABBILDUNGSVERZEICHNIS ............................................................................................................................... 2 ABKÜRZUNGSVERZEICHNIS ............................................................................................................................. 3 1 VORWORT ...................................................................................................................................................... 4 2 MOTIVATION ................................................................................................................................................ 4 3 ENTERPRISE 2.0 – SOCIAL SOFTWARE IM UNTERNEHMENSKONTEXT ................................... 7 3.1 ENTERPRISE 2.0 UND SEINE EINSATZEBENEN ............................................................................................. 7 3.2 DIE ZENTRALEN BEGRIFFE WEB 2.0, SOCIAL SOFTWARE UND SOCIAL MEDIA ........................................ 8 3.3 DIE VIELFALT AN SOCIAL SOFTWARE ........................................................................................................11 3.4 DAS WIKI – MEHR ALS TECHNOLOGIE ......................................................................................................15 3.4.1 Das Wiki und seine Funktionsweise ..................................................................................... 15 3.4.2 Nutzenund Einsatzpotenziale ............................................................................................. 17 3.4.3 Erfolgsfaktoren und Indikatoren zur Erfolgsmessung .................................................... 19 4 PROZESSORIENTIERTES WISSENSMANAGEMENT (PWM) ..........................................................25 4.1 WISSENSMANAGEMENT (WM) .................................................................................................................25 4.1.1 Der Wissensbegriff ................................................................................................................... 25 4.1.2 Grundlagen des Wissensmanagements ............................................................................. 26 4.2 DAS KONZEPT DES PROZESSORIENTIERTEN WISSENSMANAGEMENTS ....................................................31 4.2.1 Definition .................................................................................................................................... 31 4.2.2 Ausgewählte pWM-Methoden .............................................................................................. 34 5 KONZEPTION EINES PROZESSORIENTIERTEN WIKIS ....................................................................41 5.1 DER ANSATZ DER PROZESSORIENTIERUNG IN DER KONZEPTION EINES WIKIS .......................................41 5.2 ABLEITUNG EINES IDEALTYPISCHEN EINFÜHRUNGSPROZESSES ...............................................................42 5.3 ENTWURF EINES FACHKONZEPTS ALS ANWENDUNGSBEISPIEL................................................................46 5.3.1 Anwendungsbereich, Zielsetzung und Vorgehen ........................................................... 46 5.3.2 Analyseergebnisse zu Prozess und wissensintensiven Aktivitäten .............................. 48 5.3.3 Aufbau und Funktionalitäten des Wikis ............................................................................. 52 5.3.4 Anwendungsszenarien ........................................................................................................... 60 6 FAZIT UND AUSBLICK .............................................................................................................................65 LITERATURUND QUELLENVERZEICHNIS..................................................................................................67 ANHANG ................................................................................................................................................................74 - 2 - Abbildungsverzeichnis Abb. 1: Altersgliederung im Innendienst der Versicherer 2013 vs. 2003 ........................................ 5 Abb. 2: Einsatzebenen von Social Software ............................................................................................... 7 Abb. 3: Einsatzfelder von Social Software ................................................................................................... 9 Abb. 4: Zuordnung von Social Software zu den Einsatzfeldern .......................................................14 Abb. 5: Interventionsebenen im Rahmen einer Wiki-Einführung ...................................................23 Abb. 6: Bausteine des Wissensmanagements .........................................................................................28 Abb. 7: Das SECI-Modell ...................................................................................................................................29 Abb. 8: Beispielhafte Zerlegung eines Geschäftsprozesses ...............................................................32 Abb. 9: Einteilung von Geschäftsprozessen .............................................................................................33 Abb. 10: Wissensmanagement-Referenzmodell der Fraunhofer IPK .............................................36 Abb. 11: Zuordnung von Wissensprozessen zum Geschäftsprozess „Kreditantrag“ ...............38 Abb. 12: Abgeleiteter idealtypischer Wiki-Einführungsprozess .......................................................42 Abb. 13: Produktentwicklungsprozess eines Lebensversicherers ...................................................46 Abb. 14: Überblick über die wesentlichen PEP-Schritte ......................................................................49 Abb. 15: Startseite des Wikis ..........................................................................................................................53 Abb. 16: Startseite des Wiki-Arbeitsbereichs ...........................................................................................54 Abb. 17: Arbeitsvorlage: Anlegen eines PEP-Projektes .......................................................................55 Abb. 18: Nutzergruppen zur Steuerung der Zugriffsberechtigung ................................................56 Abb. 19: Steuerung der Zugriffsund Bearbeitungsberechtigung .................................................57 Abb. 20: Aufbau des Projektmanagementbereichs ..............................................................................60 Abb. 21: Entwurf eines Umsetzungsplans ................................................................................................61 Abb. 22: Kollektivierung von Lessons Learned .......................................................................................63 Abb. 23: Die untersuchten Fallstudien im Überblick ............................................................................74 Abb. 24: Screenshot vom Personenverzeichnis .....................................................................................75 Abb. 25: Screenshot vom Netzwerk ............................................................................................................75 Abb. 26: Vorwort zur Erstellung von Besprechungsnotizen ..............................................................75 Abb. 27: Vorlage zur Erstellung von Besprechungsnotizen ...............................................................76 Abb. 28: Erstellte Vorlage zur Dokumentation eines Projektauft rags ............................................76   - 3 - Abkürzungsverzeichnis Abb. BITKOM Bsp. Abbildung Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. Beispiel bspw. beispielsweise bzw. beziehungsweise i.d.R. in der Regel PEP Produktentwicklungsprozess pWM prozessorientiertes Wissensmanagement S. Seite s. siehe u.a. unter anderem vgl. VU vergleiche Versicherungsunternehmen WM Wissensmanagement z.B. zum Beispiel - 4 - 1. Vorwort Im Rahmen einer „Mentoring-Arbeit“1 im Sommer 2013 und einer Master-Thesis im Sommer 2014 wurden am Institut für Versicherungswesen verschiedene Aspekte des Einsatzes von Social Software im Unternehmenskontext beleuchtet. Die behandelten Fragestellungen waren herausfordernd, da das übergreifende Thema ein noch wenig erforschtes Gebiet darstellt. Im Mentoring wurden zunächst die Grundlagen zum Thema „Enterprise 2.0: Einsatz von Social Software im Unternehmenskontext“2 geklärt, um hierauf aufbauend in der MasterThesis eine konkrete Anwendung von Social Software zu entwickeln und die „Konzeption eines Wikis im Sinne des prozessorientierten Wissensmanagements“3 zu erarbeiten. Hierdurch wurden die beiden hochrelevanten Themen Web 2.0 und Wissensmanagement vereint. Die vorliegende Veröffentlichung stellt die im Mentoring und in der Masterthesis gewonnenen Ergebnisse zum Thema „Enterprise 2.0“ vor. Neuartig ist hierbei insbesondere die Verknüpfung eines Wikis als Social Software mit dem Gedanken des prozessorientierten Wissensmanagements. Wir bedanken uns bei der Firma Atlassian für die Erlaubnis, die Screenshots des Wiki-Entwurfs für das Anwendungsbeispiel abbilden zu dürfen, die mit der Wiki-Software Atlassian Confluence erstellt wurden. 2. Motivation Im Web 2.0 bieten Wikis eine Kollaborationsplattform zum Sammeln und Vermitteln von Wissen. Bekannt ist die Online-Enzyklopädie Wikipedia, der die wissenschaftliche Zeitschrift Nature schon in 2005 eine ähnliche Qualität wie der Encyclopaedia Britannica zusprach.4 Wikipedia hat sich binnen weniger Jahre weltweit zum meist genutzten Nachschlagewerk entwickelt und stellt das bekannteste öffentlich zugängliche Wiki dar.5 Aber nicht nur im Privatleben, sondern auch in Unternehmen werden mittlerweile Social Software-Komponenten und speziell Wikis als einfach zu bedienende, webbasierte, kollaborative Anwendungen eingesetzt. Laut einer BITKOM-Studie aus dem Jahr 2008 bescheinigten schon damals bereits 37% bis 47% der Befragten6 eine produktive Nutzung der Social 1 Im Mentoring-Modul arbeiten Masterstudenten als „Mentee“ an einem selbst gewählten Forschungsvorhaben unter Betreuung eines Dozenten als „Mentor“. In den Diskussionen mit dem Mentor erhält der Mentee inhaltliche Impulse und methodische Hinweise, muss das Thema aber letztlich eigenverantwortlich vorantreiben und eigenständig neue Einsichten erarbeiten. 2 Titel der Mentoring-Arbeit von Lilli Wunder, Sommersemester 2013, betreut von Michaele Völler 3 Titel der Master-Thesis von Lilli Wunder, Sommersemester 2014, betreut von Michaele Völler 4 Vgl. [Giles 2005] in Nature 438, 900-901 5 Vgl. [Komus/Wauch 2008], S.42-46 6 Befragt wurden 400 Unternehmen, mehrheitlich Entscheider, aus unterschiedlichen Branchen (vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM): Studie „Enterprise 2.0 – Analyse zu Stand und Perspektiven in der deutschen Wirtschaft“, 2008, S.4) - 5 - Software Wiki, ansteigend mit der Betriebsgröße.7 Weitere knapp 40 % der befragten Unternehmen befanden sich in der Einführungsund Testphase, nur wenige planten keine Implementierung.8 Wikis unterstützen die kollaborative Wissensverarbeitung und sind daher von besonderem Interesse für Unternehmen. Im Zuge des demographischen Wandels und des damit verbundenen vermehrten Eintritts von Wissensträgern in den Ruhestand werden die Sicherung und der Transfer von Wissen auf die verbleibenden Mitarbeiter immer wichtiger. Wie in anderen Branchen hat sich auch in den Versicherungsunternehmen die Altersstruktur der Mitarbeiter im letzten Jahrzehnt deutlich nach oben verschoben, womit ein Wissensverlust in naher Zukunft droht. Abb. 1: Altersgliederung im Innendienst der Versicherer 2013 vs. 20039 7 Vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM): Studie „Enterprise 2.0 – Analyse zu Stand und Perspektiven in der deutschen Wirtschaft“, 2008, S. 14 8 Vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM): Studie „Enterprise 2.0 – Analyse zu Stand und Perspektiven in der deutschen Wirtschaft“,2008, S. 12-14 9 Arbeitgeberverband der Versicherungsunternehmen in Deutschland e. V. (AGV): Broschüre „Sozialstatistische Daten 2013“, S. 11, und http://www.agv-vers.de/statistiken/mitarbeiterstruktur/altersstruktur.html [Zugriff am 30.01.2015] - 6 - Gerade für Branchen mit wissensintensiven Prozessen wie die Assekuranz gewinnt somit ein systematisches und erfolgreiches Wissensmanagement zunehmend an Bedeutung. Da ein Wiki vom Prinzip der kollektiven Intelligenz lebt, ist eine kritische Masse an Nutzern erforderlich. Ein Nutzer wiederum ist nur gewillt, die Anwendung konsequent zu nutzen, wenn er ihren Mehrwert erkennt. Dieser Mehrwert kann durch eine funktionale Integration des Wikis in die Arbeitsprozesse und die Systemlandschaft des Unternehmens generiert werden. In der vorliegenden Veröffentlichung wird daher eine idealtypische Vorgehensweise zur Einführung eines Wikis dargestellt, die diese Problemstellung aufgreift. Es wird gezeigt, wie sich der Grundgedanke der Disziplin des prozessorientierten Wissensmanagements auf die Konzeption eines Wikis übertragen lässt. - 7 - 3. Enterprise 2.0 – Social Software im Unternehmenskontext Nach einer kurzen Einführung zu Enterprise 2.0 werden die zentralen Begrifflichkeiten Web 2.0, Social Software und Social Media erläutert und voneinander abgegrenzt. Im Nachgang wird ein grober Überblick über die unterschiedlichen Social Software Systeme gegeben und das Wiki in diese Systemlandschaft eingeordnet. Da sich diese Arbeit mit der Konzeption eines unternehmensinternen Wikis beschäftigt, erfordert es ein tieferes Verständnis der Wiki-Technologie. Daher werden im Anschluss die charakteristischen Funktionalitäten vorgestellt sowie Nutzenpotenziale, Einsatzmöglichkeiten und Erfolgsfaktoren eines Unternehmenswikis identifiziert. 3.1 Enterprise 2.0 und seine Einsatzebenen Der Forschungswissenschaftler und Harvard-Professor Andrew McAfee hat den Begriff Enterprise 2.0 im Jahr 2006 mit seinem Artikel „Enterprise 2.0: The Dawn of Emergent Collaboration“ ins Leben gerufen. Er definiert den Begriff wie folgt: „Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.“ 10 Demnach wird unter Enterprise 2.0 der Einsatz von Social Software im Unternehmenskontext zur Förderung der Vernetzung und Zusammenarbeit verstanden. 11 Der Definition zufolge beschränken sich Enterprise 2.0-Lösungen nicht ausschließlich auf den unternehmensinternen Gebrauch, sondern können auch Unternehmensexterne wie die Öffentlichkeit, Geschäftspartner (B2B – Business-to-Business) oder Endkunden (B2C – Business-to-Customer) adressieren. Das folgende Schaubild veranschaulicht die unterschiedlichen Einsatzebenen. Abb. 2: Einsatzebenen von Social Software 10 Andrew McAfee, Blog Post, „Enterprise 2.0, version 2.0“, 27.05.2006, http://andrewmcafee.org/2006/05/enterprise_20_version_20/ [Zugriff am 17.07.2014] 11 Vgl. [McAfee 2006], S. 21-28; [McAfee 2009], S. 1-17 - 14 - Abb. 4: Zuordnung von Social Software zu den Einsatzfeldern47 Während Networks insbesondere im Bereich des Identitätsund Beziehungsmanagements Mehrwert stiften, unterstützten Mashups, Social Tagging und Social Bookmarking das Informationsmanagement. Die Kommunikation wird insbesondere durch Anwendungen zur Instant Communication (IC) sowie Feeds unterstützt. Die Abstufung dieser beiden Klassen auf der horizontalen Achse ist in der Kommunikationsart begründet. Während IC-Anwendungen die direkte Kommunikation ermöglichen, erleichtern Feeds und Podcasts die indirekte. Sowohl Webals auch Microblogs streben eine Informationsverbreitung an. Beide Anwendungsklassen sind auf gleicher Höhe positioniert, da Weblogs Züge des Identitätsund Microblogs des Beziehungsmanagements aufweisen können. Weblogs sind im Schaubild weiter links platziert, weil sie als Informationsspeicher auch im Bereich des Informationsmanagements Anwendung finden. Foren werden sowohl zur Kommunikation als auch zur Kollaboration eingesetzt. Auch wenn in der Praxis viele Wiki-Systeme das Anlegen eines eigenen Profils und Benutzerverzeichnisses zulassen, ist die Unterstützung des Identitätsund Beziehungsmanagements nicht die Kernintention eines Wikis,48 ebenso wenig wie die Kommunikationsunterstützung. Zwar findet im Wiki eine asynchrone, indirekte Kommunikation statt, die Verbreitung von Informationen ist im Vergleich zu bspw. einem Blog jedoch nachrangig. Vielmehr 47 Eigene Darstellung. Der Social Software Hut in seiner ursprünglichen Version stammt von Ehms (vgl. Ehms, Persönliche Weblogs in Organisationen – Spielzeug oder Werkzeug für ein zeitgemäßes Wissensmanagement?, 2010, S. 152). Die Zuordnung der Anwendungsklassen und Technologien wurde allerdings im Rahmen dieser Arbeit vorgenommen. 48 Es gibt Anwendungen (z.B. Business Networks), die explizit auf die Unterstützung des Identitätsund Beziehungsmanagement ausgerichtet sind und sich somit besser für die Suche, Abbildung und Pflege von Kontakten eignen. - 15 - dient es der Kollaboration, also der gemeinschaftlichen Erarbeitung von Inhalten, und ermöglicht darüber hinaus das Auffinden und Verwalten von Informationen. Daher wird das Wiki primär als Werkzeug zur Unterstützung der Kollaboration und des Informationsmanagements angesehen. 3.4 Das Wiki – mehr als Technologie Im Folgenden werden die charakteristischen Eigenschaften eines Wikis als Social Software herausgearbeitet und der Einsatz eines Wikis in Unternehmen thematisiert. Der Fokus wird hierbei auf den B2E-Bereich gelegt. Um einen umfassenden Überblick über die Nutzenund Einsatzpotenziale eines Wikis zu erhalten und die kritischen Erfolgsfaktoren zu identifizieren, wurden neben einer Literaturrecherche sieben Fallstudien aus der Praxis analysiert.49 Bei den Fallstudien handelt es sich um lizenzierte und somit qualitätsgesicherte Fallstudien, die die Einführung von Wikis in Unternehmen unterschiedlicher Branchen thematisieren und in einem einheitlichen Raster dokumentieren.50 In vier Fällen wurde das Wiki gemeinsam mit weiteren Social Software Systemen oder als Teil einer ganzheitlichen Social Software Plattform eingeführt.51 3.4.1 Das Wiki und seine Funktionsweise Das erste Wiki wurde von Ward Cunningham, einem US-amerikanischen Programmierer, im Jahr 1995 entwickelt und wurde zum Wissensaustausch und zur Wissensverwaltung im Rahmen der Softwareentwicklungsforschung eingesetzt. Es trug die Bezeichnung WikiWikiWeb52, was so viel wie sehr schnelles Web bedeutet, da die inhaltliche Befüllung des Wikis und der Informationsaustausch schnell erfolgen konnten. Mittlerweile existiert eine Vielzahl an Wikis. Das wohl bekannteste öffentliche Wiki ist die Online-Enzyklopädie Wikipedia.53 Ein Wiki ist kostengünstig54 und zeichnet sich durch eine einfache und schnelle Bedienung aus.55 Darüber hinaus verfügen Wikis über weitere nützliche Funktionalitäten, die im Folgenden erläutert werden56:  Editierbarkeit57 der Inhalte durch mehrere Personen Ein Wiki besteht aus mehreren miteinander verlinkten Seiten, die in der Praxis die Bezeichnung „Pages“58 tragen. Die Benutzer können leicht und ohne Programmierkenntnisse neue Pages erstellen oder vorhandene Seiten bearbeiten bzw. durch 49 Ein Überblick über die untersuchten Fallstudien befindet sich im Anhang A. 50 Vgl. http://www.e20cases.org [Zugriff am 20.06.2014] 51 Siehe Anhang A 52 Wiki wiki ist die Steigerung von wiki und bedeutet „sehr schnell“. 53 Vgl. [Komus/Wauch 2008], S.5-6, 42f. 54 Der technische Implementierungsaufwand sowie die laufenden Kosten sind gering. 55 Vgl. [Orth 2009], S. 75 56 Vgl. [Orth 2009], S. 75f. 57 Synonym für Bearbeitung 58 Vgl. [Koch/Richter 2009], S. 90 - 16 - neue Inhalte ergänzen.59 Hierzu ist lediglich der Aufruf eines Links oder einer Schaltfläche notwendig. Die Pages können problemlos mit Dokumenten und Bildern angereichert werden. Nach dem Speichern sind die Seiten für andere Benutzer direkt verfügbar. Ein aufwendiger Upload entfällt somit.  Verlinkungsmöglichkeit Wie bereits erwähnt können Inhalte durch Hyperlinks miteinander in Verbindung gesetzt werden. Es besteht ebenfalls die Möglichkeit einen Link zu einer noch leeren Page zu erstellen, um andere Benutzer auf einen noch fehlenden Input zu dem Thema hinzuweisen. Auch Verlinkungen auf andere Informationsquellen sind üblich.  Volltextsuche Neben der Verknüpfungsmöglichkeit erleichtert eine Volltextsuche das schnelle Auffinden von Inhalten.  Versionierung und Protokollierung Zu jeder einzelnen Page existiert eine detaillierte Bearbeitungshistorie. Alte Versionen werden archiviert, sind aufrufbar und können bei Bedarf wieder hergestellt werden.  Diskussionsforen In vielen Wikis sind Diskussionsforen integriert. Sie ermöglichen den Nutzern einen Austausch zu den Inhalten, um hierfür nicht direkt den Ursprungstext einer Page verändern zu müssen. Neben diesen zentralen Funktionalitäten und dem in der Regel existierenden Benutzerverzeichnis, lassen sich weitere Mehrwerte durch die Nutzung von Hilfstechnologien generieren. Da in Wikis für gewöhnlich RSS-Dienste integriert sind, können Nutzer Inhalte abonnieren und sich auf diese Weise über Aktualisierungen informieren.60 Bietet das Wiki einen Social Tagging Service an, so lässt sich durch die kollaborative Verschlagwortung die Auffindbarkeit der Inhalte verbessern.61 Somit stellt das Wiki eine neue, innovative Möglichkeit zum Wissensaustausch und der kollaborativen Zusammenarbeit dar. Durch die dynamische, inkrementelle Entwicklung der Inhalte entsteht auf organische Art und Weise eine umfangreiche Wissensbasis.62 Des Weiteren kann mittels eines Wikis die Transparenz über Inhalte erhöht und das Auffinden von Informationen erleichtert werden. 59 Technisch wird dies durch eine einfache Benutzerschnittstelle ermöglicht. In der Regel handelt es sich hierbei um ein Webformular mit einer einfachen Syntax anstatt bspw. eines HTML-Editors (vgl. [Smolnik/Riempp 2006], S. 19). 60 Vgl. [Smolnik/Riempp 2006], S. 19; Vgl. [Orth 2009], S. 76 61 Vgl. [Smolnik/Riempp 2006], S. 19 62 Vgl. [Orth 2009], S. 75f. - 17 - 3.4.2 Nutzenund Einsatzpotenziale Im vorherigen Kapitel wurden die Funktionsweise und die charakteristischen Merkmale eines Wikis beschrieben. Auf dieser Grundlage werden nun Nutzenpotenziale für Unternehmen abgeleitet, die sich durch den Einsatz von Wikis ergeben können. Im Anschluss wird ein Überblick über die Einsatzpotenziale von Wikis im B2E-Bereich gegeben. Smolnik und Riempp unterscheiden drei Nutzenkategorien. Sie sehen im Wiki-Einsatz Potenziale zur  Senkung von Kosten,  Reduzierung des Suchaufwands sowie  zur Steigerung von Qualität.63 Laut der Autoren können Kosteneinsparungen in erster Linie durch eine zeitgerechte Bereitstellung relevanter Informationen und darüber hinaus durch eine potenzielle Einsparung von Lizenzkosten erzielt werden. Qualitätssteigerungen ergeben sich aus dem intensivierten Wissensaustausch.64 Zudem wird die Innovationsfähigkeit gesteigert.65 Dem Prinzip der kollektiven Intelligenz zufolge, erzielt die Masse in der Regel bessere Ergebnisse als ein Einzelner. Das Fehlerentdeckungspotenzial erhöht sich und auch die Ideenfindung wird wie beim Brainstorming gefördert. Allerdings ist die trennscharfe Abgrenzung der soeben vorgestellten drei Nutzenkategorien nicht möglich, da auch Qualitätssteigerungen und verkürzte Recherchezeiten indirekt zu Kostensenkungen führen können. Grundsätzlich lassen sich nur schwer Aussagen zur Rentabilität von Wikis treffen. In den untersuchten Fallstudien wird zur Rentabilität in der Regel keine Angabe gemacht. Vereinzelt wird auf Qualitätssteigerungen, verkürzte Suchzeiten, verbesserte Transparenz, verschlankte Prozesse sowie Synergieeffekte verwiesen, die als wirtschaftlich nützlich deklariert werden.66 An dieser Stelle sei allerdings darauf hingewiesen, dass es sich in zwei von drei Fällen um Social Software Plattformen handelt.67 In welchem Maße das Wiki isoliert gesehen zum realisierten Nutzen beiträgt, lässt sich somit nur schwer erkennen. Festzuhalten ist jedoch, dass im Wiki mehr als ein Informationsspeicher gesehen wird.68 Vielmehr wird es als Arbeitswerkzeug erachtet, welches die Zusammenarbeit unterstützt und gar Systeme und Arbeitsweisen ersetzt.69 Aufgaben, die zuvor mit Word oder PowerPoint erledigt wurden, erfolgen nun über das Wiki. Integriert es sich in den Arbeitsalltag, so lässt sich auch das eMail-Aufkommen reduzieren.70 Darüber hinaus wirkt Social Software auf die 63 Vgl. [Smolnik/Riempp 2006], S. 20 64 Vgl. [Smolnik/Riempp 2006], S. 20; [Komus/Wauch 2008], S. 146-148 65 Vgl. [Smolnik/Riempp 2006], S. 20 66 Vgl. [Koch/Bentele 2011], S. 15f.; [Steinhüser/Gerz 2011], S. 16f.; [Koch/Thönnißen 2011], S.15 67 Vgl. [Koch/Bentele 2011], S. 7.; [Steinhüser/Gerz 2011], S. 8; 68 Vgl. [Steinhüser/Räth 2010], S. 11 69 Vgl. [Steinhüser/Räth 2010], S. 11f.; [Bukvova/Kalb 2010], S. 6f.; [Cervellieri u.a. 2011], S. 10f.; [Koch/Bentele 2011], S. 18 70 Vgl. [Steinhüser/Räth 2010], S. 11f. - 18 - junge und mittlere Mitarbeitergeneration motivierend und trägt so zu einem positiven Unternehmensimage bei.71 Allerdings ist dieser Effekt sicherlich abhängig von der Unternehmenskultur. Auf Basis der Literaturrecherche und der Fallstudienuntersuchung können zusammenfassend folgende Nutzenpotenziale festgehalten werden:  Produktivitätsund Effizienzsteigerungen  Qualitätsverbesserungen  Kostensenkungen  Prozessoptimierung  Positives Unternehmensimage Im Rahmen der Begriffsklärung in Kapitel 3.3 wurden die verschiedenen Einsatzfelder von Social Software bereits erwähnt und durch die Zuordnung der einzelnen Anwendungsklassen gemäß ihrer Charakteristika konkretisiert. Das Wiki wurde hierbei primär als Werkzeug zur Unterstützung der Kollaboration und des Informationsmanagements eingeordnet. In der Literatur werden zahlreiche Anwendungsfelder für Wikis angeführt. Am häufigsten werden sie zur Unterstützung des Wissensmanagements, gefolgt von der informellen Kommunikation und dem Projektmanagement eingeführt.72 Komus und Wauch führen darüber hinaus weitere Managementdisziplinen auf, die durch den Einsatz eines Wikis profitieren könnten: Personalmanagement, Produktund Innovationsmanagement, Geschäftsprozessmanagement, Change Management sowie die Kommunikation.73 Auch im Bereich des ELearnings werden Wikis genutzt. Als Beispiel kann der Einsatz des Wikis im E-Learning-Bereich des Automobilherstellers Opel angeführt werden. Dort wird das Wiki zur Kollektivierung von Ideen und Wissen genutzt, um hieraus Podcasts zur Schulung der Vertriebsmannschaft zu entwickeln.74 Allerdings ist das Anwendungsfeld E-Learning dem Personalmanagement und im Speziellen der Personalentwicklung zuzuordnen. Bei näherer Betrachtung stellt man fest, dass dem Wissensmanagement eine besondere Bedeutung zukommt. Wissensmanagement ist nämlich eine Disziplin, die auch für andere Managementdisziplinen von Bedeutung ist und in diesen ausgeübt wird. In Projekten, im Personalbereich und auch im Kontext der Produktund Innovationsentwicklung nimmt die Ressource Wissen einen hohen Stellenwert ein und ist gezielt zu managen, um das bestmögliche Resultat für das Unternehmen zu generieren. Wikis eignen sich beispielsweise für folgende Anwendungsszenarien75:  Kollektivierung von Ideen oder Verbesserungsvorschlägen (Vorschlagswesen) 71 Vgl. [Koch/Bentele 2011], S. 15 72 Vgl. [Orth 2009], S.161-168 73 [Komus/Wauch 2008], S. 160-253 74 Vgl. [Magnus/Hartz 2009], S. 225ff. 75 Vgl. [Orth 2009 ], S.77 - 19 -  Zusammentragung von häufigen Fragen (FAQ)  Sammlung und Erstellung von gemeinsamen Begriffsdefinitionen (Glossar)  Verschlagwortung und systematische Zusammenstellung von Artikeln u. ä.  Dokumentation von Projekten  Ablage von Checklisten  Wichtige Ankündigungen  Mitarbeiterverzeichnisse (Yellow Pages) 3.4.3 Erfolgsfaktoren und Indikatoren zur Erfolgsmessung Neben den aufgezeigten Nutzenpotenzialen und zahlreichen Einsatzmöglichkeiten hat das Wiki-Prinzip allerdings auch Grenzen und stellt Unternehmen vor gewisse Herausforderungen. Im Rahmen dieser Arbeit wurden daher potenzielle Gefahren und erfolgsverhindernde Barrieren untersucht und bewertet. Auf dieser Grundlage wurden vier übergeordnete Erfolgsfaktoren identifiziert, die im Folgenden vorgestellt werden. Im Anschluss werden Indikatoren zur Erfolgsmessung vorgeschlagen. Erfolgsfaktor 1: Kritische Masse an Nutzern Um die Nutzenpotenziale effektiv ausschöpfen zu können, muss eine kritische Masse an Usern bestehen. Schließlich lebt das Wiki von der kollektiven Intelligenz.76 Wie im vorherigen Kapitel aufgezeigt, kann durch Kollaboration bspw. die Qualität der Ergebnisse verbessert werden. Drehund Angelpunkt ist hierbei die Motivation der Nutzer zur Partizipation, die von einigen erfolgskritischen Faktoren beeinflusst wird:  Motivationsanreize Die Motivationsgründe zur Partizipation können vielfältig sein. In der Psychologie wird zwischen intrinsischen (von innen) und extrinsischen (von außen) Anreizen unterschieden. Da Mitarbeiter das Wiki im Rahmen ihrer entgeltlichen Arbeit nutzen, ist der Antrieb an sich nicht stets intrinsisch.77 Dennoch können bspw. Selbstverwirklichung oder Interesse an technologischen Innovationen Motivationstreiber sein.78 Ist der Mehrwert eines Wikis für den Nutzer erkennbar, so ist die Nutzungsbereitschaft höher. Des Weiteren hilft die Unterstützung und aktive Beteiligung der Führungskräfte, die eine Vorbildfunktion innehaben.79 In der Literatur werden auch extrinsische Motivationsanreize diskutiert. Als Beispiel werden monetäre Anreize aufgeführt, wie bspw. eine an die Social Software Nutzung 76 Vgl. [Koch/Richter 2009], S. 140; [Miller/Pfeiffer 2009], S.14; Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S.62f. 77 Vgl. Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S. 62 78 Vgl. [Komus/Wauch 2008], S. 149; [Steinhüser/Räth 2010], S.9-13; Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S. 62f. 79 Vgl. [Bukvova/Kalb 2011], S.10f. [Koch/Thönnißen 2011],S.16 [Koch/Richter 2009], S. 139; [Steinhüser/Gerz 2011], S.17; [Steinhüser/Räth 2010], S.13; - 20 - gekoppelte Leistungsvergütung.80 Aufgrund des Umfangs des Themas wird an dieser Stelle auf weiterführende Literatur zu inund extrinsischer Motivation verwiesen.81  Größe und Zusammensetzung der Wiki-Community Bei öffentlichen Wikis, die in der Regel die gesamte Öffentlichkeit adressieren, ist das Erreichen einer kritischen Masse aufgrund der Größe der angesprochen Nutzergruppe einfacher. Die partizipierenden Nutzer sind i.d.R. intrinsisch motiviert. Für Unternehmen gestaltet sich dies weitaus schwieriger. Abhängig von der Einsatzebene ist die adressierte Nutzergruppe in der Größe begrenzt und auch die Zusammensetzung bereits vorgegeben.82  Zeitund Ressourcenkapazitäten Hinzu kommt das Problem der begrenzten Zeitund Ressourcenkapazitäten.83 Selbst wenn die Mitarbeiter hoch motiviert sind und die Nutzung eines Wikis begrüßen, kann mangelnde Zeit der Nutzungsbeteiligung im Wege stehen.84 Die Nutzung des Wikis sollte daher durch die Bereitstellung der notwendigen Ressourcen gefördert werden.85 Des Weiteren ist sicherzustellen, dass die Einstiegshürden gering sind und sich kein Mehraufwand durch die Nutzung des Wikis ergibt.86 87  Unternehmenskultur Ein weiterer bedeutender Aspekt ist die Unternehmenskultur. Eine offene und dialogfähige Unternehmenskultur fördert die Nutzungsbereitschaft.88 Fallstudien haben gezeigt, dass die Angst von Mitarbeitern, unfertige Beiträge oder subjektive Einsichten zu veröffentlichen, nicht zu unterschätzen ist.89 Auch in der Literatur wird die „Angst vor öffentlicher Blamage“90 als Herausforderung für Unternehmen gesehen. 80 Vgl. [Koch/Richter 2009], S.141 81Vgl. [Koch/Richter 2009], S. 141ff.; [Komus/Wauch 2008}, S. 90-127; Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010 , S. 62-63 82 Vgl. Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S. 62 83 Vgl. Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S.63 84 Vgl. Warta, Kollaboratives Wissensmanagement in Unternehmen – Indikatoren für Erfolg und Akzeptanz am Beispiel von Wikis, Diss., 2010, S. 63 85 Siehe hierzu [Walter/Altendorf 2010], S. 14 86 Vgl. [Bukvova/Kalb 2010], S. 11, [Steinhüser/Gerz 2011], S. 12 87 Im Rahmen der Wiki-Einführung bei FRITZ&MACZIOL wurden die Profile der Mitarbeiter vor dem Roll-Out mit Daten befüllt, sodass die Mitarbeiter zu Beginn nicht viel Zeit für die Erstellung ihres Profils benötigten (vgl. [Steinhüser/Gerz 2011], S. 18). Auch eine erste Strukturierung und inhaltliche Befüllung des Wikis reduziert Einstiegshürden. 88 Vgl. [Koch/Richter 2009], S. 151ff.; [Komus/Wauch 2008], S.147; [Bukvova/Kalb 2010], S. 10f. 89 Vgl. [Bukvova/Kalb 2010], S. 10; [Steinhüser/Räth 2010], S. 8 90 [Miller/Pfeiffer 2009], S.14 - 21 -  Akzeptanz der Anwendung Insbesondere zu Anfang besteht oftmals Misstrauen gegenüber einer neuen Anwendung und ihrem konkreten Nutzen.91 92 Die Akzeptanz eines Systems ist vom Vertrauen der Mitarbeiter in seine technische Funktionsfähigkeit abhängig. Haben die Mitarbeiter in der Anfangsphase negative Erfahrungen gemacht, so ist das anfängliche Vertrauen zunächst erschüttert und der Wiederaufbau erschwert. In einer der untersuchten Fallstudien führten anfängliche technische Schwächen der Anwendung zur eingeschränkten Nutzungsbereitschaft.93 In diesem Zusammenhang spielen auch datenschutzrechtliche Aspekte sowie zuverlässige Sicherheitsstandards eine essentielle Rolle. Benutzerfreundlichkeit, das heißt Usability und User Experience sind ebenfalls von hoher Bedeutung.94 Eine hohe Usability, im Speziellen eine intuitive Bedienbarkeit, wirkt sich nicht nur positiv auf die Nutzungsbereitschaft aus, sondern reduziert zudem zeitund kostenintensiven Schulungsaufwand.95 Erfolgsfaktor 2: Integration des Wikis Ein weiterer Erfolgsfaktor, welcher ebenfalls Einfluss auf die Akzeptanz und die Motivation der Nutzer nimmt, ist die funktionale und prozessuale sowie systemische Integration des Wikis.96  Funktionale und prozessuale Verankerung Unterstützt das Wiki den Nutzer bei der Erledigung seiner täglichen Aufgaben, so schafft es einen erkennbaren Mehrwert und fördert die Motivation zur Partizipation.97 Durch eine sinnvolle Integration in die Arbeitsprozesse lassen sich Arbeitsabläufe optimieren und Effizienzsteigerungen erzielen.98 Des Weiteren wird die regelmäßige Nutzung des Wikis erhöht. Dies könnte den Prozess der Etablierung der Anwendung als Arbeitswerkzeug beschleunigen. Je nach Anwendungsbereich variiert jedoch der Grad der möglichen Integration in den täglichen Workflow des Nutzers.99 Eine funktionale Verankerung in die Prozesse des Unternehmens ist dennoch erfolgskritisch. 91 Vgl. [Cervellieri u.a. 2011], S. 9; [Miller/ Pfeiffer 2009], S. 15; 92 In den untersuchten Fallstudien wurden oftmals zunächst technikaffine und innovationsfreudige Mitarbeiter als Multiplikatoren gewonnen (vgl. [Cervellieri u.a. 2011], S. 9; [Steinhüser/Räth 2010], S. 8). 93 Vgl. [Steinhüser/Räth 2010], S. 10 94 Vgl. [Koch/Richter 2009], S. 147ff.; [Koch/Bentele 2011], S. 17 95 Vgl. [Komus/Wauch 2008], S. 202 96 Vgl. [Koch/Thönnißen 2011], S. 17 97 Vgl. [Koch/Richter 2009], S. 140; [Ebersbach u.a. 2008], S.33; [Bukvova/Kalb 2010], S. 10; [Koch/Thönnißen], S.17 98 Vgl. [Koch/Richter 2009], S.140 99 Zum Beispiel im Bereich des Innovationsmanagements. In der Regel nutzt ein Mitarbeiter das betriebliche Vorschlagswesen nicht täglich, sondern nur wenn er Ideen hat. - 22 -  Integration in die bestehende Systemlandschaft Das Wiki konkurriert mit bereits etablierten Medien im Unternehmen.100 Sind die im Unternehmen vorhandenen Systeme von ihrer Funktion her nicht ausreichend voneinander abgegrenzt, so führt dies bspw. zur Doppelgleisigkeit in der Dokumentation und somit zu Mehraufwand und Intransparenz. Eine klare Abgrenzung ist daher erforderlich. Der Einsatz von Wikis ist sicherlich nicht überall sinnvoll. Somit ist die bestehende Anwendungsarchitektur zu analysieren und das Wiki so zu integrieren, dass es einen Mehrwert gegenüber den vorhandenen Systemen generiert. Erfolgsfaktor 3: Richtlinien und Standards101 Neben der Sicherstellung einer kritischen Masse an Nutzern und der Integration des Wikis, ist es sinnvoll, Richtlinien und Standards zur gewünschten Wiki-Nutzung vorzugeben.102 Koch und Richter sprechen in diesem Zusammenhang von einer „richtigen Dose an Kontrolle und Selbstorganisation“103, die es gilt herzustellen.104 So kann einem möglichen nutzergetriebenen Vandalismus entgegengewirkt werden. Allerdings wird diese Gefahr aufgrund der Anonymität eher in öffentlichen Wikis gesehen. Im B2E-Bereich wird das Risiko angesichts eines bestehenden Arbeitsverhältnisses, der drohenden Konsequenzen bei grobem Fehlverhalten sowie des hohen Eigeninteresses an qualitativ hochwertigen und validen Inhalten als gering erachtet.105 Dennoch geben Richtlinien und Standards den Nutzern Orientierung und Sicherheit.106 Nicht jeder Mitarbeiter fühlt sich durch die Bereitstellung eines Wikis zur aktiven Beteiligung aufgefordert oder verbindet damit eine explizite Erlaubnis.107 Verzichtbar erscheint im Unternehmenskontext die Einführung eines Freigabeprozesses (peer-review-process), um inhaltliche Streits (sogenannte „Edit Wars“) zu vermeiden. Zum einen erweist sich ein solcher Prozess als aufwändig, und zum anderen wirken Restriktionen demotivierend. Sollte es zu keiner Einigung kommen, so kann der fachliche Konflikt über die nächsthöhere Führungsebene geklärt werden. Dieser Eskalationsprozess wird in Unternehmen ohnehin bereits gelebt, so dass ein Freigabeprozess nicht notwendig ist. Wohl aber sollten für solche Fälle Verhaltensregeln definiert und der Eskalationsprozess kommuniziert werden.108 100 Vgl. [Koch/Richter 2009], S. 159ff. 101 Auch bei Wikipedia gibt es einige, auch wenn wenige, Grundregeln für die Zusammenarbeit. Siehe hierzu http://en.wikipedia.org/wiki/Wikipedia:Five_pillars [Zugriff am 08.08.14] 102 Vgl. [Koch/Richter 2009], S. 139f.; [Walter/Altendorf 2010], S. 19 103 [Koch/Richter 2009], S. 140 104 Zum gleichen Ergebnis kommt auch die Fallstudie bei der ABB AG (vgl. [Steinhüser/Räth 2010], S. 15). 105 Vgl. [Ebersbach u.a. 2008], S.34; [Seibert/Preuss/Rauer 2011], S. 223f.; [Cervellieri u.a. 2011], S. 9 106 Vgl. [Koch/Thönnißen 2011], S. 17 107 Vgl. [Miller/ Pfeiffer 2009], S. 14f. 108 Vgl. [Seibert/Preuss/Rauer 2011], S. 223-226 - 23 - Erfolgsfaktor 4: Systematischer Einführungsprozess Um den soeben vorgestellten Erfolgsfaktoren Rechnung zu tragen, ergeben sich drei Interventionsbereiche, die im Rahmen einer systematischen Einführungsplanung zu gestalten sind (vgl. Abb. 5). Abb. 5: Interventionsebenen im Rahmen einer Wiki-Einführung 109 Zum einen ergibt sich die Interventionsebene „Mensch“. In diesem Kontext handelt es sich um die Nutzer des Wikis, die zur Partizipation zu motivieren und deren Ängste hinsichtlich einer öffentlichen Blamage zu lösen sind. In diesem Zusammenhang ist die Unternehmenskultur zu beachten. Besonderes Augenmerk ist somit auf die Kommunikation des konkreten Nutzens und das Aufzeigen von guten Beispielen zu legen. 110 Zum anderen stellt die Organisation bzw. das Unternehmen einen erfolgskritischen Gestaltungsbereich dar. Das Wiki ist in die Arbeitsprozesse der Mitarbeiter zu integrieren, um die Nutzenpotenziale bestmöglich auszuschöpfen und Akzeptanz zu erzielen. Mithilfe von Regeln und einheitlichen Standards lässt sich die Arbeitsweise steuern. Des Weiteren zeigt die Praxis, dass die frühzeitige Einbindung des Betriebsrates erfolgskritisch ist. 111 Der dritte Interventionsbereich repräsentiert die Technik, das heißt die Social Software mit ihren Funktionalitäten, Usability-Eigenschaften sowie Sicherheitsvorkehrungen. In den untersuchten Fallstudien fehlte teilweise eine systematische Konzeption vor der Einführung. Auf Basis eines im Vorfeld definierten Anforderungskatalogs wurde ein Software-Anbieter gewählt und die Software in der Regel nach technischer Implementierung, einem Vorabtest und teilweise erster inhaltlicher Befüllung ausgerollt. 112 Dies führte zu Anpassungsbedarf, da benötigte Funktionen (Features) fehlten oder die strukturelle Navigation bemängelt 109 Diese Dreiteilung wurde aus dem Bereich Wissensmanagement abgeleitet (vgl. [Bullinger/Wörner/Prieto 1997], S.10; [Wolf/Decker/Abecker 1999], S.745-766) und auf eine Wiki-Einführung transformiert. Die Dreiteilung wird in Kap. 4.1.1 erläutert. 110 Vgl. [Koch/Bentele 2011], S. 17 111 Vgl. [Koch/Bentele 2011], S. 18 112 Vgl. [Steinhüser/Gerz 2011], S. 11ff.; [Steinhüser/Räth 2010], S. 4ff.; [Bukvova/Kalb 2010], S. 7ff.; [Walter/Altendorf 2010], S. 12ff.; [Koch/Bentele 2011], S. 4ff. - 30 - auf ganze Teams, die sich vernetzen und explizites Wissen systematisch vermehren. Es entsteht Organisationswissen. Da die einzelnen Wissensträger wiederum vom Organisationswissen profitieren und daraus lernen, entsteht neues implizites Wissen. Diese Phase beschreiben die Entwickler als Internalisierung. Somit ergibt sich ein Transformationskreislauf, der durch eine Spirale visualisiert wird.147 Erfolgsfaktoren Für ein erfolgreiches Wissensmanagement sind bei der Implementierung folgende Erfolgsfaktoren in den Interventionsebenen Mensch, Organisation und Technik zu berücksichtigen:  Interventionsebene „Mensch“ Ziel ist es, die Mitarbeiter für Wissensmanagement-Aktivitäten, insbesondere zur Wissensteilung, zu motivieren. Eine eventuell vorhandene „Wissen ist Macht“-Einstellung ist zu lösen. Hierzu können extrinsische Anreizsysteme entwickelt werden.148 Allerdings ist es erfolgsversprechender, den Mitarbeitern einen konkreten Nutzen des Wissensmanagements sowie der Wissensmanagementsysteme aufzuzeigen und auf diese Art und Weise eine intrinsische Motivation zu fördern.149 Wichtig ist auch die Unterstützung der Führungskräfte, welche als Vorbilder agieren.150  Interventionsebene „Organisation“ Die Ziele des Wissensmanagements sind mit den Unternehmenszielen zu verknüpfen, Verantwortlichkeiten für das Wissensmanagement zu definieren und Möglichkeiten zum Feedback einzurichten. Ein kritischer Erfolgsfaktor ist die vom Mitarbeiter verfügbare Zeit für Wissensmanagementaktivitäten.151 Um den Zeitaufwand auf ein Minimum zu beschränken, empfiehlt sich die prozessuale Einbettung des Wissensmanagements.152  Interventionsebene „Technik“ Im Rahmen der technologischen Unterstützung des Wissensmanagements sind die Leistungsfähigkeit sowie eine einfache und intuitive Bedienbarkeit der Systeme sicherzustellen. Nutzungsbarrieren sind zu vermeiden und für ihre frühzeitige Problemerkennung Sorge zu tragen.153 147 Vgl. [Nonaka/Takeuchi 1997], S. 68-108; [Nonaka/Toyama/Konno 2000], S. 5-34; [Nonaka/Konno 2005], S. 5358 148 Vgl. [Lack 2004], S. 110; [Linde 2005], S. 44 149 Vgl. [Lack 2004], S. 110f. 150 Vgl. [Lack 2004], S. 110; [Linde 2005], S. 44 151 Vgl. [Lack 2004], S. 110; [Linde 2005], S. 12f., 44 152 Vgl. [Lack 2004], S. 110-113 153 Vgl. [Lack 2004], S. 110f.; [Linde 2005], S. 13, 44 - 31 - 4.2 Das Konzept des prozessorientierten Wissensmanagements Viele Projekte zur Etablierung oder Verbesserung des Wissensmanagements scheitern, da Wissensmanagement als eigenständige Aufgabe betrachtet wird und nicht in die betrieblichen Abläufe integriert wird.154 Wissen und Arbeitsprozesse sind eng miteinander verzahnt. Bei der Ausführung eines Prozesses wird vorhandenes Wissen angewendet und neues Wissen generiert. Somit ist es zielführend, Wissensmanagementaktivitäten an den Arbeitsprozessen auszurichten.155 Genau diesen Ansatz verfolgt das Konzept des prozessorientierten Wissensmanagements, welches im Folgenden näher beleuchtet wird. Neben einer Definition und der Erläuterung grundlegender Begrifflichkeiten werden drei ausgewählte Methoden zur möglichen Umsetzung vorgestellt. 4.2.1 Definition Eine einheitliche Definition zum prozessorientierten Wissensmanagement (pWM) existiert noch nicht. Dennoch haben die verschiedenen Definitionen eine integrative Betrachtung von Wissensmanagementaktivitäten und den operativen wissensintensiven Geschäftsprozessen gemein. Da sich dieser Ansatz auf Geschäftsprozesse fokussiert, wird in der Literatur häufig vom geschäftsprozessorientiertem Wissensmanagement gesprochen.156 Der Diplom-Wirtschaftsinformatiker Remus definiert prozessorientiertes Wissensmanagement (pWM) „als Managementaufgabe, die für die (…) Auswahl, Umsetzung und Evaluation von prozeßorientierten Wissensmanagement-Strategien zuständig ist, mit dem Ziel die Wissensverarbeitung in den operativen wissensintensiven Geschäftsprozessen zu unterstützen, zu verbessern und weiterzuentwickeln, um schließlich zur Kernwertschöpfung des Unternehmens beizutragen.“157 Charakteristisch für diesen Ansatz ist die Verzahnung von Prozessund Wissensmanagement. Damit geht auch die integrative Nutzung von Instrumenten und Methoden aus beiden Disziplinen einher. Ausgangspunkt ist der operative wissensintensive Geschäftsprozess, der Wissensangebot und -nachfrage bestimmt. Der Einsatz von unterstützender Informationsund Kommunikationstechnologie (IKT) orientiert sich somit an den Geschäftsund Wissensprozessen, die miteinander verknüpft werden.158 Zur besseren Verständlichkeit werden im Folgenden zentrale Begriffe erläutert und voneinander abgegrenzt. Ein Prozess ist nach DIN EN ISO 9001 ein „Satz von in Wechselbeziehungen oder Wechselwirkung stehenden Tätigkeiten, die Eingaben in Ergebnisse umwandeln“159. Prozesse zeich154 Vgl. [Lack 2004], S. 112f. 155 Vgl. [Nägele/Schreiner 2002], S. 25f. 156 Vgl. [Abecker u.a. 2002], S. 1, 4f. 157 Remus, Prozeßorientiertes Wissensmanagement, Diss., 2002, S. 82 158 Vgl. Remus, Prozeßorientiertes Wissensmanagement, Diss., 2002, S. 82f. 159 DIN EN ISO 9001:2000, Abschnitt 4 - 32 - nen sich durch einen definierten Beginn und ein definiertes Ende aus. Sie können in Teilprozesse unterteilt werden. Kennzeichnend für einen Prozess ist seine grundsätzliche Wiederholbarkeit.160 Zum Begriff des Geschäftsprozesses finden sich in der Literatur unzählige Definitionen.161 Die meisten Definitionen haben jedoch gemein, dass Geschäftsprozesse funktionsund organisationsübergreifend Aktivitäten in zeitlich-logischer Abfolge zur Erstellung von Produkten bzw. Leistungen bündeln. Somit zeichnen sie sich durch eine direkte oder indirekte Kundenorientierung aus und tragen auf direkte oder indirekte Art zur Wertschöpfung des Unternehmens bei. Wie der Prozessbegriff verlangt, wird der Beginn durch ein Ereignis ausgelöst, z.B. durch einen Geschäftsvorfall, und das Ende durch ein Ergebnis besiegelt, z.B. durch die Befriedigung des Kundenbedürfnisses.162 Das folgende Schaubild zeigt beispielhaft die Zerlegung eines Geschäftsprozesses in einzelne Prozessschritte, die arbeitsteilig in chronologischer Abfolge ausgeführt werden. Diese lassen sich wiederum in weitere elementare Verarbeitungsschritte aufgliedern, die jedoch ohne einen weiteren Bearbeiterwechsel durchgeführt werden.163 Abb. 8: Beispielhafte Zerlegung eines Geschäftsprozesses164 In Anlehnung an Porter werden Geschäftsprozesse in primäre und sekundäre Geschäftsprozesse eingeteilt.165 Die Primärprozesse sind als Kerngeschäftsprozesse auf die Erfüllung der 160 Vgl. [Broschinski. 2010], S. 71f. 161 Vgl. [Gadatsch 2012], S. 35ff. 162 Vgl. [Gadatsch 2012], S.36f.; [Allweyer 2005], S.4; [Becker/Kugeler/Rosemann 2008], S.6; [Osterloh/Frost 2006], S.33; [Schmelzer/Sesselmann 2010], S.63; [Broschinski 2010], S. 72f. 163 Vgl. [Gadatsch 2012], S. 37f. 164 [Gadatsch 2012], S. 38 165 Vgl. [Porter 1986], S.62; [Gadatsch 2012], S. 38f.; [Broschinski 2010], S. 72 - 33 - Kundenbedürfnisse ausgerichtet und zeichnen sich durch einen hohen Wertschöpfungsanteil aus. Die Sekundärprozesse (auch Unterstützungsprozesse genannt) schaffen hierfür die Voraussetzungen. Sie versorgen die Primärprozesse mit den notwendigen Ressourcen.166 In der Literatur wird häufig eine weitere Prozesskategorie definiert. Diese umfasst Steuerungsprozesse, die die Klammer über die Primärund Sekundäraktivitäten bilden und ihr Zusammenspiel steuern. Als Beispiele für Steuerungsprozesse (auch Führungsprozesse genannt) werden Strategieentwicklung und Unternehmensplanung aufgeführt. Somit lassen sich Geschäftsprozesse in Steuerungsprozesse, Kerngeschäftsprozesse und Unterstützungsprozesse unterteilen (vgl. Abb. 9). Abgrenzungskriterium ist die „Nähe zum Kerngeschäft“ des Unternehmens und somit der Wertschöpfungsanteil des Prozesses.167 Abb. 9: Einteilung von Geschäftsprozessen168 Als operative Geschäftsprozesse werden Kerngeschäftsprozesse bezeichnet.169 Auf diesen liegt der Fokus des prozessorientierten Wissensmanagements, da diese die zentralen Basisaktivitäten des Unternehmens darstellen.170 Im Kontext eines Versicherungsunternehmens sind dies Vertragsund Leistungsbearbeitungsprozesse, z.B. die Schadenregulierung.171 Neben diesen definiert der Gesamtverband der Versicherungswirtschaft (GDV) die Produktentwicklung, den Vertrieb sowie die Erstellung von Abrechnungen als essentielle Kernprozesse eines Versicherungsunternehmens.172 166 Vgl. [Porter 1986], S.62 167 Vgl. [Gadatsch 2012], S. 38f.; [Seidlmeier 2002], S. 2f. 168 [Gadatsch 2012], S. 38 169 Vgl. [Aschenbrenner u.a. 2010], S. 77, 81ff. 170 [Abecker u.a. 2002], S. 4; [Nägele/Schreiner 2002], S. 25; [Heisig 2002], S. 47f.; [Hinkelmann/Karagiannis/Telesko 2002], S. 65 171 Vgl. [Gadatsch 2012], S.39 172 GDV, VAA Versicherungs-Anwendungs-Architektur, final edition 1999, www.gdv-online.de/vaa [Zugriff am 04.07.2014] - 34 - Wissensintensiv ist ein Geschäftsprozess, wenn er im Vergleich zu anderen Prozessen verstärkt auf Wissen zurückgreift und sich somit nur bedingt vorausplanen lässt, z.B. Reklamationsprozesse oder Arbeitsabläufe im Bereich Forschung, Entwicklung und Marketing.173 In Abgrenzung hierzu bilden Wissensprozesse Kernaktivitäten des Wissensmanagements wie bspw. die Identifikation, Entwicklung und Verteilung von Wissen ab.174 Die Suche nach Experten im Unternehmen ist bspw. ein Wissensprozess. Das Wissen über einen Prozess (beispielsweise hinsichtlich seines Ablaufs, der prozessualen Zusammenhänge, der Prozessbeteiligten) wird als Prozesswissen bezeichnet. Funktionswissen hingegen ist das zur Ausführung einer Aktivität im Prozess benötigte Wissen, wie bestimmte Fähigkeiten, Fertigkeiten oder Expertise.175 4.2.2 Ausgewählte pWM-Methoden In der Literatur existieren bereits zahlreiche Methoden zum prozessorientierten Wissensmanagement. Einen guten Überblick über den Forschungsund Entwicklungsstand verschafft Heisig in seiner Dissertation „Integration von Wissensmanagement in Geschäftsprozesse“.176 Die Methoden unterscheiden sich hinsichtlich ihrer Zielsetzung, dem Anwendungsumfang, der Vorgehensweise und der eingesetzten Werkzeuge. Im Folgenden werden drei unterschiedliche Methoden vorgestellt, die einen guten Querschnitt darstellen. Es wurden bewusst solche Methoden gewählt, die eine Konzentration auf bestimmte Geschäftsprozesse erlauben und sich nicht ausschließlich auf die Modellierung des gesamten Unternehmens fokussieren. Wie im einleitenden Kapitel zu Enterprise 2.0 erläutert, erfolgt der Roll-Out eines Wikis nicht stets unternehmensweit. Stattdessen kann die Unterstützung bestimmter Prozesse oder Bereiche beabsichtigt werden. Des Weiteren wurde darauf geachtet, dass sich die Methoden nicht ausschließlich der Organisationsund Prozessgestaltung widmen, sondern auch Implikationen für die Etablierung von Wissensmanagementsystemen liefern. Die folgenden Methoden werden anhand ihrer Zielsetzung und Vorgehensweise beschrieben. GPO-WM®-Methode177 Die Methode des „Geschäftsund Prozessorientierten Wissensmanagements“ (GPO-WM®- Methode) wurde vom Diplom-Sozialwissenschaftler Peter Heisig im Rahmen seiner Forschungsarbeiten in der Fraunhofer Gesellschaft, eureki und an der Universität Cambridge 173 Vgl. [Allweyer 1998], S. 38; [Heisig 2002], S. 56; Remus, Prozeßorientiertes Wissensmanagement, Diss., 2002, S. 107 174 Vgl. [Remus 2002], S. 93 175 Vgl. [Abecker u.a. 2002], S. 18; [Nägele/Schreiner 2002], S.26f. 176 Vgl. [Heisig 2005], S. 23-51 177 Die Methode wurde von Peter Heisig als Markenzeichen beim Deutschen Markenund Patentamt eingetragen. - 35 - entwickelt und hat die Verbesserung des Umgangs mit Wissen in Geschäftsprozessen zum Ziel.178 Die Methode basiert auf dem Fraunhofer Referenzmodell zum Wissensmanagement, welches den Umgang mit Wissen auf die Erzeugung, Speicherung, Verteilung und Anwendung von Wissen reduziert.179 Somit werden die sechs Kernaktivitäten des Wissensmanagements nach Probst180 auf vier komprimiert.181 Die Methode umfasste ursprünglich acht Vorgehensschritte. Im Jahre 2009 wurde das Verfahren modifiziert und auf die folgenden fünf Phasen komprimiert182: 1. Auswahl und Eingrenzung des Anwendungsbereichs 2. Bestimmung des erfolgskritischen Wissens im Prozess 3. Analyse des Umgangs mit Wissen im Prozess 4. Erarbeitung eines Verbesserungsvorschlags 5. Umsetzung durch Integration in den Arbeitsablauf Nach der Bestimmung des Gestaltungsbereich183 in der ersten Phase wird in der zweiten Phase das für den Anwendungsbereich relevante Wissen in vier wesentlichen Schritten erhoben184: 1. Beschreibung des Geschäftsprozesses 2. Benennung des Ausgangszustands, des Ergebnisses und der Hauptaktivitäten 3. Zuordnung von Wissens-Ressourcen zu den Hauptaktivitäten 4. Identifizierung der erfolgskritischen Wissensgebiete Im Rahmen der Modellierung der wissensintensiven Geschäftsprozesse findet die Methode der Integrierten Unternehmensmodellierung (IUM)185 mithilfe des Software-Werkzeugs MO²Go186 Anwendung. Charakteristisch für die Methode ist die Differenzierung zwischen „Produkt“, „Auftrag“ und „Ressource“. Wissen kann hierbei entweder der Objektklasse „Produkt“ oder „Ressource“ zugeordnet werden und die Wissensziele dem Objekttyp „Auftrag“.187 Erfasst wird sowohl das explizite als auch implizite Wissen.188 178 Vgl. [Heisig 2002], S. 47-55; [Heisig 2009], S. 2 179 Vgl. [Heisig 2009], S. 13-21 180 Siehe hierzu Kap. 4.1.2 181 Vgl. [Heisig 2002], S. 53ff. 182 Vgl. [Heisig 2009], S. 23f.; [Heisig 2005], S.79-85 183 z.B. ein oder mehrere verbundene Geschäftsprozesse 184 Vgl. [Heisig 2009],S. 5, 9-12 185 Dies ist eine vom Fraunhofer IPK entwickelte Methode zur wissensorientierten Modellierung von Geschäftsprozessen (vgl. [Heisig 2002], S.49, 57). 186 Die Abkürzung steht für „Methode zur Objektorientierten Geschäftsprozessoptimierung“. 187 Vgl. [Heisig 2002], S. 49-52, 56ff. 188 Vgl. [Heisig 2002], S. 57 - 36 - In den ersten zwei Phasen des Vorgehensmodells werden somit Vorarbeiten geleistet, um im dritten Schritt den Umgang mit dem identifizierten erfolgskritischen Wissen zu analysieren. In diesem Zusammenhang werden die konkreten Wissensprozesse beschrieben und die Vorgehensweise sowie eingesetzten Wissensmanagement-Methoden hinsichtlich Validität und Effizienz bewertet. Es ist sinnvoll, Mitarbeiter aus dem Anwendungsbereich in die Analyse-, Gestaltungsund Umsetzungsaktivitäten zu integrieren. 189 Zur Identifizierung von Lösungsvorschlägen im Rahmen der vierten Phase werden unter www.methodenfinder.de zahlreiche Wissensmanagement-Methoden und -Werkzeuge zur Auswahl bereitgestellt. Unter Berücksichtigung der Zielvorstellung und des konkreten Anwendungsfeldes werden Lösungen ausgesucht und flankierende Maßnahmen spezifiziert. 190 Es können zum Beispiel Checklisten erarbeitet werden, die Erfahrungswissen in explizites Wissen überführen. Als weiteres Beispiel können Yellow Pages (Mitarbeiterprofile) genannt werden, die die Transparenz über vorhandenes implizites Wissen erhöhen. 191 Im Rahmen der Umsetzung (Phase 5) wird der wissensorientierte Prozess (Ablauf und Aufgaben) gestaltet bzw. der ursprüngliche modifiziert. Die ausgewählten Methoden und Werkzeuge werden in diesem Zuge implementiert. Dadurch wird ein systematischerer, methodenund technikgestützter Umgang mit Wissen gewährleistet. 192 Das in der GPO-WM®-Methode verankerte Fraunhofer IPK Referenzmodell zum Wissensmanagement definiert sechs Gestaltungsfelder, die zur Sicherstellung einer erfolgreichen Einführung zu berücksichtigen sind (vgl. Abb. 10). Abb. 10: Wissensmanagement-Referenzmodell der Fraunhofer IPK 193 189 Vgl. [Heisig 2009], S. 4, 13-22 190 Vgl. [Heisig 2009], S. 23f.; [Heisig 2005], S. 82ff. 191 Vgl. [Heisig 2002], S. 62f. 192 Vgl. [Heisig 2009], S. 25-27; [Heisig 2002], S. 48f. 193 [Mertins/Finke/Orth 2009], S. 15 - 37 - Die bestehende IT-Infrastruktur sowie die Unternehmenskultur sind sowohl in der Phase der IST-Erhebung als auch in der SOLL-Konzeptionsphase zu betrachten. Im Weiteren sind im Rahmen der Umsetzung Verantwortlichkeiten und Indikatoren zur Erfolgsmessung festzulegen sowie eine wissensorientierte Führungsund Motivationsstrategie zu erarbeiten.194 PROMOTE195 PROMOTE setzt sich aus einer Methode zur Einführung von prozessorientiertem Wissensmanagement und einem Software-Werkzeug zur technischen Unterstützung der Einführungsphasen zusammen.196 Die Methode hat die Identifizierung und Modellierung von Wissensprozessen sowie deren Verknüpfung mit Geschäftsprozessen im Rahmen einer Softwarelösung zum Ziel.197 Ausgangspunkt sind wissensintensive Aktivitäten in Geschäftsprozessen. Der Geschäftsprozess und im Speziellen die wissensintensiven Aktivitäten bestimmen Wissensangebot und - nachfrage und somit die Ausführung der notwendigen Wissensprozesse, wie bspw. das Suchen und Speichern von Wissen.198 Das in der Methode verankerte Vorgehensmodell199 umfasst fünf Phasen, die jedoch nicht zwingend in der vorgegebenen Reihenfolge einzuhalten sind200: 1. Strategieentwicklung – „Aware Enterprise Knowledge“ 2. Analyse – „Discover Knowledge Processes“ 3. Modellierung und Verknüpfung – „Modelling Knowledge Processes and Organisational Memory” 4. Operationalisierung – “Making Knowledge Processes and Organisational Memory operational” 5. Erfolgskontrolle – „Evaluate Enterprise Knowledge“ Im Rahmen der ersten Phase gilt es eine Wissensmanagementstrategie unter Berücksichtigung von Geschäftsstrategie und Kernkompetenzen des Unternehmens zu entwickeln. Es werden Ziele definiert und die zu betrachtenden Geschäftsprozesse ausgewählt.201 194 Vgl. [Heisig 2009], S. 26; [Heisig 2005], S. 66-71 195 „PROMOTE“ steht für „Process-oriented methods and tools for knowledge management“. 196 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 68 197 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 67ff. 198 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 69-72 199 Dieses Vorgehensmodell basiert auf der BPMS-Methodologie für das Management von Geschäftsprozessen, welche sich an den vier Management-Zyklusphasen Planung, Ausführung, Controlling und Verbesserung (vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 73ff.). Im Rahmen des PROMOTE-Ansatzes wird die BPMS-Methodologie um Aspekte des Wissensmanagements erweitert. 200 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 74-87 201 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 75f. - 38 - Die zweite Phase umfasst folgende Vorgehensschritte 202 : 1. Modellierung der Geschäftsprozesse, z.B. mithilfe des Toolkits ADONIS 2. Identifizierung von wissensintensiven Aktivitäten im jeweiligen Geschäftsprozess und Zerlegung in Teilaktivitäten 3. Identifizierung der Wissensarten sowie des zur Durchführung des Prozesses benötigten Wissens 4. Identifizierung der Wissensflüsse innerhalb und zwischen den Prozessen Die Ergebnisse dienen der Ableitung von operativen Aufgaben sowie Zielen des Wissensmanagements im Unternehmen. 203 In der dritten Phase werden Wissensprozesse modelliert und den wissensintensiven Aktivitäten zugeordnet (vgl. Beispiel „Kreditantrag“ in Abb. 11). 204 Die Bearbeitung der wissensintensiven Aktivitäten löst die zugeordneten Wissensprozesse aus. Abb. 11 : Zuordnung von Wissensprozessen zum Geschäftsprozess „Kreditantrag“ 205 202 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 76-80 203 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 80 204 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 80-83 205 Angelehnt an [Hinkelmann/Karagiannis/Telesko 2002], S. 82 - 39 - In der vierten Phase, der Operationalisierung, gilt es die Geschäftsund Wissensprozesse technisch miteinander zu verbinden. Als Beispiel kann die Entwicklung einer Suchmaske genannt werden, die dem Prozesskontext entspricht und den Wissensprozess „Experte finden“ maschinell abbildet.206 Die Erfolgsbewertung von Wissensmanagementaktivitäten im Rahmen der fünften Phase wird auf Basis wirtschaftlich messbarer Kennzahlen vorgenommen. Der Methode zufolge führt erfolgreiches Wissensmanagement zur Verbesserung von Geschäftsprozessen. Erfolgsindikatoren sind bspw. eine erhöhte Produktqualität oder Ressourceneinsparungen. In diesem Zusammenhang müssen jedoch die Wechselwirkungen genau analysiert werden, denn nicht jede Geschäftsprozessoptimierung ist auf erfolgreiches Wissensmanagement zurückzuführen. Im Weiteren werden Schwachstellen erforscht.207 Kommunikationsdiagnose (KODA) Die Methode der Kommunikationsdiagnose wurde vom Fraunhofer Institut für Fabrikbetrieb und -automatisierung im Rahmen zahlreicher Projekte zur Fraktalen Organisation entwickelt. Sie unterstützt bei der Analyse der Geschäftsprozesse aus der Informationsund Kommunikationsperspektive. Ziel ist die Ermittlung der Informationsqualität und -quantität sowie von Kommunikationsschwächen entlang der Prozesse.208 Der Schlüssel zum Erfolg einer Unternehmung wird in einer „schnellen, zielund entscheidungsorientierten Informationsbereitstellung und Kommunikation“209 gesehen. Daher lautet die zentrale Frage: „Sind die richtigen Informationen an der richtigen Stelle, zur richtigen Zeit und mit der richtigen Qualität verfügbar?“210 Aus Komplexitätsgründen reduziert die Methode den Umgang mit Wissen auf Informationsflüsse und Kommunikationsbeziehungen und somit auf die Wissensverteilung211. Dennoch lassen sich interessante Implikationen zur Gestaltung von prozessorientierten Wissensmanagement-Lösungen ableiten. Der Ansatz soll sich insbesondere für die Gestaltung von virtuellen Strukturen und Abläufen eignen und branchenübergreifend anwendbar sein.212 Daher werden die Grundzüge dieser Methode im Folgenden skizziert. Die Methode umfasst zehn Schritte213, die Heisig in vier Phasen zusammenfasst214: 1. Zielformulierung 2. Kommunikationsmodellierung 3. Kommunikationsoptimierung 206 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 84f. 207 Vgl. [Hinkelmann/Karagiannis/Telesko 2002], S. 84f. 208 Vgl. [Dämmig/Hess/Borgmann 2002], S. 123-136 209 [Dämmig/Hess/Borgmann 2002], S. 136 210 [Dämmig/Hess/Borgmann 2001], S. 3 211 Vgl. [Heisig 2005], S. 28; [Kühnle/Sternemann/Harz 1998], S.49 212 Vgl. [Dämmig/Hess/Borgmann 2002], S. 132, 143 213 Vgl. [Dämmig/Hess/Borgmann 2002], S. 140-142 214 [Heisig 2005], S. 27 - 46 - 5.3 Entwurf eines Fachkonzepts als Anwendungsbeispiel Der zuvor erläuterte theoretische Ansatz wird nun anhand eines Anwendungsbeispiels verdeutlicht. Es wird ein Wiki konzipiert, welches das Wissensmanagement im operativen Geschäftsprozess Produktentwicklung eines deutschen Lebensversicherers240 unterstützt. Es handelt sich hierbei um einen wissensintensiven Prozess mit Projektcharakter. Im Folgenden werden zunächst der Anwendungsbereich, die mit der Wiki-Einführung verfolgte Zielsetzung und das Vorgehen erläutert. Anschließend folgen die Präsentation der Analyseergebnisse sowie des Fachkonzeptes. 5.3.1 Anwendungsbereich, Zielsetzung und Vorgehen „Ziel der Produktentwicklung sind marktund kundengerechte sowie für das VU profitable Versicherungsprodukte.“241 Unterschiedliche Stakeholder wie bspw. Kunden, Vertriebswege und Geschäftsleitung müssen zufrieden gestellt werden. Des Weiteren handelt es sich beim Produktentwicklungsprozess (PEP) um einen iterativen Prozess, da die Produktausgestaltung die Berücksichtigung vieler Faktoren erfordert. Deren Zusammenspiel wird im Prozessverlauf stets bewertet.242 Hierzu sind die Einbindung diverser Organisationseinheiten und das Aufgreifen unterschiedlicher Fähigkeiten, Fertigkeiten und Expertise erforderlich. Somit handelt es sich um einen wissensintensiven Geschäftsprozess. Der Produktentwicklungsprozess für das vorliegende Anwendungsbeispiel umfasst sechs Phasen (vgl. Abb. 13). Abb. 13: Produktentwicklungsprozess eines Lebensversicherers243 Ausgelöst wird der Prozess durch eine Produktidee, die von Mitarbeitern unterschiedlicher Organisationseinheiten oder mittels des betrieblichen Vorschlagswesens an die Fachabteilung Leben Planung/Produktentwicklung gemeldet wird (Phase 1). Hierbei kann es sich um Produktinnovationen, -variationen, -modifikationen oder -reaktivierungen handeln. Im Planungsausschuss, einem zentralen Entscheidungsgremium der Versicherung, werden die Vorschläge diskutiert und über das weitere Vorgehen entschieden (Phase 2). Oftmals wird vor der endgültigen Entscheidung eine Vorstudie angefordert, die einer Risikobewer240 Anonymisiertes konkretes Praxisbeispiel 241 [Broschinski 2010], S. 85 242 Vgl. [Broschinski 2010], S. 85 243 Eigene Darstellung für das hier vorgestellte Praxisbeispiel - 47 - tung gleicht (Phase 3). Die Durchführung der Vorstudie wird durch die Abteilung Leben Planung/Produktentwicklung getrieben. Wurde die Idee verworfen oder zurückgestellt, so landet sie im Themenspeicher. Wird zugunsten einer Umsetzung entschieden, so wird die Zustimmung des Produktausschusses244 eingeholt und der Produktentwicklungsprozess durch das Aufsetzen eines Produktenwicklungsteams (PEP-Team) angestoßen (Phase 4). Für die Planung und Steuerung des Prozesses ist der PEP-Teamleiter, der vom Leiter des Produktmanagements ernannt wird, verantwortlich. Somit weist der Prozess Projektcharakter auf. Ab einem gewissen Investitionsvolumen wird die Produktentwicklung als offizielles Projekt initiiert. In diesen Fällen gibt es neben einem fachlichen (analog zum PEP-Teamleiter) auch einen technischen Projektleiter sowie eine Gesamtprojektleitung. Zur Komplexitätsreduzierung wird im Folgenden von einem Projekt gesprochen. Sobald die Produktentwicklung abgeschlossen ist, erfolgt die Produkteinführung (Phase 5). Im Rahmen des Produktcontrollings (Phase 6) wird die Entwicklung des eingeführten Produktes nachverfolgt und der Business Case fortgeschrieben. Zielsetzung Da es sich beim PEP um einen wissensintensiven Prozess handelt, wird eine Bandbreite an Fachund Erfahrungswissen sowie Kompetenzen benötigt. Implizites Wissen ist somit erfolgskritisch. Daher ist primäres Ziel des Wikis, die Zusammenarbeit der Wissensträger im PEP, im Konkreten des PEP-Teams, zu unterstützen und somit den Transformationsprozess zwischen implizitem und explizitem Wissen zu fördern.245 In diesem Zusammenhang sollen mithilfe des Wikis die Wissensprozesse in der Produktentwicklung optimiert werden. Vorgehen Die Analyse wurde für das vorliegende Praxisbeispiel entsprechend der im vorherigen Kapitel vorgestellten Vorgehensweise und Methodik durchgeführt. Zunächst wurde der Prozess beschrieben. Im Anschluss folgte die Identifizierung und Beschreibung der wissensintensiven Aktivitäten. In diesem Zusammenhang wurde die Wissensverarbeitung nach Status quo analysiert und Verbesserungspotenziale abgeleitet. Zur Datenerhebung im Rahmen der Ist-Analyse wurden zum einen existierende Unterlagen wie Prozessbeschreibungen246 und Präsentationen zum Produktentwicklungsprozess verwendet. Zum anderen wurden persönliche Tiefen-Interviews mit Mitarbeitern und Führungskräften unterschiedlicher Bereiche des Lebensversicherers durchgeführt. Bei den Mitarbeitern handelte es sich um Personen, die bereits in einem PEP mitgewirkt haben. Ziel war es, ein besseres Verständnis für die Prozessabläufe, Informationsund Wissensflüsse sowie einen Überblick über die benötigten und eingesetzten Ressourcen zu erlangen. Des 244 Der Produktausschuss ist ein Entscheidungsgremium für Produktentwicklungsprojekte. Es setzt sich aus Führungskräften unterschiedlicher Bereiche zusammen. 245 Siehe SECI-Modell (Kap. 4.1.2) 246 Die verwendeten Prozessbeschreibungen wurden in ADONIS modelliert. - 48 - Weiteren verhalfen die Interviews der besseren Einschätzung von Unternehmenskultur und Innovationsfreudigkeit. Darüber hinaus wurden zwei weitere Mitarbeiter des Versicherers interviewt, die zwar keine Berührungspunkte zum PEP aufweisen, allerdings über Erfahrungen des Konzerns mit Social Software im Allgemeinen und mit der im Konzern etablierten Wiki-Software Confluence im Speziellen berichten konnten.247 Idealerweise werden im Rahmen der Konzeption eines Wikis Anforderungen an die Software abgeleitet und auf dieser Basis Software-Lösungen evaluiert und ausgewählt. In der Unternehmensrealität besteht allerdings oft keine Wahlmöglichkeit, da zuvor bereits eine bestimmte Software als Unternehmensstandard definiert wurde oder aufgrund anderer ITRestriktionen vorgegeben ist. Auch im vorliegenden Anwendungsbeispiel wird eine bestimmte Wiki-Software, nämlich Confluence248 der Firma Atlassian, bereits als Konzernstandard in mehreren Unternehmensbereichen genutzt. Daher wurden die Funktionalitäten dieser Software-Lösung dahingehend untersucht, ob sie den erhobenen Anforderungen gerecht werden. 5.3.2 Analyseergebnisse zu Prozess und wissensintensiven Aktivitäten Zwar lässt sich ein wissensintensiver Prozess nicht im Detail abbilden, dennoch kann er in seinen wesentlichen Zügen modelliert werden. Wie es die Prozessdefinition erfordert, setzt er sich aus Aktivitäten bzw. Teilprozessen zusammen, die sich in der Regel wiederholen. Im Folgenden wird zunächst der modellierte PEP beschrieben. Anschließend werden die identifizierten wissensintensiven Aktivitäten dargestellt. Hierbei werden folgende Aspekte aufgegriffen:  Ausgangssituation (Auftrag)  Teilaktivitäten  Ergebnis (Produkt)  Erfolgskritisches Wissen und verwendete Systeme (Ressourcen)  Informationsund Wissensflüsse In die Beschreibung fließen des Weiteren Erkenntnisse aus der Analyse zur Wissensverarbeitung ein. 247 Im Bereich der betrachteten Lebensversicherung werden bisher keine Wikis eingesetzt. Dennoch existieren in einigen Abteilungen des Konzerns bereits Wikis, wie bspw. der Konzernorganisation oder dem Controlling. Der Nutzungsgrad variiert je nach Abteilung. Im Bereich Controlling wurde das Wiki im Vorfeld konzipiert und nun aktiv genutzt. Im Bereich der Konzernorganisation dient das Wiki lediglich als Glossar und findet kaum Anwendung. Auch im Rahmen einiger Großprojekte finden Wikis Anwendung. Jedoch stellt es in diesem Zusammenhang nicht das zentrale Dokumentationsmedium dar, sodass die Suche erschwert wird. Die Betrachtung der globalen Aktivität über alle Wiki-Bereiche des Konzerns zeigt, dass die Kommentierungsfunktion nur selten genutzt wird. Dies deutet auf eine im Wiki schwach ausgeprägte Kommunikation hin. 248 https://www.atlassian.com/de/software/confluence [Zugriff am 01.08.2014] Wir bedanken uns bei der Firma Atlassian für die Erlaubnis, Screenshots in dieser Veröffentlichung abbilden zu dürfen. - 49 - Prozessbeschreibung Die folgende Prozessbeschreibung konzentriert sich auf die Schritte der Produktentwicklung im engeren Sinne. In dieser Situation sind die drei vorgelagerten PEP-Phasen „Produktidee“, „Ideenauswahl und –analyse“ und die optionale „Vorstudie“ aus Abb. 13 bereits abgeschlossen. Es wurde eine Entscheidung zugunsten der Umsetzung einer konkreten Produktidee getroffen, für die nun die Produktentwicklung im engeren Sinne (Phase 4 aus Abb. 13) beginnt. Der erste Teilprozess dient der Vorbereitung und Planung der Produktentwicklung und umfasst Aktivitäten wie beispielsweise die Zusammensetzung des Teams, die Erstellung des Projektplans, die Planung der Jour Fixe-Termine und die Auswahl eines Dokumentationsmediums. Zu diesem Zweck kontaktiert der PEP-Leiter im ersten Schritt die Führungskräfte der relevanten Organisationsbereiche, u.a. Leben Aktuariat, Leben Vertriebsunterstützung, Leben Betrieb/Leistung sowie Leben Fachkonzeption/Informationsmanagement, und bittet um Benennung der Teammitglieder für das PEP-Team. Bei Bedarf werden weitere Organisationsbereiche einbezogen. Abb. 14: Überblick über die wesentlichen PEP-Schritte249 Gegenstand des zweiten Prozessschrittes ist die Entwicklung des Produktbildes. Die zentrale Rolle übernimmt hierbei das Produktmanagement. In diesem Zusammenhang werden Wettbewerbsvergleiche erstellt und Abstimmungen mit dem Vertrieb geführt. Im Ergebnis entsteht eine Produktskizze, die die wesentlichen Tarifund Leistungsmerkmale enthält. Die gewünschten Leistungsmerkmale werden durch den Projektleiter an das Aktuariat zur Tarifkalkulation übergeben. Die Tarifkalkulation ist im Wesentlichen eine Linienund keine Projekttätigkeit. Zum Status quo wird in den Jours Fixes berichtet. Im Anschluss (bzw. in der Praxis oftmals parallel zur Tarifkalkulation) wird ein Fachkonzept für die technische Realisierung erstellt. Auch hierbei handelt es sich um eine Linientätigkeit. Danach erfolgt die Vorbereitung der Produkteinführung. Diese umfasst folgende parallel zueinander ablaufende Aktivitäten:  Erstellung der Allgemeinen Geschäftsbedingungen (AVB)  Erstellung von Annahmerichtlinien  Initiierung der technischen Umsetzung in den Verwaltungssystemen 249 Eigene Darstellung für das vorgestellte Praxisbeispiel eines deutschen Lebensversicherers; Aufgeführt sind hier die Prozessschritte der Produktentwicklung im engeren Sinne sowie die der Projekteinführung, die erst nach der Entscheidung zur Umsetzung einer Projektidee stattfinden (vgl. Phasen 4 und 5 aus Abb. 13) Vorbereitung der Produktentwicklung Entwicklung des Produktbildes Tarifkalkulation Fachkonzept für techn. Realisierung Vorbereitung der Produkteinführung Produkteinführung - 50 -  Planung der vertrieblichen Einführung  Planung der Verkaufsunterlagen und Druckstücke  Benennung des Neuprodukts Sind alle Prozesse zur Produkteinführung fertig gestellt, so initiiert der Projektleiter die Produkteinführung. Der Vertriebsund Produkteinführungsprozess wird gestartet und endet mit der Einführung des Produktes. Identifizierung und Beschreibung der wissensintensiven Aktivitäten Folgende wissensintensive Aktivitäten, die durch den Projektleiter oder das gesamte PEPTeam ausgeführt werden, wurden identifiziert:  Planung und Steuerung der Produktentwicklung  Entwicklung des Produktbilds  Planung der vertrieblichen Einführung  Planung von Verkaufsunterlagen und Druckstücken  Benennung des Neuprodukts  Vertriebsund Einführungsprozess Sie werden in den folgenden Abschnitten erläutert. Planung und Steuerung der Produktentwicklung Ziel dieser Aktivität ist die Gewährleistung einer erfolgreichen Produktentwicklung und -einführung. Die Verantwortung hierfür trägt der Projektleiter. Er ist somit für die Planung der Jour Fixe-Termine sowie für das Berichtswesen und die Dokumentation zuständig. In der Regel wird ein Laufwerkordner zu Dokumentationszwecken angelegt. Alternativ kann auch eine Kollaborationssoftware als zentrale Dokumentationsform eingesetzt werden. Die Wahl des Dokumentationssystems sowie der Detaillierungsgrad der Dokumentation liegt im Ermessen des PEP-Leiters. Archiviert werden für gewöhnlich Protokolle, Präsentationen, das Produktdesign sowie der Projektund Businessplan. Da es im vorgestellten Praxisbeispiel allerdings kaum Vorgaben bzw. einheitliche Standards gibt, weisen die PEP-Ordner weder eine einheitliche Struktur noch gleichen Inhaltsumfang auf. Daher werden Informationen und Dokumente entweder nur schwer oder überhaupt nicht gefunden, und das Lernen aus vergangen Projekten wird erschwert. Der Projektplan wird gemeinschaftlich erstellt. Der Projektleiter setzt in der Regel einen ersten Entwurf auf und bespricht diesen mit dem Team. Die Anfertigung eines Business Case gehört ebenfalls zu den Aufgaben des Projektleiters. Der Business Case wird oft bereits im - 51 - Rahmen der Vorstudie angefertigt und ist im PEP-Verlauf bei Bedarf anzupassen. Die Absatzschätzungen des Vertriebs sowie die konkreten Aufwandschätzungen der IT und Einführungsplanung sind in diesem Zusammenhang von hoher Relevanz. Da der Projektleiter für die Steuerung zuständig ist, obliegen ihm die Ressourcenplanung sowie das Risikomanagement. Im Konzern gibt es hierzu zwar Vorgaben, vielen Mitarbeitern ist jedoch die Existenz entsprechender Unterlagen nicht bekannt, so dass diese nur selten Verwendung finden. Dementsprechend wird diesen Aspekten nicht immer die gewünschte Aufmerksamkeit gewidmet. Entwicklung des Produktbilds Ziel dieser Aktivität ist die Beschreibung des Produktes mit seinen Tarifund Leistungsmerkmalen. Ergebnis ist eine im PEP-Team abgestimmte detaillierte Produktskizze, die an das Aktuariat zur Tarifkalkulation übergeben wird. Ein einheitliches Format oder Raster existiert nicht. Die Produktskizze wird daraufhin solange überarbeitet, bis die Leistungsbeschreibung und die Tarifkalkulation aufeinander abgestimmt und vom Lenkungsausschuss abgenommen sind. Die Erstellung der Produktskizze erfolgt in erster Linie durch das Produktmanagement. Hierfür ist ein breiter und tiefer Wettbewerbsüberblick notwendig. Somit ist eine Marktanalyse unerlässlich. Diese wird mithilfe einer Datenbank durchgeführt, die Zugriff auf die Allgemeinen Geschäftsbedingungen von Konkurrenzprodukten gewährt. Im Weiteren werden die Konzernvertriebsabteilungen kontaktiert und zur gewünschten preislichen Positionierung des neues Produktes sowie zu Mindestanforderungen befragt. Zudem werden sie um eine erste Absatzschätzung sowie ein Zielgruppenkonzept gebeten. Die Antworten auf diese Fragen werden in unterschiedlichen Formaten, beispielsweise per Mail, abgegeben. Die Ansprechpartner in den Konzernvertriebsabteilungen werden zu Beginn des PEP festgelegt und erhalten Zugriff auf die Projektdokumentation. Bemängelt wird häufig, dass die vertriebsnahen Bereiche und insbesondere der Außendienst ungenügend involviert werden. Das Wissen des Vertriebs sei essentiell, fände bislang allerdings eine nur marginale Berücksichtigung. Planung der vertrieblichen Einführung Zur Einführungsplanung wird das finale Produktbild und die Zeitkette benötigt. Das für die Kommunikationsplanung verantwortliche PEP-Teammitglied koordiniert hierfür einen Arbeitskreis mit Vertretern aus verschiedenen Unternehmensbereichen, u.a. aus den Abteilungen Konzernkommunikation, Marketing, Vertriebsunterstützung und verschiedenen Vertrieben. Gemeinschaftlich wird ein grober Kommunikationsplan inkl. zeitlicher Meilensteine erstellt und im weiteren PEP-Verlauf feinjustiert. Dieser Plan dient der Erstellung eines Maßnahmenkatalogs. Auch an dieser Stelle existieren weder Vorgaben zum Format noch - 52 - zur Ausgestaltung. Die erstellten Dokumente werden mit dem PEP-Team abgestimmt und die Maßnahmen weiterverfolgt. Planung von Verkaufsunterlagen und Druckstücken Die Aktivitäten zur Erstellung von Verkaufsunterlagen und Druckstücken werden im Maßnahmenkatalog erfasst. Das Produktmanagement entwickelt eine „Verkaufsstory“, die die Neuproduktpositionierung im Kontext der bestehenden Produktpalette sowie der Konkurrenzprodukte beschreibt. Die Alleinstellungsmerkmale des Neuprodukts werden herausgestellt und vermarktet. Weiterhin wird entschieden, ob zielgruppenspezifische Verkaufsansätze benötigt werden, beispielsweise auch ob eine Differenzierung zwischen Vertriebspartnern und Endkunden erforderlich erscheint. Die Verkaufsstory dient als Leitfaden zur Erstellung der Verkaufsunterlagen durch die Marketingabteilung sowie zur Planung weiterer Vermarktungsund Kommunikationsmaßnahmen in enger Abstimmung mit der Konzernkommunikation. Darüber hinaus werden Schulungsunterlagen und Folienvorträge vorbereitet und ein Schulungsplan entwickelt. Benennung des Neuprodukts Ein einheitliches Vorgehen zur Namensgebung besteht nicht. In der Regel erarbeitet das Produktmanagement Vorschläge und stimmt diese mit dem Lenkungsausschuss und ggf. mit den Konzernvertriebsabteilungen ab. Es finden keine bestimmten Methoden, Instrumente oder Workshops Anwendung. Vertriebsund Einführungsprozess Die Einführung wird vom PEP-Team begleitet. Die Umsetzung der Kommunikationsund Schulungsmaßnahmen wird kontrolliert und der Informationsbedarf stets analysiert. Werden Informationslücken festgestellt oder gemeldet, so werden zusätzliche Maßnahmen ergriffen, z.B. die Erstellung weiterer Produktpräsentationen. 5.3.3 Aufbau und Funktionalitäten des Wikis Ziel des Wikis ist die Unterstützung der kollaborativen Wissensverarbeitung. Im Folgenden werden Aufbau, Berechtigungskonzept sowie Funktionalitäten samt der möglichen Ausgestaltung der Wissensprozesse dargelegt. Aufbau Das Produktentwicklungs-Wiki sieht derzeit zwei thematische Bereiche vor (vgl. Abb. 15). Im ersten Kapitel werden dem Nutzer die Vorteile des Wikis sowie die Handhabung erläutert. In diesem Zusammenhang erhält er Informationen zu Aufbau, Funktionalitäten, Einsatzmöglichkeiten sowie den Nutzungsrichtlinien und Standards. Zur konsequenten Weiterent- - 53 - wicklung des Wikis wird dort eine Plattform für Feedback und Verbesserungsvorschläge geschaffen. Das zweite Kapitel repräsentiert den Arbeitsbereich und ist somit das Herzstück des Wikis. Abb. 15: Startseite des Wikis250 Wie bereits in den Anfangskapiteln dieser Ausarbeitung erläutert, besteht ein Wiki aus mehreren miteinander verlinkten Seiten. Die Verlinkung ist farblich gekennzeichnet. Durch das Aufrufen des Links „Produktentwicklungsprozess (PEP)“ (vgl. Abb. 15) gelangt der Nutzer zum Arbeitsbereich des Wikis (vgl. Abb. 16). Dieser umfasst zwei Unterkapitel und differenziert hierbei zwischen dem PEP der Lebensversicherung und den PEP sonstiger Konzernunternehmensbereiche. Das erste Kapitel „PEP Leben“ (vgl. Abb. 16) dient als Plattform zur Beschaffung und Ablage von Informationen und Wissen zum Produktentwicklungsprozess der Lebensversicherung. Die Aufbauund Ablauforganisation wird beschrieben und ein Überblick über bereits durchgeführte PEP-Projekte gegeben. Das zweite Kapitel „PEP Andere Sparten“ dient der Sammlung von Informationen zu Abläufen, Verantwortlichkeiten oder Erfahrungen zu den Produktentwicklungsprozessen der anderen Unternehmensbereiche. Zwar existiert eine solche Dokumentation noch nicht, der Austausch zwischen den jeweiligen Prozessverantwortlichen findet allerdings bereits statt. Mithilfe des neuen Prozesswissens werden Ideen und Maßnahmen zur Optimierung des 250 Eigene Darstellung in der Wiki-Software Atlassian Confluence, Version 5.4.4 XY - 54 - PEPs der Lebensversicherung generiert. Insbesondere die Krankenversicherung weist strukturelle und prozessuale Parallelen zur Lebensversicherung auf, da beide Konzerntöchter Personenversicherungen anbieten. Abb. 16: Startseite des Wiki-Arbeitsbereichs251 Primäres Ziel des Wikis ist die Unterstützung der Zusammenarbeit in einer laufenden Produktentwicklung. Hierfür ist zu Beginn eines neuen PEP-Projektes eine eigenständige WikiSeite anzulegen, die zum einen den Projektarbeitsbereich und zum anderen die Dokumentationsplattform darstellt. Dazu wird im Wiki eine Vorlage (Template) angelegt (vgl. Abb. 17). Diese fungiert als Checkliste und dient der einheitlichen Dokumentation der PEP-Projekte. Bei Bedarf kann sie selbstverständlich erweitert oder abgeändert werden. Die Gliederung orientiert sich am Produktentwicklungsprozess. 251 Eigene Darstellung in der Wiki-Software Atlassian Confluence. Version 5.4.4. Der Screenshot dient nur zur Veranschaulichung und zeigt daher nicht die vollständige Auflistung von möglichen Gliederungspunkten. Leben Andere Sparten XY1 - 55 - Abb. 17: Arbeitsvorlage: Anlegen eines PEP-Projektes252 Die ersten drei PEP-Phasen (vgl. Abb. 13) widmen sich der Ideenund Entscheidungsfindung und stellen somit vorgelagerte Teilprozesse dar. Die Ergebnisse dieser Phasen werden im ersten Kapitel unter der Bezeichnung „Allgemeines“ dokumentiert.253 Dort erfolgt eine kurze Vorstellung und fachliche Einbettung des Produkts sowie eine Schilderung des Entscheidungsprozesses und der strategischen Zielsetzung. In diesem Rahmen sollte ein Verweis auf eine ggf. durchgeführte Vorstudie bzw. Voranalyse erfolgen, die in der Regel die Arbeitsgrundlage bildet. Auch sollte die Einbettung des Business Case nicht fehlen. Dieser wird im Laufe des PEPs stets weiterentwickelt. Der PEP wird mit dem Aufsetzen eines PEP-Teams angestoßen. Die Projektleitung wird somit zuständig für das Projektmanagement254 und ist auch für das Wissensmanagement im Projekt verantwortlich. Das zweite Kapitel „Projektplanung und –steuerung“ dient in erster Linie 252 Eigene Darstellung in der Wiki-Software Atlassian Confluence, Version 5.4.4 253 Zur Sammlung und Verwaltung von Ideen existiert bereits ein Planungstool, welches alle Entscheidungen festhält. Eine diesbezügliche Dokumentation im Wiki entfällt somit. 254 Projektmanagement wird nach DIN 69901-5 als die „Gesamtheit von Führungsaufgaben, -organisation, - techniken und –mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten“ (Vgl. DIN 69901-5: 2009, S. 14) definiert. Die Verantwortlichkeit für das Wissensmanagement in Projekten liegt bei der Projektleitung. Lebensversicherung 4. 5. - 62 - Es liegt im Ermessen der Projektleitung, wie die Befüllung dieses Zeitplans zu erfolgen ist. In der Regel erstellt der Projektleiter einen ersten Entwurf und bittet das Team beispielsweise um Stellungnahme per Kommentar und Einpflege weiterer Detaildaten. Denkbar ist aber auch, dass das Team zunächst Vorgaben einträgt wie beispielsweise schon bekannte Release-Termine. Eine weitere zentrale Aufgabe der Projektleitung ist die Überwachung des Status einzelner Themen. Im Umsetzungsplan wird daher eine Status-Ampel hinsichtlich der inhaltlichen Zielerreichung bzw. Termintreue gepflegt. Das Statuslicht kann bequem durch Anklicken des Buttons geändert werden. Die Aktualisierung könnte auch der Aufgabenverantwortliche übernehmen. Mithilfe der RSS-Feeds bleiben auch hierzu alle Beteiligten stets auf dem gleichen und aktuellsten Stand. Sollte ein Projektleiter eine spezielle Anwendung außerhalb des Wikis zur Projektsteuerung nutzen, so sollte er die wichtigen Informationen dennoch im zentralen Dokumentationssystem ablegen. Auch zur Erstellung von Besprechungsnotizen existieren im Wiki bereits erste Vorlagen.262 Besprechungen werden oft bereits über andere Softwarelösungen effizient organisiert. Die Mitteilung der Tagesordnung sowie die Protokollierung lassen sich jedoch im Wiki durchführen. Es ist sogar möglich, Teilnehmer direkt im Dokument zu verlinken, so dass diese eine automatische Benachrichtigung erhalten. Wurden Medien wie bspw. Flipchart eingesetzt und die Ergebnisse abfotografiert, so können die Bilder problemlos im Protokoll angehängt werden. Wichtige Ereignisse oder Termine können im gemeinsam genutzten Wiki-Kalender eingetragen werden. Es ist möglich mehrere Kalender anzulegen, den Personenkreis entsprechend zu definieren und Einträge zu teilen bzw. den Kalender zu abonnieren. Es können verschiedene Darstellungsvarianten genutzt werden (z.B. Listen, Zeitleisten, Monatsund Wochenansichten). Im Rahmen des Risikomanagements sowie zur Festhaltung von neuen Erkenntnissen („Lessons Learned“) bietet sich die Einbindung des gesamten PEP-Teams an. So lässt sich implizites Wissen in explizites umwandeln. Je mehr Beteiligte ihr implizites Wissen einbringen, desto bessere Ergebnisse lassen sich in der Regel erzielen. Aus den Erfahrungen jedes Einzelnen lassen sich darüber hinaus objektivere Erkenntnisse für Folgeprojekte ableiten. Im Bereich der Risikoidentifikation erhöht sich die Wahrscheinlichkeit, alle Risiken und offenen Punkte zu identifizieren und somit potenziellen Fehlern entgegenzuwirken. Das Wiki bietet hierfür eine adäquate Austauschund Diskussionsplattform, die im vorliegenden Fallbeispiel über kein anderweitiges System in der etablierten Anwendungslandschaft bereitgestellt wird. 262 Siehe Anhang B - 63 - Das folgende Schaubild veranschaulicht eine mögliche Darstellung zur Kollektivierung von Lessons Learned. Wichtig ist es, in einem Vorwort die Zielsetzung der Reflexion bzw. Retrospektive zu erläutern. Im Weiteren können thematische Blöcke eingeführt werden, zu denen Feedback abgegeben werden kann, z.B. Prozess, Kommunikation, Arbeitsklima, Sicherung von Wissen. Personen oder im Netzwerk angelegte Gruppen können auf der Seite verlinkt und auf diese Weise zur Teilnahme am Panel aufgefordert werden. Abb. 22: Kollektivierung von Lessons Learned263 Entwicklung des Produktbilds Um ein Produkt zu entwerfen, wird Input von den Vertriebsabteilungen benötigt, der oft in unterschiedlichen Formaten geliefert wird. Zur effizienteren Ausgestaltung dieses Prozesses sollte diese Aktivität zukünftig auch direkt im Wiki ausgeführt werden. Basierend auf diesen Informationen sowie der Wettbewerbsanalyse wird eine Produktskizze angefertigt. In diesem Zusammenhang ist ein als Template gespeichertes, grobes Raster ebenfalls sinnvoll. In der Regel wird diese iterative Aufgabe durch einen Produktmanager wahrgenommen. Dieser ist oftmals auf das Fachwissen von Kollegen angewiesen und bindet sie in den Erstellungsprozess ein. Die finale Produktskizze ist mit dem PEP-Team abzustimmen. Wie bereits im vorherigen Kapitel erwähnt, lässt sich auch dies im Wiki organisieren. 263 Eigene Darstellung in der Wiki-Software Confluence, Version 5.4.4. Angelehnt an die im Wiki gespeicherte Vorlage zur Retrospektive, die etwas abgeändert wurde. - 64 - Planung der vertrieblichen Einführung Gegenstand dieser Aktivität ist die Erstellung eines groben Kommunikationsplans sowie eines Maßnahmenkatalogs.264 In der Phase bis zur Produkteinführung werden diese Dokumente stets weiterentwickelt. Somit handelt es sich hierbei um dynamische und relativ langwierige Vorgänge. Durch den Einsatz des Wikis wird die benötigte Transparenz bzgl. des aktuellen Status sichergestellt. Auch im Rahmen dieser Aktivitäten lassen sich durch die Einbindung des gesamten PEPTeams Qualitätssteigerungen erzielen. Das Team kann bspw. zur Identifizierung von Schulungsbedarf oder zur gemeinschaftlichen Erfassung von Schulungsinhalten einbezogen werden. Neue Ideen können mühelos eingestellt und Impulse für die Weiterentwicklung gegeben werden, z.B. bezüglich neuer Produktfeatures, abweichender Annahmerichtlinien oder Einschränkungen bei der Einführung. Erstellung von Verkaufsunterlagen und Druckstücken Die Erstellung von Verkaufsunterlagen und Druckstücken liegt in der Federführung der Marketingabteilung und stellt eine Linientätigkeit dar. Zwar würde die Erstellung der Unterlagen im Wiki die Kommunikationswege zwischen Marketing und dem Produktmanagement verkürzen, doch eignet sich das Wiki hierzu nur beschränkt. Allenfalls die Verkaufsstory könnte im Wiki entwickelt werden und sich durch die Einbindung des PEP-Teams möglicherweise optimieren lassen. Die Archivierung der erstellten Verkaufsmaterialien ist laut definiertem PEP ohnehin nicht erforderlich und erfolgt in der Regel in einem separaten Druckstückverzeichnis an anderer Stelle. Namensgebung Zur Suche nach einem geeigneten Namen für das neue Produkt kann ein „Ideaboard“ eingerichtet werden, die als Plattform für Namensvorschläge dient. Da es Vorgaben bzw. Richtlinien für die Benennung neuer Produkte gibt, sollten diese einleitend vorgestellt werden. Vertriebsund Produkteinführungsprozess Zur Unterstützung dieser Prozessphase werden zwei Arbeitsumgebungen geschaffen, zum einen für die Sammlung von häufigen Fragen und zum anderen zur Abgabe von Feedback zu Schulungen, Veranstaltungen, dem Produkt usw. Auf diese Weise lassen sich Optimierungsansätze für die laufende Produkteinführung oder für Folgeprojekte generieren. Es besteht hierbei die Möglichkeit, auch externe Gruppen wie bspw. den Außendienst einzubinden. 264 Auch hierfür werden im Wiki Templates angelegt. - 65 - 6. Fazit und Ausblick Ein Wiki zählt zu den Social Software Anwendungen. Aufgrund seiner umfangreichen Funktionalitäten wie der Editierbarkeit der Inhalte, der Volltextsuche und der Verlinkungssowie Verschlagwortungsmöglichkeit stellt das Wiki ein innovatives Werkzeug zur kollaborativen Wissensverarbeitung dar. Ein Wiki ist mehr als eine neue Technologie. Es befähigt die Nutzer, als Autoren zu agieren, und verschafft diesen somit breite Gestaltungsmöglichkeiten. Viele Unternehmen haben bereits das Potenzial dieser webbasierten Anwendung erkannt. Prozesse lassen sich verschlanken und hierdurch eventuell sogar Kostenvorteile erzielen. Neben Produktivitätsund Effizienzsteigerungen können Qualitätsverbesserungen generiert werden, denn das Fehlerentdeckungspotenzial steigt dem Prinzip der kollektiven Intelligenz zufolge mit der Anzahl der Nutzer. Jedoch ist es nicht ausreichend, den Mitarbeitern lediglich eine Wiki-Software zur Verfügung zu stellen. Auch wenn Wikis als selbstorganisierende Systeme charakterisiert werden, ist die Schaffung einer Grundstruktur erforderlich. Ansonsten wird das Wiki trotz der umfangreichen Suchund Informationsverwaltungsfunktionen zunehmend unübersichtlich und generiert nicht den bestmöglichen Nutzen. Nur wenn die User den Mehrwert erkennen, sind sie bereit die Anwendung zu nutzen. Um dem Nutzer einen Mehrwert zu bieten, ist das Wiki in die Arbeitsabläufe zu integrieren. Dies erfordert vorab eine tiefgehende Betrachtung und Analyse der zugrundeliegenden Arbeitsprozesse. Aus diesem Grund wurde der Ansatz des prozessorientierten Wissensmanagements auf eine Wiki-Konzeption übertragen. Auf diese Weise lässt sich ein Wiki gestalten, das sich in die Arbeitsabläufe der Mitarbeiter sowie in die bestehende Architekturlandschaft des Unternehmens einfügt und den Nutzern einen erkennbaren Mehrwert bietet. Die Nutzenpotenziale werden zudem bestmöglich und gezielt ausgeschöpft. Der abgeleitete ideal-typische Einführungsprozess umfasst alle Aktivitäten, die zur Sicherstellung des Wiki-Erfolgs zu ergreifen sind. An der fachlichen Konzeption eines Wikis für die Produktentwicklung wurde gezeigt, wie sich das Wiki als Arbeitswerkzeug zur Unterstützung der gemeinschaftlichen Wissenssammlung, -entwicklung und -verwaltung in einem wissensintensiven Geschäftsprozess mit Projektcharakter, nämlich dem Produktentwicklungsprozess (PEP), integrieren lässt und welche Vorteile sich hierdurch ergeben. Mit dem Entwurf des Fachkonzepts kann der Einführungsprozess allerdings nicht für beendet erklärt werden. Auch die Konzeptionsphase ist noch nicht abgeschlossen. Die Entwicklung eines Kommunikationskonzepts inkl. eines Richtlinienkatalogs zur gewünschten WikiNutzung sowie die Einführungsplanung stehen noch aus. Insbesondere der Kommunikation und Motivation sollte eine hohe Bedeutung zukommen. Die Versicherungsmitarbeiter sind mit der Nutzung von Social Software im institutionellen Gebrauch meist nicht vertraut. Arbeitsprozesse werden derzeit i.d.R. konventionell ausgeführt. Daher ist die Implementierung - 66 - eines Wikis ein Change Management Prozess, der als solcher geplant und eingeführt werden muss, um den Erfolgsfaktor der „kritischen Masse“ nicht zu gefährden. Um adäquate Motivationstreiber zu identifizieren, ist es darüber hinaus empfehlenswert, sich mit soziopsychologischen Theorien auseinanderzusetzen.265 Im Rahmen der prototypischen Konzeption (Prototyping) wurde festgestellt, dass das Wiki für die Generation der Digital Natives266 zwar selbsterklärend ist, die Digital Immigrants267 jedoch auf Probleme stoßen könnten. Derzeit zählt der Großteil der Innendienstmitarbeiter aber zu den Digital Immigrants. Daher empfiehlt es sich neben dem Aufzeigen der Einsatzmöglichkeiten auch schriftliche oder filmische Gebrauchsanleitungen (auch Tutorials genannt) bereitzustellen.268 Des Weiteren wurde deutlich, dass die Einrichtung eines Feedback-Kanals essentiell ist.269 Es sollte insbesondere ein Kommunikationskanal zu den technischen Ansprechpartnern, die die Software betreuen, geschaffen werden. An einigen Stellen konnten bereits im Rahmen des Prototypings Verbesserungspotenziale hinsichtlich Funktionalitäten und Usability identifiziert werden. Da die hier betrachtete Plattform-Software des Confluence-Wikis jedoch stets weiterentwickelt und an Benutzerbedürfnisse angepasst wird, ist eine nutzerorientierte Optimierung wahrscheinlich. In Zukunft könnten zur Unterstützung der Linientätigkeiten in den jeweiligen Abteilungen weitere Wikis eingeführt und miteinander vernetzt werden. Auf diese Weise ließen sich intransparente Datenbanken ablösen, Wartungskosten senken und die Kommunikationswege zwischen den einzelnen Bereichen verkürzen oder effizienter ausgestalten. Denkbar ist auch die Einführung einer konzernweiten Social Software Plattform, die die Integration weiterer Social Software Anwendungen ermöglicht und somit die Ausschöpfung weiterer Potenziale in Aussicht stellt. Allerdings hängt auch ihr Erfolg vom zugrundeliegenden Konzept ab. 265 Weiterführende Literatur: [Koch/Richter 2009], S. 141ff.; [Komus/Wauch 2008], S. 90-127; [Warta 2010], S. 62f. 266 Der Begriff bezeichnet die Generation, die mit digitalen Technologien, wie Computern, Smartphone, Internet usw. aufgewachsen ist. 267 Das Pendant zu Digital Natives. 268 Alternativ zu Screenshots ist es möglich, die Ausführung einer Aktivität aufzeichnen zu lassen und die Aufzeichnung im Wiki abzulegen. 269 Siehe Kap. 3.4.3 - 67 - Literaturund Quellenverzeichnis Fachartikel und Beiträge in Fachzeitschriften und Büchern [Abecker u.a. 2002] Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer-Verlag, 2002 [Allweyer 1998] Allweyer, Thomas: Modellbasiertes Wissensmanagement, in: Information Management & Consulting, 13. Jg. Nr.1, Saarbrücken 1998, S. 37-45 [Allweyer 2005] Allweyer, Thomas: Geschäftsprozessmanagement – Strategie, Entwurf, Implementierung, Controlling, Herdecke, Bochum: W3L Verlag, 2005 [Bach 2000] Bach, Volker: Business Knowledge Management: Wertschöpfung durch Wissensportale, in: Bach, Volker; Österle, Hubert; Volger, Petra (Hrsg.): Business Knowledge Management in der Praxis – Prozessorientierte Lösungen zwischen Knowledge Portal und Kompetenzmanagement, Berlin, 2000, S. 51-119 [Bächle 2008] Bächle, Michael: Ökonomische Perspektiven des Web 2.0, in: Wirtschaftsinformatik, Vol. 50, Nr. 2, 2008, S. 129-132 [Becker/Kugeler/Rosemann 2008] Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. Auflage, Berlin u.a.: Springer, 2008 [Broschinski 2010] Broschinski, Ralph: Kerngeschäftsprozesse eines Versicherungsunternehmens, in: Aschenbrenner, Michael; Dicke, Ralph; Karnarski, Bertel; Schweiggert, Franz (Hrsg.): Informationsverarbeitung in Versicherungsunternehmen, Heidelberg, Dordrecht, London, New York: Springer, 2010, S. 71-95 [Bukvova/Kalb 2010] Bukvova, Helena; Kalb, Hendrik: T-Systems Multimedia Solutions: Vernetztes Arbeiten im TeamWeb, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr. 04, Back, Andrea; Koch, Michael; Smolnik, Stefan; Tochtermann, Klaus (Hrsg.), München, St. Gallen, Graz, Frankfurt: Enterprise 2.0 Fallstudien-Netzwerk, April 2010, ISSN 1869-0297 [Bullinger/Wörner/Prieto 1997] Bullinger, Hans-Jörg.; Wörner, Kai; Prieto, Juan: Wissensmanagement heute: Daten, Fakten, Trends. Ergebnisse einer Unternehmensstudie des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation (IAO) in Zusammenarbeit mit dem Manager Magazin, Stuttgart, IAO, 1997 [Cervellieri u.a. 2011] Cervellieri, Adrian u.a.: SFS services: Wiki zur Wissenskollaboration , Schriftenreihe zu Enterprise 2.0-Fallstudien Nr. 11, Back, Andrea; Koch, Michael; Schubert, Petra; Smolnik, Stefan (Hrsg.), München, St. Gallen, Koblenz, Frankfurt: Enterprise 2.0 Fallstudien-Netzwerk, 04/2011, ISSN 1869-0297, http://www.e20cases.org/wp-content/uploads/fallstudien-e20cases/e20cases-11-SFS.pdf, [Zugriff am 26.06.14] [Dämmig/Hess/Borgmann 2001] Dämmig, Ingo; Hess, Uwe; Borgmann, Claudius: Wissenstransparenz und –werkzeug in das praktische Wissensmanagement von Unternehmen, in: Proceedings zum - 68 - Workshop Prozeßorientiertes Wissensmanagement, 1. Konferenz für Professionelles Wissensmanagement Erfahrungen und Visionen WM2001, 14-16, März, Baden-Baden, 2001 [Dämmig/Hess/Borgmann 2002] Dämmig, Ingo; Hess, Uwe; Borgmann, Claudius: Kommunikationsdiagnose (KODA) – Einstiegsmethode und –werkzeuge in das praktische Wissensmanagement, in: Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer, 2002 [Doran 1981] Doran, George T.: There's a S.M.A.R.T. way to write management's goals and objectives. Management Review, Volume 70, Issue 11(AMA FORUM),1981, S. 35-36. [Ebersbach u.a. 2008] Ebersbach, Anja u.a.: Wiki – Kooperation im Web, 2. Auflage, Berlin, Heidelberg: Springer, 2008 [Gadatsch 2012] Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management – Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 7. Auflage, Springer Vieweg, 2012 [Giles 2005] Giles, Jim: Internet encyclopaedias go head to head, in: Nature 438, 900-901, 15.12.2005 [Heinrich 1999] Heinrich, Lutz J.: Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur, 6. Auflage, München, 1999 [Heisig 2002] Heisig, Peter: GPO-WM®: Methode und Werkzeuge zum geschäftsprozessorientierten Wissensmanagement, in: Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer, 2002 [Heisig 2005] Heisig, Peter: Integration von Wissensmanagement in Geschäftsprozesse, hrsg. von Mertins, Kai, Berlin, 2005, zugl. Diss. Techn. Univ. Berlin [Heisig 2009] Heisig, Peter: GPO-WM®-Analyseleitfaden – Nutzen Sie Ihr Wissen effektiver!, 2009, ISBN 978-3-00-024128-4 [Hinkelmann/Karagiannis/Telesko 2002] Hinkelmann, Knut; Karagiannis, Dimitris; Telesko, Rainer: PROMOTE-Methodologie und Werkzeug für geschäftsprozessorientiertes Wissensmanagement, in: Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer, 2002 [Kaplan/Haenlein 2010] Kaplan, Andreas M.; Haenlein, Michael: Users of the world, unite! The challenges and opportunities of Social Media, in: Business Horizons 53, 2010, S. 59-68 [Kirsch 1992] Kirsch, Werner: Kommunikatives Handeln, Autopoiese, Rationalität – Sondierungen zu einer evolutionären Führungslehre, München: Herrsching, 1992 [Koch/Bentele 2011] Koch, Michael; Bentele, Markus: Rheinmetall: Unified Communication and Collaboration, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr. 07. Back, Andrea; Koch, Michael; Schubert, Petra; Smolnik, Stefan (Hrsg.), München, St. Gallen, Koblenz, Frankfurt: Enterprise 2.0 FallstudienNetzwerk, 02/2011, ISSN 1869-0297, http://www.e20cases.org/wp-content/uploads/fallstudien-e20cases/e20cases-07-rheinmetall.pdf [Zugriff am 26.06.14] - 69 - [Koch/Richter 2007] Koch, Michael; Richter, Alexander: Enterprise 2.0: Planung, Einführung und erfolgreicher Einsatz von Social Software in Unternehmen, München: Oldenbourg, 2007 [Koch/Richter 2009] Koch, Michael; Richter, Alexander: Enterprise 2.0: Planung, Einführung und erfolgreicher Einsatz von Social Software in Unternehmen, 2. Auflage, München: Oldenbourg, 2009 [Koch/Thönnißen 2011] Koch, Michael; Thönnißen, Hans-Jürgen: ESG: Unterstützung von Wissensmanagement durch Social Software, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr. 08, Back, Andrea; Koch, Michael; Schubert, Petra; Smolnik, Stefan (Hrsg.), München, St. Gallen, Koblenz, Frankfurt: Enterprise 2.0 Fallstudien-Netzwerk, 02/2011, ISSN 1869-0297, http://www.e20cases.org/wp-content/uploads/fallstudien-e20cases/e20cases-08-esg.pdf [Zugriff am 26.06.14] [Komus 2006] Komus, Ayelt: Social Software als organisatorisches Phänomen – Einsatzmöglichkeiten in Unternehmen, in: HMD-Praxis der Wirtschaftsinformatik, Heft 252, 2006, S. 36-44 [Komus/Wauch 2008] Komus, Ayelt; Wauch, Franziska: Wikimanagement – Was Unternehmen von Social Software und Web 2.0 lernen können, München: Oldenbourg, 2008 [Kühnle/Sternemann/Harz 1998] Kühnle, Hermann; Sternemann, Karl-Heinz; Harz, Karl: Herausforderung Geschäftsprozesse – Den Wandel organisatorisch und technisch gestalten, Stuttgart: LOGIS Verlag, 1998 [Lack 2004] Lack, Thorsten: Wissensmanagement, in: Kremin-Buch, Beate; Unger, Fritz; Walz, Hartmut (Hrsg.): Wissen – das neue Kapitel, Verlag Wissenschaft & Praxis Dr. Brauner GmbH, 2004 [Linde 2005] Linde, Frank: Barrieren und Erfolgsfaktoren des Wissensmanagements – Ein Ergebnisbericht im Rahmen eines Praxisprojektes von Studenten der Fakultät Informationsund Kommunikationswissenschaften der Fachhochschule Köln unter Leitung von Prof. Dr. Frank Linde, Kölner Arbeitspapiere zur Bibliotheksund Informationswissenschaft, Band 47, März 2005 [Magnus/Hartz 2009] Magnus, Stephan; Hartz, Michael: Fallstudie: Podcasts in der Vertriebsschulung bei Opel, in: Back, Andrea; Gronau, Norbert; Tochtermann, Klaus: Web 2.0 in der Unternehmenspraxis, Fallstudien und Trends zum Einsatz von Social Software, München: Oldenbourg, 2009 [McAfee 2006] McAfee, Andrew P.: Enterprise 2.0: The Dawn of Emergent Collaboration, MIT Sloan Management Review 47 (3), 2006, S. 20-28 [McAfee 2009] McAfee, Andrew P.: Enterprise 2.0: new collaborative tools for your organization’s toughest challenges, Boston, Massachusetts: Harvard Business Press, 2009 [Mertins/Finke/Orth 2009] Mertins, Kai; Finke, Ina; Orth, Ronald: Ein Referenzmodell für Wissensmanagement, in: Wissensmanagement im Mittelstand – Grundlagen – Lösungen – Praxisbeispiele, Berlin, Heidelberg: Springer, 2009 [Miller/Pfeiffer 2009] Miller, Frank S.; Pfeiffer, Thomas: Wie man ein Wiki zum Leben erweckt, in: Wissensmanagement. Das Magazin für Führungskräfte, Heft 1/2009, S. 14-15 - 70 - [Musser/O’Reilly 2007] Musser, John; O’Reilly, Tim: Web 2.0: Principles and Best Practices, Sebastopol: O’Reilly Radar, 2006 [Nägele/Schreiner 2002] Nägele, Reiner; Schreiner, Peter: Potenziale und Grenzen von Business Process Management Tools für geschäftsprozessorientiertes Wissensmanagement, in: Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer, 2002 [Nonaka/Toyama/Konno 2000] Nonaka, Ikujiro; Toyama, Ryoko; Konno, Noboru: SECI, Ba and Leadership: a Unified Model of Dynamic Knowledge Creation, In: Long Range Planning 33, Heft 1/2000, S. 5-34 [Nonaka/Takeuchi 1995] Nonaka, Ikujiro; Takeuchi, Hirotaka: The Knowledge-Creating Company – How Japanese Companies Create the Dynamics of Innovation, New York/Oxford: Oxford University Press, 1995 [Nonaka/Takeuchi 1997] Nonaka, Ikujiro; Takeuchi, Hirotaka: Die Organisation des Wissens – Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen, Frankfurt am Main, New York: Campus, 1997 [Nonaka/Konno 2005] Nonaka, Ikujiro; Konno, Nobora: The Concept of “BA”: Building a Foundation for Knowledge Creation, in: Nonaka, Ikujiro (Hrsg.): Knowledge Management – Critical Perspectives on Business and Management, Band 2, Routledge, 2005 [OECD 2007] Organisation for economic co-operation and development (OECD): Participative Web and User-Created-Content – Web 2.0, Wikis and Social Networking, OECD Publishing, 2007, http://www.oecd-ilibrary.org/science-and-technology/ participative-web-and-user-created-content_9789264037472-en [O’Reilly 2005] O’Reilly, Tim: What is Web 2.0? – Design Patterns and Business Models for the Next Generation of Software, http://oreilly.com/web2/archive/what-is-web-20.html, [Zugriff am 15.06.2014] [Orth 2009] Orth, Ronald: Wissensmanagement mit Wiki-Systemen, in: Wissensmanagement im Mittelstand – Grundlagen – Lösungen – Praxisbeispiele, Berlin, Heidelberg: Springer, 2009 [Osterloh/Frost 2006] Osterloh, Margrit; Frost, Jetta: Prozessmanagement als Kernkompetenz – Wie Sie Business Reengineering strategisch nutzen können, 5. Auflage, Gabler 2006 [Porter 1986] Porter, Michael E.: Wettbewerbsvorteile. Spitzenleistungen erreichen und behaupten, Frankfurt/Main: Campus Verlag, 1986 [Probst/Raub/Romhardt 2006] Probst, Gilbert, Raub, Steffen; Romhardt, Kai: Wissen managen: Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 5. Auflage, Frankfurt am Main: Gabler, 2006 [Probst/Raub/Romhardt 2012] Probst, Gilbert, Raub, Steffen; Romhardt, Kai: Wissen managen: Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 7. Auflage, Springer Gabler, 2012 - 71 - [Remus 2002] Remus, Ulrich: Integrierte Prozessund Kommunikationsmodellierung zur Verbesserung von wissensintensiven Geschäftsprozessen, in: Abecker, Andreas u.a. (Hrsg.): Geschäftsprozessorientiertes Wissensmanagement, Berlin, Heidelberg, New York: Springer, 2002 [Schmelzer/Sesselmann 2010] Schmelzer, Hermann J.; Sesselmann, Wolfgang: Geschäftsprozessmanagement in der Praxis, 7. Auflage, München: Carl Hanser, 2010 [Schmidt 2006] Schmidt, Jan: Social Software: Onlinegestütztes Informations-, Identitätsund Beziehungsmanagement, in: Forschungsjournal Neue Soziale Bewegung, Nr.2/2006, S. 37-46, http:/www.bamberg-gewinnt.de/wordpress/wp-content/pdf/SocialSoftwareFJNSB_preprint.pdf, [Zugriff am 29.06.14] [Seibert/Preuss/Rauer 2011] Seibert, Martin; Preuss, Sebastian; Rauer, Matthias: Enterprise Wikis – Die erfolgreiche Einführung und Nutzung von Wikis in Unternehmen, Gabler, 2011 [Seidlmeier 2002] Seidlmeier, Heinrich: Prozessmodellierung mit ARIS®. Eine beispielorientierte Einführung für Studium und Praxis, Vieweg Braunschweig, 2002 [Smolnik/Riempp 2006] Smolnik, Stefan; Riempp, Gerold: Nutzenpotenziale, Erfolgsfaktoren und Leistungsindikatoren von Social Software für das organisationale Wissensmanagement, in: HMD, Heft 252/ Dezember, 2006, S. 17-26 [Steinhüser/Gerz 2011] Steinhüser, Melanie; Gerz, Matthias: FRITZ & MACZIOL: Vertriebsunterstützung durch Social Software, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr.12, Back, Andrea; Koch, Michael; Schubert, Petra; Smolnik, Stefan (Hrsg.), München, St. Gallen, Koblenz, Frankfurt: Enterprise 2.0 Fallstudien-Netzwerk, 04/2011, ISSN 1869-0297, http://www.e20cases.org/wp-content/uploads/fallstudien-e20cases/e20cases-12-fum.pdf, [Zugriff am 26.06.14] [Steinhüser/Räth 2010] Steinhüser, Melanie; Räth, Philip: ABB AG: Blog und Wiki in der Unternehmenskommunikation, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr.03, Back, Andrea; Koch, Michael; Smolnik, Stefan, Tochtermann, Klaus (Hrsg.), München, St. Gallen, Graz, Frankfurt, Enterprise 2.0 Fallstudien-Netzwerk, Januar 2010, ISSN 1869-0297, http://www.e20cases.org/files/fallstudien/e20cases-03.pdf, [Zugriff am 26.06.14] [Steinmüller 1993] Steinmüller, Wilhelm: Informationstechnologie und Gesellschaft: Einführung in die Angewandte Informatik, Darmstadt Verlag, 1993 [Völler 2012] Völler, Michaele: Die Social Media Matrix – Orientierung für die Versicherungswirtschaft, Schriftenreihe Forschung am IVW Köln 7/2012, Cologne Open Science, ISSN 2192-8479, http://nbn-resolving.de/urn:nbn:de:hbz:832-cos-140, [Zugriff am 28.11.14] [Voigt/Seidel 2009] Voigt, Stefan; Seidel, Holger: Herausforderungen für Unternehmen, in: Wissensmanagement im Mittelstand – Grundlagen – Lösungen – Praxisbeispiele, Berlin, Heidelberg: Springer, 2009 [Walter/Altendorf 2010] Walter, Thomas; Altendorf, Michael: ADTELLIGENCE: Ganzheitlicher Einsatz von Social Software bei einem Startup, Schriftenreihe zu Enterprise 2.0-Fallstudien Nr. 05, Back, Zuletzt erschienen im Rahmen von „Forschung am IVW Köln“ 2015 • Heep-Altiner, Rohlfs: Standardformel und weitere Anwendungen am Beispiel des durchgängigen Datenmodells der „IVW Privat AG‘‘, Nr. 6/2015 • Knobloch: Momente und charakteristische Funktion des Barwerts einer bewerteten inhomogenen Markov-Kette. Anwendung bei risikobehafteten Zahlungsströmen, Nr. 5/2015 • Heep-Altiner, Rohlfs, Beier: Erneuerbare Energien und ALM eines Versicherungsunternehmens, Nr. 4/2015 • Dolgov: Calibration of Heston's stochastic volatility model to an empirical density using a genetic algorithm, Nr. 3/2015 • Heep-Altiner, Berg: Mikroökonomisches Produktionsmodell für Versicherungen, Nr. 2/2015 • Institut für Versicherungswesen: Forschungsbericht für das Jahr 2014, Nr. 1/2015 2014 • Müller-Peters, Völler (beide Hrsg.): Innovation in der Versicherungswirtschaft, Nr. 10/2014 • Knobloch: Zahlungsströme mit zinsunabhängigem Barwert, Nr. 9/2014 • Heep-Altiner, Münchow, Scuzzarello: Ausgleichsrechnungen mit Gauß Markow Modellen am Beispiel eines fiktiven Stornobestandes, Nr. 8/2014 • Grundhöfer, Röttger, Scherer: Wozu noch Papier? Einstellungen von Studierenden zu E-Books, Nr. 7/2014 • Heep-Altiner, Berg (beide Hrsg.): Katastrophenmodellierung - Naturkatastrophen, Man Made Risiken, Epidemien und mehr. Proceedings zum 6. FaRis & DAV Symposium am 13.06.2014 in Köln, Nr. 6/2014 • Goecke (Hrsg.): Modell und Wirklichkeit. Proceedings zum 5. FaRis & DAV Symposium am 6. Dezember 2013 in Köln, Nr. 5/2014 • Heep-Altiner, Hoos, Krahforst: Fair Value Bewertung von zedierten Reserven, Nr. 4/2014 • Heep-Altiner, Hoos: Vereinfachter Nat Cat Modellierungsansatz zur Rückversicherungsoptimierung, Nr. 3/2014 • Zimmermann: Frauen im Versicherungsvertrieb. Was sagen die Privatkunden dazu?, Nr. 2/2014 • Institut für Versicherungswesen: Forschungsbericht für das Jahr 2013, Nr. 1/2014