Zusammenfassung
Neben Kommunikationssystemen stellen Vorgangsbearbeitungssysteme einen weiteren Anwendungstyp bei Groupware dar. Unter Vorgangsbearbeitungssystemen1 sollen Anwendungen verstanden werden, die Nutzer dabei unterstützen, gemeinsam zu bearbeitende Dokumente in festzulegender Reihenfolge aneinander zu übergeben. Diese Übergabe von Dokumenten ist mit einer Aufforderung zur Ausführung einer Aufgabe verbunden. Deshalb bildet die Sequenz des Durchlaufs von Dokumenten die Bearbeitungsreihenfolge an einer nach dem Verrichtungsprinzip zerteilten Aufgabe ab. Der Zustand der elektronischen Dokumente repräsentiert dabei den Arbeitsfortschritt (vgl. Abbott und Sarin 1994, S. 113 ff.; Ellgass und Krcmar 1994, S. 67 ff.).3
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Im Englischen werden diese Anwendungen in der Regel mit “Workflow Management Software” (Hales und Lavery 1991, S. 5), “Office Procedure System” (Kreifelts et al. 1991, S. 117) oder “Business Process Systems” (Medina-Mora et al. 1992, S. 281) bezeichnet.
Auf die mit der Anwendung von Vorgangsbearbeitungssystemen verbundene Zuweisung von Aufgaben an einzelne Nutzer weisen insbesondere Haies und Lavery (1991, S. 5) und Medina-Mora et al. (1992, S. 281ff) bei der Definition von Vorgangsbearbeitungssystemen hin.
Bei der Implementierung wird dabei häufig auf sogenannte “aktive” Komponenten zurückgegriffen, die in Abhängigkeit vom Zustand der jeweiligen Dokumente deren Weiterversand und die Einhaltung bestimmter Konsistenzbedingungen überwachen. Jakobs (1993) und Hales und Lavery (1991) sehen darin ein wesentliches Charakteristikum von Vorgangsbearbeitungssystemen.
Dieses Spezifikum trifft allerdings auch auf asynchrone Kommunikationssysteme zu. Von diesen unterscheiden sie sich nicht in erster Linie durch die technische Gestaltung, sondern durch ihre Nutzungsform. Der wesentliche Unterschied besteht darin, daß mit der Übergabe eines Dokuments nicht primär eine Nachricht ausgetauscht wird, sondern eine an diesem Dokument durchzuführende Arbeitsaufgabe zugewiesen wird.
Die Rolle des Empfangenden kann durchaus auch von einer Organisationseinheit wahrgenommen werden.
Hilpert führt zur Beschreibung dieser Teilfunktionalität die Unterscheidung zwischen “Snapshot” und “Monitoring” ein, die sich mit der hier entwickelten Differenzierung zwischen akutem und protokollierendem Gebrauch weitgehend deckt (Hilpert 1993, S. 18).
Dies ist beispielsweise der Fall, wenn der Initiator eines Vorgangs erfahren will, in welchem Zustand sich dieser augenblicklich befindet (vgl. Kap. 9.2).
Daraus begründet sich auch die Differenzierung zwischen aktivierungsbezogener Transparenz und dem Ereignisdienst (vgl. Kap. 5.2).
In seiner objektorientierten Implementierung realisiert Hilpert (1993, S. 29 f.) Vorgangstypen als Klassen, aus denen bei der Initialisierung einzelne Objekte gebildet werden. Eine Modifizierung des Objekttyps führt dann entweder zu einer Veränderung der Klasse oder zur Bildung einer neuen Unterklasse.
Diese kann dann dezentral von den dann am Vorgang Beteiligten mittels der Delegationsfunktionalität verändert werden.
Hierfür wird in der Literatur häufig der Begriff der Rolle benutzt, der sich von der in dieser Arbeit verwendeten Begrifflichkeit unterscheidet (vgl. Kreifelts u. a. 1991, S. 237 ff.; Karbe und Ramsperger 1991, S. 212).
Hilpert (1993, S. 29) diskutiert solche Möglichkeiten in seinem mit Hilfe objektorientierter Methoden implementierten Ansatz unter dem Aspekt, daß ein Objekt als eine singuläre Instanz eines bestimmten in einer Klasse repräsentierten Vorgangstyps modifiziert wird.
Der hier vorgeschlagene Umgang mit Konfliktpotentialen ist ähnlich dem Regelungsansatz in Kommunikationssystemen für Funktionalität, die den Sender beim Aufbau einer Verbindung unterstützt. Auch dort wird den Betroffenen kein Einspruchsrecht bei der Aktivierung dieser Funktion gegeben, sondern ihre Aktivierung sollte lediglich bei der Verbindungsetablierung transparent werden, um auf diese Weise den Betroffenen Interventionsmöglichkeiten zu geben.
Für eine auf Koordination durch Selbstabstimmung ausgerichtete Organisation erscheint es sinnvoll, den durch die Stornierung eines Vorgangs Betroffenen Verhandlungsmöglichkeiten vor Ausführung dieser Funktion zu bieten. Dies insbesonders dann, wenn die Anwendung neben dem Zurücksetzen noch andere Funktionsalternativen zum Umgang mit Ausnahmesituationen bei der Bearbeitung eines Vorgangs zur Verfügung stellt.
Dies ist umso überraschender, als die Autoren dem Umfeld der Firma Action Technology entstammen und deshalb eine Verknüpfung dieses Workflow-Ansatzes mit dem des Coordinators (vgl. Winograd 1987) nahegelegen hätte. Schäl (1995) vertritt hinsichtlich der Notwendigkeit von Verhandlungen eine ähnliche Auffassung. Auch er zieht daraus keine Konsequenzen hinsichtlich einer entsprechenden technischen Unterstützung.
Das Leitbild teilautonomer Gruppenarbeit würde eher für eine Gestaltung plädieren, die die vollständige Kontrolle über jeden einzelnen Arbeitsschritt dem aktuellen Bearbeiter überläßt. Dies würde für die Funktionen “Zugriff geben” und “Delegation” bedeuten, daß sie steuerbar unter der
Kontrolle des Aktivators verblieben. Für die Funktion “Zugriff auf Dokumente” bedeutet es, daß der extern Zugriff Begehrende ausschließlich mit dem aktuellen Sachbearbeiter über seinen Zugriffswunsch verhandeln sollte. Die übrigen an diesem Vorgang Beteiligten würden jeweils nicht in das Aktivierungsgeschehen einbezogen, weil dies den Handlungsspielraum der Nutzer in der Rolle des aktuellen Bearbeiters einschränken würde.
Die in Kap. 5 dargestellten Ergebnisse zeigen, daß die Zugriffgebenden in der Tat mehrheitlich eine solche Gestaltung bevorzugten, während die Nutzer in der Rolle des Zugriffnehmenden mehrheitlich sich diese Funktion unter ihrer Kontrolle wünschten. Dabei gestanden sie den davon Betroffenen aktivierungsbezogene Transparenz zu.
Hier wird der bei der Definition von Vorgangsbearbeitungssystemen übliche Rollenbegriff benutzt. Dieser unterscheidet sich vom ansonsten hier genutzten Rollenbegriff (vgl. Kap. 2.3).
Rights and permissions
Copyright information
© 1997 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Wulf, V. (1997). Konfliktmanagement bei Vorgangsbearbeitungssystemen. In: Konfliktmanagement bei Groupware. Vieweg+Teubner Verlag, Wiesbaden. https://doi.org/10.1007/978-3-322-89553-0_9
Download citation
DOI: https://doi.org/10.1007/978-3-322-89553-0_9
Publisher Name: Vieweg+Teubner Verlag, Wiesbaden
Print ISBN: 978-3-528-05576-9
Online ISBN: 978-3-322-89553-0
eBook Packages: Springer Book Archive