Aufgaben aus Ereignissen erzeugen, zuweisen und anhand ihrer Ergebnisse weiterführen
Task Orchestration: Aufgaben im Prozess kontrolliert koordinieren
Zwei Aufgaben stehen im Arbeitsvorrat, doch nur eine ist bearbeitbar. Was fehlt bei der anderen: ein Ergebnis, eine Berechtigung oder eine freie Ressource?
Kurzdefinition: Task Orchestration ist die regelgebundene Koordination konkreter Aufgaben von ihrem fachlichen Auslöser über Zuweisung und Ausführung bis zur Wirkung ihres Ergebnisses auf den weiteren Prozess.
Was Task Orchestration bedeutet
Im Mittelpunkt steht nicht die isolierte Aufgabenliste. Eine orchestrierte Aufgabe besitzt einen fachlichen Anlass, einen definierten Eingangskontext, einen zulässigen Ergebnisraum und eine Wirkung auf andere Aufgaben oder Prozessobjekte. Erst diese Beziehungen machen aus mehreren To-dos einen zusammenhängenden Ablauf.
Workflow-Modelle beschreiben die übergeordnete Struktur eines Prozesses. Task Orchestration setzt einen engeren Schwerpunkt: Sie sorgt während der Ausführung dafür, dass aus dieser Struktur jeweils die richtige konkrete Aufgabe für den aktuellen Zustand entsteht.
Zwei offene Aufgaben, aber nur eine ist bearbeitbar
Ein fiktiver Arbeitsvorrat enthält zwei Aufgaben für Charge C-24: „Dokumentation ergänzen“ und „Material bereitstellen“. Die Ergänzung kann beginnen. Die Bereitstellung wartet auf eine Freigabe und die Verfügbarkeit des benötigten Bereichs. Ein gemeinsames Fälligkeitsdatum macht beide Aufgaben noch nicht gleichermaßen ausführbar.
Eine berechtigte Person übernimmt die Ergänzung. Erst deren bestätigtes Ergebnis kann den Approval Workflow zur Prüfung des neuen Dokumentationsstands weiterführen. Die Bereitstellung bleibt bis zur erforderlichen Entscheidung zurückgestellt.
Zwischenzeitlich wird die Charge gesperrt. Selbst wenn nun ein Bereich frei wird, darf diese zusätzliche Voraussetzung die Sperre nicht überstimmen. Die Bereitstellungsaufgabe muss entsprechend dem festgelegten Ablauf angehalten oder aufgehoben werden. Bereits erfasste Angaben bleiben mit ihrem Status erhalten.
Die Aufgabenentscheidung beruht damit auf mehreren getrennten Fragen: Sind die fachlichen Voraussetzungen erfüllt? Ist die Person berechtigt? Sind die benötigten Ressourcen verfügbar? Gilt der Auftrag noch? Priorität entscheidet erst unter den jeweils zulässigen Optionen.
Eine Aufgabe ist eine fachliche Arbeitseinheit
Eine Aufgabe sollte so geschnitten sein, dass ihr Ergebnis fachlich bestimmt und überprüfbar ist. „Charge bearbeiten“ ist dafür meist zu unspezifisch. „Trockengewicht erfassen“, „Abweichung bewerten“ oder „Materialübergabe bestätigen“ bezeichnet dagegen einen klaren Arbeitsgegenstand und ein erwartetes Ergebnis.
Zur Aufgabeninstanz gehören mindestens Identität, Typ, auslösender Vorgang, betroffene Objekte, aktueller Status und zuständige Rolle. Hinzu kommen je nach Prozess Frist, Priorität, anzuwendende Verfahrensversion, erforderliche Eingaben und zulässige Abschlussarten.
Der Abschluss ist nicht mit der fachlichen Wirkung gleichzusetzen. Eine Person kann die Eingabe beendet haben, während eine nachgelagerte Prüfung noch offen ist. Ebenso kann ein technischer Aufruf erfolgreich abgeschlossen sein, obwohl sein fachliches Ergebnis eine Nacharbeit auslöst. Die Orchestrierung muss Bedienstatus, technisches Ergebnis und Prozesswirkung getrennt behandeln.
Abhängigkeiten bestimmen die Reihenfolge
Aufgaben können sequenziell, parallel oder bedingt voneinander abhängen. Eine nachfolgende Prüfung darf beispielsweise erst beginnen, wenn Messwert und Dokumentation vorliegen. Zwei unabhängige Kontrollen können parallel erfolgen. Eine zusätzliche Untersuchung entsteht nur, wenn ein Ergebnis außerhalb des festgelegten Bereichs liegt.
BPMN 2.0.2 unterscheidet unter anderem Aktivitäten, Ereignisse, Sequenzflüsse und Gateways. Damit lassen sich Reihenfolgen, Verzweigungen und Zusammenführungen formal beschreiben.[1] Die Notation entscheidet jedoch nicht, welche reale Abhängigkeit fachlich erforderlich ist. Diese muss aus dem Prozess und seinen Risiken abgeleitet werden.
Bei parallelen Aufgaben ist außerdem zu klären, wann der Ablauf weitergeht. Müssen alle Ergebnisse vorliegen, genügt ein Ergebnis oder beendet eine negative Rückmeldung die übrigen Aufgaben? Ohne diese Regel kann ein System zwar Arbeit verteilen, aber keinen eindeutigen Prozesszustand bilden.
Zuweisung verbindet Verantwortung mit Verfügbarkeit
Eine Aufgabe kann einer konkreten Person, einer Rolle, einem Team, einer Warteschlange oder einem technischen Dienst zugewiesen werden. Die Wahl hängt davon ab, ob besondere Qualifikation, Unabhängigkeit, Standortnähe oder Gerätezugriff erforderlich sind.
WS-HumanTask beschreibt für menschliche Aufgaben unter anderem potentielle und tatsächliche Eigentümer, Stakeholder und Business Administrators sowie Zustände und Operationen für Übernahme, Delegation, Weiterleitung und Abschluss.[2] Diese Rollen verdeutlichen, dass Zuweisung mehr ist als das Eintragen eines Namens. Durch rollenbasierte Prozesssteuerung wird die zulässige Ausführung zusätzlich an Rollen, Qualifikationen und Berechtigungen gebunden.
Auf Architekturebene beschreibt Weske denselben Zusammenhang zurückhaltender: In Human-Interaction-Workflows können organisatorische Informationen zu Prozessbeteiligten, ihren Fähigkeiten und ihrer Verfügbarkeit von der Workflow Engine genutzt werden, um Arbeit geeigneten Personen anzubieten.[6] Für die Task Orchestration ist das eine Eingangsgröße der Zuweisung, nicht deren vollständige fachliche Regel.
Eine gute Orchestrierung prüft Berechtigung und Eignung beim Entstehen und gegebenenfalls erneut bei der Übernahme. Ändern sich Schicht, Qualifikation oder Vertretung, muss die Aufgabe regelgebunden neu verteilt werden können. Die bisherige Zuweisung und der Grund der Änderung bleiben nachvollziehbar.
Ob Zuständigkeiten und Unterstützung auch über Schichtwechsel hinweg funktionieren, lässt sich vor der Betriebsaufnahme gemeinsam erproben. Zur Einführung von Workflow-Software gehören deshalb auch die Vorbereitung der Beteiligten und die kontrollierte Übergabe an den Betrieb.
Priorität entsteht aus Prozesswirkung und Dringlichkeit
Treffen mehrere Aufgaben gleichzeitig bei einer Person oder Rolle ein, benötigt ihre Reihenfolge eine nachvollziehbare Grundlage. Ein früheres Erstellungsdatum allein reicht nicht aus. Eine sicherheitsrelevante Abweichung, eine drohende Materialgefährdung oder eine zeitkritische Übergabe kann Vorrang vor einer älteren Routineaufgabe haben.
Priorität sollte deshalb aus fachlichen Merkmalen abgeleitet werden: Risiko, Fälligkeit, Prozessblockade, betroffene Charge und mögliche Folgewirkung. Das System kann diese Faktoren zusammenführen und eine Reihenfolge vorschlagen. Es sollte zugleich kenntlich machen, warum eine Aufgabe höher eingestuft wurde.
Eine manuelle Umpriorisierung kann erforderlich sein, darf aber die ursprüngliche Regel nicht unsichtbar ersetzen. Wer die Reihenfolge ändert, benötigt die passende Berechtigung; Grund und Zeitpunkt bleiben erhalten. So wird aus einer flexiblen Arbeitssteuerung keine beliebige Verschiebung kritischer Kontrollen.
Auch Kapazität gehört in die Orchestrierung. Werden mehr Aufgaben erzeugt, als berechtigte Personen bearbeiten können, helfen zusätzliche Erinnerungen allein nicht. Das System muss Engpässe sichtbar machen und gegebenenfalls geregelte Vertretung, Neuverteilung oder eine bewusste Prozessunterbrechung auslösen.
Veränderte Prozesszustände können offene Aufgaben entwerten
Eine offene Aufgabe bleibt nicht unter allen Umständen gültig. Wird eine Charge gesperrt, ein Dokument zurückgezogen oder ein Gerät außer Betrieb genommen, können bereits verteilte Folgeaufgaben ihren fachlichen Gegenstand verlieren. Die Orchestrierung muss solche Abhängigkeiten erkennen.
Je nach Prozess wird die Aufgabe abgebrochen, angehalten oder mit aktualisiertem Kontext neu erzeugt. Eine bereits begonnene Tätigkeit benötigt dabei besondere Behandlung: Eingaben dürfen nicht unbemerkt verworfen werden, zugleich darf ein veralteter Abschluss keine unzulässige Wirkung mehr auslösen.
Der Abbruch bleibt ein eigenes Ereignis mit Ursache, Zeitpunkt und ausgelöstem Zustand. Dadurch ist später erkennbar, ob eine Aufgabe regulär abgeschlossen, durch eine andere Entscheidung überholt oder wegen eines technischen Problems beendet wurde. Offene abhängige Aufgaben lassen sich so kontrolliert schließen, statt als scheinbar weiterhin gültige Arbeit im System stehen zu bleiben.
Was bei einer neuen Vorgabe mit der offenen Aufgabe geschieht
Eine Aufgabe braucht einen erkennbaren Bezug zur geltenden Verfahrensfassung. Ändert sich diese während der Bearbeitung, ist eine konkrete Entscheidung nötig: weiterarbeiten nach dem bisherigen Stand, Aufgabe anhalten oder mit dem neu vorgeschriebenen Kontext fortsetzen.
Eine kontrollierte Migration bleibt möglich. Sie muss berücksichtigen, welche Eingaben bereits entstanden sind, ob zusätzliche Schritte erforderlich werden und wer die Änderung veranlasst hat. Der Anwender sollte erkennen können, was sich für seine noch offene Arbeit geändert hat. Ein stiller Austausch der Anweisung lässt diese Frage unbeantwortet.
Aufgaben entstehen aus Ereignissen und Ergebnissen
Eine Aufgabe benötigt einen nachvollziehbaren Auslöser. Das kann der Abschluss einer vorherigen Tätigkeit, das Eintreffen eines Messwerts, ein Termin, eine Statusänderung oder eine bewusste Entscheidung sein. Auch das Ausbleiben eines erwarteten Ereignisses kann eine Kontroll- oder Eskalationsaufgabe erzeugen.
Prozessereignisse bilden solche beobachtbaren Veränderungen als strukturierte Daten ab. Die Orchestrierung wertet sie im Kontext der laufenden Prozessinstanz aus und bestimmt, ob daraus eine neue Aufgabe, ein Wartezustand oder der Abschluss eines Prozessabschnitts folgt.
Ein Ereignis darf nicht mehrfach dieselbe fachliche Wirkung erzeugen. Wird eine Nachricht erneut zugestellt oder ein Nutzer aktualisiert die Seite, sollte nicht versehentlich eine zweite identische Aufgabe entstehen. Dafür benötigt der Ablauf eindeutige Ereignis- und Aufgabenidentitäten sowie Regeln zur Wiederholung.
Ergebnisse steuern den weiteren Verlauf
Ein bloßer Status „erledigt“ reicht für viele Prozesse nicht aus. Eine Kontrolle kann „in Ordnung“, „Abweichung festgestellt“, „nicht prüfbar“ oder „erneute Messung erforderlich“ ergeben. Jedes Ergebnis benötigt eine festgelegte fachliche Bedeutung.
Die Orchestrierung übersetzt das Ergebnis in die nächste zulässige Wirkung. Ein positiver Messwert kann die nächste Produktionsstufe freigeben, ein unplausibler Wert eine Wiederholungsmessung erzeugen und eine festgestellte Abweichung einen Untersuchungsprozess beginnen. Diese Logik sollte sichtbar im Prozessmodell liegen und nicht unbemerkt in einzelnen Formularen verteilt sein.
Freitext kann ein Ergebnis erläutern, sollte aber nicht die alleinige Grundlage für automatische Weiterführung sein. Strukturierte Ergebniswerte schaffen eindeutige Übergänge; ergänzende Kommentare erhalten den fachlichen Kontext.
Fristen erzeugen neue Handlungen, keine stillen Entscheidungen
Aufgaben können Fälligkeiten, Erinnerungen und Eskalationsstufen besitzen. Wird eine Prüfung nicht rechtzeitig übernommen, kann das System eine Vertretung informieren oder die Aufgabe einer anderen berechtigten Rolle anbieten.
Der Ablauf muss unterscheiden, ob eine Frist nur der Arbeitsorganisation dient oder eine fachliche Grenze markiert. Eine überfällige Wartungskontrolle kann beispielsweise die weitere Nutzung eines Geräts sperren. Eine verspätete Rückmeldung darf dagegen nicht automatisch als Zustimmung gelten, wenn eine aktive Entscheidung erforderlich ist.
Auch Zeitereignisse brauchen einen nachvollziehbaren Ursprung. Festzuhalten ist, welche Frist galt, aus welcher Regel sie abgeleitet wurde und welche Eskalation tatsächlich ausgelöst hat. So bleibt später erkennbar, ob eine Verzögerung organisatorisch, technisch oder fachlich bedingt war.
Menschliche und technische Aufgaben folgen verschiedenen Regeln
Technische Aufgaben können unmittelbar ausgeführt, wiederholt oder nach festgelegten Fehlern kompensiert werden. Menschliche Arbeit benötigt dagegen Zeit, verständlichen Kontext und reale Handlungsmöglichkeiten. Sie kann Rückfragen, Unterbrechungen und begründete Abweichungen enthalten.
BPEL4People erweitert serviceorientierte Prozessmodelle um menschliche Interaktionen und beschreibt die Koordination zwischen Prozess- und Aufgabeninfrastruktur.[3] Daraus folgt nicht, dass menschliche und technische Aufgaben gleichbehandelt werden sollten. Sie können in einem gemeinsamen Ablauf stehen, benötigen aber unterschiedliche Lebenszyklen.
Digitale Arbeitsanweisungen führen die Person durch die fachliche Ausführung einer Aufgabe. Task Orchestration bestimmt dagegen, warum diese Aufgabe jetzt vorliegt, welchen Kontext sie erhält und welches Ergebnis anschließend welchen Schritt auslöst.
Ein technischer Neuversuch ist keine neue Messung
Wurde ein Übertragungsaufruf unterbrochen, kann ein erneuter Aufruf dasselbe bereits erfasste Ergebnis übermitteln. Wird eine Messung erneut durchgeführt, entsteht dagegen eine neue Beobachtung. Die Aufgabenführung muss diese Fälle unterscheiden und den neuen Versuch mit seinem Anlass verbinden.
Technische Fehler- und Kompensationsmechanismen, etwa in WS-BPEL,[4] legen nicht fest, ob eine Wiederholungsmessung fachlich zulässig ist. Eine Ausgleichshandlung nach bereits eingetretener Wirkung benötigt ebenfalls eine ausdrückliche Aufgabe mit eigenem Ergebnis.
Eine Rückmeldung gehört zu einer bestimmten Aufgabeninstanz
Wenn mehrere Personen oder Dienste ähnliche Aufgaben bearbeiten, muss ihre Antwort den konkreten Auftrag identifizieren. Eine allgemeine Chargenkennung allein kann dafür zu grob sein. Der Abschluss einer früheren Kontrolle darf nicht versehentlich eine neu angesetzte Kontrolle erledigen.
Technische Trace-Identitäten können verteilte Aufrufe zusammenführen, wie W3C Trace Context beschreibt.[5] Für die Aufgabensteuerung bleibt zusätzlich die fachliche Identität erforderlich. Sie bestimmt, auf welche Aufgabe und welchen Versuch sich das Ergebnis bezieht.
Aufgaben im Arbeitszusammenhang von 420+
Die Aufgabenführung von 420+ leitet aus einem betrieblichen Anlass den nächsten bearbeitbaren Schritt ab. Material, SOP-Version, Person beziehungsweise Rolle und Ergebnis sind im Aufgabenkontext verknüpft. Sperren, Fristen und Eskalationen lassen sich entsprechend dem Prozess konfigurieren. Der digitale Betriebszwilling verbindet diese Aufgaben mit den betroffenen Objekten und erfassten Zuständen.
Die Workflow Engine setzt die Prozessinstanz entsprechend ihrem Zustand fort. Der Arbeitsvorrat muss dazu passen: Eine nicht mehr gültige Aufgabe darf keine weiterhin zulässige Tätigkeit vortäuschen. Für die menschenzentrierte Gestaltung im Sinne von Industrie 5.0 muss die ausführende Person erkennen können, welche Aufgabe noch bearbeitbar ist und wo Klärung nötig wird.
Task Orchestration von benachbarten Begriffen abgrenzen
- Eine Aufgabenliste ist keine Task Orchestration. Ohne Auslöser, Kontext und Ergebniswirkung bleiben Einträge voneinander getrennt.
- Orchestrierung ist nicht bloße Automatisierung. Sie kann menschliche Arbeit koordinieren, ohne die Entscheidung zu automatisieren.
- Ein technischer Erfolg ist nicht zwingend ein fachlicher Abschluss. Beide Zustände müssen getrennt ausgewertet werden.
- Eine Erinnerung ersetzt keine Eskalationsregel. Zuständigkeit und mögliche Prozesswirkung müssen bestimmt sein.
- Korrelation beweist keine Datenintegrität. Sie ordnet Vorgänge einander zu, bewertet aber nicht deren Richtigkeit.
- Ein erneuter Versuch darf die Historie nicht überschreiben. Wiederholung und Korrektur bleiben als verbundene Vorgänge sichtbar.
Der Arbeitsvorrat muss den aktuellen Betrieb widerspiegeln
Eine nützliche Aufgabenübersicht unterscheidet bearbeitbare Arbeit von blockierten, übernommenen und überholten Aufträgen. Sie macht sichtbar, ob ein fehlendes Ergebnis, eine Berechtigung oder eine belegte Ressource das Weiterarbeiten verhindert.
Damit wird auch ein Engpass besprechbar: Fehlt Kapazität, hilft eine Neuverteilung. Fehlt eine fachliche Voraussetzung, muss diese geklärt werden. Zusätzliche Erinnerungen lösen weder das eine noch das andere von selbst.
Primärquellen und weiterführende Literatur
- Object Management Group, Business Process Model and Notation (BPMN), Version 2.0.2, Januar 2014. Offizielle Spezifikation (PDF)
- OASIS, Web Services – Human Task (WS-HumanTask) Specification Version 1.1, Committee Specification 01, 2010. Offizielle Spezifikation
- OASIS, WS-BPEL Extension for People (BPEL4People) Specification Version 1.1, Committee Specification 01, 2010. Offizielle Spezifikation
- OASIS, Web Services Business Process Execution Language Version 2.0, OASIS Standard, 2007. Offizieller Standard
- World Wide Web Consortium, Trace Context, W3C Recommendation, 23. November 2021. W3C Recommendation
- Mathias Weske, Business Process Management: Concepts, Languages, Architectures, 4. Auflage, Springer, 2024, Kapitel 8.1 „Workflow Management Architectures“. Verlagsfassung / DOI