Aggregation, syndication and the delicacies of smart knowledge worker workflows ™

Now this has evolved into one hot topic, huh? And so it’s about time to sort, aggregate and systematize my thoughts on the smart knowledge workers workplace and lifestream configuration.

Well, I was blogging about my personal workspace before, and that post and this one have blurring boundaries. See there for my general setup, my choice of browsers et al. Here it’s about processes and ways to channel and refine content.

I got triggered by various posts and inspirations – one being recent posts by Robert Scoble (on what it needs for better content curation), Louis Gray (on how he proceeds with sharing content), Steph Booth (on why she likes Tumblr and how it fits into her lifestream), Andi Gohr (on his lifestream configuration) and Mac Slocum (on how buzz can be perceived as hybrid blogging). Other inspirations include people asking me on buzz how I share links (Christian, yes!), why I continue to use and enjoy buzz (DT, yes!), and how I refine the contents I share.

All this made me compile this post to share some of the tweaks and lifehacks I have chosen to tailor content I share, how I get a grip on the topics myriad of people whose work I am following et al. Basically most of these tweaks are in place to avoid needless redundancy, ie. channels get selected depending upon content (and audience) – hoping that the stuff I share to different platforms will be interesting (or valuable at times).

So here’s the basic setup:

Complicated infographic, yes. So let me explain: Basically I am depicted in the middle (ie. the neat frogpond logo) – and I am busy filtering, refining and curating content (from the top down to the bottom).

Most of the things I am learning on the web reach me via RSS – and in my reader of choice, the Google Reader. Currently I am subscribed to +1000 feeds, including podcasts, Tumblr feeds, a ton of blog feeds, searches and everything – all sorted into folders (yes, these folders have varying importance to me, you sure believe me when I say that the _fun folder is less important and funny than the _e20 folder, will you?). Moreover the Google Reader is the focal point for all the recommendations I am subscribed to, ie. the Google Reader items my buzz contacts and friends are sharing (top left). This is the lions share – and you will understand that I basically live and breathe by RSS.

Other sources of inspiration and content include my buzz lifestream (now following 400 people) and my twitter lifestream (following roundabout 1600) – and the usual suspects, ie. mail, skype, IRC, Google Talk, telcos, talking to actual people, working with customers et al.

All of this – remixed, refined and reworked – gets pushed out via various channels again, the easiest being my delicious bookmarks (bottom right). I am bookmarking and tagging a lot – yet, I must confess that not everything I hamster is public. As of today roundabout 75% of my bookmarks are marked private – I bookmark them so that I alone can find them again, come time. The 25% of my delicious bookmarks that I think are interesting to share in public get spliced into the main feed of frogpond by Feedburner.

Then I am blogging – in WordPress blogs here and there. Mostly I am pretty happy with generic posting, but sometimes it’s more convenient via Posterous, ie. via frogpond.posterous.com. This Posterous blog also allows for manual autoposting to my tumblr, a range of self-hosted internal collaboration wordpress blogs (my interpretations of a linkblog and an aggregation site), to Facebook, to Friendfeed and even to delicious. Heck, I could even tweet directly from Posterous …

All of the posts that make it to my regular blogs are syndicated to Google buzz – which in turn is feeding Twitter (via the Feedburner socialize solution, employing Pubsubhubbub) and Facebook (via Twitterfeed). Notice that I only feed native and generic buzz to Facebook, no @-Replies, no Retweeting, no redundancy, no nothing. And no, it’s not because I like Facebook and I want to keep it clean and easy. It’s more the other way round – if you want to interact with me you better use the spaces I engage in, ie. buzz and to a lesser extent Twitter. No point in aggregating my replies into Facebook when nobody there knows why I am replying ..

Ok, onto buzz – you notice it’s bigger than the rest (hey, almost as huge as Google Reader …). This is for a reason: I just love the platform. And I use it daily. Via mobile access or via old-school generic usage. Daily.

Into buzz there goes
a) generic buzzes – say I want to macroblog a link or an image or, err a tweet
b) my GReader recommendations (GReader is linked with buzz, ie. every time I click on “recommend” in Reader the item gets added to my lifestream)
c) all content I share via my secondary Posterous-Blog buzzpond (this is directly linked to buzz, while frogpond.posterous.com ain’t linked).
d) content from my blogs
e) all mobile (picture) buzzing and all public Flickr additions ;)

Now I should elaborate as to why buzz has hit a nerve with me, but I will keep this for another post …

5. April 2010 | Martin Koser | Tags: , , | 30 Comments »

Thoughts on using Google Buzz for collaboration and knowledge work

Ah, all the buzz about Google Buzz. Everybody is kicking the tires, experimenting and playfully learning. This is fun – at least for geeks and I can say that the overall experience has been pretty cool. It’s slick, has seen some very good ideas implemented and integrates nicely with my (private) Google account. Some feature requests and some questions still remain, and right – mine are not so much focussed on the consumer experience side but rather on the side of collaboration and knowledge worker’s processes. So no thoughts on mobile usage of Buzz now, nor about usability, complexity or design and only a smallish thought on adoption near the end of this post.

One – I am really waiting for the Buzz to arrive in my Google Apps domain (mail to frogpond adresses is handled by Google Mail, yes, there are a lot reasons for putting mail and apps into the cloud) – and the official announcement wasn’t clear I think:

We also plan to make Google Buzz available to businesses and schools using Google Apps, with added features for sharing within organizations.

Hmm, does this include the standard edition of Apps or is this planned for Premium alone?

Two – let’s applaud Google for relying on open communication standards for its social web endeavours – it’s playing, integrating and – as Chris Messina writes here – leveraging the fabric of the open web. Of course this is helping Google but it’s also helping us, and it’s a wildly disruptive move too (hey, everything that uses Pubsubhubbub is a friend of mine …).

Three – Right, Buzz both validates and marginalizes Friendfeed (I so dig the tag line “FriendFeed Reborn. On Growth Hormone” at Techcrunch). Indeed, the idea of an aggregated life-workstream was just too good to go unsatisfied – and I am now waiting for rooms and/or persistent searches to find their ways into Buzz.

Knowledge workers they need to arrange their groups and channels of communication, finding information from sources that are contextually relevant (and then act upon them, sometimes this may just mean more information filtering, analysis and refining et al.). All in all the knowledge workers workplace can need some more nifty tools that improve productivity – and yes, this is a big topic in Vulcan too everywhere.

Four – Commencing on the context topic of three, what Buzz already has done for me is a boosting of the volume (and so far the usefulness) of Google Reader recommendations. I really like the pre-filtered stuff that gets channeled to me through my social network (and I hope they enjoy the stuff I am recommending and bookmarking on a daily basis).

And now there’s more of it – and it’s easy to “buzzify content” that may start a discussion on Buzz. So I guess we need some more Backtype wizardry to include the Buzz discourse on blogs. That said – we’re still missing threaded conversation, individual favoriting of comments et al. in Buzz. Until that arrives I would rather have the conversation and discourse in here, yet I am not sure how this will work out in the end. But yes, I see and I like that Buzz will allow for more finetuning, filtering and finding stuff that interests me.

Let’s assume then that the adoption rolls in the enterprise sphere too? That’s asking for much now (and let’s not forget that these are beta status thougts …). One reason is that Google is not exactly in the position to enter the large enterprises market, even taking into account the considerable amount of consumerization of corporate IT and collaboration instruments. But I am sure that collaboration systems that merge IM, mail, wiki style collaborative editing, content sharing and communication will succeed in the enterprise too.

So yes, I think they can mount the 9x challenge – Susan asked here whether Buzz can overcome Andrew McAfee’s famous test – and I commented that it’s the integration with Google Mail that helps Buzz access a huge initial user base and network, of which:

[...] some may use it at times, even when it’s not 9 times better than the other ways we communicate

From this initial user base I guess it’s a downhill battle …

So yes, and to sum it up – for now Buzz may be immature, but it has lots of promise to change the way people collaborate and communicate.

PS. I know this could as well been a BMID post – as Buzz pondering touches and meanders around the cultures of innovation, the nerve and resilience to pull through with your innovation and ideas (some have fears Google may not), all in all the excitement and the wonders of technology innovation. And it’s relevant from a business model innovation perspective too, I feel a bit so …

11. February 2010 | Martin Koser | Tags: , , , , , | 12 Comments »

Why is Google Wave a tsunami?

wavelogoWhy is Google Wave important? Well, the toys of today are the tools of tomorrow, a compelling keynote for a developer conference is cool and all, but there’s more on the upside:

  • Google Wave is poised to reshape (rewires I say) the nature of communication (yes, more face-to-face real-timelineness communication), improving the web experience. We probably need to experience and use it a while to understand its potentials completely …

- A wave is equal parts conversation and document. People can communicate and work together with richly formatted text, photos, videos, maps, and more.
- A wave is shared. Any participant can reply anywhere in the message, edit the content and add participants at any point in the process. Then playback lets anyone rewind the wave to see who said what and when.
- A wave is live. With live transmission as you type, participants on a wave can have faster conversations, see edits and interact with extensions in real-time.

And as we’re moving onto more real-timeness and collaboration already (think Friendfeed lifestreams, real social bookmarking and annotation, social news and more), this is much more than another Google service:

  • Yes, it’s a promising product, framework and protocol.
  • Yes, it’s got an API which is devised to allow “developers to embed waves in other web services and to build extensions that work inside waves”.  With HMTL 5 and a supportive browser we get an app that is part wiki, part chat, part forum, part collaborative office and document (nah, content) sharing tool and part email. We get multi-user real time editing – be it in uploaded photos, videos or other stuff (alas, you can’t edit the photo or the video but you can collaboratively tag the uploaded files). It’s possible to play-back the history of the document to see how it evolved (think wiki page history on a ton of steroids).
  • Yes, the platform will be open-sourced, it will be able to run on any server, so it won’t belong to Google. It’s a standard thing so whoever is hosting waves can build no walled garden (you listen Facebook, do you?) but must ensure interoperability (yes, like with plain old mail). One step closer to living in the cloud of distributed apps and data. And it’s playing along the lines of integration and adaptivity … so I can’t wait to put this on my own servers

At last, one more thing, something that explains why Google is such a remarkable company – it’s the story behind Wave. Starting from the question “Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum? How simple could we make it?” they have achieved a lot. And Google’s introductory blog post has the innovation story, ie. why it must have been Google to say yes to this idea and on the early days of Wave (more on Google innovation culture, ie. a company whose unique culture shows through in small ways):

When Lars Rasmussen first floated the idea, Google co-founder Sergey Brin wasn’t impressed. “He came to me and he said ‘This may sound kinda crazy, but we’re going to reinvent communication and we just need a bunch of engineers to go of to Australia for a while and we’ll get back to you after a couple of years,’” Brin remembers. “It was not a very compelling proposal.”

More wave information at the usual places, like Techcrunch, Tim O’Reilly (Open Source, Open Protocol, and Federated Wave Clouds), Forrester, Mashable

And yes, you can sign up for Google Wave updates

1. June 2009 | Martin Koser | Tags: , , , | 20 Comments »

Upcoming part 4: do it.konferenz am 13. und 14. Oktober 2008

Anfang nächster Woche findet die do it.Konferenz 2008 in der Neuen Messe Stuttgart statt. Bis einschließlich morgen ist noch die Anmeldung möglich (Disclosure: Ich werde auf Einladung der MFG dabeisein – vielen Dank dafür!)

Die Veranstaltung ist Gipfeltreffen, Innovationsschnittstelle, Talent- und Networkingplattform rund um Kreativwirtschaft, Informationstechnologie und wissensbasierte Anwenderbranchen..

In 4 eigenständigen Fachkongressen bieten über 100 Experten aus Wissenschaft und Praxis ein breites Spektrum an Informationen über verschiedene Lösungen, aktuelle Entwicklungen und die wichtigsten IT-Trends der nächsten Jahre. Experten und Entscheider diskutieren, wie Unternehmen der Zukunft aussehen und Medien und Informationstechnologie unsere Wirtschaft und Gesellschaft verändern werden.

Auf der begleitenden Fachausstellung präsentieren sich innovative Unternehmen, Initiativen und Institutionen aus Baden-Württemberg.

Ich selbst werde mich auf die Veranstaltungen, die im Rahmen des ebigo Mittelstandsforums stattfinden konzentrieren. Die Potenziale, die in innovativen Internet- und Softwareanwendungen wie Wikis, Weblogs, Microblogging, Social Networking, Social Bookmarking etc. gerade für KMU und Mittelstand liegen beschäftigen mich schon seit langem. Und wo besser kann man den Kontakt zur Zielgruppe suchen als auf einem solchen Kongress …

7. October 2008 | Martin Koser | Tags: , , , , | No Comments »

More coverage of the Enterprise 2.0 conference at Boston …

Stephen Collins reports on Dion Hinchcliffe’s seminar on “Implementing Enterprise 2.0: Exploring the Tools and Techniques of Emergent Change” (the state of Enterprise 2.0, the tools and platforms scene, best practices and Cutting-Edge Techniques and success stories). Most disturbing thing in my view is this one:

An interesting point is while SMBs are proving slow to adopt, large organisation are buying tools today.

Some more notes

Tools that provide high leverage value in E2.0 adoptions are key, as is efficient and effective enterprise search. The gulf between good search on the web and good search inside the wall is significant.

In the comments James Dellow notes that RSS is missing, yes I agree, RSS provides a good investment / benefit ratio (well, after people understand it, we need more explaining, showing and telling).

Obviously, Dion also talked about the importance of understanding Andrew McAfee’s thinking on Enterprise 2.0 (start with the SLATES acronym, full ack Stephen, that “Dion continues to use this set of definitions indicates their ongoing importance.”).  Stephen notes:

At it’s core, the notion of applying the “Web 2.0 effect” at work is critical:

  • globally visible (which is not everything, but everything appropriate), persistent collaboration
  • use of the tools of the Web 2.0 world
  • putting workers into the centre of the contributory world

And for some more interesting coverage see the stuff aggregated at the conference site. Like e.g. that Thomas Vanderwal talked about how to manage the flood of information via social bookmarking and advanced forms of tagging (slides found via John Eckman), btw – good writeup by Stephen:

19. June 2008 | Martin Koser | Tags: , , , | 1 Comment »

Intranet.days 2008: Muss es immer gleich Web 2.0 sein?

Next post from Intranet.days 2008 at Frankfurt: Ein Vortrag von Eckhard Oberfrank von Detecon zum Thema “Mitarbeiterbeteiligung im Intranet der Deutschen Telekom – Muss es immer gleich Web 2.0 sein?”

Kleiner Rundown zum Thema Web 2.0 – angelehnt an die Web 2.0 Meme Map von Tim O’Reilly – mit besonderem Fokus auf Folksonomies, Social Bookmarking, … und wie Social Media im Unternehmen eingeführt werden kann.

Intranet 2.0 – welche Elemente der Tim O’Reilly Definition gelten für das Intranet:
- Vision: Intranet wird eine Plattform
- Benutzer steht im Zentrum
- Erschließung der kollektiven Potenziale
- Trust the Mass – kollektives Regularium – Intranets haben aber oftmals nicht die kritische Masse (frogpond: sehe ich nicht ganz so kritisch, in Intranets kann auch mit wenigen aber interssierten und engagierten Mitarbeitern viel wertvolles entstehen – zum anderen reicht es oft aus, wie vorhin bei Leila Summas Vortrag gehört, wenn die Mitarbeiter passiv daran teilnehmen und dadurch besser informiert werden)
- Bewertungen von Informationen -> Bewertung von Personen schwierig
- Kollaborationsanstoss im Unternehmen schwierig

Captain Obvious strikes again: “Social Media for Collaboration is different from generic Social Media on the Internet.”

Einige Beobachtungen:
- RSS ist bei T-Systems anscheinend noch in der Testphase
- AJAX und Eye Candy muss im Intranet anders verstanden und eingesetzt werden – es geht nicht darum Stickyness zu haben
- AJAX und Eye Candy können aber das Intranet (und die Corporate Strategy) emotionalisieren
- Mr. Clemens blog is well accepted – employees are checking the contents, yet there aren’t too many comments until now
- internal blogs at T-Systems try to build up #authenticity, connecting to employees – while talking with authority
- es gibt auch eine nette Reihe von etablierten Kommunikationsmethoden und -instrumenten die dabei helfen können die Authentizität der “corporate message” zu erhöhen
- user generated rich content (videos) im Intranet der Telekom – über 30.000 Beiträge wurden von den Mitarbeitern im Rahmen einer iPhone-Verlosung (?) eingesendet

4. June 2008 | Martin Koser | Tags: , , , , , | 2 Comments »

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.

7. May 2008 | Martin Koser | Tags: , , , , , , , , , | 13 Comments »
« Older Entries