Der Case-Life-Cycle von Pega
Business-Anwendungen helfen dabei, die Arbeit zu automatisieren, die notwendig ist, um bestimmte Ergebnisse zu erzielen. Herkömmliche Business-Anwendungen basieren auf einzelnen Transaktionen und sind auf eigenständigen Anwendungen für verschiedene abteilungsspezifische Funktionen aufgebaut. Isolierte Anwendungen erschweren es den verschiedenen Geschäftsbereichen zusammenzuarbeiten und effiziente Geschäftsergebnisse zu erzielen.
Pega ist der Meinung, dass Anwendungen so funktionieren sollten, wie die Benutzer über ihre Arbeit denken und sie beschreiben. Nehmen wir zum Beispiel einen Online-Bestellprozess: Der Kunde gibt eine Bestellung auf und das Unternehmen bearbeitet und liefert die Bestellung dann aus. Eine Pega-Plattform-Anwendung, die den Online-Bestellprozess modelliert, folgt dem gleichen Ablauf.
Die Journey beschreibt die Interaktionen, die zwischen einem Kunden und einem Unternehmen stattfinden, wenn der Kunde ein bestimmtes Ziel verfolgt, z. B. die Einstellung eines Bewerbers.
Von der Microjourney zum Case-Life-Cycle
Microjourneys sind die Lebenszyklen oder Arbeitseinheiten, die Kunden und Anwendern ein sinnvolles Ergebnis liefern. Microjourneys sind Teil der gesamten Customer Journey, mit der alle oder ein Teil der gewünschten Geschäftsergebnisse erreicht werden.
Um Microjourneys zu identifizieren, müssen Sie die gesamte User Experience von Anfang bis Ende für die Endbenutzer analysieren. So erkennen Sie die einzelnen Funktionsschritte, die Teams schnell in die Produktion implementieren können, was einen unmittelbaren Mehrwert schafft. Sie können Microjourneys direkt in der Pega-Plattform erfassen, indem Sie die Microjourney in die drei Säulen Ihrer Anwendung unterteilen.
Das folgende Diagramm zeigt die drei Säulen Ihrer Anwendung. Die drei Säulen sind die Case-Typen und -Strategien, Personas und Channels sowie die Daten und Schnittstellen für die Microjourney:
Wenn Sie als Business Architect die drei Säulen direkt in App Studio erfassen, können Sie schnell und einfach einen Konsens über die Lösung erzielen, indem Sie Folgendes visuell dokumentieren:
- Die Microjourney (Case-Life-Cycle) visualisiert den Weg Ihrer Geschäftsprozesse bis zum Abschluss.
- Personas repräsentieren die Personen, die an Ihren Prozessen beteiligt sind, sowie die Channels, die sie für die Interaktion mit einem Case verwenden.
- Daten sind die Informationen, die Ihr Workflow benötigt, um eine Lösung zu erreichen, und Interfaces sind die Schnittstellen, die vorgeben, wie auf diese Daten zugegriffen wird.
Case-Typen und Cases
Ein Case-Typ (Vorgangstyp) ist ein abstraktes Modell einer Business-Transaktion. Case-Typen modellieren wiederholbare Business-Transaktionen. Ein Case (Vorgang) ist eine bestimmte Transaktionsinstanz. Um die Online-Bestellungstransaktion in Pega zu modellieren, definieren Sie den Case-Typ einer Online-Bestellung, der von der Aufgabe der Bestellung über die Verarbeitung bis hin zur Lieferung reicht. Wie in der folgenden Abbildung dargestellt, legt die Pega-Plattform jedes Mal, wenn ein Benutzer eine Online-Bestellung einreicht, einen Order-Case an und weist dem Case eine Nummer zu:
Der Case-Life-Cycle
Sie legen den Case-Life-Cycle eines Case-Typs fest, um die Arbeitsschritte zu visualisieren, die im Rahmen der gewünschten Business-Transaktion absolviert werden müssen. Der Case-Life-Cycle repräsentiert das Geschäftsmodell der Microjourney™. Der Case-Life-Cycle gibt den Pfad vor, dem Ihr Case bis zu seinem Abschluss folgt. Die wichtigsten Bausteine des Case-Life-Cycle sind Phasen (Stages), Prozesse und Schritte (Steps).
Bei den Zahlen zur folgenden Abbildung erfahren Sie mehr über die Bausteine eines Case-Typs:
- Stage
- Prozess
- Step
Stage
Wenn Sie einen Case-Life-Cycle entwerfen, gliedern Sie zuerst die Arbeit in Stages. Stages definieren die Organisation der Aktionen auf oberster Ebene, die in Ihrem Business-Prozess ausgeführt werden.
Jede Stage markiert eine bestimmte Phase oder einen Meilenstein im Case-Life-Cycle. Stages organisieren den Business-Prozess in einer sequenziellen, logischen Sammlung von Aktionen oder Aktivitäten, die den Prozess auf den Weg zum Abschluss bringen.
Beispielsweise erwarten Sie bei einer Online-Bestellung die Beteiligung von drei verschiedenen Gruppen: Kunden, die Bestellungen aufgeben, Lagerarbeiter, die Bestellungen bearbeiten, und Mitarbeiter des Versandservice, die Bestellungen für die Auslieferung vorbereiten. Daher erstellen Sie für den Case-Typ „Online-Bestellung“ diese drei Stages: Bestellungseingang, Bearbeitung und Lieferung: „Submission“, „Processing“ und „Delivery“.
Prozess
Prozesse umfassen mehrere Aufgaben oder Steps, die die Benutzer während der Arbeit an einem Case ausführen. Jede Stage kann einen oder mehrere Prozesse enthalten.
Wenn Sie Prozesse zu einem Case-Typ hinzufügen, organisieren Sie verwandte Aufgaben auf logische Weise. Außerdem legen Sie eine Reihenfolge der Ereignisse fest, sodass ein Case erst dann in den nächsten Prozess übergehen kann, wenn die Steps im aktuellen Prozess abgeschlossen sind.
Beispielsweise handelt es sich beim Aufgeben und Bearbeiten von Bestellungen bzw. beim Versenden von Artikeln um Prozesse. In der Abbildung heißen diese Prozesse „Place Order“, „Processing“ und „Delivery“.
Step
Ein Step ist entweder eine Benutzeraktion oder eine automatisierte Aktion innerhalb eines Prozesses, die von der Anwendung ausgeführt wird. Ein Step, der eine Benutzeraktion erfordert, wird als Aufgabe (Task) oder Assignment bezeichnet. Schritte, die das System erledigt, werden als Automatisierungsschritte bezeichnet.
Durch die Verwendung einer Vielzahl von Step-Typen stellen Sie sicher, dass Ihre neu gestalteten Business-Prozesse alle relevanten und notwendigen Maßnahmen zum Erreichen des strategischen Ergebnisses umfassen.
Beispielsweise ist der Step „Enter customer details“ ein Schritt im Prozess „Place Order“, bei dem die Benutzer Informationen eingeben müssen.
Namenskonventionen für Case-Typen
Beachten Sie bei der Erstellung von Case-Typen sowie von Stages, Prozessen und Steps in einem Case-Life-Cycle die folgenden Namenskonventionen.
Beim Benennen des Case-Typs sollten Sie einen Namen wählen, der das Ergebnis des Business-Prozesses widerspiegelt – nicht auf die Aktionen, die Benutzer ausführen müssen. Stellen Sie sicher, dass der Name des Case-Typs den Zweck des Case-Typs klar vermittelt. Beispielsweise ist der Name „Finanzvorgänge“ mehrdeutig und unspezifisch, aber Bezeichnungen wie Kreditantragsprüfung, Hypothekenantragsprüfung oder Kreditkartenstreitfall vermitteln ihren Zweck genau.
Benennen Sie Stages, indem Sie den Kontext des Abschnitts mit einem Substantiv, Substantivsatz oder Gerundium (das als Substantivsatz fungiert) beschreiben. Versuchen Sie, möglichst nicht mehr als zwei Wörter zu verwenden. Diese Bezeichnungen sollten aussagekräftig und für Business-Anwender relevant sind. In oben genannten Beispiel bearbeitet das Unternehmen die Bestellung in der zweiten Stufe des Case-Life-Cycle. Deshalb benennen Sie diese Stage Bearbeitung.
Testen Sie für Stages, die den Case nicht lösen, den gewählten Namen, indem Sie prüfen, ob er in den folgenden Testsätzen korrekt klingt (für englische Beispiele):
This Case is in <Stage name>.When does this Case move to <Stage name>?How many Cases are in <Stage name>?
Lesen Sie den Satz mit Ihrem vorgeschlagenen Stage-Namen laut vor. Wenn der Stage-Name in diesen Sätzen nicht richtig passt, ist eine Änderung sinnvoll.
Benennen Sie Prozesse und Steps mit einem Verb und einem Hauptwort als gängige Namenskonvention. Im Bestellbeispiel nennen Sie den Prozess in der Processing Stage Auftragsbearbeitung. Die einzelnen Prozessschritte nennen Sie Bestandsprüfung und Verpacken.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen:
Dieses Thema ist im folgenden Modul verfügbar:
Möchten Sie uns dabei helfen, diesen Inhalt zu verbessern?