Wikis in Organisationen: Anforderungen an das Wiki

Zur Einführung eines Wikis sind eine Vielzahl von Anforderungen zu betrachten. Die Auswahl der Software ist eine der unflexibelsten Entscheidungen bei der Einrichtung einer Wiki, da Struktur- und Inhaltsänderungen ständig möglich sind und sogar das Grundprinzip und Arbeitsweise eines funktionierenden Wikis sind, eine Umstellung der Software ist technisch aufwändig und erfordert neue Eingewöhnung der Benutzer. Dabei Usability ist wahrscheinlich die wichtigste Eigenschaft für den Erfolg jedes Kommunikationssystems, auch für Wikis.

Die Inhalte müssen einfach, logisch und über mehrerer Wege erreicht werden können. Neben den klassischen Wikilinks zwischen den Texten ermöglicht dies vor allem eine gute Suchfunktion und eine einfache aber umfassende Strukturierung (viele Kategorien, Tags, etc).

Bei der Schreibfunktion ist die größte Hürde die ungewohnte Syntax. Die viel geforderten WYSIWG Editoren sind (noch) keine sinnvolle Hilfe, trotzdem ist bei der Wikiauswahl auf die zu verwendende vereinfachte Auszeichnungssprache zu achten; zu empfehlen ist Markdown und, da weit verbreitet, der Mediawikisyntax.

Der strukturierte Einsatz von Wikis erfordert Transklusionen, sie ermöglichen es andere Seiteninhalte in Seiten einzufügen. Vom einfachen Textbaustein der leicht Hinweise einfach einbaut bis hin zu programmierbaren Infoboxen die selektiv von andern Anwendungen abgefragt werden können.

Die oft geforderte komplexen Zugriffsregelung und exakte Organisationsabbildung kann und muss vernachlässigt werden, besteht ein Wiki hauptsächlich aus organisatorischen Schranken ist es kein Wiki und wird nie eins werden. Es genügt Zugriffsrechte allgemein zu regeln und wenigen Ausnahmen zu definieren.

Inhalt

Schreiben

Oft stößt man bei den ersten aktiven Wikiberührungen auf missfallen beim Markup. Es sieht, wie alles Neue, ungewohnt und damit schwierig aus. Allerdings handelt es sich um sehr vereinfachte Auszeichnungssprachen wie z.B. Wikitext, die sehr leicht zu lernen sind und alle notwendigen Regeln auf einer Postkarte Platz haben.

Die Extension:FCKeditor für Mediawiki

WYSIWYG ist zwar eine oft geforderte Anforderung, wird aber erfahrungsgemäß im laufenden Betrieb nicht benötigt, da die Vorteile von Markup überwiegen. Allerdings ist das "verwirrende" Markup ein gewaltiger psychologischer Hemmschuh gegen ein Wiki: „In einer unternehmens-internen Umfrage unter Verantwortlichen äußerten 75% der Befragten, dass sie selbst und die Mitarbeiter ihres Bereiches ein Wiki ohne integrierten Rich-Text Editor kaum verwenden würden. In der Praxis konnte dies zwar teilweise widerlegt werden“ ()

Jemand der die wenigen Regeln Wikitext nicht verstehen will, wird kaum in der Lage sein den dynamischen Inhaltsprozess zu verstehen und zu nutzen.

Darstellung

Wikiinhalte werden hauptsächlich mit einem Browser auf einem normalen PC dargestellt. Allerdings sind weitere Darstellungsarten möglich und nützlich:

Drucken

Für normale Büroausdrucke gibt es in fast allen Wikisystemen eine spezielle Druckseite oder ein print-css wie bei klassischen Internetseiten auch üblich. Aufwendigere Druckverarbeitungen für Broschüren oder gebunden Bücher sind wie bei anderen Inhaltsverwertungssystemen nicht standardmäßig eingebaut. Es gibt aber sicher Möglichkeiten ein Wiki als Text- oder Mediadatenbank eines Desktop Publishing Systems einzubinden. Teilweise gibt es weiter noch die Möglichkeit mehrere Seiten in Buchform zu bringen, um alle oder bestimmt Artikel in eine klassisches Buch zu fassen (für Handbücher etc.).

Präsentation

Inhalte müssen oft vorgestellt werden. Dabei muss man nicht unbedingt alle Inhalte statisch aus dem Wiki in eine Powerpointpräsentation kopiert werden. Auch hier kann man direkt aus dem Wiki präsentieren, muss die Inhalte aber für einen Vortrag den die Projektion umgestalten. Hier gibt es wieder die Möglichkeit mit einem projection css, welches aber nur vom Browser Opera nativ unterstützt wird und sonst mit einem styleswitch eingeschaltet werden muss. Angenehm ist S5, ein Präsentationssystem auf der Grundlage von XHTML zur Definition von Präsentation und den dazugehörigen Folien.

Mobil

Nicht nur das mobile Internet sondern auch das mobile Intranet wird immer wichtiger und hilfreicher. Außendienstmitarbeiter oder Montagetrupps können wichtige, umfangreiche und aktuelle Information auch ohne Laptop abrufen. Dazu ist eine Darstellung auf mobilen Geräten nötig, die aber wiederum per css oder Sonderansicht möglich ist und als gängige Webtechnologie bei vielen engines dabei ist.

Ordnung

Neben der Aufbewahrung, Veränderung und Darstellung, ordnet eine Wiki Information und Wissen.

Doch kann man in einem Wiki gleichzeitig mehrere Ordnungssysteme verwenden.

Seitentitel und Hyperlinks

Die primäre Ordnung stellen die Seitentitel dar. Diese sind nicht nur die Identifikation für die dargestellte Menge an Wissen, sonst könnte man einfach aufeinander Nummern nutzen, sondern beschreiben schon den Inhalt (z.B. Umgang mit Gefährlichen Stoffen).

Die Seitentitel dienen innerhalb des Wiki auch als Identifikator für einen Hyperlink. So müssen Referenzen auf andere Inhalte nicht erst mühsam gesucht und verarbeitet werden (z.B. knowlegdebase.intra/index.php?id=1234) sondern können meist flüssig im Text verlinkt werde ([[Seitentitel]]). Gegenüber einem rein schriftlichen Querverweis (siehe Gefahrguthandbuch S. 34) ist die die Zugänglichkeit einfacher und damit die Wahrscheinlichkeit der Nutzung wahrscheinlich höher. Eine gute Verlinkung strukturiert das Wissen semantisch und matritzenförmig.

Hyperlinks sind aber nicht nur intern wichtig, auch externe links müssen einfach gesetzt werden können. Bei häufig gebrauchten Zielen, wie anderen Software (CRM, ECM etc), können in vielen System ebenfalls sehr vereinfacht geschrieben werden. (z.B. [[vcard:Max Huber]] anstatt crm.intra/index.php?id=Max%20Huber)

Zusätzlich können über Backlinks, Links die auf eine Seite verweisen, semantische Informationen gewonnen werden. So kann man rudimentär aber einfach sehen welche Projekte einen Prozess nutzen. Leider haben nicht alles Wikis Backlinks

Kategorisierung

Die wichtigste 2. Ordnung in jedem Wiki sind Kategorien. Zwar könnte man Kategorien manuell als eigene Seiten führen, jedoch benötigt man so für jede Kategorisierung 2 Edits. Was erfahrungsgemäß irgendwann nicht mehr gemacht wird.

Es gibt streng hierarchische Kategorisierungen, bei der alle Kategorien immer einer Baumstruktur nach unten folgen, und matritzenförmige, bei der auch Querkategorien angelegt werden können.

Wichtig ist hier auch die Skalierbarkeit. Muss man Kategorien z.B. aus einem DropDown-Menue auswählen (Tikiwiki), fällt die Übersichtlichkeit schnell weg, da alle Kategorien angezeigt werden müssen. Andere Kategorisierungssysteme binden sich als spezieller Syntax (Mediawiki) auf der Seite ein, und können so wesentlich mehr werden.

Namensraum

Eine Erweiterung des Seitentitel sind Namensräume, diese können eine nützliches Instrument zur Strukturierung sein und sollten in der meisten Software vorhanden sein.

Transklusionen

B ist in Dokument A transkludiert worden.

Eine Transklusion ist die Fähigkeit andere Dokumente oder Abschnitte daraus, in sich einzuschließen. So können Textbausteine an unterschiedlichen Stellen im Wiki mehrfach genutzt werden. Wird der transkludierte Text aktualisiert, aktualisiert sich automatisch auch die Transklusion in allen Seiten in die diese eingebunden ist. Diese Bausteine sind hilfreich um Artikel zu Kennzeichnen, Unternavigation oder Infoboxen flexibel zu gestalten.

In diesen Textbausteinen kann man je nach Wikisoftware alle Funktionalitäten (Markup, Kategorisierung, html, Sperren, etc) verwenden. Auch Teilweise lassen sich diese auch programmieren (Mediawiki).

Dateien

Die meisten Wikisysteme können Dateien verwalten. Meist lässt sich einstellen welche Dateitypen erlaubt sind. Wenige wikis haben einen Bulkupload, bei dem mehrere Dateien gleichzeitig oder ganze Ordner hochgeladen werden können.

Gruppe

Änderungsmanagement

Eine Wiki lebt von seiner Veränderung, doch diese müssen gut überwachbar sein. Dazu ist es wichtig, dass die Software nicht nur mitteilt, dass etwas verändert wurde, sondern auch was. Die sogenannte Diff-Darstellung beschreibt genau, welche Textphrasen verändert wurden. Hilfsmittel zur Benachrichtigung sind Beobachtungslisten und letzte Änderungen, aber auch externe wie Email oder RSS.

Rollenkonzept

Es gibt unterschiedliche Organisationsstrukturen, zwar sollte man immer versuchen möglichst einfach und freiheitlich mit den Hierarchien umgehen. Aber manche Organisationen wollen und brauchen speziellere Zugriffsregelungen, um ihr organisatorisches Sicherheitsbedürfnis zu decken. Auch in der Einführungsphase ist es wichtig, das bestehende Rollenkonzepte abgebildet werden können, auch wenn diese mit der Zeit einfacher werden und mehr in das Wechselspiel zwischen schneller Änderung und deren Überwachung verändert.

Prinzipiell müssen mindestens die Grundseiten immer für alle Teilnehmer einsehbar und veränderbar sein. Können "normale" Mitglieder nur in ihren Bereichen (Namensräumen) editieren ist das Wikiprinzip gebrochen und die Nutzer sind nur schwer zur Mitarbeit zu bewegen.

Weiter gilt in einem Wiki mit einem definierten Mitgliederstamm im Gegensatz zu einem freien Wiki im Internet: Jeder der lesen darf, darf auch schreiben. Viele Berater empfehlen auch: Keine Zugriffs- oder Editierbeschränkungen! (alle User dürfen alles). Die Gefahr, dass Seiten mutwillig zerstört werden besteht aufgrund der namentlichen Verfolgbarkeit nicht.

Zugang

Gesperrte Inhalte, die nur einer exklusiven Gruppe (z.B. Geschäftsleitung, Entwicklung) vorbehalten sind, müssen sicher und einfach verwaltbar sein; dazu gibt es 2 Methoden:

Seite werden einzeln gesperrt (Seitenselektiv)

Hier ist die Auswahl der verdeckten Inhalte selektiv. Mit einer einzelnen Sperrung lassen sich wenige, spezielle Seiten die brisante Inhalte beinhalten sperren; eine größere oder definierte Informationsmenge ist so schwer zu schützen.

Es werden ganze Namensräume oder Kategorien gesperrt (Raumselektiv)

Alle Inhalte, die in einem sinnvollen Namensraum (z.B. Entwicklung) stehen, sind für Nichtmitglieder weder einsehbar noch editierbar. So werden sehr viele Inhalte grundsätzlich dem Zugriff "Gruppenfremder" entzogen.

Eine Kombination aus beiden ist natürlich ideal.

Gruppen

Die Mitglieder und Teilnehmer an einem Wiki kann man in unterschiedliche Gruppenformen einteilen:

• Liegt eine hierarchische Ordnung vor, darf die oberste Gruppe (z.B. Geschäftsführung, Admins) alles einsehen und ändern, die Gruppen darunter dürfen dann immer weniger.
• bei einer matrizenförmigen Ordnung dürfen bestimmte Gruppen sich nicht gegenseitig in die Inhalte schauen. So darf die Entwicklung nicht die Preisstruktur des Marketings sehen, im Gegenzug die Marketingabteilung nicht die Neuentwicklungen.

Auch hier gilt weniger ist mehr. Umso feiner eine Gruppenstruktur gezimmert wird umso mehr gehen die Wikieigenschaften flöten und am Schluss hat jeder seinen eigenen, ausschließlich persönlichen Bereich. Der Vorteil eines Wikis, das man Informationen der des ganzen Teams oder Organisation nutzen und aktiv mitgestalten kann, ist weg.

Workflow

Die Wikiphilosophie dreht den klassischen Workflow um. Normalerweise wird eine Änderung "beantragt" und dann vom Verantwortlichen freigegeben, was mitunter dauern kann. In der Umgebung eines Wikis ist Vertrauen aber elementar (Natürlich würde keine Firma verlautbaren kein Vertrauen in seine Mitarbeiter zu haben). In diesem Vertrauensumfeld geht man davon aus das Neuerungen oder Änderungen nach besten Gewissen gemacht werden, auch bei kritischen Informationen wie Geschäftsprozessen. Das hat den immensen Vorteil das Änderungen nah am Zeitgeschehen mit dokumentiert werden können und nicht im Rund lauf dahinsterben und sich selbst überholen. Wobei Änderungen im Nachlauf immer noch kontrolliert werden.

Wird doch ein redaktioneller Wikiworkflow gewünscht so kann diesen derzeit nur Confluence und Twiki anbieten.

Technik

Skalierung

Ein dann grundlegendes System wie eine Wiki muss die Größe und Struktur der Organisation auch bedienen können. Die meisten Technologien sind sicherlich standardmäßig für eine Mitgliederanzahl in der Größe einer Kleinstadt ausgelegt; aber auch größerer Zugriffe sind durch technisch Aufrüstung kein Problem. Auch eine hohe örtliche Verzweigung ist weltweit, durch Internet,möglich. Die verhältnismäßig geringen Datenmengen die übermittelt werden sind schnell verteilt.

Datenbank

Oft werden Datenbanken eingesetzt um die Inhalte zu speichern, hier kommen mySQL oder auch PostgreSQL zu Einsatz. Viele Wikis können Ihre Daten aber auch in Textdateien (Dokuwiki, TWiki) speichern. Das hat den Vorteil das keine Datenbankumgebung, mit Sicherheitsrisiken und Administrationsaufwand, benötigt wird und die Dateien im Notfall auch mit einem einfachen Editor gelesen werden können.

Den Performance-Vorteil von Datenbanken kommt in einem abgesteckten Wiki mit Zugriffszahlen von unter 10 Zugriffen pro Sekunde nicht zum tragen.

Add-on

Diese Grundfunktionen genügen aber oft nie allen Ansprüchen dazu ermöglicht es die meiste Software mit Add-on (auch Extensions) eine Erweiterung und Anpassung. Dabei ist darauf zu achten das Add-ons ob und wie Add-ons zukünftige Pläne abdecken, ob es eine ausreichende Unterstützung der Community oder des Herstellers gibt und wie die Möglichkeiten zur Eigenentwicklung bestehen. Vor allem bei Add-ons ist eine reichhaltige Dokumentation sehr wichtig für die Anpassung.

Schnittstelle

Mit Programmierschnittstellen können:

• die Daten des Wikis in verschiedenen Formen von andern Programmen mit verwendet werden.
• fremde Daten, z.B. aus anderen Programmen können im Wiki einbezogen werden (z.B. Daten aus einem Mitgliederverzeichnis, Wetter Information)

Hier ist darauf zu achten ob und wie das Wiki Daten ausgibt und importieren kann. Hier werden meist xml gefordert.

Quellen

Wikis in Organisationen

Theorie: Begriffe | Abgrenzung | Anwendung

Praxis: Ordnung | Kultur | Leben | Kontrolle | Datenschutz

Projekt: Einführung | Anforderungen an das Wiki & die Organisation | Software | Schulung

Meta: Referenzen | Nachwort