Corporate Wiki: easy to blame


Alex Schröder, Hauptentwickler hinter dem Wikisystem Oddmuse (das übrigens alle meine Sympathienpunkte bekommt, weil es a) Perl, b) klein, c) erweiterbar und d) der Programmcode einfach veränderbar ist) ist von WikiSym 2008 mit einigen Gedanken zu Corporate Wikis zurückgekehrt. Etwas überzogen, aber doch mit einem wahren Kern, stellt er sich Gespräche über Anforderungen an Wikisystemen für den Unternehmenseinsatz in etwa so vor:

bob
We need an interface to the product database.
fred
Hm, did you actually write about any product yet?
bob
Then we could have a form to describe products in a structured way.
fred
Yeah, but did you write a product description on the wiki?
bob
We could produce a PDF document containing our product catalog.
fred
Yeah, but have you actually started to write anything?
bob
But we need to ensure “security” using identity management and permissions.
fred
Does anybody ever write anything on the wiki!?

Es ist auch mein Anliegen, mit meinen Klienten zunächst einmal herauszuarbeiten, was mit einem Wiki erreicht werden soll und wie man diesen Kulturwandel schafft, dass Informationsverarbeitungsprozesse im Wiki abgebildet werden.

Weiterlesen im CommunityWiki: CorporateWiki.

Tim, vielen Dank für den

Tim, vielen Dank für den Link zu der der spannenden Diskussion (und der Abbildung). Das Beschriebene trifft auch manche meiner Erfahrungen in der immer wiederkehrenden Diskussion ob und wie ein WYSIWYG-Editor implementiert werden soll.

Manchmal könnte man da fast den Eindruck gewinnen dass der Wunsch nach vielfältigen Features und Funktionalitäten nicht mehr ist als der Versuch Zeit zu gewinnen. Oder ganz negativ formuliert: "der Wunsch nach xyz, zyx und zxy ist nur ein höflich formuliertes (und politisch absolut korrektes) Nein" ;)

In der Tat sind Anforderungs- und Aufgabenanalysen zentral in unserer Arbeit, das ist eine (aus meiner Sicht) nicht zu unterschätzende Leistung von uns Beratern. Wiki-Technologie erklären, empfehlen und implementieren sind dann folgende Schritte.

Moin Martin, CommunityWiki

Moin Martin,

CommunityWiki ist eine ganz spannende Plattform, da dort viele Wiki-Enthusiasten zusammenwirken. Eigentlich müsste man das mal in einem eigenen Posting aufdröseln... Ich freue mich, dass dir Diskussion dort gefällt :-)

Ich komme ja aus dem E-Learning, und da ist mir so ein Verhalten gar nicht fremd. Als es nämlich Ende der 90-er Jahre daran ging, E-Learning einzuführen, hatten die Menschen ähnliche Probleme wie mit der Wiki-Einführung. Es ist nämlich sehr schwer, »harte« Erfolgskriterien für Lern- und Kommunikationsprozesse zu definieren. Und darum war es schon in den 90-er Jahren bei der Einführung von E-Learning so, dass man meist die IT-Abteilungen ihre Forderungen hat aufstellen lassen. Das waren harte Erfolgskriterien, die zwar herzlich wenig mit den eigentlichen Lernprozessen zu tun hatten, aber dafür eben recht sicher in einer Matrix überprüfbar waren.

Von daher glaube ich, dass Forderungen nach den vielen Features und Funktionalitäten auch ein Zeichen der Unsicherheit von Organisationen sind, wie man dort mit dem ganzen Wiki-Einführungsprozess umgehen soll.

-Tim

Da ist viel dran, auch wenn

Da ist viel dran, auch wenn es interessanterweise gegen viele - eigentlich akzeptierte Regeln der Corporate IT - wie bspw. "Beachtet den TCO", "es sollte sich leicht ändern, pflegen und updaten lassen" usw. verstößt.

Ist aber nicht wirklich schlimm, der Markt der Enterprise Wikis (ach, der Wiki Engines überhaupt) bietet ja auch leichtgewichtige, adaptive (und oft auch leicht erweiterbare) Wikis - das sind gute Argumente gegen die Unsicherheit.

Bspw. beobachte ich oft eine Art Erstaunen dass eine empfohlene Wiki-Engine die Inhalte nicht proprietär und "eifersüchtig bewacht" ablegt, sondern einem Export und einer Migration auf eine andere Engine offensteht. Dadurch wird eine grundlegende Unsicherheit, nämlich welche Engine eigentlich gewählt werden soll, schon etwas entschärft.

Kommentar hinzufügen

Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Zeilen und Absätze werden automatisch erzeugt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
CAPTCHA
Mit dieser Frage wird getestet, ob Sie ein menschlicher Benutzer, um so automatisierten Spam vorbeugen zu können.
Bild-CAPTCHA
Tragen Sie die Zeichen aus dem Bild oben in das Feld ein.