Case-Life-Cycle entwerfen

Die erste Stage im Case-Life-Cycle ist die „Create Stage“, die durch einen grünen Balken gekennzeichnet ist. Die Create-Stage sollte dabei Prozesse und Steps für Benutzer enthalten, damit diese bei der Case-Erstellung erste Daten eingeben können.

Die Stage „Create“ kann nicht gelöscht oder im Case-Life-Cycle neu positioniert werden. Die Stage „Create“ kann umbenannt werden. Cases, die die Stage „Create“ enthalten, erhalten bei der Case-Erstellung eine Case-ID.

Die Stage „Create“ enthält standardmäßig einen Create-Prozess, den Sie an Ihre Business-Anforderungen anpassen können. Create-Prozesse, die nicht Channel-spezifisch sind, können lediglich Steps zum Erfassen von Informationen enthalten.

Create-Prozesse lassen sich so konfigurieren, dass sie nur unter bestimmten Bedingungen starten. Sie erstellen beispielsweise einen digitalen Messenger-Kanal und konfigurieren einen kanalspezifischen Erstellungsprozess. Sie konfigurieren den Prozess so, dass er nur gestartet wird, wenn der Benutzer die Digital Messenger-App verwendet.

Primäre Stages sind Stages, die zu einem erwarteten Ergebnis führen. Um die primären Stages eines Case-Typs zu identifizieren, sollten Sie Folgendes beachten:

• Die meisten solcher Cases sollen diese Stage durchlaufen.
• Der Abschluss der einzelnen Steps dieser Stage ist Bestandteil der normalen Case-Bearbeitung.
• Die Prozesse in dieser Stage bilden einen wichtigen Bestandteil des Case-Life-Cycle.
• Das Durchlaufen dieser Stage ist für einen positiven Case-Abschluss unerlässlich. 

Der Weg, den ein Case durch den Case-Life-Cycle nimmt und ohne von den primären Stages abzuweichen, wird als Primärpfad – oder auch „Primary Path“ – bezeichnet.

Die Haupt-Stages im Onboarding-Beispiel sind Verification, Pre-arrival Setup, Setup und Onboarding.

Steps zum Sammeln von Informationen (Collect Information) gehören zu jenen, die eine Benutzeraktion oder Input erfordern. Steps zum Sammeln von Informationen sind im Case-Life-Cycle mit grünen Icons versehen.

„Collect information“-Steps werden oft als Assignments oder Aufgaben bezeichnet.

In einer Stage mit zwei oder mehr Prozessen werden die Prozesse normalerweise in sequentieller Reihenfolge ausgeführt. Wenn zwei oder mehr Prozesse unabhängig voneinander gestartet und abgeschlossen werden können, können Sie sie als parallele Prozesse konfigurieren. Während der Case-Bearbeitung kann das aktive Assignment in einem der beiden Prozesse ausgeführt werden.

Das Onboarding-Beispiel enthält einen Prozess „Create IT Setup“, um dem neuen Mitarbeiter einen konfigurierten Laptop zur Verfügung zu stellen, und einen Einrichtungsprozess zum Erstellen von Einrichtungen, um dem neuen Mitarbeiter ein Büro zuzuweisen. Diese Prozesse können in beliebiger Reihenfolge ausgeführt werden, und die Stage wird fortgesetzt, wenn beide abgeschlossen sind.

Tipp: Standardprozesse lassen sich auch in der Stage „Create“ als parallele Prozesse konfigurieren.

Automation Steps werden vom System ausgeführt und sind im Case-Life-Cycle mit gelben Symbolen gekennzeichnet. Automation Steps kann E-Mails versenden, PDF-Dateien erstellen, eine bestimmte Zeit warten oder die Stage eines Case ändern.

Das Onboarding-Beispiel verwendet Automatisierungs-Steps, um abgelehnte IT-Setups auf den primären Pfad zurückzugeben, eine Willkommenspaket-E-Mail an den neuen Mitarbeiter zu senden und verschiedene Arten von Benachrichtigungen an den neuen Vorgesetzten und das Team des Mitarbeiters zu senden.

Alternate Stages sind Stages, die bei Abweichungen vom Primärpfad zum Tragen kommen. Die Alternate Stages sind optional und stellen eine negative Resolution Stage dar oder werden für die Bearbeitung von Ausnahmen verwendet, damit der Case wieder in den primären Pfad eintreten kann.

Entsprechend des Primärpfads des Onboarding-Case-Beispiels geht der Case, wenn die Auswahl im Prozess „IT Setup“ genehmigt wurde, in die Stage „Verification“ über. Wird die Auswahl beim IT-Setup stattdessen abgelehnt, geht der Case in die Alternate Stage „Approval Rejection“ über, die bei Ablehnung der Genehmigung aktiv wird. In dieser Stage kann die Auswahl für das IT-Setup geändert werden.

Die Resolution Stage, gekennzeichnet durch einen roten Balken, definiert das Case-Verhalten am Ende des Case-Life-Cycle. Die Resolution Stage zeigen an, dass der Case seinen Life-Cycle mit dem Abschluss der Stage beendet hat.

Jeder Case-Typ sollte mindestens eine Resolution Stage haben. Ein Case-Typ kann mehr als eine Resolution Stage aufweisen, wenn ein alternativer Pfad für Ihren Business-Prozess definiert wurde. In diesem Beispiel hat der Onboarding-Case-Life-Cycle zwei Resolution Stages: die Stages „Verification“ und „Approval Rejection“.