Rückblick auf das Expertensymposion “Wikis in Organisationen”

109211670_e666cc162b

Visual CC-BY Maisonbisson

Die obige Grafik ist kein Zufall – Visualisierungen dieser Art wurden letzten Freitag beim “Wikis in Organisationen” Expertensymposion mehrfach gezeigt und auf verschiedene Weise analysiert. Um was ging es: vorrangig um quantitative und qualitative Analyse der Nutzung von Wikis in Organisationen. Für mich war das interessant, u.a. weil so auch Ansatzpunkte für Coaching und Skalierung gefunden werden können. Es war also auch nicht überraschend dass sich die Diskussionen zumeist um Fragen der Implementierung drehten, bzw. wie die Nutzung eines bereits eingeführten Wikis ausgebaut werden kann.

Die visualisierten Daten lieferten hier verschiedene Ansatzpunkte für interessante Diskussionen, kein Wunder, sie können ganz verschieden interpretiert werden (wobei es mir so vorkam dass sich die verschiedenen Interpretationen vor allem aus dem qualitativen Hintergrundwissen bzw. den verschiedenen Erwartungen enstanden). Die Auswertungmöglichkeiten aus Sicht des Informatikers (und die Möglichkeiten mit deskriptiver Statistik, visuellem Datamining und Visualisierung von Netzen) sind eben mehr ein Startpunkt für weitere, mehr “explorative” Überlegungen. Die qualitative Auswertung, ergänzt mit der quantitativen Auswertung, kann dann bspw. genutzt werden um gezielt Nutzer (für Interviews oder auch für Wiki-Coaching) herauszufinden.

Was ist mir sonst noch aufgefallen, zum einen eine Fokussierung auf die Mediawiki-Engine, und ein wiederholtes Reiben an der Wikipedia, obwohl früh deutlich gemacht wurde dass die Bedingungen und Ziele von Unternehmenswikis doch sehr verschieden sind, zum anderen eine leider zu kleine Untersuchungsgruppe – vier Organisationswikis sind sicherlich zu wenig um wirklich tragfähige Ergebnisse zu liefern. Dennoch sind die Fallstudien verschiedener Wikis natürlich interessant, auch wenn die verschiedenen Organisationen recht unterschiedliche Arbeitsweisen aufweisen.

Zum anderen fand ich es interessant dass immer wieder Anknüpfungspunkte zu Wikipatterns in der Diskussion auftauchten – der Werkzeugkasten “Wikipatterns” wird bekannter, bspw. wenn die zentrale Rolle von Wikigärtnern und Wikignomen (adoption patterns) diskutiert wird.

Zuletzt: der Mac hat mich (freundlich, aber bestimmt) bereits an diesen versprochenen Post erinnert, einen ausführlichen Bericht vom Symposion hat Cedric gepostet: Expertensymposium – Wikis in Organisationen.

Grow your wiki goes free

Seems like I missed out on quite a couple of things lately (in the world of Enterprise 2.0 you better not go on holidays or spend endless days refining lengthy papers and other scientific work, or spend time with clients and writing proposals … so I need to blog more over the next days and play catch-up).

One of the missed things being the announcement by Stewart Mader (author of Wikipatterns book, find my favorable review and related posts on my very own wikipatterns takes and talks here) that he’s now offering (freelance) specialist wiki consulting. Thomas, Luis, Stephen and others were so much faster than me. Whatever, I think this is a good move and I heartily welcome Stewart to the small circle of (networked and vendor independent) wiki and Enterprise 2.0 consultants.

Congratulations Stewart, and I look forward to see you again, last time in Varese time was much too short – maybe we’ll venture in a project sometime. Don’t forget I am still owing you a nice german beer :*)

Wiki – Gegenargumente und Gegengegenargumente

KoopTech hat eine Liste von Wiki-Gegenargumenten vorgestellt. Nicht alles davon ist stichhaltig. Manche Punkte benötigen schon einer Relativierung – oder auch direktem Widerspruch. Aber ich will nicht überkritisch sein, denn Kooptech hat ja auch 10 Gründe für den Wiki-Einsatz gefunden.

Johannes Moskaliuk hat die 8 Gegenargumente analysiert – unterteilt in funktionale und psychosoziale “Lösungsmöglichkeiten”. Gefällt mir sehr, und ja, es geht hier nicht um absolute “Wahrheiten” sondern mehr um Gefühle, Einschätzungen und eben auch alternative Umsetzungs- und “Lösungsmöglichkeiten”. Also erweitere und kommentiere ich Johannes’ Ideen aus meiner Sicht:

1. Die krude Wiki-Syntax ist oftmals ein Akzeptanzproblem.

Psychosozial: Neue Software erfordert neue Kompetenzen. Ohne Schulung der Mitarbeiter, Supportfunktion und eine Beteiligung der Nutzer bei der Entscheidungsfindung geht es auch im Wikizeitalter nicht.

Funktional: Mit dem Einsatz eines WYSIWYG-Editors ist das Problem lösbar. Technisch möglich ist auch die weitergehende Integration ins Betriebssytem, wie z.B. beim TWiki mit dem Kupu-Add-on (Linux) oder beim der Confluence-Software mit MS Office (Microsoft).

Zum einen: WYSIWYG-Editoren sind kein Allheilmittel und weisen nach jetzigem Stand der Technik auch gewichtige Nachteile auf. Es ist kein Zufall dass Enterprise Wikis wie Socialtext beide Editor-Alternativen parallel anbieten. Eine ausführlichere Analyse von Pro und Contra findet sich hier (“Simplicity, adoption and WYSIWYG editors”).

Zum anderen: Eine Einschätzung als krude Syntax (sic!) gilt nicht für jeden Markup-Dialekt, man vergleiche einmal die Auszeichnungsalternativen von bspw. Mediawiki für kursiv und bold (” und ”’, bold und kursiv sieht dann so aus: '''''fett und kursiv''''' – eingängig nicht wahr?) mit denen von Wikicreole, an die sich u.a. DokuWiki anlehnt.

Aber die eigentliche Aufgabe liegt natürlich im Bereich “psychosoziale Akzeptanz”, und es ist zweifellos richtig, dass Markup ein Akzeptanzproblem hat. Letztlich gilt das für alle Werkzeuge, die nicht wie Word aussehen (interessanterweise werden manche andere Werkzeuge und Systeme nicht so stark hinterfragt was Usability und Akzeptanz angeht, sie werden Mitarbeitern aufgezwungen und diese müssen damit mit SAP R/3 arbeiten – auch wenn die Usability bescheiden ist). Pragmatisch gesehen liegt die Antwort daher meist in einem “sowohl als auch”, in Verbindung mit einer gewissenhaften Analyse von Anforderungen und Zielgruppen, die Frage ob WYSIWYG sein muss, sollte dabei ergebnisoffen und vorurteilsfrei angegangen werden.

2. Kategorien und Hierarchien lassen sich zwar aufbauen, doch eine entsprechende Navigation kann nur über einen Eingriff im Backend eingerichtet werden.

Funktional: Über den Einsatz semantischer Technologien oder – einen Schritt vorher – die konsequente Anreicherung von Informationen mit Metadaten (z.B. Tags, Projektzuordnung, Themen, Inhaltsklassen) sind die Inhalte letztlich schneller über eine Suchfunktion als über eine Navigationsstruktur zugänglich.

Psychosozial: Dieses Gegenargument ist gleichzeitig ein Pro-Argument: Die Navigation wird eben nicht „von oben“, vom Admin oder Chef festgelegt, sondern wird von der Community kollaborativ erstellt.

Hmm, Navigation nur über einen Eingriff im Backend? Gilt nicht für die Wiki-Engines zu denen ich rate. Und Navigation über Kategorien oder Hierarchien? Es muss eben evaluiert werden, ob es nicht Wiki-Engines gibt, die so etwas von Hause aus mitbringen (bspw. TWiki-Webs, eigentlich alle gängigen Enterprise Wikis oder auch DokuWiki mit dem Namespace-Konzept).

Johannes – großartiger Punkt bei psychosozial. Dieser Aspekt des emergenten Entstehens von Struktur wird zu oft vernachlässigt, obwohl er viel für die flexible Anpassung an veränderliche Aufgabenstellungen (und die Motivation der Mitarbeiter) tun kann. Arbeitsgruppen, einzelne Mitarbeiter, einzelne Projektgruppen etc. können sich situativ angepasste Arbeitsumgebungen, Portal- und Übersichtsseiten einrichten. Das habe ich mit großem Erfolg auch schon begleitet, und es war eine Freude zu sehen wie die Möglichkeiten von den Nutzern aufgenommen und schnell genutzt wurden.

3. Die Kategorisierung spielt bei den Suchergebnissen keine Rolle bzw. sorgt nicht für eine Priorisierung von Suchergebnissen.

Funktional: lösbar, siehe oben

Psychosozial: Kompetenz bei der Anwendung der Suchfunktionalität muss bei den Nutzern vorhanden sein, oder geschult werden. Außerdem kann das Finden von Informationen, nach denen eigentlich nicht gesucht wurde, Prozesse der Wissensemergenz fördern (Serendipity).

Ich würde noch ergänzen, dass wir auch die zunehmende Einbindung von Wiki-Inhalten in Enterprise Search Ansätze sehen werden. Von Social Bookmarking in the Enterprise ganz zu schweigen. Das Problem ist erkannt, daran wird gearbeitet und Wikis sind eigentlich hierbei das kleinste Problem, viel mehr wird zurzeit damit gekämpft relevante Suchergebnisse aus den vielen, verteilten Office-Dokumenten zu generieren …

4. Suchergebnisse zeigen nicht an, welche Unterthemen es zu einem Oberthema gibt oder ob es in einer anderen Sprache einen Artikel zum gesuchten Thema gibt. Die Semantik drückt sich nicht in Wiki-Strukturen aus. Ab einer gewissen Textmenge ist das nicht mehr praktikabel.

Funktional: lösbar, siehe oben. Schlagwort: Semantic Wiki.

Ja, Semantik drückt sich auch nicht in Office-Dokumenten aus. Tagging, Kategorisierung, redundanzfreie Datenhaltung – alles wichtig, das Semantic Web wird auch manches davon lösen. Psychosozial gilt Punkt 3, Informations- und Medienkompetenz ist nicht immer gleichverteilt und gut ausgeprägt. Coaching und Schulung (und Learning-by-doing) kann hier helfen.

5. Die Suche erstreckt sich nur auf Wiki-Inhalte, andere Quellen können damit nicht erschlossen werden.

Funktional: lösbar. Beispiel ist das Confluence Wiki, dass auch zum Durchsuchen von externen Quellen, z.B. Austauschordner oder Servern genutzt werden kann.

Ja, siehe auch oben die Anmerkungen zu Enterprise Search. Enterprise Wikis bieten mittlerweile fast durchgängig die Möglichkeit bspw. hochgeladene Dokumente in die Suche aufzunehmen.

6. Das Rechtemanagement für ein Wiki muss mühsam eingerichtet werden, insbesondere wenn ein nach Personen und Gruppen differenzierter Zugang für verschiedene Bereiche eingerichtet werden soll.

Funktional: Lösbar zum Beispiel durch den Einsatz von Windows Active Directory. Für das Wiki können bestehende Rechtestrukturen übernommen werden.

Psychosozial: Ein Erfolgsfaktor für den Einsatz von Wikis ist eine flache Hierarchie und der freien Zugänglichkeit von Inhalten. Idealerweise ist die Einführung von Wikis in einer Organisation verbunden mit einer Änderung der Organisationskultur im Bezug auf den Umgang mit Wissen und Informationen zwischen Hierachieebenen.

Hmm, was heißt mühsam? Ist in den meisten Wikis nicht aufwendiger oder anspruchsvoller als die Benutzer- und Rechteverwaltung von Windows Server etc. Eine LDAP-Anbindung ist oft vorgesehen, damit ist dann selbst SSO machbar.

7. Nach etwa ein, zwei Jahren kann es für Unternehmen problematisch werden, wenn die entsprechende Pflege fehlt.

Funktional: Tools können die Pflege unterstützen, zum Beispiel das Finden von toten oder falschen Links, das Ändern von falschen Kontaktdaten etc.

Psychosozial: Das Problem tritt bei allen Systemen zum Wissensmanagement auf. Neben der Einführung einer Technologie, müssen sich deshalb auch Arbeitsabläufe, Arbeitsaufgaben und Rollen (Wikigärtner) anpassen, so dass eine ständige Pflege und Aktualisierung von Inhalten gewährleistet bleibt. Anders als bei anderen Werkzeugen kann die Verantwortlichkeit für die Aktualität der Inhalte auf alle Mitglieder einer Organisation verteilt werden.

Ohne Pflege geht es nicht, nicht umsonst werden die Rollen des Wiki-Gärtners oder des Wiki-Gnoms so wichtig eingeschätzt. Und ja, auch in einem klassischen Intranet kann ohne strukturierende Pflege Wildwuchs, wie bspw. veraltete, widersprüchliche oder redundante Inhalte entstehen (ich gebe aber zu dass ich die Möglichkeit an veröffentlichte Seiten ein “Verfallsdatum” zu knüpfen manchmal vermisse). Aber diese Schwäche kann man durchaus auch zum Vorteil wenden, siehe Punkt 8:

8. Wikis eignen sich für Projekte. Über die Jahre werden jedoch immer mehr Wikis eingerichtet, der Überblick geht verloren – man weiß nicht mehr, in welchem Wiki man suchen muss.

Funktional: Lösbar durch eine Suche, die über mehrere Wikis ausgedehnt ist.

Psychosozial: Klassischerweise wird ein Projekt in einem Abschlussbericht dokumentiert. Auch das lässt sich auf ein Wiki übertragen: Am Ende eines Projekts werden die zentralen und wichtigen Inhalte des Projekts in ein zentrales Wiki übertragen und bleiben dort zugänglich. Das Projektwiki wird gelöscht.

Wenn im Zeitverlauf mehrere Wikis entstanden sind (oder Projektunterbereiche etc.) ist es aus meiner Sicht auch eine Chance Inhalte rückschauend zu strukturieren, und dabei positive und negative Erfahrungen zu dokumentieren. Ein After-Action Review mag zwar zeitraubend erscheinen, aus meiner Erfahrung lohnt sich die Mühe aber. Eine Zusammenfassung der wesentlichen Punkte schafft einen Überblick, der bei anderen ähnlich gelagerten Projekten hilft. Ein paar Ideen zum Einsatz von Wikis im Projektmanagement habe ich hier, hier und hier zusammengestellt.

Zusammenfassend: Einige der Punkte entstammen meiner Meinung nach einer weitverbreiteten (aber unüberlegten) Gleichsetzung von Wiki mit Mediawiki bzw. Wikipedia. Die Wikipedia ist aber kein archetypisches Wiki, und Mediawiki ist auch nicht stets die beste Wiki-Engine. So weisen bspw. Enterprise Wikis wie Socialtext oder Confluence einen Großteil der oben vermuteten Angriffspunkte überhaupt nicht auf, sprich es bestehen bereits funktionale (technologische) Lösungen.

Zudem beziehen sich viele der Kritikpunkte der originalen Liste von Kooptech auf potenzielle Nachteile, d.h. mögliche Schattenseiten von Wikis, die erst durch eine “ungeschickte” Einführung und ungeignetes (Wiki-)Management* zutage treten. Die Auswirkungen auf Strukturen und etablierte Routinen etc. können ja groß sein – das ist auch das eigentliche Motiv von Enterprise 2.0. Aber um diese Potenziale heben zu können braucht es auch ein schlüssiges Konzept, sowie die Anpassung an die Unternehmensgegebenheiten und -ziele. Aber wenn etablierte Vorgehensweisen und Erfolgsfaktoren der Implementierung nicht beachtet werden, kann es durchaus schon mal schiefgehen.

<werbung>Deshalb bietet es sich ja auch an professionelle Unterstützung ins (Projekt-)Boot zu holen. Berater wie wir bringen zum einen spezifische Erfahrungen ein, aber auch

  1. einen Überblick über bewährte Vorgehensweisen und
  2. Ideen, d.h. innovative, kreative Problemlösungsstrategien.

Davon kann die organisationsseitige Einpassung – sprich das Change Management in Bezug auf die eigentlich spannenden sozialen und unternehmenskulturellen Aspekte – profitieren. Und weil es bei Enterprise Social Software wie Wikis meist weniger um Technologie, denn um diese weichen Faktoren geht ist eben weniger Technologieberatung denn Organisationsberatung notwendig.</werbung>

* ich lese gerade das Buch Wikimanagement von Prof. Komus, Review folgt.

Some recent enterprise social software notes …

Thomas Van der Wal ponders the uses of social software in mergers and acquisitions, referring a recent post by Stewart Mader on the opportunities of getting new employees up to “working speed” quickly (“Onboarding: getting your new employees cleared for takeoff“).

Ken Thompson on the relation between collaboration, teams and business process management:

It’s the human-to-human interactions of teams that count when it comes to innovation and agility. … you and everyone you work with must be able to function in and through internal and multi-company teams, and must also grasp what the latest concept of “team” really means

Matt Moore interviewed James Dellow about the Enterprise RSS Day of Action, here’s the mp3

Armin Karge tells us the story (in german language) of a tangible method of change communication:

Das “Cockpit” muss vor allem zwei Anforderungen gerecht werden: Einerseits soll es Alarmanlage und Kontrollinstrument sein. Andererseits soll es durch Offenheit und Transparenz zu mehr Akzeptanz der Beteiligten führen. Im Idealfall sind die Mitarbeiter beteiligt und identifizieren sich.

Stewart Mader and the team from Atlassian are sharing insights on wiki functionality, use cases and adoption (and they are giving away free copies of Stewarts Wikipatterns book, my review is here) at the Web 2.0 Expo this week, see what’s on the slate and drop by if you’re in San Francisco.

And finally Andrew McAfee reminds us of the importance of all this:

Enterprise 2.0 is not a hype, but it is also not easy, and it will serve to separate the winners from the losers

Andrew will keynote Heliview on May 7th, looks promising, I am thinking of going too – want to meet up?

re:publica 08 @ Berlin

Heute und morgen bin ich auf einer Konferenz, die viele Züge einer Un-Konferenz trägt. Mal sehen, vielleicht biete ich auch noch einen (erweiterten) Vortrag meiner bewährten Wiki-Patterns Session an, für alle die Teilnehmer von den 800 re:publicanern, die sie noch nicht gehört haben.

Ansonsten werde ich vermutlich weniger bloggen, denn micro-bloggen, mein Programm ist recht gedrängt.

Stewart Mader video series on wiki adoption

Whoa, fresh content for this blog is secured for the next 20 days, as Stewart Mader (whose book I’ve just reviewed very favorably here) will post a short video episode each day. I’ll try to not only post his content but to add some thoughts and observations of mine as time permits. For now let’s start with the first two episodes, number one is the introductory episode, number two is the first episode dealing with the details (Day 1 “Grassroots is best”)

Termine: Seminare, BarCamps, WikiWednesday Stuttgart, CeBIT und mehr

Transparenz von Terminplänen ist manchmal eine gute Sache – wer mich bei den folgenden Veranstaltungen treffen möchte weiß nun wo und wann. Also, rund um verschiedene Kundentermine (die ich natürlich nicht transparent machen werde …) bin ich in nächster Zeit hier tätig:

Am Mittwoch 23.01 bin ich auf der Open Source meets Business Konferenz in Nürnberg, hier mein Plan für den Tag.

BarCamp JenaDann am 30.01 ein Workshop an der Universität Stuttgart: SOA & Co.: Diensteorientierung in der IT, sowie vom 8.-10.02 das BarCamp Mitteldeutschland, für das ich noch eine Session zum Thema Wikipatterns vorbereiten will.

Mein Enterprise 2.0 Seminar (“Social Software in Unternehmen nutzen“), das ich zusammen mit Oliver Gassner anbiete, findet dann am am 18.2.2008 an der MFG Baden-Württemberg, Stuttgart statt.

dfnIn der Woche darauf wieder eine Konferenz, im Rahmen der DFN Betriebstagung in Berlin vom 26.-27.02 werde ich einen Vortrag zum Thema Web 2.0/Enterprise 2.0 vorbereiten und im Track Multimedia präsentieren. Genaueres sowie evtl. Materialien stelle ich dann zeitnah zur Verfügung.

BarCamp Alsace Am Freitag 29.02 startet dann das BarCampAlsace5 in Mulhouse (F), mein erstes BarCamp außerhalb Deutschlands.

Im März folgt die CeBIT, hier werde ich einmal am Enterprise 2.0 Summit am 4. März und natürlich an den Enterprise 2.0 Open am 9. März teilnehmen, gefolgt vom vierten WikiWednesday Stuttgart am 19. März, mit dem Schwerpunktthema “Projektmanagement”.

Zu den Terminen die ich leider nicht wahrnehmen kann, zählen das BarCamp Ruhr, sowie das BarCamp Hannover. Ein gewisser Trost besteht darin dass ich vermutlich viele der Teilnehmer von dort am BarCamp Offenburg bzw. am BarCamp Bodensee wiedersehen werde …