|
|
|
Annette Haeussler, SAP AG – 12/09/2002
Bei der Entwicklung eines Groupware-Systems müssen nicht nur technische Aspekte berücksichtigt werden. Auch rechtliche, organisatorische und insbesondere auch menschliche und soziale Aspekte beeinflussen die Entscheidung, welche Funktionalitäten die Zusammenarbeit optimal unterstützen. Dieser Artikel ist ein Auszug aus meiner Diplomarbeit "Entwicklung eines Instant-Messenger-basierten Groupware-Systems zur Widerspiegelung des Online-Zustands (Awareness) anhand einer umfassenden Anforderungsanalyse für zeitlich und räumlich verteilte Ad-hoc-Gruppen (virtuelle Teams)" und untersucht die Akzeptanzbedingungen für Groupware bei den Anwendern.
Der Einfluss eines Gruppenmitgliedes auf die Gruppe und umgekehrt wird von zwei Faktoren geprägt, nämlich der Wahrnehmung des Handelns anderer Gruppenmitglieder und der Wahrnehmung des eigenen Verhaltens durch die Gruppenmitglieder.
Dabei handelt es sich um einen Handlungs- und Wahrnehmungsprozess, in dem gemeinsame Normen und Werte gesucht oder verändert werden. Ein Team durchläuft in diesem Prozess seiner Entwicklung verschiedene Phasen. Zunächst ist das die Phase der Orientierung (Sammeln der Information und Einfügen in das Gesamte), anschließend die Phase der Evaluation (Diskussion und Aushandeln mit Ziel der Verbesserung) und schließlich die Phase der Kontrolle (Anpassung und Regelung des persönlichen Verhaltens) [Bal50].
"If individuals see themselves as being a group then a group exists." (R. Bales [Bal50])
Die gemeinsamen Normen und Werte einer Gruppe, die den Umgang (das soziale Verhalten gegenüber einander) regeln und für die Gesellschaft als Verhaltensnorm gelten, mögen beim Kontakt auf elektronischem Weg anders oder schwächer ausgeprägt sein als in der realen Welt. Sie sind aber im zwischenmenschlichen Umgang stets vorhanden und bei der Entwicklung von Systemen zur Unterstützung der Zusammenarbeit zu berücksichtigen, denn das Einbringen von neuen Technologien und Prozessen in Gruppen verändert die dort vorherrschende Beziehungs-, Wahrnehmungs- und Machtreproduktionsprozesse [Her01].
Grudin hat diese Herausforderung für die Entwickler von Groupware-Anwendungen untersucht und wie folgt beschrieben [Gru94].
Es werden immer noch Applikationen entwickelt, die sich als praktisch nicht verwendbar erweisen. Dies liegt nicht in dem Design der Anwendungen, sondern daran, dass die Entwickler der Groupware nicht genug über den Arbeitsablauf der Teams wissen. Eine Groupware-Anwendung muss aber auf die individuellen Anforderungen der Gruppe und deren Arbeitsprozesse zugeschnitten sein.
Arbeitsprozesse können auf zwei Arten beschrieben werden: so wie die Dinge laufen sollen und so wie die Dinge tatsächlich laufen. Der Mensch kann seine Arbeit jedoch auf verschiedene Arten erledigen. Oft hat er seine Arbeitsweise durch Erfahrungen schon optimiert. Er kann flexibel auf Ausnahmesituationen und Fehler reagieren. Eine Übertragung dieser Möglichkeiten in ein elektronisches System erweist sich jedoch sehr schwer, denn dafür müssen "Standard-Prozesse" definiert werden.
Die Herausforderung ist also, Groupware an die Arbeitsweise der Menschen anzupassen, statt die Menschen an die Arbeitweise der Groupware.
Eine Groupware-Anwendung muss sozial und politisch motiviertes Verhalten der Anwender berücksichtigen. Computer dienen in erster Linie der Verarbeitung von Daten. Die subtilen und komplizierten sozialen Strukturen des menschlichen Verhaltens lassen sich damit schwer darstellen. Handlungen werden jedoch häufig unbewusst durch das soziale Umfeld oder durch das Wissen um Funktionen, Eigenschaften oder Prioritäten unserer Mitmenschen beeinflusst.
Freie Termine in einem elektronischen Terminkalender des Managers bedeuten eben nicht zwangsläufig, dass man diese unautorisiert verplanen kann. Ein Missbrauch in dieser Hinsicht führt daher zwangsläufig zur Ablehnung des Systems. Ähnliche Probleme wird es auch bei einem prioritätsbasierten Terminplaner geben, denn welcher der Mitarbeiter würde schon offiziell zugeben, dass einige seiner Sitzungen von niedriger Priorität sind.
Es ist daher in jedem Fall wichtig, so weit es möglich ist, Rücksicht auf die menschliche Komponente bei der Erstellung eines Groupware-Tools zu nehmen.
Von einer Groupware-Anwendung profitieren darüber hinaus nicht alle Teammitglieder im gleichen Maße. Der Aufwand und Ertrag hängen von den Vorlieben, Erfahrungen, Rollen und Aufgaben der Anwender ab. Manche Mitglieder der Gruppe müssen mehr dazu beitragen als andere, um für die Anwendung erforderlichen Informationen einzubringen oder zu verarbeiten. Eine Groupware-Anwendung sollte zwar in erster Linie der Gruppe nutzen, idealerweise sollte daraus auch jeder einzelne einen Vorteil ziehen. Dies ist jedoch schwer zu realisieren.
Von einem elektronischen Kalendersystem für das automatische Vereinbaren von Meetings profitiert derjenige, der die Meetings organisieren muss, gewöhnlich ein Manager oder eine Sekretärin. Aber um ihm dies überhaupt zu ermöglichen, muss die ganze Gruppe ihren persönlichen Kalender pflegen. Wird der Kalender nicht aktuell gehalten, funktioniert das ganze System nicht. Dies ist der Grund, warum Email so gut angenommen wurde. Denn der Anwender ist selbst derjenige, der daraus den direkten Nutzen zieht.
Die Herausforderung liegt darin, möglichst allen Anwendern der Gruppe das System "schmackhaft" zu machen, indem man den Aufwand zur Pflege des Systems für den einzelnen immer geringer hält, als den Nutzen, den er selbst aus dem neuen System zieht.
Ein weiterer Punkt ist das Problem der critical mass: Ein Textverarbeitungs-Tool, das einer von fünf Anwendern sofort akzeptiert, ist ein Erfolg. Für eine Groupware-Anwendung die der Unterstützung eines Teams von fünf Personen dient, wäre das jedoch katastrophal. Für ein Groupware-Tool ist es nämlich äußerst wichtig, dass möglichst viele, im Optimalfall alle Teammitglieder es auch aktiv verwenden. Der Schwellwert an aktiven Nutzern, ab dem ein solches System funktioniert wird als critical mass bezeichnet.
Das Problem, auch als prisoner's dilemma [Rap65] bekannt, besteht bei Groupware-Anwendungen in Folgendem: So lange also ein Groupware-Infosystem von allen Teammitgliedern aktualisiert wird, ist die optimale Strategie eines einzelnen, bezogen auf den Aufwand und Nutzen, gar nichts in die Datenbank zu stellen, sondern nur für sich herauszuziehen. Wenn jedoch alle diese Strategie verfolgen, wird das System selbstverständlich gar nicht benutzt und keiner hat mehr einen Nutzen davon.
Groupware-Anwendungen sind also nur sinnvoll, wenn ein hoher Prozentsatz der Gruppe sie auch aktiv benutzt. Dies macht die Einführung eines neuen Systems aber umso schwieriger. Denn diejenigen, die das System gleich zu Beginn verwenden (early adaptor), können nicht alle Funktionen optimal nutzen, weil sie noch nicht von jedem in der Gruppe aktiv benutzt werden. Es besteht die Gefahr, dass die neuen Anwender frustriert aufgeben und zu ihren alten Arbeitsmethoden zurückkehren, bevor die kritische Masse von Anwendern erreicht ist.
Die Hauptaufgabe der Entwickler war bisher das Erstellen eines Programms. Eine genauso schwierige Aufgabe besteht bei der Entwicklung von Groupware folglich jedoch aber in dem Erzeugen von Akzeptanz bei den Anwendern.
Hilfreich ist dabei folgende Punkte im Auge zu behalten [Gru94]: Zunächst sollte das Problem der Gruppe genau identifiziert werden, um eine passende und sinnvolle Lösung finden zu können. Die geografische Entfernung von Teammitgliedern führt beispielsweise zu der Überlegung Voicemail oder Email, oder auch synchrone oder asynchrone Entscheidungshilfe.
Es sollten zudem passende Arbeitsabläufe ausgewählt werden. Die Tendenz, sich zu sehr auf die Strukturierung von Prozessen zu fixieren, kann für die Kommunikationstechnologie unangemessen sein, die oft wichtige (aber wenig strukturierte) Prozesse unterstützt.
Die Auswahl der passenden Pilotgruppe und Personen trägt ebenfalls zum Erfolg der Einführung bei. Wichtig ist zudem die technischen Anforderungen der Systemumgebung nicht außer acht zu lassen.
Darüber hinaus sollte man die Anwender mit dem neuen System nicht alleine lassen. Die neuen Funktionalitäten müssen erläutert, die Vorteile des neuen Systems aufgezeigt und gegebenenfalls Schulungen angeboten werden, um Hemmungen abzubauen.
Es empfiehlt sich zudem, auf auftauchende Schwierigkeiten in der Anfangsphase vorbereitet zu sein. Schnelle Reaktion auf mögliche Probleme und entsprechender Support sind dabei unerlässlich.
Mit den Anwendern und deren Akzeptanz steht und fällt der Erfolg eines Systems zur Unterstützung der Zusammenarbeit. Groupware ist für Menschen und sollte daher möglichst "kundennah" entwickelt werden. Stetiger Kontakt mit der Zielgruppe ermöglicht es, jederzeit optimal auf die Bedürfnisse der Anwender eingehen zu können und eventuelle Fehlentwicklungen gleich entgegen steuern zu können. Der positive Nebeneffekt ist dabei, dass die Anwender so gleich von Beginn an in das neue System hineinwachsen, sich darin wiederfinden und es akzeptieren.