Conversations Connected with Context – Socialtext Signals

Socialtext launched Socialtext 3.0, a trio of applications for connected collaboration with context:

  • People – Social networking for the enterprise
  • Workspace – Group-editable wiki for easy, flexible, enterprise-wide collaboration
  • Dashboard – Customizable home pages that let each person decide where to focus their attention.

Here’s the 60 second video, fresh from Ross Mayfield’s blog

Now add Signals to the mix, Socialtexts Twitter for the enterprise clone …

[…] integrated microblogging for the enterprise. Socialtext Signals is social messaging for the enterprise connected with context. With the rise of Twitter, more people are learning the benefits of microblogging as a medium for conversations and sharing each day. Socialtext developed a standalone version six months ago. Using it internally we’ve learned how different usage is from Twitter, not just because it is more private, but because it is in the context of a company. The social patterns of what people say and share has taught us a lot about potential use cases. Now in private beta with Socialtext customers, Socialtext Signals will provide an integrated user experience across Socialtext Workspace, Socialtext Dashboard and Socialtext People.

Above, that’s an 18 min interview found via Robert Scoble. Yes, I believe this is an important addition and will be an essential part of any enterprise 2.0 platform. Integrating social features like easy microsharing and social networking into Enterprise wikis is just natural. While supporting relationships is a generic purpose, it needs an integrated user experience (that’s a point where laconi.ca based implementations still have a hard time), a focus on work groups and a discrete use (well, we need to ease a pain point to really make the point). See how Dennis Howlett expands on the need for context-sensitive linkage

SocialText [Signals] is providing the essential linkage between people and context with some elements of process. That’s crucial for this type of application to make sense in a corporate environment.

This move by Socialtext is all too timely, we’re seeing enterprise Twitters pop up here and there. Check out some of the recent newcomers with Laura Fitton’s evaluation sheet and read up on some of my thoughts on related adoption patterns and best practices.

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.

Focusing on people and work relations, usability and more …

Socialtext has announced version 2.20, with improvements to the user experience and added Dashboard and People modules. Besides the “Facebook for the enterprise” approach, that puts people and work relations at the center of interest, I particularly like the focus on integration and usability (yes, this is important): Ease-of-use can be a dig differentiator in this market of “enterprise collaboration suites” (wikis are a central part still) – corporate users don’t want to spend days of training to learn “systems”: It’s better to spend the time (and consulting budget too, you know) on coaching and implementation, supporting early users, building up internal support (and use cases) etc.

Here’s a video demo of the newly added capabilities (via Jon Grorud and Socialtext Customer Exchange):

In this context, Scott Schnaars explains the direction and goals of Socialtext along four business use cases:

  • Collaborative Intelligence for sales and marketing
  • Participatory Knowledgebase for service and support
  • Flexible Client Collaboration for professional services
  • Business Social Networks for partners and customers

Disclaimer: Jon pointed me to this video, alas – I am subscribed to Ross Mayfield and the Socialtext news and feeds anyway. Consultants need to stay up to date … and that’s where this is apt:

Disclaimer 2: I know there are other players in this market too, like Jive’s Clearspace, XWiki, BlueKiwi, MyWorkLight – even Lotus Connections might stand the test and integrates well (I don’t have to link the IBM guys – do I?).

What’s wrong with current corporate systems?

Nice rhetorical question in this interview with Ross Mayfield in CIO, nothing new for people into enterprise social software, but I like how Ross draws the field, my markups:

Mayfield: The way organizations adapt, survive and be productive is through the social interaction that happens outside the lines that we draw by hierarchy, process and organizational structure. The first form of social software to really take off to facilitate these discussions was email. The “reply all” feature was fantastic for forming groups, communicating, and getting some things done, but it’s also been stretched thin. Because of its popularity, we use it for everything. It creates what the Gartner Group calls occupational spam, and it makes up 30 percent of email. It’s when you CC, blind CC, or reply to all. Consistently, with our customer base, that 30 percent moves over to the wiki. So e-mail is a big part of it.

Traditional enterprise software is the other. If you think about traditional enterprise software, it’s top down, highly structured, and is made for rigid business rules. The entire goal is automation of business process to drive down cost. But the net result is someone goes and buys SAP, implements the same 15,000 business processes that it comes with, and all they’re doing is paying the ante to stay in the round. They don’t gain any competitive advantage. Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process. That’s what they’re doing in their [e-mail] inbox for four hours a day. Email has become the great exception handler.

Unfortunately, what it means is all the learning disappears because it’s hidden away in people’s inbox. It’s not searchable and discoverable or findable through tags and folksonomies. And so just simply moving some of that exception handling into a more transparent, searchable, and discoverable Wiki means that you have the opportunity to gain a different kind of competitive advantage. John Seely Brown and John Hagel wrote this book recently called The Only Sustainable Edge , and there they suggest that the greatest source of sustainable innovation is how you’re handling these exceptions to business process.

So at the edge of your organization, there are all kinds of exceptions that are happening. If you handle them appropriately, you can adapt to where the market is going. You can adapt to the problems you have in your existing structures. So I’ve always looked at it as we’re doing the other half of enterprise software: making this unstructured information transparent.

Interview with Ross Mayfield

Paul Dunay interviewed Ross Mayfield on wikis and published it as a podcast. You can’t download the audio file, but you can listen to it via a flash player.

I like this way of presentation, as it shows the cut marks of the recording and allows to skip forward and backward in the TOC:

Start podcast 00:00:00
Enterprise 2.0 defined 00:00:28
First Enterprise 2.0 deployment 00:02:07
How to Implement a Wiki 00:02:46
SAP’s Wiki implementaion 00:04:55
External marketing Wiki example 00:06:06
The Best Way to rollout a Wiki 00:08:13
How to build Adoption of your Wiki 00:11:55
What is the typical first project to start a Wiki? 00:14:59
How to get more info on Wikis 00:15:48

This interview touches also a lot of stuff that I layed out in my presentation here. No wonder I recommend both to anyone interested in social software for the enterprise …

The Next Wave of Enterprise 2.0

M.R. Rangaswami, of Sand Hill Group interviews
Web 2.0 pioneer Ross Mayfield of SocialText on what’s going to define the next few years in social software for business.

Enterprise 2.0 technology is revolutionizing the knowledge workplace. And despite debates over the name and definition, experts agree that the core concepts and business-driving power of Enterprise 2.0 will only continue to grow.

Low-cost (and stealth) Business Intelligence

Dennis Howlett on knowledge management acceptance and more:

It seems to me the obvious answer comes from using bottom up enterprise strength blog/wiki/RSS/search like say Blogtronix. SocialText, Attensa and Google. That could be a useful combination to kick start the discovery process at ridiculously low per user cost.

[…] These tools are certainly easing the information blockage overflow/problem but I accept there’s still more that can be done. The good news is that these tools deliver incremental value I can see will carry through into the future.