POLIVEST
Integrierte Televerwaltung
Clemens Dietel, Georg Schneider, Dr. Jean Schweitzer
Zusammenfassung:
Der Einsatz moderner Informationstechnologie revolutioniert die Arbeitswelt. Eine Schlüsselrolle spielen dabei neue Arbeitsformen mit integrierter Telekooperation. Die Bandbreite der zu unterstützenden Verwaltungsprozesse macht den Einsatz von integrierten Lösungen notwendig, die sowohl synchrone (Multimediale AV-Desktopkonferenzen) wie auch asynchrone (Workflow Management Systeme) Arbeitsweisen unterstützen. Die Übergänge zwischen den Systemen spielen dabei eine entscheidende Rolle.
Nach einer Klassifizierung der unterschiedlichen Arten von MM-Telekonferenzen wird der Übergang von asynchroner zu synchroner Arbeitsweise und umgekehrt aus technischer, organisatorischer und sozialpsychologischer Sicht untersucht. Abschluß ist eine Beschreibung der Integration von Workflow Management System und synchroner Telekooperation im POLIVEST Pilotfeld Rhein-Sieg-Kreis.
1. EinleitungMit der modernen Informationstechnologie hat ein neues Zeitalter der Arbeit begonnen, die Möglichkeiten der Zusammenarbeit wurden revolutioniert. Schon heute kommunizieren Menschen über große Entfernungen miteinander und bearbeiten Vorgänge zeitgleich. Elektronische Brücken verbinden weit voneinander entfernte Schreibtische. Im Projekt POLIKOM geht es um die standortverteilte Kooperation in der Verwaltung, aber auch in der Wirtschaft. Durch die Zusammenarbeit von Systementwicklern, Wissenschaftlern und Anwendern werden Systemlösungen in konkreten Anwenderfeldern erprobt und evaluiert. Durch die Umsetzung von Anwenderansprüchen sollen Anreize für die Wirtschaft geschaffen werden.
Im Zentrum des POLIKOM Forschungsprojekts steht die Optimierung der administrativen Organisation:
Ausgangspunkt ist der Einsatz von moderner IT Technik am Arbeitsplatz in ausgewählten Pilotfeldern. Dabei sollen die anfallenden Aufgaben in einer integrierten Arbeitsumgebung mediengestützt erledigt werden, Medienbrüche sollen vermieden werden, Informationen sollen orts- und zeitunabhängig zur Verfügung stehen. Eine Schlüsselrolle spielt dabei die Erprobung neuer Arbeitsformen mit Telekooperation. Telekooperation hat dabei das Ziel:
Unter den Namen POLIVEST wird eine neue, vernetzte Ebene entwickelt, auf der unterschiedliche Behörden effizient, flexibel und schnell zusammenarbeiten. Ziel der Projekts ist die praxisreife Entwicklung einer automatischen verwaltungsübergreifenden Vorgangsbearbeitung unter Einsatz synchroner Telekooperation. Zwei exemplarische Anwendungsfelder zeigen, was moderne Informationstechnologie möglich macht. Prototypen für die POLIVEST-Erprobung sind
und
In diese beiden Anwendungsfelder sind letztlich alle Ebenen der öffentlichen Verwaltung (s. Bild 1) involviert und es müssen Anforderungen von schwach bis zu hoch strukturierten Verwaltungsprozessen erfüllt werden.
Abb. 1: Positionierung der Pilotfelder in der Verwaltungshierarchie
Die Bandbreite der zu unterstützenden Verwaltungsprozesse macht den Einsatz von integrierten Lösungen notwendig, die sowohl synchrone (Multimediale AV-Desktopkonferenzen) wie auch asynchrone (Workflow-Management-Systeme) Arbeitsweisen unterstützen.
Im folgenden wird die Integration der Teleworkingkomponenten untersucht.
2. Integration von Workflow und TelekooperationWorkflow-Management-Systeme sind ein Mittel, Arbeitsabläufe zu strukturieren und geregelt und systemunterstützt ablaufen zu lassen. Ein Nachteil der bisher existierenden Systeme ist jedoch, daß diese Arbeitsabläufe relativ starr mit dem System verdrahtet sind, d.h. Ausnahmeregelungen werden oftmals nur unzureichend unterstützt. Ein situationsabhängiges Reagieren auf nicht vorhersehbare Ereignisse ist somit keine Stärke von Workflow-Management-Systemen, ebenso können Arbeitsschritte, die auf die Interaktion mehrerer Personen angewiesen sind, nicht berücksichtigt werden. Diese Problemklasse wird allerdings durch multimediale Audio/Video Desktopkonferenzsysteme (kurz: MM-Konferenzsysteme) unterstützt, die synchrone Audio/Video Verbindungen ermöglichen und das gemeinsame Bearbeiten von Dokumenten durch "application sharing". In einer MM-Konferenz kann unmittelbar zu anderen Stellen Kontakt aufgenommen werden und es können gemeinsam Dokumente bearbeitet werden. Die beiden Systemklassen ergänzen sich somit hinsichtlich der Arbeiten die sie unterstützen. Durch Integration von Workflow-Management- und MM-Konferenzsystemen [SMDSS 96] kann die Lösung von Problemen unterstützt werden, die bisher keines der Systeme alleine bewältigen konnte. Da die Arbeitsweisen in den beiden Systemen jedoch sehr unterschiedlich sind, auf der einen Seite asynchrone Kooperation einzelner Mitarbeiter und auf der anderen Seite synchrone Kooperation eines Teams, werden weiterführende Unterstützungsmöglichkeiten für die Mitarbeiter an der Schnittstelle zwischen den Systemen benötigt.
Abb. 2: Integration von Workflow-Management- und MM-Konferenzsystem
Somit werden einerseits die Synergieeffekte verstärkt, andererseits wird der Weg zu einer einheitlichen Plattform, bei der die unterschiedlichen Arbeitsweisen nahtlos ineinandergreifen, begangen. Abbildung 2 beschreibt das grundsätzliche Integrationskonzept [SWS 97].
Aus einem Workflow wird eine MM-Konferenz initiiert. An dieser Konferenz partizipieren mehrere Bearbeiter, sowohl solche, die an das Workflow-Management-System angeschlossen sind, als auch solche, die nur über ein MM-Konferenzsystem verfügen und als externe Berater hinzugezogen werden. In dieser Konferenz wird gemeinschaftlich an Dokumenten gearbeitet. Nach Beendigung aller Konferenzaktivitäten wird der Workflow gemäß der Konferenzergebnisse fortgesetzt.
Im folgenden werden zunächst Unterscheidungmerkmale der unterschiedlichen Konferenztypen aufgezeigt
2.1 Merkmale unterschiedlicher MM-TelekonferenzenUm einen Formalismus zu schaffen, wie MM-Konferenzen hinsichtlich ihrer Integration in Workflow-Management-Systeme und hinsichtlich der Arbeitsweise in den Konferenzen und den damit verbundenen Auswirkungen auf den Workflow zu charakterisieren sind, unterscheiden wir zwischen Prozeßaktivitäten und Konferenzaktivitäten.
Prozeßaktivität [WfMC 95]:
"Ein logischer Schritt oder die Beschreibung eines Arbeitsteils, der zur Vollendung eines Prozesses beiträgt. Eine Prozeßaktivität kann eine manuelle Prozeßaktivität und/oder eine automatische Workflow-Prozeßaktivität sein."
Im Gegensatz dazu wird eine Aktivität, die in einer MM-Konferenz ausgeführt wird, als Konferenzaktivität bezeichnet [SWS 97]. Naturgemäß arbeiten hierbei mehrere Personen zusammen.
Der Begriff Konferenzaktivität ist wie folgt definiert:
"Eine Konferenzaktivität ist ein logischer Schritt oder die Beschreibung eines Arbeitsteils, der zur Vollendung einer Konferenz beiträgt. Eine oder mehrere Konferenzaktivitäten können einzeln oder zusammengefaßt eine Prozeßaktivität bilden."
Eine Beschränkung auf eine 1:1 Relation zwischen Prozeß- und Konferenzaktivität ist nicht notwendig, 1:n Beziehungen sind gleichfalls möglich.
Ist jede Konferenzaktivität eine Prozeßaktivität, was einer 1:1 Relation entspricht, handelt es sich bei der Konferenz um einen (Sub-)Workflow (Abb. 3, linke Seite).
Abb. 3: 1:1 versus 1:n Relation
Bei 1:n Relationen ist die Konferenz aus Sicht des Workflow-Management-Systems eine einzelne Prozeßaktivität, während der mehrere Konferenzaktivitäten unsichtbar für das Workflow-Management-System ausgeführt werden. Eine Prozeßaktivität stößt somit mehrere Konferenzaktivitäten an (Abb. 3, rechte Seite). In diesem Fall wird die Ablaufsteuerung vom Workflow-Management-System auf das Konferenzsystem übertragen. Die teilweise relativ unflexible "Verdrahtung" in Workflow-Management-Systemen kann somit durch einen flexibleren Mechanismus ersetzt werden.
Diese Vorüberlegungen helfen bei der Unterscheidung von MM-Konferenzen in Bezug auf die Kriterien Modellierungszeitpunkt und Koordination der Konferenz. An Hand dieser Kriterien spannt sich der Klassifikationsraum für Konferenzen auf [SBS 97].
2.1.1 ModellierungszeitpunktBetrachtet man den Zeitpunkt, zu dem das Auftreten einer Konferenz in einem Arbeitsablauf modelliert wird, kann man zwei Zeitpunkte unterscheiden:
Konferenzen, die bereits zum Entwicklungszeitpunkt des Workflows vorgesehen sind, werden als geplante Konferenzen bezeichnet. Sie sind in die Vorgangsbearbeitung fest integriert.
Im Gegensatz dazu stehen ad-hoc Konferenzen, bei denen nicht vorhersehbar ist, wann sie stattfinden. Dies kann z.B. auf Grund eines unvorhersehbaren Problems geschehen. Das Aufrufen einer Konferenz hängt hierbei von der aktuellen Situation ab, die erst zum Ablaufzeitpunkt bekannt ist. Zum Entwicklungszeitpunkt sind keine Informationen über diese Konferenz verfügbar.
2.1.2 Koordination der KonferenzEin weiteres Unterscheidungskriterium ist, wie bzw. von wem die Konferenz geleitet, bzw. koordiniert wird [RSVW 94]. Wird die Konferenz vom Workflow-Management-System geleitet, sprechen wir von statischen Konferenzen, leitet ein Teilnehmer die Konferenz, von dynamischen Konferenzen.
Bei statischen Konferenzen ist der Konferenzverlauf detailliert beschrieben und kann daher durch einen Workflow modelliert werden [Jabl 94]. Die Konferenzaktivitäten stehen fest, folglich hat die Konferenz eine relativ starre, unflexible oder statische Struktur (1:1 Relation). Sämtliche Konferenzaktivitäten sind dem Workflow-Management-System bekannt. Als Konsequenz ergibt sich, daß das System die Konferenz unterbrechen und an diesem Punkt wieder aufrufen kann.
Die Ausführung der dynamischen Konferenzen (1:n Relation) ist hingegen frei und erlegt den Teilnehmern keine Einschränkungen hinsichtlich der Ausführung und Organisation der Konferenz auf. Die Koordination ist allein ihnen überlassen. Dadurch soll sich die volle Dynamik und Kreativität der Gruppenarbeit entfalten können. Der Konferenzinhalt wird mit Hilfe eines Agenda Editors beschrieben. Das Workflow-System kann die Konferenz nicht unterbrechen und an diesem Punkt wieder aufrufen. Der relativ restriktive, konventionelle Workflow-Mechanismus wird hierbei aufgeweicht, um kooperatives Arbeiten in der Gruppe besser zu unterstützen, beispielsweise durch die Möglichkeit Konferenzaktivitäten zu vertagen.
2.2 Arten der IntegrationIm folgenden Abschnitt werden die Integrationsarten beschrieben und in einigen Beispielen verdeutlicht.
Abb. 4: Mögliche Konferenztypen
Die in Abbildung 4 beschriebenen Konferenztypen dienen weiterhin dazu, die Zeitpunkte zur Bestimmung der für die Konferenz notwendigen Informationen festzulegen. Für ad-hoc Konferenzen bedeutet dies, daß fast alle Parameter zum Zeitpunkt des Aufrufs der Konferenz ermittelt werden müssen, es können höchstens intelligente Hilfen zur deren Ermittlung zur Verfügung gestellt werden. Bei geplanten Konferenzen können zwar Teilnehmer und Konferenzaktivitäten (im allgemeinen Sprachgebrauch üblicherweise als Tagesordnungspunkte bezeichnet) zum Modellierungszeitpunkt des Workflows festgelegt werden, die Bestimmung des Konferenztermins und die Auflösung von Rollen und Stellen kann beispielsweise jedoch erst zu dem Zeitpunkt ermittelt werden, an dem die Konferenz zur Ausführung ansteht.
Zuerst werden wir die Integrationsarten der geplanten Konferenzen beschreiben, dann die der ad-hoc Konferenzen (siehe Abb. 4). Kombinationen zwischen den verschiedenen Extremen sind ebenfalls möglich, auf sie wird hier jedoch nicht weiter eingegangen.
2.2.1 Dynamische geplante KonferenzenDas Stattfinden einer Konferenz dieses Typs ist im Workflow bereits zum Modellierungszeitpunkt vorgesehen. Die zu bearbeitenden Inhalte werden als Konferenzaktivitäten vor, bzw. während der Konferenz ermittelt.
Ein Beispiel für diesen Konferenztyp ist ein Antrag beim deutschen Umweltministerium. Nach einigen Routinearbeiten, wie der Kontrolle der beigefügten Anlagen und der Vergabe eines Aktenzeichens, stimmen die betroffenen Abteilungsleiter die weitere Verfahrensweise in einer Konferenz ab. Diese Konferenz würde auf Grund ihres informellen Charakters eher als "Meeting" bezeichnet werden.
Während der Konferenz wird nach einer kurzen Einführung der Antrag geprüft und über die zukünftige Verfahrensweise entschieden. Falls Unklarheiten bestehen, werden weitere Mitarbeiter befragt und zur Konferenz hinzugezogen. Als Resultat der Konferenz wird in die passenden (Sub-) Workflows verzweigt. Die Vorgehensweise in der Konferenz kann mit konventionellen Workflow-Methoden kaum unterstützt werden, da die Konferenz einen stark informellen Charakter hat. Hier wäre eine fest vorgeschriebene Vorgehensweise zu starr.
2.2.2 Statische geplante KonferenzenStatische geplante Konferenzen sind komplett als Teil eines Workflows modelliert, sie sind ebenfalls (Sub-)Workflows. Das Workflow-Management-System benutzt die besondere Ressource MM-Konferenz um diesen Subworkflow auszuführen. Die Konferenzausführung wird vom Workflow-Management-System geleitet und protokolliert.
Ein Beispiel für diesen Konferenztyp ist eine Anhörung, nach der entschieden wird, in welche Richtung sich der Workflow verzweigen soll. Zuerst legen verschiedene Mitarbeiter ihre Standpunkte dar, danach wird von einem Abteilungsleiter eine Entscheidung über das weitere Verfahren getroffen. Diese Entscheidung muß begründet und von einem weiteren Abteilungsleiter autorisiert werden.
Wie das Beispiel zeigt, sind die Aktivitäten und deren Reihenfolge vorgegeben. Somit kann die Konferenz als Workflow modelliert werden, der dann ebenfalls die ordnungsgemäße Ausführung der Konferenzaktivitäten garantiert.
2.2.3 Dynamische ad-hoc KonferenzenAd-hoc Konferenzen sind nicht vorhersehbar und können deshalb zum Modellierungszeitpunkt im Workflow nicht berücksichtigt werden. Situationen in denen sie auftreten sind alltägliche Probleme, wie Softwareprobleme oder Rückfragen bei Vorgesetzten. In dem Fall, daß bei Aktivität "z" (siehe Abb. 3, linke untere Ecke) ein Problem auftaucht, kann es durch eine Konferenz unmittelbar behoben werden. Danach wird die Arbeit an "z" fortgesetzt.
2.2.4 Statische ad-hoc KonferenzenStatische ad-hoc Konferenzen sind von Anfang an ebenfalls nicht Teil des Workflows. Im Gegensatz zu dynamischen ad-hoc Konferenzen beschreiben sie jedoch eine Standardsituation in der die Konferenzteilnehmer einem bestimmten Prozedere unterliegen.
Beispiele hierfür sind Kompensationsreaktionen. Eine Prozeßaktivität wurde fehlerhaft ausgeführt. Dies wird in einem späteren Arbeitsschritt von einem anderen Workflow-Teilnehmer bemerkt. Normalerweise besitzt er nicht die Zugriffsrechte, um die entsprechenden Änderungen vorzunehmen. In einer Konferenz mit dem vorherigen Bearbeiter könnte dieser Fehler unmittelbar und ohne Wartezeiten behoben werden. Die Aktivität "z" (siehe Abb. 3, rechte untere Ecke) wird unterbrochen und eine MM-Konferenz mit dem betroffenen Bearbeiter einberufen. Gemeinsam wird der Fehler korrigiert. Eine gemeinsam verfaßte Notiz protokolliert die Änderung. Danach wird der Workflow wie vorhergesehen mit der Aktivität "z" fortgesetzt.
Da diese Vorgehensweise wohlstrukturiert ist, kann sie als Workflow modelliert werden. In der entsprechenden Situation wählen die Bearbeiter den passenden Unterstützungs-Workflow aus, der sie dann durch die Konferenz führt und die Ergebnisse festhält. Folglich koordiniert das System die Konferenz. Durch diese Vorgehensweise wird zusätzlich die hohe Ausführungsqualität durch das Workflow-Management-System garantiert. Diese Subworkflows können auch als eine Art Fallbibliothek für Lösungen häufiger auftretender Probleme angesehen werden.
Im folgenden wird die Schnittstelle, d.h. der "Zwischenraum" zwischen den Systemen näher beleuchtet. Die Konzepte sollen dabei zu einem system-unabhängigen, transportablen Ansatz führen, der unterschiedliche Systeme der Systemklassen "Workflow-Management-Systeme" und "MM-Konferenzsysteme" unterstützt [ScSc 96].
2.3 Der Telekooperations-WorkspaceDer Telekooperations-Workspace kann daher aus verschiedenen Perspektiven betrachten werden, nämlich aus technischer Sicht, aus organisatorischer Sicht und aus sozialpsychologischer Sicht. Während die technische Sicht systemische Probleme in den Vordergrund stellt, wie Systemauruf, Dokument- und Parameterübergabe, etc., orientiert sich die organisatorische Sicht an den Arbeitsabläufen. Die sozialpsychologische Sicht wiederum stellt das Team und die Interaktion zwischen seinen Mitgliedern in den Vordergrund.
Im folgenden wird auf die letzten beiden Kriterien eingegangen. Die technologische Sicht wird in [WSPHSS 97] näher erläutert.
Aus organisatorischer und sozialpsychologischer Sicht sind folgende drei Elemente des Telekooperations-Workspace von besonderem Interesse (siehe Abb. 5).
Abb. 5: Der Telekooperations-Workspace
Es handelt sich hierbei um Zeit, Mitarbeiter und Informationen. Zuerst wird auf den Problemkreis der Ressourcenallokation eingegangen, der die Zuweisung von Mitarbeitern und Terminen zu Konferenzen zum Gegenstand hat, danach wird darauf eingegangen, wie die Wissenssynchronisation der einzelnen Mitarbeiter vom System unterstützt werden kann.
2.3.1 Ressourcenallokation
Der erste Problemkreis umfaßt den Bereich des Teko-Workspace zwischen Kalender und Mitarbeitern. Es muß eine Allokation der Ressourcen "Time Ressources" und "Human Ressources" stattfinden, bzw. deren Zuordnung zu Konferenzen.
2.3.2 Auswahlkriterien
Die Wahl des Konferenztermins unterliegt normalerweise ebenso gewissen Freiheitsgraden, wie die Zuordnung von Aktivitäten zu Bearbeitern bei Workflow-Management-Systemen. Hier sind sie durch Zuordnungen über Kompetenzen, Rollen und Stellen zu Aufgaben gegeben (wie beispielsweise "Abteilungsleiter", Sachbearbeiter", "Zeichnungsbevollmächtigter" usw.).
Aus organisatorischer Sicht können durch eine Rollenauflösung nach dem Prinzip "schnellstmöglicher Sitzungstermin" die Teilnehmer so zusammengestellt werden, daß die Konferenz zu dem frühestmöglichen Termin stattfindet.
Die Zuordnung von Mitarbeitern und Kompetenzen zu Terminen unter Berücksichtigung sozialpsychologischer Ziele wird für die Auswahl von Teilnehmern für MM-Konferenzen wichtig, wenn eine zügige und erfolgreiche Abarbeitung der Konferenzen gewünscht wird. Erfolglose und langwierige Konferenzen führen zu Verzögerungen im Workflow und sind somit kontraproduktiv. Bei der Auswahl der Konferenzteilnehmer sollen ebenfalls Eignungsbeschränkungen berücksichtigt werden, um ein Team für eine Konferenz zusammenzustellen, so daß erwartet werden kann, daß es zu einem möglichst guten Konferenzergebnis gelangt.
Eine Konkretisierung der Rollen, Stellen und Kompetenzen auf Mitarbeiter kann dann anhand der folgenden Kriterien stattfinden:
Eine Kombination mehrerer Kriterien ist ebenfalls denkbar.
Orthogonal zu diesen Kriterien können ebenfalls die Rechte des Konferenzleiters oder "Facilitators" [Maie 63] einem der Teammitglieder zugewiesen werden, wodurch ein weiterer Optimierungsprozeß innerhalb des Teams durchgeführt wird.
2.3.3 Grundlagen zur Realisierung der Auswahlkriterien
Beim Kriterium "bestes Team" muß auf ein Team Ranking zurückgegriffen werden. Dieses Ranking kann durch mehrere Verfahren ermittelt werden. Beispiele hierfür sind Kriterien, wie Konferenzdauer und -erfolg, d.h. wurden beispielsweise alle Aufgaben erfolgreich in der Konferenz absolviert.
Ein andere Möglichkeit sind Einzelbefragungen der Konferenzteilnehmer. Durch Auswertung von Fragebögen, die nach der Konferenz verschickt werden, werden Kriterien überprüft, die eine Konferenzbewertung zulassen.
Die Randbedingungen und die Reihenfolge der organisatorischen, technischen und sozialpsychologischen Ziele können beispielsweise auf Constraints abgebildet werden (siehe [MSH 97] oder [MMPSS 96]).
2.4 Briefing und Debriefing
Briefing und Debriefing dienen dazu, Informationen aus dem Workflow in die Konferenz zu übertragen und umgekehrt. Das Briefing ist hierbei ein Mittel die Synchronisation des Wissens der Teammitglieder zu unterstützen.
[Schn 85] stellt heraus, daß eine ausführliche Aufgabenbeschreibung zu einem besseren Konferenzergebnis führt. In [BKLS 95] werden Beispiele aufgeführt, bei denen sich schlechte Vorbereitung negativ auf das Konferenzergebnis auswirkt.
Grundsätzlich wird in Workflow-Management-Systemen davon ausgegangen, daß ein Bearbeiter die Informationen besitzt, die zur Bearbeitung einer anstehenden Tätigkeit benötigt werden. Somit sind ausführliche Aufgabenbeschreibungen zur Abarbeitung von Aktivitäten in diesen Systemen nicht vorgesehen (beispielsweise [IBM 95], [SNI 95]). Ein Bearbeiter hat weiterhin entweder gar keine oder nur unzureichende Möglichkeiten, sich Kontextinformation über seine Arbeit im Workflow zu beschaffen.
2.4.1 Benutzeradaptive Beschreibungen mit Hilfe von Benutzermodellen
Aus organisatorischer Sicht müssen alle Bearbeiter beim Übergang in eine Konferenz auf den gleichen Kenntnisstand über die Aktivitäten gebracht werden, die Gegenstand der Konferenz sein werden. Somit wird garantiert, daß die Konferenz effektiv abgehalten werden kann. Hierzu muß ihnen eine detaillierte, benutzer- und situationsangepaßte Aufgabenbeschreibungen für diese Aktivitäten zur Verfügung gestellt werden.
Situationsabhängig heißt hierbei, daß die Nachricht sowohl an das Medium angepaßt sein muß, über das sie kommuniziert wird (z.B. Email, Video, etc.) als auch an die Bearbeiter.
Benutzerabhängig heißt hierbei, daß ein Benutzermodell erstellt wird, welches die Vorkenntnisse eines Bearbeiters erfaßt, um so ein Briefing auf ihn zuschneidern zu können. Da in Workflow-Management-Systemen vorgangs-spezifische Historiendaten vorhanden sind, die bei der Abarbeitung des Workflows gespeichert werden, kann auf diese Daten zugegriffen [SSS 96] werden.
Hinsichtlich des Benutzermodells können drei Stereotypen unterschieden werden [Rich 89].
Folglich benötigen Bearbeiter, der bereits in der Instanz des Workflows mitgearbeitet hat weniger Informationen über diese Instanz, als ein "Außenstehender".
2.4.2 Domänenwissen
Das Domänenwissen ist ebenfalls im Workflow-Management-System durch die Prozeßdefinitionen vorhanden. Um Systemunabhängigkeit zu gewährleisten, muß die Beschreibung in eine Zwischensprache übersetzt ([Lehm 97], [WoTel 96]) werden, welche die zu kommunizierende Information enthält. Sie soll einerseits an Standards angelehnt sein (beispielsweise [WfMC 95]), andererseits muß sie auf das Problem (Generierung von Beschreibungen) zugeschnitten sein.
2.4.3 Natürlichsprachliches Briefing
Das Briefing wird in Form einer natürlichsprachigen Nachricht durchführt werden, um die Benutzerakzeptanz zu steigern. Die Umsetzung der Beschreibung in natürliche Sprache kann beispielsweise durch Templates realisiert werden [LRR 96], wofür sowohl der beschränkte Problemkreis, als auch Effizienzgründe [Reit 95] sprechen.
[Maie 63] hat einen Kriterienkatalog für diese Art der Kommunikation aufgestellt, der hierbei ebenfalls zu berücksichtigen ist, wie: situationelle Begriffe benutzen, keine konkreten Lösungsvorschläge äußern, Interesse aller Beteiligten berücksichtigen, etc.
2.4.4 Debriefing
Für den Weg aus der Konferenz in das Workflow-Management-System müssen die Konferenzergebnisse aufbereitet und zu einem Protokoll verdichtet werden. Dieses enthält die Resultate der Konferenz und wird nach der Sitzung verschickt. Es dient dazu den Mitarbeitern den Kontext für die weitere Arbeit im Workflow zu liefern.
2.5 Aspekte der Systemarchitektur
Aus technischer Sicht stehen Fragestellungen der Systemintegration im Vordergrund. Eine integrierte, generische Plattform zeigt Abbildung 3. Eine Realisierung durch Broker wird in [WPSSS 97] eingehend erläutert.
Im Vordergrund steht hierbei, den Übergang zwischen dem Arbeiten mit dem einen System zum Arbeiten mit dem anderen System möglichst reibungslos zu gestalten. Dies wird dadurch erreicht, daß die Systeme zum computergestützten kooperativen Arbeiten mit einem Telekooperationsmanager verbunden werden, der Vermittlungs-dienste leistet. Er besteht aus einer Steuerungskomponente, die mit einem Applikations Manager und einem Informations Manager kommunziert. Der Applikations Manager hat Zugriff auf unterschiedliche Applikationen, die zur Unterstützung dienen, wie ein Terminplaner, eine Briefing Komponente, ein Agenda Editor, etc.. Der Informations Manager hat Zugriff auf die unterschiedlichen Datenbasen der einzelnen Systeme. Er hat auf die Gesamtheit der Daten eine ganzheitliche, integrierende Sicht.
3. Beispiel: Baugenehmigungsverfahren im RSK
Im Rhein-Sieg-Kreis wird das gesamte Baugenehmigungsverfahren als Workflow-Modell reorganisiert. Die Umsetzung erfolgt mit WorkParty Team Edition und Smart Assist.
Innerhalb des Verfahrens ergeben sich Ansatzpunke für die Integration von synchroner Telekooperation. Das ist immer dann der Fall, wenn mehr als eine Person an der Entscheidungsfindung beteiligt ist, wenn z.B. der Architekt in das Genehmigungsverfahren einbezogen wird. Der Fall, der hier näher beschrieben werden soll, ist die Durchsprache des Vorprüfberichts zwischen dem Bauaufsichtsamt der Kreisverwaltung in Siegburg und dem Hochbauamt der Gemeindeverwaltung in Wachtberg.
Nach dem Eingang eines Bauantrages in der Kreisverwaltung wird dieser zunächst klassifiziert, mit einem Aktenzeichen versehen und vom Sachgebietsleiter dem zuständigen Sachbearbeiter übermittelt. Dieser prüft die Vollständigkeit der Unterlagen und übersendet diese nach Prüfung, welche verwaltungsinternen und -externen Stellen am Verfahren beteiligt werden müssen, an die Gemeinde-verwaltung. Dort wird ein neues Aktenzeichen vergeben und der sogenannte Vorprüfbericht erstellt.
Im Vorprüfbericht werden Stellungnahmen von unterschiedlichen Stellen (Tiefbauamt, Gemeindewerke, etc.) erfaßt, wobei eine planungsrechtliche Prüfung vorgenommen wird und eventuelle Auflagen formuliert werden. Am Ende dieses Teilprozesses steht das Übermitteln des mit Unterschriften versehenen Vorprüfberichts per Kurier in die Kreisverwaltung.
Unklarheiten im Vorprüftbericht und die damit einhergehenden Diskussionen, Überarbeitungen und Wiederverschickungen des Berichts führen zu Zeitverzö-gerungen. An dieser Stelle wird der Prozeß durch den Einsatz von synchroner Telekooperation unterstützt bzw. optimiert. Es werden zwei Varianten der Integration von Telekooperation untersucht und später im Pilotfeld evaluiert:
3.1 Standardtätigkeit Telekooperation in WorkParty
Die Einführung einer Standardtätigkeit Telekooperationssitzung, d.h. der Aufruf von MM-Konferenzen aus WorkParty mit Hilfe von Informationen aus dem Workflow Management System, bedeutet eine sehr enge Kopplung von WfMS und MM-Konferenzsystem. Er eignet sich vom allem bei Workflows, in denen eine Konferenz möglichst gut antizipiert werden kann, sowohl zeitlich als auch inhaltlich. Die Konferenz kann in diesem Fall beispielsweise als geplante statische Konferenz realisiert werden. Das Erfassen der weiteren, zum Aufrufen der Konferenz notwendigen Informationen wird über WorkParty und den Telekooperations Manager organisiert. Nach dem Instantiieren der Teilnehmer und dem Auswählen des Konferenztermins wird dann ein Briefing an die Konferenzteilnehmer verschickt, welches sie einlädt, ihnen die notwendige Hintergrundinformation liefert und sie über die bevorstehenden Aufgaben informiert. Zum festgesetzten Zeitpunkt wird dann die Konferenz einberufen.
Zum Erfassen der Konferenzergebnisse während der Konferenz dient der Protokoll Assistent (Abb. 6). Im Konferenzprotokoll werden Zeiten und Tagesordnungspunkte mit Status (bearbeitet, nicht bearbeitet), Piorität (obligatorisch, optional, verschiebbar) und voraussichtlicher Dauer eingetragen. Zum Bearbeiten eines Tagesordnungspunktes wird dieser angewählt und ein spezielles Fenster baut sich auf, um die Ergebnisse festzuhalten (beispielsweise Editor bei textueller Eingabe, Toggles bei Ja/Nein Entscheidungen, Radio Button Auswahl zwischen mehreren Alternativen etc.). Obligatorische Tagesordnungspunkte müssen bearbeitet werden, um eine Konferenz erfolgreich zu beenden. Werden sie nicht bearbeitet muß die Konferenz nochmals neu einberufen werden.
Abb. 6: Bearbeitung der Konferenztätigkeiten mit Protokollassistent
Nach dem Ende der MM-Konferenz werden als Ergebnis der Konferenz, z.B. das positive Ende der Konferenz (alle obligatorischen TOPs mit Erfolg durchgeführt) oder die erstellten Dokumente, in den Prozeß (die Vorgangsmappe) übertragen. Die Ergebnisse sind für den weiteren Verlauf des Workflows relevant und können z. B. als Entscheidungskriterien beim Verzweigen innerhalb des Workflows dienen. Weiterhin findet nach der Konferenz ein Debriefing statt, bei dem den Konferenzteilnehmern ein Sitzungsprotokoll zugesandt wird, welches auch zu den Akten (Vorgangsmappe) als Dokumentation der Konferenz zugefügt wird.
3.2 Smarty Telekooperationssitzung
Um möglichst flexibel auf Konferenzwünsche eingehen zu können, wird die Definition eines Subworkflows Telekooperationssitzung inklusive Vorbereitung, Durchführung und Nachbereitung mit Hilfe von SmartAssist durchgeführt. Der dabei entstandene Miniworkflow wird als Smarty ablauffähig abgelegt (ad-hoc Konferenz).
Bei dieser Vorgehensweise können zwar auch Informationen aus dem WfMS übernommen werden, es wird aber die Möglichkeit gegeben, unterstützt durch entsprechende Assistenten das System zum Zeitpunkt der Konferenzplanung manuell mit den notwendigen Informationen zu versorgen. Dieses Verfahren eignet sich vor allem auch dazu, MM-Konferenzen außerhalb eines Standard-WfMS wie WorkParty zu planen und durchzuführen. Ein Smarty besteht dabei mindestens aus den Teilen:
Neben Konferenzname, Thema und Uhrzeit werden Informationen zu den einzelnen Tagesordnungspunkten innerhalb der Konferenz erfragt. Diese werden bei der Durchführung verwendet, um Ergebnisse zu erfassen und diese später bei der Konferenzdurchführung in ein Protokoll zu übertragen.
Nach dem Beenden des Smartys können alle Konferenzinformationen entweder WorkParty als übergeordnetem WfMS übertragen werden (ähnlich wie im Fall der Standardtätigkeit Telekooperation) oder im Falle der autarken MM-Konferenz entweder in ein Konferenz-Repository abgelegt werden.
Abb. 7: Vorbereiten der Sitzung
4. Zusammenfassung und Ausblick
In der ersten Phase des POLIVEST Projektes lag der Schwerpunkt auf der Installation der Systeme beim Anwender und der Anwenderschulung und Unterstützung beim Systemeinsatz. Als Ergebnis wird im Rhein-Sieg Kreis ab August 1997 auf elektronische Bearbeitung der Bauanträge mittels WorkParty [SNI 95] umgestellt, in den Innenministerien der beteiligten Bundesländer und im Ausschußbüro für innere Angelegenheiten wurde das Arbeiten mit AV Konferenzsystemen erfolgreich etabliert. Die 2. Phase beschäftigt sich die nunmehr schwerpunktmäßig mit der Weiterentwicklung der Integration der nun im Einsatz befindlichen Systeme.
In diesem Papier haben wir ein Konzept im Hinblick auf die Integration zwischen Workflow-Management- und MM-Konferenzsystem dargestellt, welches den Problemkreis von mehreren Seiten beleuchtet. Hierbei fokussieren wir besonders auf die weitergehende Anwenderunterstützung und die einfachere Integration von Teamarbeitsprozessen.
Die Konzepte werden derzeit prototypisch realisiert und evaluiert. Im nächsten Schritt werden sie sukzessiv beim Anwender eingeführt und weiterentwickelt
Wir danken Astrid Scheller-Houy, Heiko Maus und Ruppert von Teutul für Input und Mitarbeit.
5. Literatur[BKLS 95] Barent, V., Krcmar, H., Lewe, H., Schwabe, G., Improving Continuous Improvement with CATeam: Lessons from a longitudinal case study, in: Proceedings of the 28th Hawaii International Conference on System Sciences, 1995
[Ha Bu 94] A. Haddadi, S. Bussmann, Scheduling Meetings by Multi-Agent Negotiation, in: CAIA-94 Workshop on Coordinated Design and Planning, San Antonio, Texas, ftp://cdr.stanford.edu/pub/caia-wrkshp, 1994
[IBM 95] IBM: IBM FlowMark - Programming Guide, Version 2.1, 1995.
[Jabl 94] Jablonski, S., MOBILE: A Modular Workflow Model and Architecture, in: Proceedings of the Fourth International Conference on Dynamic Modelling and Information Systems, Noordwijkerhout, The Netherlands, 1994
[LRR 96] B. Lavoie, O. Rambow, E. Reiter, The Model Explainer, Demonstrations and Posters, INLG 96, Herstmonceux Castle, Sussex, UK, 1996
[Lehm 97] F. Lehmann, Gebrauchssprachliche Modellierungsmethoden, in S. Jablonski, M. Böhm, W. Schulze, (Hrsg.), Workflow-Management - Entwicklung von Anwendungen und Systemen - Facetten einer neuen Technologie, dpunkt.verlag Heidelberg, 1997
[LiSy 94] J. S. Liu, K. P. Sycara, Distributed Constraint-directed Meeting Scheduling, in: CAIA-94 Workshop on Coordinated Design and Planning, San Antonio, Texas, ftp://cdr.stanford.edu/pub/caia-wrkshp, 1994
[Maie 63] N. R. F. Maier, Problem-solving Discussions and Conferences: Leadership Methods and Skills, McGraw-Hill Book Company, New York 1963
[MMPSS 96] M. Mehl, T. Müller, K. Popow, R. Scheidhauer, C. Schulte, DFKI Oz User's Manual, http://www.ps.uni-sb.de/oz/documentation/
[MSH 97] H. Meyer auf'm Hofe, S. Schwarz, A. Hoffmann, Ein System zur Auswertung von Constraints der flexiblen Personaleinsatzplanung im Pflegedienstbereich - Programmdokument, http://www.dfki.uni-kl.de/conplan/conplan3/conplan3.html
[Reit 95] E. Reiter, NLG vs. Templates, in: Proc. Of the fifth european workshop on language generation, Leiden, the Netherlands, Rijks universiteit, 1995
[Rich 89] E. Rich, Stereotypes and User Models, in: A. Kobsa, W. Wahlster, User Models in Dialog Systems, Springer, Berlin 1989
[RSVW 94] Reinhard, W., Schweitzer, J., Völksen, G., Weber, M., CSCW Tools: Concepts and Architectures, in: IEEE "Computer", May 1994, Vol. 27, No.5
[SBS 97] G. Schneider, S. Baumann, J. Schweitzer, Integrating and coordinating major software systems with workflow management systems, in: D.T. Wright, M.M. Rudolph, V. Hanna, D. Gillingwater, N.D. Burns (Hrsg.), Tagungsband "Managing Enterprises - Stakeholders, Engineering, Logistics and Achievement", 22-24 July 1997 at Loughborough University, UK
[SMDSS 96] G. Schneider, H. Maus, C. Dietel, A. Scheller-Houy, J. Schweitzer. Concepts for a flexibilisation of workflow management systems with respect to task adaptable solutions, In: D. E. O'Leary, P. Watkins, (ed). AAAI Workshop: AI in business: AI in electronic Commerce and Reengineering, Portland, Oregon, August 1996
[SSS 96] G. Schneider, A. Scheller-Houy, J. Schweitzer. Vom Workflow-Management-System zur Vorgangsbearbeitungsplattform mit integrierter Telekooperation. In H. Krcmar, H. Lewe, G. Schwabe, (ed). Herausforderung Telekooperation, Springer, Berlin, 1996.
[ScSc 96] G., Schneider, J. Schweitzer. Workflow-Management-Systeme koordinieren Arbeitsprozesse - eine Gesamtdarstellung -. In: CoPers - Computergestützte und operative Personalarbeit 5/96, Datakontext-Fachverlag, Frechen-Königsdorf, 1996.
[ScSc 97] G. Schneider, J. Schweitzer, Ein teamzentrierter Ansatz zur Integration von Workflow-Management-Systemen und multimedialen Audio/Video Desktopkonferenzsystemen, in: Tagungsband "Dritter Bremer KI-Pfingstworkshop: KI-Methoden in verteilten und dynamischen Prozessmanagementsystemen", 15.-16. Mai 1997
[SWS 97] G. Schneider, M. Weber, J. Schweitzer, Einbindung von synchronen CSCW-Anwendungen am Beispiel von multimedialen Konferenzsystemen, in S. Jablonski, M. Böhm, W. Schulze, (ed.), Workflow-Management - Entwicklung von Anwendungen und Systemen - Facetten einer neuen Technologie, dpunkt.verlag Heidelberg, 1997
[Schn 85] H. D. Schneider, Kleingruppenforschung, in: Studienskripten zur Soziologie, Teubner, Stuttgart, 1985
[Scho 96] C. Scholz, "Virtuelle Unternehmen - Organisatorische Revolution mit strategischer Implikation", in: Management & Computer, 4/96, H.1
[SNI 95] Siemens Nixdorf Informationssysteme AG: WorkParty, User Manual, Version 2.0, 1995.
[WfMC 95] Workflow Management Coalition, Workflow Process Definition, (http://www.aiai.ed.ac.uk:80/WfMC/DOCS/if1/wg1_1000.html).
[WoTel 96] Der WoTel Demonstrator: Workflow - MMC (DeTeBerkom Projektbericht), Siemens AG (STZ), DFKI GmbH, Universität Ulm, DeTeBerkom Verbundprojekt WoTel, DeTeBerkom, März 1996
[WPSSS 97] M. Weber, G. Partsch, A. Scheller-Houy, J. Schweitzer, G. Schneider. Flexible Real-time Meeting Support for Workflow Management Systems. 30th Hawaii International Conference on System Sciences, IEEE Computer Society Press, 1997.
[WSHPSS97] M. Weber, G. Schneider, G. Partsch, S. Höck, A. Scheller-Houy, J. Schweitzer, Integrating Synchronous Multimedia Collaboration into Workflow Management, in Proc. GROUP ‘97 International Conference on Supporting Group Work The Integration Challenge, November 16-19, 1997, Phoenix, Arizona, USA, to appear