«

»

Okt 29 2012

[DE] Buchkritik “Enterprise Wikis– Die erfolgreiche Einführung und Nutzung von Wikis im Unternehmen”

Tobias Wolter gehört zu der (langsam) wachsenden Schar deutschsprachiger SharePoint Blogger. Im Juni 2012 hat er eine Rezension des Buches Enterprise Wikis: Die erfolgreiche Einführung und Nutzung von Wikis in Unternehmen von Martin Seibert, Sebastian Preuss und Matthias Rauer geschrieben, die ich hier mit seiner Genehmigung veröffentlichen darf. Das Thema Wiki ist ja hier auf dieser Site immer noch eines der beliebtesten Topics.


// Originalartikel

Lieber Leser,

wer meinen alten Blog über die Motive in die Selbständigkeit gelesen hat, der weiß, dass mich das Thema “Wie halte ich Know-how in meinem Unternehmern, bzw. wie fördert man die Innovationskraft eines Teams”, sehr interessiert.

Derzeit entwickle ich einen Kurs sowie ein SharePoint Modul für die Erweiterung des SharePoint Enterprise-Wiki. Natürlich habe ich meine eignen Ideen und Vorstellungen wie Wikis eingesetzt werden sollten und welche Use-Cases sinnig sind. Ich höre mir jedoch gerne die Argumente der Technologie-Konkurrenz an. Der größte deutschsprachige SharePoint Gegner ist nach meiner Meinung Martin Seibert. Ich hatte vor Jahren mal ein Video gesehen und Ihn danach sofort als frustrierten Java Entwickler abgestempelt. Zum Glück habe ich keine weiteren Videos angeschaut, denn dann hätte ich mir das Buch bestimmt nicht gekauft.  Gut, dass ich diese Videos erst danach gefunden habe.

Die 250 Seiten sind einfach zu lesen und die Idee mit den Stereotypen (Ernst Entscheider, Norman Netzaffin, Marc Microsoft etc.), anhand derer ein beispielhafter Projektverlauf dargelegt wird, ist genial. Mir persönlich hat aber noch “Notes Kanndas und Java Forever” gefehlt. Die Tipps rund um Projektpsychologie, den Umgang mit Blockierern etc., sollten für SharePoint Consultants nichts Neues sein. Im ersten Teil schaffen es die Autoren an tollen Beispielen die Potentiale, die eine offene Unternehmenskultur,  vertrauen in die Mitarbeiter, hervorrufen können aufzuzeigen. “Vertrauen und Offenheit zahlen sich aus”. Im Verlauf werden die Ist-Situation und die damit verbunden Probleme hervorragend beschrieben. Das Aufkommen an internen Mails muss reduziert werden.

Auch Facebook möchte eine E-Mail Alternative anbieten. Wenn es sich jedoch lediglich um einen andersartigen Kommunikationskanal handelt, sehe ich wenige Vorteile darin. Wenn man es jedoch schafft, die darin enthaltenen Informationen strukturiert zu extrahieren und abzulegen, könnte das ein echter Erfolg werden.

Zurück zum Buch:
Wer wissen möchte, warum E-Mails ein schlechtes “Informationsmanagementsystem” ist, sollte das Buch kaufen!

Am Beispiel “Ein Tag ohne Wiki, ein Tag mit Wiki” wird dies sehr gut veranschaulicht. Fazit: Ich stimme mit den Autoren zu 100% überein, was die gegenwärtige Problematik in den Unternehmen betrifft. Ich war dann doch überrascht, dass die Beispiele Projektmanagement und Meeting Organisation, genannt werden. Mit Sicherheit kann man in Confluence, Templates für Projektmanagement und Meetings erzeugen. Ob dies aber ein geeigneter Mechanismus ist, wage ich zu bezweifeln. Man sollte, zwischen strukturierten Daten und Informationen und unstrukturierten Daten und Informationen, unterschieden. Projetmanagement und Meetings sind für mich “Strukturierte Daten”.

  • Jedes Meeting hat:
  • Teilnehmer
  • Agenda
  • Titel
  • Ressourcen(Beamer, Telko-Nr)
  • Aufgaben
  • ..

Wenn ein Mitarbeiter krankt wird, kann man strukturierte Daten einfach Abfragen, z.B. über die Suche:  “Teilnehmer: Max, Mustermann”.

Ich versuche mit den Standard-Cloud Modulen sämtliche strukturierten Daten abzufangen. Denn in der Regel sind hinter strukturieren Daten auch Prozesse (z.B. Genehmigung für Budget etc).

Was sind dann unstrukturierte Daten und Informationen?

Alle Daten und Informationen, die zum jetzigen Stand noch nicht strukturiert sind und ggf. dies auch nie werden.

Was heißt das? Stellen wir uns vor: Wir sind eine Müllentsorgungsfirma für Spezialaufgaben. Der Mount Everest ist zu einer großen Müllhalde geworden. Jedes Jahr steigen ca. 250 Bergsteiger herauf und hinterlassen pro Person ca. 5 Sauerstoffflaschen. Unser Auftrag ist es, diese zu sammeln und entsorgen. Wie gehen wir vor? Wir haben keine strukturierten Daten und Informationen hierüber – das hat noch niemand gemacht. Wir können zwar einen Projektplan erstellen – doch funktioniert dieser?

Wenn man Tübinger Wissenschaftler fragt, dann ist anonymes Brainstorming der Projektteilnehmer die beste Lösung. Wir erzeugen aus Outlook ein Meeting, laden die Sherpas ein und erzeugen für jeden Teilnehmer eine Wiki Seite, auf der er anonym seine Lösungsideen notiert.

  • z.B.: “Die Bullen müssen Redbull trinken” (Anonymer1)
  • “Der Restsauerstoff der Flaschen wird genutzt..” (Anonymer2)

Danach ist es die Aufgabe, diese unstrukturierten Daten und Informationen zu managen. Den Projektplan erstellen und die Beziehungen|Relationen|Abhängigkeiten zwischen den Wiki-Seiten/Daten/Informationen herzustellen. Vor der Aufräumaktion haben wir dann strukturierte Informationen, die aber mit unstrukturierten Informationen verlinkt sind. Das macht in Zukunft auch Wikipedia (http://netzpolitik.org/2012/wikidata-strukturierte-daten-fur-wikipedia-co/)

Ein weiteres Beispiel wäre z.B. ein IT Ticketsystem. Jedes Ticket (strukturierte Daten) enthält folgende Information:

  • IT
  • Datum
  • Problembeschreibung
  • ..

Besser wird das Ticket System aber erst, wenn man auf Wiki-Seiten verlinken kann. Wenn ich dann noch aus der Wiki-Seite heraus ermitteln kann, welche Tickets auf meine Seite verweisen, ist das perfekt. Das alles ist mit SharePoint “out-of-the-box” möglich.

Ich habe mir in den vergangen Wochen mal darüber Gedanken gemacht, wie Daten und Informationen strukturiert abgelegt werden können. Denn man sollte eine Methode haben, wie unstrukturierte Information in strukturierte umgewandelt werden könnten. Dazu habe ich ein Modell entwickelt. Dieses sollte alle Anwendungsfälle des Mitarbeiters abdecken, wenn er Informationen teilen möchte. Dazu aber im übernächsten Blog-Eintrag mehr.

Zurück zum Buch – ich bin etwas abgedriftet – aber ich wollte den Unterschied noch einmal klar machen. Mich hatte das Beispiel aus dem Buch eben sehr verwundert.  Zu ein paar Thesen möchte ich noch Stellung nehmen:

  • Warum Wiki und kein Intranet –  “Änderungen sind so kompliziert und umständlich vorzunehmen, dass man im Endeffekt auf sie verzichtet Ohne Schulung keine richtiges Intranet.
  • Interne Mail-Dateianhänge verbieten
    Gute Idee, traue ich mich aber nicht an den Kunden heranzutragen und wird sich in der Praxis auch nicht bewähren.
  • E-Mail Analyse für Verbesserungspotentiale heranziehen.
    Gute Idee, aber keiner lässt sich freiwillig in das Postfach sehen.
  • “Das was den Marktwert eines Mitarbeiters im Unternehmen definiert, kann im Wiki gar nicht abgebildet werden.”
    Richtig. Außerdem ist manchem Unternehmen gar nicht bewusst, was ein Mitarbeiter möglicherweise noch an Know-how etc. vorweisen kann.
  • Informelle Selbstbestimmung motiviert
    Definitiv, keiner möchte auf großen E-Mail Verteilerlisten stehen.
  • Pilotprojekte empfohlen
    Es macht definitiv Sinn, mit einer kleinen Gruppe zu beginnen, Feedback einzuholen, Optimieren und erst dann ausrollen.
  • “Wiki-Philosophie bedeutet Kollaboration und Transparenz”
    Stimmt.
  • Wiki muss an CI angepasst werden
    Mitarbeiter können sich nur dann mit dem Produkt identifizieren, wenn auch das Design passt.
  • Feedback Automatismus
    Jeder Mitarbeiter muss die Möglichkeit haben, Verbesserungsvorschläge einzubringen.
  • Klar definierte Use-Cases
    Der Anwender darf nicht abgeschreckt werden. “Klar” definierte Use-Cases und eine “Politik des Vergebens” helfen.
  • “Eine vergleichsweise grobe Strukturierung reicht unserer Erfahrung nach aber vollkommen aus … relativ unsystematisch viel Inhalt .. Es ist aus unseres Sicht ein sinnvolles Opfer darauf zu verzichten.
  • Ich kann mir nicht vorstellen, dass man 5000 Wiki-Seiten mit einer einfachen Seitenstruktur/Navigation verwalten kann, bzw. schnell zum gewünschten Artikel kommt.  In der SharePoint Wiki Lösung gibt es deshalb ein Feld für die Seitenstruktur und ein weiteres für das Tagging der Inhalte.
  • Kugelschreiber mit der Aufschrift “Ab ins Wiki .. oder Schon im Wiki?”
    Die Idee finde ich super. Kostet nix, könnte aber eine Wirkung haben.

Insgesamt ist das Buch eine absolute Kaufempfehlung. Ich würde mir allerdings gerne mal ein großes Confluence-Wiki mit mehreren tausend Seiten anschauen. Die Thesen werden mit Statistiken belegt. Mir persönlich würde aber ein Beispiel von einer “echten” Firma gefallen.

Wer Gründe für die Wiki Einführung benötigt, dem helfen die “111 Gründe für ein Firmen-Wiki”:
http://blog.seibert-media.net/2010/08/18/111-gruende-fuer-ein-firmenwiki/