Wiki – Gegenargumente und Gegengegenargumente

KoopTech hat eine Liste von Wiki-Gegenargumenten vorgestellt. Nicht alles davon ist stichhaltig. Manche Punkte benötigen schon einer Relativierung – oder auch direktem Widerspruch. Aber ich will nicht überkritisch sein, denn Kooptech hat ja auch 10 Gründe für den Wiki-Einsatz gefunden.

Johannes Moskaliuk hat die 8 Gegenargumente analysiert – unterteilt in funktionale und psychosoziale “Lösungsmöglichkeiten”. Gefällt mir sehr, und ja, es geht hier nicht um absolute “Wahrheiten” sondern mehr um Gefühle, Einschätzungen und eben auch alternative Umsetzungs- und “Lösungsmöglichkeiten”. Also erweitere und kommentiere ich Johannes’ Ideen aus meiner Sicht:

1. Die krude Wiki-Syntax ist oftmals ein Akzeptanzproblem.

Psychosozial: Neue Software erfordert neue Kompetenzen. Ohne Schulung der Mitarbeiter, Supportfunktion und eine Beteiligung der Nutzer bei der Entscheidungsfindung geht es auch im Wikizeitalter nicht.

Funktional: Mit dem Einsatz eines WYSIWYG-Editors ist das Problem lösbar. Technisch möglich ist auch die weitergehende Integration ins Betriebssytem, wie z.B. beim TWiki mit dem Kupu-Add-on (Linux) oder beim der Confluence-Software mit MS Office (Microsoft).

Zum einen: WYSIWYG-Editoren sind kein Allheilmittel und weisen nach jetzigem Stand der Technik auch gewichtige Nachteile auf. Es ist kein Zufall dass Enterprise Wikis wie Socialtext beide Editor-Alternativen parallel anbieten. Eine ausführlichere Analyse von Pro und Contra findet sich hier (“Simplicity, adoption and WYSIWYG editors”).

Zum anderen: Eine Einschätzung als krude Syntax (sic!) gilt nicht für jeden Markup-Dialekt, man vergleiche einmal die Auszeichnungsalternativen von bspw. Mediawiki für kursiv und bold (” und ”’, bold und kursiv sieht dann so aus: '''''fett und kursiv''''' – eingängig nicht wahr?) mit denen von Wikicreole, an die sich u.a. DokuWiki anlehnt.

Aber die eigentliche Aufgabe liegt natürlich im Bereich “psychosoziale Akzeptanz”, und es ist zweifellos richtig, dass Markup ein Akzeptanzproblem hat. Letztlich gilt das für alle Werkzeuge, die nicht wie Word aussehen (interessanterweise werden manche andere Werkzeuge und Systeme nicht so stark hinterfragt was Usability und Akzeptanz angeht, sie werden Mitarbeitern aufgezwungen und diese müssen damit mit SAP R/3 arbeiten – auch wenn die Usability bescheiden ist). Pragmatisch gesehen liegt die Antwort daher meist in einem “sowohl als auch”, in Verbindung mit einer gewissenhaften Analyse von Anforderungen und Zielgruppen, die Frage ob WYSIWYG sein muss, sollte dabei ergebnisoffen und vorurteilsfrei angegangen werden.

2. Kategorien und Hierarchien lassen sich zwar aufbauen, doch eine entsprechende Navigation kann nur über einen Eingriff im Backend eingerichtet werden.

Funktional: Über den Einsatz semantischer Technologien oder – einen Schritt vorher – die konsequente Anreicherung von Informationen mit Metadaten (z.B. Tags, Projektzuordnung, Themen, Inhaltsklassen) sind die Inhalte letztlich schneller über eine Suchfunktion als über eine Navigationsstruktur zugänglich.

Psychosozial: Dieses Gegenargument ist gleichzeitig ein Pro-Argument: Die Navigation wird eben nicht „von oben“, vom Admin oder Chef festgelegt, sondern wird von der Community kollaborativ erstellt.

Hmm, Navigation nur über einen Eingriff im Backend? Gilt nicht für die Wiki-Engines zu denen ich rate. Und Navigation über Kategorien oder Hierarchien? Es muss eben evaluiert werden, ob es nicht Wiki-Engines gibt, die so etwas von Hause aus mitbringen (bspw. TWiki-Webs, eigentlich alle gängigen Enterprise Wikis oder auch DokuWiki mit dem Namespace-Konzept).

Johannes – großartiger Punkt bei psychosozial. Dieser Aspekt des emergenten Entstehens von Struktur wird zu oft vernachlässigt, obwohl er viel für die flexible Anpassung an veränderliche Aufgabenstellungen (und die Motivation der Mitarbeiter) tun kann. Arbeitsgruppen, einzelne Mitarbeiter, einzelne Projektgruppen etc. können sich situativ angepasste Arbeitsumgebungen, Portal- und Übersichtsseiten einrichten. Das habe ich mit großem Erfolg auch schon begleitet, und es war eine Freude zu sehen wie die Möglichkeiten von den Nutzern aufgenommen und schnell genutzt wurden.

3. Die Kategorisierung spielt bei den Suchergebnissen keine Rolle bzw. sorgt nicht für eine Priorisierung von Suchergebnissen.

Funktional: lösbar, siehe oben

Psychosozial: Kompetenz bei der Anwendung der Suchfunktionalität muss bei den Nutzern vorhanden sein, oder geschult werden. Außerdem kann das Finden von Informationen, nach denen eigentlich nicht gesucht wurde, Prozesse der Wissensemergenz fördern (Serendipity).

Ich würde noch ergänzen, dass wir auch die zunehmende Einbindung von Wiki-Inhalten in Enterprise Search Ansätze sehen werden. Von Social Bookmarking in the Enterprise ganz zu schweigen. Das Problem ist erkannt, daran wird gearbeitet und Wikis sind eigentlich hierbei das kleinste Problem, viel mehr wird zurzeit damit gekämpft relevante Suchergebnisse aus den vielen, verteilten Office-Dokumenten zu generieren …

4. Suchergebnisse zeigen nicht an, welche Unterthemen es zu einem Oberthema gibt oder ob es in einer anderen Sprache einen Artikel zum gesuchten Thema gibt. Die Semantik drückt sich nicht in Wiki-Strukturen aus. Ab einer gewissen Textmenge ist das nicht mehr praktikabel.

Funktional: lösbar, siehe oben. Schlagwort: Semantic Wiki.

Ja, Semantik drückt sich auch nicht in Office-Dokumenten aus. Tagging, Kategorisierung, redundanzfreie Datenhaltung – alles wichtig, das Semantic Web wird auch manches davon lösen. Psychosozial gilt Punkt 3, Informations- und Medienkompetenz ist nicht immer gleichverteilt und gut ausgeprägt. Coaching und Schulung (und Learning-by-doing) kann hier helfen.

5. Die Suche erstreckt sich nur auf Wiki-Inhalte, andere Quellen können damit nicht erschlossen werden.

Funktional: lösbar. Beispiel ist das Confluence Wiki, dass auch zum Durchsuchen von externen Quellen, z.B. Austauschordner oder Servern genutzt werden kann.

Ja, siehe auch oben die Anmerkungen zu Enterprise Search. Enterprise Wikis bieten mittlerweile fast durchgängig die Möglichkeit bspw. hochgeladene Dokumente in die Suche aufzunehmen.

6. Das Rechtemanagement für ein Wiki muss mühsam eingerichtet werden, insbesondere wenn ein nach Personen und Gruppen differenzierter Zugang für verschiedene Bereiche eingerichtet werden soll.

Funktional: Lösbar zum Beispiel durch den Einsatz von Windows Active Directory. Für das Wiki können bestehende Rechtestrukturen übernommen werden.

Psychosozial: Ein Erfolgsfaktor für den Einsatz von Wikis ist eine flache Hierarchie und der freien Zugänglichkeit von Inhalten. Idealerweise ist die Einführung von Wikis in einer Organisation verbunden mit einer Änderung der Organisationskultur im Bezug auf den Umgang mit Wissen und Informationen zwischen Hierachieebenen.

Hmm, was heißt mühsam? Ist in den meisten Wikis nicht aufwendiger oder anspruchsvoller als die Benutzer- und Rechteverwaltung von Windows Server etc. Eine LDAP-Anbindung ist oft vorgesehen, damit ist dann selbst SSO machbar.

7. Nach etwa ein, zwei Jahren kann es für Unternehmen problematisch werden, wenn die entsprechende Pflege fehlt.

Funktional: Tools können die Pflege unterstützen, zum Beispiel das Finden von toten oder falschen Links, das Ändern von falschen Kontaktdaten etc.

Psychosozial: Das Problem tritt bei allen Systemen zum Wissensmanagement auf. Neben der Einführung einer Technologie, müssen sich deshalb auch Arbeitsabläufe, Arbeitsaufgaben und Rollen (Wikigärtner) anpassen, so dass eine ständige Pflege und Aktualisierung von Inhalten gewährleistet bleibt. Anders als bei anderen Werkzeugen kann die Verantwortlichkeit für die Aktualität der Inhalte auf alle Mitglieder einer Organisation verteilt werden.

Ohne Pflege geht es nicht, nicht umsonst werden die Rollen des Wiki-Gärtners oder des Wiki-Gnoms so wichtig eingeschätzt. Und ja, auch in einem klassischen Intranet kann ohne strukturierende Pflege Wildwuchs, wie bspw. veraltete, widersprüchliche oder redundante Inhalte entstehen (ich gebe aber zu dass ich die Möglichkeit an veröffentlichte Seiten ein “Verfallsdatum” zu knüpfen manchmal vermisse). Aber diese Schwäche kann man durchaus auch zum Vorteil wenden, siehe Punkt 8:

8. Wikis eignen sich für Projekte. Über die Jahre werden jedoch immer mehr Wikis eingerichtet, der Überblick geht verloren – man weiß nicht mehr, in welchem Wiki man suchen muss.

Funktional: Lösbar durch eine Suche, die über mehrere Wikis ausgedehnt ist.

Psychosozial: Klassischerweise wird ein Projekt in einem Abschlussbericht dokumentiert. Auch das lässt sich auf ein Wiki übertragen: Am Ende eines Projekts werden die zentralen und wichtigen Inhalte des Projekts in ein zentrales Wiki übertragen und bleiben dort zugänglich. Das Projektwiki wird gelöscht.

Wenn im Zeitverlauf mehrere Wikis entstanden sind (oder Projektunterbereiche etc.) ist es aus meiner Sicht auch eine Chance Inhalte rückschauend zu strukturieren, und dabei positive und negative Erfahrungen zu dokumentieren. Ein After-Action Review mag zwar zeitraubend erscheinen, aus meiner Erfahrung lohnt sich die Mühe aber. Eine Zusammenfassung der wesentlichen Punkte schafft einen Überblick, der bei anderen ähnlich gelagerten Projekten hilft. Ein paar Ideen zum Einsatz von Wikis im Projektmanagement habe ich hier, hier und hier zusammengestellt.

Zusammenfassend: Einige der Punkte entstammen meiner Meinung nach einer weitverbreiteten (aber unüberlegten) Gleichsetzung von Wiki mit Mediawiki bzw. Wikipedia. Die Wikipedia ist aber kein archetypisches Wiki, und Mediawiki ist auch nicht stets die beste Wiki-Engine. So weisen bspw. Enterprise Wikis wie Socialtext oder Confluence einen Großteil der oben vermuteten Angriffspunkte überhaupt nicht auf, sprich es bestehen bereits funktionale (technologische) Lösungen.

Zudem beziehen sich viele der Kritikpunkte der originalen Liste von Kooptech auf potenzielle Nachteile, d.h. mögliche Schattenseiten von Wikis, die erst durch eine “ungeschickte” Einführung und ungeignetes (Wiki-)Management* zutage treten. Die Auswirkungen auf Strukturen und etablierte Routinen etc. können ja groß sein – das ist auch das eigentliche Motiv von Enterprise 2.0. Aber um diese Potenziale heben zu können braucht es auch ein schlüssiges Konzept, sowie die Anpassung an die Unternehmensgegebenheiten und -ziele. Aber wenn etablierte Vorgehensweisen und Erfolgsfaktoren der Implementierung nicht beachtet werden, kann es durchaus schon mal schiefgehen.

<werbung>Deshalb bietet es sich ja auch an professionelle Unterstützung ins (Projekt-)Boot zu holen. Berater wie wir bringen zum einen spezifische Erfahrungen ein, aber auch

  1. einen Überblick über bewährte Vorgehensweisen und
  2. Ideen, d.h. innovative, kreative Problemlösungsstrategien.

Davon kann die organisationsseitige Einpassung – sprich das Change Management in Bezug auf die eigentlich spannenden sozialen und unternehmenskulturellen Aspekte – profitieren. Und weil es bei Enterprise Social Software wie Wikis meist weniger um Technologie, denn um diese weichen Faktoren geht ist eben weniger Technologieberatung denn Organisationsberatung notwendig.</werbung>

* ich lese gerade das Buch Wikimanagement von Prof. Komus, Review folgt.

tags: , , , , , , , , ,

14 Responses to “Wiki – Gegenargumente und Gegengegenargumente”

  1. Danke für Erweiterung und Kommentare. Das Buch Wikimanagement von Ayelt Kamus liegt auch noch halbgelesen auf meinem Schreibtisch. Zumindest das Kapitel B, wo er klassische Organisationsansätze mit der Social Software/Wiki-Idee vergleicht finde schon mal sehr lesenswert.

  2. Martin Koser says:

    Geht mir auch so, da ich von der Organisationswissenschaft herkomme finde ich Teil B auch sehr spannend.

    Schön finde ich dass das Buch sehr flüssig geschrieben ist, liest sich gut und sollte denn auch viele Leser bekommen.

    Ob der Neologismus Wikimanagement dagegen sinnvoll ist? Ich bin unschlüssig, als mentalen “Shortcut” hat das zwar einen gewissen Reiz, aber ich befürchte eine vorschnelle Klassifizierung als Buch über eine Mode und/oder einen Hype, was es ja definitiv nicht ist.

  3. [...] statt, wo Synaxon gerade eben ein paar Zahlen zur Wiki-Nutzung spendiert hat, bei Emplify und Frogpond, der in herrlicher Tiefe eine Antwort auf die Antwort bei Johannes Maskaliuk verfasst hat, der den [...]

  4. Beim Titel gehts mir ähnlich wie bei anderen Versuchen den Begriff Wiki zu nutzen, um eine neue Denkweise zu suggerieren (z.B. Wikinomics oder Wikipattern). Und dabei geht tatsächlich unter, dass Ideen, die hinten einen 2.0 haben, oft über einen Hype gepushed werden, aber trotzdem notwendig sind und den Hype überdauern werden.

  5. Johannes Moskaliuk says:

    … Und weil ich als Psychologe natürlich eine psychologische Perspektive einnehme und außerdem ein Buch so etwas wie ein Antipattern ist, wenn um die Konstruktion und Kommunikation von Wissen geht, möchte ich hiermit eine Blogparade starten. Ich freue mich über kurze oder lange Beiträge, oder Abstracts bereits vorliegender Publikationen zu den folgenden drei Fragestellungen: …

  6. Martin Koser says:

    Hmmm, Buch als Antipattern? Bist aber arg pessimistisch – ein gedrucktes Werk hat ja zumindest den Vorteil dass es einmal fertig wird und dann wie ein Fels in der Brandung und unverückbar dasteht. Ganz im Gegensatz zu einem Wiki in dem sich das was wir so als Wissen bezeichnen potenziell ständig verändern und weiterentwickeln kann.

    Aber im Ernst, ich finde deine Idee zum Blogkarneval interessant, mal sehen ob mir a) etwas einfällt und b) ich Zeit finde. Die späte Deadline kommt mir schon sehr entgegen.

    Aber in bezug auf “Wikinomics” stimme ich dir zu, Don Tapscott ging es sicher mehr um einen catchy Namen.

    Wikipatterns von Stewart Mader ist dagegen nicht wirklich “marketinggeignet”, zum anderen sehr sinnvoll und überlegt im Konzept von Pattern/Anti-Pattern verwurzelt. Wikipatterns sollen daher auch keine neue Denkweise begründen, sondern sind eher eine Sammlung von bewährten Vorgehensweisen und Methoden – ganz pragmatisch und undogmatisch.

    Und das ist dann auch ein spannender Punkt: sind überhaupt Erfahrungen mit vielen dieser Patterns und Anti-Patterns vorhanden und kann man virtuos mit ihnen umgehen, oder wird nicht immer wieder ein “Standardprogramm” gefahren?

  7. Ayelt Komus says:

    Ein Buch als Antipattern? Da denke ich – als(einer) der Autor(en) von Wikimanagement wohl kaum überraschend – ein wenig anders. Für mich gilt doch eher ‘Varatio delectat’!

    Was das Thema Wikimanagement als Hype angeht: Das Thema ist hochinteressant. Einige Gedanken finden sich übrigens bereits im Schlusskapitel ‘Wikimanagement – Ein Scheinriese’. Ich werde mich aber demnächst unter weblog.wikimanagement.de noch einmal dazu an die Tastatur setzen. Dann mehr….

  8. Martin Koser says:

    Herr Komus, da bin ich schon ihrer Meinung – Bücher haben als Transportmittel und -medium für Wissen ein paar Vorteile, ich schreibe ja selbst an einem.

    Ihren Versuch Erweiterungen über das Wikimanagement-Wiki aufzunehmen und weiterzutreiben beobachte ich mit Interesse und Sympathie, ich werde versuchen die eine oder andere Erweiterung einzubauen.

    Zum Thema Hype oder Nichthype will ich ein kurzes Zitat beisteuern – fast eine Heuristik für den Umgang von Menschen mit technologischen Veränderungen:

    “Wir überschätzen die kurzfristigen Erfolge und Einsatzgebiete von Technologien/Veränderungen und unterschätzen die langfristigen Auswirkungen”. Gilt aus meiner Sicht auch für den Themenkomplex Enterprise 2.0 und Social Software im Unternehmen.

  9. Ayelt Komus says:

    Sag ich doch. Deshalb finden Sie übrigens genau dieses Zitat auf S. 260 im Wikimanagement-Buch ;-)

  10. Martin Koser says:

    So weit mit dem Durcharbeiten bin ich noch nicht ;)

    Aber ich hätte mir das eigentlich merken müssen – ich habe das Kapitel (das so nett mit dem Scheinriesen-Zitat beginnt) nämlich als erstes “gescannt” …

  11. Karsten Ehms says:

    Vielen Dank für die kommentierende Darstellung der Aspekte zur Wikieinführung. Das deckt sich weitestgehend mit meinen Erfahrungen bei einem großen dt. Elektrokonzern und meinem Hintergrund als Psychologe ;-)

  12. Martin Koser says:

    Hallo Herr Ehms, das freut mich – die Passung überrascht uns beide aber sicher nicht wirklich ;)

    Die Grundmuster sind ja ähnlich, ob nun bei einem DAX- oder KMU-Unternehmen: Der personelle Kontext Team, Projektgruppe, Abteilung etc. ist vom Umfang und von den Strukturen her in der Regel vergleichbar – auch wenn Entscheidungswege, Geschwindigkeiten etc. natürlich anders aussehen.

    Meine Erfahrungen mit der Veränderungsfähigkeit von (KMU-)Unternehmen sind dabei durchaus positiv, ich kann daher auch mit “fatalistischen” Einschätzungen wie “das dauert in Deutschland noch ewig” nicht viel anfangen, niemand hat gesagt dass es einfach ist.

    Die Einführung von Social Software in Unternehmen ist nicht trivial – gerade weil damit die Veränderung von tiefsitzenden Routinen und Praktiken einhergeht. Aber dass es notwendig ist und auf jeden Fall kommen wird ist meiner Meinung nach klar. Und hier können wir viel von den Erfahrungen und Vorgehensweisen lernen, die das organisatorische Change Management entwickelt hat. Weder ist Social Software ganz neu, noch ändern sich die Vorgehensweisen und Prinzipien denen wir vernünftigerweise folgen.

    Umgekehrt kann das Management von Veränderungen durchaus einige Methoden und Werkzeuge aus dem Fundus von Enterprise Social Software gebrauchen, bspw. hier eine entsprechende Umfrage, die meine “alte Heimat” an der Universität Stuttgart durchgeführt hat:
    http://www.frogpond.de/index.php/archive/social-software-as-change-management-infrastructure/

  13. [...] Blogssphäre rund um die Frage des effektiven Einsatzes von Wikis gibt es jede Menge, z.B. bei kooptech, frogpond, Ayelt Kamus oder emplify. Ich möchte – nach meinem Urlaub super erholt – wieder in [...]

  14. Wilfred says:

    It’s awesome to pay a visit this website and reading the views of all colleagues
    regarding this paragraph, while I am also eager of getting know-how.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>