Zusammenfassung Der Bedeutung von Geschaftsprozessen wird in der Dienstorientierung (Service-oriented Computing) durch Losungen zur Automatisierung und Unterstutzung bspw. mit WS-BPEL Rechnung getragen. Da allerdings ehrenamtlichen und privaten Gruppen weder entsprechendes Wissen noch notwendige Soft- und Hardwareprodukte zur Verfugung stehen, konnen sie derartige Prozessunterstutzungen nicht fur ihre Einsatzzwecke nutzen und setzen statt dessen weiterhin insbesondere auf E-Mails zur Koordination ihrer Prozesse. Diese Arbeit ermittelt daher die speziellen Anforderungen solcher Gruppen an eine Prozessunterstutzung und stellt einen entsprechenden dienstorientierten Architekturstil vor.
Computer und Internet unterstutzen Anwender nicht nur bei Berechnungen und Informationsbescha ung. Zusatzlich werden sie heute oft zur Koordination ganzer Prozesse in der Geschaftswelt aber auch in ehrenamtlich agierenden Gruppen wie z. B. Vereinen und im privaten Umfeld genutzt. Wahrend die Steuerung von Prozessen in der Geschaftswelt bereits vielfaltig adressiert und bspw. in dienstorientierten Architekturen mit WS-BPEL unterstutzt wurde, sind bisherige Losungen kaum fur ehrenamtliche oder private Gruppen geeignet, da diese anderen Rahmenbedingungen unterliegen. Solche Gruppen nutzen bisher meist lokal installierte Software und E-Mails fur ihre Prozesse. So werden initialer Einrichtungsaufwand, Einarbeitung und mogliche Kosten vermieden, aber Medienbruche, unkontrollierte Informationsweitergabe, Verlust einzelner Informationen, mehrfache Datenhaltung, Dateninkonsistenz und Verlust der Prozessubersicht in Kauf genommen. Erfolgreiche Prozesse sind nur schwer wiederholbar, da Wissen uber sie nur implizit vorhanden ist und somit standig rekonstruiert werden muss. Kollaborative integrierte Prozessschritte wie bspw. das Sammeln von Tagesordnungspunkten sind nur durch erheblichen manuellen Aufwand realisierbar. Dabei machen vereinzelte Losungen wie Konferenzmanagementsysteme deutlich, dass auch au erhalb des klassischen industriellen Umfeldes Prozessunterstutzung hilfreich sein kann, um aufwendige und fehleranfallige handische Koordinationen zu vermeiden. Aufgrund unterschiedlicher Voraussetzungen sind aber Techniken aus dem Unternehmensumfeld nicht ohne weiteres fur ehrenamtliche und private Gruppen adaptierbar.
Diese Arbeit analysiert daher in Abschnitt 2 die Anforderungen dieser Gruppen an eine Prozessunterstutzung und leitet einen entsprechenden dienstorientierten Losungsansatz her, der verschiedenen verteilten Diensten erlaubt, gezielt mit Anwendern in Kontakt zu treten. In Abschnitt 3 wird diese Losung in Form eines Architekturstils prazisiert und in Abschnitt 4 eine ausstehende Fallstudie motiviert. Die Betrachtung verwandter Arbeiten in Abschnitt 5 und ein kurzer Ausblick in Abschnitt 6 beschlie en diese Arbeit. 2
Prozesse von Gruppen, die nur vorubergehend existieren, deren Mitglieder nur temporar diesen Gruppen oder deren Mitglieder zugleich mehreren anderen unabhangigen Gruppen angehoren (z. B. ehrenamtlich agierende Vereine, Veranstaltungen mit temporaren Organisationsteams wie Bene zkonzerte, aber auch Workshops oder Konferenzen) haben gemein, dass sie primar aus manuellen Arbeitsschritten (Aufgaben genannt) bestehen, die von entsprechenden Mitarbeitern zu bearbeiten sind. Typische Rahmenbedingungen sind dabei: { Es ist kein IT-Fachpersonal und oft nur private Hardware verfugbar. { Es sind weder Zeit noch Geld fur den initialen Aufbau einer technischen
Infrastruktur verfugbar. { Gruppen andern sich bestandig in ihrer Zusammensetzung oder arbeiten nur kurze Zeit zusammen. { Gruppenbildung und Verantwortlichkeiten innerhalb dieser konnen auf Vereinstrukturen basieren, von Initiatoren bspw. im Rahmen von Workshops vorgegeben werden, oder auch z. B. bei Interessensgemeinschaften frei verhandelbar sein. { Gruppenmitglieder arbeiten parallel an Projekten anderer Gruppen. { Prozesse werden nur selten in einer Gruppe wiederholt, aber ahnliche Prozesse nden in vielen Gruppen statt (z. B. jahrliche Mitgliederversammlungen). { Prinzipielle Prozessablaufe sind kein Geschaftsgeheimnis.
Einige Forderungen an eine Prozessunterstutzung sind demnach: { Konzentration auf freie Technologien, Infrastrukturen, Dienste und Prozesse fur weitestgehend kostenlose Losungen { Leicht formulier- und anpassbare Prozesse und Dienste; Ausnahmesituationen konnen beim Auftreten dynamisch gelost werden { Leichte Anwendung (und individuelle Anpassung) von Standardprozessen in verschiedenen Kontexten { Einfacher und automatisierter Bezug von Aufgaben { Unterstutzung von Aufgaben verschiedener Art und Komplexitat (von einfachen Uberprufungen bis hin zu komplexen, kooperativ zu bearbeitenden Aufgaben) { Flexible Verwaltung von Gruppenmitgliedern und Verantwortlichkeiten Insbesondere der einfache Zugang von Anwendern zu ihren Aufgaben soll in diesem ersten Schritt einer Losungsentwicklung betrachtet werden. Denn | so weit vorhanden | setzen bisherige Losungen wie Konferenzmanagementsysteme darauf, dass Anwender bestimmte Dienstseiten oder Portale regelma ig aufsuchen, um sich uber anstehende Aufgaben zu informieren. Dies weist aber zwei wesentliche Probleme auf: (1.) Der Anwender ist in einer Holschuld, er muss aktiv die entsprechenden Informationen uber ausstehende Aufgaben einholen. Bei einer wachsenden Anzahl genutzter Dienste und einem zudem nur sporadischen Auftreten der Aufgaben ist eine zeitnahe Kenntnisnahme anstehender Aufgaben daher schwierig, so dass bisher oft erganzend E-Mails eingesetzt werden. (2.) Die Verwendung von E-Mails kann zwar sicherstellen, dass Anwender zeitnah von Aufgaben erfahren, letztendlich werden aber weder die zeitliche Einplanung und Bearbeitung noch die Weiterverfolgung von Aufgaben nebst zugehorigen Prozessen unterstutzt.
Die wichtigsten Anforderungen in diesem ersten Losungsschritt lassen sich daher zunachst auf folgende Punkte reduzieren: { Es darf | auch wenn Prozesse und Dienste mehrerer Anbieter (Service Provider) genutzt werden | nur einen Einstiegspunkt fur den Anwender geben, an dem ihm alle wesentlichen Informationen zu ausstehenden Aufgaben und zur Verfolgung von Prozessen (ohne sein aktives Eingreifen) zur Verfugung gestellt werden. { Dieser Einstiegspunkt muss einen exiblen Zugri auf zur Aufgabenausfuhrung notwendige unterstutzende Dienste und Informationen bieten. { Dieser Einstiegspunkt muss von Prozessen und Diensten mit aktuellen Informationen, z. B. zum Status einer Aufgabe, versorgt werden konnen. Die oft verwendeten E-Mails bieten durch ihre i. d. R. personenbezogene Adressierung zwar einen zentralen Einstiegspunkt, eignen sich aber nicht zur ubersichtlichen Aufgabenverwaltung und -darstellung und erlauben zudem keine komfortablen Aktualisierungen bspw. des Aufgabenstatuses. Die Verwendung von Portalen und proprietaren Losungen kann zwar eine gute Aufgabenverwaltung bieten, fuhrt aber wieder zu dem Problem multipler Einstiegspunkte. Ein E-Mailahnlicher Ansatz mit strukturierten Informationen und einer dienstorientierten Schnittstelle kann beide Vorteile zusammenfuhren und personenbezogene Aufgabenzuweisungen aber auch Aktualisierungen von Informationen zu Aufgaben aus beliebigen Prozessen und Diensten heraus unterstutzen.
Diese Idee wird im Folgenden in Form eines Aufgabenlistendienstes aufgegriffen, der uber eine eindeutige, einem Anwender zugeordnete URI adressierbar ist und erlaubt, uber im Detail noch zu entwickelnde Dienste Aufgaben inkl. Metainformationen wie Deadline, Status, o. a. einem Anwender zuzuordnen. Der Anwender kann uber diesen Dienst auf seine aktuellen Aufgaben zugreifen und diese verwalten, und sie bspw. auch nach Metadaten sortieren. Die Dienstorientierung erlaubt dabei sowohl auf Seiten des Dienstanbieters und des Prozesses als auch auf Seiten von Klientanwendungen fur den Anwender exible und innovative Losungen unabhangig von verwendeten Programmiersprachen u. a. Der nachste Abschnitt wird nun einen Architekturstil vorstellen, der dieser Idee entspricht.
Nach Fielding [
Abbildung 1. Architekturstil
Anwender werden durch eindeutige URIs, unter denen ein Aufgabenlistendienst (assignment list service) neu zugewiesene Aufgaben sowie Aufgabenaktualisierungen entgegennimmt, zu adressierbaren Entitaten (ahnlich einer E-MailAdresse nebst Postfach). Dienste, die den Eingri von Anwendern benotigen (human-supported services), informieren diese per Aufgabenlistendienst uber ausstehende Aufgaben und geben dabei neben einigen Metainformationen u. a. eine eindeutige URI fur den Aufruf einer Reprasentation der Aufgabe an. Um gro tmogliche Flexibilitat bei der Aufgabenrealisierungen zu ermoglichen, werden Daten uber potentielle Nutzer (z. B. bei der Dienst-Initialisierung ubergeben) und interne Zustande von den Diensten eigenverantwortlich verwaltet. Eine Auslagerung dieser Funktionalitaten ist in Form weiterer Dienste oder Entwicklungsframeworks optional denkbar.
Zusatzliche Identitatsmanagementdienste (identity management services) erlauben eine spate, dynamische Bindung von Rollen an konkrete Anwender und eine Wiederverwendung von Organisationsstrukturen und Anwenderinformationen. Selbst Randbedingungen wie Urlaub oder Arbeitsauslastung lie en sich bei dieser dynamischen Bindung berucksichtigen. Den Diensten werden dann statt Adressen von Anwendern Rollenbezeichungen und die Adresse eines Identitatsmanagementdienstes ubergeben, sodass erst bei Auftreten einer Aufgabe die konkreten Anwenderadressen ermittelt und genutzt werden.
Lokale und netzbasierte Klienten (human assistant) erlauben den Anwendern den komfortablen Zugri auf die sie betre enden Aufgaben, und konnen bspw. durch Kalenderintegration zur Bearbeitungsplanung Mehrwerte bieten.
Fur den praktischen Einsatz ist dieser Stil u. a. um standardisierte Schnittstellen fur Identitatsmanagementdienste und Aufgabenlistendienste zu konkretisieren, um gema o. g. Anforderungen anbieterubergreifend arbeitende Losungen zu ermoglichen. U ber alle andere Dienste und Klienten sind dagegen moglichst wenig Annahmen zu machen, um exible und innovative Realisierungen zu ermoglichen. 4
Folgendes, noch umzusetzendes, einfaches Fallbeispiel ist zur Demonstration der Realisierbarkeit geplant: Fur die Vorbereitung einer Sitzung, z. B. eines Mitarbeitertre ens eines Vereines oder einer o entlichen Versammlung einer Burgerbewegung, wird ein Prozess nebst notwendigen Diensten entwickelt werden, der das gemeinsame Sammeln von Tagesordnungspunkten und das Versenden von Einladungen zur Sitzung unter Angabe der Tagesordnung unterstutzt. Der Prozess besteht aus folgenden Schritten: 1. Rahmendaten wie Datum, Raum, Sitzungsleitung, etc. sind zu spezi zieren (demonstriert die Initialisierung einer Prozessinstanz mit anwenderspezi zierten Daten inkl. Benennung von potentiellen Anwendern als Sitzungsleitung, etc. und die Kon guration der Instanz z. B. bzgl. eines optionalen Anmeldeschrittes). 2. Tagesordnungspunkte sind zu sammeln (Beispiel fur eine kooperative Aufgabe; wenn Anwender nicht gegenseitig ihre Beitrage zur Sammlung einsehen konnen, erhoht sich die Wahrscheinlichkeit von Mehrfachnennungen signi kant, einzelne Punkte konnen aber auch leichter vergessen werden). 3. Wenn der Sitzungsleitung nicht alle potentiellen Teilnehmer bekannt sind, ist ggf. eine Anmeldung z. B. uber ein Webschnittstelle zu ermoglichen (Beispiel einer dynamisch wachsenden Gruppe). 4. Tagesordnung ist zu genehmigen/uberprufen (einfache Aufgabe). 5. Einladungen mit Tagesordnung sind an alle Teilnehmer zu versenden (klassischer, automatisierter Dienst).
Der Einsatz eines Identitatsmanagementdienstes ist optional zu ermoglichen, um
das Potential der Wiederverwendung von Anwenderinformationen insbesondere
fur temporar stabile Gruppen aufzuzeigen. Gleichzeitig kann aber der Einsatz
mit dem Beispiel einer Burgerbewegung auch fur dynamisch wachsende Gruppen
demonstriert werden. Daruber hinaus wird die Fallstudie zeigen mussen, dass
etablierte Losungen wie z. B. YAWL [
Gangige Work ow- und Task-Management-Systeme bspw. von IBM, SAP oder
Active Endpoints basieren u. a. auf WS-BPEL, BPEL4People und WS-HumanTask,
um Prozesse in einem dienstorientierten Kontext zu modellieren und manuelle
Aufgaben einzubinden. Alle drei Techniken entstammen dem Unternehmensumfeld
und bieten daher fur Gruppen im Fokus dieser Arbeit keine direkte Unterstutzung:
WS-HumanTask [
WS-BPEL und BPEL4People bieten interessante Moglichkeiten zur Formulierung von Prozessen. Im Rahmen einer allgemeinen und exiblen Architektur ist aber von konkreten Sprachen soweit moglich zu abstrahieren, um auch alternative Implementierungen zu ermoglichen. WS-HumanTask dagegen ist zwar sprachunabhangig gehalten, unterstutzt aber z. B. mit seinem Fokus auf nichtteilbare Aufgaben keine kollaborativen Aufgaben (der de nierte Lebenszyklus erlaubt keine derartigen Aufgabentypen). Die auf diesen Techniken basierenden Losungen leiden fur den hier anvisierten | aber bei deren Entwicklung nicht vorgesehenen | Einsatz an weiteren Problemen: Es gibt kein einheitliches Modell fur Aufgabenlisten und -zuweisungen (Aufgabenverwaltung) und die Losungen sind | da fur das komplexe Unternehmensfeld mit hohen Anforderungen an Robustheit, Skalierbarkeit u. a. entwickelt | fur nicht professionelle Gruppen zu komplex und kostspielig. Der Einsatz eines Enterprise Service Bus bspw. ist nicht fur das Internet und die Nutzung frei verfugbarer Dienste optimiert, die aber im Rahmen der o. g. Anforderungen hier wesentlich sind.
Das freie und leichtgewichtige Work ow-Management-System YAWL (Yet
Another Work ow Language) [
Selbst im geschaftlichen Umfeld fuhrt der Mangel einer standardisierten
Aufgabenverwaltung dazu, dass Anwender, die in mehreren Unternehmen oder
Abteilungen mit eigener Softwareinfrastruktur involviert sind, mehrere
Aufgabenlisten verwalten und abarbeiten mussen, und dass eine Auslagerung einzelner
Aufgaben und Teilprozesse nicht unterstutzt wird. Unger et al. [
Aufgaben von Anwendern in Prozessen konnen vielfaltiger Natur sein: Einfache Genehmigungs- und Pruftatigkeiten oder kreative Aufgaben, alleine oder kooperativ auszufuhrende Aufgaben, der Organisation des Anwenders, einmaligen Veranstaltungen oder ehrenamtlich und privaten Projekten entstammende Aufgaben, und in bspw. Java, XML oder PHP realisierte Aufgaben. Letztendlich muss aber jede Aufgabe ihren Bearbeiter (Anwender) nden. Dazu wurde hier ein einfacher, von der E-Mail-Infrastruktur inspirierter Architekturstil vorgestellt, dessen Konkretisierung Gegenstand kommender Forschungsarbeit werden wird.
Auf diese Architektur aufbauend sind Datenschutz, Authenti zierung und Sicherung gegen Spam komfortabel zu ermoglichen. Aber auch die Flexibilitat, Kontrollierbarkeit und Nachvollziehbarkeit ganzer Prozesse sind in Zukunft noch zu adressieren.
Literatur