Den Betrieb großtechnsicher Anlagen sichern heute Online-Handbücher auf MediaWiki-Basis.Foto: Philipp Hertzog, (Lizenz: CC)

Vom 28. - 29. September 2011 findet in Köln das IOM SUMMIT von Kongress Media statt. Der führende Fachkongress für Intranet, Dokumentenportale und Enterprise 2.0 wartet diesmal mit 17 Erfahrungsberichten und 4 Seminaren auf.

Mehr als 20 Referenten aus verschiedenen Unternehmen stellen ihre Projekte vor. Man erfährt aus erster Hand Hintergründe über Intranet-Governance von Airbus, Social Networking bei Bigpoint, Micro-Blogging bei der Deutschen Bank, Kollaborationsmanagement bei Celesio oder Wissensmanagement bei Bilfinger Berger.

Case: TenneT TSO

MediaWiki in der Praxis: Carsten Walsch zieht Bilanz

Nicht verpassen sollte man den Slot mit Carsten Walsch (TenneT TSO GmbH). Auch wenn der Vortragstitel leider etwas fad wirkt: "Unterstützung der Arbeit an lebendigen Dokumeten bei der Tennet TSO". Vorgeschlagen hatten wir eigentlich den Titel dieses Blogbeitrags: "Living Documents". Das trifft es!

Worum gehts? Als einer der vier Übertragungsnetzbetreiber in Deutschland betreibt TenneT TSO ein Höchstspannungsnetz mit einer Leitungslänge von 10.700 km und 115 Umspannwerken. Das Unternehmen betreibt Spitzen-Technik, bündelt Experten-Know-How und hat höchste Anforderungen an die Qualitätssicherung. Der effiziente

Netzbetrieb basiert auf hausinternen Standards und Regelungen für die Errichtung und den Betrieb der Netzanlagen. Diese Standards sind in verschiedenen Handbüchern dokumentiert, die Handbücher werden ständig weiterentwickelt.

Im Jahr 2010 stellte TenneT TSO seine Handbücher auf ein ausgebautes MediaWiki um und konnte so u.a. den redaktionellen Aufwand erheblich reduzieren. Carsten Walsch zieht auf dem IOM SUMMIT Bilanz. Doch man kann schon jetzt sagen, dass man professionelle Online-Handbücher auf MediaWiki-Basis weit mehr können und können müssen, als das MediaWiki, das man von der Wikipedia her kennt. Lassen Sie sich überraschen!

Q: U.S. Navy, Wikimedia Commons, Lizenz: CC

Plaudern wir ein wenig aus dem Web 2.0-Nähkästchen: Der Erfolg eines Projekts hängt nicht zuletzt vom "Pilot Team" ab, das, um im Bild zu bleiben, die Plattform "zum Fliegen" bringen soll.

Ein Wiki zum Beispiel. Geht man von einer typischen Wiki-Implementation innerhalb eines Unternehmens aus, so läuft diese in Phasen ab, d.h. die Unternehmensmitarbeiter werden zu bestimmten Projektabschnitten in Gruppen in das Wiki eingeführt, die man wie folgt benennen kann:

Innovators: Hierbei handelt es sich um die Projektinitiatoren, die mit der Untersuchung der Mitarbeiteranforderungen, mit der Auswahl der Software, mit der Beantragung und Freigabe des entsprechenden Budgets und der Projektplanung betraut sind. Abhängig von der Unternehmensgröße, der Reichweite des geplanten Wikis und der Methode des Projektmanagements sind fünf bis zehn Mitarbeiter mit den betriebswirtschaftlichen und organisatorischen Aufgaben des sogenannten Pre-Pilots für ca. ein halbes Jahr (mit unterschiedlicher Arbeitsbelastung) beschäftigt. Die „Haupt“-Verantwortlichen für den Betrieb des Wikis, also die Wissensmanager und ggfs. ihre Assistenten werden essentieller Teil des Pilot Teams.

Pilot Team: Ein repräsentativer Ausschnitt der künftigen Wiki-User, die kurz nach der Installation des Wikis seine Arbeit aufnimmt. Meistens dreht es sich um ein Team von 20 bis 30 Usern, also eine Gruppengröße, mit der man auch in voller Besetzung während eines Meetings oder einer Telefonkonferenz noch effektiv arbeiten kann. Selbst bei großen Unternehmen ist diese Anzahl valide, da der Umfang der Aufgaben einigermaßen gleich bleibt (s. u.)

Extended Pilot Team: Ist das Wiki funktional, inhaltlich und strukturell vorbereitet, kann die nächste Gruppe angeheuert werden. Das Extended Pilot Team testet das Wiki, das sich in einer Art Beta-Version befindet, anhand seiner größeren Useranzahl und bringt damit eventuell weitere Fehler der Software und Anforderungen des Unternehmens ans Tageslicht. Demnach sollte es sich um eine kritische Masse von ca. 50 bis 70 Nutzern drehen, die sehr informell vom Pilot Team an das Wiki herangeführt werden. Meistens handelt es sich um technikaffine, neugierige Kollegen, die indirekt bereits von der Wikieinführung erfahren haben und gerne einen kritischen Blick auf die neue Plattform werfen.

Post Kick-Off-Community: Wie der Name bereits andeutet, werden irgendwann mit einem gewissen Trommelwirbel, wie z. B. durch eine Einladung des CEOs, die Tore des Wikis für alle Mitarbeiter geöffnet. Das Pilot Team und das Extended Pilot Team sind jedoch eindeutig identifizierbar, da sie als „Vorreiter“ nach wie vor gerade in der ersten Zeit dieser Phase spezielle Aufgaben zu erfüllen haben. Mit der Zeit ändert sich die Zusammensetzung des Teams der Verantwortlichen jedoch: Mitglieder des ursprünglichen Pilot Teams scheiden aus und werden durch andere Community-Mitglieder ersetzt.

Nachzügler: Auch wenn die Einführung des Wikis noch so erfolgreich ist, eine von Anfang hundertprozentige Annahme des Wikis durch die Mitarbeiter wird aus verschiedensten Gründen nicht erreicht. Selbst wenn man die frisch eingestellten Mitarbeiter nicht mitrechnet, tröpfeln noch Monate nach der Einführung des Wikis immer wieder Neulinge in das System.

Die Vorgehensweise anhand eines Phasenmodells stellt unterschiedliche Anforderungen an die jeweiligen Gruppen. Doch besonders die Zusammensetzung und Organisation des Pilot Teams sollte wohl durchdacht sein, da davon ein gelungener Start des Wikis abhängt.

Aufgaben des Pilot Teams

Den Mitgliedern des Teams darf nicht verschwiegen werden, dass ihre Tätigkeit mit viel Arbeit und Engagement verbunden ist. Der Prefill eines Wikis kostet Zeit und Energie, was auch vom Arbeitgeber durch entsprechende Zugeständnissen anerkannt werden muss.
Ganz grob gesagt soll das Pilot Team möglichst viel an und mit der neuen Plattform arbeiten, denn nur wer selbst mit dem Wiki umgeht, kann auch abschätzen, wo die Potenziale und Schwierigkeiten des Projekts liegen, kann helfen die Software anzupassen und für sein Unternehmen nutzbar zu machen.

Konkret stehen folgende Aufgaben im Raum:

• Kontakt zwischen dem Wikiprojekt und dem eigenem Arbeitsbereich, wie z. B. der eigenen Abteilung
  • Inhalte zur Verfügung stellen
  • Anforderungen an die Usability formulieren
• Strukturierung des Contents
• Funktionales Testen des Systems
• Training und Support für andere User
• Marketing und PR im Kollegenkreis

Die Koordination des Pilot Teams sollte über wöchentliche Meetings erfolgen. Dabei hat es sich als sinnvoll erwiesen, dass sich jedes Mitglied ein bestimmtes Arbeitspensum zuteilt, das in der darauffolgenden Woche zu erfüllen ist.

Zusammensetzung des Teams und Profil des Pilot Users

Wie sieht die typische Zusammenstellung des Pilot Teams aus? Am besten setzt man auf eine in jeder Hinsicht, aber besonders in folgenden Punkten, heterogene Gruppe:

Technische Kompetenz: Vom Computerneuling bis hin zum Programmierer kann sich das gesamte Spektrum der Teammitglieder erstrecken, da alle Perspektiven für die optimale Anpassung des Systems an das Unternehmen und seine Mitarbeiter interessant sind. Schließlich ist die Gesamtheit der angestrebten Community ebenso verschieden.

Abteilungen: Da die einzelnen Pilot User jeweils ihren thematischen Arbeitsbereich repräsentieren, sollte auch möglichst viele, wenn nicht sogar alle Abteilungen im Team vertreten sein, damit nicht eine oder mehrere Sektionen des Unternehmens ausgegrenzt werden. Die fehlenden Abteilungen nachträglich zu integrieren ist immer mit höherem Aufwand verbunden.

Hierarchien: Die Mischung unterschiedlicher Hierarchiegrade bringt v. a. den Vorteil, dass von Anfang an auf allen Ebenen eine Akzeptanz für das Wiki geschaffen wird und die unterschiedlichen Autoritätsstufen im Wiki möglichst flach gehalten werden können.

Alter: Gerade inhaltlich tragen Mitarbeiter reiferen Dienstalters anders zum Unternehmenswissen bei als beispielsweise die Auszubildenden. Während Letztere in ihrem Lernprozess gerade prädestiniert dazu sind, Lücken im Firmenwissen aufzuspüren und dokumentieren, schleifen die Älteren eher über die gesammelten Informationen drüber und ergänzen die Angaben durch Details

Wirft man einen Blick auf die einzelnen Persönlichkeiten des Teams, so gibt es wünschenswerte Charakteristika, die (fast) nicht fehlen dürfen:

Toleranz bezüglich Team UND System: Das installierte Wiki in seiner Rohfassung ist leer, langweilig, meist noch fehlerbehaftet und wenig funktional. Demensprechend „leidensfähig“ sollte der Pilot User sein. Auch die Heterogenität des Teams selbst kann die Geduld und Toleranz des Einzelnen extrem strapazieren.

Kreativität: Das Wiki ist funktional und inhaltlich (fast) beliebig formbar. Diese Freiheit sollte in vernünftigem Maße genutzt werden um eine ansprechende Lösung für die gesamte Community zu basteln. Daher sind durchaus auch Querdenker erwünscht, die aus der technischen Einheitswikiinstanz eine lebende Individualsoftware machen

Mut: Das Engagement in einem Pilot Team wird von den Kollegen nicht immer wohlwollend aufgenommen. Unsicherheit und Unverständnis gegenüber der neuen Plattform führen häufig zu gehässigen Bemerkungen bis hin zu offenem Widerstand. Standfestigkeit ist hier gefragt!

Fleiß und Selbstdisziplin: Wie der obere Abschnitt schon deutlich machen sollte, darf nicht unterschätzt werden, wieviel Arbeit in einer Wiki-Implementation steckt. Vom eigenen Beschäftigung mit dem Systems über die Strukturierung der Inhalte bis hin zur Pflege einer ansehnlichen Community ist ein weiter Weg, der manchmal auch mit Rückschlägen gepflastert ist.

Idealismus: Oft heißt es, dass ein Wiki die Firmenkultur positiv verändert. Ganz so weit möchte ich gar nicht argumentieren. Es genügt daran zu glauben, dass das Wiki eigentlich keine bloße Software sondern ein Prinzip darstellt, das die Arbeitsweisen in einer Organisation stärker an die Bedürfnisse der Menschen anpassen kann. Diese Einsicht benötigt der Pilot User um den Prozess einer Wiki-Einführung von dem anderer Software-Projekte zu unterscheiden.

Fazit

Rein äußerlich scheint die Auswahl eines Pilot Teams keine aufwendige oder gar komplizierte Sache zu sein. Oft ist man dabei sogar auf die freiwillige Teilnahme der Mitarbeiter beschränkt und hat keinen direkten Einfluss auf die Zusammensetzung. Dennoch lohnt es sich, ein paar Gedanken in die Planung der Teamarbeit zu stecken, um eventuelle Fehlbesetzungen zu vermeiden.

Im Ergebnis kann Warta zeigen, dass "die Voraussetzungen für Kollaboration in den untersuchten MediaWikis besser  zu sein" scheinen. Die MediaWikis hatten mehr Ko-Autoren als die Confluence-Maschinen und in den MediaWikis werden die Artikel besser verlinkt.

Alexander Warta: Über den Einfluss der Wiki-Engine auf die Nutzung von Unternehmenswikis, in: Information Wissenschaft uind Praxis, 4/2009, 245ff.