Advertisement

Begriffliche Grundlagen

  • Volker Wulf
Chapter

Zusammenfassung

Ich will in diesem Kapitel zunächst einige Grundbegriffe erläutern, auf denen die Argumentation der Arbeit im weiteren beruht. Da die im folgenden zu thematisierenden Konflikte sich beim Gebrauch flexibel nutzbarer Funktionen von Groupware zeigen, sollen zunächst die drei Schlüsselbegriffe “Groupware”, “technische Flexibilität” und “groupware-spezifischer Konflikt” präzisiert werden.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 1.
    Die Frage, ob ISDN-Telefonanlagen zu den Groupwareanwendungen zu zählen sind, bleibt bei den meisten Autoren, die eine Definition des Begriffs Groupware geben, ungeklärt. Während andere, lediglich die Kommunikation zwischen Nutzern unterstützende Systeme wie E-mail oder Videokonferenzen ganz selbstverständlich zur Groupware gezählt werden (vgl. CSW ’92; CSCW ’94), finden sich in der Diskussion um Groupware nur wenige Beiträge, die Weiterentwicklungen bei Telefonanlagen zum Gegenstand haben (vgl. Resnick 1992). Ich will im folgenden ISDN-Telefonanlagen aus zwei Gründen unter dem Begriff Groupware subsumieren. Erstens sind diese Systeme seit dem Übergang von der analogen zur digitalen Technik computerbasiert — mit all den daraus resultierenden Problemen — und zweitens können sie Kommunikation, Kooperation und Koordination zwischen ihren Nutzern unterstützen.Google Scholar
  2. 2.
    Die Autoren beanspruchen weder, alle möglichen Anwendungen von Groupware zu erfassen, noch hinsichtlich der von ihnen gebildeten Anwendungstypen überschneidungsfrei zu sein (vgl. Easterbrook u.a. 1993, S. 52; Ellis, Gibbs und Rein 1991, S. 41 f; Johansen 1988, S. 13).Google Scholar
  3. 1.
    Easterbrook u.a. (1993, S. 52 ff) bezeichnet beispielsweise diesen Anwendungstyp als “Computer-Mediated Communication Systems”. Außerdem gehören bestimmte Anwendungen der “Information-Sharing Systeme” — wie z.B. die Anwendung “Information-Lens” zu diesem Anwendungstyp. Die von Ellis, Gibbs und Rein (1991, S. 42ff) genannten Katagorien “Message Systems” und “Computer Teleconferencing Systems” decken diesen Anwendungstypus ab. Johansens (1988) Kategorien “Computer-Supported Spontaneus Interaction” und “Computer-Conferencing Systems” gehören ebenfalls zu diesem Anwendungstyp.Google Scholar
  4. 2.
    Dieser Anwendungstyp findet sich nicht in den Klassifikationen von Johansen (1988) und Easterbrook u.a. (1993). Er wird von Ellis Gibbs und Rein (1991, S. 43) als dokument-orientierte Koordinationssysteme bezeichnet.Google Scholar
  5. 1.
    Bei dieser Klassifikation betrachte ich Funktionen ganzheitlich. Ich unterscheide dabei nicht die verschiedenen Ebenen der Benutzungsschnittstelle. Will man diese Betrachtungsweise im IFIP-Mo-dell (vgl. Dzida 1983) einordnen, so definiert sich eine Funktion durch die Gestaltung auf der Werkzeugebene oder der technischen Organisationsschnittstelle, während die Gestaltung auf der Dialog-und E/A-Ebene sicherstellt, daß sie von Nutzern aktiviert werden kann. Insofern folge ich auch nicht Höllers (1993) — durch die Betrachtung der X.400 Norm nahegelegten — Beschränkung auf bestimmte Aspekte der Werkzeugschnittstelle. Die Implementierung von Konfliktregelungsmechanismen wird allerdings durch eine gemäß dem IFIP-Modell modularisierte Software erleichtert (vgl. Kap. 6.2.5). Höller (1993) grenzt die in seiner Arbeit untersuchte Funktionalität mit Hilfe des IAO-Modells (vgl. Bullinger, Fähnrich, Hanne und Ziegler 1984) ab, welches eine Weiterentwicklung des IFIP-Modells (vgl. Dzida 1983) darstellt. Neben anderen Unterschieden wird im IAO-Modell die Werkzeugschnittstelle des IFIP-Modells durch das Anwendungssystem ersetzt. Dieses Anwendungssystem untergliedert sich in die AS’ (Werkzeugrepräsentation) und die AS” (Anwendungsrepräsentation). Während die AS’ festlegt, wie auf die Funktionen zugegriffen werden kann, legt die AS” fest, welche anwendungsspezifischen Funktionen vorhanden sind. Da es Höller in seiner Arbeit um eine Bewertung der standardisierten Aspekte von Message-Handling-Systemen geht, begrenzt er das Anwendungsfeld seines Bewertungsansatzes auf funktionelle Aspekte der AS”-Schnittstelle und blendet die übrigen Aspekte der Benutzerschnittstelle aus (vgl. Höller 1993, S. 111 ff.).Google Scholar
  6. 1.
    Höller (1993) trifft darüber hinaus aber noch eine weitere Abgrenzung, die für die internationale Normung auf Grund ihres sich ausschließlich auf den Nachrichtenaustausch zwischen technischen Systemen beziehenden Kommunikationsverständnisses nicht vorgenommen wurde. Er unterscheidet dabei aus Nutzerperspektive zwischen MCCM-, MCC- und CC-Systernen (vgl. ebenda, S. 127 ff.).Google Scholar
  7. 3.
    In der Tat beziehen sich die genannten Richtlinien lediglich auf die Dialog-Schnittstelle des IFIP-Modells. Befolgt man aber dort genannte Grundsätze, so wirken sie sich auch auf die Gestaltung der Werkzeugschnittstelle aus und stellen auch für diese den bisher weitest ausgearbeiteten Anforderungskatalog dar (vgl. Höller 1993, S. 206 ff.).Google Scholar
  8. 4.
    Diese Unterscheidung zwischen globalen und lokalen Funktionen ließe sich auch im IFIP-Modell abbilden. Differenziert man dort die Organisationsschnittstelle in eine technische und eine nichttechnische Komponente (vgl. Oppermann u. a. 1992), so liegt es m. E. nahe, die Funktionen von Groupware, die mehr als einen Nutzer betreffen, auf der Ebene der technischen Organisationsschnittstelle einzuordnen. Dagegen könnten einzelplatzbezogene Funktionen der Werkzeugschnittstelle zugeordnet werden, um sie gemäß den Grundsätzen der traditionellen Software-Ergonomie zu gestalten.Google Scholar
  9. 1.
    Herrmann (1994, S. 75 f.) spricht in diesem Zusammenhang auch von Transparenzdatensätzen und von einem Transparenzspeicher, in dem diese Daten abgelegt werden.Google Scholar
  10. 2.
    Unsere Definition von Groupware schließt Anwendungen aus, die ausschließlich Daten über das Verhalten ihrer Nutzer sammeln, ohne die Möglichkeit zu bieten, Inhaltsdaten zu übertragen. Eine solche Anwendung stellen beispielsweise Batch-Systeme dar, bei denen mit Hilfe elektronischer Sender der Aufenthaltsort der Nutzer periodisch abgefragt und aufgezeichnet wird (vgl. Lövstrand 1991).Google Scholar
  11. 1.
    Bei dem hier verfolgten Klassifizierungsansatz knüpfe ich an die von mir (Wulf 1993, S. 279 ff.) vorgenommene Einteilung der Funktionalität asynchroner Groupware an. Unter dem Begriff “asynchroner Groupware” wurden dabei solche Anwendungen von Groupware verstanden, die von räumlich oder zeitlich getrennten Benutzern zur Unterstützung ihrer Kommunikations- und Kooperationsbeziehungen genutzt werden können (vgl. Wulf 1993, S. 276).Google Scholar
  12. 2.
    Eine solche Klassifikation unterscheidet sich von dem siebenschichtigen ISO/OSI-Referenzmodell durch die Perspektivenwahl und den Klassifikationsgegenstand. Während das ISO/OSI Modell die zur Erbringung technischer Kommunikation notwendigen Dienstelemente in verschiedene Schichten einteilt (vgl. Effelsberg und Fleischmann 1986), orientiert sich die hier gewählte Klassifikation an den den Nutzem zur Verfügung stehenden Funktionen unabhängig davon, ob durch deren Ausführung technische Kommunikation in einem verteilten System entsteht.Google Scholar
  13. 2.
    In früheren Arbeiten wurde diese Teilfunktionalität als “nutzungsbezogene Transparenz” bezeichnet (vgl. Wulf 1993, Wulf und Hartmann 1994).Google Scholar
  14. 3.
    Ein ausdifferenzierter Ansatz für eine objektorientierte Architektur eines Ereignisdienstes findet bezogen auf einen gemeinsamen Arbeitsbereich sich bei Fuchs, Pankoke-Babatz und Prinz (1995). Sohlenkamp und Chewelos (1994) diskutieren die Frage, wie eine geeignete Benutzerschnittstelle für einen Ereignisdienst aussehen könnte.Google Scholar
  15. 1.
    Oberquelle (1993, 1994) bezieht sich dabei auf Arbeiten von Leavitt (die sogenannte Leavitt-Raute), der diese vier Dimensionen bereits benannt hatte.Google Scholar
  16. 1.
    Neben den hier diskutierten Dimensionen schlägt Paetau (1993) vor, technische Flexibilität zusätzlich gemäß der Aspekte: “Reichweite der Maßnahmen” und “zur Flexibilisierung verwendete Softwareentwicklungs-Werkzeuge” einzuteilen. Die Dimension “Reichweite der Maßnahmen” bezieht sich dabei auf eine Verortung in dem an das IFIP-Modell angelehnten Strukturmodell der VDI-Richtlinie 5005. Hinsichtlich der Mittel für die Realisierung technischer Flexibilität schlägt er vor, zwischen applikationsinternen und -externen Werkzeugen zu unterscheiden. Haaks (1992) schlägt analog zur Dimension “Reichweite der Maßnahme” vor, zwischen “Modifikation der Benutzeroberfläche” und “Modifikation der Funktionalität” zu unterscheiden. Außerdem unterscheidet er noch zwischen “Adaptierbarkeit im Großen” und “Adaptierbarkeit im Kleinen” und benennt diese Dimension mit “Reichweite der Modifikationen”.Google Scholar
  17. 1.
    Es müssen dabei nicht alle Nutzer diese Anpassungsmaßnahmen vornehmen können, sondern diese können auch kollektiv in einer Gruppe oder von einzelnen speziell geschulten Nutzern durchgeführt werden. Nardi (1993) spricht in diesem Fall von Gärtnern.Google Scholar
  18. 2.
    In der englischsprachigen Literatur besteht hinsichtlich der Akteure des Anpassungsprozesses keine einheitliche Auffassung. Während Trigg u.a. (1987) davon ausgehen, daß immer Nutzer die Akteure der Anpassung sein werden, kann Anpassung gemäß des Ansatzes von Henderson und Kyng (1991) auch von Systemspezialisten vorgenommen werden. Diese unterschiedlichen Auffassungen resultieren m.E. daraus, daß die Autoren hinsichtlich der verschiedenen Akteursgruppen wenig differentierte Vorstellungen entwickeln.Google Scholar
  19. 1.
    Dzida (1994, S. 292 ff.) hat in ähnlicher Weise gezeigt, wie Anpassung in den Prozeß evolutionärer Software-Entwicklung integriert werden kann.Google Scholar
  20. 2.
    es ist beispielsweise bei als Ware über einen Massenmarkt vertriebener Software der Fall. Dort haben Nutzer und auch einzelne Anwender in der Regel nur geringe Möglichkeiten, ihre Bedürfnisse dem Hersteller gegenüber zu artikulieren, um damit Einfluß auf die Weiterentwicklung der Software zu nehmen.Google Scholar
  21. 1.
    Des ist beispielsweise bei als Ware über einen Massenmarkt vertriebener Software der Fall. Dort haben Nutzer und auch einzelne Anwender in der Regel nur geringe Möglichkeiten, ihre Bedürfnisse dem Hersteller gegenüber zu artikulieren, um damit Einfluß auf die Weiterentwicklung der Software zu nehmen.Google Scholar
  22. 2.
    Haaks (1992, S. 63ff.) behandelt diese Fragestellung unter der Bezeichnung “Methodik der Adaption”.Google Scholar
  23. 3.
    Im englischen Original bezeichnen die Autoren dies als: “Choosing between Alternative Anticipated Behaviour”Google Scholar
  24. 4.
    Im englischen Original bezeichnen dies die Autoren mit: “Constructing New Behaviours from Existing Pieces”.Google Scholar
  25. 1.
    Die Autoren bezeichnen dies im englischen Original mit: “Changing the Artifact”.Google Scholar
  26. 2.
    An dieser Stelle soll der Fall nicht betrachtet werden, daß Anpassungen auch vom System selbst automatisch initiiert werden könnten, wie dies in dem Konzept der (Auto)- Adaptivität vorgesehen ist (vgl. Oppermann 1989, S. 133ff.; Friedrich 1990, S. 180 ff.).Google Scholar
  27. 1.
    Oppermann (1989) splittet das Konzept der Individualisierbarkeit noch weiter auf, indem er die von den Nutzern durchzuführenden Eingriffe (Anpaßbarkeit oder Adaptierbarkeit) von denen vom System automatisch durchgeführten Veränderungen (Auto-Adaptivität) unterscheidet. Da sich das Konzept der Auto-Adaptivität als wenig praxisrelevant erwiesen hat, soll hier darauf nicht näher eingegangen werden (siehe hierzu auch Friedrich 1990).Google Scholar
  28. 1.
    Sie unterscheiden zwischen: Setzen von Parametern, Hinzufügen von Funktionalität zu existierenden Objekten, Schaffen neuer Objekte durch Modifikation existierender Objekte und Schaffen völlig neuer Objekte (vgl. Fischer und Girgensohn 1990, S. 184).Google Scholar
  29. 1.
    Die Autoren bezeichnen dieses Konzept im englischen mit “radical tailorability” (vgl. Malone, Lai und Fry 1992).Google Scholar
  30. 1.
    Es sollen hier nur einzelne für den weiteren Verlauf der Untersuchung wichtige Dimensionen dargestellt werden, weil es bisher keine in den Sozialwissenschaften allgemein anerkannte Konfliktklassifikation gibt (vgl. Fink 1968, S. 416 ff.; Grunwald 1981, S. 56; Glasl 1992, S. 95 ff.).Google Scholar
  31. 1.
    Grunwald benutzt anstelle des Begriffs “Konflikt” den Begriff “Konkurrenz”, der für ihn einen Unterbegriff der Konfliktdefinition darstellt (1981, S. 70).Google Scholar
  32. 1.
    Ich werde im folgenden beim Konfliktmanagement nicht mehr zwischen den Aktivitäten der Nutzung und der Anpassung unterscheiden. Diese Unterscheidung ist immer relativ zu den Aufgaben der betrachteten Akteure. Die Aktivierung einer bestimmten Funktion mag für einen lokalen Experten eine Nutzung darstellen, weil seine Aufgabe in der Anpassung des Systems besteht. Die Aktivierung derselben Funktion kann für einen Nutzer dagegen eine Anpassung darstellen. Unabhängig von dieser Unterscheidung kann für die Betroffenen ein Konfliktpotential bestehen.Google Scholar
  33. 1.
    Ein vielzitiertes Beispiel für mangelnde Berücksichtigung des Konfliktpotentials einzelner Leistungsmerkmale bei der Herstellung von Software stellt die Kanaletablierungsfunktion im bundesdeutschen ISDN-Netz dar. Dort wird die Anruferidentifizierung starr mit dem Kanalaufbau verknüpft, so daß Telefonate im ISDN-Netz lediglich gekoppelt an eine Vorabidentifizierung des Anrufers erfolgen können. Diese Designentscheidung beinhaltet kerne technische Flexibilität bezüglich der Anruferidentifizierung für die Nutzer, und somit besteht auch diesbezüglich kein groupware-spezifisches Konfliktpotential. Nichtsdestotrotz entfällt durch diese Entscheidung die Möglichkeit, anonym kommunizieren zu können, was Konflikte bezüglich dieser Designentscheidung zur Folge hatte (vgl. Kubicek 1987; Roßnagel 1990).Google Scholar
  34. 1.
    Ich werde im folgenden den Begriff Dahrendorfs “Konfliktfront” durch den Begriff “Konfliktkonstellation” ersetzen.Google Scholar
  35. 1.
    Dahrendorf versteht unter sozialer Rolle “Bündel von Erwartungen, die sich in einer gegebenen Gesellschaft an das Verhalten von Trägern von Positionen knüpfen” (Dahrendorf 1977, S 33). In der von Dahrendorf gewählten Terminologie wäre das Pendant die “soziale Position”. Mit Hilfe dieses Terms beschreibt er Konfliktparteien wie folgt: “Aufgrund des jeweils relevanten Strukturmerkmals lassen sich in der betreffenden sozialen Einheit zwei Aggregate sozialer Positionen, die “beiden Seiten” der Konfliktfront unterscheiden…” (Dahrendorf 1961, S. 218). Der in diesem Zusammenhang interessanten Frage, inwieweit durch Funktionen in Groupware zur Definition sozialer Rollen in bestimmten Anwendungskontexten beigetragen wird, soll an dieser Stelle nicht nachgegangen werden.Google Scholar
  36. 2.
    Kreifelts u. a. (1984, 1991) verwenden den Rollenbegriff bei elektronischen Vorgangsbearbeitungssystemen als Beschreibungselement, um daran einzelne bei der Bearbeitung eines bestimmten Vorgangstyps notwendige Aktionen zu binden. Trevor, Rodden und Blair (1993, S. 22 f.) nutzen diesen Begriff, um daran Zugriffsrechte zu binden. In beiden Ansätzen sind Rollen eine Zwischeninstanz, um Zugangsrecht oder Leistungsmerkmale in sich im zeitlichen Verlauf verändernder Weise einzelnen Nutzern zur Verfügung zu stellen.Google Scholar
  37. 3.
    Diese Abstraktionsebenen reichen von der allgemeinen Klassifizierung der Funktionalität für Groupware (vgl. Kap. 2.1) bis hin zur Betrachtung einer einzelnen Funktion in einem konkreten Anwendungskontext.Google Scholar
  38. 1.
    Wenn wir im folgenden trotzdem von Konfliktlösungen sprechen, dann handelt es sich — im Sinne Dahrendorfs — um Quasilösungen, die einen Konflikt für einen bestimmten Zeitabschnitt verschwinden lassen (vgl. Dorow 1978, S. 226 f.). Das Konfliktpotential bleibt weiter bestehen.Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 1997

Authors and Affiliations

  • Volker Wulf

There are no affiliations available

Personalised recommendations