frogpond

Stumbled upon: Enterprise 2.0, intranets and cognitive surplusses

There are now a lot of open tabs in my browser – small wonder when researching, conferencing and preparing a new consulting gig. Let me try a rundown, no special order:

Clay Shirky says on CIO Insight that businesses are just beginning to understand the value—and challenges—of social technologies.

Nora Young of CBC Spark show posted audio from a full interview with Clay Shirky. The interview is worth hearing, and touches on some of the topics in his new book (Here Comes Everybody, see also here and here) – such as the pros and cons of social media, new business models online, and how big change comes from human motivation, not shiny new technologies. Download the mp3.

Nora and Clay started off by talking about our “cognitive surplus,” which Clay describes as “all the free thinking time that society has access to… in the brains of its citizens that isn’t getting used for specific tasks.” Think TV watching time, except Clay has some ideas on how you should be/could be spending your surplus.

There’s a (german language) issue of UNESCO Heute on the web society and its understanding and emergent uses of knowledge, this is a rather heterogenous beast, a compilation of small articles:

[…] Begriffe, Konzepte und Themen der Wissensgesellschaft mit Bezug auf das Internet

Then here’s a study by the Economist Intelligence Unit about collaboration.

Corporations all over the world are making tremendous investments in technology, from servers, to storage, and network. Although technology is used on a day-to-day basis (think about the Voice over Internet Protocol (VoIP) deployments) to enhance productivity and to curb costs, it seems that collaboration is still best performed face-to-face. The study provides a glimpse into the reason: trust.

Jay Cross too has some hints for online collaboration (pdf). Dion Hinchcliffe is explaining where the conversation is going (“Endless Conversation: The Unfolding Saga of Blogs, Twitter, Friendfeed, and Social Sites“), including Twitter and Friendfeed uses for business. And Michael Krigsman analyzes power politics and pitfalls in Enterprise 2.0 adoption. Yes, we need to understand the corporate context to make this work, this is true especially when dealing with middle management. Now, getting out there and trying it is an option, it’s “show and tell” – indeed, in my experience upper management gets it rather easily. Still I somehow like this cartoon by geek and poke. Better beware this situation …

And finally check out Ross Mayfields slides of his keynote at Van Web 2.0 naar Enterprise 2.0 in the Netherlands:

I wasn’t there, nor at the Intranet Summit 2008 (Saim Alkan has a german language summary). I’ve been at the Intranet.days (meeting Saim and others) and will be here at the International Forum on Enterprise 2.0 in Varese and have some rebooting too.

Thomas Vanderwal will be there both times, in fact we will have the same flight from Milano to Copenhagen. Here, he writes on success with enterprise social tools, i.e. difficulties of applying social tools in the organisation using an illustrative model of four intersecting areas of enterprise social tools:

– tools (I would include methods as well here)
– interface and ease of use (yes, usability has some merits and plays an essential role for adoption)
– sociality
– encouraging use

Hmm, the model can serve as a good starting point, even when – as Paula Thornton observes in the comments – placing tools so prominently feels awkward.

Rückblick aufs BarCamp Bodensee

(CC-)Bild von Tobias Glawe – Samstagabend am BarCamp-Strand

Am Wochenende war ich beim rundum gelungenen BarCamp Bodensee. Mit Sonntagmorgen-Kaffee, leckerem Essen u.a. Croissants und Brezeln zum Frühstück , tollem Wetter, “crowdsourced (BarCamp-)Security”, perfekten Räumlichkeiten im neuen und beeindruckenden ZU-Gebäude, einem schnellen und zuverlässigen WLan – und natürlich spannenden und vielfältigen Sessions, vielen Diskussionen und Gesprächen rund ums Social Web und mehr.

Selbst aktiv war ich in zwei Sessions, zum einen habe ich Usability-Aspekte im Intranet beleuchtet, zum anderen habe ich Sonntags mit Tobias zusammen eine kleine Session über Use Cases, Erfolgsfaktoren und Akzeptanz von Enterprise 2.0 gehalten. Meine Unterlagen stelle ich wie üblich (in kürze, da heute etwas Montagsstress aufkam und die Woche organisiert werden wollte) im frogpond-Wiki zur Verfügung.

Daneben war ich in mehreren Sessions in denen das Thema Social Software im Unternehmen eine Rolle spielte bzw. in denen mehr um Unternehmenskultur und Führung als über Technologien diskutiert wurde. Nur ein Beispiel war die Session von Thomas Zahreddin zu Sociocracy als Organisationsprinzip.

Live gebloggt wurde aus meiner Sicht eigentlich recht wenig, dafür wurde umso mehr getwittert, die gesammelten Tweets sind hier. Bilder gibt es u.a. bei Flickr, Ipernity, , Picasa. Blogbeiträge wie immer bei Google Blogsearch, Technorati etc. oder auch gleich direkt im Wiki.

Bleibt – zum Schluß, aber zentral und wichtig – der Dank an den Organisator und “Kümmerer” Oliver, ohne dessen Initiative das BarCamp sicher nicht zustande gekommen wäre und der Dank an die Sponsoren. Herausragend ist es, wenn zum finanziellen Engagement auch die BarCamp-Mitarbeit engagierter Mitarbeiterinnen tritt.

Und ganz zuletzt: Jan hat hier die Tipps von Oliver für eine gelungene BarCamp-Organisation zusammengestellt, werden sicher in die Planung des Barcamp Stuttgart eingehen. Denn nicht vergessen, nach dem BarCamp ist vor dem BarCamp.

Clay Shirky on Cognitive Surplus

Great thinking about the web’s underlying trends (and some promises for the future) in this talk by Clay Shirky at the Web 2.0 Expo (here’s the edited transcript, here’s a post by me on his new book). Nice quotes in there, like this one on innovation in the digital economy:

The way you explore complex ecosystems is you just try lots and lots and lots of things, and you hope that everybody who fails fails informatively so that you can at least find a skull on a pikestaff near where you’re going. That’s the phase we’re in now.

Stumbled upon – innovative organization and organizations …

Klaus Eck interviews CoreMedia’s Sören Stamer (german language) on what is his definition of Enterprise 2.0, and how it gets “on the road” at CoreMedia, i.e. agility, organizational culture and more:

Als vereinfachende Formel könnte man sagen: Enterprise 2.0 = Web 2.0 in the Enterprise + Privacy + Relevance

Sören himself has an interesting post here, pointing towards Toward High-Performance Organizations: A Strategic Role for Groupware by Douglas Engelbart:

[who] makes a strong case for Enterprise 2.0 long before this term was coined. Especially his framework for improving the improvement process is eye-opening. Inventing hypertext to share information easily was definitely a great C activity. And I guess the same is true for Wikis, Blogs and Micro-Blogs.

When he describes the interdependencies between the human system and the tool system, Douglas Engelbart captures the whole challenge of transforming a conventional Enterprise into an Enterprise 2.0. Without changing our paradigms, organizations, procedures, language and attitudes we won’t see the benefits of new tools.

We’re not alone in this, Vineet Nayar, CEO of India-based information technology services HCL Technologies explains why he believes that in the future, democratic companies will outperform the command-and-control dictatorships that have persisted since the industrial revolution, his learnings include:

– Let go of command and control. In business, as in nations, dictatorship is out. Democracy is in.
– Business leaders must be open to criticism, just as elected officials are.
– Customers don’t come first, employees do, because employees are the product that your customers are buying.
– Democracy and feedback allow employees and managers to gravitate toward their strengths.

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

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.