Wikis in Organisationen: Einführung

Aus Wikibooks

Betrachtet man das die Einführung eines Wikis als Projekt und nicht nur als selbstverlaufenden Versuch kann man sich Meilensteine, Ziele und Erfolgsgrößen definieren.

Auch wenn ein Wiki kein Ende hat und nie fertig ist, da es immer mit der Organisation mit wächst, so gibt es trotzdem einen Anfang. Und hier entscheidet sich ob das wiki zu leben beginnt.

Eine Wiki darf, auch wenn es geht, nicht einfach mal so in 10 Minuten aufgesetzt werden. Keiner will einen Strukturplan für das fertige Wiki, das wäre konträr zum Wikisystem. Aber man muss sich gewisser Meilensteine bewusste sein.

Die wichtigste Frage ist ob ein Wiki in der betreffenden Organisation überhaupt funktionieren kann.

Inhaltsverzeichnis

1 Rolle des Projektleiters
2 Erste Anwendung
3 Software
- 3.1 Hosting
4 Legitimation
5 Argumentation
6 Schulungen
7 Support
8 Sicherheit
- 8.1 Technische Sicherheit
- 8.2 Organisatorische Sicherheit
9 Beratung
10 Quellen
11 Weblinks

[Bearbeiten] Rolle des Projektleiters

Um nun ein Wiki einzuführen muss man sich erst mal im klaren sein wer man selbst ist. Eigentlich hat niemand eine perfekte Position um eine Wiki zu etablieren:

Sind Sie der Chef: haben die Mitarbeiter wahrscheinlich einen gesundes Misstrauen gegenüber "moderner" Ideen von oben.
als Mitarbeiter: stehen Sie zwischen allen Stühlen.
als IT-Verantwortlicher: wird einem eine grundsätzliche Begeisterung für IT unterstellt, die wenigsten aber wollen sich davon anstecken lassen.
Als Berater: wird man eh immer scheel angesehen, und jemand der vom (Kern)Geschäft keine Ahnung hat, der kann sowas in unserem Falle sowieso nicht beurteilen. Der will dann anderen erzählen wie man was machen soll.

[Bearbeiten] Erste Anwendung

Wenn ein Wiki lebt, entscheidet die aktive Nutzergruppe, am besten die ganze Organisation, selbst, was in das Wiki gehört und was nicht. Für eine initiale Einführung empfiehlt es sich aber zu entscheiden, was als erstes im Wiki verwaltet werden soll. Diese Entscheidung kann aus bestehenden Problemen entstehen.

Erste eng umrissene Anwendung können sein:

Projekttagebuch
veraltete einkanalige Intranete
Mitarbeiterdaten
Tipps und Tricks

Ein Wiki soll auf keinen Fall andere sinnvolle Software ersetzen, diese Daten sollten teilweise dann aber in einem Wiki einbindbar sein (z.B. Adressdaten). Als Lösung sind hier serverseitige wie Datenbankausgaben und Felder oder clientseitig mit iframes, oder externer Medien.

[Bearbeiten] Software

Die Auswahl der Software ist wahrscheinlich der schwierigste Schritt einer erfolgrichen Einführung, da dieser am unflexibelsten ausgebessert werden kann. Daher muss eine Definition der Anforderungen voraus gehen. Es gibt unterschiedlichste Software mit jeweils anderen Schwerpunkten. Welche der definierten Anforderungen wichtiger zu erfüllen ist kommt auf Einsatzzweck, vor allem auf die Zielgruppe an. Ein persönliches Wiki braucht nicht unbedingt ein hochkomplexes Rollenkonzept, ein wiki das Organisationsfremde wie Kunden oder gar Interessenten zur Verfügung steht 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 schon 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 der Änderungen (persönliche und Gesamtliste, RSS, Diff-Darstellung).

Eine weiter Möglichkeit der Auswahl wäre in einer Testphase eine kleine Anzahl von favorisierten Softwares zu installieren und freiwillige Betauser in alle schreiben zu lassen, um dann mit neuen live-Erfahrungen auf ein einziges System zu migrieren. Der Aufwand ist gegenüber einer tragischen Startfehlentscheidung ist gering. Außerdem werden so die User in wirklich jede Entscheidung mit einbezogen. Eine Migration von Daten ist je nach Menge auch automatisiert per Bot (Artikel kopieren, synatx wechseln etc.) möglich. Allerdings wurde diese Variante von mir noch nie angewandt.

[Bearbeiten] Hosting

Man muss die Software nicht zwingend selbst im eigenen Netz oder der eigenen Infrastruktur hosten. Oft ist es sinnvoller das Wiki bei einem spezialisierten Anbieter oder einer Wikifarm zu hosten. Zwar scheint, bei eigener Infrastruktur, ein Eigenhosting eine kostengünstiger sichere Variante zu sein, aber sicherer Administration immer Geld, auch beim Firmenadministrator. Des weiteren gibt es auch Beratungsangebote die das Hosting in eigener Infrastruktur übernehmen.

Bei der Entscheidung über das Hosting sollte man sich ebenfalls Anforderungen stellen:

Software

bekomme ich die gewünschte Software

Zugriff

Benötige ich einen Zugriff außerhalb der Geschäftsräume (homeoffices, Partner, Kunden)

https Zugang
apache Zugangsregelung
reiner VPN Zugang

Backup: Wie oft (täglich, wöchentlich), wie (SQLdump, Kopie), wohin (intern, auf eigenes ftp) wird das Wiki gebackupt
Domain: kann man eine eigene Subdomain oder Domain verwenden (also intra.firma.net anstatt firmenintranet.wikihoster.net)
Sysstemaccess: Kann man auf Konfigurationsdateien zugreifen?
Extensions: Können allgmeine und eigene passende Softwareextensions installiert werden. Werden Extensions von einem Hostinganbieter evtl sogar unterstützt
Verfügbarkeit: Wie hoch ist die (vertragliche) Verfügbarkeit und Reaktiosnzeit (Loadbalancer etc)
Storage: Wie sicher ist die Datenbank, evtl. verschlüsselte Datenbanken
Einbindung fremder Inhalte: Können Interwikilinks leicht erstellt werden, können fremde Medienarchive (WikimediaCommons, Andere interen Server) eingebunden werden.

Wie auch immer das Hosting realisiert wird, Datenschutz ist eine der wichtigsten Kriterien.

Die kommerzielle Software Confluence wird größtenteils fremdgehostet. Es gibt aber noch weiter Anbieter die teilweise kostenloses Wikihosting betreiben aber auch Bezahlmodelle mit erweiterter Funktionalität anbieten.

wikidev.net
wikiserver.de
hallowiki.biz professioneller Unternehmenseinsatz
acc.de kostenlos und erweitert
wikia.com (Wikia) kostenlose aber offene Wiki
nexion.de 29 € pro Monat

[Bearbeiten] Legitimation

Das wichtigste sind jetzt 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.

Hierarchische Legitimation: Nicht wenige Wikis sind gescheitert weil ein Mitarbeiter ein Wiki aufgesetzt hat und dann quasi in Guerillataktik das System etabliert hat. Wenn sich dann ein Vorgesetzter übergangen fühlt, ist es schwierig für ein weiter organisatorische Akzeptanz zu werben. Ein Wiki bietet vereinzelt kurzfristigen Erfolg bei persönlichen "Aha"-Erlebnissen, der strategische Nutzen kommt aber erst mit der Zeit.

Umso größer die Organisation um so mehr muss das Wiki 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.^[1]

[Bearbeiten] Argumentation

Um mehr Menschen zu überzeugen im Wiki nachzuschauen und sich aktiv daran zu beteiligen müssen viele Ressentiment beantwortet werden. Die beste Variante ist es an konkreten Beispielen zu arbeiten

Sind Informationen im Umlauf die schlecht (z.B unaktuell, falsch, unvollständig) oder gar nicht (z.B. Flurfunk) dokumentiert sind, so ist das Wiki der erste Aufbewahrungsort. Müssen diese Informationen später erneut zusammengesucht werden kann das Wiki als schnelle Informationslösung punkten und das Mitglied lernt durch persönlichen Erfolg.

In der reinen Argumentation sind folgende Fakten hilfreich:

Aktualität
Universalität
Validität
Schnelligkeit
Reichweitenstark, da jeder einen Browser hat, nicht aber jeder SAP

Eventuelle Ängste aktiv im persönlichen Gespräch adressieren (nicht im selben Medium)^[1].

[Bearbeiten] Schulungen

Grundschulungen (ändern, neu erstellen) für alle Mitarbeiter, Multiplikatorschulungen für fähige Multiplikatoren (Beobachten, Kategorisieren).

[Bearbeiten] Support

Hat man mit all den oben genannten Schritten richtigen Erfolg läuft ein Wiki von selbst. Man kann jetzt noch weiter Ideen wie Erweiterungen anbringen oder als dritter die Arbeit der Organisation begutachten und Diskussionsgrundlagen zu Kategorisierung, Aufteilung etc stellen.

[Bearbeiten] Sicherheit

Oft gibt es Bedenken gegenüber Wikisoftware, da diese ja bekanntlich offen ist und jeder etwas verändern kann. Oft blocken Leute nur beim Gedanken an die Verwendung eines Wikis ab, da sie sofort die Vorstellung überkommt, dass jemand Organisationsfremdes aus dem Internet, nicht nur Organisationsinhalte einsehen, sondern auch diese noch verändern kann. Durch solche organisatorisch-konservative Urängste sind schon viele interessante Projekte gescheitert.

[Bearbeiten] Technische Sicherheit

Ein Wiki ist genauso eine Software wie ein Dateisystem. Ob die Daten um Wiki in unberechtigte Hände kommen, ist nicht von der Form des Wikis abhängig, sondern ausschließlich von der umgebenden IT-Struktur. Zwar sind die meisten Wikis in PHP geschrieben, welches in IT-Kreisen als anfällig gilt, in php sind aber auch die meisten anderen Content-Management-Systeme geschrieben. Ein unberechtigter Eingriff in das Wiki ist also nicht abhängig von seiner Eigenschaft als Wiki.

[Bearbeiten] Organisatorische Sicherheit

Wieder kommt das Argument das: "jeder seine ...darf". Das ist prinzipiell nicht richtig, jede Wikisoftware kann so eingestellt werden das es nur von einer Person editiert werden kann. Oder eben von mehreren Personengruppen (Abteilungsverantwortliche).

Ein Wiki zeigt aber seine Möglichkeiten erst, wenn dieses möglichst offen ist. Zwar können Organisationsmitglieder so eventuell elementare Kernprozesse oder Inhalte angreifen, diese Angriffe werden aber präzise verfolgt; und können so bei einem Fehler sehr schnell rückgängig gemacht werden.

Ein weitaus höherer Anteil der Veränderungen ist aber positiv, die wenigen schlechten Änderungen aber sind trotzdem schneller behandelt als auf gewöhnlichen Wege. Die Beantwortung einer eMail mit einem Verbesserungsvorschlag dauert sicher länger als ein Edit und dessen Revert.

Ob der Erfolg der Wikipedia auf der schmerzhaften Offenheit^[2] liegt ist nur philosophisch zu beantworten. Eine "normale" bereits gewachsene Organisation kann sich gern darauf einigen nur mit Identifizierten und eindeutigen Benutzern zu arbeiten. So ist jede Inhaltsänderung präzise nachvollziehbar, das ist sie bei anderen Werkzeugen wie Officeumgebungen nicht oder nur als Beiwerk (z. B. MS-Word Dokumente vergleichen). Ein Wiki lebt genau aus diesen Änderungen.