Groupware vs. Enterprise 2.0

August 19, 2007 um 11:13 am | Veröffentlicht in Enterprise 2.0, research | 1 Kommentar

Ich mache mir gerade ein paar Gedanken zu den Unterschieden von Social Software im Unternehmen und Groupware. Leider fehlt mir momentan die Zeit, das alles „high level“ niederzuschreiben. Deswegen stelle ich das „work in process“ hier in den Blog. Im idealen Falle bekomme ich noch ein wenig Feedback von meinen geschätzten Lesern 🙂 und greife das Ganze demnächst nochmal auf um es richtig auszuformulieren.
——————————————-

  • Die Unterschiede zwischen Social Software und Groupware (am Beispiel von Weblogs und Wikis)
  • Abgesehen vom Namen (Groupware – Software die,…whatever (Kollaboration,…)… in Gruppen unterstützt) lassen sich die beiden Gattungen Social Software und Groupware in vielen weiteren Punkten differenzieren.

    Gruppenorientierte Kommunikation vs. Persönlichkeitszentrierte Kommunikation
    Während bisher in Groupware eine feste Struktur bestand, welche Information wo einzutragen war, bin ich in meinem Blog, mein eigener Herr. Ich schreibe „worüber, wann, so viel / so oft und wie“ ich will. Dasselbe gilt für ein Wiki. Es ist jeweils klar ersichtlich, dass die Beiträge von mir stammen und ein anderer kann mich aufgrund der Beiträge kontaktieren etc…
    Dabei ist es egal ob ich für 10 oder 1000 Leute blogge oder etwas im Wiki schreibe. Ich schreibe ja auch (oder überwiegend) für mich bzw. weil ich finde, dass etwas geschrieben (oder geändert) werden muss. Niemand hat mir gesagt, dass ich diesen Beitrag leisten soll. Und niemand würde mich für das Fehlen dieses Beitrags verantwortlich machen.

    Top down vs. Bottom up („Erzwungene“ Organisation vs. Freiwillige Vernetzung / „Grüne Wiese“ vs. Web)
    Ein Erfolgsgeheimnis von Social Software ist, dass sich aufgrund der sozialen Komponente Strukturen oftmals erst im Nachhinein ergeben, die man a priori nicht erahnen konnte.
    Social Software konnte sich (bei Mio Nutzern) im Web durchsetzen. Oftmals war den Initiatoren gar nicht klar, wo die Erfolgsfaktoren lagen, man hat positive Faktoren verstärkt und negative ausgeschalten. Das Vorgehen war also eher deduktiv denn induktiv.
    Das Ziel wird folglich sein die Module die sich im www durchsetzen (bei Bedarf) in einem Unternehmen umzusetzen und dabei an die Zwänge, die sich mit dem Einsatz im UN ergeben, zu berücksichtigen. Dabei gibt es eigentlich (bis auf ein föderiertes Identitätsmanagement) keine großen Anforderungen. Was funktioniert kann übernommen werden. Eigentlich handelt es sich dabei auch um eine Art Crowdsourcing im übertragenen Sinne. Erst wenn Mio Nutzer ihr positives Feedback (durch die Nutzung) gegeben haben, wird das Konzept ins UN übernommen.

    Kleine bis mittlere Personenanzahl vs. sehr viele Personen (und die unbegrenzte Zeitdauer)
    Groupware war nie für eine größere Personenzahl gedacht und viele Funktionen eines Blog oder Wiki sind in Groupware auch nicht umgesetzt. Groupware sollte die Zusammenarbeit in einer Gruppe (mit einem bestimmten Ziel) und meist für eine konkrete Projektdauer unterstützen. (Ellis et al 1991: …systems that support groups of people engaged in a common task (or goal)…).
    Wie sollte z.B. eine Organisation wie die Bundeswehr auf lange Zeit an einem „kollektiven Gedächtnis“ schreiben. Wie sollte ein CEO seine tausend Mitarbeitern „auf dem Laufenden halten“ und gleichzeitig offen für Feedback bleiben? Für letztgenanntes bietet ein Blog Möglichkeiten, die es vorher einfach nicht gab. Weil dies nicht den Bedürfnissen eines Projektteams entsprach.

    Administratorenkontrolle vs. Selbsterfundene Konventionen (co-evolution)
    Was bei SoSo oftmals nicht a priori klar definiert wurde, war die Administration. Warum auch – die Software ist sozial. 😉 Wenn man sich an die einfachen Regeln hält, die auch im täglichen Umgang mit anderen (implizit) existieren kann man nicht viel falsch machen.

    to be continued….
    ———————-

    Bloggen auf WordPress.com.
    Entries und Kommentare feeds.