Mitarbeiter an der Universität von Amsterdam haben sich bereits im Jahr 2007 den Erfordernissen von Design für Social Software in einer Weise gewidmet, die mir sehr gefällt. Mit dem thematischen Hintergrund der Autoren wurde ich während meiner Ausbildung in der Wissenschafts- und Technikforschung vertraut. Dieser Hintergrund lässt sich kurz und prägnant auf den Nenner Wissensarbeit als Alltagspraxis bringen, worüber ich auch schon einmal ein Paper verfasst habe.

Die Autoren stellen neben des Aspekten Nachahmung, Identitätsbildung und Selbstaktivierung die Praxis, in diesem Fall die Aktivitäten der User als Gruppe, in den Vordergrund und möchte daraus Folgerungen für das Design von Social Software ableiten. Vielleicht verfängt sich ja etwas bei jenen von euch, die sich mit Software-Design beschäftigen. Aber auch diejenigen, die Web 2.0 zu produktiven Zwecken (z.B. in einem Unternehmen) einführen möchten, sollten hier mal genau reinschauen:

Bouman, W., Hoogenboom, T., Jansen, R., Schoondorp, M., Bruin, B. de, Huizing, A. (2007), ‘The Realm of Sociality: Notes on the Design of Social Software’, Conference Proceedings 28th Annual International Conference on Information Systems (ICIS), Montreal, Canada.

Die Autoren haben auf dieser Konferenz den ICIS 2007 Best Paper Award gewonnen. Man kann es auch hier herunterladen: http://sprouts.aisnet.org/8-1

Sozialität kann nicht designed werden, sondern nur für Sozialität

Was ist Sozialität im Kontext von Social Software? Bouman et al. gehen davon aus, dass Sozialität in vier verschiedenen Formen in Erscheinung tritt (vgl. Tab. 1):

• Netzwerk-zentrierte Sozialität
• Gemeinschaft-zentrierte Sozialität
• Objekt-zentrierte Sozialität
• System-zentrierte Sozialität

Zwischen diesen vier Weisen von Sozialität gibt es gewisse Dynamiken. Aus einem Netzwerk, in welchem Menschen mit unterschiedlichen Rollen in einer bestimmten Weise aufeinander bezogen sind (z.B. als Mitarbeiter in einem Unternehmen), bilden sich für gewöhnlich auch Gemeinschaften (Communities). D.h. das Netzwerk offizieller Arbeitsbeziehungen wird angereichert durch Beziehungen anderer Art (Freundschaft, Vertrauen, etc.).

Gerade in Bezug auf Produktentwicklung und Innovationen bilden sich Netzwerke allerdings nicht nur zwischen Personen, die durch offizielle Aufgaben miteinander verbunden sind. Sie bilden sich vielmehr durch Objekte. Das kann z.B. ein zu entwickelndes Produkt sein.

Solche Objekte binden wiederum Personen aneinander, formieren neue Beziehungen etc. Es entsteht ein System aus Objekten und Personen, Beziehungen zwischen Objekten, zwischen Personen und Objekten und Personen untereinander.

Ein anschauliches Beispiel ist das Musikportal Last.fm. Darin kann man Musik hören, sich eigene Playlisten zusammenstellen (Person-Objekt), die andere einsehen können (Person-Objekt-Person); man kann die Musik-Empfehlungen anderer lesen (ebenfalls Person-Objekt-Person), Freundschaften mit anderen schließen (Person-Person), Diskussionen über Musikstücke oder über Musiker führen (Person-Objekt-Person), etc. [meine eigene Playlist ]

Eine solche System-zentrierte Sozialität bildet nun ein sehr komplexes Netzwerk. Und sie ist diejenige, auf welche Social Software (also z.B. das Musikportal Last.fm) fokussiert ist.

Ein Design-Framework

Die Autoren stellen nun in Bezug auf das Design von Social Software die folgende Hypothese auf:

We hypothesize that, in order to create social software, a designer has to address in one way or the other all issues of enabling practice,  mimicking  reality,  building  identity  and  actualizing  self.

Praxis ermöglichen, nachgeahmte Realität, Identitätsbildung und Selbstaktivierung sind also die Schlüssel für ein adäquates Design. Um auf diese Phänomene zu kommen, greifen die Autoren tief in die Theorienkiste von Management-, Sozial- und Kommunikationswissenschaftlern des 20. Jahrhunderts. Das soll hier erst einmal ausgespart bleiben.

Wichtig ist ihnen jedenfalls, dass eine Social Software diese vier Möglichkeiten des sozialen Daseins im Web bieten muss:

• Praxis ermöglichen: Passives Rezipieren wie am Fernseher oder Radio gibt es am Computer nicht. Mit Blick auf Social Software sollte der Designer darauf achten, dass er einer sozialen Gruppe die Möglichkeit gibt, im Sinne der Gruppe aktiv zu sein. Er muss sich fragen, wie eine potentiell existierende Gruppe interagieren würde. Dies betrifft nicht nur die Produktion von User-Content, sondern im Idealfall auch die strukturelle Basis der virtuellen Umgebung; die Nutzer sollten auch auf diese Einfluss nehmen können.
• Realität nachahmen: Die Teilnahme sollte auf ähnliche oder gleiche Weise geschehen, wie wir auch in der Realität agieren: “people  actually  are more  inclined  to  use software  systems  that  resemble  their  daily  routines,  language  and  practices  than  to  adopt  whole  new concepts, interfaces and methods”. Hier schlagen die Autoren die Nutzung von Metaphern vor (später mehr dazu).
• Identitätsbildung: “A large part of this realm is concerned with the ability to show others a desired  picture  of  self,  a  version  of  one-self  that  is  goal-relevant.” Es ist also drauf zu achten, dass die Aktionen des Users eine Spur hinterlassen, die ihm eine Identität verleiht.
• Selbstaktivierung: Hiermit sind Mechanismen gemeint, die zur Selbstentwicklung beitragen – dass die Nutzung also in einen individuellen Vorteil resultiert. Lernen wäre ein solcher Vorteil (Wikipedia, last.fm), aber auch Kontakte knüpfen (Xing, Dating-Seiten).

Diese vier, für Social Software notwendige Eigenschaften, lassen sich spezifizieren. Bouman et al. tun dies, indem sie das notwendige Design von Social Software beurteilen mit Blick auf

• Kriterien, die erfüllt sein müssen,
• Prinzipien, denen die Software folgen muss,
• Parametern, mit denen die Erfordernisse verwirklicht werden können,
• Dilemmata, mit denen sich die Software-Designer auseinander setzen müssen.

In einer Kreuztabelle (vgl. Tab. 2) ergeben sich nun allerlei Informationen, die ich nicht im Einzelnen erörtern brauche. Die Autoren tun dies auf den Seiten 15-17 ihres Papers recht anschaulich.

Aber zu einigen Feldern möchte ich gerne einige Stichpunkte anführen:

ENABLING PRACTICE

• Economic Criteria: gute Usability und effektive Kommunikationsstandards
• Parameter (Practice): Räume zum Austausch, eigene Beiträge ermöglichen, Erlebnischaracter herstellen
• Dilemma: Hindernisse beim Implementieren von neuen virtuellen Austauschpraktiken (all die Probleme bei der Einführung von Web 2.0)

MIMICKING REALITY

• Empirical Criteria: Suche nach Modellen in der realen Welt
• Parameter (Metaphor): aus diesen Erfahrungen gut funktionierende, interessante Metaphern bilden, die sich in Social Software umsetzen lassen (z.B. Bewertungssysteme auf Amazon, Genre-Radio auf last.fm)
• Dilemma: Bezug zwischen realer und virtueller Welt kann verloren gehen

BUILDING IDENTITY

• Social Criteria: Vertrauen, Verbundenheit, Identifikationsmöglichkeiten und Aktivitätspfade
• Parameter (Presentation): Profilierung ermöglichen; Austauschbeziehungen ermöglichen, die  auf Personenaktivitäten zurückschließen lassen
• Dilemma: Verhindern, dass in diesem Bereich Wildwuchs entsteht (’Trolle’ kontrollieren, ‘Overorganizer’ bremsen, etc.)

ACTUALIZING SELF

• Individual Criteria: Gewinn an Wissen und Kreativität, ästhetische Befriedigung, soziale Kontakte (z.B. Liebe, Zuneigung, Bewunderung)
• Parameter (Feedback): Das Lehrreiche am Feedback, an Bewertungen und Einschätzungen anderer sollte in den Vordergrund treten können
• Dilemma: Anschlussfähigkeit muss gewährleistet sei, d.h. die Feedbackschleife sollte vom Inhalt her interessant sein, Betroffenheit auslösen, etc., sonst wirkt sie nicht

Designer von Social Software sollten sich mit all diesen Bereichen beschäftigen, weil sie alle in irgend einer Form (sozial-) funktional sind. Allerdings gibt es hierbei erhebliche Unterschiede in der Fokussierung. Im Vergleich zwischen LinkedIn (englischsprachiges Pendant zu Xing) und Frienster etwa stellen die Autoren in Bezug auf Identitätsbildung sowie Selbstaktualisierung unterschiedliche Akzente fest:

Frienster zielt eher exklusiv auf Identitätsbildung, ohne dass ein konkretes Ziel ausschlaggebend ist, während bei LinkedIn der individuelle Mehrwert im Zentrum steht. Sich auf der Webseite ein Profil geben zu können scheint hierbei die Lösung zu sein, die LinkedIn mit entsprechener Mimikry Business-Welt nachbildet (Prinzip: Visitenkarte, berufl. Werdegang, etc.). Entsprechend sind z.B. Fakes hier nicht zu tolerieren, wohin gegen sie in Friendster (Profilierung erfolgt im Kommunikationsvollzug) einen nicht unerheblichen Teil der Mitglieder ausmachen – und dem Funktionieren der Seite dabei nicht abträglich sind.

Aber auch die Praxis ist sehr unterschiedlich. Wo bei LinkedIn  die Konnektivität in einem wertvollen Netzwerk eher statisch hergestellt werden kann, spielt bei Frienster die dynamische Interaktion eine größere Rolle. LinkedIn akzentuiert also eher ein Sein, während Frienster eher das konkrete Tun fokussiert.

Aufgrund all dieser Unterschiede ergeben sich schließlich Differenzen in den Designs der beiden Portale – bei Frienster mehr dynamische, auf Kommunikation zielende Werkzeuge, bei LinkedIn mehr Möglichkeiten der formalen Präsentation, des Profilierens und des Schaffens von Vertrauen.

Diskussion: Design für Web 2.0 Systeme kommt nicht ohne sozialwissenschaftliche Expertise aus

Bisher habe ich noch kein Papier gelesen, das derart dezidiert den soziotechnischen Diskurs der letzten 30 Jahre in die Diskussion rund um Web 2.0 einwebt. Dabei kratzen die Autoren der Universität Amsterdam bisher allerdings lediglich an der Oberfläche. Es ließen sich viele Fragen an diese Thematik anschließen – etwa inwiefern die vier Domänen in Beziehung zueinander stehen, inwiefern sie sich je nach Social-Platform unterschiedlich ausbalancieren, ob sie in jedem Fall alle vier eine Rolle spielen, inwiefern sich dies ändert, wenn wir von organisationsinternen Plattformen reden. Oder aus einer mehr sozio-theoretischen Sichtweise: ob diese vier Domänen die einzigen sind, oder ob es gar zu viele sind, die Autoren mithin zu ekletizistisch argumentieren (z.B. lässt sich aus Sicht von Rational-Choice-Theoretikern die Domäne Identitätsbildung weitgehend in die Domäne Selbstaktivierung integrieren).

Diese Fragen lassen die Autoren bisher noch offen. Sie wünschen sich jedenfalls etwas mehr Demut beim Designen von Social Software:

In the end, it is not social software as such that determines its social-ness, but people choosing freely to use this software to engage in social relationships. [...]

Designers may think that they can design the mechanisms that make social software social, yet from our research we learn that they can only aim to create triggers activating mechanisms, which encourage people to explore their social environment and seek or enjoy companionship.

Ich finde, dass sie durchaus recht haben. Aus sozialwissenschaftlicher und psychologischer Sicht werden beim Software-Design bisher lediglich Usability-Konzepte systematisch behandelt – also etwa an Ausbildungsstätten gelehrt oder dazu geforscht. Dies ist in der Matrix (Tab. 2) aber nur ein Feld unter vielen anderen. Die anderen Felder sind bisher noch immer relativ unangetastet (bedenkt: das Papier wurde bereits im Jahre 2007 vorgestellt). Vereinzelt gibt es erste Ansätze zum Design für Sozialität, so z.B. Böhringer/Richter/Koch mit Blick auf Awareness.

Genauso selbstverständlich, wie angehende Städtebau-Architekten das Studienfach Stadtsoziologie belegen müssen, sollte zukünftig auch im Curriculum für die Ausbildung von Software-Designern die Thematik der Sozialität seinen Platz finden. Im Grunde lässt sich diese als eine riesige, sehr interessante Spielwiese für Interdisziplinarität auffassen.

Obwohl in dem Paper von Bouman et al. noch viele Fragen offen bleiben, kann Tabelle 2 durchaus als eine Matrix dienen zur Kreation von Portalen und zur Umsetzung von Maßnahmen rund um Enterprise 2.0 und Collaboration. Ich könnte mir vorstellen, dass sie den Hintergrund einer Blaupause darstellt, dass man, bevor man die konkrete Umsetzung plant, zunächst Sinn und Zweck der Collaboration herausarbeitet und dann die entsprechenden Trigger aus der Tabelle heraus liest bzw. sich um die jeweiligen Dilemmata Gedanken macht, bevor man mit dem Designen beginnt.

Da es uns vor allen Dingen um den Einsatz in Unternehmen und Organisationen geht, möchte ich Folgendes noch nachschieben: Alleine durch Software, sei sie auch noch so ausgeklügelt, wird Collaboration nicht gelingen. Zwar sind die hier vorgestellten Trigger sehr hilfreich. Sie sind womöglich sogar die Voraussetzung für erfolgreiche Collaboration. Dennoch sind so gut wie immer auch weitere Management-Maßnahmen erforderlich, um den Erfolg sicher zu stellen.

Für das Bundesland Baden-Württemberg gibt es nun eine in Bezug auf Branchen und Unternehmensgröße repräsentative Studie, die u.a. das Thema Nutzung von Social Software in Unternehmen thematisiert hat. Sie wurde vom Zentrum für Europäische Wirtschaftsforschung GmbH (ZEW) im Rahmen des Projekts FAZIT erstellt.  Repräsentativ heißt, dass man davon ausgehen kann, dass bei immerhin 1000 befragten Unternehmen dieser Studie die Verteilungen in etwa auch die wirkliche Verteilung (nach Unternehmensgröße und Branchenverteilung) im Bundesland Baden-Württemberg widerspiegelt.

In Bild 1 zeigt die Studie auf, dass die Verbreitung von Social Software in manchen Branchen noch weit unter 10% liegt. An diese Marke kommt (erwartungsgemäß) am ehesten noch der IT- und Mediensektor mit 9.9% heran. Interessant an dieser Grafik ist, dass der Verkehrssektor momentan noch sehr zurück liegt, aber immerhin 9,2% der befragten Unternehmen daran denken, demnächst Web 2.0 einzuführen.

Bild 2 zeigt, inwiefern Social Software überhaupt bekannt ist bzw. inwiefern sich der Bekanntheitsgrad zwischen den Jahren 2006 und 2008 geändert hat. Zitat: “Den stärksten Anstieg in ihrer Bekanntheit hat Social Software unter den technischen Dienstleistern erfahren. Ende 2008 kennen 67 Prozent dieser Unternehmen diese Art von Software, während es im Jahr 2006 erst 55 Prozent waren. Ebenfalls vergleichsweise stark angestiegen ist die Bekanntheit unter den Unternehmen des IT- und Mediensektors. Hier nahm der Bekanntheitsgrad in den vergangenen zwei Jahren um 10 Prozentpunkte von 76 auf 86 Prozent zu.”

In Bild 3 werden mögliche Einsatzbereiche von Social Software thematisiert. 50,1% der befragten Unternehmen nutzen sie zum internen Wissensaustausch, 48,5% zur Kommunikation mit Geschäftspartnern, 39,9% zur Sicherung von vorhandenem Wissen und 38,8% zum Aufbau und zur Pflege von Kundenbeziehungen.  Weniger verbreitet ist die Nutzung zur Zusammenarbeit mit Partnern in Projekten (28,9%) [wobei ich finde, dass diese Frage mit der Frage nach den Kooperationspartnern sehr eng in Verbindung steht]. Effizientere Geschäftsprozesse gestalten (26,1%) [geht meiner Ansicht nach einher mit Frage 1: interner Wissensaustausch], Anregung zur Innovation (23,8%) und Öffentlichkeitsarbeit (19,5%) markieren das Schlusslicht bei den möglichen Einsatzbereichen.

Die Ergebnisse (speziell zu Bild 1) sehen nun nicht so toll aus. Immerhin wollen 85,8% der befragten Unternehmen in den nächsten beiden Jahren keine Social Software einsetzen. Es muss aber auch gesagt werden, dass wegen der Repräsentatvität bei Unternehmensgrößenklassen (1-4, 5-19, 20-249, ab 250 Mitarbeiter) die Kleinstunternehmen sehr stark vertreten sind. Als Lutz und ich an der TU Chemnitz eine ähnliche Studie durchgeführt haben, haben wir diese Kleinstunternehmen aus eben jenem Grund nicht berücksichtigt.

Die übrigen Fragen waren auch nicht uninteressant, stehen mit Social Software allerdings nur bedingt im Zusammenhang. Der Vollständigkeit halber möchte ich sie mal noch nennen:

• Internetanwendungen in baden-württembergischen Unternehmen
• Anbindung ans Internet
• Intranet und Homepage
• Nutzung von Voice over IP (VoIP)
• Kooperationsbereiche
• Kooperationsbereiche nach Branchen
• Bedeutung der geographischen Nähe des Kooperationspartners
• Ausgestaltung der Kooperationen
• Kooperationshemmnisse
• Möglichkeiten zur Verbesserung der Kooperationen in Baden-Württemberg
• Formen der Auslandsaktivität
• Auslandsaktivitäten nach Regionen
• Rekrutierung Hochqualifizierter nach Region
• Rekrutierungsstrategien
• Formen der IT-Weiterbildung
• Weiterbildung für Ältere
• Produkt- und Prozessinnovationen
• Entwicklung der Innovationstätigkeit

Der Trend zum Enterprise 2.0 kann inzwischen als etabliert gelten, wie die aktuelle Studie des Bitkom 2008 “Enterprise 2.0: Analyse zu Stand und Perspektiven in der deutschen Wirtschaft” belegt. Demnach identifizierten sich 87% der Befragten “voll und ganz” bzw. “eher” mit der Aussage “Web-2.0-Technologien werden in unserem Unternehmen an Bedeutung gewinnen“.

62% der Befragten konnten bereits grundsätzlich positive Auswirkungen auf den Unternehmenserfolg feststellen. Fast die Hälfte der befragten Unternehmen begann die Auseinandersetzung mit Enterprise 2.0 in den Jahren 2006 oder 2007, etwa ein Drittel vorher. Viele Entscheidungsträger sind also bereits für Enterprise 2.0 sensibilisiert. Dies zeigt in der Gesamtschau, dass die strategische Ausrichtung auf Enterprise 2.0 in den meisten Firmen gerade beginnt.

Will man das Stimmungsbild dieser Studie umreißen, so ist aktuell ein Wendepunkt im Wandel von Unternehmen zum Enterprise 2.0 erreicht. Die Unternehmen stellen sich zum jetzigen Zeitpunkt nicht mehr die Frage, ob der Wandel zum Enterprise 2.0 sinnvoll ist. Gefragt wird vielmehr nach dem Wie des Wandels.

Einige Details: Wikis, Foren und Instant Messaging sind bereits ausgereifte Tools und werden operativ genutzt. In der Einführungs- und Testphase befinden sich Blogs, Mashups, semantische Technologien, Social Bookmarking und Tagging. Im Vergleich zu den ebenfalls etablierten klassischen Webservices (CMS, DMS) befindet sich der Entwicklungs und Erprobungsaufwand bei Wikis und Foren noch immer auf hohem Niveau. Es ist anzunehmen, dass dieses Ergebnis auf die Komplexität der Einführung von Foren und Wiki-Umgebungen zurückzuführen ist. Dies zeigt, dass die Unternehmen den Nutzen bereits erkannt haben und sich von der Komplexität des Einsatzes von Web 2.0-Technologien nicht abschrecken lassen.

]]> http://blog.cm-development.de/2008/12/23/bitkom-studie-2008-der-trend-zu-enterprise-20-ist-gesetzt/feed/ 0 http://blog.cm-development.de/2008/11/20/aktuelle-studie-warum-und-wie-firmenwikis-eingefuhrt-werden/ http://blog.cm-development.de/2008/11/20/aktuelle-studie-warum-und-wie-firmenwikis-eingefuhrt-werden/#comments Thu, 20 Nov 2008 09:20:10 +0000 Lutz Gerlach http://blog.cm-development.de/?p=72 Aussagekräftige Studien zur Verbreitung und Nutzung von Collaboration Tools sind selten – Studien, die aufzeigen, wie diese Tools in der Praxis eingeführt und gemanaged werden, sind (leider noch) sehr selten.

Penny Edwards von der Open University Business School (UK) hat mit “Managing Wikis in Business” eine dieser seltenen Studien zu Firmenwikis (bzw. Enterprise Wiki, Corporate Wiki) vorgelegt. Ihre Ergebnisse dürften für Unternehmer wie Prozessberater von hohem Interesse sein. Auf der Grundlage von Experteninterviews und weltweit 102 mittels Fragebogen befragten Unternehmen (aus IT, Services, Medien, Transport, Finanzen) zeigt sie u.a.:

• welchen konkreten Nutzen Wikis entfalten
• wie die Nutzung von Wikis gefördert wird
• wie Unternehmen Wikis strukturieren
• welche Wiki-Features genutzt werden
• Gründe der Unternehmen für Wiki-Einführungen
• Barrieren bei der Einführung von Wikis

Die Ergebnisse machen deutlich, dass sich Wikis im Businesssektor zunehmend als collaborative Plattformen etablieren, die es den Nutzern erlauben,

• effizienter als bislang miteinander zu arbeiten und zu kommunizieren,
• besser aus vergangenen Erfahrungen zu lernen und
• Wissen und Ideen auch in Unternehmenskontexten zu teilen, die bislang als schwierig für Collaboration galten.

Wiki-Management ist dabei gleich dem Management eines Change Prozesses.

Eine Wiki wechselwirkt eng mit etablierten Routinen/Arbeitsweisen, Unternehmensstrukturen und kulturellen Werten. Hier ist Veränderungsbereitschaft der Schlüssel. Erfolgreiche Wiki-Nutzung kennzeichnen zusätzlich konkrete interne Collaborationsziele, wirksame Praktiken zur Motivation und Entwicklung der Nutzer sowie permanenter(Selbst)Evaluation und Feedback.

In späteren Blogbeiträgen werde ich Teilergebnisse der Studie eingehender diskutieren. So verdienen die schwierigsten Einführungbarrieren (Zeit, Verfügbarkeit, Kultur) und der konkrete Nutzen von Wikis (für Wissenstransfer, Ideensharing, als Wissensbasis) gesonderte Betrachtungen. Auch das große Vertrauen der Unternehmen in die Selbstmotivations-, Selbstlern- und Selbstimplementierungsfähigkeit ihrer Mitarbeiter (bei 3/4 der Firmen) verdient einen zweiten Blick.

Für heute bleibt es für alle, die es genauer wissen wollen, bei dem Downloadlink zur Studie “Managing Wikis in Business” (PDF). Viel Spaß beim Lesen!