HMD 267 47
Michael Koch, Florian Ott, Alexander Richter
Wikis und Weblogs im Wissens- und
Innovationsmanagement
Verschiedene namhafte Konzerne haben sich in
der jüngsten Vergangenheit damit auseinander-
gesetzt, Wikis und Weblogs als Kollaborations-
werkzeuge innerhalb ihres Intranets einzufüh-
ren. Der Einsatz von Social Software lohnt sich
aber nicht nur für große Konzerne und Organisa-
tionen, sondern ebenso für kleine und mittel-
ständische Unternehmen oder (virtuelle) Projekt-
teams. In diesem Beitrag berichten wir von
Erfahrungen aus zwei Einführungsprojekten, die
wir im letzten Jahr wissenschaftlich begleitet ha-
ben. In beiden Projekten wurden Open-Source-
Wikis und -Weblogs eingeführt – zum Teil in
einem Umfeld mit sehr geringer Technikaffinität.
Neben der Beschreibung der Lösungen fassen wir
die gewonnenen Erkenntnisse zu Handlungs-
empfehlungen für ähnliche Projekte zusammen.
Inhaltsübersicht
1 Wissensmanagement mit Social Software
2 Wissens- und Innovationsmanagement im
Spitzensport
2.1 Ausgangslage
2.2 Erfahrungen
3 IT-Trends-Management
3.1 Ausgangslage
3.2 Erfahrungen
4 Lessons Learned
4.1 Zusammenfassung der
Rahmenbedingungen
4.2 Projektplanung/Vorgehen
4.3 Funktionsbedarf
4.4 Aktivität der Projektteilnehmer
4.5 Usability
4.6 Oberfläche/Struktur/Navigation
4.7 Nutzungsorientierte Dokumentation
5 Zentrale Erkenntnisse und
Handlungsempfehlungen
6 Literatur
1 Wissensmanagement
mit Social Software
Vielen Wissensmanagementansätzen in Unter-
nehmen fehlte bisher weitgehend eine un-
komplizierte Möglichkeit zur Partizipation. Aus
diesem Grund haben Organisationen in den
letzten Jahren vermehrt versucht, die im Inter-
net erfolgreichen Social-Software-Ansätze wie
Weblogs, Wikis, Social Tagging und Social Net-
working auf ihr firmeninternes Intranet zu
übertragen – oftmals mit großem Erfolg (vgl.
[Back et al. 2008], [Koch & Richter 2008]).
Das Vorgehen dabei lässt sich wie in Abbil-
dung 1 illustriert veranschaulichen [Richter &
Koch 2008]: Als Vorbild für die Nutzung der
Werkzeuge dient das World Wide Web. Für den
Einsatz im Unternehmen werden die adap-
tierten Werkzeuge an den Unternehmenskon-
text angepasst und zusätzlich mit Erfahrungen
aus dem Einsatz anderer unternehmensinter-
ner Kooperationssysteme angereichert. Bei-
spielsweise diente die Internetplattform Face-
book in den letzten Jahren bereits mehreren
Unternehmen als Vorbild für die Umsetzung
eigener Social Networking Services.
Beim Einsatz von Social Software in Unter-
nehmen (Enterprise 2.0) entstehen im Vergleich
zum Einsatz der Werkzeuge im »privaten« Inter-
net verschiedene neuartige, organisations-
spezifische Herausforderungen, wie z. B. die
Notwendigkeit der Einbeziehung von Unter-
nehmensstrukturen und Prozessen, von Sicher-
heits- und Rechtekonzepten sowie Anreizme-
chanismen, um kontinuierlich ausreichende
Partizipation zu gewährleisten. Werden diese
Spezifika bei der soziotechnischen Systemge-
staltung der Werkzeuge berücksichtigt, bietet
Social Software gegenüber anderen Werkzeu-

Wikis und Weblogs im Wissens- und Innovationsmanagement
48 HMD 267
Herausforderungen
des Einsatzes von
Social Soware im
World Wide Web
IntranetWWW
§§§
Herausforderungen
des Einsatzes von
Social Soware im
Unternehmen
Erfahrungen aus
dem Einsatz von
Groupware
Filter
gen bessere Möglichkeiten, implizites Wissen
(tacit knowledge) und Best Practices unterneh-
mensweit verfügbar zu machen [McAfee 2006].
Wir haben im letzten Jahr zwei Projekte im
Wissens- und Innovationsmanagement beglei-
tet, die interessante Einsatzgebiete und Her-
ausforderungen von Wikis und Weblogs in Or-
ganisationen zeigen. Im Folgenden beschreiben
wir diese Projekte und die jeweiligen spezi-
fischen Erfahrungen sowie die Lessons Learned
und versuchen dabei allgemeine Gestaltungs-
empfehlungen aus den gewonnenen Erkennt-
nissen abzuleiten. Die Erfahrungen wurden
projektbegleitend erhoben und mit unseren
Beobachtungen als Systemverantwortliche er-
gänzt.
2 Wissens- und Innovations-
management im Spitzensport
2.1 Ausgangslage
Das Projekt »Wissens- und Innovationsmanage-
ment im Spitzensport« hatte zum Ziel, die Wis-
sensmanagement- und Wissenstransferabläufe
in einem deutschen Spitzensportverband zu
verbessern.
Die Situation in der Anwendungsdomäne stell-
te sich a priori wie folgt dar:
! Die Zusammenarbeit fand in einem Netz-
werk, bestehend aus Wissenschaftlern,
Trainern und wissenschaftlichen Partnern
(Mediziner, Techniker), statt.
! Diese arbeiteten in verschiedenen wissens-
intensiven Projekten organisationsübergrei-
fend zusammen.
! Unter den Projektbeteiligten befanden sich
viele Wissensträger und Ideenlieferanten mit
geringer Technikaffinität.
! Das Wissensmanagement lief nur über so-
genannte »Wissenschaftstrainer« ab.
Wunsch aller Projektpartner war es, mög-
lichst einfach Ideen und Informationen zu
einem gemeinsamen Wissensbestand beitra-
gen zu können. Einmal gewonnene Erkennt-
nisse sollten besser kommentierbar und dau-
erhaft dokumentiert verfügbar gemacht
werden.
Im Kick-off-Workshop wurde von den Pro-
jektteilnehmern die nachfolgende erste Ziel-
vision entwickelt, die den Projektkontext be-
schreibt:
Abb. 1: Social Software – aus dem World Wide Web ins Unternehmen

Wikis und Weblogs im Wissens- und Innovationsmanagement
HMD 267 49
»Das Ziel des Projekts ist die Entwicklung einer in-
formationstechnisch unterstützten, sozio-tech-
nischen Lösung,
! mit der unterschiedliche Arten von explizitem
und implizitem kontextualisiertem Wissen
verschiedener Akteure an die verschiedenen
Innovationsphasen angepasst qualifiziert or-
ganisiert werden,
! die in Eingabe und Ausgabe möglichst überall
intuitiv, nebenbei, ohne Strukturreferenz, indi-
viduell angepasst, freudvoll genutzt werden
kann,
! auf die unterschiedliche Nutzerkreise Zugriff
haben und die Kommunikation sowie an-
regendes Stöbern unterstützt,
! die zu anderweitig genutzten Systemen kom-
patibel ist, schnell genutzt werden kann und
auf dauerhafte Nutzung ausgelegt ist.«
Zur Lösung dieser Herausforderungen wurde als
technische Basis ein Wiki konzipiert – zusam-
men mit Volltextsuche über existierende Doku-
mente und Anhänge sowie Möglichkeiten zur
Integration in die Arbeitsumgebungen/-pro-
zesse der Beteiligten.
2.2 Erfahrungen
Durch die a priori bekannte geringe Technik-
affinität des späteren Nutzerkreises standen
von Anfang an die Vereinfachung der Platt-
form (»Abspecken«), Maßnahmen zur Motiva-
tionssteigerung und die Erleichterung der Be-
dienung im Vordergrund. Zudem wurde Wert
auf einen möglichst kollegialen und offenen
Umgang gelegt, um keine »Lücke« zwischen
Praktikern, Sportlern und Technikern entste-
hen zu lassen und gemeinschaftlich auf
Augenhöhe miteinander kommunizieren zu
können.
Beim Projekt-Kick-off wurde u. a. der Begriff
»freudvolle Nutzung« geprägt, der für den wei-
teren Verlauf des Projekts und insbesondere die
spätere Umsetzung der Plattform eine ent-
scheidende Rolle spielte. Unter freudvoll ver-
stehen wir in diesem Kontext alle Maßnahmen,
die ein IT-System über den Rahmen der »nor-
malen« Nutzerfreundlichkeit hinaus zu einem
Werkzeug machen, mit dem man gerne und
ohne die sonst häufig vorzufindende anfäng-
liche Frustration bei technischen Schwierig-
keiten arbeiten kann. Um dies zu gewähr-
leisten, wurden z. B. die Begrifflichkeiten im
Wiki möglichst einfach und oftmals bewusst
umgangssprachlich gehalten. Beispielsweise
entfernten wir uns gezielt vom sonst üblichen
Wiki-Jargon wie »Neue Seite anlegen« und
führten stattdessen Begriffe wie »ich weiß
was« für die gerade beschriebene Funktion oder
»was gibt es« für den Aufruf einer Übersichts-
seite ein.
Während der ersten Nutzung des früh be-
reitgestellten und iterativ weiterentwickelten
Prototyps wurde deutlich, dass aufgrund der
Heterogenität der Benutzergruppe verschie-
dene Navigationshilfen erforderlich waren. Dies
lässt sich darauf zurückführen, dass sich neben
dem Kenntnisstand bzw. der durch das Internet
unterschiedlich stark geprägten Erwartungs-
haltung der Benutzer auch die zu dokumentie-
renden Vorhaben und Projekte z.T. erheblich
unterscheiden.
Aus diesem Grund wurde neben einer aus
Dateisystemen bekannten hierarchischen Ord-
nerstruktur und einer klassischen Volltext-
suche auch eine tag- und kategorienbasierte
Strukturierungshilfe angeboten. Dabei wurden
die Kategorien (statisch) bereitgestellt, um ei-
nen ausreichenden Strukturierungsgrad zu ge-
währleisten, wohingegen Tags von den Nut-
zern annähernd beliebig vergeben werden
konnten. Dies erleichterte die inhaltliche und
strukturelle Zuordnung enorm, da die einge-
stellten projektspezifischen Wissensbausteine
sich ohne zusätzliche Hilfen nicht direkt in das
primär von Wikipedia oder klassischen Offline-
Nachschlagewerken geprägte Enzyklopädie-
denken einordnen ließen. Hinsichtlich der
Struktur der Tags stellten sich drei Schwer-
punkte als hilfreich heraus. Vergeben wurden
Tags

Wikis und Weblogs im Wissens- und Innovationsmanagement
50 HMD 267
! zu bestimmen Themen (wie z. B. »Aerodyna-
mik«),
! zur Beschreibung des Inhalts (wie z. B. »Er-
fahrung« oder »technisches Wissen«)
! und schließlich zu einzelnen Projektnamen
(wie z. B. »Orthese«).
Um Wildwuchs zu verhindern, wurde bereits
sehr früh im Projekt beschlossen, mehrere so-
genannte Wiki-Gärtner einzusetzen, deren Auf-
gabe u. a. darin bestand, die Vergabe von Tags
zu beobachten und diese ggf. kontinuierlich
anzupassen. Hierfür boten sich aufgrund ihres
umfassenden Kontextwissens besonders die
Wissenschaftstrainer an, auf deren Schultern
bereits bisher das Wissensmanagement lastete.
Unklar war zunächst, wie die Zugangsbe-
richtigung zu einzelnen vertraulichen Seiten
gehandhabt werden sollte. Um keine unnöti-
gen Nutzungsbarrieren aufzubauen, entschie-
den wir, dass Inhalte grundsätzlich für alle
Nutzer transparent zugänglich sein sollten.
Unvorhergesehen stellte sich die Eigen-
schaft »Webapplikation« des Wikis mit ihren
vielfältigen Vorteilen im Gegensatz zu klas-
sischen Desktop-Applikationen als enormer
Motivationsfaktor heraus. Von den Nutzern her-
vorgehoben wurde neben der Datensicherheit
(»einmal eingegeben für immer verfügbar«) vor
allem die Möglichkeit, sich mit Inhalten aus
Dokumenten noch einmal konkret auseinan-
derzusetzen. Dies ist darauf zurückzuführen,
dass die statische Struktur bestehender Text-
dokumente durch die thematische Trennung
und Verlinkung kleinerer Themenbereiche
bzw. Wissensbausteine aufgebrochen werden
musste und so während der Aufbereitung der
Inhalte für das Wiki bereits akzeptierte Wis-
senslücken geschlossen und Fehler beseitigt
werden konnten.
Erwartungsgemäß wurden Awareness-
Funktionen wie »letzte Änderungen« von den
Nutzern zunehmend gern verwendet, um »am
Ball zu bleiben«. Um neben der so geminder-
ten Konsumbarriere auch die technische Hürde
zur Bereitstellung von Inhalten möglichst ge-
ring zu halten, wurde den Nutzern weiterhin
die Möglichkeit gegeben, einzelne Wissens-
bausteine und Ergänzungen sowie bei Bedarf
auch ganze Seiten per E-Mail an das System zu
senden.
Als größte Barriere und folglich als stark
demotivierender Faktor stellten sich für den
Benutzer nicht transparente Funktionen oder
Reaktionen des Systems heraus. Zu nennen sind
in diesem Kontext insbesondere kleinere Bugs
des WYSIWYG-Editors. Hier war eine schnelle
Reaktion und Aufklärung vonseiten der Admi-
nistratoren notwendig und hilfreich. Nichtsdes-
totrotz spielte das »freudvolle« Editieren der
Wiki-Seiten eine zentrale und für die Adaption
des Wikis entscheidende Rolle. Extrem proble-
matisch war dabei die Tatsache, dass aktuell
weder webbasierte Open-Source- noch kom-
merzielle Editoren die Erwartungshaltung der
Nutzer hinsichtlich der aus Office-Programmen
bekannten Funktionalitäten vollständig erfül-
len konnten. Als Kompromisslösung wurde
schließlich eine stark angepasste Version des
Open-Source-Editors TinyMCE umgesetzt und
parallel dazu aktiv an der Erwartungshaltung
der Nutzer gearbeitet.
Bezüglich des Projektmanagements wurde
schnell klar, dass regelmäßige Präsenztreffen
zum Entwicklungsstand des Systems zur (Re-)
Motivation teilweise inaktiver Nutzer notwen-
dig waren. Die möglichst aktive Nutzung, d. h.
viele Inhalte möglichst vieler verschiedener
Nutzer, war insbesondere in den frühen Projekt-
phasen notwendig, um die verschiedenen Nut-
zungsszenarien erkennen und technisch unter-
stützen zu können. Vor diesem Hintergrund
stellte sich als besonders hilfreich heraus, dass
die Identifikation der Nutzungsszenarien nicht
losgelöst vom System, sondern »Hand in Hand«
mit der Nutzung eines frühen Prototyps er-
folgte.

Wikis und Weblogs im Wissens- und Innovationsmanagement
HMD 267 51
3 IT-Trends-Management
3.1 Ausgangslage
Das zweite Projekt beschäftigte sich mit der
soziotechnischen Unterstützung der Analyse
von aktuellen Trends beim Einsatz von IT-
Technologie. Ziel der Tätigkeit für eine welt-
weit agierende Organisation waren die Verbes-
serung der Dokumentation und Bewertung
identifizierter, innovativer Technologien sowie
die Förderung des Austausches über die ge-
wonnenen Ergebnisse innerhalb des Projekt-
teams.
Aufgrund der bisherigen mehrjährigen Er-
fahrungen hatte die Organisation folgenden
Prozess für das interne Trendmanagement ent-
wickelt: Jedes Jahr wurde zusammen mit ex-
ternen Experten eine Auswahl relevanter The-
men gesammelt, recherchiert, bewertet und
eventuell weiter vertieft. Ergebnisse dieser Be-
mühungen waren bislang eine Themenüber-
sicht und -bewertung in Form einer (Excel-)
Tabelle sowie verschiedene, unstrukturierte
Textdokumente mit vertiefenden Betrachtun-
gen, wie z. B. in der Form von Interviews.
Als besonders problematisch an diesem
Status quo stellte sich heraus, dass zu wenige
Personen beteiligt waren, folglich zu wenig
Input verfügbar war und so die Sichtbarkeit der
Projektergebnisse innerhalb der Organisation
nicht zufriedenstellend gewährleistet werden
konnte.
Aufgrund der gegebenen Rahmenbedin-
gungen wurde von uns als potenzielle Lösungs-
möglichkeit auch hier die Unterstützung der
Zusammenarbeit mithilfe eines Wikis, jedoch
diesmal in Kombination mit einem inte-
grierten Weblog, identifiziert. Der Integrations-
gedanke wurde aufgegriffen, um neben der
Dokumentation der Projektergebnisse auch die
projektbezogene Kommunikation über die
Plattform abwickeln zu können und so das
Zugehörigkeitsgefühl aller Beteiligten zu stär-
ken. Weiterhin versuchten wir durch gezielte
Erhöhung der Sichtbarkeit der aktiven Nutzer
einen zusätzlichen Beitrag zur Steigerung der
Motivation der Mitarbeiter zu liefern.
Im Gegensatz zum vorherigen Projekt ging
es bei den Inhalten nicht primär um unstruk-
turierte Wissensbausteine, sondern größten-
teils um semistrukturierte Information (The-
men mit Metainformation) sowie um die
Dokumentation von Recherchehistorien, Dis-
kussionen und Qualitätseinschätzungen. Auch
die Technikaffinität des Benutzerkreises war im
Vergleich zum vorherigen Projekt sowohl ho-
mogener als auch generell höher, wodurch sich
gänzlich andere Probleme und Herausforde-
rungen bei der Umsetzung ergaben.
3.2 Erfahrungen
Bezüglich der Anforderungen dieses Projektes
zeigte sich die Stärke des in beiden Projekten
verwendeten Open-Source-Wiki-Systems FOS-
Wiki (ehemals TWiki). Durch den modularen
und leicht erweiterbaren Aufbau des Systems
war es sehr einfach, semistrukturierte Inhalte
zu definieren und deren Struktur im evolutio-
nären Setupprozess immer wieder anzupassen.
Der gewünschte kombinierte und inte-
grierte Einsatz von Wiki und Weblog offenbarte
allerdings gleichzeitig einige Probleme. Zwar
konnten durch die Integration des Weblogs
Diskussionen im Projekt leichter gehandhabt
werden als im reinen Wiki-System. Durch das
Alternativangebot stellte sich jedoch bereits
sehr schnell die Frage, was denn wo gemacht
werden soll und wie Diskussionen im Weblog
eventuell an die Wiki-Seiten gelinkt werden
können (Medienwahlproblem). Auch die Frage
der Integrationsrichtung ist in diesem Zusam-
menhang noch nicht endgültig geklärt. Das
heißt, es stellt sich die Frage, ob primär Weblog-
Inhalte in das Wiki in Form von Diskussionshis-
torien zu einzelnen Topics integriert werden
sollen oder eher Inhalte von Wiki-Seiten direkt
in Weblog-Posts eingebunden werden sollen.
Durch die größere Bedeutung von struktu-
rierten Daten und die erforderliche Prozess-
unterstützung sowie die gewünschte Visuali-

Wikis und Weblogs im Wissens- und Innovationsmanagement
52 HMD 267
sier- und Exportierbarkeit der eingegebenen
Information wurde eine im Vergleich zum
ersten Projekt starre Struktur für Inhalte und
Seitenhierarchie vorgegeben. Alle Wiki-Seiten
zu recherchierten Themen wurden mit detail-
lierten Metainformationen ausgezeichnet, um
spätere maschinelle Auswertungen und semi-
automatische Visualisierungen zu vereinfa-
chen.
4 Lessons Learned
4.1 Zusammenfassung der
Rahmenbedingungen
In Tabelle 1 sind mehrere Charakteristika der
beiden Fallstudien zusammengefasst.
In beiden Projekten wurden Erfolgsfaktoren
und Barrieren sowie daraus resultierende Her-
ausforderungen an die Umsetzung der tech-
nischen Lösung identifiziert, auf die wir im Fol-
genden noch näher eingehen wollen.
4.2 Projektplanung/Vorgehen
Sowohl beim Wissens- und Innovations-
management im Spitzensport als auch bei der
Unterstützung des IT-Trends-Managements
sind wir iterativ vorgegangen, d. h., bereits nach
der ersten Orientierungsphase wurde auf Basis
von existierenden Werkzeugen ein erster Proto-
typ entwickelt, der direkt von den Benutzern im
Tagesgeschäft eingesetzt werden konnte. Im
Hinblick auf die Übertragbarkeit auf andere
Projekte steht und fällt dieses Vorgehen mit der
Bereitschaft der späteren Nutzer, von Anfang an
aktiv an der (Weiter-)Entwicklung des Prototyps
mitzuarbeiten. Wie sich bei der Plattform für
den Spitzensportverband zeigte, kann hierzu
ein »freudvoller« Projekt-Kick-off, bei dem eine
gemeinsame Zielvision erarbeitet wird, hinter
der alle Projektpartner stehen, einen entschei-
denden Beitrag zur Benutzermotivation leisten.
Der Erfolg eines Wiki-basierten Systems hängt
weiterhin in starkem Maße von der kontinuier-
lichen Partizipation seiner Nutzer ab. Diese
nimmt unserer Projekterfahrung nach vor allem
in den frühen Phasen der Entwicklung schnell
ab, sofern für die Benutzer kein direkter Mehr-
wert oder ausreichende Aktivität im Projekt
sichtbar ist. In diesem Zusammenhang stellen
zeitnahe Treffen der gesamten Projektgruppe
zur Schaffung von Gewahrsein über die Aktivi-
täten der anderen Beteiligten einen entschei-
denden weiteren Erfolgsfaktor bei der Projekt-
planung dar.
4.3 Funktionsbedarf
In beiden Projekten wurde mit einer ähnlichen
Wiki-Installation begonnen. Zusätzlich wurde
im IT-Trends-Management-Projekt, wie oben
beschrieben, eine Weblog-Plattform integriert.
Entsprechend den verschiedenen Vorausset-
zungen und der unterschiedlich ausgeprägten
Technikaffinität der Benutzer entwickelten sich
die gewünschte Funktionalität sowie die daraus
resultierenden notwendigen Änderungen an
der ursprünglichen Plattform aber ungleich.
Charakteristikum Spitzensport IT-Trends-Management
Technische Lösung Wiki Wiki mit integriertem Weblog
Technikaffinität gering mittel/hoch
Wichtigster Aspekt freudvolle Nutzung Struktur/Übersichtlichkeit
Strukturierungsgrad unstrukturierte Wissensbausteine strukturierte Rechercheergebnisse mit
Metadaten
Motivationsfaktor kontinuierliche Treffen Sichtbarkeit von Aktivitäten und Aktivisten
Größte technische
Herausforderung
Rich-Text-Editor Integration (Wiki/Weblog)
Tab. 1: Besonderheiten der Projekte im Überblick

Wikis und Weblogs im Wissens- und Innovationsmanagement
HMD 267 53
Eine entscheidende Erkenntnis aus beiden Pro-
jekten hinsichtlich des verwendeten techni-
schen Systems war somit, dass die eingesetzte
Plattform ein breites Spektrum an Erweite-
rungs-/Anpassungsmöglichkeiten bieten muss.
Nur so kann in einer derartigen (iterativen) Vor-
gehensweise schnell und einfach auf Ände-
rungs- oder Verbesserungswünsche reagiert
werden, und im Sinne einer freudvollen Nut-
zung entsteht keine unnötige Frustration.
Wie sich während der Entwicklung in bei-
den Projekten zeigte, war neben Wiki und
Weblog auch eine Art Personenverzeichnis von
Bedeutung, um ausreichenden Bezug der ein-
gestellten Inhalte zu den jeweiligen Inhalts-
gebern herzustellen. Durch dieses Vorgehen
wird eine bessere Identifikation mit der verfüg-
bar gemachten Information gewährleistet. In
unserem Fall haben wir jeweils eine einfache
Lösung im Wiki realisiert. Zusätzlich wurde zu
jeder Wiki-Seite eine gut sichtbare Liste aller Be-
arbeiter angezeigt, um neben ausreichender
Sichtbarkeit vor allem entstehende Wertschät-
zung für die Beitragenden sicherzustellen.
Eine wichtige Erkenntnis in diesem Zusam-
menhang ist die Präsentationsform der benut-
zerspezifischen Informationen. Sobald Beitra-
gende nicht nur über ihre Benutzernamen, son-
dern zusätzlich mit Assoziationen weckenden
Bildern dargestellt wurden, konnte eine gestei-
gerte Bereitschaft zum Einstellen von Inhalten
beobachtet werden. Hier sind jedoch auf jeden
Fall noch weiterführende Untersuchungen er-
forderlich, um konkrete Handlungsempfeh-
lungen für das optische Erscheinungsbild und
die Platzierung von personenbezogenen Infor-
mationen abzuleiten.
Darüber hinaus ergaben sich im Laufe der
iterativen Anpassung sehr unterschiedliche
Entwicklungen bei den Funktionswünschen.
Diese reichten von Videointegration über Litera-
turverzeichnisse bis zu automatisch erstellten
schematischen Darstellungen der Chronologie
bzw. Zusammenhänge der eingestellten In-
halte. Aufgrund der Modularität der gewählten
Open-Source-Plattform konnten wir bisher alle
Wünsche mit (eventuell leicht angepassten)
existierenden Plug-ins befriedigen, was einen
entscheidenden Vorteil hinsichtlich des Zeitauf-
wands bei der Umsetzung im Gegensatz zu ge-
schlossenen Systemen darstellt.
4.4 Aktivität der Projektteilnehmer
Ein iterativer, partizipativer Einführungspro-
zess erfordert, wie oben geschildert, ausrei-
chende Beteiligung der Nutzer. Diesbezüglich
lassen sich zwei wichtige Erkenntnisse aus den
genannten Projekten festhalten:
Erstens ist vonseiten der Projektleitung im-
mer wieder ein »Anschieben« erforderlich, z. B.
in Form von Workshops, Umfragen per E-Mail
oder im Weblog. Denn obwohl einfache Mög-
lichkeiten zur Generierung von Feedback vor-
handen waren, wurden diese nur wenig ge-
nutzt. Erst bei aktivem Nachfragen kamen neue
Wünsche und Ideen.
Auch bei nicht technikaffinen Benutzern
zeigte sich, dass Wünsche zu neuen Möglich-
keiten meist funktionalitätszentriert formu-
liert wurden – »wir brauchen diese neue Funk-
tion« – und weniger bezüglich dessen, was er-
reicht werden soll. Hier wurde es immer wieder
erforderlich zu hinterfragen, wofür denn diese
neue Funktion genau benötigt würde, um ggf.
Alternativvorschläge hinsichtlich der konkreten
Umsetzung machen zu können.
4.5 Usability
In beiden Projekten sind wir mit einer leicht
angepassten Out-of-the-Box-Installation der
Werkzeuge gestartet. Die erste Aktivität im
iterativen Verbesserungsprozess war jeweils
eine Vereinfachung der Benutzungsschnittstel-
le. Vor allem das Weglassen von nicht oder nur
selten benötigten Funktionen und das An-
passen der üblicherweise verwendeten, stark
anglizistischen Begriffswelt an die jeweiligen
Projektspezifika leisteten hierbei einen ent-
scheidenden Beitrag zur Ermöglichung freud-
voller Nutzung.

Wikis und Weblogs im Wissens- und Innovationsmanagement
54 HMD 267
Im IT-Trends-Management-Projekt konnte
dank eines ausreichend technikaffinen Benut-
zerkreises und der Verwendung von zusätz-
lichen Eingabeformularen für strukturierte
Informationen von vornherein auf die Bereit-
stellung eines WYSIWYG-Editors verzichtet wer-
den. Dies wurde vor allem dadurch unterstützt,
dass die erfahrenen Benutzer schnell er-
kannten, wie einfach bestimmte Dinge mithilfe
der Wiki-Sprache realisierbar waren und wie
problemlos sie durch die einblendbare Hilfe zur
Wiki-Sprache direkt über dem Editierfenster
erlernt werden konnten.
4.6 Oberfläche/Struktur/Navigation
Die verschiedenen Funktionen – hauptsächlich
drei: Wiki, Weblog, Personen – sollten natür-
lich mit demselben »Look & Feel« zugänglich
sein. Obwohl die Werkzeuge (Wordpress und
FOSWiki) hier sehr unterschiedliche Ansätze
verfolgen, stellte dies aufgrund der durchgän-
gigen Verwendung von Cascading Style Sheets
kein großes Problem dar.
Wesentlich schwieriger war hingegen die
Anpassung der Navigation sowie insbesondere
des Hinweises der Nutzer darauf, wo sie sich
aktuell innerhalb der Seitenstruktur befanden
und was an dieser Stelle erwartet wurde. Hin-
sichtlich der Medienwahlproblematik liefert die
Faustregel »Ankündigungen und Diskussionen
(Kommunikation) im Weblog, Dokumentation
und Informationssammlung im Wiki« einen
vielversprechenden Lösungsansatz, der jedoch
stark vom Integrationsgrad der beiden Systeme
abhängig war, um redundante Inhalte von
Anfang an zu vermeiden.
Je nach Strukturierungsgrad und ge-
wünschter »Gängelung« der Benutzer beim
Anlegen neuer Inhalte unterschied sich der
sinnvolle Grad an zur Verfügung gestellten
Strukturierungshilfen stark. Für beide Projekte
war entscheidend, dass die Benutzer sich in
ausreichendem Maße mit der bereitgestellten
Struktur zurechtfanden und nicht auf einer
gänzlich »grünen Wiese« starten mussten.
Sowohl die im System für den Spitzensportver-
band integrierte tag- und kategorienbasierte
Strukturierungshilfe als auch die Strukturier-
barkeit über zusätzliche detaillierte Meta-
information aus dem IT-Trends-Management-
Projekt leisteten einen entscheidenden Beitrag
dazu, das durch Enzyklopädien geprägte alpha-
betische Regaldenken zu überwinden und auch
projektspezifische Inhalte bzw. Wissensbau-
steine bei gleichzeitiger Sicherstellung der Wie-
derauffindbarkeit gezielt und wohlstrukturiert
aufzubereiten.
4.7 Nutzungsorientierte Dokumentation
Wie schon angesprochen haben wir im Rahmen
der iterativen Anpassung an verschiedenen
Stellen die Optionen der verwendeten Systeme
reduziert und durch klare Dokumentation,
was wo wie gemacht werden soll, ersetzt. Eine
nutzenorientierte Dokumentation stellte sich
in diesem Zusammenhang als besonders wich-
tiger Teil der Plattform heraus. Von Bedeutung
ist hier vor allem, dass Benutzer aus der Vorge-
hensbeschreibung den Mehrwert der Platt-
form für ihren eigenen Arbeitsprozess erken-
nen können und so keine direkte Konkurrenz
mit bestehenden Anwendungen entsteht, die
das Medienwahlproblem weiter verstärken
würde. Vielmehr muss die Dokumentation den
Nutzen der gemeinschaftlich identifizierten
und von der Plattform unterstützten poten-
ziellen Nutzungsszenarien klar und intuitiv ver-
deutlichen.
5 Zentrale Erkenntnisse
und Handlungsempfehlungen
Die wichtigsten Erkenntnisse aus den be-
schriebenen Projekten stellen sich wie folgt
dar:
! Im Portfolio verfügbarer Open-Source-Soft-
ware finden sich Systeme, mit denen sich
relativ einfach integrierte Social-Software-
Lösungen zum Einsatz in Unternehmen und
Projekten erstellen lassen.

Wikis und Weblogs im Wissens- und Innovationsmanagement
HMD 267 55
! Bei der Umsetzung ist es von Bedeutung,
dass man »Raum« für iterative Anpassung
lässt (und diesen auch einplant).
! Diesen Raum für iterative Anpassung findet
man viel leichter bei der Kombination mehre-
rer jeweils speziell für ihre Aufgabe zuge-
schnittener Systeme (z. B. ein separates Wiki
und ein separates Weblog-System) als bei
integrierten Systemen.
! Es ist nicht sinnvoll, alle Anforderungen tech-
nisch zu lösen, sondern teilweise ist auch an
der Erwartungshaltung der Benutzer bzw. an
den sozialen Protokollen zu arbeiten.
! Dabei ist ein iterativer Entwicklungs- und Ein-
führungsprozess zu empfehlen.
! Im Einführungsprozess wird es Phasen ge-
ben, in denen das System noch keinen direk-
ten klaren Nutzen für die Zielgruppe hat. Dies
muss durch Aktivität der Projektleitung über-
brückt werden.
! Generell sollte darauf geachtet werden, mög-
lichst früh im Projekt den direkten Nutzen
erkennbar zu machen und entsprechend an
alle Beteiligten zu kommunizieren (z. B. über
eine nutzenorientierte Dokumentation).
Natürlich kann die Vorstellung und Diskussion
der beiden Beispiele in diesem Beitrag nur ein
Schlaglicht auf den Themenbereich werfen.
Trotzdem bestätigt und veranschaulicht die
Betrachtung viele allgemeine Aussagen und
Empfehlungen, die in der Vergangenheit im Zu-
sammenhang mit der Einführung von Social
Software in Unternehmen diskutiert wurden.
6 Literatur
[Back et al. 2008] Back, A.; Gronau, N.; Tochter-
mann, K.: Web 2.0 in der Unternehmenspraxis.
Grundlagen, Fallstudien und Trends zum Ein-
satz von Social Software. Oldenbourg, Mün-
chen, 2008.
[Koch & Richter 2008] Koch, M.; Richter, A.: Enter-
prise 2.0 – Planung, Einführung und erfolg-
reicher Einsatz von Social Software in Unter-
nehmen. Oldenbourg, München, 2008.
[McAfee 2006] McAfee, A.: Enterprise 2.0 – The
Dawn of Emergent Collaboration. In: MIT Slo-
an Management Review, 47. Jg., 2006, Heft 3,
S. 21-28.
[Richter & Koch 2008] Richter, A.; Koch, M.: The en-
terprise 2.0 story in Germany so far. In: Work-
shop »What to expect from Enterprise 3.0:
Adapting Web 2.0 to Corporate Reality« held in
conjunction with CSCW 2008, http://swiki.cs.
colorado.edu/CSCW2008-Web20/uploads/richter
koch-enterprise2.0_final.pdf; Zugriff am 20.01.
2009.
Prof. Dr. Michael Koch
Dipl.-Kfm. Dipl.-Inf. Florian Ott MSc
Dipl.-Kfm. Alexander Richter
Universität der Bundeswehr München
Fakultät für Informatik
Werner-Heisenberg-Weg 39
85577 Neubiberg
{michael.koch, florian.ott, a.richter}@unibw.de
www.kooperationssysteme.de