Ein paar Notizen zum ersten Tag beim BarCamp Berlin 3 – insbesondere zu den von mir besuchten Sessions, die Folien und Notizen zu meiner Session “Unternehmenskultur und Enterprise 2.0″ folgen.

• E-Learning 2.0 (scooyoo.de o.ä.)
• Wissensmanagement 2.0

Die Session zu E-Learning 2.0 hat mich nicht begeistert, zum einen war das mehr eine Firmenpräsentation, zum anderen war das nicht so innovativ. Im Grunde nicht mehr als die “Internetifizierung” von klassischen Edutainment-Angeboten für Schüler – halt eine Internetplattform. Es waren keine Social-Learning Elemente erkennbar, abgesehen von Dingen, die ich eher kritisch sehe. Was bringt es einem Schüler wenn er sieht dass er auf Platz 267 von 500 Schülern ist (Rating? …) – ebenso fand ich es fragwürdig dass das Feedback im Lernprozess eher trivial war. Auch das Fragendesign (bspw. Lückentexte in die die passenden Worte “hineingezogen” werden müssen) war nicht überzeugend. Ob das der aktuelle Stand des pädagogischen Herangehens für Mittelstufenschüler ist?

Zweite Session zu Wissensmanagement 2.0, mit Stefan Ehrlich von T-Systems MMS, diese hatte mehr einen einführendenCharakter, bzw. war ein Erfahrungsbericht aus dem Einsatz bei der MMS. Einige Notizen:

- alt: Wissensmanagement 1.0 – Informationsverwaltung und -verteilung. Ja, ” “Wissensmanagement” ist zwischenzeitlich aus der Mode gekommen, mit Enterprise Social Software wird das “wiederbelebt”
- einige Ausführungen zu den Erfahrungen der MMS mit dem Teamweb (u.a. wurde auch kurz das Strategie-Wiki angesprochen, das übrigens auch in diesem Interview mit Peter Klingenburg Thema war), zuerst aber zum Hintergrund der Firma. Mit drei Worten: Profit Center Organisation. D.h. auch verteilte Kompetenzen in den einzelnen Centern, mit der Folge dass die Zusammenarbeit in diesen großen Einheiten nicht einfach ist, auch weil verschiedene Sprachen und Terminologien in den verschiedenen Centern bestehen. Gleichzeitig gibt es viele Gemeinsamkeiten, bspw. Projektmanagement als grundlegende Methode.

Die Frage war nun wie die Kommunikation zwischen diesen Einheiten gefördert werden lann (ich würde ergänzen, dass es mehr noch darum geht die Kollaboration zu fördern). Die bis dato verwendete Lösung war es Competence Centers für die bereichsübergreifende Abstimmung zu installieren, diese fokussierten sich vor allem auf diese überall benötigten “Gleich-Kompetenzen”. Allerdings passierte in den ergänzten Competence Centern nicht viel, die Aktivitäten waren überschaubar – nach wie vor waren die Profit-Center der Schwerpunkt des Business (selbstverständlich, ja).

Was also tun? Coaching, Leadership und “Anreizsysteme” (ja, kritisch), Veränderung der Motivationsstrukturen und der Unternehmenskultur, … mehr dazu später im Post zu meiner Session (“Unternehmenskultur und Enterprise 2.0″).

Was wurde bei der MMS gemacht? Relativ ungezwungene Einführung eines Confluence-Wikis als “Experiment” und die Beobachtung was sich an emergenter Nutzung ergab, d.h. was wurde mit dem Werkzeug wirklich gemacht? Eine Beobachtung war es, dass sich auf der Wiki-Plattform die Profit-Center Struktur nicht widerspiegelt – es bilden sich vielmehr thematisch bezogene Communities heraus. Allerdings war bei der MMS die Nutzung der Plattform nicht natürlich, auch hier bestehen nach wie vor Bedenken und Ängste, bspw. vor kritischem Feedback. So nutzen manche das Wiki nur für Basisaufgaben wie bspw. die Vor- und Nachbereitung von Meetings, nun ja das ist meiner Meinung nach nicht notwendigerweise schlecht, die Hauptsache ist es ja dass es überhaupt genutzt wird.

Eine der Erwartungen war es Expertise bzw. Mitarbeiter mit Expertise durch das Wiki leicht auffindbar zu machen – in der Folge wird das Teamweb im wesentlichen auch dafür genutzt. Das zugrundeliegende Paradigma ist mithin: es geht weniger um “Codified Knowledge”, als um das Finden von MA die Probleme lösen können. Klar, personenfokussiertes Wissensmanagement ist prinzipiell ein guter Ansatz – hat aber natürlich auch Nachteile u.a. ist das noch keine Lösung für den Wissenstransfer (und auch keine Lösung wenn die Kompetenzträger das Unternehmen verlassen würden). Kodifiziertes Wissen ist zudem auch nicht einfach, u.a. weil Wissen stark vom Kontext abhängt – in der Folge kann es schlecht zwischen heterogenen Kontexten transportiert werden.

Die MMS plant nun mehr Unterstützung und Verständnis beim Management zu schaffen (die Vorteile zeigen, um Budget und Support etc. zu bekommen), sowie die Einführung eines Employee Social Networks im Unternehmen. Ich denke das macht Sinn, gerade um die “Knowledge Hubs” im Unternehmen zu identifizieren, und diese als Ausgangspunkte für Knowledge Cluster gewinnen. Eine Möglichkeit ist es, dass sich die Kompetenz- und Wissensträger quasi “selbstselektieren” können, und letztlich vorrangig flexible Plattformen bereitzustellen, die die Ausformung der Wissensnetze unterstützt aber nicht vorgibt. Ein Problem ist ja, dass gerade die Mitarbeiter mit den spannendsten Kompetenzen oft am wenigsten Zeit haben, bzw. unwillig sind ihr Wissen zu teilen. Positiv formuliert – oft haben genau diese Leute keine Zeit ihr Wissen zu teilen, sie “fahren besser” wenn sie weniger sichtbar sind, da dann mehr Zeit für die persönlich als spannender empfundenen Sachen bleibt. Dahinter steht die Aufgabe wie man diese Aufgabe der Wissensverteilung zu einer spannenden Aufgabe machen kann bzw. wie man diese Experten (nachhaltig) motivieren kann.

Es geht um die persönliche “job satisfaction” dieser Leute – klar, manche machen das sehr gerne, sind quasi natürliche Evangelisten. Andere wollen mehr Experte bleiben und nicht so viel kommunizieren (und das ist meiner Meinung nach ein weiterer “Leverage Point” – um die Expertise zu skalieren können Knowledge Blogs ein gutes Instrument sein).

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

einen Überblick über bewährte Vorgehensweisen und

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.

Meine Präsentation von Open Source Wikis, insbesondere DokuWiki stelle ich in kürze zur Verfügung.

Dr. Christoph Giess von Avono präsentiert nun Confluence live.

Wichtige Punkte:
- Attachments (durchsuchbar)
- Suche (kann vom Anwender auf Bereiche eingeschränkt werden)
- Restrukturierbar
- Word-Dokumente können im Wiki “angeschaut” werden
- Informationsarchitektur <=> verschiedene Sichten auf die Daten, gut für Reports die flexibel (aber schon von der internen IT, ist nicht ganz so einfach) erstellt werden können
- nicht besonders interoperabel mit anderen Systemen (in Bezug auf das semantische Netz)
- Selbstselektion der Inhalte – Mitarbeiter können Bereiche angeben, die sie interessieren – auch in Verbindung mit einem personalisierten RSS-Feed
- Confluence kann an bestehende Authentifizierungssysteme angekoppelt werden (LDAP, Active Directory etc.)
- Confluence bietet auch fein granulierbare Zugriffsrechte, u.a. Bereichsadminstratoren
- kann in bestehende Portale eingebunden werden, zudem in Filesysteme, Webdav et al.
- viele Erweiterungen verfügbar (teilweise von der Nutzercommunity entwickelt), Schnittstellen mit externen Systemen bspw. XML-RPC

Interessante Diskussion nun – warum nicht auf Sharepoint warten? Nur ein Grund: Sharepoint ist dokumentenorientiert, eher Dokumentenmanagementsystem. Und Dokumente werden überschätzt …

Und last not least stellen Björn und ich noch die Enterprise 2.0 @ CeBIT vor – hier das Blog und das Wiki.

Zwar basiert Atlassian auf Java (J2EE), dies ist aber sicherlich kein Hindernis für diese strategische Kooperation. Der Hintergrund liegt darin, dass Anwender durchaus leistungsfähige Wikifunktionalitäten benötigen, die das bestehende SharePoint-Wiki nicht erfüllen kann. Der SharePoint Connector wird daher den bidirektionalen Informationsaustausch zwischen SharePoint und Confluence ermöglichen, bzw. die Integration der Datenbasis sicherstellen (“providing single sign-on, search, content sharing and linking between the two applications”, Dennis Howlett).

Robert Scoble hat ein Interview mit den Gründern von Atlassian gemacht, in dem diese über die neue strategische Partnerschaft mit Microsoft sprechen:

Eine gute Analyse der strategischen Hintergründe findet sich bei Richard MacManus:

This is another great example of big vendors partnering with more agile, and smarter, startups to create better Web Office functionality in their products. It’s win-win for both companies [...] For Microsoft, they get a ‘best of breed’ Web Office app to beef up their hugely profitable SharePoint product.

Interessant ist auch der zweite Teil der Press Release, die Kooperation mit Newsgator, die auf die Ergänzung und Erweiterung der integrierenden (Middleware-)Funktionalitäten von RSS in SharePoint abzielt: Die NewsGator Social Sites sollen Inhalte, Menschen und Gruppen mittels RSS verbinden, Jeff Nolan von Newsgator kommentiert:

What MS is doing with Sharepoint is actually pretty cool, our Social Sites add-on brings content management and an explicit social dimension to the mix. What that means is that administrators and users can use RSS to integrate content in Sharepoint AND then connect that content to people and groups.

Tagging, clipping, sharing, and recommending bits of content is turning out to be a lot more useful that even I would have expected. I’m also constantly surprised with little things I can do, like drop my twitter feed in a widget on my Sharepoint profile page, and it’s all powered by RSS.

Treffende Analyse, RSS ist die wichtige Technologie, die den Einsatz von Social Software im Unternehmen erst lohnend macht …

1 * Update: Die Rolle von RSS wird u.a. hier bei elliptical diskutiert:

You got it right that it enhances the existing social networking functionality within SharePoint (but also WSSv3). It’s also a great solution to surface what’s going on in my organization. We have some really nice rollup views into SharePoint that help people discover other people and discover content within SharePoint. To date, most people’s answer to content discovery in organizations has been “just search for it.” But, it’s also effective to be able to grasp what’s going on organically at a quick glance.