Ideale Information? Verteilt, zentralisiert und sozial

1265460857|%d.%m.%Y

Nicht wenige verbringen den halben Berufsalltag damit, mittels E-Mail zu organisieren, was zu tun ist. Das, was eigentlich zu tun ist, bleibt dabei auf der Strecke und muss nach Feierabend getan werden. Die freie Zeit wird dadurch immer knapper, und manchmal endet alles in einem Burnout-Syndrom. Der Rat, einfach zu arbeiten und nur noch einmal täglich E-Mails zu checken, geht leider an der Realität vorbei, denn die Arbeit könnte dann schnell vergeblich sein, und das Arbeitsverhältnis dahin. Gibt es also andere Lösungen?

Die Probleme vom Medium E-Mail sind bekannt. Es erschafft einen mehr oder weniger chaotischen Peer-to-peer-Verkehr in einem Umfeld, an dem meist mehrere Benutzer beteiligt sind.

Verteilter Informationsfluss

verteilter-workflow.png
Typischer E-Mail-Workflow: manche sind besser informiert als andere, und keiner bekommt alles mit

Verschärfend kommt hinzu, dass dieser Verkehr asynchron abläuft, über Stunden oder Tage hinweg. Und immer nur sind einzelne Mails sichtbar, nie das „große Ganze“. Auch Arbeitsdokumente werden massenweise auf diesem Weg übertragen, als Attachment hier, als weitergeleitetes Attachment dort. Betrachtet man das so von außen, kommt sich vor wie in Platons Höhlengleichnis und hat das starke Bedürfnis, den armen Betroffenen endlich das Sonnenlicht zu zeigen.

Doch das ist meist gar nicht nötig. Die Betroffenen wissen selbst um die Mängel. Sie freuen sich deshalb immer darauf, wenn mal wieder ein Meeting stattfindet. Eine Veranstaltung, an der alle Beteiligten gleichzeitig teilnehmen, und in deren Verlauf binnen zwei oder drei Stunden meist mehr geklärt werden kann als in zwei oder drei Arbeitswochen E-Mail-Pflege. Beim anschließenden gemeinsamen Mittagessen wird dann meist noch abfällig über die Mailings hergezogen, und wie überlegen doch die echte Kommunikation der elektronischen sei.

Darin liegt allerdings ein Denkfehler. Denn das Problem ist nicht das Elektronische an der Kommunikation. Das Problem ist die asynchrone, chaotische Peer-to-peer-Charakteristik der E-Mail-Kommunikation. Dabei ist eigentlich alles ganz einfach. Obiges Schaubild schreit geradezu nach Zentralisierung.

Zentralisierter Informationsfluss

zentraler-workflow.png
Nenen wir ihn den Ideal-Workflow: jeder nimmt teil, und alle bekommen alles mit

Der Ideal-Workflow benötigt also, wie leicht ersichtlich ist, eine brauchbare Client-Server-Lösung, einen zentralen Informationspool, auf den alle Beteiligten zugreifen können, und zu dem alle Beteiligten beitragen können. Also letztlich das Gleiche, was bei einem Meeting geschieht. Jeder kann alles hören, was gesagt wird, und jeder kann selber etwas sagen. Das Ergebnis-Protokoll erhalten alle Beteiligten, und alle haben damit eine gemeinsame Basis.

Nun ist der oben dargestellte Ideal-Workflow stark vereinfachend und idealisierend. Zum einen findet das Beitragen und Abrufen von Information an einem zentralen Informationspool anders als ein Meeting nicht synchron statt, sondern eher wie E-Mail-Verkehr asynchron. Zum anderen könnte das Volumen der gesamten verfügbaren Information einzelne Benutzer überfordern. Es könnte infolge des Information-Overkill sogar zu energieraubendem Kompetenzgerangel kommen, da nun jeder das große Ganze sieht (oder zu überblicken vermeint).

Ganz unproblematisch ist der propagierte Ideal-Workflow also nicht. Für einige, meist kleinere Teams und Projekte mag er ausreichend sein. In Bezug auf komplexere Projekte und Involvierungsgrade von Beteiligten kommen weiterführende Überlegungen dagegen früher oder später auf eine gemischte Lösung.

Verteilter zentralisierter Informationsfluss

verteilter-zentraler-workflow.png
Idealer Workflow mit Realitätssinn: ein Teil für alle, andere Teile für bestimmte Beteiligte, aber immer zentral

In diesem Konzept gibt es wie im Ideal-Workflow einen zentralen Informationspool. Dieser ist jedoch kleiner und enthält nur Informationen, die wirklich von allen Beteiligten benötigt werden. Außerdem enthält er Links zu weiteren Informationspools mit spezielleren Informationen. Diese Spezial-Informationspools sind nur für jeweils Beteiligte von Interesse. Wichtiges Merkmal: auch die „Satelliten-Pools“ sind aus Sicht der daran Beteiligten zentrale Informationspools, zu denen alle Beteiligten beitragen können, und deren Inhalte alle Beteiligten abrufen können. Ergebnisse aus den Satelliten-Pools können wiederum in den zentralen Informationspool einfließen.

Und die Software-Lösung dafür?

Wie E-Mail funktioniert und was man dafür braucht, weiß jeder. Doch wenn man Entscheider in Unternehmen bis hierhin lesen lassen und fragen würde, mit welchen Software-Lösungen man einen verteilten zentralen Informationsfluss realisieren kann, werden die meisten mit den Schultern zucken und außerdem an ihr schmales Budget denken.

Der reine Informationsfluss lässt sich mit Hilfe von Wikis realisieren. Ein zentrales Wiki für alle Beteiligten, und Satelliten-Wikis, die über das zentrale Wiki erreichbar sind, für bestimmte Beteiligte und Teilbereiche. Der Wiki-Einsatz als E-Mail-Alternative wird ja auch durchaus häufig propagiert, wie etwa hier und dort. Es gibt auch längst Wikis, die sehr intuitiv zu bedienen sind, inklusive Wysiwyg-Bearbeitung und der Möglichkeit, Inhalte aller Art einzubinden.

Allerdings haben reine Wikis auch Nachteile. Sie erfordern von den Beteiligten nicht nur eine gewisse Einarbeitungszeit, sondern auch eine andere Art, Inhalte beizutragen. Das Gefühl zu kommunizieren geht in Wikis leicht verloren. Und das könnte sich letztlich demotivierend auswirken. Geeigneter sind deshalb möglicherweise Lösungen, die das einfache, direkte Beitragen von zentralen Inhalten um Elemente direkter Kommunikation erweitern. In genau diese Richtung zielt Google Wave. Allerdings wird sich erst noch herausstellen müssen, ob dieses Gesamtkunstwerk aus Instant Messenging, Wiki und Einbindung intelligenter Gadgets wirklich alltagstauglich ist. Soll es für konkrete Projektarbeit eingesetzt werden, erfordert Wave anders als E-Mail und ähnlich wie Wikis konzeptionelle Überlegungen. Welche Waves sollen für welchen Zweck eingerichtet werden? Welche Beteiligten sollen in welche Wave involviert werden? Eines ist jedenfalls sicher: wird Wave ohne Plan und Disziplin genutzt, ist es am Ende noch wesentlich unübersichtlicher als E-Mail.

Eine einfachere, aber auch intuitivere Lösung könnte Etherpad sein. Leider wurde die Etherpad-Hosting-Plattform von Google gekauft und wird wohl einfach in Wave einfließen. Allerdings versprechen die Anbieter, Etherpad künftig als OpenSource-Variante weiterzuentwickeln. Etherpad ist nicht so mit Funktionen überladen wie Wave, kombiniert aber das gemeinsame Erarbeiten eines Dokuments mit Chat-Funktionalität in einer schlichten Oberfläche. Funktionen wie das Anhängen relevanter Dateien oder das Einbinden intelligenter Gadgets fehlen allerdings.

Daneben gibt es diverse Tools, die kollaboratives Schreiben ermöglichen, im weiter gefassten Sinne also client-server-basiertes, gemeinsames Arbeiten an Dokumenten in Echtzeit. Diese Software-Gattung geht schon einen Schritt weiter. Unsere bisherigen Überlegungen drehten sich nämlich nur um Mittel, die den Informationsfluss unter Projektbeteiligten besser fördern als E-Mail. Es ging nicht darum, diese Mittel zum direkten gemeinsamen Arbeiten am Endprodukt zu nutzen. Wenn das Endprodukt einer gemeinsamen Arbeit jedoch aus Bits und Bytes besteht, egal ob Konstruktionsplan, Software, Storyboard oder Manuskript, dann kann das direkte gemeinsame Bearbeiten der Dokumente erwägenswert sein. Für viele Beteiligte ist diese Art zu arbeiten allerdings sehr ungewohnt, und wenn sich bei Beteiligten das Gefühl einstellt, sich ständig beobachtet zu fühlen, dann ist der Einsatz solcher Tools sogar kontraproduktiv.

Noch sehr unterbelichtet sind die Möglichkeiten, die Google Sites bietet. Es handelt sich um ein sehr intuitiv bedienbares Wiki, das eine Reihe von Funktionen mitbringt, die in klassischen Wikis fehlen. So etwa die Möglichkeit, beliebige Dateien an Wiki-Seiten als Attachment anzuhängen, oder die Möglichkeit, beliebige Seiten mit Kommentarfunktionalität auszustatten, um so über Inhalte zu diskutieren. Eine Seite in Google Sites kann eine normale Seite mit Text, Grafik usw. sein. Daneben sind aber auch weitere Seitentypen möglich, beispielsweise für Listen, für die Ablage von Dateien oder für blog-artige, chronologisch sortierte Mitteilungen. Die Möglichkeit Gagdets von Google und anderen Anbietern zu integrieren, erlaubt das direkte Einbinden von Kalenderinhalten, Aufgabenplanern und anderen Tools ins Wiki. Mit etwas Phantasie lässt sich eine Google Site so als ein Informations- und Kommunikationsort modellieren, der für viele Anwender möglicherweise geeigneter ist als Google Wave.

Größere Unternehmen lassen sich allerdings (noch) ungern von fremd-gehosteten Lösungen überzeugen. Klassische Software-Anbieter wie Microsoft oder IBM werden bevorzugt. Der Artikel Collaboration-Software im Vergleich aus der Computerwoche vom Juni 2009 beleuchtet einige der in Frage kommenden Software-Lösungen, wie etwa den Microsoft Office SharePoint Server 2007 oder Lotus Quickr.

Es ist jedenfalls an der Zeit, in Unternehmen und Organisationen Alternativen zur E-Mail ernsthaft zu implementieren. Sonst läuft diese (also die Zeit) am Ende immer mehr davon, und der Burnout trifft am Ende nicht nur Einzelpersonen, sondern das Unternehmen oder die Organisation als Ganzes.

button-compact-static-100x17.png

Kommentare

Neuen Kommentar hinzufügen
oder Anmelden als Wikidot User
(wird nicht veröffentlicht)
- +
Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License