-
Die
vorliegende Erfindung betrifft Techniken zum Koordinieren von organisatorischen
Prozessen und insbesondere Datenverarbeitungssysteme und -verfahren,
die eine flexible Darstellung, Simulation und Umsetzung von Arbeitsprozessen
unter Verwendung von verallgemeinerten Prozessstrukturgrammatiken
(GPSG) bereitstellen.
-
Es
gibt viele Beispiele für
Prozesse, die innerhalb einer Organisation ausgeführt werden,
typischrweise auf einer vernetzten Datenverarbeitungs-Plattform,
für die
von mehreren Einzelpersonen oder Abteilungen Eingaben bereitgestellt
oder daraus Aktionen (Aufgaben) abgerufen werden. Zum Beispiel kann
es sein, dass für
einen Geschäftsführer ein
monatlicher Bericht erstellt werden muss, wobei jede von drei Abteilungen
einen Teil zu dem Bericht beiträgt,
ein erster Manager eine Zusammenfassung erstellt, die in den Bericht
aufgenommen wird, und ein zweiter Manager den Bericht in seiner
endgültigen
Form abnimmt, bevor er dem Geschäftsführer vorgelegt
wird, (oder ihn zurückweist
und an die vorherige Personen mit Änderungsanweisungen zurückgibt).
-
Ein
Beispiel eines computerbasierten Verfahrens zur Modellerstellung
und Verwaltung von Geschäftsprozessen
ist in WO-A94/29804 beschrieben. Die Modellerstellung basiert auf
einem Projektmodell, das eine Regel verwendet.
-
Der
Artikel "Prozess
Enactment and Coordination" von
J.-M. Andreoli, J.-L. Meunier, D. Pagani, Sitzungsprotokoll des
EWSPT '96, Nancy
(Frankreich), 9.–11.
Oktober 1996 beschreibt ein Werkzeug zur Koordinierung in Software-Entwicklungsprozessen
sowie in allgemeiner Büroarbeit
und Wissensverarbeitungsprozessen. Das "Koordinationssprachen-Leistungsmerkmal" (coordination language
facility) (CLF) basiert auf einem Objektmodell. Verschiedene IPO-(input-process-output)
Prozessmodelle können
implementiert werden.
-
Ein
Problem bei einigen herkömmlichen
Näherungsweisen
bezüglich
der Koordinierung von Aktivitäten
in Organisationen, wie beispielsweise solchen, die auf Petri-Netzen
und ihren Varianten basieren, besteht darin, dass der Entwickler
den gesamten Prozess im Voraus vollständig mit Alternativen und Aufgabenzuweisungen
spezifizieren muss.
-
Zwar
sind die Workflow-Näherungsweisen bezüglich der
Koordinierung von Aktivitäten
auf großes
Interesse gestoßen,
doch liegt ein Mangel in der Starrheit ihrer organisatorischen Verarbeitungsmodelle.
Diese Näherungsweisen
und die mit ihnen verbundenen Nachteile werden in der britischen
Patentanmeldung 9623954.6 erläutert,
von der eine Kopie zusammen mit der vorliegenden Anmeldung eingereicht
wurde (im Folgenden "Ref.
1").
-
Den
Workflow-Näherungsweisen
für gemeinschaftliches
Arbeiten steht eine Anzahl von Systemen für computerunterstütztes gemeinschaftliches Arbeiten
(CSCW) (computer-supported co-operative work systems) gegenüber, wie
beispielsweise Gruppen-Editorprogramme und gemeinsam genutzte Arbeitsbereiche,
bei denen Darstellungen des organisatorischen Kontexts und der Ziele
absichtlich fehlen. Diese werden in Ref. 1 erläutert.
-
Weitere
Probleme bekannter Systeme werden in Ref. 1 erläutert.
-
Es
ist offenkundig, dass ein Bedarf an Systemen besteht, in die keine
starren Arbeits-Darstellungen
eingebettet sind und die den Bedürfnissen
der Benutzer nach technologischer Unterstützung von koordinierten Leistungen
Rechnung tragen. Daher besteht ein Bedarf an Systemen, in die flexible
Arbeits-Darstellungen eingebettet sind.
-
Dies
wird durch die Merkmale der Nebenansprüche erreicht.
-
Die
vorliegende Erfindung betrifft Verfahren und Systeme zum Darstellen,
Simulieren und Umsetzen von Arbeit, die auf einer Prozessgrammatik-Näherungsweise
beruhen, die auf Regeln, Objekten, Merkmalen und Bedingungen basiert.
-
Die
Erfindung verwendet vorzugsweise einen Rahmen, in den Grammatikregeln
integriert sind, um Darstellungen von Arbeits- und Merkmalsbedingungen
zu generieren, welche komplexe Arbeitsartefakte darstellen und die
grundlegenden Fähigkeiten von
kontextfreien Programmen zu steigern. Dieser Rahmen wird des Weiteren
in Ref. 1 erläutert.
-
In
den Verfahren und Systemen gemäß den bevorzugten
Ausführungsformen
der Erfindung können
neue Regeln hinzugefügt
und bestehende Regeln gelöscht
werden. Ein Vorteil ist, dass dies offene Prozessdefinitionen ermöglicht,
wodurch eine inkrementelle Prozessentwicklung über die Sammlung von lokalen
fallbezogenen Definitionen von untergeordneten Prozessen gestattet
wird. Deshalb werden die herkömmlichen
Modellierungs-Näherungsweisen vermieden,
die eine Vorlage verwenden, die als Ganzes definiert und modifiziert
werden muss.
-
Vorzugsweise
sind duale Darstellungen von Dokumenten und Aktivitäten vorgesehen:
eine Regel kann entweder definieren, wie sich eine Aktivität in eine
Anzahl von untergeordneten Aktivitäten untergliedert oder wie
sich ein Dokument in eine Anzahl von untergeordneten Dokumenten
untergliedert. In jedem Fall werden Bedingungen verwendet, um Abhängigkeiten
zwischen Aktivitäten
und Dokumentzuständen
und zwischen Dokumentteilen und ihren dazugehörigen Aktivitäten zu spezifizieren.
-
Vorzugsweise
können
flexible oder weiche temporäre
Abhängigkeiten
auf mehrere Arten umgesetzt werden: über zufällige Abhängigkeiten zwischen Aktivitäten; über Auslöser, die
auf Dokumentzuständen
basieren; und über
informationelle Abhängigkeiten
zwischen Dokumentteilen. Ein Vorteil ist, dass Prozessdefinitionen
dadurch die festgelegte Gesamtreihenfolge zwischen Dokumentteilen
vermeiden, die durch herkömmliche
Workflow-Systeme vorgegeben wird.
-
Ein
weiterer Vorteil ist, dass die Erfindung die Darstellung von Aufgaben
und Dokumenten und die Abhängigkeitsarten
zwischen ihnen, die ausgedrückt werden
können,
erhöht.
Der Schlüssel
dazu ist die Verwendung von Bedingungen zum Beschreiben der komplexen
weichen Abhängigkeiten
der tatsächlichen
Arbeitspraxis. Tatsächlich
beschreibt eine Bedingung das Set von zulässigen Möglichkeiten, das auf nur eine
Wahlmöglichkeit
zusammenfällt,
wenn die Zeit für
die Aktion gekommen ist.
-
Weitere
Vorteile der erfindungsgemäßen Techniken
werden in Ref. 1 erläutert.
-
Im
Folgenden werden Ausführungsformen der
Erfindung als Beispiel unter Bezugnahme auf die folgenden begleitenden
Zeichnungen beschrieben:
-
1 zeigt
ein Netzwerkdokument-Verarbeitungssystem gemäß einer Ausführungsform
der Erfindung;
-
2 zeigt
(a) die Abhängigkeit
zwischen zwei Aktivitäten
und (b) die entsprechenden (zeit)variablen Zuweisungen gemäß herkömmlichen
Workflow-Systemen;
-
3 veranschaulicht
die Beziehung zwischen den Aktivitäten von 2, die jedoch
in Übereinstimmung
mit der vorliegenden Erfindung in Begriffen von Bedingungen ausgedrückt werden;
-
4 zeigt
die Kopplung von Aktivitätszuständen mit
Dokumentzuständen;
-
5 zeigt
ein Beispiel einer aktivitäts-(aufgaben-)
bezogenen Regel;
-
6 zeigt
ein Beispiel einer dokumentbezogenen Regel;
-
7 veranschaulicht
die Auswirkung des Ersetzens der ersten Bedingung in 6 durch
die Bedingung "body
triggers concl";
-
8 zeigt
ein Prozessgrammatiksegment, das in Übereinstimmung mit einer veranschaulichenden
Ausführungsform
der Erfindung zum Implementieren eines gemeinschaftlichen Mehrverfasser-Prozesses
verwendet wird;
-
9 zeigt (a) Aufgaben- und (b) Dokumentenbäume, die
dem Prozessgrammatiksegment von 8 entsprechen;
-
10 zeigt
zwei mögliche
Erweiterungen des sendToReferee-Unteraufgabenbaums von 9(a).;
-
11 veranschaulicht
die Abstimmung von Unteraufgaben der Aufgabe write mit den Unterdokumenten
des Dokuments paper;
-
12 zeigt
eine Dokumentansicht des Mehrverfasser-Prozesses von 8;
und
-
13 veranschaulicht
eine geeignete Benutzerschnittstelle, die beim Implementieren der
vorliegenden Erfindung verwendet werden kann.
-
Unter
Bezugnahme auf 1 wird ein Netzwerkdokument-Verarbeitungssystem
gemäß einer Ausführungsform
der Erfindung zum Implementieren der hierin beschriebenen Techniken
durch das Bezugszeichen 100 bezeichnet. Dieses System ist
dem Fachmann bekannt und eine ausführliche Beschreibung davon
wurde daher weggelassen. Hinsichtlich weiterer Informationen wird
der Leser auf EP-A-772,857 verwiesen, in dem das System unter Bezugnahme
auf dessen 1 beschrieben wird.
-
A. GPSG-Formalismus
-
In
diesem Abschnitt wird der GPSG-Formalismus, welcher der Erfindung
zu Grunde liegt, unter Bezugnahme auf einige einfache Beispiele
beschrieben.
-
Die
Unterschiede zwischen herkömmlichen Workflow-Systemen
mit einer Prozessbeschreibungssprache (PDL) und den Techniken der
vorliegenden Erfindung werden in Ref. 1 erläutert, insbesondere unter Bezugnahme
auf Tabelle 1.
-
Gemäß der GPSG-Näherungsweise,
die der vorliegenden Erfindung zu Grunde liegt, konstruiert der
Benutzer, wenn er eine Prozessvorlage defnieren möchte, eine
Prozessgrammatik, die das Lexikon der Prozessobjekte, (z. B. Aktivitäten, Dokumente,
Rollen), und die Regeln definiert, um sie zu kombinieren. Eine Prozessinstanz
ist jede gültige
Phrase, die während
Simulation oder Umsetzung aus der Prozessgrammatik generiert wird.
Tatsächlich
definiert eine Prozessgrammatikvorlage einen Prozessbereich, eine
potenziell unendliche Zahl von Prozessinstanzen. Demzufolge ist
die Flexibilität
von Arbeitsdarstellungen, die auf dem GPSG-Formalismus basieren,
viel größer, weil
der Entwickler die Bedingungen des Prozesses und die Regeln zum
Definieren dessen, was gestattet ist und was nicht, statt des exakten Ablaufs
(und der Alternativen) von Aktivitäten und Ereignissen definieren
kann. Die Flexibilität
der Prozessspezifikation ergibt sich aus der Negierung der Bedingungen
(alles, was nicht durch die Grammatikregeln ausgeschlossen ist,
ist möglich).
Im Gegensatz dazu wird in PDL-Rahmen eine Prozessinstanz gewählt, indem
aus bedingten Verzweigungsanweisungen ausgewählt wird.
-
Durch
Anwenden einer kartesischen Metapher auf das Konzept des Prozessbereichs
lassen sich die Regeln als die Achsen definierend und die Bedingungen
als die Kurve bestimmend vorstellen. Es gibt zwei Hauptkategorien
von Regeln: aktivitätsbezogene
Regeln und dokumentbezogene Regeln (obwohl dem Fachmann klar sein
wird, dass es viele weitere Regeltypen geben könnte, z. B. rollen- oder akteurbezogene
Regeln). Aktivitätsbezogene
Regeln beschreiben, wie und unter welchen Bedingungen Ziele (Aufgaben)
in untergeordnete Ziele (Unteraufgaben) aufgegliedert werden. Zum
Beispiel ließe
sich das Ziel, am Morgen zur Arbeit zu gehen, in Aufstehen, Waschen,
Essen und zur Arbeit fahren aufgliedern. Jedes dieser Ziele könnte des
Weiteren unter Verwendung von zusätzlichen Regeln aufgegliedert werden.
Abhängigkeiten
zwischen den Aktivitäten könnten zum
Beispiel sein, dass man nur isst, wenn man Hunger hat und nur bei
schlechtem Wetter fährt. In ähnlicher
Weise beschreiben die dokumentbezogenen Regeln, wie Dokumente in
untergeordnete Dokumente untergliedert werden. Eine lokale Zeitung setzt
sich zum Beispiel aus Nachrichten, Leitartikeln und Spalten zusammen,
die von entsprechenden Fotografien und Illustrationen begleitet
werden. Strukturelle Abhängigkeiten
können
das Hinzufügen
eines Leitartikels und einer Fotografie umfassen, um eine brandaktuelle
Geschichte zu begleiten, aber auch, dass ein anderer Artikel herausgenommen
wird, um die Gesamtzeilenzahl einzuhalten.
-
Sowohl
Aktivitäten
als auch Dokumente sind Merkmalsstrukturen, das heißt Objekte,
die durch ein Set von Merkmalen oder Attributwert-Paare beschrieben
werden, die im Folgenden ausführlicher
in Abschnitt A.2 beschrieben werden. Die Merkmalswerte können selbst
Merkmalsobjekte sein. Wechselseitige Abhängigkeiten zwischen Objekten
werden unter Verwendung von Merkmalsbedingungen beschrieben, die
im Folgenden in Abschnitt A.1 erläutert werden.
-
A.1 Bedingungen
-
Rechenbedingungen
sind Beziehungen zwischen Variablen mit zwei Eigenschaften: (1)
sie können
während
der Laufzeit gelöst
werden statt während
der Prozessdefinition; (2) sie gestatten es Variablen, einen Wertebereich
einzunehmen. Zum Beispiel wird bei herkömmli chen Workflow-Systemen
die Abhängigkeit
zwischen zwei Aktivitäten
A und B (2(a)) normalerweise mit der
Variablenzuweisung von 2(b) ausgedrückt, wobei
B. start der Zeitpunkt ist, zu dem Aktivität B beginnt, und A. end der
Zeitpunkt ist, wenn Aktivität
A endet. Die Variablenzuweisung wird immer in der gleichen Richtung berechnet
(B. start wird der Wert von A. end zugewiesen).
-
Wenn
Bedingungen verwendet werden, kann jedoch eine viel größere Flexibilität erreicht
werden, wie in 3 gezeigt. Die erste Bedingung
kann von links nach rechts oder von rechts nach links gelöst werden,
abhängig
davon, welche Variable zuerst instantiiert wird. In einem aufgabenangestoßenen (task-pushed)
Ausführungsmodus
wird A beendet, A. end wird instantiiert, sein Wert zu B. start
zugewiesen und dann beginnt B. Allerdings ist anzumerken, dass auf
Grund des ≥-Operators
(Bedingung 1 in 3) B sofort oder nach einiger
Verzögerung
beginnen kann. Wenn alternativ der Ausführungsmodus zielangestoßen (goal-pushed)
ist, kann B. end instantiiert werden, weil sich eine Frist abzeichnet
(Bedingungen 2 und 3 in 3); der Wert von B. start wird
zu A. end zugewiesen und A wird ausgeführt.
-
Somit
können
durch die Verwendung von Bedingungen Abhängigkeiten zwischen Aufgaben
und Dokumenten flexibler definiert werden. Herkömmliche Workflow-Systeme gestatten
keine zeitliche Überlappung
von Aufgaben. Stattdessen erzwingen diese entweder eine zeitlich
lineare Darstellung von Aufgaben, wobei eine Aufgabe erst dann beginnen kann,
wenn die vorherige endet, oder eine vollständig gleichzeitige Verarbeitung
von Aufgaben. Mit Bedingungen, wie sie in der vorliegenden Erfindung
verwendet werden, können
Begriffe wie beispielsweise "Arbeit
an dem Dokument kann jederzeit nach Beginn der Literatursuche starten" einfach codiert
werden.
-
In ähnlicher
Weise kann, anstatt zu sagen, dass der Leitartikel für eine Zeitung
von Daniele oder Remo bearbeitet werden muss, vorgegeben werden, dass
sie von irgendeinem der Autoren oder eventuell von jedem Autor,
aber nicht von Natalie, bearbeitet werden kann, außer an Dienstagen.
Diese Art von Bedingung gestattet es auch, dass die Person, welche
die Aufgabe ausführen
darf, implizit definiert wird, indem angegeben wird, wer nicht dafür zuständig sein
darf.
-
Derzeitige
Workflow-Systeme weisen einen starren Begriff von Aufgabenzuweisung
und zeitlicher Steuerung, Dokumentweiterleitung und Struktur auf, was
die Anpassungsfähigkeit
der Prozessdefinition an aktuelle Situationen und ad-hoc-Prozessänderungen
in hohem Maße
einschränkt.
Beim Vergleich ihrer Fähigkeiten
im Kontext von Bedingungen könnte man
sagen, dass diese nur eingeschränkte
Bedingungen verwenden, wie beispielsweise Gleichwertigkeit (eine
Aufgabe wird von einer bestimmten Person ausgeführt, oder von jemand aus einer
gewissen Gruppe von Leuten, nur zu einem bestimmten Zeitpunkt oder
nur, nachdem irgendeine andere Aufgabe beendet worden ist). Indem
andere Arten von Bedingungen hinzugefügt werden, wie beispielsweise
Ungleichheit (Startzeit jederzeit nach 10 Uhr) und Disjunktion (die
Aufgabe kann von jedem erledigt werden, der kein Manager ist), kann
die Ausdruckskraft einer Prozessdefinition in hohem Maße erhöht werden.
-
Allgemeiner
ausgedrückt
verwendet die der Erfindung zu Grunde liegende GPSG-Näherungsweise
ein erweitertes Set von Bedingungen, um flexibel zu spezifizieren,
wann und unter welchen Bedingungen die Prozessgrammatikregeln greifen
(oder nicht). Bedingungen können
die zeitliche Steuerung von Aktivitäten, die Ablaufplanung von
Ressourcen (Personen, Computer, Maschinen), die Struktur von Dokumenten
und Zugriffssteuerung auf Dokumente auf eine Weise steuern, mit
der Prozessabweichungen genauso wie erkannte Routineabläufe erfasst
werden.
-
A.2 Merkmale
-
Objektmerkmale
gestatten in Kombination mit Bedingungen, dass Regeln verwendet
werden, nicht nur um zu beschreiben, wie Aufgaben und Dokumente
sich in Unteraufgaben und untergeordnete Dokumente aufgliedern,
sondern auch, wie diese untergeordneten Teile in relativ lockeren
oder engen Netzen von wechselseitigen Abhängigkeiten miteinander verflochten
sind. Meistenteils ergibt sich die Semantik von Merkmalen aus dem
lokalen Kontext der Regel. Es ist jedoch überaus nützlich, über ein Set von Merkmalen zu
verfügen,
deren Definition objekt- und regelübergreifend konstant bleibt.
Insbesondere das Merkmal doc von Aktivitätsobjekten und das Merkmal
task von Dokumentobjekten nehmen eine zentrale Stellung für den Aufbau
der Dualität zwischen
aufgabenbasierten Regeln und dokumentbasierten Regeln ein. Diese
zwei zueinander in Beziehung stehenden Merkmale bauen eine Querverbindung
zwischen den Zustandsübergängen eines Dokuments
und den Zustands übergängen seines Aufgabendoppels
auf. 4 zeigt die zulässigen Übergänge zwischen einem Aktivitätszustand
zu einem anderen und zwischen einem Dokumentzustand zu einem anderen
und gibt auch (in lockerer Weise) an, wie ein Zustandsübergang
in einem von einem dualen Paar mit einem Zustandsübergang
in dem anderen des Paars gekoppelt wird. (Die Querverbindung wird
komplexer, wenn ein Dokument mit mehr als einer Aufgabe oder eine
Aufgabe mit mehr als einem Dokument gepaart ist.)
-
Insbesondere
ist das Merkmal doc einer Aktivität ein Adressenverweis auf das
Dokument, das mit der Aufgabe verknüpft ist. Wenn die Aufgabe aktiviert
wird, wird das Dokument erstellt, wenn es nicht bereits vorhanden
ist. In ähnlicher
Weise ist das Merkmal task eines Dokuments ein Adressenverweis auf
die mit dem Dokument verknüpfte
Aktivität.
Nach der Erstellung des Dokuments wird die Aufgabe aktiviert, wenn
sie nicht bereits aktiviert oder aktiv ist. Nach der Freigabe einer
neuen Version des Dokuments wird die Aktivität erneut aktiviert, wenn sie nicht
bereits aktiviert oder aktiv ist. Ein wichtiger Nebeneffekt der
Dualität
zwischen Aktivitäts-
im Vergleich mit Dokumentregeln ist, dass ein gemeinschaftlicher
Prozess so betrachtet werden kann, dass er entweder durch das Bereithalten
einer Aufgabe der obersten Ebene oder durch die Erstellung eines
Dokuments der obersten Ebene initiiert wird. Somit kann der GPSG-Rahmen
sowohl aktivitätsausgelöste Prozesse
als auch dokumentausgelöste
Prozesse modellieren. Das Prozessbeispiel im folgenden Abschnitt
B hebt insbesondere die Dualität
von aufgabenbasierten und dokumentbasierten Regeln hervor.
-
Sowohl
Aktivitätsobjekte
als auch Dokumentobjekte besitzen ein intern geführtes Merkmal state, das auf
eine Zeitaufzeichnung von Zustandsänderungen des Objekts verweist.
Andere vordefinierte Merkmale von Aktivitäten sind: role (Rolle), die
Gruppe von Benutzern, die in der Lage sind, die Aufgabe auszuführen; duration
(Dauer), die geschätzte
Dauer der Aufgabe; begin (Start), das Startdatum der Aufgabe, und
end (Ende), das Enddatum der Aufgabe. Zu den vordefinierten Merkmalen
von Dokumenten gehören:
version (Version), eine Zeitaufzeichnung von inkrementellen Versionen
des Dokuments; group (Gruppe), die Personen, die berechtigt sind,
das Dokument zu erstellen/zu modifizieren; length (Länge), die
Länge des
Dokuments (z. B. in Bytes oder Seiten); parent (übergeordnet), ein Adressenverweis
auf das übergeordnete
Dokument, und contents (Inhalt), ein Adressenverweis auf den physikalischen
Inhalt des Dokuments.
-
Andere
Merkmale von Aufgaben und Dokumenten sind implizit innerhalb des
lokalen Kontexts einer Regel definiert, um in Kombination mit Bedingungen
hierarchische Verzweigungen, Iteration und bedingte Regeln zu gestatten,
von denen Beispiele in Abschnitt B angegeben werden, und um Fristen,
Seitenbegrenzungen und Rollenzuweisungen zu erzwingen, wie im Folgenden
in Abschnitt A.3 erläutert.
-
A.3 Beispiel-Grammatikregeln
-
Die
folgenden Beispiel-Grammatikregeln werden verwendet, um Möglichkeiten
aufzuzeigen, mit denen elementare, fundamentale wechselseitige Abhängigkeiten
von Aktivität
und Dokument unter Verwendung von Prozessgrammatikregeln dargestellt
werden können.
-
A.3.1 Aktivitätsbezogene
Regeln: temporäre
Abhängigkeiten
-
5 veranschaulicht
ein Beispiel einer aktivitätsbezogenen
Regel, (für
die Regel lokale Variablen werden durch einen Großbuchstaben
am Anfang gekennzeichnet), die verwendet wird, um zu zeigen, wie
(a) Aufgaben-Gleichzeitigkeit; (b) Aufgaben-Sequenzialisierung;
(c) Aufgaben-Überlappung;
und (d) Erzwingen von Fristen dargestellt werden. Der Hauptteil
der Regel stellt sicher, dass das Aufgabenziel (goal) (der Kopf
der Regel) aus der Ausführung von
task1 und task2 (dem Ende der Regel) besteht. Der Kopf muss aus
exakt einer Aufgabe bestehen, während
das Ende beliebig viele Unteraufgaben enthalten kann. Des Weiteren
gibt es keine implizite zeitliche Reihenfolge; task1 und task2 laufen
a priori gleichzeitig. Die Merkmale beschreiben des Weiteren die
Komponentenaufgaben und können
verwendet werden, um Werte von einer Aufgabe an eine andere zu übergeben,
ebenso von einer Regel an eine andere, und um das sich Entfalten
der Aufgaben zu erzwingen.
-
Das
Symbol "::" trennt den Hauptteil
der Regel von (den willkürlich
vielen) Bedingungen der Regel. Die zwei Bedingungen in der Vorlage
begrenzen, wie und unter welchen Voraussetzungen die Regel arbeiten
darf. Die erste erzwingt, dass task1 beendet wird, bevor task2 starten
darf. Alternativ könnten
wir diese Bedingungen durch "task1
triggers task2" ersetzen,
was task2 in lockerer Weise gestattet, jederzeit zu beginnen, nachdem
task1 begonnen hat. Die zweite Bedingung erzwingt eine Frist, und
zwar direkt auf goal und implizit auf den Komponentenunteraufgaben
(auf Befehl müssen
Unteraufgaben beginnen, nach dem ihre übergeordnete Aufgabe beginnt,
und enden, bevor ihre übergeordnete
Aufgabe endet).
-
A.3.2 Dokumentbezogene
Regel: strukturelle Abhängigkeiten
-
6 zeigt
ein Beispiel für
eine dokumentbezogene Regel, die oberflächlich betrachtet einer aktivitätsbezogenen
Regel sehr ähnlich
zu sein scheint, weil der semantische Unterschied in ihrer Interpretation
verborgen ist. Die Ähnlichkeiten
betonen die duale Natur von aufgabenbasierten und dokumentbasierten
Regeln. Dieses Beispiel wird verwendet, um zu veranschaulichen,
wie (a) Dokumentuntergliederung; (b) Dokumentauslösung von
Aufgaben; (c) Dokumentversionserstellung (document versioning);
und (d) Erzwingen von Seitenbegrenzungen ausgedrückt werden.
-
Der
Hauptteil dieser Regel stellt sicher, dass das Dokument paper sich
in drei Teile untergliedert: intro (eine Einleitung), body (einen
Hauptteil) und conclusion (einen Schluss). Wiederum besteht der Kopf
aus exakt einem Dokumentobjekt und das Ende aus beliebig vielen
untergeordneten Dokumenten. Während
sich aktivitätsbezogene
Regeln jedoch auf Aufgaben und temporäre Abhängigkeiten konzentrieren, konzentrieren
sich dokumentbasierte Regeln auf Daten und strukturelle Abhängigkeiten.
-
Standardmäßig kann
auf alle untergeordneten Dokumente gleichzeitig zugegriffen werden.
In diesem Beispiel erzwingt die erste Bedingung jedoch, dass eine
endgültige
Version des body abgeschlossen wird, bevor die conclusion erstellt
werden kann. Die Bedingung "precedes" führt zu der
strikten Sequenzialisierung der dualen Aufgaben der zwei Dokumente:
der Abschluss des body des untergeordneten Dokuments, (d. h. die
duale Aufgabe wrBody wird beendet), führt zur Erstellung des untergeordneten
Dokuments conclusion, (wodurch wiederum die duale Aufgabe wrConcl
aktiviert wird, die dann jederzeit aktiv werden kann). Die zweite
Bedingung erzwingt eine physikalische Begrenzung hinsichtlich der
Gesamtlänge
des Dokuments.
-
Wenn
alternativ gewünscht
wird, an dem Hauptteil zu arbeiten und parallel dazu, jedoch in
koordinierter Weise, mit dem Abschluss fortzufahren, könnten wir
die erste Bedingung in 6 durch "body triggers concl" ersetzen. Eine solche Bedingung gestattet
es, die Arbeit am untergeordneten Dokument conclusion zu starten,
wann immer die Arbeit am body des untergeordneten Dokuments begonnen hat,
und sie definiert auch, wie die zwei Leistungen koordiniert werden:
immer, wenn eine neue Version des body von seinen "Eigentümern" "freigegeben" wird, steht sie den Eigentümern der
conclusion zur Verfügung,
wie in 7 veranschaulicht.
-
Dies
wiederum wirkt sich auf wrConcl aus, die zum untergeordneten Dokument
conclusion duale Aufgabe: wenn die Aufgabe inaktiv oder anstehend ist,
wird sie jetzt aktiviert. Durch diesen Mechanismus können Änderungen
in Dokumenten zur erneuten Aktivierung von langlebigen Aktivitäten führen. Man geht
davon aus, dass kein bestehendes Workflow-System in der Lage ist, langlebige Aufgaben
darzustellen, die auf Dokumentzuständen basierend erneut erwachen.
-
B. Beispiel-Prozessgrammatik:
Mehrverfasser-Erstellung
-
Unter
Bezugnahme auf 8 wird zur weiteren Veranschaulichung
der Verwendung von Regeln und Merkmalsbedingungen für Modellierprozesse
ein Segment einer Prozessgrammatik für die gemeinschaftliche Mehrverfasser-Erstellung
eines Forschungsdokuments vorgestellt. Der Mehrverfasser-Prozess
veranschaulicht die vielen Koordinierungsprobleme eines Prozesses,
an dem mehrere Akteure (mit mehreren Rollen) beteiligt sind, die
sich ein komplexes strukturiertes Dokument teilen.
-
Für den Mehrverfasser-Prozess
gibt es viele mögliche
alternative Szenarios. Das in diesem Abschnitt modellierte Szenario
beschreibt das gemeinschaftliche Schreiben eines Forschungspapiers
gefolgt von der Vorlage bei einem Sachverständigen und der Veröffentlichung
im Fall der Annahme. Die Schreibphase selbst ist grob in die Durchführung von Nachforschungen,
Implementierung, Analyse und Schreiben aufgegliedert. (Somit ist
das Schreiben eines Forschungspapiers als eng mit der größeren Forschungs-Terminplanung
verflochten einzustufen.) Das Forschungspapier als Dokument wird
als ein komplexes strukturiertes Dokument modelliert, das grob in
wechselseitig voneinander abhängige
Abschnitte unterteilt werden kann: es weist sowohl untergliederbare
als auch nicht-untergliederbare Merkmale auf. Einige Abschnitte
des Papiers werden mehrere Verfasser und/oder mehrere Abhängigkeiten
von anderen Abschnitten und Aufgaben aufweisen. Mit der Zeit wird
das Papier hinsichtlich der mit ihm verknüpften Aktivitäten mehr
oder weniger untergliederbar.
-
Die
Hauptrollen sind: Verfasser, Berater, Redakteur, Sachverständiger,
Lektor und Herausgeber. Ein Akteur kann mehrere Rollen (und potenziell
alle von ihnen) haben. Verfasser schreiben das Papier und stellen
Nachforschungen dazu an, Berater stehen beratend zur Seite. Redakteure
lesen Korrektur und kommentieren. Sachverständige prüfen und beurteilen Papiere.
Lektoren koordinierten Rezensionen von einzelnen Sachverständigen.
Herausgeber veröffentlichen
Papiere, die als veröffentlichungswürdig beurteilt
werden.
-
Mit
den Grammatikregeln sind mehrere globale Variablen verknüpft:
- (1) die Rollen-Sets: Verfasser; Berater; Redakteur;
Sachverständiger;
Herausgeber.
- (2) Fristen: Fristen für
Vorlage, Sachverständigenurteil, Überarbeitung
und Veröffentlichung.
- (3) Länge:
Seitenbegrenzung für
das Dokument
-
Aus
Gründen
der Prägnanz
ist nicht beabsichtigt, eine vollständige Beschreibung dieses Prozesses
und seiner Verschlüsselung
zu geben, stattdessen wird das Ziel angestrebt, zu zeigen, dass
es in Übereinstimmung
mit der vorliegenden Erfindung möglich
ist, die dran beteiligten komplexen Koordinierungsprobleme in einer
flexiblen Weise über
Prozessgrammatiken zu codieren.
-
In 8 zeigt
Regel 1, wie die Aufgabe paper in die Komponentenunteraufgaben write, edit/proof
und sendToReferee aufgegliedert wird; und die Bedingungen sind (1),
dass write und edit/proof vor sendToReferee ausgeführt werden
und (2), dass der Zeit-Merkmalswert End für jede der Unteraufgaben auf
dem Zeit-Merkmalswert deadline der dritten Unteraufgabe sendToReferee
oder davor liegt.
-
B.1 Hierarchische Untergliederung
-
Regelsequenzen
werden verwendet, um die Mehrverfasser-Prozesse in Aufgaben und
Unteraufgaben sowie Dokumente und untergeordnete Dokumente hierarchisch
aufzugliedern.
-
9(a) zeigt einen möglichen Aufgabenbaum und 9(b) seinen komplementären Dokumentbaum für die Mehrverfasser-Grammatik.
-
Die
Modularität
einer regelbasierten Näherungsweise
macht es einfach, untergeordnete Prozesse und untergeordnete Dokumente
neu zu definieren. Das Ersetzen einer Regel, die einen untergeordneten
Prozess definiert, ist wie das Ersetzen einer Verzweigung des Aufgaben-
oder Dokumentbaums in 8. Durch das
Hinzufügen
einer Regel kommt eine neue Verzweigung hinzu; durch das Entfernen einer
Regel wird eine Verzweigung abgeschnitten.
-
B.2 Bedingte Verzweigung
-
Regel-Sets
können
auch verwendet werden, um alternative untergeordnete Prozesse oder
untergeordnete Dokumente zu beschreiben. 10 zeigt zwei
mögliche
Erweiterungen des Unteraufgaben-Baums sendToReferee in 9(a), abhängig davon,
ob der Sachverständige
das Papier akzeptiert oder ablehnt.
-
Unter
Verwendung einer regelbasierten Näherungsweise ist es einfach,
Alternativen hinzuzufügen
oder zu entfernen, indem eine neue Regel eingegeben oder eine alte
gelöscht
wird. Es ist fernen wichtig, anzumerken, dass, während das hier angegebene Beispiel
rein deterministisch ist, es offenkundig ist, dass auch nicht-deterministisch
zwischen mehreren Möglichkeiten
verzweigt werden kann. Die Weiterentwicklung der Aufgaben- und Dokumentbäume hätte dann
eine zufällige
Komponente.
-
B.3 Verflochtene Aktivitäts- und
Dokument-Regeln
-
Koordinierungsverfahren
und Dokumentstruktur und Steuerung hängen in hohem Maße wechselseitig
voneinander ab; das heißt,
der Typ von Koordinierungsstrategien, die sachdienlich sind, hängt von
der Struktur des Dokuments und der für den Steuerungszugriff verfügbaren Technologie
ab. Diese Verbindung kann in Posner und Beckers (How people write
together. In Proc. of the 25th Hawaii Int. Conf. On System Sciences,
Hawaii, 1992) Kategorisierung von gemeinschaftlichen Schreibprojekten
in vier Dimensionen beobachtet werden: Rollen, Aktivitäten, Dokumentsteuerungsverfahren
und Schreibstrategien. Insbesondere können wir uns dokumentbezogene
Prozesse so vorstellen, dass sie zu einer von zwei strukturellen
Kategorien gehören:
untergliederbare Dokumentprozesse und nicht-untergliederbare Prozesse,
obwohl sich der Prozess am besten als eine sich dynamisch weiterentwickelnde Kombination
aus beiden ausdrücken
lässt.
Im ersten Fall werden die Prozessaufgaben eins zu eins zu den unabhängigen Abschnitten
eines untergliederbaren Dokuments zugeordnet. Ein Beispiel für einen
solchen Prozess kann das Schreiben eines Buchs in dem Fall sein,
in dem es in fast unabhängige
Abschnitte aufgeteilt werden kann, wie Einleitung, Kapitel und Schluss.
Als Ergebnis dessen kann die Koordinierung von Aktivitäten zum
Untergliedern von Dokumentprozessen sehr geradlinig verlaufen: jede
Aktivität
ist mit einem Teil des Dokuments verknüpft. In dem zweiten Fall von
nicht-untergliederbaren Prozessen liegt eine Zuordnung von Dokumenten
zu Aufgaben und Aufgaben zu Dokumenten von vielen zu eins vor. Ein
Beispiel hierfür
ist das Brainstorming, Verfassen, Bearbeiten und Genehmigen eines
Vorschlags, bei dem alle Schritte des Prozesses auf das gleiche
physikalische Dokument einwirken. Es gibt zwei verschiedene Koordinierungslösungen für Prozesse,
für die
das gemeinsame Nutzen eines nicht-untergliederbaren Dokuments erforderlich
ist: (1) sequenzielle Aktivitäten,
wobei jeder Akteur an einer geschlossenen Version des gemeinsamen
Dokuments arbeitet; und (2) gleichzeitige Aktivitäten, bei denen
die Arbeit von Akteuren an einer eingefrorenen Version später zusammengeführt wird.
-
Da
der gemeinschaftliche Schreibprozess von 8 in hohem
Maße dokumentgeführt ist,
sind die Aktivitäten
und Dokumente, die an einem solchen Prozess beteiligt sind, wechselseitig
stark voneinander abhängig.
Tatsächlich
gibt es in dem Prozesssegment von 8 viele
Paare von komplementären Aktivitäts-/Dokument-Regeln,
die über
duale Aktivitäten
und Dokumente verbunden sind. Es ist zu beachten, dass Aktivitäten und
Dokumente einander nicht eins zu eins, also eine Aktivität einem
Dokumentteil, entsprechen müssen.
-
Betrachten
wir das Paar der Regeln 3 und 4 in 8, die über die
Aktivität
write und das Dokument paper verbunden sind. Regel 4, eine dokumentbasierte
Regel, gibt explizit die Struktur des Mehrverfasser-Dokuments paper
an. Das untergeordnete Dokument sections selbst erfordert eine zusätzliche Regel,
ebenso wie die Aufgabe research (nicht enthalten). Regel 3 ist eine
aktivitätsbasierte
Regel, welche die Aufgabe write in mehrere Unteraufgaben aufgliedert,
deren Ziele grob den Abschnitten des geschriebenen Dokuments selbst
entsprechen, wie in 11 veranschaulicht.
-
Aus
dem Regel-Set könnten
entweder Regel 1 oder Regel 2 als die übergeordneten Regeln betrachtet
werden, da jede Aktivität
bzw. jedes Dokument erhalten werden kann, indem eines von beiden als
ein Ausgangspunkt verwendet wird. Allerdings können die Regeln 3 und 4 auch
so brachtet werden, dass sie ein Set von untergeordneten Prozessen
definieren, das für
sich alleine stehen kann (Papier schreiben, Nachforschung unterlassen,
Bearbeitung und Veröffentlichung).
[Parallele Prozesse ergeben sich, wenn mehrere Regeln unabhängig voneinander greifen.
Zum Beispiel können
viele laufende Nachforschungsprojekte innerhalb einer Gruppe vorhanden sein.]
Auf diese Weise ist es möglich,
die Erstellung von Strömen
von Dokumenten und Aktivitäten
auszulösen,
die sich auf das Schreiben des Papiers beziehen, indem entweder
die Dokumentregel für
paper oder die Aktivitätsregel
für write
greift. Zum Beispiel wird das Dokument des paper erstellt, indem
zuerst Regel 4 ausgelöst
wird. Da write das Aktivitätsdoppel zu
paper ist, wird es unter Auslösung
von Regel 3 anschließend
aktiviert. Alternativ könnte
die gleiche Ereigniskette von der Aktivitätsseite aus initiiert werden,
indem zuerst Regel 3 ausgelöst
wird.
-
B.4 Dokumentprozesse
-
Unter
Ausnutzung des Zusammenspiels zwischen Dokument- und Aktivitätsregeln
ist es möglich, sowohl
untergliederbare als auch nicht-untergliederbare Dokumentprozesse
einfach zu modellieren, deren Merkmale oben zusammengefasst wurden,
und die beiden dynamisch zu mischen. Um es kurz zu wiederholen,
untergliederbare Prozesse gestatten grob gesagt einen gleichzeitigen
Ablauf von Aktivitäten,
die mit Dokumentteilen verknüpft
sind, während nicht-untergliederbare
entweder einen sequenziellen Ablauf von Aktivitäten oder in hohem Maße koordinierte
parallele Abläufe
von Aktivitäten
erfordern.
-
Die
Untergliederbarkeit oder Nicht-Untergliederbarkeit eines Dokumentprozesses
ist innerhalb des Kontexts der Aktivitäten definiert, die auf das
Dokument und seine Teile einwirken. Insbesondere kann sich die Untergliederbarkeit
eines Dokuments mit der Zeit ändern,
indem sie sich von einem Ende des Spektrums auf das andere und wieder
zurück verlagert.
Während
zum Beispiel das Dokument des paper hier in Bezug auf die Aktivitäten des
Schreibens der Einleitung, der Hauptabschnitte und des Schlusses
(Regel 4) als untergliederbar betrachtet wird, wird es weder hinsichtlich
des refereeing und revising (Regel 8) noch in Bezug auf writing
und editing/proofreading (Regel 2) als untergliederbar betrachtet. 12 hebt
die Dokumentenansicht des hier betrachteten Mehrverfasser-Prozesses
hervor, wobei die dynamischen Verlagerungen in der Untergliederbarkeit
betont werden. Im Folgenden werden die untergliederbaren und nicht-untergliederbaren Aspekte
dieses vereinfachten Prozesses ausführlicher beschrieben.
-
B.4.1 Untergliederbare
Prozesse: paralleler Aktivitätenablauf
-
Regel
4 in 8 gibt ein Beispiel dafür, wie die untergliederbaren
Aspekte eines Dokumentprozesses zu handhaben sind. Hier wurde ein
paper als ein in drei Teile untergliederbares Dokument modelliert:
eine introduction, mehrere sections und eine conclusion. Das Fehlen
von strukturellen Bedingungen (wie beispielsweise precedes oder
triggers) gibt an, dass es sich bei diesen um unabhängige untergeordnete
Dokumente handelt, und dass in Abwesenheit von zeitlichen Bedingungen
(siehe Regel 3) für ihre
dualen Aufgaben die Arbeit an jedem von diesen parallel fortgeführt werden
kann. In diesem Szenario entwickeln sich die Versionsströme der getrennten untergeordneten
Dokumente unabhängig.
Alternativ kann es auch wünschenswert
sein, strukturelle Bedingungen aufzunehmen, um tatsächliche
wechselseitige Abhängigkeiten
darzustellen. Beispielweise kann es sein, dass Änderungen an der conclusion
in der introduction berücksichtigt
werden müssen,
und das Papier wäre
während
der Schreibphase nicht mehr vollkommen untergliederbar.
-
B.4.2 Nicht-untergliederbare
Prozesse: sequenzieller Aktivitätsablauf
-
Regel
8 zeigt, wie ein nicht-untergliederbarer Dokumentprozess durch strikte
Sequenzialisierung von Aktivitäten
gehandhabt werden kann, die von dem gleichen Dokument abhängen, indem
eine lokale Bedingung in der Form von doc1 geht doc2 voraus verwendet
wird. Diese Dokumentregel beschreibt die Struktur der endgültigen Version,
die zur Veröffentlichung
vorgelegt wird: die comments des Sachverständigen sind in das übergeordnete
Dokument des paperals revisions eingearbeitet, um das revisedPaper
zu erzeugen. Die lokale Bedingung precedes erzwingt, dass die Autoren
erst dann mit dem Überarbeiten
des Papiers beginnen können,
wenn sie die Bemerkungen des Sachverständigen erhalten haben, wodurch
eine strikte Sequenzialisierung von Aktivitäten erzwungen wird, die auf
das gleiche nicht-untergliederbare übergeordnete Dokumentobjekt
paper einwirken. Sowohl der Sachverständige als auch die Autoren
modifizieren Kopien des gleichen Dokuments in einer streng koordinierten
Abfolge.
-
B.4.3 Nicht-untergliederbare
Prozesse: koordinierter paralleler Aktivitätsablauf
-
Regel
2 gibt an, dass das Dokument des paper auch in Bezug auf die Aktivitäten writing
und editing/proofreading nicht untergliederbar ist. Diese Regel
koordiniert gleichzeitiges Verfassen und Lektorieren durch die zwei
Bedingungen triggers: neue Versionen des write-Stroms des paper
werden den Akteuren zur Verfügung
gestellt, die für
den edit/proof-Strom von edits zuständig sind und umgekehrt.
-
5. Simulationsumgebung
und Benutzerschnittstellen-(UI) Aspekte
-
In Übereinstimmung
mit einer bevorzugten Ausführungsform
der Erfindung ist zur Unterstützung des
GPSG-Formalismus eine Benutzerschnittstelle 2 vorgesehen,
wie in 13 gezeigt, die den Modellierer
beim Untersuchen des Prozessbereichs führt, der durch eine vorgegebene
Grammatik definiert ist. Es ist ersichtlich, dass (unabhängig voneinander)
vier Fenster 4, 6, 8, 10 angezeigt
werden können,
wobei die Fenster mehrere Ansichten des Prozesses zeigen.
-
Das
Fenster 4 oben rechts stellt eine Aufgabenansicht dar,
welche die hierarchische Untergliederung von Aufgaben in Unteraufgaben
zeigt, die derjenigen in 9(a) ähnlich ist.
Neben den herkömmlichen
Schaltflächen 12 zeigt
das Fenster 4 eine Baumstruktur für die zur Diskussion stehende Aufgabe.
Es ist klar, dass die dort angezeigte Aufgabe den gesamten zur Diskussion
stehenden Prozess umfassen oder nur ein Teil davon sein kann. In
dem veranschaulichten Fall ist ersichtlich, dass die Aufgabe mr
(monatlicher Bericht) in die Unteraufgaben remind, writeMR und approve
untergliedert ist, die Unteraufgabe writeMR in die Unteraufgaben
writeCT, writeMLTT und merge untergliedert ist und so weiter.
-
Die
zweite Ansicht, die im Fenster 6 rechts unten dargestellt
ist, ist eine Zeitansicht, welche die temporären Abhängigkeiten zwischen Aufgaben zeigt.
In diesem Fall stehen die (auf unterster Ebene befindlichen) Unteraufgaben – writeCT,
writeMLTT, merge und doApprove – an
diskreten Punkten auf der vertikalen Achse, wobei die Zeit (auf
einer geeigneten Skala nach Wahl des Benutzers, z. B. Wochen) auf
der horizontalen Achse angegeben ist. Die Blöcke 62–70 stellen
die Dauern der Unteraufgaben dar. Indem mit dem Zeiger 72,
(der durch eine nicht gezeigte herkömmliche Maus betrieben wird),
die vertikale Linie 74 gewählt wird, (die den Endpunkt
von Aufgabe/Prozess mr) definiert), können verschiedene Szenarios
untersucht werden. In diesem Fall ist ersichtlich, dass der Endpunkt
von Woche 11 auf Woche 10 verschoben worden ist. Die Prozessgrammatik
wird dementsprechend modifiziert, um die auf diese Weise durch den
Benutzer eingegebene Änderung
der Frist wiederzugeben.
-
Im
Fenster 8 unten links ist eine Rollenansicht dargestellt,
die eine Lösung
für die
Einplanung von Personen für
Aufgaben anzeigt. Die Zeit (z. B. Wochen) ist auf der horizontalen
Achse angegeben. Die an der Aufgabe/dem Prozess beteiligten Mitarbeiter
(Ressourcen) werden an diskreten Punkten auf der vertikalen Achse
angezeigt, und der horizontale Balken gegenüber jeder Ressource gibt an,
ob sich die Ressource im Einsatz befindet, wann sie sich im Einsatz
befindet und in welchem Ausmaß.
Der Letztere ist farbig angezeigt, und ein Farbenschlüssel 84 wird
im Fenster 8 bereitgestellt, wobei das Ausmaß des Einsatzes
durch die folgenden Prozentsätze
angegeben wird: 0%, weiß;
25%, rosa; 50%, gelb; 75%, orange; 100%, rot und überbeansprucht, lila.
Es ist klar, dass andere Werte oder Skalen verwendet werden können. In
der gezeigten Tabelle sind die Zonen R rot, wodurch ein Einsatz
von 100% angegeben wird, während
die Zone P lila ist, wodurch eine Überbeanspruchung angegeben
wird. Der Benutzer kann daher problemlos erkennen, dass der Effekt
der Verlagerung des Endpunkts 74 im Fenster 6 von
Woche 11 auf Woche 10 darin besteht, dass der Manager während der
fünften
Woche überarbeitet sein
wird.
-
Der
Benutzer kann sich dann dafür
entscheiden, ein Szenario zu untersuchen, um dies zu korrigieren: über die
Eingabefelder 84 kann der Benutzer die Menge der verfügbaren Ressourcen ändern. Zum Beispiel
kann die Anzahl der Manager oder die Anzahl der Assistenten von
1 auf 2 geändert
werden, (entsprechend den Vorkehrungen, die für zusätzliche temporäre Mitarbeiter
oder Ähnliches
getroffen werden). Die Prozessgrammatik wird dementsprechend modifiziert,
um die auf diese Weise durch den Benutzer eingegebenen Änderungen
der Ressourcen wiederzugeben.
-
Schließlich stellt
das Fenster 10 einen textbasierten Grammatikeditor zum
Eingeben der Prozessgrammatik dar, die oben ausführlich erläutert wurde. In einer Hinsicht
kann die GPSG-Grammatik selbst, die den Simulationsprozess führt, als
ein Set von Bedingungen betrachtet werden, die hinzugefügt, entfernt,
modifiziert werden können.
Der Benutzer kann in einer Simulation interagieren, nämlich über diese "Prozessvorlagen"-Ansicht, die den
aktuellen Zustand der Simulation anzeigt.
-
Die
in den Fenstern 4–10 gezeigten
Ansichten sind interaktiv: Änderungen,
die vom Benutzer in einer Ansicht vorgenommen werden, werden auf
die anderen propagiert. Im Kontext des Mehrverfasser-Beispiels des
vorherigen Abschnitt könnte
der Benutzer zum Beispiel die verschiedenen Prozessalternativen
untersuchen, (z.B. Papier akzeptiert/abgelehnt), Aktivitäten zeitlich
vorverlagern oder zurückstellen,
Fristen für
das Papier und Seitenbegrenzungen ändern, die Anzahl der Autoren
oder Redakteure erhöhen/reduzieren,
Abhängigkeiten
zwischen verschiedenen Abschnitten des Papiers hinzufügen/entfernen
und so weiter. Während
der ganzen Zeit stellt der Simulator sicher, dass diese Änderungen
innerhalb des Prozessbereichs liegen, der durch die Regeln und die
Bedingungen der Mehrverfasser-Prozessgrammatik geschaffen worden
ist. Wenn zum Beispiel die Anzahl der Autoren im Vergleich mit der geschätzten Dauer
der Aktivitäten
zum Beenden des Schreibens des Papiers bis zum Fristablauf zu klein ist,
wird der Simulator den Benutzer warnen.
-
Das
oben genannte Beispiel wurde auf der Basis von vorhandenen aufgabenbasierten
Regeln beschrieben. Dem Fachmann ist jedoch klar, dass die Erfindung
in ähnlicher
Weise so implementiert werden kann, dass sowohl dokumentbasierte
als auch aufgabenbasierte Regeln erkannt werden.
-
Die
Simulations- und Ausführungsumgebung unterscheidet
sich sehr von derjenigen von herkömmlichen Workflow-Systemen:
das Simulationswerkzeug ist dazu gedacht, es Benutzern zu ermöglichen,
verschiedene Prozesspläne
zu untersuchen. (d. h. verschiedene gültige Phrasen der Grammatik) und
sie auszuwerten. Sobald der Benutzer einen Plan gewählt hat,
löst der
Bedingungslöser
(constraint solver) das Bedingungs-Set auf, um einen vorläufigen Ablaufplan
zu generieren, und gibt dann an den Benutzer zurück, um eine weitere Untersuchung des
Bereichs zu gestatten. Der Benutzer kann dann das System anweisen,
eine ausführbare
Prozessspezifikation zu erstellen (analog zu der Prozessinstanz
eines her kömmlichen
Workflow-Systems). Wenn der Benutzer während der Ausführung das
Prozessmodell ändern
muss, kann er zur Simulationsumgebung zurückkehren. Das Simulationswerkzeug
berücksichtigt,
was bereits ausgeführt
worden ist und nicht mehr rückgängig gemacht
werden kann, und gestattet dem Benutzer, den Prozessbereich von
diesem Punkt an zu untersuchen. Der neu definierte Plan kann dann
wieder ausgeführt
werden.
-
Von
der Ausführungsseite
her wird für
all dies eine geeignete Workflow-Maschine vorausgesetzt, die unter
anderem die Fähigkeiten
besitzt, Überlappen,
langlebige Aufgaben sowie Dokument-Versionserstellung und Steuerung
zu unterstützen.
Um die Ausdrucksfähigkeit
der GPSG-Näherungsweise
tatsächlich
voll ausnutzen zu können,
wird entsprechend eine Workflow-Maschine der nächsten Generation verwendet,
wie beispielsweise diejenige, die auf dem CLF (Co-ordination Language
Facility) aufgebaut ist, einer Entwicklungsumgebung für die Koordinierung
von verteilten Objekten, (siehe Andreoli, J.-M., Freeman, S. und
Pareschi, R., The co-ordination Language Facility: co-ordination
of distributed objects, Theory and Practice of Object Systems 2,2 (1966)).
-
14 ist
ein Ablaufdiagramm der Verfahren in Übereinstimmung mit der Erfindung
für die
Simulation/Umsetzung von Arbeitsprozessen.
-
Die
GPSG-Grammatik spezifiziert (Schritt s1) einen Prozessraum, der
aus einem potenziell unendlichen Set von Prozessinstanzen besteht,
(die Sätze
werden von der Grammatik erkannt), und eine Simulation kann als
eine Untersuchung dieses Bereichs betrachtet werden. Der aktuelle
Zustand der Simulation, der als ein Teilsatz betrachtet werden kann,
(der nicht-terminale
Symbole enthält),
kann jederzeit über
die mehreren Ansichten von 13 angezeigt
werden.
-
Der
Benutzer kann mit dem System über
diese Ansichten interagieren, indem er zum Beispiel Bedingungen
hinzufügt
(Schritt s4), um die Start- und Endzeiten einer Aufgabe weiter einzuschränken (oder
zuzuweisen) oder um die Anzahl der an einem bestimmten Punkt verfügbaren Ressourcen
zu binden (Schritt s6) oder ein Merkmal zuzuweisen.
-
Die
Aktion des Hinzufügens
einer Bedingung kann eine Navigation (Schritt s2) in dem Prozessbereich
auslösen.
Wenn es nach einer Aktion möglich wird,
ein untergeordnetes Ziel, das vorher nicht erweitert war, auf eine
einzige Weise zu erweitern, dann wird dieses untergeordnete Ziel
typischerweise erweitert, was zu einem neuen Syntaxbaum führt, d. h.
einem neuen (kleineren) untergeordneten Set des Prozessbereichs.
Wenn letztendlich alle untergeordneten Ziele erweitert worden sind,
wird ein einziger Prozess erhalten und die Simulation endet.
-
Damit
die Navigation in dem Prozessbereich jedoch flexibel bleibt, muss
sie nicht-monoton sein, und der Benutzer muss die Möglichkeit
haben, einige seiner Aktionen "rückgängig zu
machen", d. h. Bedingungen
zu entfernen. Der einfache Weg, dies zu erreichen, besteht aus der
chronologischen Zurückverfolgung:
bei jeder Benutzer-Aktion wird ein Bild des aktuellen Zustands des
Systems direkt vor der Aktion gespeichert und wird wiederhergestellt,
wenn der Benutzer diese Aktion rückgängig macht.
Obwohl diese Lösung
nützlich
ist, weist sie einige größere Nachteile
auf: das Zurückgehen
auf einen alten Zurückverfolgungspunkt
führt zum
Verlust aller Aktionen, die seither durchgeführt worden sind, selbst von
denjenigen, die mit der Aktion, die entfernt wird, nichts zu tun
haben.
-
In
der Literatur wurden intelligente Rückverfolgungsmaßnahmen
vorgeschlagen, doch sind sie schwierig in einen in hochinteraktiven
Kontext, wie beispielsweise eine Simulation, zu implementieren und
zu integrieren. Stattdessen wird eine Lösung verwendet, die auf einem
Rückspul-/Wiederhol-Mechanismus
(Schritt s5) basiert. Wenn eine Aktion entfernt wird, findet im
Grunde genommen zuerst eine chronologische Rückverfolgung statt, dann werden
alle diejenigen Aktionen, die nach der entfernten Aktion eingetreten
sind, wiederholt. Allerdings können
einige dieser Aktionen von der entfernten Aktion oder einigen ihrer
Auswirkungen abhängen
und sollten nicht wiederholt werden; daher müssen die Abhängigkeiten
zwischen den Aktionen analysiert werden. Es wurde herausgefunden,
dass im Kontext einer Workflow-Prozess-Simulation, die auf GPSG
basiert, ein einfaches Kriterium im Allgemeinen zum Bestimmen der
Abhängigkeit
ausreicht.
-
Zur
Erläuterung
dieses Kriteriums wird angenommen, dass jede Benutzer-Aktion mit
einer spezifischen Aufgabe (oder einem untergeordneten Ziel) oder
einem Aufgaben-Set verbunden ist. Dies schließt solche globalen Bedingungen
wie Ressourcenbindungen aus, wie im Folgenden erläutert wird. Also
wird eine Benutzer-Aktion B, die nach einer Benutzer-Aktion A durchgeführt wird,
als von A abhängig
betrachtet, wenn, wäre
die Bedingung von A nicht hinzugefügt worden, die mit B verknüpfte Aufgabe nicht
hätte vorhanden
sein können.
Mit anderen Worten, Aktion B hängt
von Aktion A ab, wenn Aktion A mittels einer Bedingungs-Propagierung die
Erweiterung eines untergeordneten Ziels aktiviert hat, das die mit
Aktion B verknüpfte
Aufgabe generiert hat.
-
Zum
Beispiel kann die Zuweisung des Startdatums einer Aufgabe auf nach
einer (weichen) Frist das Erweitern eines untergeordneten Ziels
auf eine eindeutige Weise erzwingen, indem eine Notfallprozedur
ausgelöst
wird. Es ist offensichtlich, dass weitere Aktionen, welche die Notfallprozedur
bedingen, nicht wiederholt werden sollten, wenn die anfängliche Aktion,
die zu dem Notfall geführt
hat, entfernt wird. Anderseits sollte jede Aktion, die für eine Aufgabe durchgeführt wurde,
die nicht von dem Notfall betroffen ist, wiederholt werden.
-
Dieser
Rückverfolgungsablauf
gilt nicht für globale
Bedingungen, wie beispielsweise Ressourcenbindungen, die sich auf
jede Aufgabe auswirken können,
welche die Ressource verwenden kann. Des Weiteren wurden spezielle
Algorithmen, die mit wenig oder keiner expliziten Rückverfolgung
verbunden sind, in der Literatur für die Ablaufplanung von Problemen
in Anwesenheit von Ressourcenbindungen vorgeschlagen (eine so genannte "disjunkte Ablaufplanung"). Solche spezialisierten
Strategien können als
unabhängige
Werkzeuge integriert werden, die der Benutzer jederzeit aufrufen
kann, um die Machbarkeit eines vorgegebenen Prozesszustands punktuell
zu testen. Zum Beispiel kann ein Benutzer mitten in einer Simulation
testen, "was geschehen
würde,
wenn er solche und solche Ressourcen binden würde". Ein spezialisiertes Werkzeug würde dann versuchen,
eine Ablaufplanung für
die Aufgaben mit den vorgegebenen Bedingungen zu erstellen, wobei einige
neue Bedingungen zurückgegeben
werden, für
deren Beibehaltung sich der Benutzer dann entscheiden kann oder
nicht, und die Simulation würde normal
weitergeführt,
ohne die globale Bedingung zu berücksichtigen.