Probleme bei der Klassifizierung

Ein wichtiger Teil dieser Arbeit ist es, eine geeignete Strukturierung für Open-Source-Groupware zu entwickeln, die bei der Auswahl von CSCW-Programmen möglichst schnell zum Ziel führt. Dabei hat es sich angeboten, zuerst die bereits entwickelten Klassifizierungen zu untersuchen und gegebenenfalls zu verwenden. Leider passt keine der ,,klassischen Einteilungen``. Im Folgenden soll kurz diskutiert werden, warum sich weder die Raum-Zeit-Matrix, noch anwendungsorientierte Funktionsklassen und 3K-Modell für den Zweck dieser Diplomarbeit einfach übernehmen lassen. Dabei wird zuerst erläutert, welche Anforderungen an die Strukturierung durch die Aufgabenstellung gegeben sind und dann aufgezeigt, in welchen Punkten die vorgestellten Modelle Probleme haben.

Wie in Abschnitt 1.2 betont, besteht der Hauptzweck der vorliegenden Diplomarbeit darin, eine Hilfestellung bei der Auswahl und Installation freier Groupware-Lösungen für Standardaufgaben zu geben. Wer sich bereits näher mit Installationshinweisen beschäftigt hat, der hat sich im Normalfall schon für eine Groupware-Lösung entschieden. Für die Klassifizierung ist also die oberste Maxime die Hilfe bei der Auswahl der CSCW-Systeme. Trotzdem soll die Strukturierung von allgemeiner Natur sein, das spricht gegen eine Auflistung von existierenden Produktkategorien. Zusätzlich ist es erforderlich, dass die Einteilung einen pragmatischen Hintergrund hat, denn die eigentliche Zielgruppe sollen nicht Groupware-Spezialisten sein, sondern Fachfremde, die CSCW-Systeme einsetzen wollen. Unnötiger theoretischer Ballast soll weggelassen werden.

Wichtig ist auch, dass die Strukturierungmerkmale und die Anforderungen, die an Groupware-Programme gestellt werden, in engem Zusammenhang stehen. Der Grund ist einfach, es wird davon ausgegangen, dass die Zielgruppe eine gewisse Erwartungshaltung bereits mitbringt, also bereits Anforderungen an Groupware stellt. Normalerweise haben diese Anforderungen unterschiedliche Priorität. Die Strukturierung soll sich wenn möglich an der Hauptanforderung der Auswählenden festmachen. Sie bildet die Grundlage für die Einteilung. Zusätzliche Anforderungen, die in Kapitel 3 herausgearbeitet werden, sollen als Rahmenbedingungen die Hauptanforderung sinnvoll ergänzen.

Probleme der Raum-Zeit-Matrix:

In Abschnitt 2.1.1 wurde die Raum-Zeit-Matrix vorgestellt. Schwierigkeiten könnte es geben, wenn bei der Recherche nach der passenden Groupware die Fragen nach räumlicher und zeitlicher Verteilung nicht beantwortet werden können. Das ist meist dann der Fall, wenn die gesuchten Produkte nachweislich an den Schnittstellen der Matrixfelder liegen. Unglücklicherweise ist die Platzierung an den Schnittstellen auch ein signifikantes Merkmal von Groupware-Produkten.

Auch bei der Erweiterung nach Grudin fehlt die eindeutige Hauptanforderung, nach der die CSCW-Systeme klassifiziert sind. Der pragmatische Hintergrund ist bei diesem Modell nicht vorhanden. Die Raum-Zeit-Matrix wird deshalb in der selbstentwickelten Klassifizierung in Abschnitt 2.3 nicht berücksichtigt.

Probleme der anwendungsorientierten Funktionsklassen:

Zweifellos hat eine anwendungsorientierte Sichtweise den Vorteil, dass auch Nicht-Informatiker sich schneller zurecht finden, die Darstellung insgesamt also leichter verständlich ist und auch Nicht-Fachleute die Strukturierung eher als Auswahlhilfe nutzen können. Aber auch dieser Ansatz zeigt Schwächen: So ist die Einteilung in Funktionsklassen nicht redundanzfrei, ,,beispielsweise sind in asynchronen Konferenzsystemen meist Nachrichtensysteme integriert, um eine asynchrone Kommunikation zwischen Gruppenteilnehmern zu ermöglichen``^2.1.

Ein weiterer Kritikpunkt an dieser Vorgehensweise ist eine begrenzte Aktualität. Während etwa die Raum-Zeit-Matrix neue Systemklassen ohne Probleme neu einordnen kann oder bestehende entfernen kann, ist das mit der anwendungsorientieren Sicht nicht so einfach. Auch Verschiebungen der Funktionsklassen wirken sich stärker aus. Wenn man diesen Ansatz verwendet, sollte man in kurzen Abständen die gefundenen Klassen auf ihre Gültigkeit überprüfen.

Die anwendungsorientierten Funktionsklassen in Abschnitt 2.1.1 passen jedoch besser auf die gestellten Anforderungen wie die Raum-Zeit-Matrix. Für diesen Ansatz spricht vor allem der Praxisbezug. Auch die Gliederung anhand der Funktionalität passt gut, denn das sollte die Hauptanforderung sein, die potentielle Groupware-Nutzer an eine Lösung stellen. Die Bezeichnungen der Funktionsklassen sind aber nicht auf den ersten Blick verständlich. Unter der Klasse Agentensysteme werden sich viele Nutzer zuerst nichts vorstellen können. Außerdem passen die Gruppeneditoren als Produktgruppe nicht in die Klassenhierarchie.

Probleme des 3K-Modells:

Das 3K-Modell, vorgestellt in Abschnitt 2.1.3, ist zwar sehr übersichtlich, die Unterscheidung in Kommunikation, Koordination und Kooperation ist aber nicht intuitiv und praxisnah. Vielmehr müsste sich ein Laie erst in die begrifflichen Abgrenzungen einarbeiten, bevor er dann erst im zweiten Schritt die vier Systemklassen kennenlernt. Das ist aber für den Einsatz von Groupware nicht notwendig. Besonders gelungen ist an den Funktionsklassen aber, dass sie den gesamten Groupware-Bereich abdecken. Aus diesem Grund sind die vier Systemklassen eine Art Grundlage für die neu abzuleitende Klassifizierung.