AristaFlow TechNews: Deferred Decision
Prozessschritte, die sowohl automatisch als auch manuell bearbeitet werden können.
Die Herausforderung
Sie kennen die Problematik: ein Geschäftsprozess wartet darauf, dass er Daten als Input bekommt, damit die nachfolgenden Schritte ausgeführt werden können. Woher er diese Daten bekommt, ob per Benutzereingabe, über ein Formular, über ein externes Event oder über eine Input-Schnittstelle, ist für den weiteren Prozessverlauf irrelevant. Wichtig ist nur, dass der Geschäftsprozess diese Daten bekommt und zwar exakt einmal.
Prinzipbedingte Einschränkungen
Prozessmanagement-Systeme tun sich hier prinzipbedingt schwer. Es handelt sich schließlich weiterhin nur um einen einzigen Schritt der Daten an den Prozess liefern soll, obwohl der Input auf mehrere Arten erfolgen kann.
Ansätze
Um dieses Szenario abzubilden, gibt es grundsätzlich zwei Ansätze:
- Der Implementierer des Prozessschrittes, genauer der dahinterliegenden Aktivität, muss alle möglichen Fälle (z.B. Formular, Event, DB) berücksichtigen und diese entsprechend in der Aktivitätenimplementierung abbilden.
- Das Prozessmodell der Workflow-Engine bietet ein Konstrukt, mit Hilfe dessen die Situation im Prozess explizit modelliert werden kann.
Beim ersten Ansatz könnte man den Vorteil sehen, dass weiterhin nur ein Prozessschritt im Prozessmodell zu sehen ist. Dies geht aber auf Kosten der Transparenz und der Wiederverwendbarkeit. Weder der Prozessmodellierer noch der Anwender können erkennen, dass der Prozessschritt seine Daten auf unterschiedliche Weise liefern kann. Die spezifische Implementierung erschwert/verhindert die Verwendung von Standardaktivitäten, was sowohl die Wartung als auch die Wiederverwendung erheblich erschweren.
Bei Ansatz 2 verhält es sich genau umgekehrt. Es ist im Prozessmodell zwar nicht mehr nur ein Prozessschritt, aber es ist sowohl für den Modellierer als auch für den Anwender klar ersichtlich, dass der Input in den Prozess auf mehrere Arten erfolgen kann. Für den Modellierer bietet sich zusätzlich der Vorteil, dass er auf Standardaktivitäten wie Formulare, Events, etc. zurückgreifen kann, was in der Regel dazu führt, dass für die Erstellung des Prozesses kein Implementierer benötigt wird.
Die Lösung: AristaFlow Deferred Decision
Mit dem neuen Konstrukt AristaFlow Deferred Decision löst AristaFlow diese lang bestehende Problematik von Workflow-Systemen. Basierend auf Ansatz 2 stellt der AristaFlow Process Designer ein Modellierungskonstrukt zur Verfügung, dass die explizite Abbildung eines Prozessschrittes ermöglicht, der auf unterschiedliche Arten Input liefern kann. Das Symbol zur Kennzeichnung eines Deferred Decision Konstrukts sieht in den beiden unterstützten Modellierungsrepräsentationen folgendermaßen aus:
BPMN-Symbolik
ADEPT-Symbolik
Der Prozessmodellierer kann ganz bequem alle möglichen Fälle explizit im Prozessmodell abbilden und die Standardaktivitäten wie Formulare, Events, etc. nutzen.
Mit dem Start der ersten eintreffenden Aktivität werden gleichzeitig die anderen Aktivitäten stillgelegt, so dass hier keine doppelte Ausführung stattfinden kann. Wird der Schritt nicht beendet oder die Daten zwischengespeichert, werden die anderen Aktivitäten wieder aktiv geschaltet. Erst wenn eine Aktivität erfolgreich erledigt wurde, werden die anderen Aktivitäten dauerhaft auf SKIPPED gesetzt.
Anwendungsbeispiel:
Ein Compliance-Prozess wartet darauf, dass ein Lieferant eine Schulung absolviert hat, bevor von diesem weitere Waren bezogen werden dürfen. Die Rückmeldung ob eine Schulung durchgeführt wurde, kann sowohl telefonisch, per Mail als auch über den Import einer Teilnehmerliste aus dem Schulungssystem erfolgen. Im ersten Fall werden die Daten von einem Anwender über das Benutzerformular eingegeben und dem Prozess somit zur Verfügung gestellt. In den anderen beiden Fällen kommt jeweils eine Standardaktivität zum Einsatz welche die Daten beim Eintreffen in der Mail-Box, bzw. beim Exportieren aus dem Schulungssystem automatisch ausliest. Je nachdem was nun zuerst eintritt, führt dazu, dass die entsprechende Aktivität ausgeführt wird, der Prozess seine Daten bekommt und gemäß dem Prozessablauf weiterschaltet.
Haben Sie Interesse oder Fragen dazu? Gerne präsentieren wir Ihnen anhand eines Praxisbeispiels die ganze Funktionialität.
Kommentar schreiben
Kommentare
Keine Kommentare
