Wikis in Unternehmen - Fluc...

Ich habe bisher Wikis in zwei Unternehmen gesehen. Die Entwicklung der beiden Wikis verlief komplett diametral. Bei der einen Firma wurde das Wiki immer mehr und mehr mit Leben gefüllt und jeder Entwickler hat seinen Teil dazu beigetragen. Bei dem anderen Unternehmen war das Wissen, welches verteilt hätte werden müssen, sowieso schon nur auf wenige Personen verteilt und diese haben das Wiki fast vollständig ignoriert, so dass es lediglich ein Randdasein fristete und es auch nicht bemerkt wurde, wenn es mal 3 Wochen nicht lief.

Contra

1. Wiki Syntax als Akzeptanz Problem. Das ist in der Tat ein Problem, gerade wenn es um etwas übersichtlichere Formatierung von Daten (z.B. in Tabellen) geht. Wer hier will, dass sämtliche Mitarbeiter den Umgang mit dem Wiki erlernen, muss hier wenigstens mal eine Einführung geben. Interessanterweise habe ich dieses Problem auch schon von reinen Softwareentwicklern gehört - denen es aber auch lieber war, sämtliche Dokumentation als Word Datei zu pflegen, um den kollaborativen Gedanken im Keim zu ersticken. Dieses Problem weitet sich allerdings auch noch weiter aus, wenn man von der einfachen Syntax eines mediaWiki zu etwas komplexeren Tools wie Twiki wechselt.
2. Kategorisierung und Hierarchiesierung. Kategorisierung lässt sich inzwischen bei einigen Wikis nachrüsten, dafür müsste allerdings ein sinnvolles Tagging stattfinden. Bei einem der Unternehmen stand nach der Installation des Wikis auf einmal die Frage nach einer Hierarchie auf dem Programm. Das genau ist ja nicht Sinn eines Wikis in meinen Augen. Es geht um die Bereitstellung von Wissen, welches in meinen Augen auch nicht zwingend priorisiert werden muss, weil diese Priorisierung pro Person sehr unterschiedlich sein kann (Techniker vs. Vertriebler). Daher ist auch sehr schwer Suchergebnisse zu priorisieren.
3. Rechtemanagement. Kurz gesagt: Ein großes Problem sowohl organisatorisch als auch in der Praxis aufgrund der Komplexität. mediaWiki besitzt gar kein ACL System (zumindest ist es nicht aktiviert). Vor allem, wenn dann noch die Idee vorherrscht, dass auch Kunden in das Wiki schauen können sollen. IMO ein absolutes "No". ACLs, gerade wenn der Autor der Seite diese auch noch selber managen müsste, würden früher oder später in die Hose gehen. Wie man dieses Problem löst, außer mit einem zweiten Wiki für Kunden, weiß ich allerdings auch nicht wirklich.
4. Pflege. Im Artikel steht, dass so ein Wiki nach 1 bis 2 Jahren Pflege benötigt. Ich glaube, dass muss sehr viel früher geschehen, damit die Akzeptanz für dieses System nicht nachlässt.
5. Wikis sind projektbezogen. Das sehe ich komplett anders. In meinen beiden Beispielen wurden Wikis eher als Ersatz für die bis dato fehlende Dokumentation des Systems oder für entwicklerinterne Dokumentation verwandt. Und genau da spielt ein Wiki auch seine Stärken aus, weil es sich der starken Veränderung einer Softwareentwicklung schnell anpassen kann.
6. Das Wiki wird als Ersatz für alle andere verwendet. Sei es für Linksammlungen (social bookmarking), als Bugtracker, oder nur um Seiten zu erstellen, an die man dann ein Handbuch attached anstatt ein DMS für soetwas zu verwenden. Genau das wird die Akzeptanz stark senken.
7. Datenexport. Lässt sich eine Seite formschön als PDF exportieren, so dass man diese einem Kunden in die Hand drücken könnte, oder muss man dafür ein weiteres Dokument anlegen? Oftmals ist das letztere der Fall und verdoppelt in diesem Fall die Arbeit.
8. Initiale Datenpflege. Hier liegt in meinen Augen eines der größten Akzeptanzprobleme. In ein leeres Wiki wird nicht gern geschrieben. Was also kann man tun, damit die User anfangen, das Wiki mit Leben zu füllen? Anreizsysteme? Wer Vorschläge hat, raus damit. Bei kleineren Unternehmen kann man ja direkt zu den Leuten gehen, das funktioniert in größeren Unternehmen ja leider nicht mehr.

Pro

1. Wiki als Ersatz für CMS. Ein CMS ist oftmals am Ziel vorbeigeschossen, wenn man bestimme Informationen einer Gruppe von Menschen innerhalb eines Unternehmens anbieten will.
2. Know-How-Sicherung in Unternehmen. Jeder Mitarbeiter hat Zugriff auf Wissen, auch wenn der Mitarbeiter nicht mehr im Unternehmen ist. Das benötigt natürlich das Einsehen des Mitarbeiters, dass Wissen nicht gehortet werden darf. Das ist das eigentliche Problem, welches sich nicht technisch lösen lässt.
3. Unterstützung von Innovationsmanagement. Ganz klar, eine Art virtuelles Brainstorming, ohne dass man zu einem bestimmten Zeitpunkt kreativ sein muss. Allerdings habe ich noch nich ein Wiki in einer Firma auf diese Art genutzt gesehen.
4. Für Softwareentwickler: Integration mit Ticket- und SCM Systemen. Tools wie trac (die sich ja inzwischen sogar via Mylyn in Eclipse integrieren lassen) spielen hier ihren größten Trumpf auf. Das ist nur ein Teil eines Softwareprojektes, und alle anderen benötigten Dinge gibt es ebenso anbei. Hier spielt das Bundle seine Stärke aus, da aufgrund des reinen Vorhandenseins aller Tools schon ein gewisses Maß an Zuständigkeiten selbst erklärt ist.

Also, seht zu, dass ihr alle Wikis in eure Unternehmen packt.

Update: Es hat sich zu diesem Thema vor allem abseits meines Eintrags eine interessante Diskussionskultur entwickelt. Bei Frogpond sowie Johannes Miskaliuk gibt es neuen Input sowie eine Zusammenfassung bei Kooptech. Danke für die Kommentare.