Google Buzz: Anwendungsszenario für Intranet-Kommunikation

betrachten wir Google Buzz im Hinblick auf die Integration mit dem Maildienst genauer und beziehen das Gebilde auf bisherige Kommunikationssysteme in Unternehmen. Vorab: Ich denke, dass an Google Buzz angelehnte Systeme die Gruppenkommunikation inhouse erheblich befördern können.

Die zwei dominierenden Kommunikationssysteme in modernen Unternehmen sind:

1. Mailing – hier dominieren MS Exchange und Lotus Notes den Markt
Mailsysteme, wie sie uns heute bekannt sind, wurden zunehmend in den frühen 90er Jahren installiert

2. Instant Messaging – auch hier dominieren Lösungen von Microsoft und IBM
Instant Messaging wurde spürbar zunehmend ab Mitte der 90er Jahre in den Unternehmen eingesetzt und mit den Mailsystemen integriert. So bietet Lotus Notes einen Presence-Service im Mailbasket an, um dem Empfänger anzuzeigen, ob der Absender online via IM verfügbar wäre. Ich möchte betonen, dass die Integration beider Systeme ein entscheidendes Merkmal ist! Was nicht unwichtig für den weiteren Gedankengang ist.

Weitere Kommunikationssysteme, wie z.B. Blogs, Twitter ähnliche Tools, Foren oder gar Social Networks haben sich noch nicht als Standards etabliert, verbreiten sich aber auch nicht in dem Tempo wie Mailing und IM zu ihren frühen Anfangszeiten.

Kommen wir nun zu Googles Lösung. Was ließe sich damit anfangen? Man kann es ohne Weiteres als eine erneute Erweiterung der dominierenden Mail-Lösung betrachten. IM hat Mailing erweitert. An Google Buzz angelehnte Systeme könnte dies nochmals gelingen!

Google hatte erst kürzlich Google Wave als Protokoll veröffentlich, hier ist es noch viel zu früh, um Ableitungen treffen zu können, ob es sich in Intranets als ergänzendes Kommunikationssystem etablieren wird.

Anders sieht es bei Google Buzz aus. Es ist ein Dienst, der schon alleine aufgrund seiner Nähe zum Mailing klare Anwendungsszenarien aufzeigt. Google Buzz erweitert die Möglichkeiten bisheriger Instant Messaging Systeme um eine Socializing Komponente. Anders gesagt, es erweitert die Kommunikation auf Basis von IM um eine neuartigere Gruppenkommunikationskomponente, die es in sich hat.

Schauen wir uns ein Szenario an, das heute schon als klassisch zu bezeichnen ist:
Mitarbeiter A liest eine Mail von B und hat Fragen. Er sieht, dass Mitarbeiter B online ist und nimmt via IM Kontakt mit ihm auf. Es ergibt sich, dass man Mitarbeiter C und D hinzuziehen muss. Auch das ist heute via IM Systemen kein großes Thema. Sollte es sich allerdings um ein Problem handeln, das nicht klar umrissen ist, kann es sehr effizient sein, stattdessen einen public chat Kanal aufzumachen. Bedingung: Es bedarf erstens eines Follower-Systems und zweitens einem daraus abzuleitenden Buzz-System, das die neuen Gespräche nach oben spült, um eine vernetzte Kommunikation zu fördern. So können sich Mitarbeiter bei Bedarf einklinken, wo sie dazu vorher – in der besteheden Systemlandschaft- keine Chance hatten, wenn sie der Initiator nicht aktiv von sich aus hinzuziehen würde. Exakt dies bietet GBuzz. Das relativ einfach unter Zuhilfenahme der bestehenden Adressbücher und IM-Systeme anzuflantschen wäre, ohne ein eigenes Komplettsystem bauen zu müssen.

Zusammengefasst: Es ist unabdingbar, dieses System ins bestehende Mail- und IM Set zu implementieren. Ebenso ist es notwendig, Chinese Walls zu beachten, was aber schon von Haus aus die bestehenden Kommunikationssysteme und vorliegenden Rechteszenarien (wer darf was lesen) mit sich bringen. Doch gerade im Bereich Rechte stößt man mit dem GBuzz System auf zunächst scheinbar komplexere Probleme:

Das Follower-Gebilde (wer lauscht wem) von GBuzz leitet sich beim Start aus der Interaktionshäufigkeit der Mitarbeiter via Mailing ab. Insofern wäre es nicht unbedingt allzu schwer, einen Kickstart hinzubekommen, ohne großen Projektmarketing-Bemühungen. Man könnte es fast schon als Instant Forum Lösung verkaufen, die die Welten Mailing und IM miteinander verbindet. Und als herausragendes Merkmal eine Gruppenkommunikation innerhalb des Hauses extrem gut fördert. Ohne, dass man einem Overflow erliegen muss, da jeder Mitarbeiter auf Basis seines Followersystems den vernetzten Informationsstrom selbst steuern kann (GBuzz-Funktionen dahinter: „Anzahl Follower“, „Muting“, „Commenting“, „Like“). Jetzt kommen wir zu dem Rechteproblem: Angesichts der vernetzten Kommunikation ist es notwendig zu berücksichtigen, wem bestimmte Informationen nicht mehr angezeigt werden. So könnte ein Vertriebsmitarbeiter einen Informationsstrom anstoßen, der Mitarbeiter anderer Bereiche erreicht, die diese Information nicht lesen dürften, doch auf Basis der Followersystematik diese bekommen würden. Die Lösung ist aber nicht wirklich schwer: Man zieht Mauern über Gruppenzuordnungen hoch. Problem gelöst! Neues Problem geschaffen: Beim Anstoßen eines „Buzzes“ muss der Mitarbeiter von vornherein die Gruppen ausschließen, die diese Information nicht sehen dürfen! Lösbar, aber nicht ganz problemfrei. Was aber alle Systeme mit sich bringen, die von Haus aus eher offener gestaltet sind, weniger bidirektional.

Ich wünsche den vielen Systemanbietern und inhouse Zuständigen viel Spaß beim Ausbaldowern, ich denke, es lohnt sich!