Der zentrale Gedanke des vertragsbasierten Prozessmanagement besteht darin, das Management von Workflowressourcen zu dezentralisieren und die Bearbeitung der jeweiligen Workflowinstanz durch eine kontinuierliche Bemühung, mit sozialen und/oder technischen Akteuren bzw. Agenten „eine Vereinbarung einzugehen“, erfolgreich fortzusetzen. Um Kundenorientierung, Flexibilität und Interoperabilität in organisationsübergreifenden Workflownetzen zu ermöglichen, muss es möglich sein, jede Art von (neuer) Workflowressource als einen Service zu binden und dessen Leistung zu integrieren, während der Gesamtprozess sich entfaltet. Daher schlagen wir vor, (1) die Steuerung bzw. Ausführung eines Workflowprozesses als eine Folge von Zyklen der Evaluation und Anforderung, des Auswählens und vertraglichen Verpflichtens von Services sowie der Ausführung und Überwachung dieser Services und ihrer Leistungsintegration zu konzipieren sowie (2) die IT-Unterstützung für ein vertragsbasiertes Prozessmanagement auf eine modularisierte Architektur zu gründen, wobei die dezentralisierte Workflowsteuerung getrennt wird von der Bereitstellung der erforderlichen Workflowressourcen als Services.
Workflow Management (WFM) handelt von der Organisation von Prozessen, in denen Elemente „fließen“, um von beteiligten Akteuren be- bzw. verarbeitet zu werden. Ein Workflow ist (übersetzt nach [Al00], S. 15) „die Automatisierung eines Geschäftsprozesses als Ganzes oder in Teilen, in dessen Verlauf Dokumente, Information oder Aufgaben entsprechend einer Reihe von verfahrenstechnischen Regeln von einem Teilnehmer zum nächsten zwecks Bearbeitung übermittelt werden“. Die organisatorische Unterstützung durch WFM-Systeme folgt bisher hauptsächlich einem Leitbild, das wir definitionsbasiertes Prozessmanagement nennen: umfassende Analyse sowie genaue Planung und Festlegung von Arbeitsabläufen werden als Voraussetzungen sowohl für wirkungsvolle Unterstützung bzw. Ausführung durch WFM-Systeme als auch für die Bereitstellung einer Umgebung betrachtet, in der alle Beteiligten die ihnen zugewiesenen Arbeitselemente, die notwendigen Services, Prozessinformation und andere Ressourcen vorfinden. Dieser Ansatz basiert auf der tayloristischen Annahme, Arbeitsprozesse ließen sich durch Entwurf eines (wissenschaftlichen) Systems optimieren, bei dessen Anwendung die Arbeit auf die beste Weise ausgeführt wird. Gleichzeitig werden dabei stabile Bedingungen für Prozessausführung vorausgesetzt: Die wiederholte Ausnutzung desselben WFM-Systems und wiederholte Implementierung desselben Prozessmodells sind nur möglich, wenn alle erforderlichen Prozesselemente und Ressourcen aus der Umgebung auf dieselbe Weise verbunden und verwendet werden.
Diese allgemeine Vorstellung von WFM (die durchaus auch für die Unterstützung vieler e-Business-Prozesse geeignet ist) lässt sich allerdings nicht auf jene Bereiche übertragen, in denen (teil-)autonome Akteure in einem heterogenen Netz organisationsübergreifend Prozesse durchführen, die sich erst über die Zeit entfalten: wie etwa in den Bereichen Gesundheit (z.B. Behandlung von Patienten vor, während und nach eines Krankenhausaufenthaltes), öffentlicher Verwaltung (z.B. Prozesse der Entscheidungsfindung über mehrere Verwaltungseinheiten hinweg), Tourismus (z.B. individuelle Reiseunterstützung durch viele Dienstleister), Bauindustrie (z.B. Kooperation der verschiedenen Gewerke und Lieferanten). Diese Beispiele haben das Ziel gemeinsam, dem jeweiligen Klienten des Prozesses (Patient, Kunde, Bürger, usw.) einen kohärenten Dienst zu liefern, obwohl dieser sich über die Zeit erst entfaltet bzw. sich in seiner Zielsetzung wandelt (d.h. eine Prozessdefinition a priori hat keinen determinierenden Einfluss) und sich auf (teil-)autonome und heterogene Dienstleistungspartner abstützt (mit je unabhängiger Entscheidungsfindung und eigener Infrastruktur für Prozessunterstützung). Das Management dieser Art von Prozessen stellt eine spezielle Herausforderung dar, wobei die Grundannahmen über WFM vor allem durch folgende neue Anforderungen in Frage gestellt werden (vgl. auch [WK02], [AJ00]): • • •
Kundenorientierung: während WFM zuvörderst auf die Unterstützung interner Prozesse zielt(e) (bei denen der Kunde höchstens am Anfang und Ende von Arbeitsabläufen involviert ist), betreffen gerade im Dienstleistungsbereich viele Arbeitsprozesse bzw. Arbeitsschritte den Kunden direkt oder müssen das Anliegen des Kunden berücksichtigen, das sich während Prozessausführung auch ändern kann. Flexibilität: während IT-gestütztes WFM zuerst eingeführt wurde, um Effizienz und Transparenz zu verbessern, steht heute zunehmend der Bedarf nach Flexibilität in Organisationen und über Organisationsgrenzen hinweg im Vordergrund: Einbeziehung vieler und vielfältiger Akteure (Dienstanbieter und Kunden, individuell und als Organisationen) auch noch zusätzlich während der Prozessausführung, Einbindung verschiedenster organisatorischer und technischer Infrastrukturen, Unterstützung von Geschäftsprozessen mit unvorhergesehene Aktivitäten und Verläufen (aufgrund von sich verändernden äußeren Bedingungen) – mittlerweile ist in vielen, insbesondere serviceorientierten Bereichen die Redefinition von Prozessplänen während Prozessausführung der Normalfall und nicht die Ausnahme! Interoperabilität: während ursprünglich die IT-Unterstützung für WFM darauf abzielte, jeweils Workflowanwendungen auf der Basis eines Systems zu entwickeln und innerhalb einer Organisation einzusetzen, lassen sich die heute im Bereich WFM zu verbindenden Komponenten meist nicht mehr in einem System zusammenfassen, sondern müssen über Schnittstellen und Messaging verbunden werden. (vgl. z.B. [AA99]). Oftmals sind Komponenten sogar verstreut und liegen außerhalb der Steuerung der WFM-Systeme, eingebettet in unterschiedliche und komplexe Infrastrukturen, wobei Internettechnologien sowohl die Konnektivität von Komponenten ermöglichen als die Kommunikation mit Dienstleistungsmitarbeitern und Kunden. Aufgaben im Bereich Interoperabilität umfassen Informationsaustausch (z.B. bezüglich aktueller Workflowinstanz, Prozessmuster, Komponentenschnittstellen) sowie die entfernte Ausführung von Softwarekomponenten und automatisierten Services (z.B. Web Services, Application Services).
Unser Beitrag argumentiert daher, dass die Grundlagen von Workflow Management überdacht werden müssen, um den heutigen Anforderungen zu entsprechen und eine angemessene IT-Unterstützung für Workflow in heterogene Dienstleistungsnetzen zu bieten. Während das Workflowparadigma der Vergangenheit als definitionsbasiertes Prozessmanagement bezeichnet werden kann, d.h. als Prozessausführung entsprechend vordefinierten Prozessmustern und Ressourcenbeziehungen (s.u.), schlagen wir alternativ das Leitbild des vertragsbasierten Prozessmanagement vor, d.h. eine Art der Prozessausführung basierend auf einem Zyklus von situativer Evaluation, Serviceverpflichtung und -ausführung.
Im folgenden stellen wir zunächst das Ressourcenmanagement als zentrales Anliegen von WFM in den Mittelpunkt. Zweitens untersuchen wir einige neuere Ansätze zu organisationsübergreifendem WFM, wobei wir feststellen, dass diese alle die Flexibilität des Ressourcenmanagement durch das vertragliche Verpflichten von Services verbessern. Drittens argumentieren wir für ein dezentralisiertes Ressourcenmanagement, das wesentlich die Bereitstellung aller Workflowressourcen als vertraglich bindungsfähige Services voraussetzt, und skizzieren viertens Konzepte für die Implementation eines vertragsbasierten Prozessmanagement als IT-Unterstützung in organisationsübergreifenden Workflownetzen.
Die Konzeptualisierung und IT-Unterstützung im Bereich Workflows steht und fällt mit dem Begriff des Prozesses, der in der Regel als eine Folge von unabhängigen Aktivitäten verstanden wird: „A process definition consists of one or more activities, each comprising a logical, self-contained unit of work within the process.“ ([WMC01], S.8) Aus der Sicht der Informatik bestand die Aufgabe im Bereich WFM zunächst darin, gut strukturierte und stabilisierte Kooperationsprozesse zu unterstützen. In der Folge wurde die Prozesssteuerung an WFM-Systeme übertragen, die Workflows vollständig definieren, verwalten und ausführen mittels einer Software, deren Ausführung von einer Repräsentation der Workflowlogik bestimmt wird (vgl. [La97], S. 244). Dabei war von Anbeginn auf mehreren Ebenen ein Management von Beziehungen zwischen den für die Ausführung des Workflow notwendigen Instanzen erforderlich: • • •
Verbindung von vordefinierten Aufgaben und Arbeitseinheiten aufgrund des Prozessmodells, Benachrichtigung von Mitarbeitern, in bestimmter Zeit bestimmte Elemente zu bearbeiten, basierend auf Rollenkonzept, Worklist usw., Verbindung von informationellen Ressourcen (Arbeitsgegenstände wie elektronische Dokumenten oder andere Datenobjekte) mit ausführenden Einheiten (insbes. Softwareanwendungen) sowie Konfiguration des WFM-Systems im Rahmen der gegebenen Infrastruktur (Hardware, Middleware, Rechteverwaltung, usw.). Anwendungserfahrungen zeigten allerdings, dass die Umgebungen für WFM Systeme nicht stabil genug sind, um die tayloristische Grundidee der Trennung von Planung und Ausführung konsequent anzuwenden. Die zweite Welle der WFM-Systeme entsprach deshalb dem Bedarf nach mehr Flexibilität am Arbeitsplatz, nach adhoc-Änderungen des vordefinierten Prozesses und der vordefinierten Kooperation und nach der Anpassung an bestimmte organisatorische Erfordernisse. Forschung und Entwicklung versuchten nun, die Grundidee der Massenproduktion im Büro zu verbinden mit gewonnenen Einsichten u.a. im Bereich computerunterstützter kooperative Arbeit. Dadurch rückte zunehmend ins Bewusstsein, dass WFM-Systeme eine Vielfalt von Beziehungen zwischen sozialen Akteuren und technischen Komponenten integrieren müssen, die für den Erfolg der Prozessausführung wesentlich sind (z.B. bei der Darlehensvergabe an einen Bankkunden, wo so unterschiedliche Aktivitäten wie Bewertung der Kundensolvenz, Darlehensberechnung, Aushandlung, Vertragsgestaltung usw. in einem Prozess kombiniert werden). Viele dieser Beziehungen stellen sich in herkömmlichen WFM-Systeme als fixiert bzw. implizit dar und sind dadurch Hindernisse auf dem Weg zu mehr Flexibilität. Überdies ist in den meisten Fällen die Relation zum Prozessklienten (dem Nutznießer der Prozessausführung) kein integraler Bestandteil der Workflowanwendung gewesen. Mit zunehmenden Anforderungen an Flexibilität in komplexen, heterogenen und organisationsübergreifenden Workflowumgebungen ist die Verwaltung von Workflowressourcen zu einem zentralen Anliegen geworden. Ein Ausweg wird u.a. in einem allgemeineren Ressourcenbegriff gesucht: „The basic characteristic of a resource is that it is able to carry out particular tasks.“ ([AH02], S.75). Mit anderen Worten, Workflowressourcen können handeln, sie sind Agenten, unabhängig davon, ob sie Menschen oder Maschinen oder eine Art von heterogenem Akteuren sind. Über diese Interpretation als aktive Ressourcen hinaus erfordert Workflow-Ausführung u.E. auch die Einbeziehung passiver Ressourcen ohne eigene Handlungsfähigkeit, z.B. die zu verarbeitenden informationellen Objekte oder zu interpretierende Prozessmuster für Ausführung von Prozessinstanzen. Vor diesem Hintergrund hat sich auch die Diskussion um zentrale Begriffe verändert. Allen zum Beispiel beschreibt ein WFM-System wesentlich vorsichtiger als früher als „a system that defines, creates and manages the execution of work-flows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications“ ([Al00], S. 16). Jedoch, diese Beschreibung – obwohl sie mehrere innerhalb von WFM zu beachtende Beziehungen hervorhebt – folgt immer noch dem Leitbild des definitionsbasierten Prozessmanagement (d.h. der regelgeleiteten Ausführung von vordefinierten Prozessmustern und Ressourcenbeziehungen). Im folgenden untersuchen wir einige Ansätze zu WFM in heterogenen Netzen, die alle den Anforderungen an Flexibilität durch die vertragliche Bindung von Ressourcen als Services während der Workflowausführung begegnen.
Sich vertraglich zu etwas verpflichten oder eine Vereinbarung mit einem Akteur einzugehen bedeutet, etwas unter vereinbarten und damit bindenden Bedingungen zu liefern oder zu tun. Ein Vertrag ist dann eine dem zugrundeliegende formale bzw. dokumentierte Vereinbarung. Verträge zwischen sozialen Akteuren sind grundlegend für die Bereiche Wirtschaft, Politik und Justiz – und es scheint, dass Verträge im Bereich der Informatik eine vergleichbare Bedeutung gewinnen. In der Informatik ist das Verständnis von Vertrag vor allem durch die Arbeiten von Bertrand Meyer geprägt, der im Rahmen von programming by contract die Beziehung zwischen einer Klasse und ihren Klienten als eine formale Vereinbarung betrachtet, die die Rechte und Verpflichtungen jeder Partei ausdrückt (vgl. z.B. [Me88], S. 111). Die darauf aufbauende objektorientierte Softwarekonstruktion verbindet mit dem Vertragsmodell nach Meyer weitere wichtige Begriffe wie Zusicherung, Vorbedingung, Nachbedingung, Invarianz (bzw. Nebenbedingung) und Delegation (subcontracting).
Das Vertragsmodell und die damit verbundene Idee der Services haben auch Bedeutung innerhalb der Workflowdiskussion gewonnen. Die vertragliche Bindung gilt hier nicht nur für die Beziehung zwischen technischen Komponenten, sondern auch für Arbeitsbeziehungen: „A person who is assigned a task is a contractor. [...] A contractor does not necessarily carry out the work itself, but may redirect or subcontract it to third parties.“ ([AH02], S. 11) Ein Reihe von neueren Ansätzen versucht nun, das organisationsübergreifende und internetbasierte WFM durch Integration von Teilleistungen als Services zu ermöglichen. Trotz aller Unterschiede im einzelnen kann sich die Einbeziehung von sozialen und/oder technischen Services innerhalb von WFM-Netzwerken auf eine abstrakte Sicht abstützen: „Service is a process or system providing a facility to the network. The service itself is accessed using a communication mechanism (...)“ [Ve97]. Dieser Kommunikationsmechanismus basiert auf Anforderung (request) und Antwort (response) und führt zu einer Vereinbarung zwischen Servicegeber und Servicenehmer vor der eigentlichen Serviceerbringung.
Vom Standpunkt des Klienten sind Services Ressourcen, die in der Lage sind, besondere Aufgaben auszuführen. Aus dieser Perspektive heraus kann WFM auch als die Auswahl und Verbindung von sozialen und/oder technischen Services zum Zwecke der Prozessdurchführung betrachtet werden. Einige Ansätze haben die Vorstellung von Service und/oder das Vertragsmodell bereits benutzt, um den heutigen Anforderungen an WFM gerecht zu werden: •
Die eFlow-Plattform ([Ca00a], [Ca00b]) unterstützt die Bereitstellung von integrierten Mehrwertdiensten in dynamischen Geschäftsumgebungen (genauer betrachtet werden die Beispiele Umzug und Veranstaltungsmangement). Der Ansatz zielt auf die Kombination von e-Services verschiedener Anbietern durch einen Integrator ab, der auch Prozessmuster und Serviceauswahl anbietet. Die Workflowausführung basiert darauf, (Teil-)Services auszuwählen und zu integrieren: die Steuerungskomponente wendet sich zur Laufzeit an den Service-Broker, der entsprechende Services (möglicherweise nach entsprechend definierten Selektionsregeln) auswählt, und dann an die jeweiligen Serviceprovider, um den Service einzufordern. Zwar muss die Zusammensetzung von Services im Prinzip vor der Ausführung gewählt werden (somit wird dem Leitbild des definitionsbasierten Prozessmanagement gefolgt; sich entfaltende Prozesse sind weniger in Fokus), aber die Ausführung bleibt flexibel u.a. durch die Möglichkeit zur Änderung der Servicekombination während der Ausführung, durch generische Selektion mit dynamischen Parametereinstellun• • gen, durch möglichen Austausch von Standardservicekomponenten entsprechend dem Bedarf des Kunden sowie durch Konzepte für Service-Monitoring, Messaging zwischen den Services, Ereignismanagement und eine benutzerorientierte Rechteverwaltung.
Das CrossFlow-Projekt [Gr01] zielt auf die Unterstützung von Outsourcing und organisationsübergreifendem Workflow in dynamisch etablierten virtuellen Unternehmen. Die Kooperation von Geschäftspartnern wird unterstützt durch elektronisches Abschließen von Verträgen, bei denen allerdings eine klare Rollenverteilung hinsichtlich Servicegeber und -nehmer vorausgesetzt wird. Eine MatchmakingKomponente wählt Serviceprozesse aus und verbindet sie. Serviceprovider bieten ihre Services in einer XML-basierte Spezifikationssprache an, während Servicenehmer einen Provider über eine gegebene Beschreibung auswählen und mittels Hinzufügen von erforderlichen Parametern vertraglich binden. Details dieser Verträge gehen über die Beschreibung des Service-„Inhalts“ hinaus und enthalten auch Information zur Interoperabilität. Ein Konfigurationsmanager in Verbindung mit weiteren Modulen zur Kooperationsunterstützung ermöglicht den Aufbau einer übergreifenden Infrastruktur für die Servicebereitstellung und -ausführung. Außerdem wird die Servicequalität entsprechend der vertraglichen Vorgaben überwacht, einschließlich flexibler Änderungen in der Ausführung entsprechend der im Vertrag vordefinierten Regeln.
Serviceflow Management (vgl. [KWB01], [WK02] u.a.) unterstützt die Ausführung von Serviceprozessen in heterogenen Dienstleisternetzwerken und zielt dabei primär auf die Unterstützung von Dienstleistungsmitarbeitern und ihren Organisationen. Der Ansatz modelliert Prozesse als eine Folge von Servicepunkten, an denen jeweils Kunde und Dienstleister aufeinandertreffen bzw. die aktuelle Situation und das Kundenanliegen neu bewertet werden, wobei die Servicepunkte jeweils durch die dort üblicherweise auszuführenden Aktivitäten und ihre jeweiligen Vor- und Nachbedingungen beschrieben werden. Bei der Servicedurchführung werden die beteiligten Dienstleister (ggf. auch der Kunde) jeweils über den bisherigen Verlauf und die aktuelle Planung eines sich entfaltenden Serviceprozesses informiert und beim (evtl. automatischen) Auswerten der aktuellen Serviceinstanz gegenüber den vorher vereinbarten Prozessmustern unterstützt. Konzepte für XML-basierte Prozessrepräsentationen beziehen sich sowohl auf die veränderbare Folge der Servicepunkte mit ihren sukzessive akkumulierten Nachbedingungen (service float) als auch auf die (veränderbare) Zusammenstellung der Aktivitäten an einem Servicepunkt (service point script). Diese Repräsentationen, die jeweils den Stand der vertraglichen Bindung bezüglich der Teilservices an den Gesamtprozess bzw. der Aktivitäten an jeden Teilservice darstellen, können prozessbegleitend peer-to-peer oder mittels einer zentralisierten Architektur kommuniziert werden.
Die oben skizzierten Ansätze1 unterscheiden sich in der Art der zu unterstützenden Prozessen und entsprechenden IT-basierten Lösungen, jeder mit bestimmten Vorteilen 1 Eine Reihe von weiteren Ansätzen, die ebenfalls Probleme des internetbasierten und organisationsübergreifenden Workflow adressieren (z.B. Workflow-„Mediation“, vgl. [Ch01], [SGW01]) machen Vorschläge in ähnliche Richtungen, wobei jeweils noch andere Aspekte des Ressourcenmanagement hervorgehoben (und Schwächen): eFlow setzt soziale und technische Services durch XML-basierte Vertragsabschlüsse in Beziehung (aber unterstützt nicht das Entfalten von zusammengesetzten Prozessen über die Zeit); CrossFlow führt ausgearbeitete Funktionen für das Aktivieren und Monitoring von Services ein (aber erwartet alle Workflowressourcen als Teil einer individuell aufgebauten Infrastruktur); Serviceflow Management zielt auf die Berücksichtigung von situierten Servicebedarfen und entsprechender Prozessadaption (während es bei den technischen Aspekten dynamischer Ressourcenverwaltung relativ vage bleibt). Alle diese Ansätze haben jedoch gemeinsam, dass sie – – – – – – die Ausführung jedes Prozesses auf instanzbasierte Prozessrepräsentationen gründen, dynamische Prozess- und Ressourcenverwaltung durch kontinuierliche bzw. wiederholende Auswertung von Ressourcenangebot und -nachfrage ausführen, Auswahl und vertragliche Bindung von Ressourcen als soziale und/oder technische Services auf verschiedenen Ebenen ermöglichen, die Verbindung von Services und die Interoperabilität innerhalb des Prozessmanagements mittels XML- und internetbasierter Kommunikation erreichen, zunehmend Regeln für den Vertragsabschluss definieren bzw. spezifizieren (und nicht für die Prozessausführung selbst), neue Formen des Prozessmonitoring einführen, um eine Workflowsteuerung auch in heterogenen Netzen mit autonomen Akteuren zu ermöglichen.
Dies sehen wir als die aktuellen Trends im Bereich WFM an, die jedoch (noch) nicht durch übergreifende Metaphern, Konzepte und Theorien verbunden bzw. fundiert sind. Aus diesem Grund, so unsere These, sollte die Workflowforschung ihre Basis der Diskussion überdenken und sich vom Leitbild des definitionsbasierten Prozessmanagement zum vertragsbasierten Prozessmanagement bewegen, zumindest für den Bereich des organisationsübergreifenden WFM. Diesem neuen Leitbild folgend versuchen wir nun, Perspektiven für die IT-Unterstützung zu entwickeln, die den heutigen Anforderungen an WFM gerecht wird.
Der zentrale Gedanke des vertragsbasierten Prozessmanagement besteht darin, das Management von Workflowressourcen zu dezentralisieren und die Bearbeitung der jeweiligen Workflowinstanz durch eine kontinuierliche Bemühung, mit sozialen und/oder technischen Akteuren/Agenten „eine Vereinbarung einzugehen“, erfolgreich fortzusetzen. Um Kundenorientierung, Flexibilität und Interoperabilität in heterogenen Workflownetzen zu ermöglichen, muss es möglich sein, jede Art von (neuer) Workflowressource als einen Service zu binden und dessen Leistung zu integrieren während der werden. Für die Integration von Web Services in WFM hat z.B. IBM eine Web Services Flow Language [Le01] entwickelt. Ein Ziel von WSFL ist, Web Services als Implementationen von Aktivitäten im Rahmen von Geschäftsprozessen zu aktivieren. Jede Aktivität wird mit einem für die Ausführung des Prozessschrittes verantwortlichen Dienstleister verbunden. Diese Beziehung definiert die Zuordnung zwischen in den Kontrollfluss integrierten Aktivitäten und den vom Dienstleister angebotenen Leistungen. Gesamtprozess sich entfaltet. Daher schlagen wir vor, die Ausführung eines Workflowprozesses als eine Folge von Zyklen der Evaluation und Anforderung, des Auswählens und vertraglichen Verpflichtens von (menschlichen und technischen) Services sowie der Ausführung und Überwachung dieser Services und ihrer Leistungsintegration zu konzipieren (siehe Abbildung 1).
Work unit 1 In einem organisatorisch stabilen Netz von Work-units erscheint für diese Art von Prozess auch eine übergreifende (ggf. zentral organisierte) technische Infrastruktur für das Auswählen und Integrieren aller erforderlichen Services möglich, die für alle Prozessinstanzen innerhalb dieses Netzes anwendbar ist (vergleichbar mit einer etablierten Zulieferkette). Sind jedoch bei jeder Prozessinstanz andere bzw. neue Partner (als Work-units) und Ressourcen involviert (z.B. bei der Patientenbehandlung), müssen die beteiligten Partner überhaupt erst eine kooperatives Prozessmanagement etablieren, sowohl auf der anwendungsorienterten als auch auf der technischen Ebene des fallbasierten Ressourcenmanagement. Um in diesen Fällen den Zyklus von Evaluation/Anforderung, Auswählen/vertragliche Bindung und Ausführung/Überwachung zu ermöglichen, sind noch weitere Anstrengungen in Richtung Dezentralisierung notwendig, insbesondere die Bereitstellung aller Workflowressourcen als vertraglich bindungsfähige Services und darauf aufbauend die Etablierung einer Workflowsteuerung bzw. einer entsprechenden IT-Unterstützung, die diesen Zyklus auch dezentral ausführen kann (siehe nächsten Abschnitt).
Wie bereits oben eingeführt, betrachten wir alle Workflowressourcen als Services, d.h. als eine über request und response abrufbare Leistung auf der Basis einer Vereinbarung zwischen Klient und Dienstleister. Obwohl diese Services in ihrer Art sehr verschieden sein können, und jeder von diesen sich wiederum auf komplexe Weise auf andere Services beziehen kann, plädieren wir für eine einheitliche Sicht für den Zweck der vertraglichen Bindung an einen Workflowprozess. Vor diesem Hintergrund empfehlen wir, auch passive Ressourcen (s.o., z.B. die zu verarbeitende informationelle Objekte oder zu interpretierende Prozessmuster für Ausführung von Prozessinstanzen) zusammen mit ihren grundlegenden Methoden für Zugriff und Bearbeitung als Services zu kapseln. Wir unterscheiden folgende Arten von Workflowservices (zum Verständnis mit Beispielen aus dem Krankenhauskontext) nach ihrer anwendungsorientierten bzw. technischen Leistung, nach der Ebene ihrer vertraglichen Bindung und nach ihrer Stellung im Mensch-Maschine-Kontext (Auswahl- oder Benutzungsschnittstelle für Workflowteilnehmer: ja oder nein): – – – – –
Services als soziale Beziehung versuchen die situativen Bedürfnisse eines Klienten zu erfüllen, die Partner sind einzelne Menschen (z.B. bei Beratung eines Patienten durch einen Spezialisten) oder kollektive soziale Akteure (z.B. bei Erweiterung von OP-Teams im Rahmen der Telemedizin); werden in der Regel durch Workflowteilnehmer ausgewählt und integriert aufgrund einer Repräsentation der Dienstleistung, die die wichtigen Aspekte der Serviceleistung anzeigt (für request: z.B. Daten zu Person, Ort, Termin sowie Beschreibung der zu leistenden Grundaufgabe; für response: z.B. Dokumentation von Aktivitäten, erreichten Nachbedingungen usw.). e-Services ermöglichen mehr oder weniger komplexe Funktionen, Aktivitäten oder Teilprozesse (z.B. Terminvereinbarung in einem entfernten Krankenhaus, die Berechnung einer Behandlung auf der Basis des ausgewählten Krankenhauses und der Krankenversicherung des Patienten); werden in der Regel mittels Internettechnologien durch Workflowteilnehmer ausgewählt und mit Benutzungsschnittstelle integriert.
Fachliche Services liefern Funktionen (im Englischen auch domain services, vgl. [LWZ01]) innerhalb von Anwendungen (z.B. automatische Auswertungen von Labordaten); werden in der Regel ohne eigene Schnittstelle zu den Workflowteilnehmern ausgewählt und integriert.
Technische Services unterstützen die für die Workflowverarbeitung notwendige Systemfunktionalität wie z.B. Implementierung von rollenbasierten Sichten und Verwaltung von Zugriffsrechten (z.B. verschiedene Sichten vom Datensatz eines Patienten entsprechend professioneller und organisatorischer Zugehörigkeit aktivierte); werden in der Regel auf der Ebene von Softwareanwendungen ohne eigene Benutzungsschnittstelle zu den Workflowteilnehmern ausgewählt und integriert. Objekt-Services erlauben den Zugriff auf und die Manipulation von informationelle Objekte (z.B. geduldigen Datensatz, Prozessplan für besonderen Patienten) ohne Funktionalität außer Methoden liefern, um direkt jene Objekte zu manipulieren; werden mit oder ohne Auswahl- bzw. Benutzungsschnittstelle zu den Workflowteilnehmern ausgewählt und integriert.
Grundsätzlich könnten alle diese Services als Web Services modelliert und spezifiziert werden, um die Kooperation von Dienstleistern auf der Basis von Internettechnologien zu unterstützen. Jedoch dürfen wir nicht vergessen, dass viele Aspekte der von Menschen bzw. sozialen Akteuren geleisteten Servicebeiträge der Formalisierung nicht zugänglich sind. Die IT-Unterstützung für Evaluation/Anforderung, Auswählen/vertragliche Bindung und Ausführung/Überwachung jener Services bleibt deshalb zwangsläufig beschränkt (in Abb. 2 daher gestrichelt dargestellt).
Es gehört zum Wesen von WFM, menschliche Aktivitäten, technische Operationen und andere Ressourcen miteinander zu verknüpfen. Mit Hilfe des Leitbilds des vertragsbasierten Prozessmanagement kann diese Verknüpfung erreicht werden, indem alle diese Ressourcen als Services konzipiert werden und dadurch ein einheitlicher Kommunikationsmechanismus (request/response) zur Verfügung steht. Allerdings, aufgrund der wesentlichen Unterschiede zwischen diesen Services ist keine übergreifende Formalisierung möglich, mit der alle Aspekte der einzelnen Serviceleistungen abgedeckt werden könnten. Jedoch können wir aus der übergreifenden Betrachtung von Ressourcen als Services mögliche Grundlagen für eine dezentraler Workflowsteuerung und für die Architektur und Implementierung von IT-Unterstützung in heterogenen Workflownetzen ableiten.
Welche Konzepte brauchen wir, welche Bemühungen sind notwendig, um ein vertragsbasiertes Prozessmanagement als IT-Unterstützung in heterogenen Workflownetzen zu implementieren? Aus unseren Überlegungen heraus lassen sich folgende wesentliche Eckpfeiler ableiten: • • •
Workflowsteuerung: Da wir nicht von einer übergreifend integrierten IT-Infrastruktur (mit einer zentralen Workflowsteuerung) ausgehen können, muss eine dezentralisierte Prozesssteuerung und -ausführung ermöglicht werden. In Prinzip kann jeder Work-unit durch eine eigene Workflowmaschine (workflow engine) unterstützt werden, um den Kontrollfluss von der vorangegangenen Maschine aufzunehmen, den Zyklus von Evaluation/Anforderung, Auswählen/vertragliche Bindung und Ausführung/Überwachung der heterogenen Workflowressorucen auszuführen und den Kontrollfluss dann zur (ggf. zu ermittelnden) nachfolgenden Maschine weiterzugeben. Es ist durchaus sinnvoll, die Funktionalität dieser dezentralen Workflowmaschinen selbst elementar auszulegen und die Aktivitäten des Zyklus durch explizite WFM-Services ausführen zu lassen. Diese WFM-Services können wiederum eine Kombination von menschlichen Aktivitäten (z.B. Dienstleistungsmitarbeitern, aber ggf. auch Kunde) und technischen Operationen sein (zur detaillierten Beschreibung der Aktivitäten im Zyklus siehe [KW02]).
Ressourcenbereitstellung: Der Schlüssel zu erfolgreichen Workflowbearbeitung ist (wie oben ausgeführt) die Fähigkeit, zur richtigen Zeit die Leistung der notwendigen Ressourcen in den Prozessverlauf integrieren zu können. Da die Anzahl und Art der (potenziellen) Ressourcen und auch der Bedarf nach ihrem flexiblen Gebrauch gestiegen sind, ist ein systematischer Ansatz erforderlich, um alle diese Ressourcen zu beziehen und zu integrieren. Als Minimalinfrastruktur schlagen wir einen Integrationsserver vor, der alle Ressourcen als Services erkennt und vertraglich binden kann, so dass die entsprechende Leistung von der Workflowsteuerung im Bedarfsfall abgerufen zu werden kann. In Prinzip kann jeder Work-unit von einem eigenen Integrationsserver unterstützt werden, aber ein Server kann auch einzelne oder viele Work-units innerhalb eines organisatorischen Netzes betreuen (solange der Nutzen die Kosten für Transaktion und notwendige Standardisierung aufwiegen). Auf der Seite der Ressourcen sollte jeder Integrationsserver sich auf ein dediziertes service repository beziehen oder außerhalb der eigenen Infrastruktur entsprechende Leistungen auf einem offenen elektronischen Markt für (Web) Services rekrutieren können. Standards: technisch-organisatorische Vereinbarungen zwischen den am Workflow Beteiligten sind relevant auf mehreren Ebenen: (1) Prozessmodellierung: Workflows sind so zu modellieren, dass sie erkennbar aus verbundenen bzw. integrierten Services bestehen, die alle notwendigen Ressourcen einbringen. Workflowmodelle sind selbst auch Ressourcen, als Prozessmuster bilden sie ein Gerüst für die Kooperation der Beteiligten und dienen als Blaupause (template) für die einzelnen Workflowinstanzen. (2) Kontrollfluss: das vertragsbasierte Prozessmanagement erfordert die Standardisierung von Kommunikation zwischen den beteiligten dezentralen Workflowmaschinen in Bezug darauf, wie der Kontrollfluss weiterzugeben ist und wie instanzbasierte Prozessrepräsentationen (und damit verbundene Daten) zu interpretieren und zu verarbeiten sind. (3) Service-Schnittstellen: es sind standardisierte Schnittstellen zu Services erforderlich, um die notwendigen Workflowressourcen flexibel und organisationsübergreifend auswählen, vertraglich binden und integrieren zu können. (4) Komponenten-Schnittstellen: eine standardisierte Schnittstelle zwischen Integrationsservern und dezentralen Workflowmaschinen ermöglicht flexible Architekturen, z.B. könnten mehrere Workflowmaschinen dann einen Integrationsserver nutzen, oder internetbasierte WFM-Services (für die Workflowsteuerung) könnten sich auf entfernte Integrationsserver beziehen.
vom vorherigen
Work unit WF-Kontrolle WF-Ressourcen Insgesamt betrachtet sollte die IT-Unterstützung für ein vertragsbasiertes Prozessmanagement aus eine modularisierten Architektur bzw. einem Netz von Komponenten bestehen (siehe Abbildung 2), wobei Evaluation/Anforderung, Auswählen/vertragliche Bindung und Ausführung/Überwachung von Workflowressourcen getrennt werden von der Bereitstellung dieser Ressourcen als Services. Auf dem Weg, mit Hilfe des Leitbilds des vertragsbasierten Prozessmanagement konkrete Systeme zu implementieren, stellen sich noch eine Reihe von Forschungsfragen – unter anderen: • • • • •
Wie können wir anwendungsorientierte Modellierungssprachen anreichern, um Workflows als bestehend aus heterogenen Services zu beschreiben? Wie sollten wir Workflowmaschinen entwerfen und implementieren, die bei der Workflowsteuerung menschliche Aktivitäten und technische Operationen (als WFM-Services) integrieren? Welches sind die Anforderungen an die Interaktion zwischen Workflowmaschinen und Integrationsserver? Welche Art Schnittstelle brauchen wir, um multilaterale Kommunikation zu unterstützen? Welches sind die angemessene Funktionalität und Architektur von Integrationsservern für Workflowressourcen? Welches ist die beste standardisierte Schnittstelle für Workflowressourcen als Services? Sind Standards für Web Services eine geeignete Ausgangsbasis? Was können wir von anderen Ansätzen lernen, um Services innerhalb von WFM miteinander zu verbinden? In der heutigen Workflowforschung werden eine Reihe von Konzepten für die flexible Einbindung von Workflowressourcen auf organisatorischen und technischen Ebenen entwickelt und erprobt – übergreifende Konzepte dafür sind allerdings bislang nicht erkennbar. Das Hauptargument hier ist, dass die durchgängige Konzipierung von Workflowressourcen als Services einen gemeinsamen Kommunikationsmechanismus bereitstellt, der in dem Zyklus von Evaluation/Anforderung, Auswählen/vertragliche Bindung und Ausführung/Überwachung jeweils eine situationsbezogene Kombination von menschlichen Aktivitäten, technischen Operationen und anderen Ressourcen ermöglicht (die in vielen Arbeitsumgebungen erforderlich ist, wo schwach strukturierte Geschäftsprozesse eine Flexibilität auf allen Stufen der Prozessdurchführung erfordern). Darauf aufbauend vertreten wir die These, dass das Leitbild des vertragsbasierten Prozessmanagements (gegenüber dem des definitionsbasierten Prozessmanagements) als gemeinsame Orientierung besser geeignet ist, um organisationsübergreifendes WFM insbesondere mittels Internettechnologien erfolgreich unterstützen zu können.
[AH02] [AJ00] [Al00] [AA99] [Ca00a] Casati, F.; Ilnicki, S.; Jin, L.; Krishnamoorthy, V.; Shan, M.C.: eFlow: a Plaform for Developing and Managing Composite e-Services. Software Technology Laboratory, HP Laboratories Palo Alto, HPL-2000-36, 2000 [Ca00b] Casati, F.; Ilnicki, S.; Jin, L.; Krishnamoorthy, V.; Shan, M.C.: Adaptive and Dynamic Service Composition in eFlow. Software Technology Laboratory, HP Laboratories Palo Alto, HPL-2000-39, 2000 [Ch01] Christophides, V.; Hull, R.; Kumar, A.; Siméon, J.: Workflow Mediation using
VorteXML. IEEE Data Engineering Bulletin, Jg. 24 (1), 2001, S. 40-45 [Gr01] Grefen, P.; Aberer, K.; Ludwig, H.; Hoffner, Y.: CrossFlow: Cross-Organizational Workflow Management for Service Outsourcing in Dynamic Virutal Enterprises. Data Engineering, Jg. 24 (1), 2001 [KW02] Klischewski, R.; Wetzel, I.: Processing by Contract. Turning the Wheel within Heterogeneous Workflow Networks. Eingereicht für: Business Process Management Journal (BPMJ), Special Issue on Internet-enabled Workflow Management [KWB01] Klischewski, R.; Wetzel, I., Bahrami, A.: Modeling Serviceflow. In: Proceedings ISTA 2001 (Information Systems Technology and its Applications). Gesellschaft für Informatik, Bonn, 2001, S. 261-272. [La97] Lawrence, P. (Hrsg.): Workflow Handbook 1997. John Wiley & Sons, New York, 1997 [Le01] Leymann, F.: Web Services Flow Language (WSFL 1.0). IBM Software
Communications Department, Somers, NewYork, 2001 [LWZ01] Lippert, M.; Wolf, H.; Züllighoven, H.: Domain Services for Multichannel Application
Software. In: Proceedings of HICSS-34, IEEE Computer Society, 2001 [Me88] Meyer, B.: Object-oriented Software Construction. Prentice Hall, Hertfordshire, 1988 [NIS92] National Information Standards Organization (NISO): Application Service Definition and Protocol Specification for Open Systems Interconnection,. ANSI/NISO Z39.501992. NISO Press, Bethesda, Maryland, 1992 [SGW01] Shegalov, G.; Gillmann, M.; Weikum, G.: XML-enabled Workflow Management for E
Services across Heterogeneous Platforms. VLDB Journal, Jg. 10 (1), 2001, S. 91-103 [Ve97] Veizades, J.; Guttman, E.; Perkins, C.; Kaplan, S.: Service Location Protocol. RFC 2165. Juni 1997, www.ietf.org/rfc/rfc2165.txt [WK02] Wetzel, I.; Klischewski, R.: Serviceflow beyond Workflow? Concepts and Architectures for Supporting Inter-Organizational Service Processes. In: Advanced Information Systems Engineering. Proceedings 14th CAiSE. Springer Lecture Notes in Computer Science, Berlin, 2002, S. 500-515 [WMC01] Workflow Management Coalition (WfMC): Workflow Process Definition Interface – XML Process Definition Language, Document Number WFMC-TC-1025 (Draft 0.03a), 2001, www.wfmc.org/standards/docs/xpdl_010522.pdf