Business Architect: Grundlegende Best Practices für Pega Express

Geschäftsergebnisse beschreiben die Ergebnisse für das Unternehmen. Es handelt sich um wichtige Geschäftsziele, die einen hohen Nutzen bringen und die mit einer mit Pega-Plattform erstellten Anwendung erreicht werden sollen. Geschäftsergebnisse sind z. B.: 

• ein neues Umsatzziel
• ein Konzept zur Kundenbindung
• ein Effizienzziel

Die Identifizierung und Festlegung wichtiger strategischer Geschäftsergebnisse für die Pega-Anwendung gibt die Richtung für Ihr Programm zur Transformation von Business-Prozessen vor. Außerdem wird so sichergestellt, dass alle Schritte dazu beitragen, die Anforderungen des Kundenunternehmens und seiner Endkunden zu erfüllen. 

Bei der Best Practice für den Geschäftswert geht es um die Sicherstellung, dass das Unternehmen seine strategischen Ergebnisse erreicht. Damit das ein Erfolg wird, müssen die geschäftliche Begründung und der unterstützende Business Case gründlich vorbereitet werden. 

Für Sie als Pega BA bringt eine genaue Kenntnis des Business Case viele Vorteile, wie z. B.:

• Priorisierung des Umfangs, damit sich mit der vorgeschlagenen Lösung die Geschäftsergebnisse erreichen lassen
• Festlegen von Ziel-KPIs (Key Performance Indicators), die mit der Pega Lösung erreicht werden
• Berechnung der Kapitalrendite (Return on Investment, ROI) anhand des Baseline- und des Target-Modells

Durch die Ermittlung des Geschäftswerts für ein Projekt erhalten Sie als Vermittler zwischen Business und IT während des gesamten Projekts einen Bezugspunkt für Gespräche zur Priorisierung mit dem Business-Team.

Praktische Anwendung von Geschäftsergebnissen und Geschäftswert für Pega Business Architects

Als Pega Business Architect arbeiten Sie mit dem Product Owner zusammen, um die wichtigsten strategischen Geschäftsergebnisse des Projekts zu verstehen und so die Richtung für die Transformation des Business-Prozesses vorzugeben. Im weiteren Verlauf des Projekts dient Ihre Kenntnis des Business Case als Grundlage für Gespräche mit Stakeholdern des Business-Teams, wenn es um die Priorisierung von Features nach dem Geschäftswert geht, den jedes Feature bringt. 

Prüfen Sie mit der folgenden Interaktion Ihr Wissen:

Das Konzept der Microjourney bildet die Grundlage für den Bereitstellungsansatz von Pega Express. Diese Methode steht für das Besondere, was Pega ausmacht: Die Komplexität der größeren Customer Journeys wird in kleinere, schneller durchführbare Journeys unterteilt, damit Sie schneller von der Neugestaltung Ihrer Business-Prozesse profitieren.

Um Microjourneys zu identifizieren, müssen Sie die vollständige Endbenutzererfahrung einer Anwendung „von A bis Z“ berücksichtigen. Diese Übung identifiziert inkrementelle Funktionselemente in der gesamten Journey, die Ihre Projektteams schnell in die Produktion implementieren können, um einen unmittelbaren Mehrwert für das Kundenunternehmen und dessen Endkunden zu schaffen. 

Die folgende Abbildung zeigt beispielsweise, wie eine Service-Journey im Automobilbereich – eine Anfrage um Pannenhilfe bei einem Unternehmen namens GoGoRoad – in eine Microjourney unterteilt werden könnte:

Der Bereitstellungsansatz von Pega Express empfiehlt, Anwendungsänderungen in einem Software-Release zu bündeln, das als „Minimum Lovable Product (MLP)“ bezeichnet wird. Eine MLP-Release oder mehrere MLP-Releases in einem Projekt bilden dann die transformative Roadmap für die Neugestaltung Ihrer Business-Prozesse.    

Jedes MLP liefert eine Lösung, die nicht nur realisierbar ist, sondern auch von den Endanwendern gewünscht und angenommen wird. Wie in der folgenden Abbildung dargestellt, ist ein MLP so konzipiert, dass es schnell Geschäftsergebnisse auf eine Weise liefert, die Kunden begeistert und ihnen das Leben leichter macht, wodurch sich die Time-to-Value für den Kunden beschleunigt:

Praktische Anwendung von Microjourneys und MLP für Pega Business Architects

Mit dem Konzept der Microjourney und der MLP-Struktur brechen Sie als Business Architect die Komplexität des Entwicklungsprozesses in inkrementelle Bereitstellungen auf. Das erhöht nicht nur die Sicherheit und verbessert die Anwendungsbereitstellung, sondern trägt auch dazu bei, den damit verbundenen Wert zu erreichen. Dadurch wird der Prozess der Anwendungsbereitstellung überschaubar und flexibel für Änderungen. Stakeholder in allen Business- und IT-Teams können dann die gewonnenen Erkenntnisse bei der Implementierung der einzelnen MLPs während der Roadmap berücksichtigen und anwenden.  

Prüfen Sie mit der folgenden Interaktion Ihr Wissen:

Directly Capture Objectives (DCO) ist die Pega-Disziplin der kontinuierlichen Zusammenarbeit, Iteration und Validierung während eines Pega Projekts. DCO fördert die Abstimmung zwischen den Stakeholdern sowie die gute, zielführende Zusammenarbeit zwischen Business- und IT-Teams. Wie in der folgenden Abbildung dargestellt, legt DCO den Schwerpunkt auf kontinuierliche Zusammenarbeit (Collaboration), schrittweise Verbesserungen (Iteration) und Validierung (Validation):

Schwerpunkte der DCO-Gespräche sind:

• Anwendungsdesign und -entwicklung
• Erreichen von Geschäftsergebnissen
• ein Design, bei dem der Mensch im Mittelpunkt steht
• Iterationen zur schnelleren Realisierung des Geschäftswerts

Mithilfe der von Pega bereitgestellten Visualisierungstools hilft DCO den geschäftlichen Stakeholdern, die Anwendung aus einer praktischen, erlebnisorientierten Perspektive zu verstehen.

Als Business Architect ist die Integration von DCO in Ihr Projekt von entscheidender Bedeutung. Denn dadurch vermeiden Sie Missverständnisse und minimieren das Risiko, dass Diskrepanzen zwischen Geschäftsanforderungen und Funktionalität zu spät im Anwendungsentwicklungsprozess entdeckt werden. 

Wiederverwendung ist die strategische Best Practice für das Design und die Konfiguration von Anwendungen hinsichtlich der längerfristigen Roadmap, Skalierbarkeit und Unternehmensanforderungen.  

Die Wiederverwendung ermöglicht die schnelle Implementierung von kurzfristig erweiterbaren Anwendungen zur Erfüllung spezieller Business-Anforderungen und Förderung einer einheitlichen User Experience.

Das Pega-Konzept der Wiederverwendung, das der Situational Layer Cake zusammenfasst, besteht aus den folgenden Application Layers, die vom spezialisiertesten bis zum allgemeinsten reichen:

• Innovation: umfasst Regeln für Anwendungen, die für bestimmte Geschäftseinheiten oder Regionen mit Lokalisierung entwickelt wurden
• Business: umfasst Regeln, die mit den einzelnen Geschäftseinheiten eines Unternehmens verknüpft sind
• Module: umfasst alle Regeln, die zur Wiederverwendung in Geschäfts- und Innovationsanwendungen verfügbar sind
• Enterprise: umfasst Regeln, die für alle Anwendungen im Unternehmen gelten
• Pega-Plattform: besteht aus allen Regelpaketen der Pega-Plattform

Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um mehr über das Pega-Konzept der Wiederverwendung und den Situational Layer Cake von Pega zu erfahren:

Scrum ist ein grundlegender Bestandteil des Bereitstellungsansatzes mit Pega Express. Scrum stellt sicher, dass Stakeholder aus den Business- und IT-Teams transparent und gut zusammenarbeiten, um die richtigen Ergebnisse für den Kunden zu erzielen. Außerdem garantiert der Scrum, dass es zum Zeitpunkt der Bereitstellung keine unerwünschten Überraschungen gibt. 

Scrum ist eine Form der Agile-Entwicklung, um bestimmte Rollen, Zuständigkeiten, Ereignisse, Artefakte und Prozesse für Ihr Projekt zu definieren. Dazu gehören Führungsrollen wie Product Owner (PO), Project Delivery Lead (PDL) und Scrum Master, die Gliederung von Projekten in zeitlich begrenzte Entwicklungszyklen (so genannte „Sprints“) und die Pflege eines Projekt-Backlogs, der in User Stories unterteilt ist.

Sprints und Scrum-Events 

Ein Sprint ist ein zeitlich begrenzter Arbeitszyklus, der bis zu vier Wochen dauert und in dem das Team ein Ergebnis erarbeitet. Sprints sind während des gesamten Projekts gleich lang und wenn ein Sprint endet, beginnt der nächste, der ein neues Ergebnis liefert. In jedem Sprint finden mehrere Scrum-Events statt. Jeder Scrum-Event hilft dem Team, das Geleistete zu überprüfen und anzupassen. 

Scrum-Events beinhalten: 

• Optimierung und Schätzung der User Story: bietet Zeit für die Überprüfung von User Stories auf Umfang und Vollständigkeit
• Sprint-Planung: ermöglicht es dem Product Owner, Project Delivery Lead und Scrum Master, die User Stories im aktuellen Sprint zu priorisieren
• Daily Scrum: findet täglich statt, damit bestimmte Mitglieder des Projekts zusammenkommen und ihre Fortschritte besprechen können
• Sprint Review: damit bestimmte Mitglieder des Projektteams überprüfen können, was im aktuellen Sprint entwickelt wurde
• Sprint-Retrospektive: damit sich das Projektteam darüber austauschen kann, was beim nächsten Sprint anders werden soll – basierend darauf, was im aktuellen Sprint gut gelaufen ist oder was verbessert werden kann

Als Business Architect nehmen Sie aktiv an allen Scrum-Events soweit möglichst auch an den Daily Scrums teil.

User Stories optimieren und Schätzung 

Es finden häufig Sitzungen zur Optimierung und Schätzung von User Stories statt. Während der Meetings zur Optimierung der User Stories und der Schätzung führt das Team folgende Aktionen durch: 

• Bestätigen, dass das IT-Team weiß, welche User Stories für die Schätzung bereit sind und dass die User Stories die Definition of Ready (DoR) erfüllen (das Kriterium zur Bestimmung, ob eine Story vollständig ist) 
• Informieren des Entwicklerteams, damit dieses den Aufwand für die Konfiguration und das Testen der User Story ermitteln kann, um die in der Definition of Done (DoD) festgelegten Kriterien zu erfüllen (d. h. die Kriterien, anhand derer festgestellt wird, ob die Entwicklung einer Story abgeschlossen ist) 
• Bestimmen des Story-Umfangs (Dimensionierung) anhand von Story Points (klein = 1, sehr groß = 13), damit der Scrum Master die Story in der nächsten Sprint-Planungssitzung berücksichtigen kann 

Scrum in der Praxis für den Pega Business Architect

Als Vermittler zwischen Business- und IT-Projektteams nehmen Sie während des Projekts aktiv an vielen Scrum-Events teil. Die Informationen, die während der Scrum-Events kommuniziert werden, ermöglichen es Ihnen, mal für das Business-Team und mal für das IT-Team als Fürsprecher aufzutreten. Sie nehmen beispielsweise aktiv an den Scrum-Events zur Story-Verfeinerung und Schätzung teil, um die User Stories fertigzustellen, die Sie im Rahmen Ihrer DCO-Sitzungen erstellt haben. Sobald die User Stories fertig sind, fügen Sie sie dem Projekt-Backlog hinzu, damit sie dem IT-Team bei den kommenden Sprints für die Entwicklung und das Testen zur Verfügung stehen.  

Prüfen Sie mit der folgenden Interaktion Ihr Wissen: