Die Unterstützung von Anwendungsprozessen durch Informationssysteme ist für Wirtschaft, Verwaltung und Wissenschaft von großem Interesse. WorkflowManagement-Systeme haben sich dabei in vielen Anwendungsgebieten als adäquat und hilfreich erwiesen. Es gibt jedoch auch eine Vielzahl von Anwendungsszenarien, die in ihren Anforderungen bezüglich der Flexibilität der Prozessausführung, der Parallelität der Verarbeitung und dem Umgang mit Daten keine ausreichende Unterstützung durch Workflow-Management-Systeme finden. In diesem Beitrag wird das neuartige Konzept der Fallbehandlung (Case Handling) anhand der Anforderungen prozessorientierter Anwendungen motiviert, und seine zentralen Aspekte werden diskutiert. Fallbehandlung stellt keine Erweiterung der Konzepte des Workflow-Managements im Hinblick auf einzelne Aspekte - etwa Flexibilität - dar, sondern unterscheidet sich von diesem in den Grundlagen der Steuerung des Prozessablaufs und des Zugriffs auf Daten. Dadurch kann für eine Vielzahl von Anwendungen ein höheres Maß an Flexibilität und Parallelität bei der Ausführung erreicht werden.
Workflow Management Systeme (WFMS) erlauben die Modellierung und kontrollierte Ausführung von Anwendungsprozessen und stellen heute eine wesentliche Technologie für prozessorientierte Anwendungssysteme dar [GHS95, LR00, SGJ +96, JB96]. Während viele Anwendungsszenarien durch diese Systeme erfolgreich unterstützt werden können, gibt es auch eine Reihe von Defiziten, die den Einsatz von WFMS in einigen wichtigen Bereichen aufgrund mangelnder Flexibiltät und zu starrer Prozessstrukturen nicht geeignet erscheinen lassen. Obwohl sowohl Fallbehandlung als auch Workflow-Management auf die Unterstützung prozessorientierter Anwendungen abzielt, gibt es doch fundamentale Unterschiede: Während bei Workflow-Management Aktivitäten und deren Ausführungsreihenfolge eine zentrale Position einnehmen, sind dies bei der Fallbearbeitung Daten. Der Ablauf eines Prozesses wird nicht durch eine feste, vordefinierte Reihenfolge von Arbeitsschritten geregelt. Stattdessen werden lediglich die Abhängigkeiten zwischen Arbeitsschritten und den jeweils relevanten Daten beschrieben. Die Reihenfolge der Arbeitsschritte ist bei der Fallbehandlung aus diesem Grund lediglich das Resultat dieser Abhängigkeiten. Wie nachfolgend motiviert wird, passen die zentralen Konzepte der Fallbehandlung sehr gut zu prozessorientierten Organisationsformen, wo es nicht um eine Zergliederung von Arbeit, sondern um eine Integration mehrerer Arbeitsschritte auf einen Mitarbeiter geht.
Als eines der zentralen Probleme klassischer Workflow-Technologie wird von einigen Autoren die fehlende Flexibilität dieser Systeme angemahnt und entsprechende Erweiterungen bestehender Workflow-Technologie vorgeschlagen [Nut96, RD98, WHKS98]. Dabei werden jeweils recht komplexe Verfahren und Korrektheitskriterien entwickelt, die flexiblere Ausführungen erlauben. Damit sind zusätzliche Verfahren und Techniken erforderlich, um einen – zunächst stark strukturiert beschriebenen – Prozess a posteriori flexibel zu gestalten. Im Unterschied zu diesen Ansätzen werden die Prozessstrukturen bei der Fallbehandlung lediglich auf der Basis von Daten und damit weniger einschränkend definiert, so dass zur Laufzeit keine zusätzlichen, flexibilisierenden Maßnahmen notwendig sind. Dieser Beitrag ist wie folgt gegliedert: In Kapitel 2 werden anhand zentraler Aspekte der Prozessorientierung Anforderungen an ein prozessunterstützendes Informationssystem abgeleitet. Kapitel 3 gibt einen Überblick über die bestehenden Arten prozessunterstützender Informationssysteme. In Kapitel 4 werden zwei wesentliche Konzepte der Fallbehandlung vorgestellt. Dabei erfolgt jeweils eine Motivation vor dem Hintergrund des Business Process Redesign und eine Abgrenzung von den entsprechenden Konzepten des WorkflowManagement. Kapitel 5 fasst die Erkenntnisse zusammen und zeigt Grenzen und Erweiterungsmöglichkeiten des Ansatzes auf. 2
Unter einem Prozess versteht man eine teilweise geordnete Menge von Arbeitsschritten, die einen Mehrwert für ein Unternehmen schafft, etwa die Bearbeitung eines Kreditantrages. Das Konzept der Arbeitsteilung sieht vor, dass nicht alle Arbeitsschritte eines Prozesses von einer Person erledigt werden, sondern dass sich die Personen auf bestimmte Arbeitsschritte spezialisieren. Es hat sich gezeigt, dass sich durch diese Spezialisierung eine hohe Produktivitätssteigerung erreichen läßt. Ursprünglich für die industrielle Produktion entwickelt, fand dieses Konzept immer breitere Anwendung in vielen Gebieten von Wirtschaft und Verwaltung [HC93]. Diese Arbeitsteilung bringt allerdings auch Nachteile mit sich. Hierzu gehören in erster Linie mangelnde Flexibilität, hohe Durchlaufzeiten und fehlende Übersicht über den Prozessablauf. Diese Nachteile spielten lange Zeit gegenüber dem Gewinn an Produktivität eine untergeordnete Rolle. In heutigen Märkten, in denen das Angebot die Nachfrage übersteigt, hat sich diese Situation grundlegend geändert. Die Kunden erwarten individuelle, flexible und zügige Lösungen für ihre Wünsche. Bezogen sich bis dahin Optimierungsansätze in erster Linie isoliert auf die einzelnen Arbeitsschritte, setzte sich nun die Erkenntnis durch, dass um eine wesentliche Verbesserung der Flexibilität und Durchlaufzeit von Prozessen zu erreichen, sich die Betrachtung nicht auf die einzelnen, funktionalen Einheiten beschränken darf, sondern auf den gesamten, sie durchlaufenden Prozess ausgeweitet werden muss. Entsprechende Ansätze bezeichnet man allgemein als Business Process Redesign [WWK94, Mal98].
Das Ausmaß der propagierten Änderungen ist jedoch sehr unterschiedlich. Das Spektrum reicht von evolutionären Ansätzen, die die Aufbauorganisation unverändert lassen und sich auf die in diesem Rahmen möglichen Optimierungen beschränken, bis hin zu dem radikalen Neudesign der kompletten Struktur einer Unternehmung, bei dem in nicht auf die bestehende Organisationsform Rücksicht genommen wird. Bei dem evolutionären Ansatz steht die schrittweise Optimierung des Prozessablaufs im Vordergrund. Im Rahmen der bestehenden Aufbauorganisation wird der gesamte Prozess betrachtet und nach Optimierungsmöglichkeiten gesucht; die Arbeitsteilung wird dabei im wesentlichen beibehalten. Wesentliche Verbesserungen der Durchlaufzeit, der Flexibilität und der Qualität lassen sich nur erreichen, wenn man die Organisation des Unternehmens grundlegend ändert und die Bearbeitung eines Prozesses wieder in die Verantwortung einer Person legt. Ein entsprechender Ansatz wurde unter der Bezeichnung Business Reengineering vorgestellt [HC93] und diskutiert [Dav95, CJS94, JWA94]. Entgegen dem bisher vorgestellten evolutionären Ansatz des Business Process Redesign ist das Business Reengineering eine radikalere Variante, da es eine komplette Restrukturierung des gesamten Unternehmens vorsieht. Zentrale Idee hierbei ist, die einzelnen Arbeitsschritte eines Prozesses wieder zusammenzuführen und einer Person die Verantwortung für diesen Prozess zu geben. Der Prozess durchläuft nicht mehr verschiedene Abteilungen und wird nicht von einer Person zur nächsten weitergereicht, sondern soweit wie möglich von einer Person an einem Ort bearbeitet. Hierzu benötigt sie als Generalist natürlich Fachwissen aus den unterschiedlichen Bereichen, das die Voraussetzung für die Bearbeitung der Prozesse darstellt. Indem die Arbeit nicht mehr von Person zu Person weitergereicht wird, entfallen die hierbei auftretenden Verluste und Wartezeiten. Die Durchlaufzeit verkürzt sich dramatisch. Da eine Person Überblick über den gesamten Prozess hat und für ihn verantwortlich ist, kann sie prozessübergreifende Änderungen kontrollieren, flexibel auf Ausnahmesituationen reagieren und die voraussichtliche, restliche Bearbeitungszeit bestimmen. Dies ist in arbeitsteilig organisierten Unternehmen nur mit großem Aufwand möglich.
Ein Generalist kann natürlich nicht auf jedem Gebiet die gleichen tiefen Kenntnisse besitzen wie ein Spezialist. Deshalb wird er bei komplizierten Fällen auf die Mithilfe eines Spezialisten zurückgreifen müssen. Jedoch behält er immer die Verantwortung und den Überblick über den Prozess und kann einfach strukturierte Fälle sogar völlig selbständig bearbeiten. Bei der arbeitsteiligen Organisation geht man davon aus, dass jeder Fall potentiell kompliziert ist. Deshalb wird jeder Arbeitsschritt von einem Spezialisten durchgeführt, der in der Lage ist, auch den kompliziertesten Fall zu bearbeiten. In der Praxis hat sich jedoch häufig gezeigt, dass die große Mehrzahl der Fälle eher einfach strukturiert ist und routinemäßig von einem Generalisten bearbeitet werden kann. Neben den beiden Möglichkeiten, dass ein Generalist alle Schritte eines Prozesses allein ausführt, bzw. dass alle Schritte an Spezialisten delegiert werden müssen, erscheint es sinnvoll für jede Ausführung des Prozesses individuell zu entscheiden, welche Arbeitsschritte aufgrund ihrer Komplexität an Spezialisten delegiert werden müssen und welche von dem verantwortlichen Generalisten selbst ausgeführt werden können. Legende: Anforderungsprofil Kundendaten
Stückliste
Workflow-Management-Systeme setzen, um eine Unterstützung anbieten zu können, eine Modellierung der betroffenen Prozesse voraus. Dies geschieht in einem Workflow-Schema. Die systeminternen Abbildungen der einzelnen Ausführungen eines Workflow-Schemas bezeichnet man als Workflow-Instanzen. Mit dem Workflow-Schema wird dem WFMS mitgeteilt, aus welchen Schritten sich der Prozess zusammensetzt, welche Kontroll- und Datenflussbeziehungen zwischen diesen bestehen und welche Personen (durch Rollen beschrieben) welche Schritte ausführen können.
Zur Veranschaulichung wird an dieser Stelle der Prozess der Bearbeitung einer Angebotsanfrage dargestellt. Der entsprechende Prozess ist als Workflow-Schema W1 in Abbildung 1 dargestellt. Das Workflow-Schema basiert auf einer graphenbasierten WorkflowSprache, die an die in [LR00] verwendete angelehnt ist. Bei einer Angebotsanfrage beschreibt ein Kunde eine gewünschte Leistung und bittet ein Unternehmen um ein Angebot. Der Prozess wird durch den Eingang der Angebotsanfrage im Unternehmen initiiert. In Aktivität A1 werden die Kundendaten aufgenommen, aus der Leistungsbeschreibung des Kunden ein Anforderungsprofil formuliert und dem Kunden der Eingang der Anfrage bestätigt. Ist A1 abgeschlossen, können A2 und A4 ausgeführt werden. Durch den Kontrollfluss wird sichergestellt, dass die von A2 und A4 benötigten Daten zum Zeitpunkt ihrer Ausführung vorhanden sind. In A2 wird eine Kundenanalyse durchgeführt, die die Bestimmung vereinbarter Rabatte, die Prüfung der Bonität, eine Bewertung der strategischen Bedeutung des Kunden und, falls es sich um einen ausländischen Kunden handelt, die Bestimmung der gültigen Exportbestimmungen für das betreffende Land umfasst. Alle diese Ergebnisse sind Bestandteil der Kundenbewertung, die das Resultat dieser Aktivität darstellt.
In A4 wird für die Anforderung des Kunden eine technische Lösung erarbeitet, wobei hierbei zur Vereinfachung nur die Stückliste als Ergebnis der Aktivität betrachtet wird. Diese Stückliste dient in A5 der eigenen Kalkulation. Auf deren Basis und der Kundenbewertung wird in A3 letztlich ein Angebot erstellt. Hierzu gehört die Festlegung des Preises und die Formulierung eines Angebotstextes. Für unser Beispiel sollen des weiteren folgende Randbedingungen gelten: Die Ausführungsdauer des Prozesses (Durchlaufzeit) ist eine für das Unternehmen besonders kritische Größe und soll so klein wie möglich sein. Aus diesem Grunde wird A2 nebenläufig zu A4 und A5 durchgeführt. Während A1 und A3 stets von einem Generalisten ausgeführt werden können, kann bei A2, A4 und A5 in komplizierten Fällen eine Übergabe an entsprechende Spezialisten notwendig sein. 4
In diesem Kapitel wird die Fallbehandlung in ihren grundlegenden Konzepten vorgestellt: die datenbasierte Prozesssteuerung und der Zugriff auf alle fallbezogenen Informationen. Dabei erfolgt jeweils eine Motivation vor dem Hintergrund des Business Process Redesign und eine Abgrenzung von den entsprechenden Konzepten des Workflow-Management. Während beim Workflow-Management der Fokus auf der Modellierung von Aktivitäten und dem Kontrollfluss zwischen diesen Aktivitäten liegt, stehen bei der Fallbehandlung der Fall und die damit verbundenen Daten im Vordergrund. Die daraus resultierenden Unterschiede betrachten wir in den folgenden Abschnitten im Detail und beurteilen ihre Eignung in Bezug auf die Unterstützung prozessorientierter Organisationsformen. 4.1
Während beim Workflow-Management die Steuerung über den Kontrollfluss erfolgt, besitzt die Fallbehandlung eine datenbasierte Steuerung. Die Entscheidung, ob eine Aktivität ausgeführt werden kann, wird auf Basis der vorhandenen Datenobjekte, anstatt der ausgeführten Aktivitäten getroffen. Analog zu einem Workflow-Schema wird bei der Fallbehandlung ein Fall-Schema (Case Schema) definiert, auf dessen Basis ein Fallbeabei
D0 Angebotsanfrage
D2 Kundenbewertung
D5 Stückliste tungssystem (Case Handling System) die Ausführung von Anwendungsprozessen begleiten kann.
In Abbildung 2 ist das Beispiel der Angebotsanfrage entsprechend der Fallbehandlung in einem Fall-Schema dargestellt. Bei der Fallbehandlung werden einzelne Arbeitsschritte als Aktivitäten modelliert, welche als Rechtecke dargestellt werden. Ein wesentlicher Unterschied zu dem oben beschriebenen Workflow-Schema ist das Fehlen des Kontrollflusses. Stattdessen besitzen Aktivitäten Beziehungen zu Datenobjekten. Datenobjekte werden dabei oval dargestellt. Die Beziehungen zwischen den Aktivitäten und den Datenobjekten sind gerichtet. Ein Pfeil von einer Aktivität zu einem Datenobjekt bedeutet, dass dieses Datenobjekt ein Ergebnis der Aktivität ist. Ein Pfeil von einem Datenobjekt zu einer Aktivität bedeutet, dass ein Datenobjekt zur Durchführung einer Aktivität benötigt wird. Dadurch können Datenabhängigkeiten zwischen Aktivitäten definiert werden: Zum Beispiel benötigt A2 das Datenobjekt D1 zur Ausführung, denn eine Kundenanalyse kann nicht durchgeführt werden, bis die notwendigen Informationen vorliegen. Beim WorkflowManagement werden diese Datenabhängigkeiten über Kontrollfluss implementiert. Dabei wird sichergestellt, dass A2 erst starten kann, wenn Aktivität A1 beendet wurde. Diese streng sequenzielle Ausführung von A1 und A2 ist aber nicht notwendig und stellt in diesem Fall eine allzu starke Einschränkung der zulässigen Ausführungen dar: Falls die Kundendaten bereits zu Beginn der Ausführung von A1 aufgenommen werden, könnte A2 dann bereits ausgeführt werden, während Aktivität A1 noch aktiv ist! Bei der Implementierung einer solchen Datenabhängigkeit über den Kontrollfluss findet somit eine unnötige Sequenzialisierung der Aktivitäten statt, welche die Menge der gültigen Ausführungen unnötig einschränkt. Diese Einschränkung umgeht die Fallbehandlung, indem der Sachverhalt der Datenabhängigkeit unmittelbar im Fall-Schema modelliert wird. Hiermit wird ein potentiell höherer Grad an Parallelität erreicht. Dabei stellt der Zeitraum von dem die Kundendaten erfasst sind bis zum Abschluss von A1 genau den zeitlichen Vorteil dar, den man durch eine datenbasierte Steuerung gewinnen kann. Besonders groß kann dieser Zeitraum in unserem Beispiel dann werden, wenn eine vollständige Aufstellung des Anforderungsprofils nicht möglich ist, weil die Beschreibung des Kunden unklar formuliert ist. Ist hier eine Rückfrage erforderlich, kann sich der Abschluss von A1 stark verzögern. Wie diese Beispiele zeigen, ermöglicht die direkte Modellierung der Datenabhängigkeiten einen höheren Grad an Parallelität der Prozesse. Die damit einhergehende Verkürzung der Durchlaufzeiten ist für viele Geschäftsprozesse von großer Bedeutung und ein zentrales Ziel des Business Process Redesign [HC93].
Es stellt sich nun die Frage, ob die Ablauflogik, wie sie hier als Fall-Behandlung dargestellt wurde, nicht auch als Workflow modelliert werden kann. Beim Workflow-Management erfolgt die Steuerung des Ablaufs über den Kontrollfluss. Dies bedeutet, dass die Vorbedingung für den Start einer Nachfolgeaktivität immer die Beendigung einer Vorgängeraktivität ist. Das entscheidende Kriterium ist also immer die Beendigung einer Aktivität und nicht wie bei der Fallbehandlung die Existenz eines Datenobjekts. Ein Ansatz, die Ablauflogik der Fallbehandlung in einem Workflow nachzustellen, ist somit die Eingabe jedes steuernden Datenobjekts als Aktivität abzubilden. In Abbildung 3 ist das WorkflowSchema W2 dargestellt, in dem A1 in mehrere Aktivitäten aufgespalten wurde. Es existieren jetzt gesonderte Aktivitäten A6 und A7, die jeweils nur die Eingabe der Datenobjekte D1 (Kundendaten) bzw. D3 (Anforderungsprofil) zum Gegenstand haben. Das WorkflowSchema W2 entspricht dem Fall-Schema insofern, als dass A2 starten kann, sobald die Kundendaten eingegeben wurden und A4 starten kann, sobald das Anforderungsprofil eingegeben wurde. Bei dieser Modellierung besteht allerdings die Problematik, dass nicht mehr sichergestellt ist, dass die Aktivitäten A6, A7 und A8 einer Instanz von der gleichen Person ausgeführt werden, wie es entsprechend dem ursprünglichen Schema festgelegt war. Soll dieser Zusammenhang bestehen bleiben, ist für das Workflow-Schema ein neues Modellierungskonstrukt notwendig, das es erlaubt festzulegen, dass eine Menge von Aktivitäten einer bestimmten Workflow-Instanz jeweils nur von einer Person durchgeführt werden darf, so dass für diese Aktivitäten jeweils nur eine Rollenauflösung stattfindet. Mit einem solchen Modellierungskonstrukt und der Modellierung jeder Eingabe eines steuernden Datenobjekts als einzelne Aktivität ließe sich die Ablauflogik der Fallbehandlung in diesem Beispiel nachbilden.
Eine solche Modellierung erscheint jedoch im Vergleich zu der Modellierung in der Fallbehandlung als recht umständlich. In der Fallbehandlung wird eine Datenabhängigkeit zwischen zwei Aktivitäten direkt über Beziehungen zu dem betroffenen Datenobjekt zum Ausdruck gebracht. Beim Workflow-Management hingegen wird die Konsistenz der Ausführung bei Datenabhängigkeiten zwar über den Kontrollfluss sichergestellt, aber aus dem Workflow-Schema ist nicht mehr direkt ersichtlich, welche Datenabhängigkeit der Grund für diesen Kontrollfluss ist. Wie in dem Beispiel gezeigt wurde, kann es des weiteren durch
A6 Kundendaten erfassen
A7 Anforderungen erfassen
A8 Anfrage bestätigen
Stückliste die indirekte Modellierung der Datenabhängigkeiten über den Kontrollfluss dazu kommen, dass ein Prozess in unnötiger Weise sequenzialisiert wird. Dieses kann ggf. zu größeren Durchlaufzeiten des gesamten Prozesses führen. 4.2
Bei dem Übergang von arbeitsteiligen zu prozessorientierten Organisationsformen ergibt sich ein neues Berufsbild eines Mitarbeiters. An die Stelle des Spezialisten für ein bestimmtes, klar abgegrenztes Aufgabengebiet tritt der Generalist. Er hat ein weitaus breiteres Betätigungsfeld, das sich nicht mehr klar von dem der Spezialisten abgrenzen lässt. Die Grenzen der Zuständigkeit können sich verwischen [HC93].
Das Konzept eines Generalisten kann nur erfolgreich sein, wenn die entsprechenden Rahmenbedingungen geschaffen werden. Hierzu gehört insbesondere, dass ein Generalist Zugriffsrechte auf alle Informationen besitzt, die er zur Bearbeitung eines Prozesses potentiell benötigt. Während der Zugriff eines Spezialisten auf die für seine Tätigkeit benötigten Informationen eingeschränkt werden kann, ist für einen Generalisten der Zugriff auf alle, den Prozess betreffenden Informationen Voraussetzung für eine effektive Arbeit. Workflow-Management-Systeme bieten zur Ausführung einer Aktivität immer nur die zum Zeitpunkt der Modellierung als relevant erachteten Dokumente zur Bearbeitung oder Einsichtnahme an. Diese Festlegung des Datenflusses ist Bestandteil des WorkflowSchemas. Es ist zwar unter Umständen möglich, das System zu umgehen und auf anderen Wegen an die gewünschten Informationen zu gelangen, jedoch ist dies nicht vorgesehen und wird nicht unterstützt. Insofern spiegelt Workflow-Management im Umgang mit Informationen die traditionelle Sicht der arbeitsteiligen Organisationsform wieder, in denen der Mitarbeiter nur mit den für seine Aufgabe vorhersehbar notwendigen Informationen versorgt wird. Dieses Vorgehen wird auch als Information Tunneling bezeichnet [AW01]. In dieser Denkweise hat der Arbeiter als Spezialist weder die Kompetenz noch den Überblick, um weitere Informationen sinnvoll zu verwerten. Demgegenüber ist der freie Zugriff auf alle Informationen, die mit der Bearbeitung eines Prozesses in Zusammenhang stehen, charakteristisch für die Fallbehandlung. Bei der Fallbehandlung können Datenobjekte auch vor und nach der Ausführung der im Fall-Schema dafür vorgesehenen Aktivität eingegeben, modifiziert und gelesen werden. Beispielsweise ist im Fall-Schema das Datenobjekt D5 als Ergebnis der Aktivität A4 dargestellt. Dies bedeutet, dass A4 erst beendet werden darf, wenn D5 erzeugt wurde. Damit soll sichergestellt werden, dass alle für den Prozessfortlauf notwendigen Daten erzeugt werden. Auf der anderen Seite bedeutet dies nicht, dass auf D5 nur von A4 aus zugegriffen werden darf. Vielmehr kann auf D5 grundsätzlich von jeder Aktivität aus zugegriffen werden.
Betrachten wir einen lesenden Zugriff. Die Existenz von D1 ist im Fall-Schema als Voraussetzung für die Ausführung von A2 modelliert. Dies bedeutet, dass eine Kundenanalyse ohne diese Information nicht durchgeführt werden kann. Es kann jedoch durchaus sinnvoll sein, weitere Informationen bei der Analyse zu berücksichtigen. Handelt es sich zum Beispiel um einen Kunden im Ausland, so werden bei der Kundenanalyse (A2) auch die für ihn gültigen Exportbeschränkungen bestimmt. Existiert zu diesem Zeitpunkt die Stückliste (D5) bereits, kann die Prüfung der Exportbeschränkungen auf die relevanten Positionen beschränkt werden. Ist die Stückliste noch nicht verfügbar, müssen bei der Kundenanalyse die vollständigen Exportbeschränkungen bestimmt werden und ein Abgleich mit der Stückliste kann erst in A3 erfolgen. Wie dieses Beispiel zeigt, ermöglicht der freie Zugriff auf alle den Fall betreffenden Informationen eine flexiblere und effektivere Arbeit. Betrachten wir nun schreibende Zugriffe. Bei der Angebotsanfrage darf A1 erst beendet werden, wenn D1 und D3 erzeugt wurden. Dies wird im Fall-Schema durch die Pfeile von A1 zu D1 und D3 dargestellt. Optional können in A1 jedoch auch schon weitere Datenobjekte angelegt werden. Existiert beispielsweise eine Datenbank schon bearbeiteter Anforderungsprofile mit entsprechenden technischen Lösungen und gelingt es bereits bei der Ausführung der Aktivität A1 ein zur aktuellen Anfrage äquivalentes Anforderungsprofil zu finden, so kann direkt das Datenobjekt D5 (die Stückliste) erzeugt werden. Hierdurch wird implizit auch A4 ausgeführt, und A5 steht zur Bearbeitung an. Es ist in dieser Instanz somit keine Rollenauflösung für die A4 nötig – ein Weiterreichen von Arbeit wird vermieden. Dies ist ein elementarer Gedanke des Business Reengineering. Ein Generalist, der A1 ausführt, ist bei einfachen Fällen – dank seiner breiten Fachkenntnisse – in der Lage, Arbeitsschritte zu übernehmen, die normalerweise von Spezialisten ausgeführt werden. Im Extremfall kann dies bedeuten, dass der gesamte Prozess der Bearbeitung einer Angebotsanfrage von einer Person durchgeführt wird. Die Fallbehandlung unterstützt dabei in idealer Weise alle Fälle von Ausführungen, bei denen die Aktivitäten A2, A3 und A4 von Spezialisten ausgeführt werden müssen bis zu sehr einfach strukturierten Fällen die ein Generalist allein bearbeiten kann.
Die Fallbehandlung bietet auf Basis der Modellierung von Aktivitäten und der Zuordnung von Rollen Unterstützung bei der Übergabe von Arbeit an Spezialisten über die dynamische Rollenauflösung. Im Fall-Schema wird sichergestellt, dass beim Start dieser Aktivitäten die notwendigen Daten vorhanden sind. Da Datenobjekte jedoch schon erzeugt werden
Kundendaten, Selbstkosten
Stückliste können, bevor dies nach dem Fall-Schema zwingend notwendig ist, bleibt die Übergabe der Arbeit optional. Diese Flexibilität der Ausführung besitzt das Workflow-Schema W1 nicht. Auch hier stellt sich wieder die Frage, ob sich die Ausführung des Prozesses durch eine Modifikation des Workflow-Schemas W1 in einer entsprechenden Weise flexibilisieren läßt. In dem Beispiel soll nach Beendigung von Aktivität A1 je nachdem, ob das Datenobjekt D5 existiert oder nicht, als nächstes die Aktivität A5 oder A4 ausgeführt werden. Das bedeutet, es wird an dieser Stelle ein alternativer Kontrollfluss A1!A5 und der dem Datenobjekt D5 entsprechende Datenfluss benötigt. Zu dem alternativen Kontrollfluss wird eine Bedingung formuliert, die in Abhängigkeit davon, ob die Stückliste in Aktivität A1 eingegeben wurde, die passende Alternative bestimmt. Bei der Ausführung der WorkflowInstanz wird diese Bedingung dann nach Beendigung von Aktivität A1 ausgewertet und entsprechend dem Ergebnis Aktivität A4 oder A5 zur Ausführung freigegeben. Um generell die Ablauflogik der Fallbehandlung in Bezug auf die variable Eingabe von Datenobjekten nachzubilden, müssen derartige alternative Kontrollflüsse für alle Möglichkeiten der Ausführung gebildet werden. Dies entspricht der transitiven Hülle der Kontrollfluss-Beziehungen. Neben dem oben beschriebenen zusätzlichen Kontrollfluss A1!A5 gehören hierzu A4!A3 und A1!A3. Zu jedem alternativen Kontrollfluss gehört eine Bedingung, die dann zur Laufzeit die Existenz des entsprechenden Datenobjekts prüft und die passende nachfolgende Aktivität bestimmt. In Abbildung 4 ist das entsprechende Workflow-Schema W3 dargestellt, in dem alle alternativen Kontrollflüsse und die zugehörigen Datenflüsse abgebildet sind. Jedoch entspricht auch ein solches Workflow-Schema noch nicht der Ausführungslogik des Fall-Schemas. Der frühste Zeitpunkt, an dem A5 entsprechend W3 gestartet werden kann, ist nach Beendigung von A1. In dem Fall-Schema kann A5 gestartet werden, sobald die Stückliste (D5) eingegeben wurde. Hier sind wir wieder bei den Überlegungen des vorhergehenden Kapitels. Es gilt nun die Konzepte zur Nachbildung des Fall-Schemas als Workflow-Schema aus diesem und dem vorhergehenden Kapitel zu verbinden. Ein Ansatz ist, W2 so zu erweitern, dass A1 aus W1 nicht nur in drei Aktivitäten aufgeteilt wird, sondern in so viele, dass nicht nur die Eingabe von D1 und D3 als eigenständige Aktivitäten abgebildet sind, sondern auch die Eingaben aller anderen Datenobjekte. Diese Aktivitäten wären dann die Ausgangspunkte für die oben genannten zusätzlichen, alternativen Kontrollflüsse. Bei dieser Art der Modellierung ergibt sich jedoch das Problem, dass die Eingabe der Stückliste bei der Erfassung der Anfrage nicht mehr optional ist.
Zusammenfassend kann man sagen, das eine dem Fall-Schema entsprechende Modellierung als Workflow-Schema in Ansätzen möglich ist, aber schnell hoch komplex und unübersichtlich wird. Auf der anderen Seite ist für die Fallbehandlung mit ihrer datenbasierten Prozesssteuerung eine unmittelbare und einfache Modellierung im Fall-Schema kennzeichnend. Die datenbasierte Prozesssteuerung bietet zusammen mit der Möglichkeit des Zugriffs auf alle fallbezogenen Informationen dazu ein hohe Flexibilität der Ausführung und erfüllt damit insbesondere die Anforderungen eines prozessorientierten Unternehmens. 5
Fallbehandlung ermöglicht durch eine unmittelbare Modellierung von Datenabhängigkeiten eine im Vergleich zu einem entsprechenden Workflow höhere Parallelität der Prozessausführung. Zusammen mit dem freien Zugriff auf alle fallbezogenen Daten wird des weiteren eine Flexibilisierung der Ausführung erreicht. Fallbehandlung ist besonders zum Einsatz in prozessorientiert organisierten Unternehmen geeignet, in denen wesentliche Teile der Prozessbearbeitung von Generalisten übernommen werden und Spezialisten nur in Ausnahmesituationen zum Einsatz kommen. Demgegenüber entspricht WorkflowManagement von der Konzeption eher dem evolutionären Ansatz des Business Process Redesign, bei dem die strikte Arbeitsteilung beibehalten wird und in diesem Rahmen Probleme wie etwa Weiterleitung von Arbeit und fehlende Übersicht angegangen werden. Der freie Zugriff auf alle fallbezogenen Daten erfordert vor dem Hintergrund einer potentiell parallelen Bearbeitung durch mehrere Personen Transaktionskonzepte, die dabei die Datenkonsistenz sicherstellen. Hierbei ist eine genaue Abwägung zwischen der Flexibilität der Prozessausführung und einer eventuell notwendigen Einschränkung der ACIDEigenschaften von großer Bedeutung. Der grundsätzlich freie Zugriff auf Daten, den die Fallbehandlung bietet, sollte über ein Rechtemanagement kontrollierbar sein. Beim Workflow-Management werden Zugriffsrechte indirekt dadurch kontrolliert, dass nur über bestimmte Aktivitäten auf Daten zugegriffen werden kann. Ein Bearbeiter muss das Recht besitzen, die Aktivität auszuführen, um auf die entsprechenden Daten zugreifen zu können. Die Verwaltung der Zugriffsrechte von Personen auf Daten findet also indirekt über die Aktivitäten statt. Bei der Fallbehandlung kann bei der Bearbeitung einer Aktivität prinzipiell auf alle Datenobjekte des Falls zugegriffen werden. Daher ist hier ein Rechtemanagement notwendig, das direkt auf der Beziehung zwischen Bearbeiter und Datenobjekt basiert. [AW01] [CJS94] [Dav95] [GHS95] [HC93] [JB96] [JWA94] [LR00] [Mal98] [Nut96] [RD98] [RK01] [SGJ+96]
W.M.P. van der Aalst and Mathias Weske. Case Handling: A New Paradigm for Business Process Support. 2001.
J. Raymond Caron, Sirkka L. Jarvenpa, and Donna B. Stoddard. Business Reengineering at CIGNA Corporation: Experiences and Lessons Learned From the First Five Years. Management Information Systems Quaterly, 18, 1994.
Thomas H. Davenport. The Fad That Forgot People. FastCompany Magazine, 1, 1995. Dimitrios Georgakopoulos, Mark F. Hornick, and Amit P. Sheth. An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, 3(2):119–153, 1995.
Michael Hammer and James Champy. Reengineering the corporation. Harper Collins Publishing, New York, 1993.
S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, 1996.
Robert Janson, Roy W. Walters, and Associates. Time to get some satisfaction! Continuous Journey, 1994.
Frank Leymann and Dieter Roller. Production workflow: concepts and techniques. Prentice Hall, 2000.
Yogesh Malhotra. Business Process Redesign: An Overview. IEEE Engineering Management Review, 26, 1998.
Gary J. Nutt. The evolution towards flexible workflow systems. Distributed Systems Engineering, 3:276–294, Dec 1996.
Manfred Reichert and Peter Dadam. ADEPT flex -Supporting Dynamic Changes of Workflows Without Losing Control. Journal of Intelligent Information Systems, 10(2):93–129, 1998.