Exploration & Promotion:
Einführungsstrategien von Corporate Social Software
Alexander Richter
Universität der Bundeswehr München
Werner-Heisenberg-Weg 39
D-85577 Neubiberg
+49 089 6004 4406
a.richter@unibw.de
Alexander Stocker
Institut DIGITAL, JOANNEUM RESEARCH
Steyrergasse 17-19
A-8010 Graz
+43 316 876-2611
alexander.stocker@joanneum.at

ZUSAMMENFASSUNG
Im Kontext des Einsatzes von Social Software zur Unterstützung
der innerbetrieblichen Zusammenarbeit wird regelmäßig über die
„richtige“ Einführungsstrategie diskutiert und es werden die bei-
den Paradigmen Top-Down (vom Management getrieben) und
Bottom-Up (von den Mitarbeitern getrieben) gegenüber gestellt.
Der vorliegende Beitrag zeigt anhand einer vergleichenden Analy-
se von 21 Fallstudien, dass die Diskussion um o.g. Dichotomie
nicht zielführend ist. Die Ergebnisse der Untersuchung lassen
vielmehr erkennen, dass die betrachteten Unternehmen zwei
durchaus miteinander vereinbare Strategien anwandten: Die Art
der Nutzung blieb im Rahmen eines partizipativen Vorgehens
zunächst den Nutzern überlassen und die Anwendungsszenarien
wurden nach und nach identifiziert („Exploration“) oder/und die
Plattformen wurden im Unternehmen mit Unterstützung des Ma-
nagements koordiniert vermarktet und deren gezielte Nutzung
geschult („Promotion“).
Keywords
CSCW, Social Software, Collaboration, Enterprise 2.0, Exploring,
Promoting, Wikis, Weblogs, Microblogging, Social Networking.
1. MOTIVATION
Aufgrund des großen Erfolgs von „Web 2.0“-Plattformen wie
Wikipedia oder Twitter und der darauffolgenden umfangreichen
Berichterstattung aus der Presse, haben viele Organisationen in
den letzten Jahren damit begonnen, vergleichbare Dienste auch
prototypisch „hinter der Firewall“ zu nutzen. Die Einführung
dieser Dienste zur Unterstützung der Zusammenarbeit in Unter-
nehmen, stellt die Beteiligten dabei vor spezifische Herausforde-
rungen, wie z.B. die Einbeziehung von Organisationsstrukturen
und -prozessen. Diese gehen über die Anforderungen an Web-
Plattformen hinaus, welche primär durch informelle Strukturen
gekennzeichnet sind [23] und müssen bei der sozio-technischen
Gestaltung der Dienste berücksichtigt werden. Das erzeugt in
Unternehmen ein Spannungsfeld zwischen der mit dem Web 2.0
implizit verbundenen Selbstorganisation mit der durch Organisa-
tionsstrukturen oktroyierten Fremdorganisation der Mitarbeiter.
Während das Potential der Dienste wie Weblogs, Wikis oder
Social Networking Services (SNS) im Unternehmenskontext zu-
nächst überwiegend prototypisch untersucht und durch die Wis-
senschaft in explorativen Studien eine Vielzahl einzelner Gestal-
tungsparameter aufgezeigt wurde (z.B. [7], [14], [21]), hat es
inzwischen den Anschein, dass diese neuen Dienste zunehmend
den Weg in die Arbeitsprozesse finden und ernster genommen
werden [37]. Vor diesem Hintergrund wird in Wissenschaft und
Praxis vermehrt diskutiert, welche Auswirkungen der Einfüh-
rungsprozess auf den tatsächlichen Erfolg der Dienste für Wis-
sensarbeiter und Organisation hat. Insbesondere wurde zuletzt
mehrfach die Frage aufgebracht, ob es gegen die Natur der Diens-
te wäre diese „Top-Down“ (durch das Management gesteuert und
koordiniert) einzuführen (z.B. [4]). Diese und vergleichbare Fra-
gen sind -aufgrund der Tatsache, dass der Einsatz von Corporate
Social Software in mehrfacher Hinsicht einen Paradigmenwandel
mit sich bringt - mit den Erkenntnissen der Erforschung (traditio-
neller) Groupware nicht vollständig zu erklären [26]. Aus diesem
Grund ist es notwendig über den umfangreichen Erfahrungsschatz
zur Einführung von Groupware in Unternehmen hinaus Ansätze
zu finden, um mehr über diese neuartigen Phänomene zu lernen.
Hier setzt die vorliegende vergleichende Analyse von 21 von den
Autoren dieses Beitrags in den vergangenen vier Jahren erhobe-
nen Fallstudien an. In der Untersuchung wurden unter anderem
das von den Unternehmen bei der Einführung der neuen Dienste
gewählte Vorgehen (Potenzial, Art der Nutzung, Treiber) und
dessen Auswirkungen auf die Zusammenarbeit analysiert. Dabei
stellte sich heraus, dass in den Unternehmen die Frage nach Top-
Down und Bottom-Up schnell in den Hintergrund trat, oder sich
oftmals gar nicht erst stellte. Vielmehr kristallisierten sich zwei
(durchaus miteinander vereinbare) Vorgehensweisen zur Einfüh-
rung als praktikabel bzw. praktiziert heraus: Die kontinuierliche
Ermittlung möglicher Anwendungsszenarien für derart nutzungs-
offene Dienste im Rahmen eines partizipativen Vorgehens (im
Folgenden „Exploration“ genannt) und die mit Unterstützung des
Managements koordiniert vermarktete und gezielt geschulte Nut-
zung mit Fokus auf bestimmte Nutzungspotentiale („Promotion“).
Es folgt ein Überblick über bestehende Arbeiten, die sich mit der
Einführung von Corporate Social Software beschäftigen (Kap. 2).
Dann wird das methodische Vorgehen erläutert (Kap. 3) und als
(Teil-)Ergebnis des Forschungsprojektes werden die gerade be-
zeichneten Vorgehensweisen, Exploration und Promotion, anhand
von besonders aussagekräftigen Beispielen aus den erhobenen
Fallstudien veranschaulicht (Kap. 4). Im darauffolgenden Kapitel
(Kap. 5) werden diese Beispiele diskutiert sowie Implikationen
für Wissenschaft und Praxis aufgezeigt. Zusammenfassung und
Ausblick schließen diesen Beitrag (Kap. 6).

10th International Conference on Wirtschaftsinformatik,
16th - 18th February 2011, Zurich, Switzerland

2. ARBEITEN ZUR EINFÜHRUNG VON
CORPORATE SOCIAL SOFTWARE
Bereits seit mehreren Jahren finden verschiedene IT-Werkzeuge,
welche sich im Web 2.0 durch eine stetig ansteigende Nutzung
privater Art auszeichnen, auch in der Unternehmenspraxis zu-
nehmend Anwendung ([1], [5], [30]). Obwohl das Potential der
Werkzeuge noch nicht vollständig erforscht ist [37], wird diesen
bereits vielfach bescheinigt, Informationsmanagement, Identitäts-
und Netzwerkmanagement sowie Interaktion und Kommunikation
in einem Unternehmen verbessern zu können [26]. Der Einsatz
von Corporate Social Software bringt einen Wandel auf mehreren
Ebenen mit sich. Dieser Wandel ist nicht nur in den Werkzeugen
selbst zu sehen, sondern in den Paradigmen, die hinter dem Web
2.0 stehen und die durch die Werkzeuge ermöglicht bzw. umge-
setzt werden: Beispielsweise werden die Benutzer einer Plattform
als Produzenten von Informationen und Inhalten betrachtet, die
die Inhalte freiwillig und selbstorganisiert erstellen („Participati-
on“), (z.B. [30]). Damit zusammenhängend ist Social Software
durch eine wesentlich stärkere Orientierung an den Bedürfnissen
der Nutzer charakterisiert (oftmals als „me-centricity“ bezeichnet;
siehe z.B. [26]).
Inzwischen gibt es einen umfangreichen Bestand an Forschungs-
arbeiten darüber, wie Social Software im Allgemeinen in einer
Unternehmensumgebung eingesetzt werden kann. In mehreren
Studien wurde der Einsatz der einzelnen Dienste wie z.B.
Weblogs (z.B. [10], [22]), Microblogs (z.B. [31], [42]), Wikis
(z.B. [6], [52]) und Social Networking Services (SNS; z.B. [7],
[39]) innerhalb der Grenzen eines Unternehmensintranets unter-
sucht. In überwiegend explorativen Studien wurde dabei bereits
eine Vielzahl einzelner Aspekte, wie etwa die Frage nach der Art
und Anzahl von Beiträgen [50], dem Verhältnis zwischen lesen-
der und schreibender Nutzung [3], der Qualität der nutzergene-
rierten Beiträge [19], der Motivation der Nutzer [7], dem Nutzen
für Individuum und Organisation [50] oder den bei der Nutzung
empfundenen Hindernissen oder Regeln untersucht [26].
Nicht vollständig geklärt ist jedoch die Frage, welche Einfüh-
rungsstrategien von Unternehmen verfolgt werden, die Social
Software für sich nutzen möchten. Diesbezüglich wurde in bishe-
rigen Arbeiten beispielsweise untersucht, welche Rolle die Unter-
nehmenskultur [3] oder die Existenz verschiedener Nutzergruppen
spielen (können) [10]. Weiterhin aufgebracht wurde die Diskussi-
on, wie viel Freiwilligkeit möglich bzw. wie viel Kontrolle nötig
ist (z.B. [4]). Im Spannungsfeld Freiwilligkeit/Kontrolle wird
auch regelmäßig darüber diskutiert, ob Corporate Social Software
Top-Down oder Bottom-Up eingeführt werden sollte. In dieser
Diskussion wurde bereits argumentiert, dass sich nicht die Frage
stellt, ob die Einführung vom Management angeordnet oder von
den Mitarbeitern gewünscht und vorangetrieben wird, sondern
wie das Management eine Bottom-Up-Einführung zielführend
unterstützen kann [26].
Die in diesem Zusammenhang betonte Notwendigkeit des Com-
mitments von Seiten des Managements (das heißt, dass die Diens-
te durch die Unternehmensführung konsistente, überzeugende und
verlässliche Unterstützung erhalten) wurde bereits für ähnliche
Systemgattungen aus dem Bereich Groupware untersucht und für
notwendig befunden (vgl. z.B. [16], [24]). Dabei sollte das Ma-
nagement aufgrund seiner Vorbildfunktion deutlich machen, dass
es vom Sinn der Plattform überzeugt ist und diese selbst nutzt
(z.B. [8]). Zu vergleichbaren Ergebnissen kommen auch bisherige
Forschungsarbeiten zum IT-gestützten Wissensmanagement. In
dieser Domäne wurden bereits zahlreiche Rahmenwerke zur Ein-
führung der Dienste vorgestellt und Einführungsstrategien disku-
tiert (vgl. z.B. [17]). Gerade beim IT-gestützten Wissensmanage-
ment sind es häufig Top-Down-Einführungsstrategien, welche
sich durch die Manifestation von Management-Rollen wie bei-
spielsweise dem Chief Knowledge Officer (CKO) darstellen.
Klassische Wissensmanagement-Ansätze vernachlässigen dabei
sehr oft die Perspektive der Wissensarbeiter [17] und dementspre-
chend auch die Faktoren, welche Wissensarbeiter zur Teilung von
Wissen motivieren. Gerade diese „Grenze“ will Wissensmanage-
ment durch die Konvergenz mit Web 2.0 und Social Software
überwinden [33].
Ein wesentlicher Unterschied zwischen (traditioneller) Groupware
und Social Software wird darin gesehen, dass Social Software
oftmals „Bottom-Up“ eingeführt wird (z.B. [4]). Sie wird also, als
logische Folge der o.g. „me-centricity“, von den Mitarbeitern
gewünscht und vorangetrieben, oftmals ohne, dass das Manage-
ment bereits vom Dienst überzeugt wurde, aber gleichzeitig auch
ohne umfangreiche Vorschriften und Genehmigungsprozesse
(z.B. [26]). Dies hat den Vorteil, dass sich die Software nicht so
sehr nach bestehenden Prozessen und sozialen Strukturen richten
muss (wie eine umfangreich „von oben“ oktroyierte Plattform),
sondern auch neue Wege gehen kann.
Diesem Bottom-Up-Ansatz werden in der Diskussion um Corpo-
rate Social Software häufig verschiedene Einwände entgegenge-
bracht. Beispielsweise wird argumentiert, dass eine derart einge-
führte Software sich nur schwer an den Zielen des Unternehmens
orientieren könne. Zudem ergeben sich Fragestellungen nach dem
Zusammenspiel verschiedener Einflussfaktoren wie z.B. der Un-
ternehmenskultur, die bei der Einführung betrachtet werden müs-
sen (vgl. z.B. [37]). Zudem werde Bottom-Up häufig als Ausrede
benutzt, um entweder kein Budget in die Einführung von Social
Software zu investieren, oder nach der Umsetzung die Nutzer für
Fehler verantwortlich zu machen, da sie die Einführung nicht
ausreichend unterstützt haben, obwohl ihnen genügend Freiraum
dafür gegeben wurde [28]. Deswegen, so wird gerne interpretiert,
müsse die Einführung einer langfristig orientierten Kollaborati-
onsplattform, wie auch bei anderen Diensten, Top-Down erfolgen.
Aus dieser öffentlichen und interdisziplinären Diskussion heraus,
wurden in der vorliegenden Studie das in Unternehmen gewählte
Vorgehen und dessen Auswirkungen systematisch untersucht. Ziel
war es festzustellen, welchen Einfluss die o.g. Paradigmen des
Web 2.0 einerseits und bestehende Strukturen in den Unterneh-
men andererseits auf die Einführungs-Vorgehensweisen hatten.
Bevor die Forschungsergebnisse der vergleichenden Fallstudien-
analyse präsentiert und daraus Erkenntnisse für Theorie und Pra-
xis abgeleitet werden, folgt im nächsten Abschnitt eine Erläute-
rung des methodischen Vorgehens.
3. METHODIK
3.1 Vergleichende Fallstudienanalyse
Wie bereits zuvor ausgeführt, wurde der Einsatz von Corporate
Social Software in der Vergangenheit bereits anhand einer Anzahl
verschiedener, explorativer Fallstudien untersucht. Der Einsatz
der Fallstudienforschung als Hilfsmittel zur Erklärung des Phä-
nomens Corporate Social Software ist darin begründet, dass sich

aufgrund der Vielzahl und Komplexität verschiedener Geschäfts-
prozesse und Arbeitspraktiken Informationsinfrastrukturen zu-
nehmend schwieriger modellieren lassen [32]. Aus diesem Grund
ist eine Sammlung von Regeln (z.B. in Form von praxistauglichen
Leitfäden) allein nicht ausreichend. Vielmehr sollte ein Anwen-
dungssystem-Verantwortlicher sich Anregungen von Anwen-
dungserfahrungen anderer Unternehmen einholen können. Fall-
studien stellen in diesem Zusammenhang eine gute Möglichkeit
dar, Gestaltungs- und Aneignungsformen von Informationstech-
nologien in ihrem Kontext zu beschreiben [53].
Für die vorliegende Analyse wurde von den Autoren auf insge-
samt 21 Fallstudien von Unternehmen in Deutschland, Österreich
und der Schweiz zurückgegriffen. Die zugrundeliegenden Daten
wurden im Rahmen zweier Promotionsprojekte und fünf weiterer
Forschungsprojekte zwischen April 2007 und Juli 2010 selbst
erhoben, es handelt sich also um eine Studie auf Basis von Pri-
märdaten. Schon während der Promotionsprojekte haben sich die
beiden Autoren über die eigenen Vorarbeiten hinaus intensiv
ausgetauscht, um später eine gemeinsame Vergleichsbasis zu
schaffen.
Pro Fallstudie standen jeweils sehr unterschiedliche Datenquellen
zur Verfügung, die in die Analyse eingingen:
 Für jede Fallstudie, d.h. in jedem Unternehmen wurde
mindestens ein mehrstündiges Interview mit Mitarbei-
tern geführt, die für Einführungsprozess und/oder Nut-
zerbegleitung verantwortlich waren. In zehn Fällen wa-
ren es zwei oder mehr Interviews.
 Zusätzlich wurden über alle Unternehmen verteilt zu-
sätzlich über 30 weitere Interviews und mehrere Work-
shops mit Nutzern geführt. In sechs Fällen wurden
quantitative Online-Befragungen mit Mitarbeitern als
Nutzer der neuen Dienste geführt. Insgesamt wurden so
rund 200 Nutzer befragt.
 Bis auf fünf Ausnahmen konnten die Autoren sich zu-
dem vor Ort einen Überblick über die neuen Dienste
und deren Nutzung verschaffen. In vier Fällen standen
auch Nutzungsdaten zur Verfügung, die qualitativ aus-
gewertet (codiert) wurden.
 Darüber hinaus wurden meistens interne und in jedem
Fall zur Verfügung stehende externe Dokumente aus-
gewertet. In zwei Fällen wurde zudem auf zusätzliche
Informationen, die entlang eines vergleichbaren umfas-
senden Rasters durch das Enterprise-2.0-
Fallstudiennetzwerk (e20cases.org) dokumentiert wur-
den, zurückgegriffen.
Zusammenfassend lässt sich sagen, dass die Triangulation mehre-
rer Datenquellen und mehrerer Verfahren zur Datenerhebung
dabei wesentlich zur Sicherstellung einer größtmöglichen Objek-
tivität und Konstruktvalidität (vgl. z.B. [9], [51], [54]) der aus den
Fallstudien gewonnenen Erkenntnisse beiträgt.
Eine wesentliche Herausforderung bei der vergleichenden Analy-
se mehrerer Fallstudien stellen die oftmals unterschiedlichen,
durch die jeweiligen Autoren gewählten Zielsetzungen der ver-
schiedenen Untersuchungen dar [54]. Im vorliegenden Fall war es
von Anfang an das Ziel der Autoren, alle Fallstudien im Rahmen
der Datenerhebung möglichst strukturiert zu beschreiben und es
so zu ermöglichen, Fallstudien in einzelnen Punkten strukturiert
miteinander vergleichen zu können. Dabei wurde auf gängige
Strukturierungshilfen für Fallstudien zurückgegriffen ([45], [46],
[47]). Die strukturierte Dokumentation der Fallstudien orientierte
sich dabei an den folgenden Punkten: (1) Unternehmen, (2) Prob-
lemstellung, (3) „alte“ Vorgehensweise, (4) Einführung der neuen
Lösung, (5) Änderungen, (6) Zielerreichung und „Lessons
Learned“.
Für jeden analysierten Fall wurde ein detaillierter Fallstudienre-
port auf Basis des Rasters erstellt. Auf diese Weise ließen sich
eine Vielzahl von Parametern (z.B. Ausgangssituation, Betrieb,
Nutzung, etc.) detailliert vergleichen. Vor allem die zahlreichen
Bemerkungen, Aussagen und Feststellungen von Verantwortli-
chen und Nutzern im Zuge der Befragungen zum Einführungspro-
zess und zu den Zielen waren für die in diesem Beitrag vorgestell-
te Studie äußerst wertvoll und trugen zur internen Validität (vgl.
[54]) bei.
So waren in den Interviews beispielsweise folgende Fragen an
Entscheider und Nutzer herangetragen worden:
 Was war der Leidensdruck für die Einführung eines
neuen Dienstes? Wer hat diesen Leidensdruck erstmalig
festgestellt? (Ausgangssituation)
 Was war das Ziel des einzuführenden Dienstes? Wel-
ches Potenzial wurde wahrgenommen? (Potenzial)
 Welche Prozesse bzw. Aktivitäten sollte dieser neue
Dienst unterstützen? (Nutzung)
 Nach welchen Kriterien wurde der neue Dienst ausge-
wählt? Wie wurden Nutzeranforderungen erhoben?
(Auswahl)
 Wer sollten die Nutzer des neuen Dienstes sein: Projekt-
teams, Abteilungen oder das gesamte Unternehmen?
(Umfang)
 Wer hat den neuen Dienst ausgewählt und festgelegt, in
welchem Kontext dieser verwendet wird? (Treiber)
 Welche Aktivitäten wurden hinsichtlich Projektmarke-
ting, Bekanntmachung und Akzeptanzsteigerung ge-
wählt und was war der Inhalt? (Akzeptanz)
 Wurde eine einführende Schulung bezüglich Ziele und
Nutzung des neuen Dienstes durchgeführt? (Training)
Auch die zur Verfügung stehenden Dokumente wurden jeweils
nach diesen Inhalten und Fragestellungen (Ausgangssituation,
Potenzial, Nutzung, Auswahl, Umfang, Treiber, Akzeptanz, Trai-
ning, …) durchsucht, sodass sich ein zufriedenstellendes Gesamt-
bild über die tatsächliche Art der Einführung ergab.
Aufbauend auf den zur Verfügung stehenden und die Forschungs-
frage adressierenden Daten wurden alle Fälle von den Autoren
unabhängig voneinander analysiert und auf gemeinsame Muster
untersucht. Dabei wurden die konkreten Situationen der realen
Welt in den Fallstudien als Basis zur induktiven Theoriebildung
benutzt, wobei jeder Fall eine eigenständige analytische Einheit
bildete [12]. Bei der Theoriebildung folgten wir der in der Groun-
ded Theory definierten Methode des konstanten Vergleichs [13].
Gemäß dieser Methode wurden alle Fälle systematisch miteinan-
der verglichen, um ähnliche Rahmenbedingungen und Vorge-
hensweisen zu identifizieren. Die Grundidee besteht darin, durch
die Feststellung von Gemeinsamkeiten und Unterschieden zwi-
schen verschiedenen Phänomenen im Datenmaterial ein konzep-
tuelles Unterscheidungsvermögen zu gewinnen. Hinter der Analy-

se von Gleich- und Andersartigkeit der untersuchten Vorkomm-
nisse soll ein Sinn entdeckt und abstrahierend mit Bezug auf die
Forschungsfrage in ein Konzept gegossen werden. Als Ergebnis
dieser durchgeführten Analyse stellten sich schließlich zwei unter-
schiedliche Vorgehensweisen für die Einführung von Corporate
Social Software, sowie deren Kombination heraus, auf die in Ab-
schnitt 4 näher eingegangen wird, Exploration und Promotion.
3.2 Qualität der Stichprobe
Die als Fallstudienteilnehmer gewählten Unternehmen zeichnen
sich durch eine Reihe von Gemeinsamkeiten aus. In allen Unter-
nehmen existieren namentlich bekannte Verantwortliche für die
Durchführung der Einführungsprojekte. Alle Unternehmen sind
im deutschsprachigen Raum angesiedelt und weisen somit kultu-
relle Ähnlichkeiten auf. In allen Fällen konnten auch trotz der
Novität und Komplexität von Social Software bereits hinreichend
Erfahrungen mit den eingesetzten Werkzeugen Wiki, Weblog,
Microblog und Social Networking Services gesammelt werden.
Die 21 erhobenen Fallstudien werden im Anhang in einer Tabelle
skizziert, wobei jeweils die Aspekte „konkrete Umsetzung der
Technologie“, „Ursprung/Konzept“ und „Art der Einführung“
herausgestellt werden. Auf eine umfangreichere Darstellung aller
21 Fälle muss aufgrund des beschränkten Platzes in diesem Bei-
trag leider verzichtet werden.
Der größte Teil der Fallstudien (18) wurde bereits durch mindes-
tens einen Autor des vorliegenden Beitrags auf wissenschaftlichen
Konferenzen vorgestellt oder in Fachzeitschriften bzw. Fachbü-
chern publiziert (vgl. Tabelle 1). Aufgrund dieses bereits stattge-
fundenen Peer-Review-Prozesses, wurde, die wissenschaftliche
Qualität der in diesem Beitrag analysierten Fallstudien von exter-
nen Experten bereits positiv bewertet, was sich positiv auf die
externe Validität (vgl. [54]) der mit Hilfe des verwendeten Da-
tenmaterials gewonnenen Erkenntnisse auswirkt. So wird trotz
unterschiedlicher Zielsetzungen der einzelnen Publikationen auf-
grund der umfangreichen Dokumentation auch die Nachvollzieh-
barkeit der Fälle für den Leser sichergestellt (vgl. [47]).
Tabelle 1: Referenzen zu den Fallstudien (18)
Untersuchte(s) Unternehmen Referenz
Accenture, IBM, SAP [39]
Bosch [52]
Communardo [42]
Deutscher Skiverband [40]
Infineon Technologies, IVM, Raiffeisen [49]
Fraport, Maschinenfabrik Andritz, Micro-
soft, Pentos Spirit Link, Synaxon, TAO
[50]
Siemens Building Technologies [31]
Siemens [38]
4. ERGEBNISSE
Auf Basis der bereits eingeführten Diskussion zum Spannungsfeld
zwischen Bottom-Up und Top-Down wurde in der vorliegenden
Studie der Frage nachgegangen, auf welche Weise die Dienste in
den betrachteten Unternehmen eingeführt wurden und welche
Implikationen sich daraus ergeben. Dabei wurden in den betrach-
teten Fallstudien zwei durchaus vereinbare Vorgehensweisen
identifiziert: Exploration und Promotion.
In diesem Abschnitt werden die beiden Vorgehensweisen zu-
nächst kurz allgemein erläutert und dann anhand mehrerer beson-
ders aussagekräftiger Beispiele veranschaulicht. Dabei werden
sowohl Fälle, in denen nur Exploration oder Promotion verfolgt
wurden, als auch Fälle, in denen beide Ansätze zum Tragen ka-
men, vorgestellt.
Für die Gesamtheit aller 21 Fälle ergibt sich folgendes Bild: Wäh-
rend in fünf Fällen „Exploration“ als dominierende Einfüh-
rungsstrategie durch die Autoren identifiziert werden konnte,
findet sich ebenfalls in fünf Fällen „Promotion“ vor. In elf Fäl-
len wurden beide Einführungsstrategien kombiniert angewandt.
Nachfolgend wird die Einführung von Corporate Social Software
exemplarisch anhand von jeweils drei fokussierten Fallbeispielen
pro Einführungsstrategie, also insgesamt neun Fällen (Explorati-
on, Promotion, Kombination beider Strategien) kurz erläutert. Die
nachfolgenden Fallbeispiele sollten eine gewählte Einführungs-
strategie möglichst klar und deutlich widerspiegeln und wurden
daher genau aus diesem Grunde durch die Autoren zur Präsentati-
on herangezogen. Für die Definition der beiden Vorgehensweisen
Exploration und Promotion werden die Aspekte Potenzial des
Dienstes, Art der Nutzung des Dienstes und Treiber des Diens-
tes analysiert
4.1 Exploration
In rund einem Viertel der untersuchten Fallstudien wurde Explo-
ration als dominierende Einführungsstrategie verwendet.
Unter Exploration wird in diesem Beitrag die kontinuierliche
Ermittlung möglicher Anwendungsszenarien für neue nutzungsof-
fene Dienste mittels eines partizipativen Vorgehens verstanden.
Die Vorgehensweise der Exploration war in den Fallstudien auf
unterschiedliche Art und Weise ausgeprägt. Im Laufe der Unter-
suchung kristallisierten sich folgende Merkmale als charakteris-
tisch für dieses Vorgehen heraus:
 Das Potential des neuen Dienstes war nicht (oder zu-
mindest nicht vollständig) klar und sollte während der
Nutzung erstmals oder noch weitergehend erschlossen
werden.
 Die Art der Nutzung des neuen Dienstes wurde nicht,
oder nur zu einem kleinen Teil, vorgegeben.
 Die Treiber des Dienstes waren von dessen Nutzen
überzeugt, aber es fehlte ein klarer „Business-Case“ mit
definierter Zielsetzung und festgelegten Einsatzszenari-
en.
Als erstes Fallbeispiel ist die bereits im Jahr 1998 in einem Soft-
ware-Entwicklungs-Bereich der Siemens AG erfolgte Einführung
der Plattform TechnoWeb zu nennen. Die Nutzung wurde in den
Jahren 2007 und 2008 zunächst auf den gesamten Bereich Sie-
mens IT Solutions und Services und damit auf ca. 20.000 potenti-
elle Nutzer weltweit ausgedehnt. Im Juni 2009 wurde vom Zent-
ralvorstand der Siemens AG entschieden, die Plattform auf eine
neue Technologie, Liferay, zu stellen und um mehrere Funktiona-
litäten, vergleichbar einem Social Networking Service, zu erwei-
tern. Ziel war es, das TechnoWeb in dieser neuen Gestalt kon-
zernweit auszurollen, um das Potential des Dienstes für das ganze
Unternehmen zu überprüfen. Das „neue“ TechnoWeb sollte eine

heterogene Gruppe von ca. 100.000 potenziellen Nutzern dabei
unterstützen, sich gegenseitig zu vernetzen und auszutauschen. In
der Pilotphase sollte herausgefunden werden, „welchen Beitrag
das TechnoWeb zum Geschäftserfolg einzelner Siemens-Bereiche
und für den Konzern als Ganzes leisten kann“. Aus diesem Grund
sollten mögliche Szenarien identifiziert werden, in denen die An-
wendung des Dienstes nutzbringend ist und die Art und Weise der
Nutzung wurde nicht vorgegeben. Nutzer hatten die Möglichkeit,
mit dem neuen Dienst zu experimentieren, um erfolgreiche Szena-
rien zu explorieren. Um in einem weiteren Schritt Management
und Mitarbeiter vom Nutzen der Plattform zu überzeugen sowie
eine kritische Masse an Anwendern und Themen zu erreichen,
wurde das Ziel verfolgt „bereits identifizierte Szenarien als Er-
folgsgeschichten zu kommunizieren, um mehr Transparenz zum
Potential der Dienste zu schaffen“. Gleichzeitig wurde aber da-
rauf hingewiesen, dass es jedem Nutzer weiterhin ungenommen
bleibt, das Potential von TechnoWeb für sich zu entdecken.
Ein weiteres Beispiel stellt die Nutzung des Microblogging-
Dienstes Yammer.com durch inzwischen über 17.000 Mitarbeiter
des international agierenden Beratungsunternehmens Capgemini
dar. Yammer ist eine im World Wide Web erreichbare Plattform,
die speziell für Unternehmen, Organisationen und sonstige ge-
schlossene Gruppen angeboten wird. Aufgrund eines sehr einfa-
chen Registrierungsverfahrens, kann jeder Mitarbeiter eines Un-
ternehmens durch die Eingabe der eigenen (Firmen-)E-
Mailadresse Mitglied eines geschlossenen Netzwerks auf Yammer
werden, das sich einzig und allein durch die Domäne der E-Mail-
Adresse definiert. So können nur Mitarbeiter desselben Unter-
nehmens in das Netzwerk gelangen. Im März 2009 beschlossen
mehrere Capgemini-Berater ein firmeneigenes Yammer-Netzwerk
zu gründen, in welchem sich nach und nach immer mehr Kollegen
in über 100 Themengruppen organisierten und austauschten. Nach
einigen Monaten schlossen sich auch mehrere hochrangige Mana-
ger des Unternehmens, unter anderem der Chief Technology
Officer (CTO), der Nutzergruppe an, um wie die anderen Nutzer
die Potentiale des Dienstes für sich zu entdecken. Stellvertretend
für viele andere Nutzer stellte der CTO fest, dass er „vom Nutzen
für das Unternehmen überzeugt [ist], und weiter daran interes-
siert [wäre], neue Anwendungsszenarien zu identifizieren“.
Bei Fraport, einem Großunternehmen in der Flugbranche mit
international rund 70.000 Beschäftigten, wurde der Wunsch nach
einem unternehmensweiten Wiki im Rahmen einer firmeninternen
Mitarbeiter-Befragung offenbar. In einem im Jahr 2006 initiierten
Projekt begann zunächst eine für zwei Jahre angesetzte experi-
mentelle Erprobung eines „Wiki als Web-2.0-Werkzeug im Wis-
sensmanagement“. Eine Kerngruppe bestehend aus fünf Mitarbei-
tern aus Personalabteilung, Unternehmenskommunikation, Wis-
sensmanagement und IT begann mit der inhaltlichen Betreuung
und Erstbefüllung des Wiki sowie mit der Umsetzung des Pro-
jekts. Nach und nach meldeten sich die ersten Autoren, wobei ein
Teil von ihnen, vorwiegend Themenexperten, persönlich durch
die Kerngruppe angesprochen wurde. Zur internen Vermarktung
der Lösung wurden zahlreiche Flyer inklusive eines Vorworts des
Arbeitsdirektors online und offline im Unternehmen mit folgender
Aussage verteilt: „Inhalt des Wiki darf jegliches Wissen sein,
welches für die Unternehmen und seine Mitarbeiter wichtig ist.
Mitarbeiter bei Fraport sind daher frei, Inhalte im Wiki nach
bestem Wissen und Gewissen zu erstellen sowie zu verändern.“
„Von oben“ wurden weder einzelne gewünschte Themenbereiche
vorgeschlagen, noch Prozesse in denen das Wiki zum Einsatz
kommen soll. Das Wiki entwickelt sich im Unternehmen evoluti-
onär, getrieben durch die Initiative der Beitragenden.
4.2 Promotion
Ebenfalls in rund einem Viertel der Fallstudien wurde Promotion
als dominierende Einführungsstrategie verwendet.
Unter Promotion wird in diesem Beitrag die (mit Unterstützung
des Managements) koordiniert vermarktete und gezielt geschulte
Nutzung der neuen Dienste mit Fokus auf bestimmte Nutzungspo-
tentiale verstanden.
Dabei war die Vorgehensweise der Promotion in den Fallstudien
insbesondere durch folgende Merkmale charakterisiert:
 Das Potential des neuen Dienstes war den Treibern
größtenteils bereits vor der Einführung dieses Dienstes
bekannt.
 Die möglichen Arten der Nutzung wurden im Rahmen
der Einführung (mit Unterstützung des Managements)
koordiniert und kommuniziert.
 Die Treiber der Einführung hegten bereits eine klare
Erwartung an den neuen Dienst und erkannten eine kla-
re Zielsetzung sowie einen bestimmten Nutzen.
Als Beispiel für eine Einführung bei welcher der Ansatz der Pro-
motion verfolgt wurde, lässt sich Infineon Technologies Austria
nennen, die österreichische Tochter eines weltweit operierenden
Konzerns in der Halbleiterindustrie. In diesem Fall bestand das
klar definierte Ziel des einzuführenden Wiki in der Schaffung
einer elektronischen Wissensbasis, um das „Kerngeschäft des
Unternehmens durch effizienteren Tool- und Methodensupport zu
unterstützen“. Der Bedarf nach einer neuen Lösung für den
Transfer von internem Supportwissen zwischen Supportmitarbei-
tern wurde durch den verantwortlichen Manager des „Design
Application Engineering“ Teams festgestellt. Dezentral in Pro-
jektgruppen operierende Mitarbeiter benötigten eine zentralisierte
Lösung, um wiederkehrende Fragen und Probleme effektiv zu
bearbeiten. Im Hinblick auf den Adressatenkreis war das durch
den Manager einführte Wiki in erster Linie dazu gedacht, Sup-
portmitarbeiter in ihrem Kerngeschäft zu unterstützten. Verbun-
den mit internen Marketingmaßnahmen, wie beispielsweise der
Präsentation des Wiki inklusive Zielen und erwartetem Nutzen in
anderen Abteilungen, wird sukzessive daran gearbeitet, auch die
eigentlichen Adressaten des Supports, Techniker und Chipent-
wickler, zur eigenständigen Nutzung des Support-Wiki zu über-
zeugen.
Bei der Maschinenfabrik Andritz, einem österreichischen Unter-
nehmen aus der Branche Maschinen- und Anlagenbau, wurde ein
passendes Werkzeug gesucht, um die Abwicklung eines Projekts
zur Einführung eines neuen Customer-Relationship-Management-
Systems zu optimieren. Der Nutzen des durch die beiden Projekt-
leiter eingeführten Wiki war allen Mitarbeitern sehr schnell klar.
Geht ein Projekt über eine gewisse Komplexität hinaus, wird eine
geeignete technologische Lösung für die Unterstützung benötigt.
Das Wiki erfüllte alle an eine solche Lösung gestellten Anforde-
rungen ausgezeichnet und stellte sich als einfach und rasch im-
plementierbar heraus. Alle Projektmitarbeiter verstanden diesen
Umstand schnell und nutzten das Wiki, auf die von den Projekt-
leitern beabsichtigte und an die Projektmitarbeiter kommunizierte
Art und Weise.

Bei der Pentos, einem deutschen IT-Systemdienstleister, wurde
durch den Vorstand festgestellt, dass der Wissenstransfer zwi-
schen den Mitarbeitern nicht optimal war. So wurden Mitarbeiter-
Weblogs auf der Basis von Lotus-Notes implementiert und durch
den Vorstand in Abstimmung mit der Personalabteilung einge-
führt. Das Ziel der neuen Lösung bestand darin, die interne Mit-
arbeiter-Kommunikation effektiver zu gestalten, als über klassi-
sche Medien wie Telefon und E-Mail möglich und die Mitarbeiter
durch das Schreiben von Beiträgen zu mehr Selbstreflexion über
ihre Tätigkeiten zu ermuntern. Mitarbeiter sollen in ihren „Wo-
chenberichten“ einmal pro Woche festhalten, was sich in ihrem
Arbeitsbereich ereignet hat und diese Informationen dann allen
Kollegen zur Verfügung stellen. Die Informationen in den Mitar-
beiter-Weblogs sollen Mitarbeiter-Ziele und -Tätigkeiten sowie
den Bezug dieser Tätigkeiten zum Unternehmenserfolg transpa-
rent machen. Sowohl die Nutzungsart, als auch der erzielte Nut-
zen war bei Pentos also von Anfang an durch den Vorstand klar
definiert und kommuniziert.
4.3 Exploration und Promotion
Wie sich in den untersuchten Fallstudien zeigte, sind beide Vor-
gehensweisen auch miteinander vereinbar, ohne dass eine die
andere dominiert. In elf Unternehmen, also in mehr als der Hälfte
der untersuchten Fälle, konnten beide Vorgehensweisen in Kom-
bination festgestellt werden, teilweise auch nachgelagert (zuerst
Exploration, dann Promotion). Drei Beispiele für diese Misch-
form werden im Folgenden angeführt.
Zur Verbesserung der unternehmensinternen, internationalen
Zusammenarbeit und zur Unterstützung des unternehmensweiten,
informellen Expertenaustauschs führte Ende 2005 der zentrale IT-
Bereich von Bosch zusammen mit einer Entwicklungsabteilung
des Geschäftsbereichs Diesel Systems eine mehrmonatige Studie
zur unternehmensweiten Wiki-Einführung durch. Das Ziel der
Wiki-Studie bestand darin, eine einheitliche Wiki-Plattform aus-
zuwählen, diese im Testbetrieb zu untersuchen und schließlich
Anfang 2007 im Produktivbetrieb jedem Mitarbeiter der Bosch-
Gruppe zur Verfügung zu stellen. Schon vorher waren vereinzelt
Wiki-Server im Einsatz - in der Regel genutzt innerhalb einer
Abteilung und auf unterschiedlichen Plattformen. Aufgrund dieser
vorhergegangenen „Explorationsphase“ waren bereits verschiede-
ne Wiki-Nutzungsszenarien identifiziert worden, die bei der Pro-
motion des Wikis in den weltweiten Abteilungen hilfreich waren.
Dazu gehörte die Nutzung zum Bug Tracking, d.h. zum Verfolgen
von Software-Fehlern, als Glossar, als Artikelsammlung, als Do-
kumentationsplattform, zum Experten-Debriefing und zum inter-
kulturellen Austausch.
Die 180 Mitarbeiter der Communardo GmbH arbeiten in wissens-
intensiven Softwareentwicklungs- und Beratungsprojekten und in
Form verschiedener Teams zusammen. Bedingt durch das schnelle
Wachstum entstanden Schwierigkeiten bei der Weitergabe von
Informationen und Ideen zwischen Organisationseinheiten und
zwischen Projekten. So wurde im Frühjahr 2008 von einem Mit-
arbeiter vorgeschlagen das Potential von Twitter oder einen Twit-
ter-ähnlichen Instrument zur Erleichterung der Kommunikation
im Team zu untersuchen. Diese Idee wurde von der Geschäftsfüh-
rung unterstützt und mitgetragen. Schnell entschied man sich
gegen einen öffentlichen Microblogging-Dienst und entwickelte
eine eigene Lösung. Jedoch war unklar, welche Nutzungsszenari-
en die Plattform insbesondere unterstützen würde. Also wurde
beschlossen, die Potentiale der Plattform nach und nach für sich
zu entdecken (Exploration). Die Geschäftsführer waren von den
Vorteilen der Nutzung überzeugt und begannen „Erfolgsgeschich-
ten“ regelmäßig an die Belegschaft zu kommunizieren (Promoti-
on). Bereits Mitte 2009 hatte der Dienst so nicht nur einen festen
Platz in der IT-Landschaft des Unternehmens erobert, sondern es
waren eine Vielzahl von Nutzungsszenarien bekannt, in denen der
Dienst genutzt werden sollte (Promotion).
Bei Spirit Link, einem deutschen IT-Systemhaus für die
Healthcare Industrie, wurde durch die Geschäftsleitung ein Lei-
densdruck in Folge einer Überverwendung von klassischen Medi-
en wie E-Mail festgestellt. Die Effizienz einer über Kanäle im
Gegensatz zu Portalen gesteuerten Informationsverteilung wurde
im Unternehmen als sehr gering eingestuft. Das Ziel der durch die
Geschäftsleitung initiierten Themen-Weblogs bestand darin, das
Kerngeschäft des Unternehmens durch eine optimierte Verteilung
innovativer Inhalte im Unternehmen zu unterstützen (Promotion).
Inhalte und inhaltliche Strukturen werden jedoch weitestgehend
von den themenverantwortlichen Mitarbeitern in Selbstorganisati-
on erstellt (Exploration), welche die von ihnen verantworteten
Weblogs im Unternehmen auch eigenständig vermarkten. Obwohl
Nutzen und primäre Nutzung der Themen-Weblogs durch die
Geschäftsleitung mittels der Zuweisung von Themen und The-
menverantwortlichen vorgegeben wird (Promotion), obliegen
inhaltliche Arbeiten und Ausrichtung der Weblogs und das Erstel-
len von Beiträgen den Mitarbeitern selbst (Exploration).
5. DISKUSSION
Obwohl die beiden Vorgehensweisen aus Sicht der Autoren klar
beschrieben und voneinander abgegrenzt wurden, wird aus den
neun fokussiert erläuterten Fallbeispielen klar, dass jede Einfüh-
rung von unterschiedlichen Faktoren beeinflusst wird und daher
nur im Kontext betrachtet werden kann. So können, wie aufge-
zeigt, beispielsweise bereits bestehende Vorgängerlösungen Ein-
fluss auf das Vorgehen bei der Einführung eines neuen Dienstes
ausüben, ebenso wie verschiedene Zielsetzungen sowie Anforde-
rungen von Stakeholdern an die Dienste und noch eine Vielzahl
weiterer Einflüsse. Aus diesem Grund fordert eine saubere Tren-
nung der Vorgehensweisen und anschließende Einordnung der
einzelnen Fälle eine gründliche Auseinandersetzung mit jedem
unterschiedlichen Einführungsprozess (vgl. dazu z.B. [24]). Dabei
waren mehrere bestehende Denkansätze zur Einführung von
Groupware aus dem Forschungsgebiet Computer Supported Col-
laborative Work (CSCW) hilfreich, die in diesem Abschnitt mit
den in der Studie gewonnenen Erkenntnissen in Beziehung gesetzt
werden. Gleichzeitig wird im Folgenden auch auf die bestehenden
Unterschiede von (traditioneller) Groupware und Social Software
hingewiesen.
5.1 Exploration
Zusammenfassend lässt sich sagen, dass das Ziel der Exploration
in den untersuchten Fällen darin bestand, einen neuen Dienst als
Hilfsmittel in bestehende (soziale) Prozesse und Mitarbeiter-
Aktivitäten zu integrieren und diese damit zu unterstützen.
Gleichzeitig sollten aber auch weitere noch nicht identifizierte
Anwendungsszenarien mithilfe des Dienstes unterstützt werden.
Es ging es den Verantwortlichen bei prototypischen Umsetzungen
oftmals gar nicht darum, einen sogenannten „viralen Effekt“ (z.B.
[2]) zu erzielen und damit eine starke und schnell skalierende
Nutzerbasis zu gewinnen. Vielmehr hing die Entscheidung davon
ab, ob das Potential eines Dienstes bereits vollkommen klar war,

oder ob Management bzw. Mitarbeiter nach und nach weitere
bisher unbekannte Nutzungsmöglichkeiten identifizierten.
Die dieser Fragestellung zugrundeliegende Nutzungsoffenheit
kann dabei als eine Kerncharakteristik von Corporate Social
Software und als Unterschied zu (traditioneller) Groupware gese-
hen werden [39]. Das heißt, das Potential der Dienste zeigt sich
erst nach der Aneignung durch die Anwender. Die Dienste müs-
sen hierfür erst zu einem Bestandteil der Gruppenpraktiken und
organisationalen Prozesse werden (vgl. [41]).
Wie in den vorliegenden Fallstudien deutlich wurde, eigneten die
Nutzer sich die Dienste im Rahmen ihrer Arbeitspraktiken an. Bei
dieser Aneignung wurden sie in der Regel unterstützt – nicht in-
dem man ihnen die Nutzung strikt vorschrieb, sondern indem man
ihnen lediglich eine moderne und zeitgemäße Infrastruktur für
ihre Arbeitspraktiken zur Verfügung stellte. Ein klarer „Business-
Case“ mit definierter Zielsetzung, die Festlegung der für die Nut-
zung beteiligten Mitarbeiter und eine detaillierte Beschreibung
des erwarteten Nutzens für Mitarbeiter und Unternehmen fehlten.
Erst im Laufe der Zeit konnte sich dieser aufgrund der langsam
aufkeimenden Nutzung der neuen IT-Werkzeuge kontinuierlich
herausbilden. Ein solches Vorgehen wird in der Literatur auch
„Infrastructuring“ genannt (vgl. [35]). Dabei ist eine Infor-
mationsinfrastruktur als “a shared, evolving, heterogeneous in-
stalled base of IT capabilities among a set of user communities
based on open and/or standardized interfaces” zu verstehen ([18],
p. 208).
Im o.g. Vorgehen kommt auch die Relevanz der partizipativen
Einführung von Software zum Tragen, die bereits seit Jahren im
Bereich CSCW betont wird (z.B. [16], [24]). Denn neben den
zunehmend komplexeren Beziehungen in solchen Systemen, än-
dern sich die Arbeitssysteme häufig durch die Technikeinführung
und erst nach der Einführung erster Versionen werden die Mög-
lichkeiten der Nutzung richtig klar. Aufgrund von immer kürzer
werdenden Innovationszyklen ändern sich technologische Syste-
me viel rascher, als die Arbeitspraktiken der Mitarbeiter. Organi-
sationale Änderungen benötigen aufgrund der höheren Komplexi-
tät sozialer Systeme mehr Zeit. Jedoch kann eine Technologie ihr
volles Potenzial nur dann ausspielen, wenn sich beide Systeme
aneinander anpassen.
Dabei zeigt sich auch die hohe Bedeutung einer sozio-technischen
Systemgestaltung, d.h., dass bei der Entwicklung und Einführung
sowohl das soziale als auch das technische Teilsystem einer Orga-
nisation gleichmäßig beachtet werden müssen [34]. Nur wenn sich
beide Teilsysteme regelmäßig im Rahmen einer Ko-Evolution
einander annähern, ist der Nutzen des Dienstes sichergestellt [39].
Sehr oft wird dem technischen System jedoch eine weit höhere
Aufmerksamkeit geschenkt und ein nicht adaptiertes soziales Sys-
tem konterkariert den Nutzen einer neuen Technologie.
5.2 Promotion
Das Ziel der Promotion besteht darin, möglichst rasch eine kriti-
sche Masse [29] an echten Nutzern zu erreichen, was gerade für
Social Software eine wichtige Rolle spielt (z.B. [39]). Hier kann
das Management als Vorbild dienen, d.h. die Nutzer motivieren
und zur Nutzung der neuen Dienste aufzurufen. Es sollte aber
gleichzeitig nicht diktieren, wie Nutzer damit zu arbeiten haben.
Zudem sollten keine Hierarchien abgebildet werden, wo sie nicht
notwendig sind und sichergestellt werden, dass die richtigen An-
reize zur Nutzung bestehen.
Weiterhin ist die Vorgehensweise der Einführung dadurch charak-
terisiert, dass ein „Business-Case“ bereits vor der Einführung
vorhanden ist und meist durch das Management definiert wurde.
Entsprechende IT-Werkzeuge wurden in mehreren Fällen auch
bereits vor dem Hintergrund dieses speziellen Business-Cases
ausgewählt. Dieser Business-Case wird auch im Rahmen von
Begleitmaßnahmen wie beispielsweise Akzeptanzmaßnahmen,
Präsentationen oder Schulungen laufend an die Mitarbeiter kom-
muniziert.
Gleichzeitig zeigte sich in mehreren Fällen, dass die Phasen des
klassischen Veränderungsprozesses (beispielsweise Sensibilisie-
rung, Vision entwickeln und kommunizieren, Steuerung der Ver-
änderung, etc., vgl. z.B. [25]) auch für Corporate Social Software
durchaus sinnvoll anwendbar sind. Interessant erscheint in diesem
Zusammenhang ebenfalls, dass allgemein auch die Vertreter
nachhaltig gemeinter Veränderungsprozesse dafür plädieren, alle
Stakeholder frühestmöglich einzubeziehen (z.B. [43]). Gerade an
diesem letztgenannten Punkt zeigt sich, dass die beiden Vorge-
hensweisen nicht diametral gegenüber stehen müssen, sondern
sich durchaus ergänzen können bzw. sich teilweise ähnliche
Schritte anbieten.
5.3 Limitationen
Die vorgestellten Forschungsergebnisse müssen im Lichte der
folgenden Limitationen der Analyse betrachtet werden. Wie an
der eben geführten Diskussion ersichtlich, ist die Abgrenzung der
beiden Vorgehensweisen Exploration und Promotion stark vom
Kontext abhängig. Als Grund hierfür ist die bereits angesprochene
Vielzahl unterschiedlicher Faktoren, welche die Entscheidung für
eine oder beiden Vorgehensweisen beeinflussen können, zu se-
hen. Es wurden Unternehmen unterschiedlicher Größe und mit
sich unterscheidenden Organisationskulturen untersucht – um nur
zwei Unterschiede zu nennen.
Während statistische Generalisierbarkeit durch die durchgeführte
Forschung ohnehin nicht beabsichtigt wird, so ließe sich durch die
Erweiterung der Cross-Case-Analysis die analytische Generali-
sierbarkeit der gewonnenen Ergebnisse erhöhen (vgl. dazu z.B.
[54]). Dabei lässt sich die in diesem Beitrag entwickelte Theorie
(„Exploration“, „Promotion“) als Schablone benutzen und mit den
empirischen Ergebnissen weiterer Fallstudien vergleichen. Unter-
stützen zwei oder mehrere Fälle die Theorie, kann von Replikati-
on gesprochen werden [54].
Des Weiteren ist anzumerken, dass aufgrund der vorliegenden
einheitlichen Struktur aller Fallstudien, der eingegrenzten For-
schungsfrage und der Vertrautheit der Autoren mit den einzelnen
Fällen auf eine zusätzliche Codierung der Fallstudien verzichtet
wurde. Dabei wird nicht in Frage gestellt, dass für die weiteren
Auswertungen eine Codierung (wie z.B. in [44] verfolgt) einen
zusätzlichen Nutzen bringen kann.
6. ZUSAMMENFASSUNG UND AUSBLICK
Im vorliegenden Beitrag wurden Teilergebnisse aus einer verglei-
chenden Analyse von 21 Fallstudien zum Einsatz von Corporate
Social Software vorgestellt und diskutiert. Durch die systemati-
sche Betrachtung der Vorgehensweisen bei der Einführung stellte
sich heraus, dass in den Unternehmen zwei unterschiedliche, je-
doch nicht unbedingt widersprüchliche, Vorgehensweisen ange-
wandt wurden: „Exploration“ (in fünf Fällen), „Promotion“ (in
fünf Fällen), sowie eine Kombination beider Vorgehensweisen (in
elf Fällen).

Eine Flankierung der Einführung von Corporate Social Software
von „links“ und „rechts“ erscheint dabei zielführender als die
nicht enden wollende Diskussion darüber, ob Unternehmen Cor-
porate Social Software „von oben“ oder „von unten“ einführen
sollten. Die in diesem Beitrag vorgestellten Forschungsergebnisse
räumen auch mit dem Vorurteil auf, dass neue IT-Werkzeuge in
Unternehmen immer Top-Down eingeführt werden müssen, um
erfolgreich zu sein. Neue Dienste können auch nutzenstiftend
wirken, wenn sie nicht Top-Down, sondern explorativ eingeführt
werden. Den Autoren liegt nach bestem Wissen und Gewissen
noch keine wissenschaftliche Arbeit vor, welche diese von Prakti-
kern schon länger gemutmaßte Erkenntnis anhand einer großen
Anzahl an Fallstudien bestätigt.
Die vorgestellte Studie hat noch weitere Erkenntnisse zu Tage
gebracht, die jedoch nicht im Fokus des vorliegenden Beitrags
stehen. Beispielsweise ist den Fallstudien zu entnehmen, dass der
Einsatz von Social Software zunehmend weniger prototypisch
abläuft, den Weg in die Arbeitsprozesse findet und mit anderen
Diensten integriert wird (oder werden soll). Auf Basis der erhobe-
nen Daten lässt sich vermuten, dass Werkzeuge wie Wikis und
Weblog im Kontext von Unternehmen bereits eine gewisse Reife
besitzen, sodass sich Promotion als dominierende Strategie her-
auskristallisiert, während Microblogging als neuer Dienst ver-
stärkt mittels Exploration in Unternehmen durch die Mitarbeiter
„erforscht“ wird. Eine Einführung neuer Dienste, bei denen noch
größtenteils Unklarheit über Szenarien und Nutzungsmuster
herrscht, tendiert eher in Richtung Exploration, während klassi-
sche Anwendungen, für die bereits reichlich Verständnis zu Nut-
zung und Nutzen vorliegt, von „Promotion“ stark profitieren.
7. LITERATUR
[1] Back, A., Gronau, N., und Tochtermann, K. 2009. Web 2.0
in der Unternehmenspraxis. Oldenbourg, München.
[2] Barabasi, A.L. 2003. Linked: How Everything Is Connected
to Everything Else and What It Means. Plume, London.
[3] Böhringer M, Richter, A., und Koch, M. 2009. Awareness
2.0 - Ein Anwenderbeispiel von Microblogging im Unter-
nehmen, Information, Wissenschaft & Praxis, 60, 4, 275-
279.
[4] Buhse W., und Stamer S. 2008. Enterprise 2.0 - Die Kunst,
loszulassen. Rhombos, Berlin.
[5] Bughin, J., und J. Manyika 2007. How businesses are using
Web 2.0: A McKinsey Global Survey. McKinsey Research.
[6] Danis, C., und Singer, D. 2008. A Wiki Instance in the En-
terprise: Opportunities, Concerns and Reality. In Proceed-
ings of the 11th Conference on Computer Supported Coop-
erative Work, San Diego, ACM Press.
[7] DiMicco, J.M., Millen, D.R., Geyer, W., Dugan, C., Brown-
holtz, B., und Muller, M. 2008 Motivations for Social Net-
working at Work. In Proceedings of the 11th Conference on
Computer Supported Cooperative Work, San Diego, ACM
Press.
[8] Disterer, G. 2000. Individuelle und soziale Barrieren beim
Aufbau von Wissenssammlungen. Wirtschaftsinformatik, 42
6, 539-546.
[9] Dubé L. und Paré G. 2003. Rigor in Information Systems
Positivist Case Research: Current Practices, Trends, and
Recommendations. MIS Quarterly 27, 4, 597-635.
[10] Ebersbach, A., und Glaser, M. 2009. Wiki als zentrales
Suchportal. Das Beispiel bluepedia. Information, Wissen-
schaft & Praxis, 60, 4, 197-201.
[11] Efimova, L,. und Grudin, J. 2007. Crossing boundaries: A
case study of employee blogging. In Proceedings of the 40th
Hawaii International Conference on System Sciences, Wai-
koloa, IEEE Computer Society Press.
[12] Eisenhardt K. M. 1989. Building Theories from Case Study
Research. The Academy of Management Review, 14, 4, 532-
550
[13] Glaser B.G., und Strauss, A.L. 1967. The Discovery of
Grounded Theory: Strategies for Qualitative Research. Al-
dine Publishing Company, Chicago
[14] Grace, T. 2009. Wikis as a Knowledge Management Tool.
Journal of Knowledge Management, 13, 4, 64-74.
[15] Gratton, L. und Erickson, T.J. 2007. 8 Ways to Build Col-
laborative Teams. Harvard Business Review (Nov. 2007),
100-109.
[16] Gross, T, Koch, M. 2007. Computer-Supported Cooperative
Work, Oldenbourg, München.
[17] Han, B.M., und Anantatmula, V. 2006. Knowledge Man-
agement in IT Organizations From Employee’s Perspective.
In Proceedings 39th Hawaii International Conference on
System Sciences
[18] Hanseth, O., und Lytinnen, K. 2004. Theorizing about the
Design of Information Infrastructures: Design Kernel Theo-
ries and Principles, Sprouts: Working Papers on Information
Systems, 4, 12.
[19] Happel, H., und Treitz, M. 2008. Proliferation in Enterprise
Wikis. In: Proceedings International Conference on the De-
sign of Cooperative Systems, Carry-le-Rouet.
[20] Holsapple, C.W., und Joshi, K.D. 1999. Description and
Analysis of Existing Knowledge Management Frameworks.
In Proceedings of the 32th Hawaii International Conference
on System Sciences.
[21] Holtzblatt, L., L. Damianos. und Weiss, D. 2010. Factors
Impeding Wiki Use in the Enterprise: A Case Study. In Pro-
ceeding of the 28th annual SIGCHI conference on Human
factors in computing systems, Atlanta, ACM Press.
[22] Ip, K.F.R., und Wagner, C. 2008. Weblogging: A study of
social computing and its impact on organizations. Decision
Support Systems, 45, 2, 242-250.
[23] Jahnke, I. 2009. Socio-technical Communities: From Infor-
mal to Formal? In: Withworth, B. (Hrsg.) Handbook of Re-
search on Socio-Technical Design and Social Networking
Systems. IGI Global Publisher, 763-778
[24] Karsten, H. und Jones, M. 1998. The Long and Winding
Road: Collaborative IT and Organisational Change. In Pro-
ceedings of Conference of the ACM 1998 Conference on
Computer Supported Cooperative Work, Seattle.
[25] Kotter, J.P. 1996. Leading Change. Harvard Business School
Press, Boston.

[26] Koch, M. 2008. CSCW and Enterprise 2.0 - towards an inte-
grated perspective. In Proceedings 21st Bled eConference
eTrust: Implications for the Individual, Enterprises and So-
ciety.
[27] Koch, M., und Richter, A. 2009. Enterprise 2.0 - Planung
Einführung und erfolgreicher Einsatz von Social Software im
Unternehmen. Oldenbourg, München.
[28] Mans, R. 2010. Bottom up: an overrated and underperform-
ing social strategy (for lazy people). Online:
http://www.capgemini.com/technology-blog/2010/04/ bot-
tom_ up_overrated _and_underperforming.php
[29] Markus, M. L. 1987. Toward a "critical mass" theory of in-
teractive media: Universal access, interdependence and diffu-
sion. Communication Research, 14, 5, 491.
[30] McAfee, A. 2009. Enterprise 2.0: New Collaborative Tools
for Your Organization's Toughest Challenges. Mcgraw-Hill
Professional, Boston.
[31] Mueller, J. und Stocker, A. 2010. Enterprise Microblogging
at Siemens, Building Technologies Division: A Descriptive
Case Study. In Proceedings of 10th International Conference
on Knowledge Management and Knowledge Technologies,
Graz.
[32] Orlikowski, W. J. 2000. Using technology and constituting
structures: A practice lens for studying technology in organi-
zations. Organization Science, 11, 4, 404-428.
[33] Paroutis, S., und Saleh, A. 2009 Determinants of knowledge
sharing using Web 2.0 technologies. Journal of Knowledge
Management, 13, 4, 52-63.
[34] Pasmore, W., Franics, C., Haldeman, J., und Shani, A. 1982.
Sociotechnical systems: A North American reflection on em-
pirical studies in the seventies, Human Relations, 35, 12,
1179-1204.
[35] Pipek, V., und Wulf, V. 2009. Infrastructuring: Towards an
Integrated Perspective on the Design and Use of Information
Technology, Journal of the Association of Information Sys-
tems, 10, 5.
[36] Razmerita, L., Kirchner, K., und Suzdina, F. 2009. Personal
knowledge management. The role of Web 2.0 tools for man-
aging knowledge at individual and organizational levels.:
Journal of Knowledge Management, Emerald Publishing.
[37] Richter, A., und Bullinger, A. C. 2010. Enterprise 2.0 – Ge-
genwart und Zukunft. Vorschlag einer Forschungsagenda. In
Proceedings Multikonferenz Wirtschaftsinformatik, Göttin-
gen.
[38] Richter, A., Mörl, S., Koch, M.; und Trier, M. 2011. An-
wendungsszenarien als Werkzeug zur (V)ermittlung des Nut-
zens von Corporate Social Software. In Proceedings Wirt-
schaftsinformatik 2011, Zurich.
[39] Richter, A., und Riemer, K. 2009. Corporate Social Net-
working Sites – Modes of Use and Appropriation through
Co-Evolution. In Proceedings 20th Australasian Conference
on Information Systems, Melbourne.
[40] Richter, A., und Vogl, G. 2009. SkiBaserl – Knowledge
Management in High-Performance Sports. In Proceedings
9th International Conference on Knowledge Management
and New Media Technology, Graz.
[41] Riemer, K., Frößler, F., und Klein, S. 2007. Real Time
Communication – Modes of Use in Distributed Teams. In
Proceedings 15th European Conference on Information Sys-
tems. St. Gallen.
[42] Riemer, K.und Richter, A. 2010. Tweet Inside: Microblog-
ging in a Corporate Context. In Proceedings 23rd Bled
eConference eTrust: Implications for the Individual, Enter-
prises and Society.
[43] Rosenstiel, L. v. 2000. Grundlagen der Organisationspsy-
chologie. Schäffer-Poeschel Verlag, Stuttgart.
[44] Schubert, P., Williams, S. P. 2009. Constructing a Frame-
work for Investigating and Visualizing ERP Benefits and
Business Change. In Proceedings of the 22nd International
Bled eConference, Bled.
[45] Schubert, P., Wölfle, R. 2006. eXperience-Methodik zur
Dokumentation von Fallstudien. In: Wölfle, R.; Schubert, P.
(Hrsg.): Prozessexzellenz mit Business Software. Hanser
Verlag, München, 19-30.
[46] Schubert, P., Wölfle, R. 2007. The eXperience Methodology
for Writing IS Case Studies. In Proceedings of the Thirteenth
Americas Conference on Information Systems, Keystone.
[47] Senger, E., Österle, H. 2004. PROMET – Business Engineer-
ing Cases Studies (BECS). Arbeitsbericht BE HSG / BECS /
1. Institut für Wirtschaftsinformatik, Universität St. Gallen,
Juni 2004.
[48] Stake, R.E. 1995. The Art of Case Study Research. SAGE
Publications, London.
[49] Stocker, A. Tochtermann, K. 2009. Exploring the Value of
Enterprise Wikis - A Multiple-Case Study. Proceedings of
the International Conference on Knowledge Management
and Information Sharing, Funchal.
[50] Stocker, A., und Tochtermann, K. 2010. Wissenstransfer mit
Wikis und Weblogs. Fallstudien zum erfolgreichen Einsatz
von Web 2.0 im Unternehmen. Gabler-Verlag, München.
[51] Stake, R.E. 1995 The Art of Case Study Research. SAGE
Publications, London.
[52] Warta, A., und Richter, A. 2007. Die Medienvielfalt als Bar-
riere für den erfolgreichen Einsatz von Wikis im Unterneh-
men am Fallbeispiel der Robert Bosch GmbH. In Procee-
dings des Workshops Gemeinschaften in Neuen Medien,
Dresden.
[53] Wulf, V. 2009. Theorien sozialer Praktiken zur Fundierung
der Wirtschaftsinformatik: Eine forschungsprogrammatische
Perspektive, In: Wissenschaftstheorie und Gestaltungsorien-
tierte Wirtschaftsinformatik, Springer/Physika, 211-224.
[54] Yin, R.K. 2003. Applications of case study research. Thou-
sand Oaks, California: Sage Publications, Thousand Oaks.

8. ANHANG

#
Unternehmen,
Land
Technologie
(konkrete
Umsetzung)
Ursprung / Konzept Einführung
(P = Promotion, E = Exploration)
1
ABB,
D
Wiki, Blog, Newsletter
(Sharerpoint 3.0)
Pilotprojekt, Test versch. Tools,
Nutzung nicht vorgegeben
E, P "Wiki-Tour", Ansprache von
Multiplikatoren
2
Accenture,
weltweit
Social Networking
Service (SNS)
(Eigenentwicklung)
Pilotprojekt nach Vorbild Facebook
und LinkedIN, „Business-Case“
unscharf
E, P Evaluierung möglicher
Nutzungsszenarien, div. Promotionen
bei weltweiter Einführung
3
Bosch,
D
Wiki
(Confluence)
Mehrere unterschiedliche Plattformen
wurden zusammengeführt
E, P Zunächst Pilotprojekt bei Division
(Diesel), dann weltweiter Roll-Out
4
CapGemini,
weltweit
Microblogging
(Yammer)
Einführung von kleiner Gruppe von
Mitarbeitern vorangetrieben
E Geschäftsführung (CTO) von Nutzung
überzeugt, aber keine Vorgabe
5
Communardo,
D
Microblogging
(Eigenentwicklung)
Pilotgruppe mit Wordpress-Lösung,
Rapid Prototyping
E, P Potentiale während Entwicklung
identifiziert, später Wunsch der Nutzung
und Art der Nutzung durch GF klar
6
Deutscher Skiverband,
D
Wiki
(TWiki)
Pilotprojekt, ohne vorher klare
Nutzungsszenarien
E, P Nutzerworkshops zur Identifikation von
Nutzungsszenarien, Schulungen
7
Fraport,
D
Wiki
(MediaWiki)
Interne Befragung zu WM-
Instrumenten, Pilotprojekt
E Ohne klare Nutzungsszenarien gestartet,
Nutzung nicht vorgegeben
8
IBM,
weltweit
SNS
(Eigenentwicklung)
Evolution aus bestehender Lösung
heraus, vielfältige Integration
E Kontinuierliche Identifikation neuer
Nutzungspotentiale
9
Infineon Technologies,
AUT
Wiki
(MediaWiki)
Bedarf durch Abteilungsleiter
erkannt, teilweise Migration von
anderem System
P Vorstellung klar definierter angestrebter
Nutzungsszenarien in den Abteilungen
10
IVM,
AUT
Wiki
(Perspective)
Kein Intranet vorhanden, Bedarf
durch Abteilungsleiter erkannt und
Projekt aufgesetzt
E, P Nutzungsszenarien für Techniker und
Verwaltung, Techniker haben effektive
Nutzungspraktiken herausgebildet
11
Maschinenenfabrik
Andritz, AUT
Wiki
(TWiki)
Klar vordefinierter Einsatzfall,
Bedarf durch Manager erkannt
P Klar definierte Nutzungsszenarien, Ziel
der Nutzung von Beginn an klar
12
Microsoft,
AUT
Integrierte Blogs
(Sharepoint)
Kein Intranet vorhanden,
Kommunikationskonzept als Basis
P Blog-Nutzung aus E-Mail-Nutzung
ableiten, Schulungen, Flyer
13
Pentos,
D
Blogging
(Lotus Notes/Domino)
Bedarf durch Vorstand erkannt,
simple Eigenkonzeption
P Schulung durch Geschäftsleitung,
finanzielle Honorierung
14
Raiffeisen,
AUT
Wiki
(JSPWiki)
Bedarf durch WM-Kerngruppe
erkannt
P Fest vordefinierte Inhalte, Artikel zur
Nutzung und Zielen, Flyer
15
SAP,
weltweit
SNS
(Eigenentwicklung)
Pilotprojekt nach Vorbild Facebook
und LinkedIN
E, P Evaluierung möglicher
Nutzungsszenarien, spätere Promotion
16
Siemens Building
Technologies Division,
CH
Microblogging-Service
(Eigenentwicklung)
Pilotprojekt nach Vorbild Yammer,
Integration in bestehende WM-
Plattform
E Individuelle Verwendung gewünscht,
Akzeptanzmaßnahmen
17
Siemens,
weltweit
SNS
(Liferay)
Pilotprojekt, Migration bestehender
Daten aus Vorgängersystem
E Nutzer sollen selbst Zugang finden,
freier Verwendungszweck
18
Spirit Link,
D
Weblogs
(Wordpress)
Gespräche der Geschäftsleitung mit
befreundeter Organisation
E, P Zuweisung von Verantwortlichen durch
Geschäftsleitung nach Themen,
Eigenständiges Bearbeiten
19
Synaxon,
D
Wiki-Blog
(Media-Wiki &
eigenentwickelter Blog)
Überzeugung des Vorstands,
Evolution aus bestehender Lösung
E, P Mitarbeiter agieren in Eigeninitiative,
entwickeln die Vision des Unternehmens
weiter
20
TAO Beratungs- und
Management, AUT
Wiki
(MediaWiki)
Überzeugung eines Standortleiters,
Pilotprojekt nach Vorbild Wikipedia
E, P Schulungen, Ziel weitere
Nutzungsszenarien zu finden
21
T-Systems MMS,
D
Social Intranet
(Confluence)
Heterogenes Projektteam, Test des
Confluence Wiki
E,P Pilotgruppe, iterative Freischaltung von
neuen Nutzern