“we quickly realized the importance of rapidly deploying the full social computing stack [...] to realize greater value from social computing—and mitigate the risks associated with unmanaged use of niche or external tools”

Wir können also davon ausgehen, dass INTEL in den nächsten Jahren zu einem Enterprise 2.0 werden wird. Im White Paper wird bereits das Jahr 2010 als Zielgröße angegeben.

Was geschehen soll bei INTEL, wird mit einigen Beschreibungen angedeutet und hört sich interessant an. Auch was die Issues sein werden, wir nicht verschwiegen – immerhin ist einer der Autoren, Malcom Harkins, für die IT-Sicherheit bei INTEL zuständig (chief information security officer).

Neues St. Galler Management-Modell
(Quelle: Dubs et al.: Einführung in die Managementlehre. Downloadbares Kapitel)

Sehr wenig wurde allerdings ausgesagt über

die breitgefächerte Implementierungs-Strategie mit Blick auf die Konzernbestandteile, mit Blick auf die Kommunikationsweisen der einzelnen Divisionen, auf deren Art der Vernetzung, auf Fragen, welche Division eher ein strukturiertes und welche eher ein unstrukturiertes Web 2.0 benutzen sollte, etc. Dies scheinen mir auch hier bei INTEL (aber nicht nur hier) völlig vernachlässigte Kriterien. Spielerisch orientiertes und auf Kreativität abzielendes Web 2.0 in der Forschung und Entwicklung einerseits vs. an Strukturen und Verbindlichkeit orientiertes Web 2.0 in Logistik, Beschaffung und Produktion andererseits wäre beispielsweise solche eine überlegenswerte Kategorie.

Der Komplexität einen Rahmen geben: Das St. Galler Management-Modell

Im Zuge des Kategorisierens könnte man nun im Einzelnen Überlegungen anstellen – über die Kommunikationsweise der Abteilungen, über die natürlichen Netzwerke im Konzern, über dessen Außenkontakte, etwa zu den Medien, zu Kunden, zu Stakeholdern. Und das sollte man auch. Allerdings braucht man hier nicht bei Null anzufangen. Die Management-Literatur füllt ganze Bibliotheken über diese Verhältnisse – auch mit Blick auf Kommunikation, wenn auch (noch) nicht mit Blick auf Web 2.0.

Dennoch lässt sich viel Nützliches aus dieser Literatur herausarbeiten, sowohl was die Implementierung auf Gesamt-Konzern-Ebene bedeutet, als auch mit Blick auf Software-Design. Nur ist es nicht leicht, ein ganzheitliches Abbild eines Unternehmens oder einer Organisation zu erhalten. Die Literatur ist sehr fragmentiert. Ein solches Abbild aber könnte sehr ambitionierten Enterprise 2.0 Initiativen wie der von IBM als Folie dienen, um dem komplexen Mikrokosmos einer Unternehmung irgendwie beizukommen – als Atlas gewissermaßen.

Mir ist hierbei gleich das St. Galler Management-Modell eingefallen (vgl. Abb.). In der systemisch-ganzheitlichen Perspektive dieses Modells spielt – wie bei systemischen Ansätzen üblich – erstens die Kommunikation eine überragende Rolle. Zweitens ist das Modell darauf angelegt, die Reduktion einer Unternehmung rein auf deren Kernaufgaben (Geschäftsprozesse) zu überwinden, indem diese Kernaufgaben in ein komplexes Beziehungsgeflecht von Anspruchsgruppen integriert werden. Deshalb spricht man hierbei auch vom integrierten Managementsystem.

In den nächsten Blogbeiträgen werde ich mal die einzelnen Elemente dieses Modells hinsichtlich Fragestellungen rund ums Web 2.0 durchleuchten.

Die Titel der Blogbeiträge werden dann ungefähr wie folgt lauten:

Enterprise 2.0 im St. Galler Modell (I): Die Umweltsphären

Enterprise 2.0 im St. Galler Modell (II): Anspruchsgruppen und Interaktionsthemen

Enterprise 2.0 im St. Galler Modell (III): Ordnungsmomente

Enterprise 2.0 im St. Galler Modell (IV): Prozesse

Enterprise 2.0 im St. Galler Modell (V): Entwicklungsmodi

(Die Titel werde ich hier verlinken, sobald ich einen Blogbeitrag online gestellt habe; ihr könnt unseren Blog aber auch als RSS Feed abonnieren)

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.