Case-Design

Der erste Step beim Case-Design in der Prepare-Phase besteht darin, das Backlog der Case-Typen zu überprüfen und den Case-Typ für jede Microjourney zu erstellen, die für das Minimum Lovable Product (MLP) priorisiert wurde. So wird sichergestellt, dass Ihre geplante Lösung auch sinnvoll ist.

Folgende Ziele stehen beim Case-Design im Mittelpunkt:

• Zur Vorbereitung der Build-Phase werden grundlegende Case-Typen und die Verknüpfungen zwischen ihnen erstellt.
• Der Funktionsumfang der Microjourney wird mit dem Product Owner validiert.
• Es wird darauf geachtet, dass beim Case-Design von Anfang an Best Practices zum Einsatz kommen.

Mittels Directly Capture Objectives (DCO) modellieren der Business Architect, der Systemarchitekt und der Product Owner gemeinsam den Case-Typ in Stages und Steps. Diese Aktivität gliedert den Case-Typ in seine Bestandteile.

Nachdem die Steps und Stages mit dem Product Owner abgestimmt wurden, werden in weiteren Gesprächen die am Case-Typ beteiligten Personas sowie die zum Abschluss der Bearbeitung nötigen Datenobjekte definiert. Am Ende der DCO-Sitzungen haben Sie eine visuelle Darstellung des Case-Typs, die vom Product Owner validiert werden kann.

Damit von Anfang an Best Practices für das Case-Design angewendet werden, leitet der Systemarchitekt (SA) die technischen Designaspekte des Case-Typs innerhalb der DCO-Sitzung.

Der SA gewährleistet, dass folgende Punkte beim Case-Design berücksichtigt werden:

• Workflow
• Personas und Channels
• Daten
• Wiederverwendung
• Skalierung

Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um mehr über die Stages und Steps beim Case-Design zu erfahren.

Die Kombination aus Stages und Steps bestimmt den Case-Workflow. In den meisten Unternehmen finden sich mehrere Konstellationen von Aufgaben:

• Manche Aufgaben können nacheinander ausgeführt werden.
• Teilweise können die Aufgaben parallel durchgeführt werden.
• Und bestimmte Aufgaben können optional sein; sie sind nur unter bestimmten Bedingungen anwendbar.  

Zu Beginn des Projekts beeinflussen die verschiedenen Aufgabenarten Ihr Case-Design. Basierend auf den Erkenntnissen aus den Workshops mit dem Product Owner überlegt sich der Lead System Architect (LSA) technische Best Practices. Gegebenenfalls kann beschlossen werden, zusätzliche Case-Typen anzulegen (z. B. um paralleles Arbeiten mithilfe von untergeordneten Cases zu ermöglichen).

Eine weitere Überlegung beim Case-Design ist die Arbeitsaufteilung, die zu Beginn des Projekts besprochen und vereinbart wird. Die Arbeitsaufteilung gibt vor, wie Aufgaben an die mit dem Case-Typ verknüpften Personas weitergeleitet werden. Um das Arbeitsaufteilungsmodell definieren zu können, muss es ein klares Verständnis des geschäftlichen Betriebsmodells geben.

Zwei Modelle stehen für die Arbeitsaufteilung zur Wahl:

• Push-Modell: In einem Push-Modell weist das System oder ein Teammanager die Arbeit manuell dem entsprechenden Benutzer zu.
• Pull-Modell: In einem Pull-Modell wird dem Benutzer die Arbeit automatisch auf Grundlage eines Katalogs an Geschäftsregeln zugewiesen.

Mit dem Ansatz von Pega Express^™ werden Personas mit Stages innerhalb eines Case-Typs verknüpft, um die Interaktion der Persona während des Cases darzustellen. Personas werden auch mit Channels verknüpft, um anzugeben, wie die Persona auf die Anwendung zugreifen kann (z. B. per E-Mail oder über eine Self-Service-Webseite). 

Da die Pega-Plattform eine Persona mit einem Channel assoziieren kann, können UI und Prozesse spezifisch auf einen Channel abgestimmt werden, um eine der jeweiligen Situation entsprechende User Experience zu schaffen.

Im Rahmen der DCO-Sitzungen während der Prepare-Phase ordnen der Product Owner und der Business Architect (BA) die Personas den Stages zu, um sicherzustellen, dass die Geschäftsszenarien im Rahmen des Case-Typs abgedeckt werden. Im Zuge dieser Diskussionen ist es wichtig zu berücksichtigen, welche Art von Interaktionen durch die Persona innerhalb eines bestimmten Channels gebildet werden können. Zum Beispiel könnte es möglich sein, einen Antrag über einen Self-Service-Channel, aber nicht per E-Mail einzureichen. 

Sicherheit je nach Persona und Channel

Für den Case-Typ werden zudem Zugriffsrechte sowohl auf die Daten als auch auf die Prozesse definiert. Zugriffsrechte können sich auf verschiedene Weise auf das Design des Case-Typs auswirken, so z. B.:

• Ausschluss von Aufgaben/Daten von bestimmten Channels
• Einteilung der Arbeit in verschiedene Stages innerhalb des Case-Typs
• Erzeugung eines völlig neuen Case-Typs  

Auf Grundlage der Sicherheitsanforderungen muss der SA über das Design des Case-Typs entscheiden, um die entsprechenden Vorgaben zu erfüllen.

Zu Beginn des Projekts benötigen Sie ein umfassendes Verständnis der Datenobjekte, die mit dem Case-Typ verknüpft sind, um sicherzustellen, dass das Design den Datenanforderungen gerecht wird. 

Für jedes Datenobjekt muss der Systemarchitekt folgende Aspekte berücksichtigen:

• Verfügbarkeit und Aktualität
• Aufbewahrung und Archivierung 

Die Verfügbarkeit von Daten bezieht sich auf die Quelle der Daten. Einige Daten lassen sich möglicherweise aus externen Systemen abrufen. Andere Daten können vom Benutzer direkt erfasst werden und wieder andere sind vielleicht nicht verfügbar, sondern müssen im Laufe des Cases erstellt werden. Die Aktualität der Daten gibt an, wie schnell sie aus anderen Systemen abgerufen werden können und wie häufig sie sich ändern.

Angesichts des zunehmenden Bewusstseins für Datenschutzbestimmungen haben die Vorgaben des Kunden zur Datenspeicherung einen direkten Einfluss auf die Datenmodellierung in Verbindung mit dem Case-Design. Durch die Identifizierung dieser Regeln im Vorfeld muss der SA den Case-Typ so gestalten, dass die Datenverwaltung innerhalb des Cases optimiert wird. 

Beispiel: Ein Bank-Workflow könnte die Bankdaten im letztmöglichen Moment im Case erfassen, um zu vermeiden, dass diese Daten früher als nötig gespeichert werden. Zusätzlich könnte der Workflow einen automatischen Step zur Löschung der Bankdaten benötigen, wenn es keinen legitimen geschäftlichen Grund mehr gibt, die Daten weiterhin zu speichern.

Zu Beginn des Projekts sollten Sie Schlüsselaspekte des Case-Typs identifizieren, die für andere Case-Typen oder spätere MLPs nützlich sein könnten. Dadurch erhält der SA die nötigen Informationen für das Case-Design während der Prepare-Phase, um die Wiederverwendung des Case-Typs als Ganzes oder in Teilen (z. B. bestimmte Prozesse, Daten und die UI) zu ermöglichen. Es empfiehlt sich, geschäftliche und technische Gemeinsamkeiten zu identifizieren. Anschließend spezifizieren und entwerfen Sie die Gemeinsamkeiten als Regeln oder Komponenten zur Verwendung über mehrere Case-Typen hinweg.

Berücksichtigen Sie beim Entwurf des Case-Typs zur Skalierung die Häufigkeit und die Menge der Cases. Die Skalierung bezieht dabei auch die Interaktion der Personas mit dem Case-Typ ein. 

Verschiedene Teammitglieder verwenden die Skalierung, um den Case-Typ zu gestalten:

• Der Product Owner und der BA überprüfen den Workflow, um zu entscheiden, welche Automatisierungsgrade in dem Case-Typ implementiert werden sollen.  
• Der Systemarchitekt erwägt die Mechanismen zum Abrufen und Speichern von Daten innerhalb des Case-Typs.

Wenn Cases häufig und in großen Mengen auftreten, konzentrieren Sie sich auf das Case-Design, um die Direktverarbeitung zu maximieren und den bestmöglichen Durchsatz in kürzester Zeit zu erreichen.   

Durch Beachtung der Case-Menge werden die mit den Case-Typen verbundenen Datenanforderungen schon in den anfänglichen Designdiskussionen berücksichtigt. So werden notwendige Änderungen an der ursprünglichen Case-Modellierung besser erkennbar und es kann sichergestellt werden, dass der Datenzugriff effizient und optimiert abläuft und die Schnittstellen und Reaktionszeiten nicht übermäßig belastet. 

Während der Prepare-Phase notieren Sie diese Aspekte als User Stories und fügen sie dem Backlog für die weitere Ausarbeitung während des Projekts hinzu. 

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.