Heute haben wir den Abschluss unseres internen Wiki-Projekts gefeiert. Damit rumgeturnt haben wir seit Juli 2007, Idee und Konzept entstanden kurz davor. Hier die wichtigsten Learnings und eine Einladung zum Weblog-Wiki-Seminar an der Orbit-iEX 2008.
Es war (auch) eine Zangengeburt. Aber wir sind zufrieden. Das Bernet Wiki enthält jetzt alle Prozessdefinitionen, Anleitungen für Programme, wichtiges Wissen für unser Projektmanagement. Was früher in verschiedenen Word-, PDF- oder Grafikdateien lag, sitzt auf der gemeinsam gefütterten Datenbank. Seit Ende Oktober 07 waren etwa 80 Prozent der Daten im Wiki drin, die letzten zwanzig Prozent und ein lange anhaltender Kampf mit Eingabe und Darstellung von Tabellen haben uns aufgehalten.
Was wir besser machen würden:
- Eine Wiki-Software auswählen, die alles kann. Okay, vielleicht kann keine alles. Wir haben mit liip.ch die Open Source-Software dokuwiki um ein benutzerfreundliches Interface ergänzt. Dieser Prozess war sehr aufwändig. Und einiges, das wir gerne hätten, geht nicht. In der Zwischenzeit habe ich andere Wiki-Lösungen gesehen, wo ich gestaunt hatte, was an Funktionalitäten gleich schon alles mitkommt. Es wäre schön, wenns mal so was wie WordPress für Wikis gibt – aber vielleicht gibts das schon.
- Einen Programmierpartner auswählen, der schnell verfügbar ist und schon fertige Wikis für KMUs gemacht hat.
- Das Projekt schneller abschliessen. Am Ende haben wir zu lange rumgeturnt – weil alle Beteiligten einfach zu wenig Zeit hatten, um mit Druck den Finish zu machen. Das ganze war ja auch ein internes Projekt, Kundenaufgaben gingen immer vor. Und so waren wir immer mal etwas mehr, mal etwas weniger dran.
- Die Einbettung von Dokumenten auf unserem Server müsste irgendwie besser möglich sein. Grafiken pflegen wir zum Beispiel weiterhin besser auf dem Grafikprogramm – hier wäre ein Direktlink aus dem Wiki auf den Server genial. Heute posten wir halt die Grafik im Wiki, nach jeder Änderung.
Was wir geniessen:
- Wie schnell es geht, einen Eintrag im Wiki zu machen. So schnell, dass man ein Learning oder einen Prozess sofort abbilden oder aktualisieren kann.
- Wie schnell die Infos gefunden werden. Auch wenn der Suchbaum nicht immer ein-eindeutig benamst ist – mit der Volltext-Suchfunktion landet man schnell am gesuchten Ort.
- Das abgespeckte, standardisierte, elektronische Format: Früher sahen die Manuals je nach Programm sehr unterschiedlich aus. Es war viel schwieriger, die Übersicht zu erhalten.
Was noch auf uns zukommt:
- Laufend aktuell bleiben: Nur wenn das ganze Autoren-Mitarbeitenden-Team „dran“ bleibt, bleiben die Infos wertvoll. Da werden wir unsere Erfahrungen machen.
- Die Struktur transparent halten: Jede/r kann eine neue Seite benamsen und einfügen, wo sie/er will. Der Suchbaum wächst einfach. Und zum Teil finde ich heute schon meine eigenen Einträge nur noch über die Suchmaschine. Da werden wir wohl zwischendurch ein wenig durchforsten müssen.
Wiki-Learnings von Unternehmen wie Die Post oder local.ch kann man am 23. Mai an der Orbit-iEX erfahren. Dort spreche ich mit Jürg Stuker von namics auch über den internen Einsatz von Weblogs. Hier die Seminardetails und so sehen Jürg und ich aus, wenn wir uns als Weblog-Wiki-Gurus verkaufen.
Sehr interessant. Wann wird das Bernet Wiki aufgeschaltet?
Grüsse aus Luzern, Fatima Vidal
@fatima – es ist schon aufgeschaltet – intern. habe ich wohl zu wenig klar gemacht, dass es eine interne wissensdatenbank ist.
Oh! Schade.
„benutzerfreundliches Interface“ – Was bedeutet das im Einzelnen? Ein eigenes Template (nicht nur für Design sondern auch für Funktion), jede Menge Plugins und … etwa gar ein WYSIWYG-Editor?
@frank: dokuwiki hatte keinen wysiwyg-editor. andere wikis scheinen das ja zu haben.
Das Fehlen eines WYSIWYG-Editors kann man meines Erachtens verschmerzen. Ein paar Gründe habe ich hier zusammengetragen:
http://www.frogpond.de/index.php/archive/simplicity-adoption-and-wysiwyg-editors/
DokuWiki hat ja eine eingängige Markup-Language, die den Verzicht auf WYSIWYG leicht macht. Dass andere Wikis einen solchen Editor mitbringen ist richtig (funktionieren die aber auch immer wie versprochen?) – auch für DokuWiki wird an einer Einbindung eines HTML Editors gearbeitet.
Andereseits kann ich ihre „Schmerzen“ bei der Bearbeitung von Tabellen sehr gut nachvollziehen, das ist eine Aufgabe die von WYSIWYG potenziell profitiert 😉
@martin: wo du völlig recht hast – zu viel wysiwig bringt nichts. ich liebe den wordpress-editor, so sollte jeder editor für webcontent sein. no frills. grad im wiki will ich wirklich nur netto-content.
Was haltet ihr von Confluence?
Wioe bringt man nicht computer-affinen Mitarbeitern in KMU´s das Wiki näher?
@Marcel bei den Plugins gibts inzwischen einen Editor (den ich aber noch nicht ausprobiert habe) von … liip.ch, wenn ich mich nicht irre 🙂
@Frank @Marcel Ja, stimmt, zumindest sagt das http://wiki.splitbrain.org/plugin:fckw
Ob dieser Versuch der Einbindung des FCKeditors damit zusammenhängt (http://dokuwiki.free.fr/dokuwiki/doku.php)?
@noman: da bei uns alle bloggen, sind wir schon ein wenig weiter im täglichen umgang mit ganz einfachen web-editoren. aber es braucht eine einstiegs- und lernzeit. blöd ist natürlich, wenn der web- und der blog- und der wiki-editor ganz anders funktionieren. da liegt noch ein wenig standardisierung vor uns, auf die ich mich freue.