Ein Wiki ist eine Sammlung von digitalen Dokumenten die von Benutzern nicht nur gelesen, sondern auch online direkt im Webbrowser geändert werden können, um Erfahrung und Wissen gemeinschaftlich zu sammeln, verbessern und auch zu teilen.
Organisationen besitzen Wissen in Form von Prozesswissen und spezifischen Projekt- oder Kundeninformationen; sie kommunizieren dieses Wissen und wenden es im organisatorischen Alltag an. Austausch, Anpassung und Festschreibung dieses Wissens ist für Firmen, Interessenverbände, Vereine oder Gruppen der zentrale organisatorische Vorgang.
Das Wissen der meisten Organisationen ist in Handbüchern, Aushängen, Powerpoints, Dienstanweisungen, Excel- oder Worddokumenten festgeschrieben und existiert, als informelles Wissen in den Köpfen. Kommuniziert werden diese Inhalte durch E-Mailverteiler, Chats, Aushänge und vor allem durch persönliche Kommunikation. Das führt oft dazu, dass Mitglieder Wissen ständig suchen, weiterleiten oder anfragen müssen. Mögliche Verbesserungen von vorhandenen Dokumenten müssen vorgeschlagen und vom ursprünglichen Ersteller eingearbeitet werden, was leider oft im dringenden Aufgabenberg untergeht.
Wikis als Software und das Wiki-Prinzip an sich dienen nicht der direkten Kommunikation zwischen Mitarbeitern oder Mitgliedern, sondern versuchen diese Kommunikationsinhalte kollaborativ zu sammeln und zu verbessern, um dann im Tagesgeschäft darauf Bezug zu nehmen.
Ein Wiki in einer Organisation soll eine Wissensbasis schaffen, die jedes Mitglied, auch aktiv, mit einschließt. Mit einem Wiki lässt sich sowohl Wissen erfassen, als auch spezifische Informationen und Verfahrensbeschreibungen gemeinsam erstellen und verbessern. Auf diese Weise ist ein Wiki geeignet, stark umfassende Prozesse zu unterstützen. Welche Inhalte konkret in einem Wiki gesammelt werden, muss jede Organisation für sich selbst entscheiden.
Folgt man dem gesellschaftlichen Konsens, ist Wissen das Kapital der Zukunft. Kein Unternehmensleitbild, das ohne diese Formel auskommt. Und in der Tat sind in unserer modernen Wissensgesellschaft der Zugang zu gut ausgebildeten Mitarbeitern, produktiven Verfahren und Patenten das wichtigste Kapital von Unternehmen und Organisationen.
Tun Firmen alles, um die besten Absolventen einzustellen und Verfahren und Patente zu sichern oder zu astronomischen Preisen zu kaufen, wird das interne und täglich genutzte Wissen oft nur in unzulänglicher Kommunikation weitergegeben. Der Blackberry gebeugte Manager lässt grüßen!
Dabei gibt es zahlreiche Lösungsansätze: klassisches Wissensmanagement, Verfahrensdokumentationen im prozessorientierten Qualitätsmanagement (wie die ISO 9000) oder die Nutzung von Social Media wie Chats, Kommentare oder interne "Facebooks".
Wikis sind kein zusätzlicher Ansatz, sondern bieten eine Kultur, eine Software und vor allem eine handfeste Lösung, um Wissensmanagement, aber auch Prozess- und Projektverwaltung, so schnell und leicht wie Social Media zu betreiben.
Wikis werden nicht zum Selbstzweck eingeführt, sondern weil eine effiziente Informationsverwaltung erwartet wird. Ein produktives Wiki, das möglichst viele relevante, gut strukturierte Inhalte, bereit hält, muss erst einmal geschrieben werden. Und das setzt zeitliche und damit finanzielle Ressourcen voraus.
Neben der Zeit, die Mitarbeiter damit verbringen, Inhalte in das Wiki einzupflegen, kommt der Aufwand hinzu den ein aktives Gardening (Betreuung von Inhalt und Nutzern) erfordert.
Diesem Aufwand steht in einem funktionierenden Wiki ein produktiver Nutzen gegenüber:
Aktuelle, bekannte Inhalte werden zielgerichtet gefunden und Wissen muss nicht immer wieder von primären Wissensträgern erfragt werden. Der zeitliche Aufwand der anfällt, um in unsortierten E-Mails Informationen zu finden, liegt bei bis zu 20 Prozent[1]. Würden Nutzer Wissen nicht nur durch E-Mails, verstreute Einzeldokumente oder mündliche Überlieferung sammeln müssen, sondern durch Wikis auf strukturierte, dokumentiertes und durch sozialen Medien kommuniziertes Wissen zugreifen können, wären Produktionssteigerungen von bis zu 25 Prozent möglich.[2]
Durch die universalen Dokumentationsmöglichkeiten und die semantische Struktur, vor allem durch Links, wird dem Nutzer zusätzliche Information im Kontext angeboten. Wikis ermöglichen gleichzeitig verschiedene Wissensgebiete (beispielsweise Prozess- und Projektwissen) in der selben Anwendung zu sammeln. So kann sich der Nutzer, je nach bereits vorhandenem Wissen, zielgerichtet und auch tiefgreifend informieren.
Wikis können schnell und ohne Probleme verändert werden. Dies bedeutet nicht zwingenden einen Qualitätsverlust, denn der Inhalt wird durch effektive Kontrollmechanismen sogar besser.
eventuelle Fehler, Fehlannahmen und Missverständnisse werden zwar erst einmal schriftlich festgehalten, sind dadurch aber leichter zu finden und zu beheben.
Durch Transparenz der Geschäftsprozesse steigert sich die Akzeptanz und das Verständnis für betriebliche Vorschriften. Mitarbeiter die beispielsweise den Hintergrund einer Reisekostenabrechnung im einzelnen Detail einsehen und damit verstehen können, werden weniger Fehler machen und Angaben auslassen.
Durch die benutzerfreundliche Arbeitsweise eines Wiki fällt der Übergang von impliziten in explizites, organisatorisch nutzbarem, Wissen leichter.
Wikis können zwar nur für bestimmte Zwecke geplant werden, es ist aber ein Vorteil, in Wikis sich nicht auf spezielle Anwendungen beschränken zu müssen. Wikis erlauben eine Basis für verschiedenste Formen von Information und Wissen, ohne hinderliche strukturelle Grenzen.
Primär verwalten Wikis freien Text, erst in dessen Kontext auch strukturierte Daten. So kann jede Art von Information abstrakt erfasst werden. Texte sind, im Vergleich zu strukturierten Datenverwaltung, wie Excellisten oder Datenbanken, die flexibelste Möglichkeit, jede Art von Informationsstruktur zu beschreiben. Die Vorteile dieser flexiblen Struktur können aber auch zu unstrukturiertem Inhalt führen, denn es ist keine Ordnung vom technischen System vorgegeben. Eine Ordnung muss als Konvention definiert und gepflegt werden.
Zwar ist es wichtig, bei der Einführung erste Anwendungen zu definieren, nichts spricht jedoch dagegen das Wiki auch für andere Anwendungen zu öffnen.
Es ist sinnvoll, in einem Wiki unterschiedliche Informationen zu verwalten. Da auf diese Weise Projekte beispielsweise auf ihre dazugehörigen Prozesse verweisen können, können umgekehrt Prozesse auf angewandte Projekte hinweisen.
Der Nutzer bekommt zusätzliche Information aus dem Kontext der ursprünglich gesuchten Information.
Die Wissensrepräsentation, die formale Abbildung des zu vermittelnden Wissens, der Wikiartikel ist nicht grundsätzlich hierarchisch in einer pyramidalen Struktur eingebettet, sondern in ein semantisches Netz. Jede Information ist so in ihrem Kontext eingebettet. Das ist die größte Stärke von Wikis. Wikis bieten dem Nutzer prozess-, projekt- oder abteilungsübergreifenden Wissenszugang. Vor allem durch Links gelangen Nutzer oft zu Artikeln, und damit zu Wissen, das zunächst nicht gesucht wurde. Man kennt den Effekt aus Wikipedia: Man sucht nur die Einwohnerzahl einer Stadt und landet über deren Geschichte, einem Klick bei einem historischen Ereignis, und man kommt über ein Herrscherhaus zu einer Kunstrichtung. Diese Serendipität führt bei Wikipedia lediglich zu einem interessanten Wissensgewinn. In einem Organisationswiki hilft sie dem Nutzer, sich mehr relevantes und benötigtes Wissen anzueignen, oder noch besser die Fähigkeit zum richtigen Zeitpunkt zu wissen wo dieses Wissen im Wiki zu finden ist.
Es gibt zahlreiche andere kollaborativen Systeme: Schwarze Bretter oder white boards , die leider örtlich begrenzt sind und über Notizen nicht hinausgehen. Netzwerklaufwerke, die zwar Änderungen zulassen, diese aber nicht nachvollziehbar darstellen. Social-Media-Plattformen wie Blogs, Microblogs, Foren ermöglichen eine schnelle und einfache Interaktion, erlauben jedoch nur eine Kommentierung und keine Veränderung von bestehenden Inhalten.
Dabei ist es vor allem die technologische Einfachheit[3] die es Nutzern berechtigt, Verbesserungen und Ergänzungen hinzuzufügen. Diese Neuerungen oder Verbesserungen in Wikis müssen weder angefragt noch erlaubt werden. Jedes Wiki gestattet es Inhalte, sprichwörtlich auf Knopfdruck, zu ändern, erlaubt aber trotzdem eine Kontrolle oder Freigabe der Nutzerbeiträge.
Der prinzipiell offene (Schreib)-Zugang macht eine schnelle, unbürokratische Arbeitsweise möglich. Durch Kontrollstrukturen werden etwaige Fehler rasch und einfach ausgebessert, jeder Zustand ist wiederherstellbar und jede Änderung nachvollziehbar. Teams können an gemeinsame Inhalten auch gemeinsam Arbeiten; dennoch bleibt jeder Zustand und die Urheberschaft, falls erwünscht, eines jeden Buchstaben erhalten und jeder Arbeitsschritt kann auch rückgängig gemacht werden.
Anja Ebersbach, Markus Glaser, Richard Heigl, Alexander Warta: Wiki - Kooperation im Web. Springer, 2. Auflage 2008 ISBN 978-3540351108
Martin Seibert, Sebastian Preuss und Matthias Rauer: Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in UnternehmenISBN 978-3-8349-2827-6
Welche Felder des organisatorischen Wissens soll man in einem Wiki aufnehmen? Prinzipiell kann man ein Wiki für alle Aufgaben einsetzen, wenn Informationen gesammelt, ausgetauscht und verändert werden müssen. Besonders gut sind Wikis an strategischen, nichtoperativen Stellen[1]. Allerdings sind Wikis nicht die einzigen Mittel zur Kommunikation und Informationssammlung. Manche Aufgaben werden mithilfe anderer Medien besser erfüllt.
Wofür ein Wiki verwendet wird, muss zwar auf-, aber nicht festgeschrieben sein. Ein Wiki kann mit projektspezifischen Informationen beginnen, aus der sich allgemeine Prozessbeschreibungen entwickeln können, oder es kommen administrative Informationen (beispielsweise Protokolle, Laufzettel, Speisepläne) hinzu.
Im Gegensatz zu vorstrukturierten Datenbanken und Softwarelösungen, die, wie ein Lottoschein, genau einen Zweck erfüllen. Vorstruktuierte Datenbanken erfüllen genau einen Zweck: Geschäftssoftware, Adressoftware, Buchhaltung. Im Gegenzug dazu ist ein Wiki wie ein Flipchart oder ein großer Notizblock, auf dem in manchen Fällen detailreiche Gemälde entstehen, in anderen Fällen aber nur skizziert wird. Alles lässt sich darstellen und muss softwareseitig nicht geplant oder vorstrukturiet werden.
Support - und Managementprozess flankieren den Kernprozess
Jede Organisation benötigt zum reibungslosen Betrieb interne Absprachen und Festlegungen, die entsprechend kommuniziert und hinterlegt. Diese Dokumentationen müssen im betrieblichen Alltag aktuell gehalten und an die entsprechenden Nutzer verteilt werden. Wikis sind eine einfach aber dennoch sichere Möglichkeit, administrative Vorgänge zu dokumentieren, zu ändern und zu verteilen.
Stellenbeschreibungen, Geschäftspläne und andere Richtlinien sind umfangreich, aber wichtig für den täglichen Betrieb. Änderungen müssen klar kommuniziert werden. Mit einem Wiki haben alle Nutzer Zugriff auf aktuelle Absprachen. Veränderungen können restriktiv kontrolliert werden.
Neben der klassischen Kernprozessdefinition oder dem spezifischen Projektwissen gibt es zahlreiche Informationen, die man im alltäglichen organisatorischen Betrieb wissen, aber oft suchen muss. Die Beschreibung von Supportprozessen sind oft trivial, aber oft nicht für alle zugänglich, veraltet oder missverständlich interpretiert.
Solche Informationscluster eignen sich besonders gut für eine erste Anwendung bei der Wikieinführung, da sich schnell ein für die Nutzer sichtbarer Mehrwert einstellt.
Agenden und Protokolle für Besprechungen und Sitzungen
Um Teilnehmer einer Besprechung auf die Themen vor- und nachzubereiten, werden Agenden und Protokolle erstellt. Oft ändert sich aber Themenauswahl oder Prioritäten, da andere Fragestellungen aufkommen oder sich Schwerpunkte verschieben. In einem Wiki lassen sich diese Themen sammeln und gemeinsam priorisieren. Alle Teilnehmer haben Einblick auf die aktuelle Agenda und können diese anpassen. Die Verantwortlichen können die Änderungen einsehen, freigeben oder zurücknehmen. Nachrangige Themen, die erst auf späteren Sitzungen behandelt werden sollen, können einfach gesammelt werden.
Es dauert häufig sehr lang, bis neue Mitarbeiter produktiv arbeiten, auch deshalb so lang, weil diese erst interne Prozesse und Verfahren, aber auch Traditionen und Gewohnheiten lernen müssen. Ein Wikiseite als Einstieg für alle Neulinge hilft, die ersten dieser vielen Fragen zu beantworten.
Neue Mitarbeiter haben einen unverstellten Blick auf die Organisation, ohne Betriebsblindheit. Sie sollen das Wiki nicht nur nutzen, um Inhalte zu lesen, sondern sich vom ersten Tag aktiv beteiligen. Wenn unverständliche oder unvollständige interne Inhalte nicht verstanden werden, dann durch erfahrene Nutzer erklärt werden, kann das Wiki gleich mit verbessert werden. Außerdem kann "frischer Wind" tradiertes Wissen hinterfragen.
Weiter kann man festlegen, was ein neuer Mitarbeiter erledigen muss, ein Laufzettel, aktualisiert und verbessert im Wiki, hilft neuen Mitarbeitern Aufgaben wie NDAs unterschreiben, Zugangskarten, System Konten anlegen, Kantinekarte kaufen, strukturiert abzuarbeiten, ohne einzeln nachfragen zu müssen. Im Falle des Ausscheidens kann ein Wiki ebenfalls alles nötigen Todos für Mitarbeiter und Firma zusammenfassen.
Eine Wikiseite, auf der Mitarbeiter Ideen einbringen können, als einfache Form des betrieblichen Vorschlagswesen, erfordert wenig Aufwand, aber neue Ideen erreichen andere Kollegen und fördern deren Weiterentwicklung.
Interne und externe Handbücher
Software oder Maschinen benötigen Betriebsanleitungen. In einem Wiki können Handlungsanweisungen schnell und einfach gesammelt, kontinuierlich an Weiterentwicklungen angepasst und so auf dem aktuellen Stand gehalten werden.
Festschreiben der Corporate Identity
Die Angaben über standardisierte Hausschriftarten, Logodateien, Firmenfarben in RGB, CMYK und Pantone werden auch in viele Abteilungen gebraucht.
Inventaraufstellung
Kleine Büros oder Geschäfte haben meist kein System zur Verwaltung von Inventar. Um einen Überblick über Computer, Bürogeräte oder Möbel zu erhalten, genügt eine Liste im Wiki. Dort kann dann weiterführende Information, wie Gebrauchsanleitung, Lieferanten oder Garantiebedingungen, verlinkt werden.
Pressespiegel
Jede Organisation sammelt gerne externe Veröffentlichung und Presseberichte. In einer Wikiseite lassen sich Links auf Onlinepublikationen, Scans oder Erwähnungen einfach sammeln.
Sicherheitsregeln
IT-Sicherheitsregeln, wie Passwortqualität und Nutzungserlaubnis, Diebstahlschutzregeln oder Fluchtpläne für Gebäude - Wikis sind ein guter Ort, Regeln aus unterschiedlichen Bereichen zusammentragen. Nutzer können all diese Informationen immer aktuell und vor allem einfach einsehen.
Social Media Guidelines
Verhaltensregeln, wie sich Mitarbeiter in Social Networks verhalten sollen.
FAQ
Ein Wiki kann Antworten auf Häufig gestellte Fragen (FAQ) geben. Und wikiintern auf weiterführende Artikel verlinken.
einfache Adressverzeichnisse
Falls keine Standardadressverwaltung (zum Beispiel Outlook) vorhanden ist, können häufig genutzte Adressen und Kontaktdaten auch in einem Wiki hinterlegt werden.
Aktueller Speiseplan
Im klassischen Intranet ist eine der häufigsten Fragen: Was gibt es heute in der Kantine?
Diese Aufstellung ist ein Leitfaden dafür, was in einem Wiki an administrativen Prozessen zusammengetragen werden kann. Welche Inhalte tatsächlich aufgenommen werden, muss jede Organisation selbst entscheiden. Es gibt unendlich viele Möglichkeiten ein Wiki zu gestalten.
Der Managementprozess umfasst die Steuerung von Kernprozessen in Organisationen, mit dem Fokus auf die Strukturierung der organisatorischen Rollen und deren Aufgaben. Prozesse sollten transparent dokumentiert und für alle Nutzer zugänglich sein.
Mit einem Wiki kann auch das Management direkten und bindenden Einfluss auf Prozesse nehmen. Dennoch können diese Dokumentationen von Mitarbeitern selbst weiterentwickelt werden und diese Veränderung "von unten" durch das Management kontrolliert werden. Auch Zielsetzung, Planung und Kontrolle kann in einem Wiki einfach und schnell erfolgen.
Vor allem in der gemeinsamen Arbeit über Hierarchien hinweg ist eine Wikikultur unabdingbar. Es Chef muss es proaktiv erlauben das Mitarbeiter seine Vorgaben verbessern und ergänzen. Mitarbeiter müssen wissen das ihre Beiträge erlaubt, ja sogar gewünscht sind. Wikis können helfen die oft entstandene Parallelwelten zwischen oben und unten zu vereinen.
ISO 9001: „Die Organisation muss das Wissen bestimmen, das benötigt wird, um ihre Prozesse durchzuführen […] Dieses Wissen muss aufrechterhalten und in erforderlichem Umfang zur Verfügung gestellt werden. Beim Umgang mit sich ändernden Erfordernissen und Entwicklungstendenzen muss die Organisation […] bestimmen, auf welche Weise jegliches notwendige Zusatzwissen und erforderliche Aktualisierungen erlangt oder darauf zugegriffen werden kann.“
Hauptbestandteil des Qualitätsmanagement ist die Standardisierung von Prozessen, um ein Ergebnis mit gleichbleibender und definierter Qualität zu erreichen. Diese Standardisierung erreicht man durch Dokumentation, Verwirklichung, Aufrechterhaltung und ständiger Verbesserung. [3]
In der Praxis sollen alle Produktions- und Arbeitsschritte dokumentiert und kontinuierlich verbessert werden.
Für die Dokumentation von Arbeitsschritten ist ein Wiki bestens geeignet, da es allen Mitgliedern ermöglicht, Prozessbeschreibungen einzubringen, zu verändern, aber auch Veränderung zu kontrollieren.
Die Prozessbeschreibung sollte möglichst ausführlich und leicht zugänglich sein. Wikis ermöglichen es dem Nutzer Teilinformationen zu erfassen, die sich dann durch Kategorisierung und vor allem durch Verlinkung in das gesamte System einzubetten.
Einzelne Prozessbeschreibungen können ständig ergänzt, verbessert und sogar von dritten Nutzern überprüft werden.
Auch wenn in einem gelebten Wiki alle Inhalte aktuell gehalten werden, kann es passieren, dass Wissen veraltetet. Dafür gibt es Wiki-Software die eine regelmäßigen Überprüfung der Inhalte[4] von definierten Prozesseignern einfordert. Das können Vorgesetzte, Mitarbeiter des Qualitätsmanagements oder fachlich benannte Personen sein.
Der Demingkreis (plan, do, control, act) aus dem Qualitätsmanagement stellt genau die Arbeitsweise eines Wikis dar.
Die Dokumentation im Qualitätsmanagement darf nicht beliebig veränderbar sein.
Prozesse werden vor allem von Anwendern beeinflusst, daher erfordert das Qualitätsmanagement die aktive Einbindung aller am Prozess beteiligter Personen[5]. Ein Wiki ermöglicht eine technisch einfache und offene Integration alle Prozessnutzer. Dennoch kann die Kontrolle der Inhalte einem Prozesseigner unterliegen.
In einem gelebten Qualitätsmanagement innerhalb eines Wikis können die Mitglieder lesen, schreiben, ändern und sind ständig auf dem aktuellen Stand.
Was die Form angeht, schreibt die ISO 9000 nichts vor: „Es ist nicht die Absicht, dieser internationalen Norm zu unterstellen, dass Qualitätsmanagementsysteme einheitlich strukturiert oder einheitlich dokumentiert sein müssen.“[6] Ein Wiki kann zusätzlich als klassisches Qualitätsmanagementhandbuch zudem ausgedruckt und archiviert werden.
Ein wesentliches Alleinstellungsmerkmal jeder Organisation ist das gesammelte explizite und implizite Wissen ihrer Mitglieder. Wissensmanagement versucht, Wissen zu erschließen und zu verteilen. Neben der Fortbildung einzelner Mitglieder ist die Verschriftlichung von Wissen ein Schwerpunkt organisatorischer Wissensarbeit.
Neben der Darstellung von Wissen hilft ein Wiki aber bei der ständigen Erweiterung und dient als Diskussionsgrundlage. Sind organisatorische Inhalte erst einmal dokumentiert, kann dies auch Kritik provozieren. Wird diese Kritik konstruktiv genutzt, können Details ergänzt, präzisiert oder verbessert werden.
Ein Wiki unterstützt diesen Prozess des Austauschens als Medium. Primär dadurch, dass Wissen einfach gesammelt und zu einem Ganzen verknüpft werden kann. Außerdem kann Kritik an bestehendem Wissen über eine Wikiänderung sichtbar gemacht wird. Diese Änderung kann, eine entsprechende Kultur vorausgesetzt, in eine konstruktive Diskussion führen. Dokumentiert Person A einen Prozess und Person B ändert diese Beschreibung, zeigt dies eine unterschiedliche Auffassung bezüglich des Prozesses zwischen Person A und B.
Ein Wiki hilft nicht, diese Meinungsverschiedenheiten zu lösen, dies muss ein Moderator machen. Jedoch verdeutlicht die Wikifunktion den inhaltlichen Konflikt, der sonst im jeweiligen Handeln beider Personen verborgen geblieben wäre.
Im Wissensmanagement unterscheidet man Personalisierung und Kodifizierung von Wissen. Wikis sind, auf den ersten Blick, eine starke Form von Kodifizierung, da das fertig dokumentierte Wissen und die technologische Infrastruktur, losgelöst vom Wissensträger, im Vordergrund steht.
Bei der Personalisierung steht der Mensch als Wissensträger […] im Mittelpunkt der Betrachtung. Vor allem die Entwicklung von Beziehungssystemen und Kommunikationsstrukturen wird fokussiert.[7]
Wikis dienen nicht primär der Wissensentwicklung, sondern der Dokumentation konsolidierten Wissens, also Inhalte, die unstrittig oder bereits allgemeiner Konsens sind. Dennoch ist Wissensentwicklung in einem Wiki möglich. Wikis unterscheiden sich von anderen Dokumentationssystemen in der Art und Weise wie neues Wissen entsteht. Das fokussiert sich auf die Beiträge einzelner Personen, eingebettet in die Inhalte, die andere Nutzer beigesteuert haben. Wikis sind durch ihre Offenheit, aber auch ihre Kontrollstruktur, ein Kommunikationsinstrument[8] das mehr ist als ein Laufwerk voller Worddokumente. Durch diese Kommunikation von Wissen sind Wikis vor allem eine Form des personalisierten Wissensmanagements, das zusätzlich eine wiederverwendbare Aggregation des Wissens erzeugt.
Wird im "wikilosen" personalisierten Wissensmanagement Wissen über persönliche Gespräche, Telefonate, Chats oder E-Mails weitergegeben, kann mit einem Wiki genau diese persönliche Kommunikation kontinuierlich übernommen werden.
Wikis sind eine unsichtbare Form personalisierten Wissens. Von aussen betrachtet ist ein Wikipedia-Artikel für den normalen Internet-User ein von einer anonymen Schwarmintelligenz geschriebener Text. In der Wikipedia-Community aber gibt es zahlreiche informelle und persönliche Strukturen. Jeder Beitrag und Änderung ist einem Autor zugeordnet und wird auch in Zusammenhang mit diesem bewertet. Auch andere Wiki-Communities sind sehr über die Beziehungsgeflechte ihrer Mitglieder definiert, nur ist dies für Außenstehende nicht erkennbar.
Wikis in Organisationen, die viele Wikianfänger integrieren wollen, müssen versuchen, diese versteckte Personalisierung des Wissens wieder zu sichtbar machen:
Man kann bei Prozessdefinitionen den Projekteigner mit angeben, die Ansprechpartner oder das Projektteam nennen, oder eine Liste aller bisherigen Bearbeiter des Wikiartikels anhängen[9].
Bilder oder kleine Visitenkarten der jeweiligen Personen geben diesem kodifizierten Wissen sprichwörtlich ein Gesicht.
Im Rahmen des Projektmanagements werden Projekte, anhand von definierten Prozessen, geplant, gesteuert, kontrolliert und abgeschlossen. Das Projektmanagement unterliegt einer ständigen Dynamik, da Pläne während der Projektlaufzeit oft angepasst werden müssen. Die Kunst des Projektmanagements ist es nun, das Projekt durch Nachsteuern, also durch kleine Planänderungen, das Projektziel zu errichen.
Mit Wikis lassen sich Projekte verwalten, indem inhaltliche Beschreibungen des Projekts, Metadaten (Ansprechpartner, Kosten, etc.), der jeweils aktuelle Status und anstehenden Aufgaben gesammelt und aktualisiert werden.
Eine Projektwiki hat den Vorteil, dass der Status quo, Meilensteine und Abhängigkeiten an einem Ort gesammelt werden.
Einzelne Projektabschnitte, Funktionalitäten oder Untergruppen werden mit ihrer jeweiligen Zielbeschreibung und ihrem Status im Wiki dokumentiert.
Eine Projektbeschreibung in einem Wiki kann beinhalten:
Allgemeine Beschreibung
Die Beschreibung erklärt das Projektziel und spezifische Besonderheiten.
Anforderungen
Projekt-Anforderungen werden als Text hinterlegt und duch Pläne, Skizzen, Diagrammen, Layouts und mehr ergänzt. Ein Wiki ermöglicht es, die Anforderungen einfach zu erfassen und Anforderungsänderungen für alle Beteiligten transparent abzubilden.
Aktueller Status
Der Istzustand sollte beschrieben sein, beispielweise in der Einleitung oder einem eigenen Abschnitt. Durch die Funktion der automatischen Benachrichtigung werden alle Projektbeteiligten auch über Änderungen am Status quo informiert. Gerade der aktuelle Status eines Projekt ist häufigen Änderungen unterworfen und wird aber oft von Führungskräften eingefordert, ohne dass diese sich ständig in das komplette Projektwiki einlesen müssen. Eine häufigen Anforderungen aus der Praxis ist es diese Statusinformationen aggregiert zusammenzufassen, um so aus vielen Projektseiten eine aktuelle Projektstatusübersicht zu sammeln.
Metadaten
Hierzu zählen Fakten wie Ansprechpartner, Projektteam, Ressourcen (notwendige Maschinen und Fahrzeuge, Server, URLs etc) oder der Status. Diese Informationen können nicht nur auf der Projekteseite selbst, sondern auch als strukturierte Daten zusammengefasst und aggregiert werden.
Zeitplan
Alle wichtigen Meilensteine wie Projektstart, Entwurf, Planung, Umsetzung, Test, Prüfungen, Abnahmen und der Projektabschluss können in Listen aufgeführt werden. Dadurch erfahren alle Projektbeteiligten Änderungen zeitnah und haben ständig einen aktuellen Zeitplan vorliegen.
Details
Jedes noch so kleine Detail findet in einem Wiki seinen Platz. Wenn die Detailfülle zu umfangreich wird, lassen sich Artikel aufteilen. Dieses spezifische Wissen verändert sich und veraltet, daher müssen Detailseiten und Abschnitte regelmäßig überarbeitet oder archiviert werden.
Ergebnisse
Die ständig aktualisierten Projektinformationen bilden nach Abschluss des Projekts automatisch eine komplette Dokumentation für spätere Projekte. Im Idealfall fließen alle Erfahrungen des Projekts in die strategische Prozessdefinition mit ein.
Gebrauchsdokumentation
In einem Projektwiki kann während des Projektverlaufs auch eine Gebrauchsanweisung für das abgeschlossene Projekt oder das fertige Produkt erstellt werden (zum Beispiel für Software, QM-Verfahrenseinführung, Nutzungsbeschreibungen für Bauvorhaben).
Rudimentäre Aufgabenverwaltung
Zudem lassen sich einfache To-do-Listen, sortiert nach Priorität oder Nutzer, erstellen und verwalten. Natürlich nur, sofern kein Issue-Tracking-System zur Verfügung steht. Die Wikisoftware Confluence bietet sogar die Möglichkeit, automatische Task-Listen mit Zuordnung und Status zu verwalten.[10]
Projekte bestehen aus Unterprojekten, Abschnitten und Einzelaufgaben, die in zeitlicher und organisatorischer Abhängigkeit zueinander stehen. Projekte sind etliche einzelnen Teilaufgaben mit definierten Anforderungen und aktuellem Status, Priorität, gegebenenfalls Ort, Zeit- und Ressourcen-Zuordnung.
Wikis erfassen Einzelaufgaben, Abschnitte oder Unterprojekte nur als einfache To-do-Listen in einem Artikel oder in Unterartikeln für größere Einzelaufgaben.
Moderne und agile Projektmanagement-Methoden wie Scrum oder Kanban setzen, neben einer ebenfalls unhierachischen Gruppenstruktur, vor allem auf Anpassungsmöglichkeit, Transparenz und Visualisierung von Aufgaben. Scrum arbeitet mit User-Stories und Backlogs, Kanban mit einzelnen Tasks auf einer Kanban-Tafel. Die Anforderungen an Anpassungsmöglichkeit, Transparenz und Visualisierung können Wikis gut abbilden.
Leider ist es schwierig, Übersichten über Teilaufgaben nach Status, Priorität und Zuordnung einfach darzustellen, da Wikis Artikel zwar kategorisieren können, diese aber meist nicht kombiniert abbilden können.
So ist es kaum möglich, alle Aufgaben eines Projekts mit einer bestimmten Priorität und dem zugeordneten Bearbeiter auszugeben.
Dafür gibt es spezielle Projektmanagement-Software und Issue-Tracking-Systeme. Diese dienen primär zur transparenten Darstellung von aktuellen Aufgaben, Abhängigkeiten und Status.
Zudem ist es schwierig Backlogs und Kanban-Boards in einem Wiki wirklich übersichtlich darzustellen. Papier auf einem Whitebord ist sogar noch flexibler, übersichtlicher und für alle Nutzer transparenter und einsehbarer als ein Wiki.
Dennoch können Projektmanagement-Software und Issue-Tracking-Systeme auch im Projektmanagement ein Wiki nicht ersetzen. Denn diese zeigen nur aktuelle Teilprojekte und Aufgaben, aber kein aktuelles Gesamtbild mit Ziel, Metadaten und Ergebnissen.
Ein Wiki den aktuellen Status des Projekts und dessen strukturelle Informationen dokumentieren und einfach zur Verfügung stellen und nach der Projektlaufzeit, wenn alle Tickets und Aufgaben geschlossen sind, Endergebnis und Erfahrungen aufzeigen. Auch zusätzliche Artefakte, wie die Definition of Done und andere Prozessvereinbarungen aus agilen Methoden, können im Wiki gemeinsam verwaltet werden.
Rückfragen, Aufforderungen zur genaueren Spezifikation, Kommentare oder Arbeitsaufträge müssen in Projektwikis über die etablierten Wege der direkten Kommunikation (wie persönliches Gespräch, Telefon, Chat oder Besprechungen) geführt werden.
Selbst wenn jedes Wiki eine Uploadfunktion hat, mit welcher man Daten aller Art zentral zugänglich speichern kann, ist ein Wiki grundsätzlich kein Dokumentenmanagementsystem für externe oder eingescannte Dokumente.
Unveränderliche Dokumente, auch elektronische, gehören nicht im großen Maßstab in ein Wiki. Verträge,
kaufmännische Dokumente (Rechnungen, Belege) oder Offline-Benutzerdokumentationen sollen in einem Dokumentenmanagementsystem oder einem normalen Dateisystem gespeichert werden. Natürlich gilt auch hier: lieber im Wiki als in verstreuten Rundmails.
Allerdings kann ein Wiki Inhalte für Dokumente verwalten. Ein Vertragsmuster kann so aktuell gehalten, von allen Beteiligten kontrolliert und sogar über Schnittstelle und APIs, an andere Systeme wie Officeprogramme, Website, Drucker übergeben werden.
Für alle Arten von Arbeitsdokumenten lassen sich Entwürfe gemeinsam verwalten und pflegen:
Textbausteine für Einladungen, Absagen, Ausschreibungen, Änderungsbestätigungen, Betriebsausfälle
Vorlagen für Hinweisschilder
Checklisten für Veranstaltungen, Urlaubsvertretung, Notfälle
Gebrauchsanleitungen für technische Geräte, Verfahren oder Tätigkeiten bedürfen einer hohen Aktualität und Verständlichkeit. Nutzer ohne einschlägige fachliche Vorbildung sollen den Inhalt verstehen können.
Da Wikis einem ständigen Verbesserungsprozess unterliegen, können auftretende Unklarheiten nach der Klärung sofort in das Wiki einfließen und ermöglichen dadurch anderen Nutzern ein besseres Verständnis.
Vor allem Software-Benutzerdokumentationen sind oft komplex und müssen häufig geändert werden, beispielsweise wenn neue Funktionen zur Veröffentlichung anstehen. Ein gut gepflegtes Wiki verringert den Supportaufwand, vor allem im First-Level-Support.
Sogar Anwender, im kommerziellen Bereich Kunden, können im Wiki Verbesserungen beitragen und so an einer gemeinsamen Dokumentation mitwirken. In der Anwendung für Softwareanleitung ist außerdem eine direkte Verknüpfung auf spezifische Wikiartikel aus der Software heraus möglich.[11]
Wikis können auch Lehrinhalte sammeln, verbessern, konsolidieren und für Lehrer sowie Schüler bereitstellen.
Öffentliche Schulen unterrichten nach einem vorgegebenen Lehrplan, der aber nur Lehrziele vorgibt.
Konkrete Inhalte können und müssen vom Lehrpersonal selbst erstellt werden.
Beginnt man in einem Bildungswiki mit einer Übersichtseite eines Lehrplans, können dessen einzelne Themen auf Unterseiten verlinkt werden.
Diese Themenseiten beinhalten die jeweilige didaktische Reduktion eines Unterrichtsthemas.
Hier können dazu passende Übungen, Unterrichtsentwürfe oder Tafelbilder weiter verlinkt werden.
Lehrer und Schüler können diese in einem Wiki auch gemeinsam verbessern.
Schüler beschäftigen sich intensiv mit den Lehrinhalten und hinterfragen diese mit unverstelltem Blick.
Schüler können daher Inhalte verbessern, ergänzen und für ihre eigene Zielgruppe verständlicher schreiben.
Wikis kommen vor allem in der internen Kommunikation zum Einsatz. Aber auch in der externen Unternehmenskommunikation sind Wikis einsetzbar, wenn der aktive und beitragende Nutzerkreis auch auf Kunden oder einen externen Personenkreis ausgeweitet werden soll. Allerdings ist noch kein Fall bekannt, bei dem eine Organisation ein nach außen offenes Wiki nutzt.
Sperrt man externe Nutzer aus, kann man ein Wiki auch als CMS nutzen.
↑Die Organisation muss entsprechend den Anforderungen dieser Internationalen Norm ein Qualitätsmanagementsystem aufbauen, dokumentieren, verwirklichen, aufrechterhalten und dessen Wirksamkeit ständig verbessern. aus DIN EN ISO 9001 4.1 Allgemeine Anforderungen
↑"Auf allen Ebenen machen Personen das Wesen einer Organisation aus, und ihre vollständige Einbeziehung ermöglicht, ihre Fähigkeiten zum Nutzen der Organisation einzusetzen." DIN EN ISO 9000 - 0.2 Grundsätze des Qualitätsmanagements c) Einbeziehung der Personen}}
Ein Wiki ist eine flexible Software. Neben der Anwendung als Wissens-, Prozess- und Projektdokumentation könnte ein Wiki auch bei vielen anderen Aufgaben helfen: Kundenanforderungen, Beschaffungen, Planungen, interne Kommunikation, Termine oder auch Adressverwaltung lassen sich in einem Wiki erfassen und verbessern. Das funktioniert ganz einfach: Alle Informationseinheiten bekommen eine eigene Seite und werden dann von allen Beteiligten reihum bearbeitet.
Das ist jedoch nicht empfehlenswert. Viele Aufgaben lassen sich durch konkrete Software wesentlich besser und effizienter organisieren. Denn Wikis sollen lösungsspezifische Software nicht ersetzen, sondern einen ergänzenden Rahmen bilden.
Ein Wiki kann jedoch nur der universale Speicherort für alles Wissen sein, was sonst keinen definierten Platz hat. Wenn man keine spezielle und leistungsfähige Software hat, sollten die Informationen im Wiki bleiben. Lieber Information in einem Wiki gespeichert, als nirgendwo.
Wissensbasierte Anwendungen wie Prozess- und Verfahrensdokumentation können in einem Wiki sehr hoch skalieren. Überschaubare administrative Prozesse oder wenige Projekte können in einem Wiki einfach und ohne viel Aufwand verwaltet werden. So werden Strukturen und Inhalte in der laufenden Benutzung an entstehenden Bedürfnisse angepasst.
Wird die Anzahl der Einträge oder Datensätze eines Genres größer, stößt ein Wiki jedoch an seine Grenzen. Dann müssen spezialisierte Softwarelösungen zum Einsatz kommen: eine Lieferantendatenbank, ein Issue-Tracking-System oder ein CRM, um nur einige Beispiele zu nennen.
Ein Wiki soll aber weiterhin auf diese Spezialanwendung verweisen und kann deren Metadaten aufnehmen. Gebrauchsanweisungen, Zuständigkeiten oder Nutzungsregeln verbleiben weiterhin im Wiki.
Denn ein Wiki ist geeignet, um Datenstrukturen, Prozesse und Aufgaben zu dokumentieren.
Die rudimentäre Verwaltung von kleinen Datengenres in einem Wiki hat den Vorteil, dass sich Strukturbedürfnisse einfach lösen lassen und vielleicht sogar Anforderungen an eine Spezialanwendung skizzieren.
Insofern kann es sinnvoll sein, ein Issue-Tracking-System erst später einzuführen, wenn man im Wiki vorher "geübt" hat und weiß, welche Voraussetzungen, Funktionen oder konkrete Datenfelder wirklich gebraucht werden.
Wikis sollen Prozesse beschreiben, nicht jedoch ausführen.
Vor allem für Kernprozesse wird auf spezielle Softwarelösungen zurückgegriffen: Warenwirtschaftssysteme, Auftragsverwaltungen, Ticketsysteme oder Software zur Begleitung der Fertigung. Aber auch Supportprozesse werden je nach Häufigkeit oder Organisationsgröße softwaretechnisch begleitet. Doch auch ohne Software lassen sich Prozesse begleiten, denn auch Formulare, Laufzettel oder bauliche Maßnahmen können Prozesse leiten.
Diese Systeme haben eine inhärente Prozessbeschreibung, aus der ein Anwender nicht ausbrechen soll, kann oder darf.
Ein Wiki sollte auf diese Prozessbeschreibung zumindest hinweisen ("und folgen Sie den Anweisungen des Protokoll") und alle zugehörigen, nicht inhärenten Informationen sammeln. Das kann bei einer Software oder Maschine die Dokumentation, die Zuständigkeit oder Besonderheiten, die es zu beachten gilt, sein.
Zusätzlich kann es aber sinnvoll sein, auch alle Prozessbeschreibungen zusätzlich zu dokumentieren, am besten in einem Wiki, um diese Prozesse transparent für alle verständlich diskutieren oder auch schulen zu können. Wenn beispielsweise ein Buchhaltungsprogramm durch seinen Kontenrahmen die dazugehörigen Buchungsprozesse beschreibt, ist nicht jeder Kontenrahmen immer selbst-erklärend, eine Erläuterung im Wiki hilft den Nutzern, diese zu verstehen.
Nebensächliche Prozesse, oder diejenigen Prozesse, die keine spezielle Softwarelösung oder ein anderes Leitsystem haben, können mithilfe von Wikis unterstützt werden.
In Wikis lassen sich einfache Ablauflisten oder -pläne erstellen und diese manuell oder auf einem Ausdruck abarbeiten.
Prinzipiell ist es möglich, den Arbeitsablauf mit einem Wiki zu steuern. Dies verlangt jedoch etwas mehr Disziplin und manuellen Aufwand.
Es ist durchaus sinnvoll, Status, Meilensteine und einfache To-do-Listen für das Projektmanagement in einem Wiki zu führen und längerfristige Aufgaben und Ziele in einem Wiki zu dokumentieren. Das ist auf jeden Fall besser als gar keine Verschriftlichung, ewige umlaufende Massenemails oder eine zweckentfremdete Software aus dem Kerngeschäft.
Für einige Informationen ist es nicht sinnvoll oder sogar falsch, sie in einem Wiki ziu speichern:
Selbst wenn es angenehm wäre, Passwörter im Wiki mit zu speichern, ist dies grob fahrlässig. Passwörter müssen verschlüsselt gespeichert werden. Derzeit ist kein Wikisystem bekannt, das Informationen auch verschlüsselt speichern kann. Für Passwörter gibt es spezialisierte Kennwortverwaltungen. Es spricht aber nichts dagegen URLs, und allgemein zugängliche Benutzernamen zu dokumentieren. Ein zusätzlicher Link auf die Seite Passwort kann wiederum erklären, welche Kennwortverwaltung genutzt wird, wo sich diese befindet und woher man das Hauptkennwort bekommt.
Personenbezogene Daten über Mitarbeiter, Nutzer oder Kunden sollten nur öffentlich zugängliche Daten enthalten. Namen, Telefonnummern und Funktionen können sicherlich auch in einem Wiki gespeichert werden. Auch sollten Nutzer selbst preisgeben, welche Informationen sie von sich eintragen. Daten aus dem Bereich der Personalverwaltung (Beurteilungen, Abmehnungen oder Stammdaten wie Krankenkasse) dürfen keinesfalls abgelegt werden.
Die scheinbar einfache Möglichkeit, E-Mails oder sonstige Dokumente nicht zu ordnen und bei Bedarf zu suchen, klingt zwar verlockend einfach, hat aber den Nachteil, dass man stets wissen muss, wonach man sucht. Eine Information, die man nicht kennt, wird man nie suchen, geschweige den finden. Und selbst wenn man weiß: "da war ne E-Mail,…", muss man immer noch wissen, was außerdem in diesem Dokument stand (Absender, Formulierung, Schlagworte), nach passenden Suchbegriffen suchen zu können.
Eine leistungsfähige Wikisuche ist wichtig für den Zugang zu Information. Dennoch ist ein Wiki keine "Enterprise Search". Wikis sollen lediglich Inhalte für die Suche bereitstellen.
E-Mail ist ein wunderbares Medium, um Nachrichten an Personen zu versenden die ein Wiki nicht regelmäßig besuchen wollen oder können.
Allerdings eignen sich E-Mails nicht als Wissensspeicher, da man keinen Einfluss auf bestehende Inhalte nehmen kann, um Verbesserung und Ergänzungen einzupflegen. Die einzige Möglichkeit Informationen zu strukturieren, ist das Verschieben in Ordner. Diese Struktur muss aber jeder Empfänger selbst erstellen. Eine gemeinsame Ordnung und damit auch Inhaltsverbesserung ist mit Emails nicht möglich.
E-Mail ist ein Push-Medium, da Leser aktiv informiert werden. Wikis sind eine Wissensbasis aus der sich der Leser passiv bedienen muss. Trotz Wiki braucht man weiterhin E-Mails, um eine Person direkt anzusprechen. Auch um Personen zu informieren der keinen Zugang zu einem Wiki hat.
Dennoch ergänzen sich Emails und Wikis: Werden Inhalte in einem Wiki gesammelt und regelmäßig aktualisiert, muss in der Emailkommunikation nicht jede Frage oder Hinweis neu formuliert werden. Vielmehr kann auf das Wiki verwiesen werden.
Mailinglisten oder auch Newsletter haben meist Archive, in denen die bisherige Kommunikation eingesehen werden kann. Das ist vor allem nützlich, wenn Themen und Fragen immer wieder auftauchen.
Dennoch kann dieses archivierte Wissen nicht verbessert und strukturiert werden. Es können immer nur jeweils neue E-Mails an Beitragshistorien angehängt werden. So muss sich jeder Nutzer, der Wissen sucht, dieses aus einzelnen Mails zusammensuchen, bewerten und einordnen.
Die häufigste Plattform zur internen digitalen Zusammenarbeit ist die gemeinsame Nutzung von Dateifreigaben (auch Netzlaufwerk genannt) oder neuerdings, vor allem für Nutzer an unterschiedlichen Standorten, Clouddienste wie Dropbox. Inhalte werden in unterschiedlichen Dokumenttypen (Text, Tabelle, Präsentationen) und Datentypen (Text, Bild, Ton) gespeichert und können, je nach Berechtigungsstruktur, von Nutzern gelesen oder bearbeitet werden.
Der Vorteil von Netzlaufwerken ist die einfache Bedienung und die standardmäßige Einbindung von lokalen Computern. Ein weiterer Vorteil ist, dass Netzlaufwerke sehr große Mengen an Daten verwalten können. Für die klassische Büroumgebung ist ein Netzlaufwerk weiterhin unumgänglich.
Leider haben Netzlaufwerke keine Funktion zur Änderungsverfolgung, die informieren ihre Nutzer nicht über Änderungen an Dokumenten.
Dokumentinterne Versionsverwaltungen, wie die Änderungsverfolgung in MS Word oder Libre Office, sind nur optional aktivierbar und bei vielen und großen Umarbeitungen schwierig zurück zu verfolgen. Außerdem gibt es keine erprobte Lösung, die Änderungen innerhalb eines gesamten Netzlaufwerk darstellen.
Als Ordnungsstruktur stehen nur Datei- oder hierarchisch gegliederte Ordnernamen zur Verfügung. Verlinkungen innerhalb von Dokumenten sind in manchen Dokumentformaten möglich, werden aber selten genutzt. Eine Kategorisierung von Inhalten kann ohne Zusatzsoftware gar nicht erfolgen.
Um eine einheitliche und für viele Nutzer verständliche Ordnung zu schaffen, werden Ordnerbereiche oft standardmäßig mit einer Ordnervorlage angelegt. Das kann ein Versuch sein, gemeinsam zu arbeiten, führt aber oft zu unflexiblen Konstrukten. So benötigt beispielsweise ein kaufmännisches Projekt den Unterordner Abrechnung, ein technisches Projekt dafür einen mit der Bezeichnung technische Unterlagen. Befinden sich in beiden Projekten beide Ordner suchen Mitarbeiter dann entweder in leeren und verwaisten Unterordnern oder müssen sich in vielen unstrukturierten Dokumenten zurecht finden.
Auch wenn der Zugriff über Office-PCs einfach ist. Externe Nutzung oder der mobile Zugriff ist im Vergleich zu einem Wiki aufwändiger.
Dateifreigabe sind der richtige Ort für große und beständige Dateien (Verträge, externe Dokumentationen). Für Text und Beschreibung ist ein Wiki besser. Man sollte Dateifreigaben mit Wikis sinnvoll verknüpfen. Mit file-links file:///gemeinsamedateien/ (je nach Client-Betriebssystem unterschiedlich) kann man aus dem Wiki heraus auf Dateien in Netzlaufwerken verweisen.
Ein Wiki sollte prinzipiell keinen Personal Information Manager (wie Outlook, Thunderbird, Kalender) ersetzen. Termine und Adressen können zwar in einem Wiki notiert werden. Zu diesem Zweck sind aber Anwendungen oder Austauschformate wie .vcf besser. Diese Anwendungen haben nicht zuletzt sinnvolle und praktische Funktionen, wie Warnung bei Terminüberschneidung oder Erinnerungsmitteilungen.
Selbst wenn einige Informationen nicht in einem Wiki verwaltet werden, sollten diese im organisatorischen Gesamtkonstrukt nicht isoliert werden. Das Wiki muss auf andere Kanäle und Tools hinweisen, andererseits müssen diese auf das Wiki zurückweisen oder zumindest im Wiki beschrieben sein.
Werden beispielsweise Geschäftsbriefe in einem gemeinsamen Dateisystemen verwaltet, kann im Wiki vermerkt sein wo sich dieses befindet und nach welcher Ablagestruktur es geführt wird.
Am einfachsten kann man per Webbrowser (http) aus einem Wiki (beispielsweise auf eine bestimmtes Ticket in einem Ticketsystem) und wieder zurück (auf die entsprechende Wikiseite) verknüpfen. Kurzlinks (z.B {{Ticket|1234567}}) erleichtern das externe Verlinken.
Zudem können Informationen aus einem Wiki über Programmierschnittstellen abgefragt und anderweitig genutzt werden. Umgekehrt kann ein Wiki Informationen aus einer anderen Software auslesen (offene Tickets zu einem Projekt, Adressinformation, etc).
Wikis sind eine Form von Social Media. Social Media ermöglicht es Nutzern, sich untereinander auszutauschen und mediale Inhalte einzeln oder in Gemeinschaft zu erstellen und auszutauschen.
Stehen bei anderen Formen von Social Media vor allem die direkte Kommunikation von meist von Einzelnen erstellten Inhalten mit einer Gruppe im Vordergrund, ermöglichen Wikis kollaboratives Schreiben mit einer ganzen Gruppe.
Neben Wikis gibt es zahlreiche andere Formate und Tools für den organisatorischen Einsatz. Die meisten Formen von Social Media sind kommentierend. In (Micro-)Blogs, Foren, sozialen Netzwerken oder Videoplattformen können User zwar User-generated content erstellen. Andere Nutzer können diese aber nur kommentieren oder replizieren, und sind nicht in der Lage diese direkt verändern. In Wikis können Inhalte von einer Gruppe gemeinschaftlich erstellt werden, indem Teilstücke und Ergänzungen eingebracht oder Fehler behoben werden.
Foren oder Blogs sind gute Kommunikationskanäle für den Austausch. Wenn mehr Inhalte einfließen leiden diese unter Unordnung und Informationsüberfluss. Werden in einem Forenthread zahlreiche Nachfragen abgesetzt und Antworten gegeben, ist oft schwer nachvollziehbar, welche die richtige ist; auch dann wenn zahlreiche Frage-Antwort Foren, wie z.B. Stack Overflow, es ermöglichen, Beiträge zu bewerten. Auch Twitter oder ein organisations-interner Microbloggingdienst ist eine unkomplizierte Möglichkeit, um eine Antwort aus einem angesprochenen Personenkreis zu erhalten. Jedoch Bedarf es viel Zeit all die vielen, wenn auch kurzen, Nachrichten zu lesen.
Wikis haben den Vorteil, dass Informationen und Wissen schnell gesammelt und verändert werden kann, jedoch dauerhaft bestehen bleibt.
Foren, Blogs, Microblogs, Chats aber auch E-Mails können sinnvoll mit Wikis kombiniert werden, indem einfach und direkt kommuniziert wird und auf den aktuellen Wissenstand im Wiki verwiesen wird. Chatten und Microbloggen ist immer noch am effektivsten, wenn man Links, im Idealfall auf das Wiki, verschicken kann.
Beispiel: Eine Mitarbeiter kennt zwar die Firmenfarbe in RGB, aber er muss einen Drucker beauftragen und dieser benötigt die Firmenfarbe in CMYK. Im Firmenchat nachgefragt bekommt er von einem printkundigen Kollegen die Erklärung was CMYK ist und einen Link auf die Seite Corporate Design.
Wikis sind nicht die einzigen Kollaborationstools. Im Wiki kann man Texte gemeinsam bearbeiten, diese aber immer nur nacheinander. Zum gleichzeitigen Bearbeiten von Texten (z.B. wenn die PR und der Vertrieb gleichzeitig an einer eilige Pressemeldung arbeiten) sind Live-Text-Tools wie EtherPad besser geeignet. Diese bieten aber nur einzelne Seiten, keinerlei Möglichkeit zu Strukturierung oder persistente Versionierung. Kombinationen aus Wiki und Etherpad sind noch in der Testphase.
Der Begriff Wiki wird oft mit dem Projekt Wikipedia assoziiert, oder zumindest mit öffentlichen Wikis.
Organisationsintere Wikis nutzen zwar die Technologie, einfachere Prozesse und flache Hierarchien von Wikis, dennoch gibt es Unterschiede. Oft erzeugt die Idee eines Firmenwikis Verwirrung: Warum sollen wir unsere Inhalte von Fremden in so einer Wikipedia erstellen lassen?. Organisationswikis sind eigene, nicht-öffentliche Wikiprojekte die sich von öffentlichen Wikis unterscheiden:
Zugriff
Öffentliche Wikis sind für die Öffentlichkeit lesbar. Geschäftsgeheimnisse und Prozesse sollen eine Organisation nicht verlassen. Interne Wikis sind genauso nut für den bestimmten Personenkreis zugänglich wie jede andere interne Software auch.
Vandalismus und Spam
Auf Wiki-Intranets haben nur bekannte und registrierte Nutzer Zugriff, mutwilliges oder fahrlässiges Verhalten kann direkt mit dem Verursacher geklärt und unterbunden werden.
Inhaltlicher Anspruch
Wikipedia und andere öffentliche Wikis haben den Anspruch neutrale Enzyklopädien, Glossare oder Wörterbücher zu sein. Organisationswikis dokumentieren organisatorische Inhalte. In einem Firmenwiki sollte die Information zu Weihnachtsgeld nicht dessen historische Geschichte aufgreifen, dafür wäre Wikipedia der geeignet Ort; intern geht es um die Höhe der Auszahlung oder um firmeninterne Regelungen zu Gratifikationen der jeweiligen Firma.
Auch wenn viele Wikis Möglichkeiten zur direkten Kommunikation der Nutzer untereinander bieten, ist dies in einer bestehenden und gewachsenen Organisation nicht immer sinnvoll.
Wenn es bereits digitale Kommunikationskanäle wie E-Mail oder Instant-Messenger gibt, benötigt man nicht unbedingt ein zusätzliches Tool im Wiki. Es führt eher zu einer Streuung der Aufmerksamkeit, wenn Nutzer Nachrichten über einen zusätzlichen Kanal erreichen.
Man kann organisationsinterne Nachfragen, Aufforderungen oder Hinweise auch per E-Mail verschicken.
Der Unternehmenskommunikation stehen zahlreiche Kanäle zur Verfügung. Digitale Kanäle sind vor allem Corporate Websites oder moderierte Social-Media-Kanäle. Eine aktive Einbindung der Öffentlichkeit in die eigene klassische Unternehmenskommunikation ist meist nicht gewünscht.
Ein offener Ansatz kann aber durchaus erlauben ein öffentliches Wiki für bestimmte externe Dokumentationen zu nutzen. Beispiel:
Aktive Kunden oder Betanutzer können gemeinsam mit der Supportabteilung die Dokumentation einer Software pflegen.
Wikis sind in erster Linie eine Frage der der Organisationskultur und weniger der Technik. Sie sind eine Möglichkeit, Informationen zu sammeln, pragmatisch infrage zu stellen oder zu diskutieren.
Das Sammeln von Wissen läuft unbürokratischer und schneller ab, vor allem im Vertrauen auf jeden Teilnehmer, Veränderungen eigenverantwortlich durchführen zu können. Klassische Verantwortlichkeitsstrukturen und Zuständigkeiten werden nicht infrage gestellt, aber dynamisch vollzogen. Ein Wiki will nicht die Organisationsstrukturen ändern, sondern die Kommunikationsstruktur vereinfachen, im Vertrauen in die Fähigkeiten und das Verantwortungsbewusstsein[1] der Nutzer.
Auch wenn Wikis langfristig einen hohen Mehrwert bieten, zuerst müssen Inhalte von den Nutzern erstellt und das Wiki akzeptiert werden. Die Bereitschaft der Nutzer mit einem Wiki zu arbeiten hängt vor allem von unterschiedlichen Kriterien ab:
Vom Verständnis, dass sich der Arbeitsaufwand eines Wiki lohnt.
Von der Fähigkeit, einfach, frustfrei und auch freudvoll[2] Inhalte beitragen zu können.
Von der Möglichkeit, auch in einem umfangreichen Wiki Inhalte von anderen Nutzern problemlos aufzufinden.
Können Nutzer kleine alltägliche Probleme anhand von Wissen aus einem Wiki lösen, führt das zu Erfolgen, die motivieren. Werden Informationen die unzureichend (unaktuell, falsch, unvollständig) oder gar nicht dokumentiert sind, im Wiki gesammelt, und dann, auch von anderen in dieser Form wiederverwendet, reift das Verständnis für die Wikilogik.
Ein Wiki kann auf die Belegschaft motivierend wirken und sich dynamisch entwickeln[3]. Basierend darauf, dass sich jeder aktiv beteiligen kann und Ergebnisse sofort sieht.
Um mehr Menschen zu überzeugen, im Wiki nachzuschauen und sich aktiv daran zu beteiligen, müssen Vorbehalte abgebaut werden. Zudem gibt es Verlustängste, was die eigenen Kompetenz angeht, Berührungsängste mit der Technik oder Frustration weil, man Inhalte nicht finden kann oder Schwierigkeiten beim Beitragen hat.
Hier sollten aktive "Wikigärtner" Nutzer im persönlichen Gespräch betreuen.[4].
Die Ein-Prozent-Regel von freien Projekten darf nicht für Organisationswikis gelten.
Wie viele aktiv schreibende und administrierende Teilnehmer braucht ein Wiki? Eine absolute oder relative Definition der kritischen Masse an Lesern und Schreibern zum Funktionieren eines Wikis ist nur ansatzweise möglich, da diese von einigen Variablen und Einflussfaktoren, wie Arbeitsweise im Wiki und Themengebiet, abhängig ist.[5]
Jedes Wiki ist auch als persönliches Wissensmanagement für eine einzige Person geeignet. Das große kollaborative Potential entwickelt sich bei einem Wiki jedoch erst in der Gruppe. So können vor allem kleine Gruppen für ihren Bereich schnell eine effektive Informationsgrundlage schaffen. Von einer solchen Keimzelle aus kann ein Wiki rasch wachsen und zu einem großen Ganzen werden.
Die Verteilung von Schreibern und Nutzern in offenen, freien Projekten folgt in etwa der 90-9-1 Prozent-Regel von Jakob Nielsen.
Wendet man diese Regel für Organisationen wie Firmen oder Vereine, wäre das die Aufgabenverteilung eines klassischen Intranets: Wenige schreiben aktiv, viele lesen nur mit.
Wikis in Organisationen sollen aber das konkrete Wissen und dessen Modifikation direkt, ohne redaktionelle Umwege, verwalten. Auch wenn es nicht nötig ist, dass alle Mitarbeiter oder Mitglieder das Wiki nutzen, ein effektives Austauschmedium wird es nur durch eine signifikant hohe Beteiligung.
Ein konkretes Ziel für ein funktionierendes Wiki: Mindestens 5 Prozent bis 10 Prozent der Nutzer betätigen sich als Autoren, die 30 Prozent des Inhaltes einbringen.[5]
Gute Erfahrungswerte liegen bei 20 Prozent[6]. Bei aktiven Wikis sind es über 50 Prozent[7].
Neben einer intrinsischen Prozessmotivation und dem internen Selbstverständnis braucht es für jede Mitarbeit auch extrinsische Motivation. Gerade in kommerziellen Organisationen, also Wirtschaftsunternehmen, die auf dem Austausch von Leistung gegen Entgelt basieren, kann die Aufgabe des Wissensmanagements nicht plötzlich gratis verlangt werden.
Auch dann, wenn Dokumentationsaufgaben von Mitarbeitern auf eigenem Wunsch, als Projekt außerhalb der Kernaufgabe erledigt werden. Selbst die Aufgabe des Wikigärtners ist nicht "nebenher" zu leisten.
Ein außergewöhnliches Incentive ist die Schaufel aus Intellipedia
Auch wenn Dokumentationsarbeit im Wiki ein Teil eines jeden Arbeitsbereichs ist, sollten gute Leistungen dennoch besonders hervorgehoben werden.
Arbeit für das Wiki sollte genauso honoriert werden wie Projekt- oder administrative Arbeit. Gibt es in einem Betrieb Anreize, sollten diesen auch für die Mitarbeit am Wiki zum Einsatz kommen.[8]
Selbst Wikipedia, die scheinbar von unsichtbaren Autoren geschriebene wird, kennt ein System zur Anerkennung von Leistung. Innerhalb der Community gibt es Auszeichnungen für exzellente Artikel oder Lekoratsarbeit.
Die vermutlich größte extrinsische Motivation in der Wikipedia ist das Wissen, dass die Arbeit von einem breiten Publikum gelesen wird.
Bei einem internen Wiki ist das Publikum natürlich kleiner und der Autor weiß nicht, ob sein Text gelesen wird. "Doch ohne Publikum sind wir nicht motiviert."[9]Daher gehört es auch zur Wikikultur, Wissensarbeit sichtbar zu machen und den Nutzen von Wissen wertzuschätzen.
Neben der Motivation ist auch die Fähigkeit der Nutzer relevant, Inhalte beizutragen. Technisch ist das Schreiben in einem Wiki meist recht einfach, auch wenn manche Nutzer mit der Wikisyntax geschult werden müssen oder auch ein WYSIWG-Editor erklärt werden muss.
Wichtiger als die technische Kompetenz ist die Fähigkeit, implizites Wissen als explizites, und damit organisatorisch nutzbares, Wissen zu verschriftlichen.
Das fällt vielen Nutzern schwer, denn nicht jeder gute Techniker, Buchhalter oder Servicemitarbeiter ist auch ein guter technischer Redakteur.
Oft schreiben Nutzer kurze stichpunktartige Listen, oder lassen scheinbar unwichtige Details weg, die aber eine unbeteiligte dritte Person zum Verständnis braucht.
Doch kein Nutzer muss auf die Journalistenschule, um einen Arbeitsprozess oder ein Projekt zu beschreiben. "Learning by Doing" klappt hier hervorragend, wenn es Unterstützung durch Wikigärtner gibt und kein Nutzer mit Fragen zum Format, Links, Sprache und Struktur alleingelassen wird.
Natürlich soll es nie das Ziel sein, dass Verfahrens- oder Projektwissen nur durch Beschreibungen vermittelt wird. Es darf und muss, trotz Wiki, weiterhin miteinander geredet werden. Ein Wiki unterstützt die Kommunikation mit dauerhaft dokumentierten Wissen.
Gegenüber rein kommentierenden Systemen, wie Blogs, hat das den Vorteil, dass Ergänzungen, Verbesserungen oder Präzisierungen nicht erst angemerkt und vom Ersteller eingepflegt werden müssen. Vielmehr können Inhalte, unabhängig von ihren Initiatoren, wachsen.
Änderung am "eigenen Text" setzen jedoch beim Autor das Bewusstsein voraus, dass Änderungen durch andere Nutzer zu einem besseren Gesamtergebnis führen können.
Außerdem ist die Bereitschaft wichtig, über Änderungen, die dem Autor missfallen oder objektiv gesehen schlechter sind, zu diskutieren.
Wichtig ist ein konstruktiver Diskurs zwischen allen Beteiligten.
Kollaboratives Schreiben verlangt von Nutzern aber auch, sich in bereits bestehende gemeinsame Strukturen einzufinden und hier konstruktiv beizutragen. Die Hemmschwelle in "fremden" Texten zu schreiben, muss manchmal überwunden werden.
Das setzt eine Organisations-Kultur voraus, die von guten Absichten ausgeht und allen Nutzern Wohlwollen unterstellt und entgegen bringt.
Zu erst muss eine Kultur der Zusammenarbeiten existieren. Wichtiger ist aber, dass diese angenommen und gelebt wird. Dies Kultur ist auch ein Grundprinzip von Wikipedia[10] und anderen großen kollaborativen Projekten.
Selbst wenn Inhalte richtig aufgebaut sind und die Suche technisch funktioniert, finden manche Nutzer nicht wonach sie suchen, weil sie falsch suchen oder nicht bereit sind, der semantischen Verknüpfung durch Links und Kategorien zu folgen. Sie erwarten Inhalte an der Stelle, an der dieser für sie subjektiv gesehen stehen sollte. Da aber jeder Mensch Wissen unterschiedlich einordnet, sind auch die Zugangswege mannigfaltig.
Wikis können diese unterschiedlichen Zugangspfade zu Wissen darstellen. Ein zusätzlicher Satz und ein Link auf die Information an der Stelle, wo anderer Nutzer diese erwarten würden, und der Nächste findet die Information sofort. Manchmal werden Informationen nur über alternative Begriffe gefunden. Werden diese alternativen Assoziationen als Weiterleitung aufgenommen, verbessert das die Auffindbarkeit von Inhalten für andere Nutzer.
Neben den gesuchten Informationen soll auch der dazugehörige Kontext aufzufinden sein.
Beispielsweise soll auf einer Projektdokumentationsseite die entsprechenden Prozesse nicht nur benannt, sondern auch damit verlinkt werden. So bekommt der Nutzer über diese Assoziation, sofern benötigt, auch die passende Prozessbeschreibung. Werden wiederum Prozesse beschrieben, haben diese meist Unterprozesse, Ausnahmen oder zusätzliche Anweisungen.
Beispiel: In einem Veranstaltungsprojekt ist es sinnvoll., die Kosten für das Event aufzuführen, zusätzlich ein Hinweis wie diese abgerechnet werden.
Dieser Hinweis kann mit dem passenden Abrechnungsprozess verlinkt werden.
Wikis sind flexibel einsetzbar. Diese Form von Flexibilität muss aber auch gepflegt werden wollen. "Ein Wiki hat immer den Charakter des Unfertigen. Dies ist eine wichtige Eigenschaft, auf die sich die Nutzer erst einstellen müssen."[6]
Denn auch Inhalt und Struktur des Wikis selbst lassen sich flexibel verändern. Mit dieser neuen Flexibilität müssen Nutzer umgehen können. Informationsstrukturen sollen auch in einem Wiki möglichst konsistent bleiben. Aber gerade wenn Inhalte wachsen, ist es nötig, Informationen umzugliedern oder in andere Artikel auszulagern. Das kann manchmal zu Irritation führen, wenn Inhalte an anderen Orten oder in einer anderen Struktur aufbereitet werden. Daher ist es wichtig, den Nutzern Wege anzubieten, wie bekanntes Wissen an neuen Orten und in neuen Formen gefunden werden kann.
Hat man beispielsweise mit einer Liste aller Projektansprechpartner begonnen und muss diese in einzelne Projektseiten ausgliedern, muss der erfahrene Nutzer Inhalte, die er an einer bestimmten Stelle erwartet, nun auf einer anderen Seite suchen.
Es gibt technische Lösungen, um Inhalte an zwei Stellen abzubilden. Fließtext kann mithilfe von Transklusionen an mehreren Orten eingebunden werden, strukturierte Informationen können mehrfach aggregiert und dargestellt werden.
Ein Wiki bildet aktuelles Wissen ab, ermöglicht über seine kollaborative Funktion aber auch eine Kommunikation innerhalb eines bestimmten Nutzerkreises. Jede Änderung ist die Verschriftlichung entweder einer konkreten Aussage oder eines Verbesserungsvorschlags, geht aber von einem allgemeinen Konsens aus, der nicht immer vorhanden ist.
Gerade wenn es schwierig ist, den Konsens zu finden, oder wenn Fehler auftreten, muss man vor der Verschriftlichung im Wiki den persönlichen Kontakt und in den direkten Dialog treten.
Ein Wiki ersetzt weder die technische Form der direkten Kommunikation noch die persönliche Kommunikation. Dies muss auf anderem Wege, zum Beispiel per E-Mail, Telefonat, Chatauskunft oder am besten über ein persönliches Gespräch, erfolgen.
Der Erfolg von Social-Media-Techniken wird oft mit kollektiver Intelligenz begründet. Kollektive Intelligenz bedeutet aber keine Verantwortungsdiffusion, sondern dass Verantwortung von einer Gruppe getragen wird.
Die Verantwortung für die Korrektheit und Vollständigkeit vorhandener und neuer Inhalte können Wikis unterschiedlich sicherstellen.
Da alle Neuerungen und Änderungen namentlich nachvollzogen werden können, sind diese bestimmten Personen zugeordnet. Im Text selbst ist es jedoch nicht nachvollziehbar, wer welchen Teil verfasst hat. Bei einer Seite mit mehreren Autoren ist die Zuordnung eines bestimmten Textabschnitts nur über die Versionshistorie bestimmbar. Wenn aber viele Nutzer Änderungen beobachten, geht man davon aus dass alle fehlerhaften Änderungen sofort bemerkt werden, da sich die Nutzer gegenseitig kontrollieren.
Vor allem Publikumswikis fordern eine Belegpflicht aus zuverlässigen Primärquellen. Bei internen Wikis ist dies oft nicht möglich, denn das Wiki selbst dient als Primärquelle.
In Organisationen existieren zu allen Bereichen Verantwortlichkeiten, die man in einem Wiki darstellen kann. Unter den Projektinformationen sollten die Projektverantwortlichen stehen, administrative Prozesse haben einen Ansprechpartner, ein Pressespiegel wird vom Verantwortlichen für externe Kommunikation betreut, Liegenschaften wiederum vom Facility Manager. Aber auch Kernprozesse und organisatorisches Wissen lassen sich mit einer verantwortlichen Person benennen. So ist allen Lesern klar, wer Entscheidungen zu einem Thema trifft. Das bedeutet nicht, dass Änderungen nicht mehr erlaubt sind. Aber es wird klar, in wessen Bereich Änderungen eingebracht werden und wer bei Unklarheiten Ansprechpartner ist.
Bei Wikipedia werden die Autoren oder informell Verantwortliche nicht sichtbar am Artikel genannt. Genau das soll man jedoch in einem Organisationswiki gern machen: wichtigen Artikeln einen Ansprechpartner zuordnen. Das lässt sich mit einer Zusatzfunktion in der Software lösen[11] oder durch Nennung im Text als Textbaustein.
Diese jeweiligen Ansprechpartner sollten "ihren" Bereich im Wiki aktiv beobachten und bei Fehlern einschreiten.
Jedes System birgt Fehler. Wo Menschen arbeiten, werden immer Fehler passieren. Das gilt auch für Wikis. Denn wenn jeder Änderungen vornehmen kann, werden Fehler passieren.
Durch falsches Wissen der Nutzer, Ungenauigkeit und Missverständnisse schleichen sich inhaltliche Fehler in Wikis ein. Wichtig ist daher eine pragmatische Fehlerkultur. Fehler in einem Wiki lassen sich einfach und schnell erkennen und ermöglichen eine Korrektur durch andere Nutzer.
Aufgrund der Fehlertransparenz können Nutzer, wie auch die Organisation aus Fehlern Lernen.
Manche Fehler werden durch eine Verschriftlichung im Wiki erst aufgedeckt und können ausgebessert und ihre Verbreitung verhindert werden. Je nach Ausmaß der Fehler müssen Nutzer geschult werden oder zumindest auf potentielle Fehlerquellen hingewiesen werden.
So sind Fehler in einem Wiki nichts Schlimmes. Im Gegenteil: Sie bieten die Möglichkeit, existierende Fehler zu erkennen und darauf entsprechend zu reagieren.
Sinnlose und falsche Informationen haben nirgendwo etwas zu suchen. Einträge in einem (internen) Wiki sind nie ganz falsch, zumindest in der ersten Version aber auch oft nie so ganz richtig. Manchmal fehlen Details die ein Autor für selbstverständlich oder unwichtig hält. Für Dritte erschliesst sich der Sinn nicht und die Information sind nicht ausreichend oder sogar missverständlich.
Die Frage muss also lauten: Wie geht man mit fehlerhafter Information um?
Löschen
Sätze, Abschnitte oder die Seite ganz zu löschen ist aus mehreren Gründen nicht der richtige Weg, vor allem wenn dieser nach bestem Wissen verfasst wurde:
Mindestens eine Person geht nach wie vor von fehlerhaften Wissen aus, lebt es und vermittelt den Fehler mündlich weiter.
Die Verfasser werden demotiviert, da ihr Beitrag verworfen wird, anstatt als Grundlage für eine Verbesserung genutzt zu werden. Ein Wiki verlangt nicht sofort nach einer perfekten Version. Die Arbeit im Wiki ist ähnlich dem Brainstorming an einem Whiteboard. Ideen Anderer sollen nicht weggewischt werden, sondern als Grundlage für Konkretisierungen oder Verbesserungen genutzt werden.
Kennzeichnen
Sofern man keine Zeit oder die Möglichkeit hat einen Fehler zu verbessern, sollte man den Fehler als solchen kennzeichnen. Textbausteine können andere Nutzer davor warnen, dass Informationen noch nicht offiziell freigegeben sind, oder sich noch im Entwurf befinden.
Trivia verschieben
Oft werden triviale Inhalte gelöscht, weil diese zu prominent aufgeführt sind und die Leser von wichtigeren Inhalten ablenken können. Es ist zwar wichtig, Inhalte zugänglich und priorisiert zu strukturieren, dennoch können scheinbar unwichtige Informationen dennoch ihren Platz bekommen. Beispiel: Auf der Seite der Buchhaltung sollte nicht als erstes die Dokumentenablageregel stehen, auf einer eigenen Unterseite jedoch schon.
Verbessern
Sinn und Zweck eines Wikis ist es Inhalte stetig zu verbessern. Werden missverständliche und unvollständige Informationen nicht nur als Fehler gesehen, sondern als Potential zur Verbesserung, führt das dazu, dass Nutzer zukünftig Inhalte besser verstehen, vorausgesetzt, man berichtigt fehlerhafte Interpretationen.
Die Absicht des Erstellers, ein Thema zu dokumentieren bleibt erhalten, selbst wenn man Inhalte neu formuliert.
Ein Beispieleintrag könnte lauten: Eingangsrechnung in den blauen Ordner. Hier sieht man folgende mögliche Fehler:
Missverständliche Information
Erst nach erfolgreicher Verbuchung durch die Buchhaltung kommen Eingangsrechnungen in den blauen Ordner. Mitarbeiter, die Eingangsrechnungen einreichen, sollen diese in einen dafür vorgesehenen Ablagekorb legen.
Unvollständigkeit
Im Gegensatz zur normalen Ablage werden Rechnungen nach Kundennummer und nicht nach Name des Lieferanten einsortiert.
Rechnungen aus der IT-Abteilung werden nicht in der Buchhaltung verbucht, sondern, durch die IT-Abteilung selbst.
Nach einer Überarbeitung könnte der Eintrag lauten: Alle Mitarbeiter geben Eingangsrechnungen, außer für die [[IT-Abteilung]], im Ablagekorb 'ER' im 1. Stock ab. Nach der Verbuchung durch die Buchhaltung werden diese im blauen Ordner, sortiert nach Kundennummer, abgelegt.
Ein Wiki ist nie fertig. Erstens weil man immer wieder fehlendes Wissen entdeckt und hinzufügt, zweitens weil Wissen sich ständig wandelt.
Jede Organisation lebt davon, sich dem ständigen Wandel anzupassen. Es kommen neue Betätigungsfelder hinzu, weil sich Anforderungen verändern oder der Fortschritt eine Weiterentwicklung fordert. Firmen müssen mit dem wirtschaftlichen und technologischen Wandel mithalten. Eine Schule bekommt neue Lehrpläne, muss andere Inhalte lehren oder von überkommenen gesellschaftlichen Voraussetzungen bei Schülern ausgehen. Ein Sportverein muss sich an neue moderne Trainingsmethoden gewöhnen.
Wissen kann veralten, auch in einem Wiki[12].
Ein Wiki ist aber, abgesehen von der Einführung, kein einmaliges Projekt. Ein Wiki muss der zentrale Kernpunkt der täglichen Wissensarbeit sein und Veränderungen kontinuierlich dokumentieren.
Ein Wiki ist dazu geeignet. Denn Wissensveränderungen, deren Auswirkung man zu Beginn oftmals gar nicht erkennt, müssen zeitnah und am Wissensstamm selbst verändert werden. Da es Wikis jedem Nutzer ermöglichen, Wissen aktuell zu halten, wird der Wissensstand besser in einem kollaborativen System abgebildet, anstatt "offizielles" Wissen von einer kleinen redaktionellen Gruppe betreuen zu lassen.
Wikis benötigen eine offene, dynamische und flexible Informationskultur, die Wissen nicht in "Stein gemeißelt", sondern als Abbild einer ständigen Verbesserung betrachtet.
Im Idealfall ist ein Wiki integraler Bestandteil der Wissenskultur. Neuerungen werden daher automatisch von Nutzern zuerst dokumentiert, dann angewendet. Ist ein Organisationswiki noch in der Aufbauphase, können organisatorische Neuerungen undokumentiert bleiben.
Um jetzt nicht den Anschluss zu verlieren, müssen sich Wikigärtner um die Überprüfungen der Inhalte kümmern. Es müssen nicht alle Artikel kontrolliert werden, es genügt sich auf bestimmte Kategorien der Kernprozesse zu konzentrieren. Im Rahmen von Qualitätsmanagementsystemen sind Maßnahmen zur Überprüfungen sogar Pflicht. Das Vorgehen nach welchen Kriterien Inhalte geprüft werden kann wiederum in einem Wiki dokumentiert werden. Größere Enterprise-Wikis haben interne Workflows zur Inhaltsprüfung[13], es genügt aber auch der übliche Dienstweg für die Verteilung von Aufgaben, sei das eine E-Mail, ein Tasktracker oder eine gemeinsame Wikiseite der Gärtner.
Vor allem Unternehmen sind hierarchische Organisationen, die Verantwortlichkeiten von oben nach unten in ihr Unternehmen hinein übertragen. Entscheidungen werden von organisatorisch definierten Verantwortlichen getroffen. Wikis mit ihrer offenen Entscheidungskultur widersprechen dem, allerdings scheinbar. Bei den meisten öffentlichen Wikis, wie beispielsweise Wikipedia, baut sich eine Heterarchie mit dem Wachstumsprozess auf.
Wie lassen sich nun die Anforderungen eines hierarchisch organisierten Verantwortungssystems mit einem Wiki vereinbaren? Zum einen ist das Bild des hierarchischen Unternehmens einseitig. Keine Firmenphilosophie würde heutzutage eine "militärische" Befehlsstruktur fordern, obwohl ein Unternehmen in letzter Konsequenz dem finanziellen Wunsch der Eigentümer folgt. Das Vertrauen in die Kompetenz aller Mitarbeiter wird zum Leitbild erhoben. Und das ist keine leere Formel. Unternehmen sind von der eigenverantwortlichen Entscheidungsfähigkeit jedes Mitarbeiters abhängig.
Moderne Unternehmen müssen ihren Mitarbeitern Gestaltungsspielraum in deren Verantwortungsbereich einräumen, bei gleichzeitiger Ausrichtung auf das Unternehmensziel.
Wikis bilden diese beiden Ziele ab, indem sie allen Nutzern eine einfache und schnelle Interaktion erlauben, dennoch darauf bauen, dass alle Veränderungen gemeinsam, auch von Vorgesetzten, kontrolliert werden können.
Vor allem die gegenseitige Überprüfung aller Änderungen erfordert weniger Hierarchie und mehr Vertrauen.[1]
„Wikis können bei Führungskräften Bauchschmerzen verursachen“[14].
Es kann sich eine Skepsis aufbauen, da Vorgänge nur indirekt kontrolliert werden. Außerdem haben Führungskräfte möglicherweise Verlustängste über den ureigenen Arbeitsbereich. "Voraussetzung für ein Ablegen der Verlustängste ist, dass man die Austauschpartner wertschätzt und sie für leistungsfähig hält. Wer die Kompetenzen der Bezugsgruppen unterschätzt, wird weniger Ressourcen einfahren als eine Einrichtung, die ihre Stakeholder für kompetent hält."[15]
Ob sich ein Wiki durchsetzt oder nicht, ist bei einer klassisch gewachsenen Organisation nicht nur von deren inhaltlicher Qualität abhängig, sondern auch auch von der Akzeptanz der Unternehmensspitze. Jeder Chef, Vorstand oder Abteilungsleiter in dessen Bereich das Wiki "stattfindet", muss dieses legitimieren. Andernfalls fühlt sich die Masse der Nutzer in ihrem Zweifel bestätigt das Wiki sei nicht so richtig offiziell. "Tendenziell funktioniert der aktive Einsatz von Wikis besser bei flachen Hierarchien, überschaubaren Wissensbeständen und in einer möglichst offenen Unternehmenskultur."[16] Andererseits darf das Management nicht versuchen, das Wiki ihrer Firma aufzuzwingen, denn Motivation und Eigeninitiative, die Hauptmotoren eines Wikis, lassen sich nicht verordnen. Die Leitung muss eine Kultur erlauben, die ein Wiki trägt. Denn „generell gelte dann in solch einem System: Vertrauen ist billiger als Kontrolle [durch den Vorgesetzten].“[17]
Ein Wiki kann man weder Top-down noch Bottom-up einführen. Öffentliche Wikis sind per se Bottom-up, da diese auf der grünen Wiese beginnen, sich die Nutzer erst sammeln und dann eine Organisationen um die Arbeit an den Inhalten des Wiki herum entsteht. Bei Firmenwikis sind die Mitarbeiter als Produzenten und Konsumenten die wichtigsten Akteure, daher liegt es in der Natur der Sache, das der Bottom-up-Ansatz zum Tragen kommt. Aber kommerzielle Firmen haben auch immer noch eine Leitung, die ein Wiki, auch aktiv und wohlwollend mittragen muss.
Wikis eignen sich grundsätzlich für jede Organisation. Dennoch gibt es Organisationsformen, für die ein Wiki eher einen Mehrwert bietet als Organisationsformen, die es aufgrund der Größe, Nutzer- und Organisationsstruktur nicht schaffen sich mit ihrer Kultur auf ein Wiki so einzulassen, dass dieses angenommen wird, funktioniert, geschweige den Mehrwert und Motivation schafft. Grundsätzlich lässt sich sagen, dass eine offene Kultur und flache Hierarchien[16] gute Voraussetzungen für ein lebendes Wiki sind. Doch die Frage ist: Wo sind die Chancen auf eine Einführung eines Wiki erfolgversprechender und wo wird man mit Widerständen zu kämpfen haben?
Start-up-Unternehmen wollen mit einer innovativen Geschäftsidee schnell wachsen und eine schnelle Rentabilität erreichen. Die Start-up-Kultur fordert Werte wie Offenheit, Flexibilität und Schnelligkeit. Flache Hierarchien sollen jeden Mitarbeiter einbinden und so die Entwicklung der Firma vorantreiben. Wikis ermöglichen hier eine Kultur, in der Nutzer ihr Wissen, Informationen, Ideen und Fehler einfach austauschen. Meist sind Mitglieder eines Start-ups junge, technologisch interessierte Menschen. Wissen und Prozesse sind im stetigen Wandel und müssen daher angepasst werden. Daher kann ein Wiki das kreative Chaos eines Start-ups erst einmal widerspiegeln und auch helfen, in eine effiziente Ordnung zu bringen.
Start-ups sind zusätzlich auf eine hohe Ressourceneffizienz angewiesen und haben meist weniger Mitarbeiter für mehr Arbeit.
Mitarbeiter sollen also nicht ständig für Auskünfte und Informationsweitergabe blockiert werden, eine Wiki bietet Auskünfte schneller und effizienter. Dadurch bleibt mehr Zeit für kreative Arbeit. Vor allem hilft ein Wiki beim Wachstum eines jungen Unternehmens, da aktuelles Wissen schnell an neue Nutzer weitergegeben werden kann. Aber auch entscheidende strategische Änderungen können einfach und zeitnah dokumentiert werden.
Unabhängig davon ob man seinen Mitarbeitern Home Office ermöglicht, ob das Unternehmen an unterschiedlichen Standorten operiert oder mit nicht örtlichen Kunden, Zulieferern oder Anderen arbeitet; immer wenn Projektbeteiligte Nutzer nicht vor Ort sind, ist ein Wiki besonderes hilfreich, um das gemeinsame Wissen zu bündeln.
In viele Verwaltungs-, Planungs- oder anderen Wissensbetrieben ist die ortsgebundene Zusammenarbeit nicht immer gegeben. Selbst wenn das Software-Entwicklungsteam im gleichen Raum mit dem Projektleiter sitzt, der Kunde befindet sich vielleicht hunderte Kilometer entfernt. Wenn dann auch einzelne Teammitglieder über Orte verteilt arbeiten und eben nicht "mal schnell über den Tisch hinweg fragen" oder auf einen Wandplan schauen können, ist eine umfassende, schnelle und einfache Dokumentation von Prozessen und Arbeitsinformation wichtig. Denn nur in Telefonaten und E-Mails haben Informationen zu schnell inkonsistente Stände und müssen von allen Nutzern selbst konsolidiert werden.
In der Arbeitswelt sind Teil- und Gleitzeit immer häufiger werdenden Arbeitsmodelle.
Wenn viele Nutzer wenige gemeinsame Präsenzstunden haben, hilft eine einfache Dokumentation in einem Wiki alle Nutzer auf dem gleichen Wissensstand zu halten.
Wie bei jeder Neuerung kann es auch gegen ein Wiki unterschiedliche Kritik und Widerstände geben. Manche Kritikpunkte sind durchaus gerechtfertigt, aber lösbar. Andere erscheinen zwar verständlich, sind jedoch unbegründet.
Strukturlosigkeit
Da dem Inhalt eines Wikis keine technische Struktur vorgegeben ist, kann es zu einer "Unordnung" kommen, wenn die vorab definierte Ordnung nicht eingehalten wird. Es gibt in jedem Wiki Beispiele dafür, dass Informationen nicht "am richtigen" Ort abgelegt sind.
Jeder Strukturfehler birgt die Chance, ein Wiki zu verbessern. Findet jemand Information nicht dort wo er sie erwartet, herrscht Handlungsbedarf. Zuerst sollte man diese Information verlinkt werden um diesen Gedankenpfad auch für Andere einzubauen. Steht im Artikel "Lieferanten" nichts über Bestellungen, kann man eine Weiterleitung, einen neuen Abschnitt oder den entsprechenden neuen Artikel "Bestellungen" hinzufügen.
Verantwortung und Gültigkeit
Wenn alle Nutzer alles verändern können, erwarten viele Kritiker ein niedriges Qualitätsniveau.
Da Änderungen aber einfach und umfassend nachvollzogen und gegebenenfalls verbessert werden können, hebt sich das grundsätzliche Qualitätsniveau in einem lebenden Wiki. Es gilt: Nicht alle Nutzer werden gleich schlecht, sondern alle können gleich gut werden
Spaßeinträge (heute haben alle Hitzefrei) oder gar kontraproduktive Beiträge kommen in internen Wikis aufgrund der namentlichen Nachvollziehbarkeit nicht vor.
Herrschaftswissen und Status
Nutzer die Herrschaftswissen nicht preisgeben wollen oder Mitarbeiter mit Verlustängsten können schwer zur Mitarbeit motivierbar sein.
Wichtig ist es daher, an einen gemeinsamen Willen zu appellieren, Beitragen zur fordern aber auch zu honorieren und persönliche Verantwortlichkeiten für Inhalte zu übertragen.
Wahrscheinlich nutzen auch die ewigen Gegner ein Wiki inhaltlich. Sie sind aber immer zur Stelle, wenn es um Kritik und Zweifel geht.
Projektleiter eines Organisationswikis müssen alle Vorbehalte ernst nehmen und versuchen zu lösen, aber nicht alle Mitarbeiter müssen zwingende motiviert werden. Ein Wiki braucht nur eine kritische Masse motivierter Mitarbeiter.
Der Großteil der Nutzer sind immer die zustimmenden Passiven. Diese Nutzergruppe nutzt die Inhalte zwar, ist auch bereit offensichtliche Inhalte beizutragen (z.B. fehlende Teile einer Auflistung), zeigen aber kein verstärktes Engagement, um neue Inhaltsbereich voran zu treiben. Auch wenn einige Nutzer dann mehr leisten müssen als andere, in der Kommunikations- und Wissensbilanz trägt dieses passive Nutzen zum organisatorischen Gesamtergebnis bei, da die passiven Nutzer Inhalte zumindest nicht suchen müssen und Fehlannahmen vermieden werden.
Man sollte nur nicht vergessen, die Mehrleister zumindest entsprechend zu motivieren.
Wahrscheinlich gibt es mehr gescheiterte Wikis als erfolgreich umgesetzte und genutzte Systeme. Wenn nach der Einführung, außer ein paar verstreute Bearbeitungen, über einen längeren Zeitraum nichts passiert, besteht die Gefahr, dass das Wiki aufgrund der Nichtnutzung verwaist und nur noch unaktuelle Informationen bruchstückhaft beinhaltet. Vor allem Skeptiker sehen damit das Wikis als gescheitertet an.
Das Scheitern eines Wikis kann, in allen Entwicklungsstufen, unterschiedliche Gründe haben:
Keine Inhalte
Ein Wiki wurde installiert, aber wenige oder nur einzelne Personen tragen Inhalte bei. Die Folge: niemand erwartet sinnvolles Wissen im Wiki. Ursachen dafür können sein:
Die Wikikultur passt nicht in die Organisation oder es gibt generelle Widerstände.
Nicht alle Teilnehmer sind im Umgang geschult oder die Usability ist unzureichend. Vor allem Schwierigkeiten mit der Syntax und eine nicht reibungslos funktionierende Suche bremsen Wikis aus.
Unauffindbare Inhalte
Selbst wenn Nutzer das Wiki als Art der Wissensschöpfung annehmen und am Fortbestand mitschreiben, kann ein Wiki scheitern. Werden Information nur häppchenweise beigetragen und nicht zu einem Gesamtkonstrukt verknüpft, wird ein Wiki von geringem Nutzen sein, da nur die Schreiber wissen, wo sie was gespeichert haben und kein anderer kann partizipieren. Meist fehlen solchen Wikis genug Gärtner, die Informationen und Wissen ordnen, Strukturen schaffen und missverständliche Informationen einordnen.
Auch wenn nicht klar ist, wofür das Wiki genutzt werden soll und wofür besser nicht, kann es passieren, dass Wissen mit anderen zusätzlichen Systemen mehrfach verwaltet wird.
Verstreute Inhalte
Es gibt zwar Inhalte, aber jeweils unterschiedliche, nicht zusammengefügte Wissensfragmente. Inhalte werden nicht verlinkt, beschreiben aber ein und den selben Sachverhalt unterschiedlich oder richten sich nur an spezifische Zielgruppen. Oft widersprechen sich dann Artikel sogar. Wenn der Wille zur Zusammenarbeit fehlt, und Belange von allgemeingültigem Interesse nicht für alle Nutzer verständlich beschrieben werden, dient ein Wiki nicht dem Wissensaustausch, sondern zementiert unterschiedliche Sichtweisen. Beschreibt z.B. die Buchhaltung einen Abrechnungsprozess fachlich-buchhalterisch, aber das Büromanagement nur aus Anwendersicht, die wiederum nicht von der Buchhaltung mit gelesen werden, werden in diesem Prozess immer wieder Fehler passieren. Alle Nutzer eines Wikis müssen ihre Inhalte auch infrage stellen lassen und beispielsweise eine ergänzende vereinfachte Version akzeptieren. Und sie dürfen nicht auf ihrem Duktus und ihrer Darstellungsweise beharren.
↑Die 90-9-1-Regel tritt in einem Corporate Wiki außer KraftDer Anteil an Leuten, die sich oft und aktiv beteiligen, tendiert gegen 60%. Das ist gut, doch nun richtet sich der Fokus auf die verbleibenden 40%, die nur gelegentlich Inhalte beisteuern oder ausschließlich passiv lesen.
↑"Das bedeutet für die Einführung von Wikis im Unternehmen, dass die Motivation der Mitarbeiter, das Wiki zu nutzen, über eine Anwenderschulung hinausgehen muss. Vielmehr muss auch die aktive und kontinuierliche Beteiligung der Mitarbeiter in der Wiki-Community unterstützt werden, zum Beispiel durch Anreiz-Systeme." aus M. Figura, D. Gross: Die Qual der Wiki-Wahl. Wikis für Wissensmanagement in Organisationen
Organisationswikis sollen unterschiedlichste Informationen sammeln und für alle Nutzer bequem zugänglich machen. Die Ordnung aller dieser Inhalte ist technisch nicht vorgegeben. Sie ergibt sich erst aus dem beschreibenden Inhalt, den Seitentiteln und vor allem den Verlinkungen zwischen den einzelnen Artikeln.
Das Wissen in einem Wiki untergliedert sich in einzelne Artikel. Die Wissensrepräsentation dieser Artikel ist nicht grundsätzlich hierarchisch in einer pyramidalen Struktur eingebaut, sondern in ein semantisches Netz. Jede Information ist so in ihrem Kontext integriert.
Alle Informationen zu einem Thema sind als Artikel auf einer Seite zusammengefasst und werden durch den Seitentitel identifiziert.
Um Information einfach und schnell zu finden, bedarf es einer Struktur aus beschreibendem Text und semantischen Links. Zusätzlich strukturiert sich ein Wiki durch Kategorien, Namensräume oder andere Ordnungsbausteine (Übersichtsseiten, Portale, Themenringe). Werden Inhalte gar nicht oder falsch verlinkt, weder kategorisiert noch richtig formatiert, sondern nur abgelegt, so entsteht schnell ein wirres Informationsgeflecht[1], auch scherzhaft Vogonismus[2] genannt. Kein Wiki strukturiert und pflegt sich von selbst. Viel Inhalt muss nicht zwangsläufig zu einer guten Struktur führen. Jedes Wiki braucht eine kleine Gruppe von Wikigärtnern, die sich um die Einhaltung einer Ordnung per Konvention kümmern.
Unabhängig, ob ein Wiki gut oder weniger gut gepflegt ist, kein Titel-, Kategorie-, oder Namensraumsystem kann jede Anfrage zufriedenstellend beantworten. Eine gute Suche ist eine wichtige Funktion. Sie hilft vor allem in der Startphase, wenn sich die Struktur und die Nutzung noch aufbauen; und kann Frust durch das "Nicht wieder finden von Inhalten" vermeiden.
Um aus vielen einzelnen Wissensbausteinen ein nützliches Ganzes zu bilden, müssen alle Inhalte verständlich und auffindbar sein.
Die Mindmap zeigt einen Gesamtzusammenhang
Im persönlichen Wissensmanagement nutzen Menschen verschiedenartige abstrakte Ordnungsmuster, die nur einzelne getrennte Wissensteile speichern. Notizsammlungen, Excellisten oder E-Mailordner, die zu einem bestimmten Projekt oder Prozess gehören, geben diesem eine Unterstruktur, jedoch ohne semantische Verknüpfung. Andere Nutzer zeichnen Verbindungen von inhaltlichen Zusammenhängen mit Mind-Maps. Mind-Maps sind meist aber nur Linien und keine beschriebenen Relationen. Mindmaps werden auch in Gruppenarbeit als grafisches Hilfsmittel zur Unterstützung der verbalen Kommunikation eingesetzt. Die Wissensstruktur wird zwar verschriftlicht, die dazugehörigen semantischen Bezüge finden aber verbal statt.
Um die Information auch für Dritte verständlich zu gestalten, muss der Wikiartikel ein lesbarer Text sein. Tabellen, Listen und Diagramme sind sinnvolle Hilfsmittel für strukturierte Informationen, müssen aber in einem semantischen Text eingebettet sein.
Vor allem Prozessbeschreibungen sollten ausführlich sein, um sprachlich auch von Neuanwendern verstanden zu werden - reine Stichpunktlisten sind schwierig zu verstehen.
Die wichtigsten Textbestandteile neben Abschnitten mit Details sind:
Einleitung
Ein Einleitungssatz sollte kurz und prägnant den Inhalt der Seite beschreiben. Er soll Links auf übergeordnete Begriffe enthalten und vor allem Besonderheiten erklären. Auch wenn das für die direkt Beteiligten trivial klingt, für Personen mit wenig Vorkenntnissen ist es wichtig zu wissen, um was es geht. (z.B. Projektseite: __Sedanstr 9__ ist ein [[Planungsprojekt]] seit 2013, bei dem wir zum ersten mal nach [[VDB-Zertifizierung]] arbeiten, daher betreuen dieses Projekt auch [[Hanne Hofer]] zusätzlich zu [[Martin Müller]]. oder auf einer Prozesseite: Die __VDB-Zertifizierung__ ermöglicht es, baubiologisch zertifizierte Projekte durchzuführen. Wir sind seit 2014 mit [[Martin Müller]] zertifiziert. Es gelten folgende Regeln...)
Abgrenzung
Besonderheiten eines Prozess oder Projekts, müssen herausgehoben werden (z.B. __Sedanstr 9__ ist ein [[Planungsprojekt]] seit 2013, das wir nicht allein, sondern ausnahmsweise zusammen mit [[Thorsten Töller]] in der [[Arge Sedan]] betreuen.).
Listen
Vor allem Projektdetails oder Arbeitsschritte können durchaus listenartiger sein und nur stichpunktartig die Kennwerte aufführen. Es ist nicht immer notwendig zu schreiben ... und der Projektleiter ist Hans, es genügt ein: * Projektleiter: Hans
Jedes Genre benötigt seine eigenen flexiblen Abschnitte die jedes Wiki für sich selbst festlegen soll.
Das hauptsächliche Ordnungssystem eines Wikis sind die Seitentitel; Lemmas, die Grundform eines Wortes, unter der man es in einem Nachschlagewerk sucht. Diese dienen nicht nur der Identifikation von Artikeln - sonst könnte man auch aufeinander folgende Nummern benutzen, vielmehr beschreiben sie den Inhalt sprachlich (z.B. Frankfurter Büro). Seitentitel ermöglichen Benutzern eine eindeutige Zuordnung des Inhalts um Wissen später wieder finden zu können. Eine Redundanz durch Kopie, Wiederholung oder Transklusionen ist zu vermeiden, stattdessen muss Wissen einmalig aufgeschrieben sein und der Kontext durch Verlinkungen hergestellt werden.
In einem Organisationswiki kann und muss man sich ebenfalls auf ein oder gegebenenfalls mehrere gemeinsame Schemata einigen.
Phonetisch
Die Lemmata werden in grammatikalisch richtiger Form mit allen Substantivdeklinationen des beschreibenden Objekts genannt
Frankfurter Büro und Besprechungsraum Main im Frankfurter Büro
Schlagworte
Es werden nur reine Substantive und keine Substantivdeklinationen verwendet.
Büro Frankfurt und Besprechungsraum Main Büro Frankfurt
Grundformen
Es gibt einen Unterschied zwischen Projektleiter und Projektleitung, aber es ist sinnvoller diese Informationen in einen Artikel zu vereinen, da sich beides überschneidet. Um dennoch beide Seitentitel finden zu können, soll der jeweils andere Titel auf den Hauptartikel weitergeleitet werden.
Verzeichnisstruktur
Eine hierarchische Sortierung und Abgrenzung, auch unter Verwendung von Namensräumen.
Frankfurt/Büro aber auch Büro/Frankfurt und Büro/Frankfurt/Besprechungsraum/Main ...
Diese hierarchische Sortierung hat generell den Nachteil, dass nicht klar ist, was zuerst kommt. Man kann das Beispiel fast beliebig umstellen, ohne dass der Sinn verloren geht.
Assoziationsfrei
Um keinerlei Benennungskonflikte zu erzeugen, können auch völlig freie neue Namen verwendet werden. Hier ist es aber hilfreich, wenn diese auch in der Realität Anwendung finden.
Mainbüro, Donald Duck oder eine Raumnummer 20060011 beschreibt das 'Arbeitsbüro in der Stadt Frankfurt'.
In jedem Wiki muss man sich auf eine Mischung einigen. Eine praktikable Form könnte eine schlagwortbasierte Grundform sein, mit sehr wenigen hierarchischen Namensräumen und optionalen nachgestellten Verzeichnissen (Main Büro Frankfurt/Inventarliste) als 'dienende' Unterseite zur eigentlichen Hauptseite.
Die natürliche Sprache ist das wichtigste Ordnungkriterium.
Umgangsprachlichen Eigenheiten der Organisation sollten aber berücksichtigt werden, das heißt Fachbegriffe und Eigennamen aus der täglichen Arbeitswelt sollen Eingang finden.
Da Informationen nicht immer mit dem richtigen Titel gesucht werden, können Seitentitel nicht die alleinige Ordnungsform sein. Verlinkungen und Kategorien verbinden die einzelnen Artikel zu einem Ganzen und führen den Nutzer zur gesuchten Information.
Innerhalb des Wikis dienen Seitentitel auch als Identifikator für einen Hyperlink. Dadurch müssen Referenzen auf andere Inhalte nicht erst mühsam gesucht und verarbeitet (z.B. knowlegdebase.intra/index.php?id=1234) sondern können flüssig im Text verlinkt werden ([[Seitentitel]]).
Gegenüber einem rein schriftlichen Querverweis (siehe Gefahrguthandbuch S. 34) ist ein Link, durch einen Mausklick leichter zu erreichen und die Nutzung damit höher. Eine gute Verlinkung strukturiert das Wissen semantisch und matritzenförmig.
Links sollten eher mehr als weniger genutzt werden, um auf weiterführende Informationen hinzuweisen. Bei Projektleiter: Max Mustermann sollte das Wort 'Projektleiter' verlinkt werden, um dem Leser zu signalisieren, dass es bestimmte Arbeitsweisen von Projektleitung gibt.
Außerdem kann der Link zu einer Auflistung aller Projektleiter führen.
Auf diesem Weg findet ein Benutzer, der nicht sofort zum richtigen Artikel gelangt, über Links zur gesuchten Information.
Externe Inhalte sind, sofern möglich, ebenfalls zu verlinken, anstatt zu kopieren. Fachliche Erklärungen, Handbücher, Branchenregeln, aber auch Wikipediaartikel sollen mit einem Link oder einem Verweis auf eine Offline Quelle referenziert werden.
Eine Klassifizierung in Kategorien hilft, eine große Anzahl von Artikeln in eine gemeinsame Struktur einzuteilen. Im Gegensatz zu Namensräumen oder Spaces kann jeder einzelne Artikel in mehrere Kategorien eingeordnet werden (z.B. der Artikel Lohnbuchhaltung in die Kategorie:Finanzen und Kategorie:Personal).
Oft werden als Kategorien semantische Tags verwendet. Tags unterscheiden sich von klassischen hierarchischen Kategorien insofern , als dass sie in keiner Baumstruktur eingeordnet sind. Würde man beispielsweise einem Projekt die Kategorie Coburg zuordnen, wäre das Projekt, als Kindelement, auch unter der Kategorie Bayern zu finden.
Bei Tags müsste man die beiden Tags Coburg und Bayern vergeben.
Das Arbeiten mit Tags hat sich aber in der Praxis etabliert, da die hierarchische Einordnung der klassischen Kategorien immer zu schwerfälligen Strukturen führt. Tags lassen sich einfach setzen und auch Sonderfälle können abgebildet werden.
Neue Tags werden einfach beim editieren eines Artikels gesetzt, ohne diese neue Tag vorher an anderer Stelle anlegen zu müssen.
Die Software Confluence bietet an jeden Artikel mit Tags zu kennzeichnen, die Autocomplete-Funktion hilft, existierende Tags schnell zu finden und zu setzen. Allerdings sind Confluence-Tags auf den jeweiligen Space begrenzt. Eine über Spaces greifende Ordnung ist nicht möglich.
Mediawiki bietet sogenannte Kategorien, die technisch wie Tags funktionieren. Diese werden an einer beliebigen Stelle der Seite (meist ganz unten) als Link im Text geschrieben (''[[Kategorie:Coburg]]''). So werden alle Artikel in dieser Mediawiki-Kategorie zusammengefasst. Neue Mediawiki-Kategorien werden, ebenfalls wie Tags, im Text geschrieben und existieren ab der ersten Verwendung. Eine Besonderheit ist, dass diese, wie klassische Kategorien, in andere einsortiert werden können. Die Kategorie:Coburg kann optional, wie andere Artikel, in der Kategorie:Bayern stehen. Auf diese Weise lässt sich ein hierarchisches Kategoriesystem erstellen. Eine Ausgabe dieser Unterkategorien ist nur mit einem Zusatzplugin[3] möglich.
Namensräume, in manchen Wikis auch Space genannt, sind Verzeichnisstrukturen übergeordnete Ordnungseinheiten, die jeden Artikel in genau einen Namensraum einordnen und in aller Regel im Seitentitel auftauchen (z.B. Wikis in Organisationen: Ordnung).
Namensräume können meist separat durchsucht und abgesperrt werden.
Diese hierarchische Verzeichnisstruktur sind vielen Nutzern vertraut und helfen, sich grundlegenden zu orientieren. Die Ordnung in Namensräumen ist einfach zu verstehen und zwingt jeden Artikel in diese eine Ordnungsstruktur. Sie hat allerdings den Nachteil, dass zwar mehrere Artikel in einen Namensraum eingeordnet werden können, aber ein Artikel nur in einem Namensraum erscheinen kann. Eine Mehrfach-Einordnung, wie bei Kategorien, ist nicht möglich.
Namensräume sollten mit bedacht und richtig eingesetzt werden. Werden zu viele Namensräume angelegt, z.B. für jede Unterabteilung, jedes Projekt, jede Hierarchiestufe, fragmentieren die Artikel in untereinander unstrukturierte Bereich und die für ein Wiki so wichtige Semantik geht verloren.
Generell soll ein Wiki zur Zusammenarbeit motivieren und nicht zum getrennten Arbeiten in den jeweiligen Räumen.
Namensräume sollten zur Kategorisierung von Inhaltsarten genutzt werden:
Metainformationen verwalten: Hilfetext für das Wiki selbst, Personenverzeichnisse, Textbausteine, Beschreibungen für Dateien.
Große Mengen gleichartiger Textkategorien wie Protokolle, Handbücher etc.
Gleiche Inhalte sollte man auch in einem gemeinsamen Namensraum belassen. Die Struktur kann dann über Kategorien erstellt werden.
Ob man Projektinformationen und Prozessbeschreibungen mittels Namensräumen trennt, ist Geschmackssache und kommt auf die Wiki-Software an, wie wenig diese zwischen Namensräumen trennt.
Namensräume müssen den Bereich den sie abgrenzen beschreiben. Werden zu allgemeine Benennungen benutzt, ist für den Nutzer nicht ersichtlich, in welchen Namensraum er Informationen suchen oder hinzufügen soll.
Ein Namensraum Glossar oder Bibliothek erklärt meist Begriffe oder Lemmata. In einer Bibliothek finden sich meistens Texte oder lediglich Weblinks zu Themenbereichen, aber eben zu Themenbereichen. Das hat den Nachteil, dass ein Themenbereich mehrmals vorkommt und der Nutzer nicht weiß, ob er über Glossar:Buchhaltung, Bibliothek:Buchhaltung oder Begriffe:Buchhaltung zu Buchhaltung gelangt.
Nicht sichtbare Namensräume, sprich, wenn der Namensraum im Link nicht sichtbar ist (ist bei DokuWiki möglich), sind für den Nutzer schwer zu verstehen, da man im Link selbst nicht mehr zwischen generischem und speziellem Inhalt unterscheiden kann. Das lässt sich nur verhindern, indem Namensräume aus sich heraus wachsen, oder eben Teil des Seitentitels sind (z. B. Hilfe:Bearbeiten)
Ein Wiki untergliedert Information in einzelne Artikel. Meist ist die inhaltliche Abgrenzung zwischen Artikeln klar, denn die meisten Wissenselemente werden durch ihre Bezeichnung beschrieben. Nicht alle Begriffe aber müssen zu einem eigenen Artikel werden, wiederum andere Wissenselemente benötigen Unterartikel.
Es gibt mehrere Kriterien, nach denen sich Artikel aufteilen können:
Inhalte mit einer starken Begrifflichkeit sind als eigene Artikel anzulegen. Wenn diese Artikel derart anwachsen, dass sich Unterabschnitte sinnvoll ausgliedern lassen, kann man Unterartikel bilden. Zusätzlich zu einem Link auf den augegliederten Inhalt hilft ein erklärender Satz auf den anderen Artikel verweisen. (z.B. aus einem Veranstaltungsprojekt das Thema "Finanzierung" auslagern)
Wissenselemente, die wenig Inhalt aufweisen (z.B. einfache Projekte mit geringer Komplexizität) können in einem Sammelartikel zusammengefasst werden. Außer diese benötigen eine eigene Kategorisierung, dann ist auch ein kurzer Artikel nötig.
Wikis zeichnen sich durch niedrige Zutrittsbarrieren aus, um möglichst vielen Nutzern eine einfache und aktive Mitarbeit zu ermöglichen.
Um in dieser Kultur der Offenheit dennoch die Qualität der Bearbeitung sicherstellen zu können, sind alle Änderungen durch alle Nutzer gegenseitig nachvollziehbar. Technisch betrachtet können Inhalte in einem Wiki gar nicht verändert werden, den bei jeder Bearbeitung wird eine neue Version des bestehenden Inhalts angelegt und als aktueller Version allen anderen Nutzern gezeigt. Dies hat zwei Vorteile: einerseits lässt sich jede vorhergegangene Version wiederherstellen und andererseits lassen sich alle Änderungen präzise betrachten.
In einem Prozess von sozialer Kontrolle begutachten Nutzer ihre Änderungen gegenseitig und greifen ein wenn Fehler passieren oder helfen Inhalt zu ergänzen. Dieser qualitätsschaffende Mechanismus, der Peer-Review, ist darauf ausgelegt, jede Änderung zu beobachten, zu bewerten, zu hinterfragen und falls fehlerhaft, rückgängig zu machen.
Im Vergleich zu anderen Dokumentations- oder Kommunikationssystemen konzentrieren sich Wikis vor allem auf die transparente Darstellung von Änderungen. Dagegen werden Änderungen an Datenbeständen auf Festplatten oder Aktenordnern seltenst kontrolliert, noch existieren überhaupt Systeme diese Änderungen einsehen zu können. Werden Änderungen nur mündlichen kommuniziert, sind diese für Außenstehende gar nicht nachvollziehbar.
Um potentielle Fehler zu finden und zu verbessern, die bei jeder Arbeitsweise und auch bei einer offenen entstehen, müssen diese Änderungen überwachbar sein. Dazu ist es wichtig das die Software nicht nur mitteilt das etwas verändert wurde, sondern auch was verändert wurde.
Mit einem Änderungsprotokoll werden die Unterschiede zwischen zwei Texten zeilen- bzw. abschnittsweise einander gegenübergestellt (auch Diff-Darstellung genannt).
Versionsverwaltungen sind erprobte Werkzeuge aus der modernen Softwareentwicklung und helfen Entwicklern Änderungen an großen Mengen von Quellcode nachzuvollziehen.
So kann synoptisch einfach nachvollzogen werden, welche einzelnen Textstellen verändert wurden. Dies erleichtert den Aufwand der Gegenkontrolle, da nicht eine gesamte neue Version gelesen werden muss, sondern nur die wirklichen Veränderungen.
Änderungen lassen sich zeilenweise am besten verstehen, wobei die eigentliche Änderung in beiden verglichenen Versionen unterschiedlich farbig dargestellt werden sollten.
Wird in einer 20 seitigen Dokumentation nur ein Rechtschreibfehler geändert, wird in der Änderungsdarstellung nur die Zeile die den Fehler enthielt dargestellt und der Rechtschreibfehler und dessen Verbesserung selbst markiert. Eine Sichtung von vielen Änderungen ist so schnell erledigt. Finden größere und inhaltliche Änderungen an einem Dokument statt, müssen auch nur die Änderungen und nicht alle 20 Seiten gelesen werden.
Die Funktion der Änderungsdarstellung gibt es auch in anderer Software. Moderne Textverarbeitungsprogramme bieten ebenfalls die Möglichkeit zur Nachverfolgung von Änderungen, dies ist oft unübersichtlich, nicht auf Mehrbenutzer ausgelegt, meist nur optional zuschaltbar und es gibt keine Benachrichtigungsmöglichkeit.
Wikis können die Nutzer auf unterschiedliche Weisen über Änderungen benachrichtigen:
selektive Beobachtung
weil nicht alle Benutzer alle Änderungen reviewen können, wollen und sollen, kann eine Auswahl von zu beobachtenden Artikeln zusammen gestellt werden. Jeder Artikel kann von jedem Benutzer zu seiner Beobachtungsliste hinzugefügt werden. Finden an diesen Artikeln Änderungen statt, wird der Nutzer benachrichtigt.
die meisten Wikis bieten jedem Benutzer eine persönliche Beobachtungsliste oder Beobachtungsfunktion in einem Dashboard an
oder es können thematische oder kategorische (z. B. Abteilung) Beobachtungslisten angelegt werden, welche von mehreren Personen beobachtet werden.
Recent Changes
erfahrene User und vor allem Wikigärtner können auch alle Änderungen und Neuerungen einsehen: Jede Verbesserung eines Rechtschreibfehlers, Verschiebungen, große inhaltliche Änderungen und gegebenenfalls auch Vandalismus. Bei gut funktionierenden Wikis sind das sehr viele Änderungen. Aber mit etwas Übung gelingt es aber schnell jede Änderung zu bewerten und nur im Fehlerfall zu reagieren. Der zeitliche Aufwand der Kontrolle ist ein Bruchteil der Zeit zur Erstellung der Inhalte.
Nutzer werden über unterschiedliche Kanäle informiert:
e-Mail oder RSS
die meisten Wikis haben die Möglichkeit sich per eMail oder auch RSS benachrichtigen zu lassen, wenn einzelne Artikel geändert wurden. Vor allem in kleinen und selten geänderten Wikis können sich User aktiv informieren lassen wenn etwas geändert wurde.
Übersichtsseiten oder Dashboard
Die meisten Wikis bieten ihren Usern eigene Seiten an, welche die persönliche Beobachtungsliste oder gesamte Recent Changes anzeigen und auf die neueste Version, aber auch direkt auf die Änderungsdarstellung verlinken.
In jedem gut funktionierenden Wiki kommt es zu einer hohen Anzahl an Änderungen, die nicht alle mit der gleichen Priorität beobachtet werden müssen. Neben der Selektion auf bestimmte Bereiche durch Beobachtungslisten lassen sich Änderungen an sich priorisieren.
Um nicht jede kleine oder triviale Änderung, wie z.B Rechtschreibfehler, zwangsweise mitgeteilt zu bekommen, gibt es in den meisten Softwares die Funktion kleine Änderungen zu markieren.
Werden so kleine Änderungen vom bearbeitenden Nutzer markiert, können Nutzer, die andere Änderungen begutachten, diese dann ausblenden. Dieses System bedarf natürlich Vertrauen in die Nutzer welche diese kleinen Änderungen durchführt.
Nicht jede Änderung muss von jedem Nutzer geprüft werden. Nutzer beobachten Artikel nur selektiv und daher kann es vorkommen, dass einige Artikeländerungen nicht beachtet werden. Auch zeitlich lassen sich nicht immer alle Änderungen verfolgen.
Aber auch bei sehr vielen Änderungen muss sichergestellt sein, dass, nach dem Vier-Augen-Prinzip, mindestens eine Person diese begutachtet.
Teilweise ermöglicht es Wikisoftwares Änderungen als überprüft zu kennzeichnen und das anderen Nutzern zu zeigen[1]. So können alle Änderungen, die noch von niemanden betrachtet wurden, selektiv nach-geprüft werden. So wird sichergestellt das mindestens eine Person eine Änderung geprüft hat, ohne dass Wikigärtner alle Änderungen kontrollieren müssen.
Anstatt Änderungen passiv zu monitoren und Änderungen grundsätzlich jedem anderen Nutzer zu zeigen, können Änderungen auch erst nach einer Sichtung durch eine spezielle Nutzergruppe freigeschaltet werden.
Ein Wiki beschleunigt den Änderungsprozess und erlaubt grundsätzlich jedem Teilnehmer Änderungen. Dieser offene Prozess ermöglicht es allen Mitgliedern aktiv und verantwortlich zu agieren. Findet diese gegenseitige Kontrolle aber nicht statt, kann es passieren dass falsche Informationen im Umlauf sind und weiterverbreitet werden. Man kann den offenen Wikiprozess beschränken und ein technisches Freigabesystem vorschalten. Dann können Änderungen eingetragen werden, müssen aber von einem verantwortlichen Mitglied freigeschalten werden.
Zwar hat in jeder Organisation eine definierte Person oder Abteilung die Verantwortung, doch erzeugt man damit einen Flaschenhals im Veränderungsprozess, wenn nur diese definierte Gruppe jeweilige Änderungen freischalteten kann. Besser ist es wenn nach dem Vier-Augen-Prinzip eine generelle Gruppe alle Änderungen freischalten darf. Eine solche Sichtergruppe kann beispielsweise aus allen regulären fest-angestellten Mitarbeiten bestehen, die Änderungen von Auszubildenden, Werkstudenten oder freiberuflichen Mitarbeitern freigeben.
Findet diese Freischaltung zögerlich oder gar nicht statt, wirkt das demotivierend auf das Bearbeiten und Erstellen neuer Einträge.
Freigabesysteme sind ein erhebliches Hemmnis für die Dynamik der Nutzer.
Daher sollte man, wenn eine solche Funktion unabdingbar ist, diese erst nutzen wenn sich in einem Wiki eine ständige und dauerhafte Nutzung abzeichnet.
Um den Trägheit eines technischen Freigabesystem zu verhindern, aber dennoch eine Unterscheidung in geprüftes und spontan gesammeltes Wissen zu haben, kann man auch neue oder strittige Inhalte markieren und diese Markierung von einem Verantwortlichen entfernen lassen.
Eine neue Seite oder Abschnitt kann mit einer Überschrift (z.B. noch zu prüfen von Horst Maier), einer Kategorie oder einem Textbausteine prominent kennzeichnet (groß über dem Inhalt) werden.
Diese Lösung benötigt keine zusätzliche technische Funktion, sondern nur eine Konvention.
Die Information ist vorbehaltlich erreichbar und Inhaltsverantwortlichen ist es möglich "ihre" Inhalte zu kontrollieren.
Bei aller Freude über die transparente Organisation darf man nicht vergessen, dass diese Transparenz auch Gläsernheit bedeutet. Eine so große Sammlung an Informationen lässt nicht nur konkrete Rückschlüsse auf die Organisation zu, sondern auch auf deren Mitglieder und deren Teilnahmewillen, Partizipation und vor allem Arbeitsqualität.
Soziale Kontrolle innerhalb einer Gruppe ist immer, auch ohne digitale Hilfsmittel, vorhanden und auch gewollt. Gegenseitiger Austausch von positiven und negativen Erfahrungen ist ein wichtiger Prozess zum gemeinsamen Lernen und zur Qualitätsverbesserung. Soziale Kontrolle kann aber auch zu sozialer Ausgrenzung oder Bloßstellung führen, wenn Fehler von Nutzern herausgehoben werden und nicht an deren Verbesserung gearbeitet wird.
Über die Versionskontrolle eines Wikis sind auch alle Fehler und Fehlverhalten aller Nutzer dauerhaft einsehbar und lassen sich statistisch Auswerten. Datenschutz heißt hier nicht nur das Informationen nur an Berechtigte gelangen, sondern auch das nicht alle Zusammenhänge des Benutzerverhaltens ausgewertet werden, welche ausgewertet werden könnten. In einem funktionierendem Wiki lässt sich zwar ablesen wer viel positives beisteuert, aber auch wer wenig oder qualitativ schlechtes hinzufügt.
Wikis verändern die Organisationskultur, vor allem die Arbeitsweise. Der klassische Weg, Kommunikation und Information durch ein Prüfsystem laufen zu lassen und zu validieren, wird umgedreht und durch einen nacheilenden Prüfprozess ersetzt. Dieses Vorgehen wird in der Autoindustrie oder der Softwareherstellung (Beta-Version) längst erfolgreich angewandt.
Wichtig ist nun, dass alle Nutzer verstehen, dass es ein Prüfsystem gibt. Und durch Gardening sicher zu stellen dass dieses auch genutzt wird.
Die Einführung eines Wikis, wie jeder anderen Social Media Anwendung, hat technische und organisatorische Aufgaben, vor allem aber die Herausforderung Mitarbeiter und Mitglieder zum eigenständigen Mitarbeiten zu bewegen.
Keine Firma, Behörde, Verein oder andere Organisation müssen zu einer Wikicommunity ala Wikipedia werden, aber Wikis brauchen eine besondere Kultur, die zur Organisationskultur passen muss, denn der Erfolg eines Unternehmens- oder Projektwikis hängt maßgeblich von seiner Akzeptanz bei den Benutzern ab[1]
Vor der Einführung muss man sich kritisch die Frage stellen ob ein Wiki zum eigenen Laden passen kann.
Schlägt dem Gedanken von oben und unten aktive und passive Kritik entgegen, ist eine Wikieinführung ein Himmelfahrtskommando. Man sollte sich vor der Einführung auch sicher sein genug Gärtner zu finden, eine Mehrheit die zurückhaltend zustimmt und ob die Führung, auch mit Ressourcen, das Wikiprojekt trägt. Findet man dies alles nicht oder zu wenig vor, muss man feststellen dass auch dieses Wiki mit großer Wahrscheinlichkeit scheitern wird. Tradierte Firmenstrukturen sind oft zu weit weg von der Laissez-faire und Effizienz, eines Wikis. Einige Unternehmen sind einfach noch nicht bereit dafür [] System wie Wikis zu etablieren und zu fördern[2]. Erzwingen kann man Wikis nicht.
Besser hat man es, wenn der Wille und sogar ein Wiki, vorhanden ist, aber die Fähigkeiten fehlen. Dann helfen Schulungen für die Nutzer und konkrete Aufräumarbeiten im Wiki den erwarteten Mehrwert zu bieten.
Auch wenn ein Wiki von geordneter Spontanität und Flexibilität lebt und die Installation oder der Kauf oft recht einfach ist,
als Projekt benötigt jedes Wiki strukturierte Meilensteine. Das bedeutet nicht, dass man einen Strukturplan für das fertige Wiki erstellt, das wäre konträr zum Wikisystem. Aber Wikis können auch scheitern, an Fehlern, die bei der Einführung vermeidbar sind.
Das sind vor allem die Softwareauswahl, Kommunikation der offenen Benutzungsregularien und die Etablierung der Rolle des Wikigärtners.
Das wichtigste sind Verbündete für die vielen kleinen Schritte. Ein Wiki lässt sich nicht per Befehl einsetzten oder spült sich auch nicht als Modetrend in den Alltag. Jeden Tag aber tun sich neue Möglichkeiten auf, sich das Leben einfacher zu machen.
Nicht wenige Wikis sind gescheitert weil ein Mitarbeiter ein Wiki aufgesetzt hat und dann in Guerillataktik das System etabliert hat. Wenn sich dann ein Vorgesetzter übergangen fühlt, ist es schwierig für weitere organisatorische Akzeptanz zu werben. Ein Wiki bietet vereinzelt kurzfristigen Erfolg bei persönlichen "Aha"-Erlebnissen, der strategische Nutzen kommt aber erst mit der Zeit. Und das benötigt Ressourcen, vor allem Arbeitszeit. Ein organisatorisches Wiki muss daher zumindest gebilligt werden.
Um so größer die Organisation, um so mehr muss das Wiki und dessen Nutzen auch erkennbar von der Leitung gewollt und befürwortet sein. Eine Schlüsselperson (z.B. Schutz vor Ressourcenabzug, Rückendeckung bei Entscheiden) muss zu 100% im Boot sein.[3]
Die Wiki-Syntax und die nicht streng-hierarchische Ordnung sind für Nutzer, die vielleicht gerade mal Word beherrschen, eine große Umstellung. Neben allen anderen Anforderungen wie Rollenkonzept, Workflow, Corporate Design oder technische Plattform ist die Usability die wichtigste Anforderung. Nischensoftware die von wenigen geschulten Spezialisten genutzt wird, kann komplizierter sein. Wikis aber sind auf die eigenständige Verwendung einer breiten Nutzerschaft angewiesen. Daher müssen Wikis im intuitiv und neben der normalen Arbeit bedienbar sein.
Auch wenn ein Wiki nicht zwingend alle Nutzer auch als Beitragende braucht. Um die kritische Masse zu erreichen muss es genügend viele Mitarbeiter, auch mit wenigen technischen Grundkenntnissen,[4] geben die sich auch aktiv einbringen wollen.
Grundsätzlich müssen alle Nutzer Informationen im Wiki einfach auffinden können. Die Schwerpunkte bei der Softwareauswahl, sollen sich vor allem nach den Fähigkeiten der aktiven, aber auch der passiven Nutzer richten.
Am Anfang der Planung steht die Frage wer die konkrete Zielgruppe des geplanten Wikis sein soll? Wikis können nur für einzelne Projektteams, das gesamte Projektgeschäft, einzelne Abteilungen oder die gesamte Organisation eingesetzt werden.
Man kann mit einem Wiki aber auch organisationsfremde Nutzer, wie Kunden oder Interessenten ansprechen und diesen Informationen wie Bedienungsanleitungen oder Anwendungsbeispiele zur Verfügung stellen.
Die Zielgruppe muss die richtige Größe haben und sollte sich auf eine organisatorische Einheit wie Firma, Abteilung oder ein Projektteam beziehen. Es ist zwar besser, wenn ein Wiki einen großen Nutzerkreis einschließt, aber vor allem in größeren Organisationen wird ein organisationsweites Wiki nicht gleich funktionieren. Wichtige Kriterien für die Definition der Zielgruppe sind:
eine Mehrheit, die ein Wiki auch nutzen will und dementsprechend aufgeschlossen ist.
es müssen sich genug Gärtner finden, die im geplanten Wissensbereich auch die entsprechenden Kompetenzen haben. Wenn ein Gärtner nur in seiner eigenen Abteilung offen aufräumen, helfen und moderieren kann und darf, werden Inhalte aus anderen Bereichen (z.B. konkurrierenden Abteilungen, Geschäftsleitung) verkümmern.
Eine zu große Nutzergruppe kann in sehr hierarchischen Organisationen die Bereitschaft zum Beitragen dämpfen, da Nutzer ihr Wissen auch organisationsintern nicht unbedingt offen legen möchten.
Je konservativer eine Organisation ist, desto kleiner sollte die Zielgruppe sein und erst mit abnehmenden Berührungsängsten wachsen.
Kommerzielle Unternehmen werden wohl eine restriktive Offenheit pflegen; NGOs, Vereine oder Gruppen aus der Bildung können offener sein. Es gibt aber auch Beispiele für sehr offene Transparenz bei Unternehmen, so hat die Firma Gitlab ihr internes Handbuch offen im Netz.
Eine Vergrößerung oder Reduktion der Zielgruppe ist jederzeit möglich, dennoch muss im Rahmen der Einführung der richtige Nutzerkreis angesprochen werden, sonst scheitert das Wiki entweder an Inhaltsleere oder an Verantwortungsdiffusion.
Die Auswahl der Wikisoftware ist der schwierigste Schritt einer erfolgreichen Einführung. Denn eine einmal genutzte Software ist schwer wieder zu verlassen. Die Entscheidung darf nicht allein von den IT-Verantwortlichen getroffen werden, denn nur weil eine Wikilösung von einem bereits genutzten oder präferierten Hersteller kommt, erfüllt dieses nicht zwingend seinen Zweck[5]. Vor allem die zukünftigen Wikigärtner, also diejenigen die für Motivation und Ordnung verantwortlich sind, müssen mit entscheiden welches System genutzt wird.
Um zu wissen welches Wiki man braucht, muss eine Analyse der Anforderungen voraus gehen, in der festgelegt wird welche Ausstattung, Besonderheiten und Funktionalitäten benötigt werden.
Es gibt unterschiedlichste Software mit jeweils anderen Schwerpunkten. Welche der definierten Anforderungen höher zu bewerten ist, kommt auf Einsatzzweck, vor allem auf die Zielgruppe an. Ein persönliches Wiki braucht nicht unbedingt ein hoch komplexes Rollenkonzept, ein Wiki für fremde Personen, wie Kunden, schon eher.
Noch wichtiger ist aber die Zielgruppe und die Organisation. Wie offen geht eine Organisation mit Ihrer Kommunikation um? Wollen einzelne Abteilungen zwingend abgesperrte Bereiche, muss das Rollenkonzept komplexer sein; sind alle Mitglieder mit einer gegenseitigen Transparenz einverstanden, dann nicht.
Soll das Änderungsmanagement benutzerfreundlich sein, benötigt man eine große Auswahl an Werkzeugen zur Darstellung von Änderungen (persönliche und Gesamtliste, RSS, Darstellung der Versionsunterschiede).
Bei der Auswahl der Software sollte die Usability an erster Stelle stehen. Die wichtigsten Anforderungen bei der erstmaligen Einführung eines Wikis, wenn Mitarbeiter noch zu Nutzern motiviert werden müssen sind daher:
ein einfacher Schreibmodus. Können alle Mitarbeiter mit Wikitext umgehen oder wird ein WYSIWIG-Editor gebraucht.
Auch wenn eine Pilotphase mit zwei oder drei favorisierten Systemen zusätzlichen Aufwand erzeugt, ergibt sie eine sehr gute Entscheidungsgrundlage. Eine Wiki-Einführung kann man nicht beliebig oft wiederholen ohne "verbrannte Erde" zu hinterlassen.[6]
Eine Gruppe von freiwilligen Beta-Nutzern kann unterschiedliche Funktionen testen und am Ende der Pilotierung alle Inhalte auf ein einziges System migrieren. Der Aufwand ist gegenüber einer tragischen Startfehlentscheidung gering. Außerdem werden so die User in wirklich jede Entscheidung mit einbezogen. Eine Migration von Daten ist je nach Menge auch automatisiert (Artikel kopieren, Syntax wechseln etc.) möglich.
Diese Pilotgruppe soll sich nicht nur aus technikaffinen Befürwortern zusammensetzen, sondern einen repräsentativen Schnitt abbilden, so haben auch Kritiker die Möglichkeit an der Entscheidung teilzuhaben und berechtigte Kritik kann in die Entscheidung mit einfliessen.[7] Je nach Organisationsgröße sollte diese Gruppe zwischen fünf und 15 Nutzern groß sein.
Vor allem Firmenwikis werden oft auf interner Infrastruktur gehostet, was oft dem Datenschutz und der gewünschten Ausfallsicherheit geschuldet ist. Aber gerade bei Wikis mit einem örtlich verteilten oder gar offenen Nutzerkreis können spezialisierte Hostingangebote genutzt werden. Spezialisierte Anbieter hosten Wikis auf Wikifarmen und bieten Wikis als Software-as-a-Service an. Von Vorteil ist hier das Software-KnowHow, auch über sinnvolle Plugins und die Durchführung von Software updates.
Bei der Entscheidung über das Hosting stellen sich folgende Anforderungen:
Software
Bekomme ich die gewünschte Software. Die meisten Anbieter haben sich auf eine Software spezialisiert.
Zugriff
Benötige ich einen Zugriff außerhalb der Geschäftsräume (homeoffices, Partner, Kunden).
HTTPS-Zugang
Zugangsregelung über Webserver
VPN-Zugang
Backup
Wie oft (täglich, wöchentlich), wie (SQLdump, Kopie), wohin (intern, auf eigenes FTP) wird das Wiki gesichert.
Domain
kann man eine eigene Subdomain oder Domain verwenden (also intra.firma.net anstatt firmenintranet.wikihoster.net).
Systemzugriff
Wie stark kann man die Konfiguration anpassen?
Softwareerweiterungen
Können allgemeine und eigene passende Softwareerweiterungen installiert werden. Werden Erweiterungen von einem Hostinganbieter evtl. sogar unterstützt.
Verfügbarkeit
Wie hoch ist die (vertragliche) Verfügbarkeit und Reaktionszeit (Lastverteilung, etc.).
Speicherplatz
Wie sicher ist die Datenbank, evtl. verschlüsselte Datenbanken.
Einbindung fremder Inhalte
Können Interwikilinks leicht erstellt werden, können fremde Medienarchive eingebunden werden.
Die kommerzielle Software Confluence kann auf eigener Infrastruktur betrieben werden oder als Service von Hersteller Atlassian[8]. MediaWiki kann ebenfalls selbst- oder fremdgehostet werden, spezialisierte Anbieter sind blue-spice.org oder wikihoster.net
Ein funktionierendes Wiki soll Antworten auf viele organisatorischen Fragen schon schriftlich bereit halten können. Das Wissen zur Beantwortung muss aber erst einmal gesammelt und aufgeschrieben werden.
Für den Beginn einer Wikieinführung empfiehlt es sich gemeinsam festzulegen, welche Themengebiete zu erst im Wiki verwaltet werden sollen. Die Nutzer, nicht die Organisationsführung[9], sollen entscheiden mit welchem Inhalt das Wiki starten soll. Am einfachsten ist, es ein bestehendes, aber überschaubares Informationsdefizit zu beheben, zu welchem es noch keine Dokumentation gibt.
Am besten eignen sich Inhalte, die zwar auf wenigen Seiten beschrieben werden können, aber von vielen gleichzeitig gelesen und verändert werden müssen, um die Vorteile der Zusammenarbeit in einem Wiki zu erkennen[10].
Dennoch sollte die erste Anwendung wichtig genug sein, um einen signifikanten Mehrwert der Information zu zeigen.
Um eine solche Killerapplikation kann sich dann Schritt für Schritt [11] das Wiki entwickeln.
Agenden und Protokolle für Besprechungen und Sitzungen
Um Teilnehmer einer Besprechung auf die Themen vor- und nachzubereiten, werden Agenden und Protokolle erstellt. Oft ändert sich aber Themenauswahl oder Prioritäten, da andere Fragestellungen aufkommen oder sich Schwerpunkte verschieben. In einem Wiki lassen sich diese Themen sammeln und gemeinsam priorisieren. Alle Teilnehmer haben Einblick auf die aktuelle Agenda und können diese anpassen. Die Verantwortlichen können die Änderungen einsehen, freigeben oder zurücknehmen. Nachrangige Themen, die erst auf späteren Sitzungen behandelt werden sollen, können einfach gesammelt werden.
Es dauert häufig sehr lang, bis neue Mitarbeiter produktiv arbeiten, auch deshalb so lang, weil diese erst interne Prozesse und Verfahren, aber auch Traditionen und Gewohnheiten lernen müssen. Ein Wikiseite als Einstieg für alle Neulinge hilft, die ersten dieser vielen Fragen zu beantworten.
Neue Mitarbeiter haben einen unverstellten Blick auf die Organisation, ohne Betriebsblindheit. Sie sollen das Wiki nicht nur nutzen, um Inhalte zu lesen, sondern sich vom ersten Tag aktiv beteiligen. Wenn unverständliche oder unvollständige interne Inhalte nicht verstanden werden, dann durch erfahrene Nutzer erklärt werden, kann das Wiki gleich mit verbessert werden. Außerdem kann "frischer Wind" tradiertes Wissen hinterfragen.
Weiter kann man festlegen, was ein neuer Mitarbeiter erledigen muss, ein Laufzettel, aktualisiert und verbessert im Wiki, hilft neuen Mitarbeitern Aufgaben wie NDAs unterschreiben, Zugangskarten, System Konten anlegen, Kantinekarte kaufen, strukturiert abzuarbeiten, ohne einzeln nachfragen zu müssen. Im Falle des Ausscheidens kann ein Wiki ebenfalls alles nötigen Todos für Mitarbeiter und Firma zusammenfassen.
Eine Wikiseite, auf der Mitarbeiter Ideen einbringen können, als einfache Form des betrieblichen Vorschlagswesen, erfordert wenig Aufwand, aber neue Ideen erreichen andere Kollegen und fördern deren Weiterentwicklung.
Interne und externe Handbücher
Software oder Maschinen benötigen Betriebsanleitungen. In einem Wiki können Handlungsanweisungen schnell und einfach gesammelt, kontinuierlich an Weiterentwicklungen angepasst und so auf dem aktuellen Stand gehalten werden.
Festschreiben der Corporate Identity
Die Angaben über standardisierte Hausschriftarten, Logodateien, Firmenfarben in RGB, CMYK und Pantone werden auch in viele Abteilungen gebraucht.
Inventaraufstellung
Kleine Büros oder Geschäfte haben meist kein System zur Verwaltung von Inventar. Um einen Überblick über Computer, Bürogeräte oder Möbel zu erhalten, genügt eine Liste im Wiki. Dort kann dann weiterführende Information, wie Gebrauchsanleitung, Lieferanten oder Garantiebedingungen, verlinkt werden.
Pressespiegel
Jede Organisation sammelt gerne externe Veröffentlichung und Presseberichte. In einer Wikiseite lassen sich Links auf Onlinepublikationen, Scans oder Erwähnungen einfach sammeln.
Sicherheitsregeln
IT-Sicherheitsregeln, wie Passwortqualität und Nutzungserlaubnis, Diebstahlschutzregeln oder Fluchtpläne für Gebäude - Wikis sind ein guter Ort, Regeln aus unterschiedlichen Bereichen zusammentragen. Nutzer können all diese Informationen immer aktuell und vor allem einfach einsehen.
Social Media Guidelines
Verhaltensregeln, wie sich Mitarbeiter in Social Networks verhalten sollen.
FAQ
Ein Wiki kann Antworten auf Häufig gestellte Fragen (FAQ) geben. Und wikiintern auf weiterführende Artikel verlinken.
Man muss vermeiden Redundanzen aufzubauen oder Inhalte aus anderen Systemen zu kopieren, diese Daten sollten besser im Wiki verlinkt oder eingebunden werden (z.B. Adressdaten).
Durch den Hype-Zyklus laufen auch die meisten Wikis
Der Hype-Zyklus, der Phasenverlauf der Aufmerksamkeit einer neuen Technologie, kann auch ein Organisationswiki treffen. Nach einer ersten Euphorie über erste Anwendungen kann ein Tal der Ernüchterung folgen.
Dies passiert vor allem, wenn es nicht gelingt die Inhalte so zu konsolidieren, dass diese von allen Nutzern gefunden werden können. Ist das Wiki nur eine Ansammlung von einzelnen zusammenhanglosen Einzelwissensteilen, finden zwar die jeweiligen Ersteller ihre Inhalte wieder, anderen bleibt der Mehrwert des ganzen Wikis verborgen. Um aus der Ernüchterung wieder heraus zu kommen, müssen vor allem die Wikigärtner auf eine Gesamtkonsistenz achten und auch Phasen in denen das System noch keinen direkten klaren Nutzen für die Zielgruppe hat aktiv überbrücken[13].
Wird ein Wiki nicht gepflegt und durchlebt Zeiten von hoher Nutzung, beispielsweise in einem Projekt, und Zeiten geringer Nutzung, so kann es passieren, dass Inhalte zwar vorhanden sind, aber sich nicht mehr in die sich verändernde Wikiumgebung integrieren. Daher ist eine übergeordnete Betreuung über den gesamten Nutzungszeitraum wichtig; es muss Gärtner geben, die bereit sind, das Wiki als ganzes im Auge behalten.
Zu einem Wiki gehört es auch die Prozesse zum Arbeiten mit dem Wiki selbst festzuschreiben. Diese sollten alle aus der täglichen Wikiarbeit entstehen und die Best Practice eines jeden Organisationswikis festhalten und natürlich stetig angepasst werden.
Die ist besonders wichtig, so dass Benutzer aus der Vorgehensbeschreibung den Mehrwert der Plattform für ihren eigenen Arbeitsprozess erkennen können[14]
Inhalt
Welche Inhalte sollen gesammelt und bearbeitet werden, aber auch welche nicht .
Was darf explizit nicht aufgenommen werden, um den Datenschutz einzuhalten.
Ein organisatorisches Wiki sollte einen Eigennamen haben, um diese Wissensressource auch im täglichen Sprachgebrauch benennen zu können. Der Begriff 'Wiki' eignet sich nur bedingt, da es oft mehrere Wikis oder Wikifunktionen gibt. Auch verwechseln viele User dann zu oft das organisatorische Wiki mit Wikipedia.
Weiter sollte der Namen keine Nutzungseinschränkung assoziieren. Ist die erste geplante Anwendung ein Pressespiegel, werden diese Wikis oft so genannt (z.B. pressespiegel.intern). Eine weitere, ja gewünschte, universale Nutzung würde diesem Namen widersprechen.
Entweder man nutzt eine nüchternere funktionale Benennungen, wie intranet, guide(-line), factbook, handbook oder manual. Oder man kann hier etwas Kreativität walten lassen und vielleicht den Vornamen des Firmengründers, eine von allen geliebte Comicfigur oder auch fiktionaler Tiere (z.B. Elefanten) Pate stehen lassen.
Auch wenn Wikis intuitiv zu bedienen sind, können Schulung Hemmungen abbauen, die Inhalte und deren Qualität schneller steigern und Mehraufwand verhindern. Dabei sollten alle Mitarbeiter eine Grundschulung (ändern, neu erstellen) erhalten.
Dennoch ist es sinnvoll fähige Multiplikatoren zu benennen, welche das gesamte Wiki im Auge behalten (Beobachten, Kategorisieren, etc.) und als Ansprechpartner für Rückfragen zur Verfügung stehen.
Ein Wiki einzuführen ist ein nicht zu unterschätzender organisatorischer Prozess. Es gibt zahlreiche Beratungsfirmen, die diesen Prozess unterstützen. Die meisten Firmen sind auf eine Software spezialisiert. Daher muss man sich wahrscheinlich selbst für eine Richtung im
Software Angebotsspektrum entscheiden und sich dann dementsprechend Unterstützung suchen.
Hallo Welt ist eine 15-köpfige Beratung mit größeren Projekten wie Bluepedia, die Firmengründer sind die Herausgeber von Wiki - Kooperation im Web (ISBN 978-3540351108) und geben die Mediawiki Enterprise-Erweiterung BlueSpice heraus.
Seibert Media ist eine Agentur mit 70 Angestellten und zahlreichen großen Wikiprojekten, Herausgeber von Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in UnternehmenISBN 978-3-8349-2827-6 und zertifizierter Confluence Partner.
Abschließend sei für alle, die gern eine Wiki in einer Organisation etablieren wollen, gesagt: Es ist kein einfacher Weg, der aber zu einem schönen, einfachen, erfolgreichen System führen kann. Darum gilt wie immer im Leben: Sei mutig
↑Martin Seibert, Sebastian Preuss und Matthias Rauer: Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in UnternehmenISBN 978-3-8349-2827-6 S. 123
↑Martin Seibert, Sebastian Preuss und Matthias Rauer: Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in UnternehmenISBN 978-3-8349-2827-6 S. 79
↑Martin Seibert, Sebastian Preuss und Matthias Rauer: Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in UnternehmenISBN 978-3-8349-2827-6 S. 119
Bei der Auswahl einer Wikisoftware sind viele technische und funktionale Anforderungen zu beachten um die richtige Wahl zu treffen.
Je nach Anforderungsprofil des geplanten Wikis, aber auch der Nutzerschaft und deren Organisationsprofil ergeben sich unterschiedliche Schwerpunkte. Braucht ein großer traditioneller Betrieb vermutlich eher strikte Zugangsbeschränkungen und sehr einfache Bearbeitungsmöglichkeit, sucht ein junges Startup eher ein System mit hoher Bearbeitungsgeschwindigkeit, flexiblen Erweiterungen und einfachem mobilen Zugriff.
Leider ist die Entscheidung für die genutzte Software die unflexibelste bei der Einführung eines Wikis und sollte daher gut geplant sein. Denn eine Umstellung der Software ist technisch aufwändig und erfordert immer eine neue Eingewöhnung der Benutzer.
Im Gegensatz zu Struktur- und Inhaltsänderungen, die jederzeit möglich sind und sogar das Grundprinzip und Arbeitsweise eines funktionierenden Wikis ausmachen.
Da ein Wiki von vielen Nutzer aktiv verwendet werden soll, ist die Usability die wichtigste Eigenschaft. Inhalte müssen einfach, logisch und über mehrerer Wege gefunden und erreicht werden können. Änderungen müssen einfach, schnell und ohne Hürden möglich sein.
Die Ladegeschwindigkeit der Seiten an sich und vor allem der Editierfunktion sollte schnell und zügig sein. Auch wenn es hier oft nur um Sekunden oder sogar Millisekunden geht. Ein Nutzer, unter Zeitdruck, der aber dennoch im Wiki etwas nachtragen will, kann von 2-3 Sekunden Ladezeit bereits so demotiviert sein, dass er sich doch wieder der eigentlichen Aufgabe widmet.
Zu viele funktionelle Buttons verwirren den User. Zwar ist eine Versionsgeschichte, eine Bookmarkfunktion oder die Seiten-Umbennenung wichtig, aber das sind Funktionen für erfahrene Nutzer. Der gewillte Wikibeginner muss erst mal nur den Edit-Button finden. Es genügt auch diesen prominent darzustellen.
Die größte Anforderung an die Usability ist die einfache Möglichkeit Inhalte beizutragen.
Ein Wiki ist nur so gut wie die Beiträge seiner Nutzer. Um die Nutzer zum aktuellen und ausführlichen Editieren zu motivieren muss dies einfach und schnell funktionieren.
Die Dokumentation sollte in einem Wiki immer zeitnah nach einer Veränderung oder gleich nach dem Erkenntnisgewinn sein; die guten Vorsätze: nach dem Projekt, nach dem Urlaub oder "wenn mal Zeit ist", bleiben meistens Vorsätze und werden viel zu selten erfüllt. Um aber im Tagesgeschäft noch nebenbei Wiki-Einträge zu erstellen muss dies so schnell und einfach gehen, wie eine Email schreiben.
Die Erweiterung WikiEditor für Mediawiki hilft dem Nutzer die Syntax zu schreiben.
Ein Wiki ist hauptsächlich ein Textmedium. Die Wiki-integrierte Textverarbeitung soll Nutzern eine möglichst einfache Bearbeitung von bestehenden Texten ermöglichen und Änderungen nachvollziehbar darstellen.
Viele Wikis speichern ihre Inhalte in einer vereinfachten Auszeichnungssprache (auch Wiktext, Lightweight Markup Language oder Markup genannt). Dieses Wiki-Markup besteht aus Text und Steuerzeichen die Formatierung und Struktur abbilden.
Dieser sieht so oder ähnlich aus:
== Überschrift ==
Ein '''fettes'''oder ''kursives'' Wort und ein Link auf [https://de.wikipedia.org/wiki/Auszeichnungssprache Wikipedia]
* erster listenpunkt
* zweiter listenpunkt
Es gibt zwei wichtige Gründe warum Wikis Markup einsetzen:
Änderungen sind exakt nachvollziehbar, da nicht nur Text verglichen werden kann, sondern auch Änderungen in der Struktur und am Format. Werden Struktur und Format versteckt gespeichert, ist es schwieriger dortige Änderungen darzustellen. Ändert beispielsweise ein Nutzer eine 2-rangige Überschrift zu einer 3-rangigen, müsste man diese sprachlich darstellen "Text" von Überschift 2 zu Überschift 3. Im Markup sieht man den Unterschied viel schneller (z.B. == Text == gegen === Text ===).
dem Text kann eine semantische Struktur geben werden.[1], die vor allem für kollaboratives Arbeiten notwendig ist[2].
Der Wechsel von der Leseansicht in den Editiermodus verwirrt viele Nutzer. Ist das Dokument lang oder komplex bekommt der Nutzer nach dem Klick auf den Edit-Button, im Gegensatz zu einem Office-Dokument oder Email, eine neue Ansicht in der er sich erst zurecht finden muss.
Er verliert die gerade gelesene Textstelle und ist ganz oben auf der Seite und muss erst wieder an die gewünschte Stelle scrollen. Wikis lösen das unterschiedlich :
Mit der Funktion edit section können einzelne Unterabschnitte einer Seite bearbeitet werden, ohne dass sich der User nach dem klick auf Edit erst im Syntax der ganzen Seite orientieren muss.
Confluence merkt sich die Stelle an der der Nutzer war und scrollt im Bearbeitungsmodus an die gleiche Stelle[3].
Am einfachsten wäre es den angezeigten Text direkt zu bearbeiten, ohne eine neue Ansicht zu laden. Mit HTML5 Content Editable ist dies auch möglich, tiki ist derzeit das einzige Wiki das diese Funktion zur Verfügung stellt. Leider gibt es derzeit keine Umsetzung um auch Formate (Überschiften, Links, Listen, etc) eingeben oder ändern zu können.
Eine weitere und häufig genannte Schwierigkeit ist, dass dieses reine Markup für sehr viele [4] User verwirrend und demotivierend sein kann, da die unterschiedlich formatierten Elemente alle gleich aussehen. Eine Überschrift ist nicht fett und groß, wie in Word, sondern nur mit zwei Gleichheitszeichen (==) gekennzeichnet. So geht für den Nutzer die sichtbare Struktur verloren.
Markdown editor mit einer Toolbar für die wichtigsten Funktionen und gehighlighteten Tags, die bedeutungsgemäß formatiert sind.
Es gibt mehrere Ansätze um hilfebedürftige Nutzer nicht mit dem Syntax und einer großen Textbox ganz allein zu lassen. Hilfsmittel um die sichtbare Struktur wieder anzudeuten und das Bearbeiten zu vereinfachen können sein:
Toolbar
um Textstellen fett oder kursiv zu formatieren, Zeilen zu Überschriften deklarieren oder Links und Bilder mit einem Auswahldialog einzusetzen.
Code Highlighter
stellen weiterhin die ganze Semantik des Markups dar, dennoch sieht der User wie das formatierte Ergebnis aussehen wird.
Der WYSIWYG-Modus ist eine Textdarstellung vergleichbar mit Office Textverarbeitungsprogrammen oder einem E-Mailprogramm. Der Nutzer sieht wie das Dokument aussehen wird wenn es gespeichert ist, daher ist er eine häufige Anforderung seitens der Nutzer. So senken sich die Eingangshürden für Word- und Powerpoint-Nutzer.
Tags, Anweisungen an die Software wie der Text aussehen soll, werden vor dem Nutzer versteckt, aber dennoch gespeichert. Die meisten Wikis können mit WYSIWYG-Editoren nachgerüstet werden, bringen diesen von Haus aus mit, wie BlueSpice, oder ermöglichen sogar nur das arbeiten mit WYSIWYG-Editor, wie Confluence.
Die für das Wiki wichtige Änderungsdarstellung ist so schwieriger, da Format- und Semantikänderungen nicht über Tags, sondern grafisch, dargestellt werden müssen.
Außerdem verändern viele WYSIWYG-Editoren die Quelltexte weitaus mehr als notwendig oder verfälschen diesen sogar[5]. Es werden teilweises falsche Formate eingesetzt (z.B. Fettschrift und Unterstreichung anstatt Überschrift), Verlinkungen entfernt oder format-entstellende Elemente hinzugefügt.
Auch können weder Open-Source- noch kommerzielle WYSIWYG-Editoren die Erwartungshaltung an den Funktionsumfang, im Vergleich zu Office-Programmen, vollständig erfüllen.[6] Um dennoch WYSIWYG-Editoren einsetzen zu können ist es wichtig, dass diese den Inhalt als Markup und nicht als HTML speichern. Nur so ist gewährleistet, dass komplexe Inhaltskonstrukte weiter in Markup verarbeitet werden können.
Viele Wikis verwenden eine eigene Syntax, die vor allem HTML vereinfachen wollen, aber nicht nur auf usability optimiert wurden. Es gibt alternative Lightweight Markup Languages, die vor allem unter dem Gesichtspunkt entwickelt wurden für Menschen einfach schreibbar, aber vor allem auch lesbarer zu sein. Beispielsweise muss man in Mediawiki Überschriften am Zeilenende schließen (== Überschrift ==), ein Relikt aus HTML; Markdown benötigt nur ein Zeichen am Zeilenanfang (## Überschrift). Auch wenn der Unterschied klein erscheinen mag, im Schreibfluss ist Markdown schneller und vor allem einfacher zu merken.
Weitere empfehlenswerte Lightweight Markup Languages sind reStructuredText und Textile (wird in Redmine genutzt).
Die meisten Wikisysteme können Dateien und Bilder verwalten. Aus Usability Sicht ist ein dialog-geführter Upload und ein durchsuchbares Medienarchiv wichtig. Manche Systeme können Bilder als Drag and Drop annehmen. Meist lässt sich einstellen welche Dateitypen erlaubt sind. Wenige Wikis haben einen Bulkupload, bei dem mehrere Dateien gleichzeitig oder ganze Ordner hoch geladen werden können.
Da Bilder und Videos schwierig sinnvoll kollobarativ verändert werden können, werden diese in einem Wiki nur eingebunden. Allerdings lassen sich diese dennoch versionieren. So können auch Änderungen der Nutzer an Bildern und Videos durch die Gesamtansicht von verschiedenen Versionen nachvollzogen werden.
Bilder sollten skalierbar und direkt in den Wikinhalt und als automatische Gallerie eingebunden werden können.
Zusätzlich zum Text können Tabellen und Charts die Inhaltsvermittlung erleichtern.
Kleine und auf Darstellung begrenzte Tabellen können mit den meisten Wikisytemen, per Wikitext oder WYSIWYG, erstellt werden. Aufwändige und berechnenden Tabellen, wie sie aus Office Tabellenkalkulationen bekannt sind, sind in Wikis nicht möglich.
Diagramme, mit der Einfachheit von Powerpoint, sind in Wikis ebenfalls nicht möglich. Lediglich Confluence bietet eine browserbasiertes Mockup-Tool.
Mediawiki bietet eine Graphviz-Extension[7], durch die Graphviz-Auszeichnungssprache können Diagramme genauso wie Text gemeinsam erstellt und verändert werden. Allerdings ist die Graphviz-Auszeichnungssprache komplexer als Wikitext und Diagramme können nicht mit der Maus gezeichnet werden, sondern müssen beschrieben werden. Graphviz wird vermutlich nur von technisch affinen Nutzern verwendet werden können.
Ähnlich zu Bildern und Videos können Tabellen und Diagramme als Datei hochgeladen und eingebunden werden, eine gemeinsame Weiterverarbeitung und Änderungsdarstellung wie bei den Wikiinhalten ist nicht möglich. Ein einmal hochgeladenes Powerpointdiagramm kann nur erneut bearbeitet und wieder komplett hochgeladen werden.
Externe Dienste können, je nach Datenschutzanforderung, diese Aufgabe auch übernehmen.[8]
Auch wenn Wikis jedem neuen Artikel ein Anfang auf einem weissen Blatt ermöglichen, gerade bei Inhalten gleicher Art gibt es Strukturen die jede Seite braucht und die dem Nutzer mit einer Grundstruktur helfen alles Relevante beizutragen.
Dem Nutzer aber auch ermöglichen aus dieser Struktur wieder auszuscheren.
Es macht weniger Sinn existierende Artikel wieder und wieder zu kopieren, da sich so Fehler und Unvollständigkeiten fortsetzen. Vorlagen kann man für Vieles anbieten: Projekte, Besprechungsprotokolle, Blogposts.
Vorlagen können zahlreiche Elemente enthalten:
die meist genutzten Überschriften (z.B. Verwendung, Zuständigkeit, Historie etc)
Inhaltsvorschläge die nach dem Ausschlussprinzip gelöscht werden und den gewünschten Inhalt hinschreiben (z.B. Projektleiter ist Maria Peter Johanna Hans)
Neben der Speicherung, Veränderung und Darstellung ordnet ein Wiki Informationen und Wissen in seinen jeweiligen Kontext ein.
Große Mengen an Informationen und vor allem unterschiedliche Wissensgenres müssen aber in einem Ordnungssystem strukturiert sein.
Wikis bieten unterschiedliche technische Ordnungsmöglichkeiten.
Verlinkungen sind ein zentrales Ordnungselement in semantischen Strukturen. Wikis müssen den Nutzer einladen leicht zu verlinken. Links sollten leicht im Textfluss geschrieben werden können.
Interne Links werden in den meisten Wikis mit doppelten eckigen Klammern ([[Seitentitel]]) gekennzeichnet. Sinnvolle Hilfsfunktionen ist die Autovervollständigung für Linkziele, entweder als Inlinefunktion im Editor (dieser zeigt nach dem Tippen von [[ mögliche Titel an) oder in einer Dialogbox.
Nicht nur interne Hyperlinks sind wichtig, auch externe Links müssen einfach erzeugt werden können. Bei häufig gebrauchten Zielen, wie verknüpfter Software (CRM, ECM etc), lassen sich Links mit Interwiki links abkürzen. (z.B. [[adresse: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 einfach sehen welche Projekte einen Prozess nutzen.
Weiterleitungen ermöglichen es Synonyme oder untergliederte Seitentitel auf andere Seiten verweisen zu lassen (z.B. Konferenzraum Main auf Büro Süd). Dies ist wichtig um unterschiedliche gesuchte Begriffe auf einen Inhalt zu verweisen und so Nutzern die mit anderen Begriffen suchen trotzdem den gesuchten Inhalt finden lassen.
Kategorien ordnen den Inhalt in logische Gruppen. Dabei gibt es streng hierarchische Kategorisierungen, bei der alle Kategorien immer einer Baumstruktur nach unten folgen müssen, oder matritzenförmige Kategorien, bei der auch Querkategorien angelegt werden können.
Wichtig ist hier 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 zahlreicher werden.
Ein Namensraum (englisch namespace) ist ein Ordnungsystem aus der Software Programmierung, bei dem alle Objekt eindeutig ein einer Verzeichnisstruktur als Baum angeordnet sind. In Wikis sind Namensräume, in Confluence auch Space genannt, Teil des Seitentitels, die jeden Artikel in genau eine hierarchische Unterkategorie einordnen.
Sie sind ähnlich wie Order in einem Dateisystem und erscheinen meist im Seitentitel und der URL (z.B. wiki.example.com/namensraum:seite). Der Namensraum kann je nach Software im Seitentitel und der URL durch ein allgemeines Trennzeichen (: oder /) abgetrennt werden. So ist bei Wikis in Organisationen: Ordnung und Wikis in Organisationen: Kultur der Bereich Wikis in Organisationen der Namensraum. Alle Artikel, die mit diesem beginnen, gehören zu einem Namensraum.
Namensräume können je nach Software unterschiedliche Funktionen ermöglichen:
Links, in Syntax geschrieben ([[Zielseite]]), werden entweder absolut oder relativ zum Namensraum erzeugt. Relativ bedeutet dass der Link [[Zielseite]], innerhalb des Namensraum, auf die Seite Namensraum:Zielseite geht, bei absoluten links führt dieser ganz normal auf die Seite Zielseite.
Die Kategorisierung mit Tags ist bei manchen Wikis nur innerhalb eines Namensraum möglich
Namensräume könne auch unterschiedliche Layouts nutzen. Das können andere Seitenstrukturen (z.B. ein- oder zwei-spaltig) sein oder graphische Unterschiede (z.B. andere Hintergrundfarbe).
Meist kann man die Suchfunktion auf Namensräume einschränken.
Namensräume sollten sparsam und richtig eingesetzt werden.
Eine Transklusion ist die Funktion, Inhalte anderer Seiten oder einzelner Abschnitte daraus, in eine andere Seite einzubinden. So können Inhaltsbausteine[9] an unterschiedlichen Stellen im Wiki mehrfach wiederverwendet werden.
Wird der transkludierte Text aktualisiert, aktualisiert sich automatisch auch die Transklusion in allen Seiten in welchen diese eingebunden ist.
Genutzt werden Transklusionen für:
Textbaustein
Textbausteine ermöglichen Kennzeichnungen oder Hinweise. In der Wikipedia z.B. werden so Warnhinweise zu Gesundheitsthemen eingefügt. In einem Organisationswiki können so die verantwortlichen Ansprechpartner einfach in Artikel eingeführt werden.
Infobox
Eine Infoboxen enthält standardisierte Metadaten zu den Artikelinhalten. Bekannt aus vielen Wikipediaartikeln zu Städten, Unternehmen oder Pflanzenarten [10]. In einem Projektwiki kann man so Metadaten, wie Ansprechpartner, Kunde, Zeitraum eines Projekts speichern.
Unternavigation
Eine Unternavigation (wie am Endes dieses Artikels) ermöglicht es dem Leser bei einer zusammenhängenden Gruppe aus Artikeln schnell die Links zu relevanten Nachbarartikeln zu sehen. Infoboxen helfen auch als Einstieg zu einem Themenkreis. Die Anzahl der aufgeführten Artikel soll sich auf maximal 15 beschränken, mehr wird unübersichtlich.
Die so erfassten Inhalte können je nach Wikisoftware aggregiert und als strukturierte Daten dargestellt werden. Teilweise lassen sich Transklusion sogar logisch programmieren (Bedingte Anweisung und Verzweigung in Mediawiki[11]).
Ganze Textabschnitte aus Fließtext sollten nicht in unterschiedlichen anderen Seiten transkludiert werden, da der Leser sonst Inhalte auf unterschiedlichen Seiten wiederfindet und eine eindeutige Zuordnung des Inhalts zu einer eindeutigen Fundstelle nicht möglich ist. Sind Inhalte an unterschiedlichen Stellen relevant, ist es besser diese als eigene Seite auszugliedern und dann auf diese zu verlinken.
Wikis sind primär für semantischen Text gedacht. Dennoch ist es möglich auch strukturierte Daten zu verwalten.
Tabellen zur einheitlich und wieder erkennbaren Darstellung strukturierter Daten sind in Wikiartikeln rudimentär möglich. Wenn auch die Funktionalitäten nicht so komplex sind wie in Tabellenkalkulationen (z.B. LibreOffice Calc, MS Excel). Dennoch hat eine Tabelle im Wiki den Vorteil gemeinsam mit mehreren Nutzern bearbeitbar zu sein.
Zusätzlich ermöglichen es Wikisysteme strukturierte Daten zu verknüpfen, zu aggregieren und anderweitig wiederzuverwenden.
Es ist möglich Daten aus Artikeln zu sammeln, meist mit Transklusionen und an anderer Stelle konsolidiert einzubinden.
Die Daten werden, genau wie Fließtext, innerhalb von Artikeln in einer strukturierten Form (z.B. Tabellen, Transklusionen, Überschriften, Listen) gespeichert.
Dies erleichtert dem Nutzer die Eingabe strukturierter Datensätze, die einfach über, unter oder sogar mitten in die Prosainhalten geschrieben werden. Man benötigt kein zusätzliches Backend oder Eingabemaske. Außerdem ist man flexibler beim Hinzufügen von neuen Datenfeldern. Selbst wenn neue, zusätzliche Datenfelder nicht verarbeitet werden, sie können von jedem Nutzer eingepflegt werden, ohne die Software anpassen zu müssen.
Die Wiki-Software, ähnlich einer dokumentenorientierte Datenbank, liest diese Daten ein und stellt sie strukturiert, an einer anderen Stelle, dar.
Beispielsweise kann ein Projektwiki eine Projektliste mit Status, Zuständigkeiten, Kontakten, Terminen generieren. Weiterhin hat man den Vorteil jedes Projekt individuell, als Wikiseite, zu beschreiben.
Nicht jede Software bietet die Möglichkeit strukturierte Daten zu verwalten. Die meisten im organisatorischen Umfeld gesetzten Wikis aber schon, wenn auch unterschiedlich ausführlich:
Confluence kann Daten aus Tabellen mit einem Makro einbinden. In Mediawiki ist es möglich Daten aus einzelnen Abschnitten[12], gekennzeichneten Bereichen[13] oder einzelne Werte aus Transklusionen[14] in anderen Seiten wiederzuverwenden. Darüber hinaus gibt es mehrere Möglichkeiten, strukturierte Daten in MediaWiki zu verwalten.[15]
Dokuwiki kann Abschnitte anhand von Überschriften gesammelt in anderen Artikeln einbinden.
Die Inhalte eines Wikis werden, wie andere Webseiten, mit einem Browser dargestellt. Weitere mögliche Darstellungsarten sind:
Mobilgeräte
Nicht nur das mobile Internet, sondern auch das mobile Intranet wird immer wichtiger. Außendienstmitarbeiter oder Montagetrupps können wichtige, umfangreiche und aktuelle Information auch ohne Laptop abrufen. Dazu ist eine Darstellung durch Responsive Webdesign oder eine mobile Version möglich.
Drucken
Für normale Büroausdrucke gibt es in allen Wikisystemen eine Druckversion, wie bei Internetseiten auch üblich. Aufwendigere Druckverarbeitungen für Broschüren oder gebunde Bücher sind meist nicht eingebaut. Es gibt aber Möglichkeiten ein Wiki als Text- oder Mediadatenbank eines Desktop Publishing Systems einzubinden. Teilweise können mehrere Seiten in Buchform gebracht werden, um alle oder einzelne Artikel in ein klassisches Buch zu binden (für Handbücher etc.).
Präsentation
Die Inhalte eines können auch vor Gruppen präsentiert werden. Dabei muss man nicht unbedingt alle Inhalte statisch aus dem Wiki in eine Powerpointpräsentation kopieren. Man kann Inhalte direkt aus dem Wiki heraus auf einem Projektor oder einen Gruppenbildschirm vorführen. Teilweise wird S5, ein Präsentationssystem auf der Grundlage von XHTML zur Definition von Präsentation und den dazugehörigen Folien, unterstützt.
Um Inhalte ohne genaue Kenntnis des Seitentitels oder der Kategorie zu finden bieten Suchmaschinen die Möglichkeit einer Schlagwortsuche über den gesamten Inhalt, und nicht nur in Seitennamen oder Kategorien. Die mit den Wikis gelieferten Suchmaschinen sind von unterschiedlicher Qualität. Einfache Wikis nutzen nur die einfache Datenbanksuchfunktion, die nur die eigentlichen Wikiinhalte, aber keine Kategorien oder Anhänge durchsucht. Auch beschränken sich diese auf die exakte Schreibweise und geben keine Ergebnisse zu Fehlschreibweisen (ähnlich dem meinten sie aus Google) an, oder ignorieren Wortstämme (Projektleiter oder Projektleiters). Leistungsfähigere Suchfunktionen (z.B. Lucene) finden auch unscharfe Suchanfragen und können den Suchbereich erweitern oder eingrenzen.
Manche Wikisuchmaschinen können zusätzlich auch Text-Medien wie PDF oder Office-Dokumente mit durchsuchen. Wikis können aber auch in externe Enterprise Search-Systeme (z.B. Google Search Appliance), sofern vorhanden, eingebunden werden.
Aber auch eine perfekte Suche muss vom Nutzer richtig bedient werden.
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.
Wichtig bei der genutzten Versionsverwaltung ist es, dass Versionen einzeln miteinander verglichen werden können.
Um Nutzer über Änderungen zu benachrichtigen sollte eine interne, persönliche Beobachtungsliste (auch Dashboard genannt) und eine Gesamtübersicht aller Änderungen möglich sein. Zusätzlich müssen Änderungsnachrichten auch per Email oder RSS versendert werden können.
Es gibt unterschiedliche Organisationsstrukturen die sich auch im Rollenkonzept eines Wikis widerspiegeln können. Zwar sollte man immer versuchen möglichst einfach und freiheitlich mit den Hierarchien umzugehen, aber manche Organisationen wollen und brauchen speziellere Zugriffsregelungen, um ihre organisatorisches Sicherheitsanforderungen 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 häufigen Änderungen und deren Kontrolle verändert.
Zugriffsseinschränkungen sollten die Ausnahmen sein und es muss vermieden werden das Nutzer nur in wenigen streng zugeordneten Bereichen lesen und schreiben dürfen. Nur so kann man die Zusammenarbeit fördern und die Vorteile einer organisatorischen Transparenz nutzen.
Weiter gilt in einem Wiki mit einem definierten Mitgliederstamm im Gegensatz zu einem freien Wiki im Internet: Jeder der lesen darf, darf auch schreiben[16]. Viele Berater empfehlen auch: Keine Zugriffs- oder Editierbeschränkungen! (alle User dürfen alles)[17]. Die Gefahr, dass Seiten mutwillig zerstört werden besteht aufgrund der namentlichen Nachvollziehbarkeit nicht.
Gesperrte Inhalte, die nur einer exklusiven Gruppe (z.B. Geschäftsleitung, Entwicklung) vorbehalten sind, müssen sicher und einfach verwaltbar sein; dazu gibt es zwei Methoden:
Seite werden einzeln gesperrt
Hier ist die Auswahl der verdeckten Inhalte selektiv. Mit einer einzelnen Sperrung lassen sich wenige, spezielle Seiten mit brisanten Inhalten sperren; eine größere Informationsmenge ist so schwerer zu schützen.
Es werden ganze Namensräume gesperrt
Alle Inhalte, die in einem sinnvollen Namensraum (z.B. Geschäftsleitung) stehen, sind für Nichtmitglieder weder einsehbar noch editierbar. So werden sehr viele Inhalte grundsätzlich dem Zugriff "Gruppenfremder" entzogen.
Es ist aber zu empfehlen Zugangsbeschränkungen immer auf ganze Namensräume zu legen und darauf zu achten das Sperrung im Namen oder im Layout erkenntlich sind. Bei einer Beschränkung von einzelnen Seiten geht leicht der Überblick verloren. Heißt ein Namensraum Geschäftsleitung ist klar wer darauf Zugriff hat, bei der einzelnen Seite Urlaubsregelung ist das nicht zu erkennen.
Die Nutzer eines Wikis 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 verloren und bremsen die Zusammenarbeit. Am Schluss hat jeder Nutzer seinen eigenen, ausschließlich persönlichen Bereich. Der Vorteil eines Wikis ist gerade, dass man Informationen der des ganzen Teams oder Organisation nutzen und aktiv mitgestalten kann.
Single Sign-on ermöglicht es das sich Nutzer an dritten Systemen anmelden und diese Anmeldung im Wiki genutzt wird. Diese Drittsysteme können Intranet-CMS, Active Directory oder LDAP-Anbindungen sein.
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 elementar. 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 Vorteil das Änderungen nah am Zeitgeschehen mit dokumentiert werden können und nicht im Entscheidungs-Rundlauf dahinsterben und sich selbst überholen. Wobei Änderungen im Nachlauf immer noch kontrolliert werden.
Auch wenn der Vorteil eines Wiki vor allem darin liegen Wissen über Gruppengrenzen hinwege zu erfassen, ist es manchmal manchmal nötig Wikis in Bereiche zu segmentieren. Eine grundsätzliche Segmentierung ist über Namensräume oder Spaces möglich, jedoch stoßen diese je nach Software an Grenzen.
Vor allem im Einsatz bei großen Unternehmen, mit konkurrierenden Profitcentern, werden mehrere getrennte Wikis gebraucht. Anstatt nun mehrere einzelne Instanzen einer Software zu betreiben, kann es sinnvoll sein ein mandantenfähige Wikis einzusetzen.
User können dann so konfiguriert werden nur in bestimmten Mandanten zu lesen, suchen, beobachten oder schreiben. So ist es möglich das je ein eigenes Wiki für viele Abteilungen, Projekte oder Gruppen angeboten wird.
Auch wenn der Trend zu ständiger Internetverfügbarkeit geht und ein Kollaborations-Tool vom einfachen Zugriff seiner Nutzer lebt, manchmal benötigt man die Inhalte Wiki eines offline. Entweder weil ein Firmenwiki nur im Intranet verfügbar ist und ein VPN-Zugang jedes mal zeitlichen Aufwand erfordert, um etwas nachzuschlagen, oder weil man unterwegs schlechten oder gar keinen Internetempfang hat. Förster, Tiefbauleiter oder Reisende im ICE sind eben nicht always-on.
Dabei stellt sich die Frage, ob es genügt, Inhalte nur nachschlagen zu können, oder ob man diese auch bearbeiten und bei Netzverbindung wieder zusammen fließen lassen will.
Die meisten Wikis ermöglichen es, einzelne Seiten, Teile oder den gesamten Inhalt als PDF- oder HTML-Snapshots zu exportieren. PDFs übernehmen keine Verlinkung, so dass der Offlinenutzer Kontext zu seiner Information selbst suchen muss. Allerdings fehlt bei PDF- oder HTML-Abzügen oft die Haptik und Funktion des Wikis. Ein lokaler Spiegelserver eines Wikis ermöglicht es den Nutzern in gewohnter Weise, sich durch das Wiki zu klicken, aber Änderungen lassen sich nicht in das Original zurück spielen.
Confluence bietet PDF- und HTML-Exporte[18] und die etwas ältere Offline Extension Roadrunner[19].
Mediawiki ermöglicht PDF-Bücher[20] oder auch HTML-Exporte.
Experimentelle Wikis, die git-Repositories als Datenbasis nutzen, können alle Vorteile einer verteilten Versionsverwaltung, wie git, nutzen und können so Inhalte lesen, bearbeiten und haben zahlreiche Möglichkeiten, inhaltliche Konflikte bei der Zusammenführung zu lösen.
Die Grundfunktionen genügen oft nicht allen Ansprüchen. Add-ons (auch Extensions) erlauben es Eingabe oder Darstellung zu verändern, zusätzliche Daten zu speichern oder fremde Inhalte einzubinden (z.B. Daten aus einem Personenverzeichnis, Wetter-Information). Es gilt zu beachten, ob es eine ausführlich Dokumentation, ausreichende Unterstützung der Community oder des Herstellers gibt und wie die Möglichkeiten zur Eigenentwicklung bestehen.
Über Programmierschnittstellen können Inhalte zur alternativen Nutzung abgefragt werden.
Andere Content-Management-Systeme, Kiosklösungen oder Drucksysteme können Inhalte aus einem Wiki weiter nutzen.
Auch automatische externe Tools zur automatischen Bearbeitung (z.B. Massenimporte, Umbenennungen, Kategorisierung, etc) werden über Schnittstellen integriert.
Schnittstellen bieten Inhalte mindestens in unterschiedlich strukturierten Formaten (z.B. XML, JSON, rohes Markup) an.
Ein grundlegendes System wie ein Wiki muss die Größe und Struktur der Organisation auch abdecken können. Die meisten Technologien mit Datenbanken sind sicherlich standardmäßig für eine Mitgliederanzahl in in den Zehntausenden ausgelegt; aber auch größere Zugriffe sind durch technische Aufrüstung kein Problem.
Auch eine örtliche Verteilung ist weltweit, durch das Internet, möglich.
Die meisten Wikisysteme setzen Datenbanken ein um 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.
Aus diesen Einzelpunkten ergibt sich eine ganze Checkliste an Anforderungen. Diese müssen für jedes Organisationswiki, im Rahmen der Einführung, im Hinblick auf das Einsatzgebiet und die Zielgruppe verglichen werden.
Dabei sind die Schwerpunkte je nach Organisation unterschiedlich. Manche Firmen brauchen unbedingt einen leistungsfähigen WYSIWYG-Modus, wollen aber sogar auf eine Wiki eigene Dateiverwaltung verzichten, da keine Konkurrenz zu internen Netzlaufwerken entstehen soll. Manche Startups schreiben fließend Markdown, wollen aber auf jeden Fall eine umfangreiche Darstellung auf Mobilgeräten und Bearbeitungsmöglichkeit auch von Telefonen und Tablets. Ein Sportverein will vielleicht zahlreiche Untersektionen und die Möglichkeit das Wiki auch als öffentliche Webseite zu nutzen, braucht aber kein Single-Sign-On.
Bearbeitung
Gibt es einen WYSIWYG, oder welcher Wikisyntax (Mediawiki, Markdown) soll genutzt werden.
Einfache Benutzeroberfläche mit wenigen Buttons.
Kann man Abschnitte einzeln bearbeiten (edit section).
Ist der Upload, aber auch die einfache Verwaltung von Dateien möglich.
Können Hyperlinks im Schreibfluss (link suggestion per Autovervollständigung) oder per Dialog eingefügt werden.
Können beliebig viele Kategorien oder Tags eingesetzt werden.
Sind Namensräume einfach anzulegen.
Können Transklusionen einfach erzeugt und auch mit Variablen bestückt werden.
Welche Arten an strukturierten Daten sollen verwaltet werden und können diese aggregeriert werden.
Kann man Tabellen und Charts erzeugen.
Sind Weiterleitungen von Begriffen auf andere Seiten möglich.
Gibt es unterschiedliche Seitenvorlagen und wie werden diese aufgerufen.
Sind Seitentitel eindeutig.
Darstellung
Ist eine Darstellung auf mobilen Geräten möglich.
Ist die Ladegeschwindigkeit ausreichend schnell.
Gibt es eine unscharfe Suche und werden auch Dateien durchsucht.
Werden Änderungen übersichtlich dargestellt (diff) und wie werden die Nutzer darüber informiert (Email, RSS, Beobachtungsliste, Gesamtliste der Änderungen).
Rollen- und Rechte-Management
Reichen die Möglichkeiten des Rechte und Rollenkonzept aus.
Ist ein Single Sign-on an bestehende Usersysteme sinnvoll.
Wird ein Workflow zur Freigabe von Änderungen gebraucht.
Software
Welche Add-on gibt es und kann man gegebenenfalls selbst welche entwickeln.
Auf welche Schnittstelle kann man zugreifen.
Wie skaliert das Wiki bei mehr Nutzern oder Inhalten.
↑Markdown vs. WYSIWYG-Editor "Durch die schnell zu lernenden Auszeichnungen wird zusätzlich eine semantische Denkweise gefördert."
↑Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts. aus Why Wiki Works
↑„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.“ aus zungu.net - Is What You See What You Wiki?
Wikis sollen Informationen technisch zuverlässig speichern, diese korrekt ausgeben und Änderungen nachvollziehbar gestalten. Bei einem kollobarativen und vernetzten System muss zusätzlich definiert werden, welche Benutzergruppen welche Inhalte lesen, schreiben und verändern dürfen.
Wikis können unterschiedliche Rollenkonzepte abbilden.
Je nach Software ist es möglich, unterschiedliche hierarchische Gruppen und Rollen anzulegen, um so zu verhindern, dass Unberechtigte Zugriff auf Daten haben.
Dennoch ist es empfehlenswert Zugangsrechte nicht zu komplex zu gestalten und Nutzern möglichst viel zu erlauben, um eine möglichst gute Zusammenarbeit zu ermöglichen.
Neben einer zwingend notwendigen Gruppeneinteilung, um Vertraulichkeit zu gewährleisten, (z.B. Geschäftsleitung, Buchhaltung, Mitarbeiter) sollten die Benutzerrollen, für alle Gruppen, möglichst einfach sein: jedem der Lesen kann, sollen auch Änderungen erlaubt sein.
Beschränkungen die nur der vorbeugenden Qualitätskontrollen dienen, sind nicht nötig, da die Qualität durch eine umfangreiche Kontrollfunktion sichergestellt wird. Denn der größte Teil der Veränderungen ist positiv und die wenigen schlechten Änderungen sind selten sinnentstellend oder komplett falsch und richten keinen Schaden an.
Zwar sollte man in einem Wiki alles speichern können, doch die Vertraulichkeit kann hier Grenzen setzen. Man muss entscheiden welche sicherheitsrelevanten Informationsarten im Wiki sein dürfen (keine personenbezogene Daten, Passwörter, Finanzdaten, etc.). Natürlich lässt sich das Hinzufügen erlaubter und nicht erlaubter Inhalte nicht technisch filtern, sondern nur als Konvention regeln.
Für Wikis gelten die gleichen Anforderungen an die Informationssicherheit wie für andere Webanwendung. Wie bei Webmail, Customer-Relationship-Management Systemen oder Zeitabrechnungsanwendungen sind verschlüsselte Verbindungen (https) und zeitnahe Softwareupdates Stand der Technik.
Ob eine Organisationswiki ausschließlich in einem Extra- oder Intranet erreichbar ist, oder auch aus dem Internet, hängt von der Zielgruppe und Sensibilität der Inhalte ab. Bei rein internen Prozessen und Informationen ist eine interne Lösung einfacher. Sollen Organisationensexterne auch auf Benutzerhandbücher zugreifen können, kann man Wikis auch in einer geschützten Umgebung im extern zugänglichen Internet betreiben.
Ist das Wiki in einem Server Backupsystem eingebunden, so ist die Gefahr eines Datenverlusts bei Systemausfällen die gleiche wie bei anderen Anwendungen. Datenverlust durch Benutzer, durch Fehlbedienung oder irrtümliche Löschungen von Seiten oder Teilabschnitten sind durch die Versionierung, unabhängig vom Backup, wieder herstellbar.
Ein besonders zu berücksichtigender Fall ist der Ausfall der Wikis selbst oder dessen Hostsysteme. Systeminformationen, Angaben zur Wiederherstellung des Wikis können zwar im Wiki selbst gesammelt werden, sollten aber in einem einfachen System redundant vorgehalten werden (lokale Kopie als Text ohne Datenbank oder ein Ausdruck).
Wikis sind zwar in erster Linie keine Fragen der Technik, sondern der Organisationskultur, dennoch ist eine Auswahl der Software ein wichtiger Schritt in der Einführung, der viele Weichen stellt.
Es gibt unterschiedliche Wikisoftware, viele sind open source (dazu auch Open Source im Unternehmen).
Wie bei jeder Softwareeinführung, sind bei der Auswahl einer Plattform für das Organisationswiki spezifische Anforderungen zu erfüllen.
Die Liste von Wiki-Software ist lang, auf wikimatrix.org gibt es eine große Vergleichsauswahl sehr vieler Wikiserversoftware. Hier will ich mich auf die häufigst verwendeten und speziell für den organisatorischen Einsatz konzipierte Software beschränken.
MediaWiki ist eine der bekanntesten Software für Wikis, da diese für das Projekt Wikipedia geschrieben wurde und dort eingesetzt wird. Der Anwendungsfokus liegt auf der Verwaltung von unterschiedlichsten und vielen Inhalten. Die Ordnungsstruktur ist wenig hierarchisch, dafür aber sprachlich-semantisch. Es gibt zahlreiche Erweiterungen, eine API und eine aktive Entwicklercommunity, so dass Anpassungen einfach erfüllt werden können.
MediaWiki selbst ist freie Software und hat durch die Wikimedia Foundation eine ständige, professionelle Weiterentwicklung. Allerdings wird MediaWiki primär für Anforderungen der Wikipedia und einer offenen Community entwickelt.
Die Business-Version BlueSpice for MediaWiki ist eine speziell an die Anforderungen von Geschäftskunden angepasste Distribution. BlueSpice hat u.a. eine leistungsfähigere Suche und einen auf Mediawiki abgestimmten WYSIWIG-Editor.
In der Standardinstallation gibt es keinen WYSIWYG editor, der inzwischen leistungsfähige auf nodeJS basierende VisualEditor kann aber nach installiert werden (Alternativen).
Kann oder soll kein WYSIWYG genutzt werden sollte den Nutzern zumindest eine erweiterte Toolbar bei der Eingabe der Syntax helfen. Empfehlenswert ist der WikiEditor, der neben einer bequemen Formatierung eine Autovervollständigung für links ermöglicht.
Der Fokus liegt auf einer hohen Nutzerorientierung im Bereich Nachprüfung. Es gibt eine Beobachtungsliste für die präzise Überwachung eines definierten persönlichen Bereichs, und wie in fast jeden Wiki die "letzten Änderungen" für die komplette Übersicht. Diesen beiden Listen verlinken direkt auf die Darstellung der Versionsunterschiede, welche eine effektive, ständige und umfassende Kenntnisnahme der Veränderungen ermöglicht.
Auch können Inhalte mit der API umfangreich exportiert werden. So kann mit der API-Funktion ?action=render fertiger html ausgezeichneter Inhalt in anderer Software übernommen werden.
Eine sehr rudimentäre Zugriffsbeschränkung ist einer der größten Nachteile von MediaWiki. So ist die standardmäßige Rollenverwaltung auf seitenselektive Schreibsperrung und lediglich drei hierarchische Gruppen (Anonyme, Benutzer, Administratoren) konzipiert.
Gitlab ist ein Webanwendung zur Versionsverwaltung für Softwareprojekte. Neben der Verwaltung von Software Repositories bietet GitLab zahlreiche andere Funktionen wie auch ein Wiki.
GitLab nutzt das inzwischen weit verbreiteten Markdown mit zahlreichen Zusatzfeatures wie Emojis, mathematischen Symbolen, ToDo-Listen und Diagrammen und flowcharts.
GitLab ist schneller als andere Enterprise-Wikisoftware.
Neben Wikis bietet GitLab auch Projektmanagement-software und Issue-Tracking-System, was eine gegenseitige Integration wesentlich erleichtert.
GitLab ermöglicht ein präzises Rollen- und Rechtekonzept (mit Freigabe-Workflow) und ein einfaches Monitoring von Änderungen.
GitLab speichert die Inhalte in einem git-Repository und kann daher auch dezentral als git-versioniert Textdateien bearbeitet werden. Vor allem technisch affinere User (Entwickler, DevOps) können hier mit ihren Standardwerkzeugen arbeiten.
Leider gibt es keine automatischen Kategorien, sondern man muss mit Übersichtsseiten arbeiten.
Auch sind keine Hinweiskästen oder anderer Textbausteine möglich.
Es gibt keinen WYSIWYG-Editor und Seiten können nur als ganzes, nicht in einzelnen Abschnitten bearbeitet werden.
GitLab ist als Open Source Software frei verfügbar und installierbar.
Es wird aber auch kommerzieller technischer Support angeboten.
Projekte, inklusive Wikis, können auch auf gitlab.com privat und kostenfrei genutzt werden.
Confluence ist eine proprietäre Software und sehr weit im Unternehmenseinsatz verbreitet. Die Stärken liegen im WYSIWYG, einer ausgeprägten Rechte- und Rollen-Verwaltung und einer guten Suche.
Vor allem für Büroanwender hat Confluence ein ausführliche Benutzeroberfläche, die alle Bearbeitungen mit Dialogen direkt unterstützt. Zusätzlich gibt es zum flüssigen Schreiben shortcodes und Autovervollständigung für Links im Text.
Confluence ist in mehrere Bereiche, sogenannte Spaces, aufgeteilt, die einzeln als Mandant unabhängig konfigurierbar sind. Artikel werden meist hierarchisch einsortiert. Weiterleitungen[1] und Transklusionen lassen sich per Plugin installieren.
DokuWiki ist zwar eine sehr schlanke Software, die, zur Freude vieler Systemadministratoren, keine Datenbank verwendet. Das ist allerdings auch der größte Nachteil, da so viele Funktionen im Monitoring und der Usability fehlen.
Es gibt zwar eine ausführliche Versionsverwaltung, welche aber nicht vollständig erhalten bleibt. Überwacht werden kann DokuWiki über eine Recent-Changes-Liste und der Einschränkung dieser auf einen Namensraum. Auch Benachrichtigung mit Emails ist möglich. Leider gibt es keine persönliche Beobachtungsliste, was aber evtl. durch eine externe RSS-Funktion abgedeckt werden kann.
Dokuwiki nutzt eine eigene Syntax, die sehr auf Visualisierung der Struktur durch Steuerzeichen optimiert ist. So wird eine Überschrift der zweiten Ebene nicht, wie z. B. in Mediawiki, mit zwei (== Überschrift ==) sondern mit fünf Gleichzeichen (===== Überschrift =====) ausgezeichnet, die dritte Ebene mit vier, die vierte Ebene mit drei usw. So wirkt die eine "höhere" Überschrift im Schriftbild der Textbox mächtiger. Listen-Punkte werden auch mit einem * geschrieben, müssen aber mit zwei Leerzeichen eingerückt werden, so spiegeln sie die gängige Einrückung von Listen in der Darstellung wider. Mit der integrierten Toolbar ist es einfach, diese Formate zu vergeben, allerdings sind Texte so wesentlich schwieriger zu schreiben, da wesentlich mehr getippt werden muss und es mehr Fehlerquellen gibt.
TWiki, wie dessen aktueller Fork Foswiki, ist eine zu großen Teilen in Perl entwickelte Wiki-Software, deren Haupteinsatzgebiet Intranetplattformen in Unternehmen sind. WYSIWYG, Rechte und Rollen sind standardmäßig installiert und gut implementiert. Ein wichtiges Feature ist die einfache Programmierung von formularbasierten Anwendungen.
Redmine ist ein webbasiertes Projektmanagement-Tool auf der Basis von Ruby on Rails. Für jedes Projekt kann ein eigener Wikibereich angelegt werden. Projekte sind dank Mandantenfähigkeit abgegrenzte Arbeitsbereiche die für Nutzer getrennt gehalten werden können. So vergibt jedes Projektwiki alle Seitentitel neu und sie sind untereinander nicht direkt verlinkbar.
Der ChangeLog, die Änderungsübersicht, funktioniert global. So können Nutzer Änderungen, sofern die Berechtigung vorliegt, Redmine weit einsehen.
Wer Redmine schon nutzt oder ein Projektmanagement-Tool einführen will, kann dieses Wiki durchaus als Projektwiki verwenden. Organisationsweite Prozessbeschreibungen und Wissensdatenbanken sind leider nur umständlich möglich.
Auch fehlen wichtige Funktionen wie Kategorien, Transklusionen, Add-ons und eine Programmier-Schnittstelle.
Das Wiki Tiki ist neben der normalen Wikifunktion sehr mächtig durch Artikel, Blog, Workflow etc. erweiterbar.
Gerade im Bereich der Gruppen- und Rollenmodelle ermöglicht Tiki eine komplexe Zugriffs- und Änderungsrechtemodell. Welches aber bei Ausschöpfung der mannigfaltigen Möglichkeiten schnell unübersichtlich werden kann.
SharePoint ist ein Kollobarationsplattform und Dokumentenmanagementsystem von Microsoft das auch eine Wikifunktion besitzt. Diese besitzt aber nur wenige Grundfunktionen und fokussiert sich nicht auf wikispezifische Anwendungen.[2]
Teamemo ist eine moderne Wiki-Software mit einem WYSIWYG-Editor in dem mehrere Personen gleichzeitig an einem Beitrag schreiben können. Derzeit wird die Software nur als Online Dienst angeboten und kann nicht auf dem eigenen Server installiert werden.
Beiträge werden nicht in Namespaces sondern in einer Baumstruktur organisiert, ähnlich zu einem Dateisystem.
Neben dem faktischen Vergleich gibt es unterschiedliche Präferenzen und Gesamtausrichtung von Wiki-Software.
Im Einsatz bei Firmen über 10 Mitarbeiter gibt es zwei große Strömungen für Enterprise Wikis.
Auf der einen Seite ist das MediaWiki und auf der anderen Confluence. Beide werden im größeren Maßstab im Organisationsumfeld eingesetzt und genutzt.
MediaWiki ist durch Wikipedia die bekannteste Software, auch bei Internet-Nutzern. MediaWiki fordert und erlaubt große Freiheiten für die Inhaltserstellung, hat aber umfangreiche Kontrollmöglichkeiten. Die Businesserweiterung BlueSpice richtet sich vor allem an die Anforderungen von Geschäftskunden.
Confluence wird als, kostenpflichtiges Enterprise Wiki von der Softwarefirma Atlassian entwickelt. Confluence führt den Nutzer in einer strengen Struktur und bietet ihm zahlreiche Hilfsmittel (WYSIWIG, Seitentemplates, Auswahldialoge, etc). Von der Struktur ähnlich, aber Open Source, ist FOSWiki.
Beide Strömungen unterscheiden sich in:
Ordnung
Confluence und FOSWiki bieten eine übergeordnete Ordnungsstruktur mit Spaces um jeder Abteilung oder Projekt einen eigenen Bereich in einer Verzeichnisstruktur zur Verfügung zu stellen. MediaWiki bietet auch Namensräume, diese sind aber weniger flexibel und sollen wenige übergeordnete Hierarchien abbilden.
In der Wikikultur soll Wissen aber gerade nicht in Bereiche eingegrenzt werden, sondern organisationsweit genutzt und verbessert werden können. MediaWiki konzentriert sich auf phonetische links und eine sprachliche Semantik.
Zugang
Confluence und FOSwiki erlauben eine granulierte Zugangsstruktur entsprechend dem Organigramm eines kommerziellen Unternehmens. MediaWiki erlaubt weniger granulierte Rollen und Rechte. Das Wikiprinzip basiert vor allem auf einer grundlegenden Offenheit und verlangt gerade interdisziplinäre Zusammenarbeit. Zugangseinschränkungen zu Software dienen vor allem der Qualitätskontrolle. Wikis nutzen eine andere, vor allem kollaborative Form der Kontrolle, um so mehr Offenheit zu ermöglichen.
Kontrolle
die mangelnde Zugangsstruktur von Mediawiki gleicht dieses durch eine umfassende Möglichkeit Änderungen mit zu verfolgen aus. Neben der persönlichen Beobachtungsliste gibt es ein Gesamtübersicht der "letzten Änderungen". Und eine präzise Darstellung der Versionsunterschiede, um viele kleine und umfangreiche Änderungen schnell, aber auch umfassend, überblicken zu können. Confluence ermöglicht ebenfalls eine Gesamtübersicht und eine persönliche Liste, hat aber weniger Möglichkeiten als Mediawiki.
WYSIWIG
Confluence setzt ganz auf den internen WYSIWIG Editor und speichert Inhalte eine einem eigenen proprietären XML-Format. Dieser funktioniert sehr gut, aber Confluence verwehrt damit generell den Nutzen einer light wight markup language im kollobarativen Schreiben.
MediaWiki selbst bietet nur zusätzlich WYSIWIG-Editoren als Plugins an. Bluespice bietet, neben anderen Enterprisefeatures, einen sehr tauglichen WYSIWIG an, der aber reinen Wikisyntax speichert, so sind Änderungskontrollen und Wartungsaufgaben einfacher.
Zusammenfassend kann man sagen: Confluence ist mehr Enterprise und Mediawiki ist mehr Wiki.
Es kommt auf die Organisation drauf an wie wikifähig sie ist. Braucht die Nutzerschaft eine enge vorgegebene Ordnungen und wird nie mit Syntax arbeiten wollen, so kommt man mit Confluence oder FOSWiki besser voran.
Sind die Nutzer offener, können Inhalte über Sprache und Semantik ordnen und generell netzaffiner, so kann MediaWiki mehr von seiner Internetdynamik entfalten.
Vor allem für IT-Betriebe oder Softwareprojekte ist GitLab Wiki zu empfehlen. Lediglich der fehlende WYSIWIG Editor spricht gegen eine generelle Empfehlung, auch für allgemeine Organisationen.
Es empfiehlt sich sich Wikis im Rahmen der Einführung zu pilotieren oder zumindest Demoinstallationen auf die eigenen Bedürfnisse prüfen.
In der generellen Auswahl sollte man mindestens MediaWiki und Confluence oder FOSWIki einbeziehen, um beide Seiten des Spektrums zu betrachten.
Liegt man mit seinen Wünschen in der Mitte, so empfiehlt sich Bluespice. Man hat ein dediziertes Enterprise Wiki, aber ein MediaWiki unter der Haube. Bluespice hat den Vorteil das es als Erweiterung alle MediaWiki Funktionen beinhaltet und jederzeit, ohne Datenverlust, zu einem MediaWiki zurück gestuft werden kann; oder aufgerüstet, je nach Sichtweise.
Wikis und auch deren Nutzer, benötigen Betreuung und inhaltliche Pflege. Jede neue Software, Arbeitsweise oder Neuerung benötigt Hilfestellung für die Nutzer. Wenn Wikis scheitern, dann daran, dass sich niemand verantwortlich fühlt die gesamte Struktur im Auge zu behalten, aber auch daran dass Nutzer nicht mit einem Wiki arbeiten können. Es bedarf einer fachlichen Anleitung um ein Organisationswiki erfolgreich zu betreiben.
Die Ordnung eines Wikis ist nicht durch das Softwaredesign vorgegeben. Kein Nutzer wird gezwungen seine Information zu strukturieren, sondern kann Inhalte ohne hohe Hürden einfach beitragen. Struktur und Ordnung muss, am besten vom Nutzer selbst, eingebracht werden. Leider machen das die wenigsten.
Wiki-Gardening beschreibt eine Rolle die Inhalte überprüft, nacharbeitet, aber vor allem Mitarbeiter motiviert und schult.[1]
Die Aufgabe der Wikigärtner ist es nicht für die Nutzer Struktur zu schaffen und aufzuräumen, aber mit ihnen.
Bei allen Richtlinien, Wünschen und Commitments der Nutzer, ein Wiki besteht nicht aus vielen einzelnen kleinen Inhaltsstücken sondern, muss immer zu einem Gesamtkontext konsolidiert werden. Es wäre ein Ideal wenn jeder Nutzer, jeden Beitrag immer in hoher Qualität einreicht und auf eine stringente Ordnung achtet. Gerade aber weil es wichtig ist Nutzer zu motivieren niederschwellig beizutragen, wird eine gewisse Unordnung nicht ausbleiben. Deshalb sind es die Aufgaben des Wikigardenings:
Inhalte auf sprachliche Allgemeinverständlichkeit und logische Vollständigkeit prüfen.
Semantische Verweise mit Links und beschreibenden Hinweisen zu relevanten anderen Artikeln anlegen. Wikiartikel dürfen keine Linklisten sein, sondern brauchen immer einen Text der Verbindungen zu anderen Inhalten in die richtige Relation setzt.
Inhalte kategorisieren und Kategorien verwalten
Inhalte aus anderen Kommunikationsformen (z.B. aus Mails oder Kommentaren) ein zu arbeiten
veraltete Inhalte erneuern, markieren oder löschen
Die Wikigärtner sollen aber nicht nur aufräumen, sondern auch Ansprechpartner für die Nutzer sein und Hilfestellung, zum selbstständigen Arbeiten, anbietet.
Dabei kann der Wikigärtner auch als persönliche Auskunft oder Hotline fungieren. Einerseits um Nutzer konkret schneller ans Ziel zu führen und andererseits fehlende Struktur zu erkennen und zu verbessern.
Inhaltliche Verbesserungen müssen aber immer Anreiz zur Verbesserung der Fähigkeiten der Nutzer sein. Ein Wikigärtner der nur "hinterherräumt" hat keinen langfristigen Effekt auf die Nutzerschaft und die Gruppendynamik bleibt aus.
Werden einzelne Änderungen herausgegriffen und dem entsprechenden Nutzer seine Verbesserungsmöglichkeiten aufgezeigt, kann jeder Teilnehmer am konkreten Beispiel die Nutzung eines Wikis lernen. Mittelfristig sollen Nutzer selbstständig gutes Wissen erstellen können.
Diese Aufgabe fordert von den Wikigärtnern das pädagogische Gespür Nutzer nicht mit Fehlern zu konfrontieren, sondern vor allem mit Verbesserungen seiner Beiträge zu motivieren. Anderseits aber auch die Seniorität und die Autorität von Mitarbeitern aktive Mitarbeit einfordern zu dürfen.
Beispiel: Oft werden Erkenntnisse, Prozessänderungen oder Neuerungen per E-Mail an die relevante Gruppe versendet. Ein Wikigärtner sollte nun überprüfen ob die Information schon, in der geforderten Qualität, im Wiki steht. Fehlt die Information, so soll ein Wikigärtner diese einfügen, dann aber den Sender, auch per E-Mail, auf den neuen Wikieintrag oder Ergänzung hinweisen. Und darauf hin arbeiten das zukünftige Informationen, vom Sender der Email, direkt in das Wiki eingetragen werden.
Je nach dem wie aktiv oder passiv der Wikigärtner sein soll braucht dieser Qualifikationen, Fähigkeiten und Befugnisse.
Geht es nur um das richtige verlinken, kategorisieren und formatieren, so kann diese Aufgabe auch ein Werkstudent oder andere Hilfskraft erfüllen. Sollen auch persönlich, subjektiv geschriebene und meist knappe Notizen zu allgemein verständlichen Handlungsanweisungen und Erklärungen aufbereitet werden, müssen die Wikigärtner fachlich versiert sein und vor allem Schreibkompetenz für dokumentarische Text haben. Um anderen, weniger erfahrenen, Nutzern im Wikiprozess zu helfen, werden auch Kompetenz, Verständnis und technische Erfahrung mit Wikis erwartet.
Sollen die Wikigärtner zusätzlich noch inhaltliche Differenzen oder Kompetenzgerangel lösen, so ist das eigentlich keine wikispezifische Aufgabe mehr, sondern ein Führungsaufgabe; mit entsprechenden ausgestatteten Kompetenzen in Moderation und Kompromissfindung. Die vielleicht aller schwierigste Aufgabe ist es Mitarbeiter, die Informationen und Wissen nicht beitragen können oder wollen, zu motivieren und Ängste zu nehmen am gemeinsamen Wissen zu arbeiten.
Der Job der Wikigärtner ist weniger technisches Lektorat als eine Kommunikationsmoderation. Vielleicht genügt es einen Praktikanten über Textwüsten zu schicken um Links und Überschriften zu setzen. Für verständliche und fachlich richtige Texte und vor allem eine gemeinsame Kultur des Wissensaustausch müssen Wikigärtner wiki-kompetent sein und organisatorische Kompetenz besitzen.
Die Gärtner sehen das Wiki als Gesamtwerk und kümmern sich weit über ihren persönlichen Fachbereich hinaus um Semantik und Format, aber auch um die Community. Die Hauptaufgaben sind:
Ordnung und vor allem Kontext zwischen den Gruppierungen (z.B. Abteilungen) zu schaffen. Das vor allem durch Verlinkung, Begriffsklärungen und allgemeinverständlichen Schreibstil.
Neben dem Verständnis für die strukturellen und kulturellen Eigenschaften brauchen die Nutzer eines Organisationswikis auch praktische Fähigkeiten zur Nutzung. Wikis haben oft weitreichende Funktionen für Nutzerrechte, Massenbearbeitungen oder Berichterstellung. Das sind Fähigkeiten die nicht jeder Nutzer haben muss, sondern nur Administrationen oder Gärtnern geläufig sein muss. Dennoch gibt es Grundfunktionen die jeder Nutzer können muss, um ein Wiki mit Mehrwert und frustfrei nutzen zu können:
Da Wikis keine generelle Struktur, sondern mehrere ergänzende Strukturen gleichzeitig haben, ist es wichtig, dass der Nutzer Informationen auch dann findet, wenn er nicht weiß, wo diese genau sind.
Von primären Suchergebnissen aus, anhand von semantischer Verlinkungen, andere Information finden. Den es ist nicht sichergestellt dass man die gewünschte Information auf den ersten Klick oder mit der einfachsten Suchanfrage findet.
Nutzung von Kategorien und Listen.
Hilfemöglichkeiten durch erfahrene Nutzer (Gärtner).
Wie man fehlende eigene Zugangspfad mit Links und Erklärungen hinzufügt, und warum man das tun sollte.
Ein einfacher User wird in einem Wiki hauptsächlich lesen, soll aber auch Inhalte beitragen. Es fühlt sich aber oft ungewöhnlich an "ungefragt" in Texten anderer Personen zu schreiben. Nutzern soll klar sein das es wichtig ist Inhalte Anderer zu verändern und dass dies auch erlaubt ist. Der Nutzer soll dazu gewisse handwerkliche Grundfertigkeiten kennen:
Auch wenn ein WYSIWYG-Editor angeboten wird, ist ein Grundverständnis des Markups wichtig, um Änderungen bewerten zu können oder Formatfehler beheben zu können. Die wichtigsten Tags sind:
Überschriften
Kategorien
Format (Fettschrift, Kursiv, Listen)
Links automatisch auswählenLinks werden in herkömmlichen Dokumenten, wie Word oder E-Mails, selten verwendet. In Wikis sind Links der wichtigste Teil der semantischen Ordnung. Daher müssen Nutzer nicht nur Texte einbringen, sondern diese über interne und externe Links in ein Verhältnis zueinander setzen. Vor allem interne Links lassen sich schnell mit eine Dialog auswählen und gleich im Schreibfluss setzen. Diese Funktion gibt es in WYSIWYG- sowie bei Syntax-Editoren (Toolbar).
Nutzer müssen neue Seiten und Weiterleitungen, auch unter Hilfe von Vorlagen, erstellen können.
Weiter sind folgende inhaltliche Fähigkeiten wichtig:
Um Duplikate zu vermeiden muss vor jedem neu zu erstellenden Artikel genau nach bereits bestehenden, auch ähnlichen, Inhalten gesucht werden.
Sollen neue Inhalte eine eigene Seite erhalten oder können diese in einen bestehenden Artikel eingearbeitet werden.
Welches fachliche Niveau wird vom Adressat erwartet.
In welchen Stil Artikel geschrieben werden können.
Viele Unternehmen setzen Wikis als Enterprise Wikis bereits ein. Ein durchschlagender Erfolg ist nicht garantiert, aber viele Firmen können bestätigen, dass es sich lohnt, kleinere Hürden zu überwinden um die großen Vorteile eines Organisationswikis zu nutzen.
Die Synaxon AG ist ein mit über 2.800 selbstständigen Partnern und einem Außenumsatz von rund 3 Milliarden Euro die größte IT-Verbundgruppe Europas. Im Synaxon Firmenwiki sind rund 5200 Seiten versammelt - von den Verträgen mit Kooperationspartnern und Lieferanten [..] bis zu den Spielregeln bei Synaxon. Der Vorstandssprecher schwärmt von einer "Kulturrevolution". [..] Neben dem Wiki für Synaxon gibt es eines für den engeren Kreis der Franchise-Nehmer und eines für den weiteren Kreis der Partner-Firmen. Auch bewiesen hier Wikis wesentlich höhere Einfachheit, denn die Einführung mehr oder minder komplizierter Wissensmanagement-Software mit je nach Hierarchie-Ebene unterschiedlichen Zugriffsrechten... funktionierte nicht. Widerstände gab es in der Firma trotzdem..., aber auch die Erkenntnis, dass Wikis keine Wundermittel sind. (Aus Die gläserne Firma)
Seit Mitte 2007 betreibt die Fraport AG ein internes Wiki für das Wissensmanagement des Unternehmens. Das „Skywiki“... aus Im Wiki haben Besserwisser keine Chance und Eine Partizipation der Mitarbeiter setzt häufig einen echten Wechsel in der Unternehmenskultur voraus.
Die Bluepedia ist ein Wiki des internationalen Konzerns IBM und wurde von deren Chefstrategen Gunter Dueck maßgeblich angetrieben, mit über 6.100 Artikeln und 1.600 Autoren (Stand Dez 2010; englische Bluepedia).[1]
Die Volkswagen AG setzt eine Reihe von Wikis im Konzern ein. Das Konzernwiki (OpenWiki) umfasst cirka 3.600 Artikel und 39.000 Seitenbearbeitungen mit ungefähr 20.000 Nutzern. Das Projektmanagementwiki der Visualisierung und Konzeptentwicklung kommt bei ca. 1.000 Artikeln auf 35.000 Seitenbearbeitungen von 40 Nutzern (350 Änderungen pro Jahr und User, zum Vergleich Wikipedia.de kommt auf cirka 10 Änderungen pro Jahr und Nutzer). Das Aktivitätsniveau unterstreicht also die These, dass bei gut moderierten Firmenwikis die Beteiligungsquote deutlich über der 90-9-1 Regel liegt. Eine besonders aussagekräftige Kennzahl für die Aktivität auf einem Wiki ist die Quote zwischen Aufrufen und Bearbeitungen der Artikel. Diese liegt bei dümpeltenden Unternehmenswikis bei ca. 20:1 bei sehr aktiven Wikis unter 5:1.
Auch eine Stadt ist eine Gruppe von Menschen, die alle in einer örtlichen Beziehung leben. Und die können sich über ein Stadtwiki organisieren ka.stadtwiki.net
Im Intranet der Wertachkliniken Bobingen lief von 03/2006 bis 12/2007 ein Krankenhaus Wiki für alle
nicht-patientenbezogenen medizinischen und organisatorischen Themen. Die Zahl der Beiträge lag zum Schluss bei etwa 3000. Das System war sehr stabil und außerordentlich praktisch. Mit dem Ausscheiden des Hauptverantwortlichen wurde es leider abgeschaltet. Infos unter Benutzer:Rho
Die Intellipedia shovel, ein Stück Usermotivation.
Die Intellipedia ist ein auf Basis des Wiki-Prinzips entwickeltes Informationsnetzwerk der Geheimdienste der USA, die in der United States Intelligence Community zusammengefasst sind.
Auch in Schulen und anderen Bildungseinrichtungen helfen Wikis in organisatorischen Fragen. Zusätzlich können Wikis in die pädagogische Arbeit einbezogen werden, wenn Schüler oder Studierende Inhalte mit gestalten.
.svg)
.png)
