Wikis werden mitlerweile in zunehmendem Maße als Werkzeug zum Wissensmanagement auch in Unternehmen eingesetzt. Ihre Stärken spielen sie vor allem in (fachlichen) Interessensgemeinschaften, Arbeitskreisen, Expertennetzwerken, Projektteams etc. aus.

In den USA ist der Einsatz von Wikis in Unternehmen bereits wesentlich verbreiteter als hierzulande. Dort haben sich bereits einige Firmen auf solche Systeme spezialisiert. Zu den Anbietern in diesem Bereich zählen z.B. Socialtext (http://www.socialtext.com) und Attlassian (Confluence).

Vor- und Nachteile

Bearbeiten

Vorteile

Bearbeiten
  • Jeder kann sofort in einem Intranet einen Beitrag veröffentlichen.
  • Die Beiträge können inhaltlich genau zugeordnet werden und sind nicht wie in Diskussionsforen rein chronologisch angeordnet.
  • Die Beiträge können relativ einfach optisch gestaltet werden.
  • Links zu externen Beiträgen und Begriffsdefinitionen (z.B. von Wikipedia) können einfach eingebunden werden.
  • Es wird neben dem Wikiserver und dem Browser keine Zusatzsoftware benötigt. Damit ist die Bedienung der Wikis plattformunabhängig!
  • Der Einsatz von Wiki Software ist kostengünstig und schont die IT-Abteilung (Installation, Wartung, Support, etc. dürfen nicht außer Acht gelassen werden)
  • Die geringen Gesamtkosten (TCO - Total Cost of Ownership) erlauben es, dass auch wirklich jeder, der Zugang zu einem Computer hat, das Wiki nutzen und pflegen kann. Nicht jedes Unternehmen spendiert jedem Sachbearbeiter/Mechaniker einen SAP-Account:-) und häufig entstehen "unten" im direkten Kontakt mit dem Kunde/dem Projekt wichtige Informationen.
  • Sehr gut geeignet für kleinere Unternehmen mit mehr als einem Firmensitz
  • Im Vergleich zu ähnlichen Ansätzen wie Groupware a la Lotus-Teamroom kann man die Dokumente nach wirklich beliebigen Kriterien organisieren. Man ist nicht an feste Orgastrukturen gebunden.
  • Ist das Wikikonzept eingeführt, können Wikis (auch projektbezogen) schnell eröffnet (und wieder geschlossen) werden.
  • Die Verwaltung des Wiki-Inhalts wird direkt von den Benutzern übernommen. Damit ist die Chance groß, dass der Inhalt auch gebraucht wird und aktuell bleibt.
  • Da die Struktur nicht festgelegt ist, kann sich das Wiki organisch mit den Bedürfnissen mitentwickeln. Ggf. entstehen mehrere parallele Wikis.
  • Häufig kann der Inhalt des Wikis in statisches Html konvertiert werden. Damit kann es auf CD oder USB-Stick auch "offline und read-only" gute Dienste leisten (z.B. als Informationssystem).
  • Wikis als immer aktuelles "Pull-Medium" können den E-Mail-Verkehr deutlich einschränken und reduzieren damit die Zeit, die vor dem Mailprogramm verbracht werden muss.
  • Bei "echten" Datenbanken muss die Struktur des Inhalts vorher bekannt sein. Eine kreative Wissensbasis ist damit kaum realisierbar. Im Wiki kann nicht nur der Inhalt selbst, sondern auch der Blick auf den Inhalt frei gestaltet werden. Es können alphabetische Listen, thematische Kataloge oder Seiten mit persönlichen Portalen erstellt werden. Die "Perspektive" auf ein Wiki ist in weiten Grenzen anpassbar.

Mögliche Barrieren

Bearbeiten
  • Jeder kann alles ändern - führt das nicht bald zum totalen Chaos? Erfahrungsgemäss nicht, denn unerwünschte oder falsche Änderungen sind mit ein paar Mausklicks wieder rückgängig gemacht.
  • Akzeptanz einer weiteren, zusätzlichen Kommunikationstechnologie, neben den vielen bereits Bestehenden?
  • Bereitschaft, eine neue, wenn auch einfache Syntax zu erlernen?
  • Firmen mit streng hierarchischen Strukturen haben mit breiten demokratischen Ansätzen Probleme. Wenn Entscheidungen nur von oben kommen, hat es Wiki schwer.
  • Es ist zeitintensiv bei einem größeren Datenbankaufwand auf dem laufenden zu bleiben. Das gilt nur, wenn nur wenige den Inhalt pflegen.
  • (je nach verwendeter Wikisoftware) fehlende Zugangskontrollen
  • Es besteht die "Gefahr", dass Dokumentationen im Wiki-Format entstehen, die die höheren Mächte lieber im Microsoft-Word-Format hätten (kein Witz!).

Erfahrungsberichte

Bearbeiten

Nichts stirbt so schnell wie ein Gemeinschaftprojekt, für das sich niemand richtig zuständig fühlt. Genau das hab' ich bei meinen Wikis auch erlebt: Die meiste Zeit schreibe ich alleine und die anderen lesen nur, aber ab und zu gibt's ein Thema, bei dem sich die Leute einschalten, weil es sie bewegt. Na, zugegeben, ich habe einen unschätzbaren Vorteil: Mittels CVS kann ich die Wikis vom Firmen-Server auf mein Notebook synchronisieren und auf Reisen und Sitzungen mitnehmen (anders als bei Wikipedia liegen im SWA-Wiki die Texte in Dateien statt in einer Datenbank). Wegen der Firewalls funktioniert das aber nur bei mir in München; die anderen Standorte können nur on-line arbeiten.

Wikis leben davon, dass die Leute einen Nutzen darin sehen, etwas rein zu stellen. Das ist genau so wie bei den berühmt-berüchtigten Wissensmanagement Projekten. Ich schätze, dass auf ein funktionierendes KM-Projekt mehrere Dutzend kommen, die an der allgemeinen Lethargie verkümmert sind.

In den Teams, die das Wiki für sich akzeptiert haben, lief es auch so: Zuerst gab es eine einzelne Person, die sich gesagt hat: "Das will ich auch haben! So was hab' ich immer schon gesucht. Jetzt muss ich die Info, die täglich so 'rumschwirrt, nicht mehr an tausend Stellen suchen; ich schreib' sie ins Wiki und dann weiß ich, wo ich's wieder finde." Eigentlich schreibt jeder nur das rein, was er selbst später wieder lesen will. Dass andere daran partizipieren, ist nur ein schöner Nebeneffekt.

Der nächste Schritt ist dann, dass eine führende Person im Team (Projektleiter, Bereichsleiter, etc.) entdeckt, was da läuft und sich sagt: "Ist ja toll; das gefällt mir; das sollten alle so machen." Dann kommt die Ansage: "Bitte stellt in Zukunft alle Infos in unser Wiki. Das funktioniert besser als E-Mail-Ordner, Dateiablagen und sonstiger Kram." Zu diesem Zeitpunkt sollte aber schon genügend Material da sein, um die Zweifler zu überzeugen.

Und es muss auf Anhieb funktionieren! Es muss eine kompetente Ansprechperson da sein, die den Leuten bei Schwierigkeiten schnell und freundlich aus der Patsche hilft oder technische Probleme aus dem Weg räumt. Heutzutage liest auch niemand mehr Programm-Dokumentation - ich ja auch nicht. Also: Entweder es funktioniert intuitiv oder es ist Schrott.

Beim Wiki ist die größte Hürde, dass es nicht WYSIWYG ist. So schlimm ist die Syntax ja wirklich nicht, und trotzdem muss sich jeder überwinden, mit ganz wenigen Ausnahmen. Techniker, die sich auch sonst viel mit kryptischem Programmtext 'rumschlagen, sind da zugänglicher; bei den anderen muss am Anfang jemand "Händchen halten."

Wann hat man's geschafft? - Wenn die Leute denken: "Wenn ich was suche, schau ich zuerst mal ins Wiki." Und es sollte klare Zuständigkeiten für die zentralen Einstiegspunkte geben (Titelseite, Tagesplan, Wochenplan, Ansprechpartner, laufende Aktivitäten, Termine, TODOs, und was sich sonst noch so 'rauskristallisiert). Manche Seiten müssen tages-aktuell gehalten werden; andere sind zeitlos.

In unseren Formatvorlagen für neue "leere" Seiten haben wir einige Standard-Zeilen eingebaut (hier in Mediawiki-Syntax):

----
'''Verwandte Seiten:''' [[Nicht Klassifiziert]]
<br>
'''Ansprechpartner für diese Seite:''' ~~~~
----

Damit hat jede Seite schon mal einen zuständigen Ansprechpartner, dieser kann auf seiner persönlichen Benutzerseite über die "Links auf diese Seite" sehen, wofür er zuständig ist, usw. Das [[Nicht Klassifiziert]] sollte man natürlich durch eine oder mehrere sinnvolle Kategorie ersetzen, denen man das neue Thema zuordnen will.

Übrigens werden im SWA-Wiki die "Links auf diese Seite" ebenfalls automatisch am Seitenende eingefügt - spart einen Klick und zeigt den unerfahrenen Benutzern sofort, dass es da was gibt.

--swa 22:01, 13. Mär 2004 (CET)

WEB.DE, Karlsruhe-Durlach

Bearbeiten

Bei WEB.DE hat sich das Wiki-Konzept im Bereich der IT schon seit über drei Jahren etabliert. Sämtliche Informationen, Linksammlungen, Interface-Beschreibungen, aber auch HowTos, Dokumentationen etc. werden im Wiki gehalten und da sich jeder Mitarbeiter von Anfang mit dem Wiki befasst, ist es auch zur Selbstverständlichkeit geworden. Lediglich bei der Strukturierung ("Was wo hin?") hapert es meiner Meinung nach manchmal etwas.

Die Jugendbildungsstätte nutzt mit Beginn des Jahres 2006 nach einer kleinen Probephase Wiki als Intranet-Datenbank zur Qualitätssicherung und Dokumentation. Das vielschichtige Team aus hauptamtlichen Referenten, Honorarkräften und Praktikanten braucht einen adäquaten Zugang zu den Ressourcen an Themen, Methoden und Organisation. Durch Portale, Kategorien, interne wie externe Links ist dabei Wiki jeder herkömmlichen Qualitätssicherungs- und Dokumentationsmethode, sei es manuell oder auf Computer, in jeder Hinsicht überlegen. Was dringend benötigt würde, wären allerdings optimierte Konvertierprogramme bzw. -macros für Word-Dateien zum unkomplizierten Import von bereits früher im doc-Format erstellten Dateien, insbesondere auch im Blick auf in den Text integrierte Tabellen. - Helmut Zenz 03:01, 6. Jan 2006 (CET)

Bearbeiten

Whikihosting z.B. http://www.seedwiki.com , http://wikihost.org , http://pbwiki.com ...

Literatur

Bearbeiten
  • Anja Ebersbach, Markus Glaser und Richard Heigl: WikiTools. Kooperation im Web, Springer 2005, ISBN 3-540-22939-6
  • Christoph Lange (Hrsg.): Wiki - Planen, Einrichten, Verwalten, Computer- und Literaturverlag 2005, ISBN 3-936546-28-2
  • Andres Streiff: Wiki - Zusammenarbeit im Netz, BoD 2005, ISBN 3-83342641-1

Presseartikel und Papers

Bearbeiten
  • Jan-Paul Köster: Wikis bündeln das Mitarbeiterwissen. 14.10.2005 [1]
  • Wikis finden den Weg ins Unternehmen. 12.01.2006 [2]
  • Oliver Gassner: Wikis ersetzen konfuse Mail-Ströme. 7.4.2005 [3]
  • Michael Pietroforte: Digitales Vergessen am Beispiel eines Artikels von Michael Pietroforte. Wie Online-Presseartikel im Nirvana verschwinden. (Kommentare siehe [4])
  • Neue Wege. Wie Sie TWiki im Unternehmen einführen und eine neue Kommunikationskultur schaffen
  • Michael John, Stephan Schmidt, Björn Decker: Community-Management in Unternehmen mit Wiki- und Weblogtechnologien. In: Meißner, Klaus Engelien: Virtuelle Organisation und Neue Medien 2005 (Proceedings zum Workshop GeNeMe, TU Dresden, 6./7.10.2005)
  • Ezra Goodnoe: Wikis at Work. 3.2.2006 [5]