Frohe Festtage und einen guten Rutsch!

2025 war für uns bei masoona wieder ein aufregendes Jahr:

Und so haben wir bei einem Besuch auf dem Gostenhofener Weihnachtsmarkt GoHo Hoho und unserem schon traditionellen Weihnachtsessen (diesmal gab es Hotpot) auf all die Ereignisse dieses Jahres zurückgeblickt und auf das Erreichte angestoßen!

Was haben wir für 2026 geplant?

Wir freuen uns auf das Jahr 2026!

Wir wünschen unseren Kunden, Partnern und Mitarbeitern frohe Festtage und einen guten Rutsch! Euer Team der masoona!

Der Beitrag Frohe Festtage und einen guten Rutsch! erschien zuerst auf Masoona Consulting.

Christian, herzlichen willkommen bei masoona!

Wir freuen uns einen neuen Mitarbeiter bei uns begrüßen zu können: Christian Piegert verstärkt unser Team seit dem 10.11. Christian bringt langjährige Erfahrung im Prozessmanagement, in der Business Analyse, im Projektmanagement und in der Konzeptionierung und strategischen Positionierung von Digitalisierungsvorhaben mit. Wir wünschen einen guten Start und viel Erfolg bei der masoona!

Du suchst einen neuen Job? Dann bewirb dich bei uns – wir wollen unser Team weiter verstärken: masoona.de/karriere

Der Beitrag Christian, herzlich willkommen bei masoona! erschien zuerst auf Masoona Consulting.

Camunda 7 Community Edition (CE) End of Life

Was tun, was sind die Alternativen?

Einleitung

In unserem DigiLAB nutzen wir mehrere Business Process Management-Plattformen (BPM-Plattformen) zu Demonstrations- und Übungszwecken. Dazu gehört neben anderen auch eine Plattform, die auf dem Toolstack von Camunda 7 Community Edition (CE) basiert. Wir verwenden sie insbesondere um die Vor- und Nachteile offener Architekturen mit lose gekoppelten Komponenten, den Best of Breed- und den Better-Coding-Ansatz der Prozessdigitalisierung und -automatisierung zu demonstrieren. Camunda 7 vereint eine hohe Performance der Engines mit einer offenen Architektur, bereitgestellt als Open Source. Die BPM-Plattform umfasst eine Prozess- und eine Entscheidungsengine, eine Tasklist mit Basisfunktionalität für die Aufgabenverwaltung sowie das Camunda Cockpit zur Administration und Überwachung von Prozessinstanzen. Camunda Optimize – ein Tool zur Erhebung und Analyse von Prozesskennzahlen bleibt hingegen der Enterprise Edition vorbehalten, ebenso wie einige Funktionen des Cockpits¹.

Mit Camunda 8 ist eine neue Plattform verfügbar, die perspektivisch Camunda 7 ablösen wird. Der Support der Community Edition von Camunda 7 wird bereits im Oktober 2025 mit Camunda Version 7.24 enden. Danach werden für die Community Edition weder funktionale noch Sicherheitsupdates bereitgestellt. Für die Enterprise Edition wird Camunda gemäß der aktuellen Roadmap noch bis April 2030 vollen Support bieten, im April 2032 endet dann auch der erweiterte Support. Ab Oktober gibt es aber auch für die Enterprise Edition nur noch Sicherheitsupdates für kritische Bugs und die Kompatibilität mit den Laufzeitumgebungen wird gewährleistet. Funktionale Updates wird es nicht mehr geben.²

Grund genug uns einmal Alternativen anzuschauen, sie zu analysieren und für uns zu bewerten.

Alternativen und ihre Vor- und Nachteile im Überblick

Was kann also getan werden, wenn aktuell Camunda 7 CE eingesetzt wird und die BPM-Plattform nicht ohne Support seitens des Anbieters weiter betrieben werden soll? Die nachfolgende Tabelle zeigt die Alternativen:

Unsere Migration

In einem ersten Schritt haben wir die Migration auf einen Fork von Camunda 7 getestet, da es unser Ziel ist, mit der Plattform unsere Architektur und den Best of Breed- sowie den Better Coding-Ansatz für die Digitalisierung und Automatisierung von Prozessen zu demonstrieren. Dabei haben wir uns für die Plattform CIB seven entschieden – aus mehreren Gründen:

1. Die Plattform ist bereits in Version 1.1.0 öffentlich verfügbar. Die CIB stellt Maven Dependencies, eine ausführliche Dokumentation sowie Migrationsskripte zur Verfügung. Die Plattform ist Open Source.
2. Die CIB hat eine klare Roadmap für die Bereitstellung und die Weiterentwicklung der Plattform.
3. Die Plattform kann mit der Lösung CIB seven EE oder CIB flow kombiniert werden. CIB seven EE stellt analog zu Camunda 7 EE die Enterprise Feature inkl. Optimize und Long Term Support bereit. CIB flow ermöglicht den Einsatz von Low Code bei der Automatisierung von Prozessen in Ergänzung zum Better Coding-Ansatz.

Unser DigiLAB Workflow Management System ist modular aufgebaut. Die Prozess- und die Entscheidungsengine sind in einer als “ProcessApp” bezeichneten eigenständigen Komponente gekapselt. Diese Komponente besitzt Dependencies zu Camunda 7, die wir durch die entsprechenden Dependencies zu CIB seven ausgetauscht haben. Mit Suchen und Ersetzen ging das ebenso wie die Aktualisierung der Importe sehr schnell. Die bereitgestellten Migrationsskripte⁷ haben wir dafür gar nicht benötigt, sie sind aber sicher bei komplexen Applikationen sehr nützlich. Vor der Migration haben wir unser System noch auf die Version 7.22 von Camunda CE gehoben.

Wir benutzen das Camunda Community Keycloak-Plugin von Gunnar van der Beck, accso⁸. Das Plugin setzt auf der Camunda 7 Plattform auf und ist daher zunächst nicht mit CIB seven kompatibel. Aber auch hier ist die Migration schnell erledigt – im ersten Schritt und zu Testzwecken haben wir hier unseren eigenen Fork erstellt, die notwendigen Anpassungen an den Dependencies und Importen vorgenommen und als lokale Dependency für unsere Entwicklungsumgebungen bereitgestellt. Die CIB ist dabei, eine eigene Community für die Entwicklung und Pflege von Plugins aufzubauen. Inwiefern dann Migrationen von Plugins der Community auf CIB seven erfolgen bleibt abzuwarten, stellt aber sicher einen wichtigen Erfolgsfaktor dar.

Unsere ProcessApp haben wir anschließend als Container in unsere BPM-Plattform eingebunden und können nun wahlweise Camunda 7.22 CE oder CIB seven 1.1.0 verwenden – je nach Bedarf aktivieren wir den einen oder den anderen Container. Unsere Workflows sind in beiden Umgebungen uneingeschränkt lauffähig. Für die Administration und die Überwachung der Workflows verwenden wir weiterhin die Camunda Webapps Admin und Cockpit in einer eigenen gekapselten Komponente. Pendants von CIB seven stehen hier in der aktuellen Version 1.1.0 noch nicht zur Verfügung. Dies soll sich aber mit der Version 2.0 ändern. Wir sind gespannt.

Ausblick

Es stehen verschiedene Möglichkeiten zur Verfügung, dem Ende des Lebenszyklusses von Camunda 7 CE zu begegnen. Mit unserer Camunda- bzw. zukünftig auch CIB seven basierten BPM-Plattform wollen wir dessen offene Architektur verbunden mit dem Best of Breed- und dem Better Coding-Ansatz als eine Alternative für den Einsatz von BPM-Plattformen weiter verfolgen. Für andere Ansätze, bspw. einer stärker integrierten BPM-Plattform mit Komponenten aus einer Hand, nutzen wir die Produkte anderer Anbieter. Und so ist auch unser Zwischen-Fazit: CIB seven oder andere Forks sind für die Zukunft interessant, wenn der Philosophie von Camunda 7 CE treu geblieben und die Zukunftssicherheit des eigenen Systems mit geringen Migrationsaufwänden erhalten werden soll. Die Migration auf CIB seven 1.1.0 ist einfach und problemlos möglich – ggf. zunächst auch einfach mal zu Testzwecken.

Wie stehen Sie zu den Alternativen – sehen Sie ggf. weitere? Wenn Sie sich mit uns zu diesem Thema austauschen wollen – kommen Sie auf uns zu. Gerne diskutieren wir Ihre Fragen und Probleme hands on in unserem DigiLAB.

1. Zu den Unterschieden zwischen Camunda 7 Community Edition und Enterprise vgl. auch Camunda 7 Editions . Abruf am 25.04.2025 ︎
2. Support Announcements, Support Announcements | docs.camunda.org. Abruf am 15.04.2025 ︎
3. Zum Preismodell von Camunda 8 vgl. Preise. Abruf am 23.04.2025 ︎
4. CIB seven: CIB seven Open Source Camunda 7 Alternative – Migration. Abruf am 22.04.2025 ︎
5. Operaton: Operaton – Operaton. Abruf am 22.04.2025 ︎
6. Eximee BPMS: New stable open source Camunda 7 alternative | EximeeBPMS. Abruf am 25.04.2025 ︎
7. Migrationsskripte für die Migration auf CIB seven: GitHub – cibseven/cibseven-migration: Migration project from Camunda 7.22 to CIB seven 1.1, based on OpenRewrite. Abruf am 22.04.2025 ︎
8. Camunda Community Keycloak-Plugin: GitHub – camunda-community-hub/camunda-platform-7-keycloak: Camunda Keycloak Identity Provider Plugin. Abruf am 22.04.2025 ︎

Der Beitrag Camunda 7 Community Edition (CE) End of Life – Was tun, was sind die Alternativen? erschien zuerst auf Masoona Consulting.

Workflows oder Cases?

Wann setze ich welches Konzept ein

Einleitung

Die Digitalisierung und Automatisierung von Prozessen sind kritische Erfolgsfaktoren für die erfolgreiche Bewältigung der digitalen Transformation von Organisationen. Prozesse übernehmen Eingaben aus ihrer Umwelt und transformieren diese zielgerichtet mittels Aktivitäten in Outputs. Klassischerweise wird dabei angenommen, dass die Ablaufreihenfolge von Aktivitäten vor der Ausführung der Prozesse (zur sogenannten Buildtime) bestimmbar ist und spezifiziert werden kann. Dieser Typ von Prozessen wird auch als “strukturiert” bezeichnet. Im Ergebnis der Digitalisierung und Automatisierung dieser Prozesse entstehen Workflows. Nicht immer jedoch können die Ablaufreihenfolgen auch wirklich zur Buildtime bestimmt werden – wir sprechen dann von unstrukturierten Prozessen.

In diesem Beitrag beleuchten wir zwei Konzepte zur Digitalisierung von Prozessen und stellen sie einnander gegenüber: Workflows und Cases. Im Gegensatz zur Workflows dienen Cases der Digitalisierung und Automatisierung unstrukturierter Prozesse. Wir gehen zudem der Frage nach, wie Workflows und Cases zur Digitalisierung von Prozessen miteinander kombiniert und Workflows iterativ aus Cases heraus entwickelt werden können.

Workflows

Sind die Ablaufreihenfolgen von Aktivitäten bekannt bzw. können diese zur Buildtime von digitalen Prozesse ermittelt werden (strukturierte Prozesse), so können Prozesse als Workflows digitalisiert und so die Ablaufreihenfolge von Aktivitäten automatisiert werden. Mögliche Ablaufreihenfolgen von Aktivitäten werden dabei mit Hilfe einer grafische Workflowbeschreibungssprache, wie bspw. der Business Process Model and Notation (BPMN) der Object Management Group (OMG)¹, festgelegt. Entscheidungen, welcher Pfad zu wählen ist, können dabei auf unterschiedliche Arten getroffen werden:

Cases

Sind die möglichen Ablaufreihenfolgen von Aktivitäten zur Buildtime hingegen nicht bekannt oder der Aufwand zu deren Ermittlung sehr hoch (unstrukturierte Prozesse), so können diese nicht a priori beschrieben werden und zur Laufzeit automatisiert eine Reihenfolge gewählt werden. Dennoch ist es auch in diesen Fällen möglich, einen Prozess Ende-zu-Ende zu digitalisieren. Cases, deutsch auch Fälle genannt, stellen eine Alternative zu Workflows dar. Bei der Spezifikation von Cases zur Buildtime werden zwar die Aktivitäten analog zu Workflows modelliert, die Ablaufbeziehungen jedoch nicht oder nur teilweise. Hier bleibt es zur Runtime eines Cases den Prozessbeteiligten überlassen, die jeweils nächste Aktivität auszuwählen und zu starten. Dies bedingt das entsprechende prozedurale Wissen bei den Prozessbeteiligten, dafür sind jedoch die Freiheitsgrade bei der Festlegung einer konkreten Reihenfolge für einen Fall sehr viel größer. Beispiele für diese Art von Prozessen sind wissensintensive Prozesse, bei denen explorativ mehr und mehr über den konkreten Fall gelernt wird, wenn dieser bearbeitet wird. Auf Basis des erworbenen Wissens und des bereits vorhandenen Wissens aus anderen Fällen werden von den Prozessbeteiligten die jeweils nächsten Aktivitäten ausgewählt. Die Bereitstellung, die kontinuierliche Verbesserung und die adäquate Unterstützung der Fallbearbeitung mit IT-Systemen wird als Adaptive Case Management bezeichnet^2,3.

Für die Modellierung von Cases zur Buildtime und deren Ausführung zur Runtime steht ebenso wie für Workflows eine Notation zur Verfügung – die Case Management Model and Notation (CMMN) der OMG⁴. Für die Ausführung werden Case Engines verwendet. Alternativ, aber verbunden mit Einschränkungen, können hier auch ad hoc- oder Ereignis-Teilprozesse der BPMN verwendet werden.

Dennoch ist es auch mit Cases möglich, Ablaufreihenfolgen zwischen Aktivitäten zur Buildtime zu spezifizieren bzw. die Freiheitsgrade bei der Auswahl von konkreten Ablaufreihenfolgen durch Casebeteiligte zur Runtime einzuschränken. In Abhängigkeit vom Zustand eines Cases können gewisse Aktivitäten ausgeführt werden, andere jedoch nicht. Auch kann bspw. festgelegt werden, dass gewisse Aktivitäten ausgeführt werden müssen.

Kombination und Transformation

Beide Ansätze des Digitalisierung von Prozessen können miteinander kombiniert werden. Mehrere Anwendungsfälle sind dabei möglich:

Prozesse können in einem Digitalisierungsprojekt zunächst nur als unstrukturierte Prozesse digitalisiert werden. Grund ist, dass die Analyse der Ablaufreihenfolgen von Aktivitäten sehr aufwändig und zeitintensiv sowie mit großen Unsicherheiten behaftet, insbesondere bzgl. der Häufigkeit genutzter Pfade, sein kann. Das Minimum Viable Product (MVP) besteht dann zunächst nur aus Cases, bei denen die Prozessbeteiligten ihr Wissen nutzen müssen, um Aktivitäten in der richtigen Reihenfolge zu starten. Die tatsächlichen Ablaufreihenfolgen werden dann im Zuge aus den Casebearbeitungen durch die Prozessbeteiligten zur Runtime ermittelt und wo wirtschaftlich oder zur Verbesserung der Qualität sinnvoll werden die Cases iterativ in Workflows transformiert. Die Transformation von Cases in Worflows werden wir in einem weiteren Beitrag beleuchten.

Fazit

Für beide Arten von Prozessen – strukturierte und unstrukturierte – stehen Konzepte für deren Digitalisierung inkl. der hierfür benötigten Notationen und Plattformen zu deren Ausführung bereit. Beide Konzepte können zudem miteinander kombiniert werden. Durch gezielten Verzicht auf die Spezifikation von Ablaufbeziehungen zwischen Aktivitäten bei einer Prozessdigitalisierung kann zudem die Zeit bis zum ersten digitalen MVP verkürzt werden. Eine nachträgliche Transformation in einen Workflow kann dann sukzessive erfolgen um manuelle Aufwände in der Bearbeitung zu reduzieren.

So ist abschließend festzuhalten, dass es sich Workflows und Cases nicht gegenseitig ausschließen, wie der Titel des Beitrags ein wenig suggeriert. Vielmehr ergänzen sich beide und bedienen spezifische Anwendungsfälle bei der Digitalisierung von Prozessen.

Haben wir Ihr Interesse geweckt? Schauen Sie doch bei uns in unserem DigiLAB vorbei. Wir halten hier für Sie spannende Angebote bereit, mit denen Sie in die Welt der Workflows und der Cases eintauchen können:

1. Zur BPMN vgl. auch die Spezifikation der Object Management Group: About the Case Management Model and Notation Specification Version 1.1 . Abruf am 08.01.2025 ︎
2. Dr. Michael Jacob, Patrick Dohrmann: “Digitalisierung von Prozessen – Ein Lösungsansatz für das Prozessmanagement”. Veröffentlicht in “Der Prozessmanager”, 2019 ︎
3. BITKOM: “Adaptive-Case-Management” – Leitfaden und Nachschlagewerk. BITKOM, 2013 ︎
4. Zur CMMN vgl. auch die Spezifikation der Object Management Group: About the Case Management Model and Notation Specification Version 1.1 . Abruf am 08.01.2025 ︎

Der Beitrag Workflows oder Cases? Wann setze ich welches Konzept ein erschien zuerst auf Masoona Consulting.

Frohe Festtage und einen guten Rutsch!

2024 war für uns bei masoona ein aufregendes Jahr voller Herausforderungen und Erfolge:

Im Jahr 2024 standen aber auch schwierige Diskussionen und Entscheidungen an. Diese haben viel Kraft und Zeit gekostet, waren aber notwendig, um den langfristigen Erfolg der masoona zu sichern.

Und so haben wir bei unserem Weihnachtsessen auf all die Ereignisse zurückgeblickt und auf das Erreichte angestoßen – gemeinsam mit unseren Familien und Partnern. Diese sind für uns eine wichtige Stütze bei der täglichen Arbeit und so gilt ihnen ein großes Dankeschön.

Was haben wir für 2025 geplant?

Seid gespannt auf 2025!

Wir wünschen unseren Kunden, Partnern und Mitarbeitern frohe Festtage und einen guten Rutsch!

Der Beitrag Frohe Festtage und einen guten Rutsch! erschien zuerst auf Masoona Consulting.

Dem Backlog Item und seinen Akzeptanzkriterien treu sein

Ich beobachte häufig, dass Backlog Items im Sprint nicht fertig werden. Betrachtet man im Nachgang die Schätzungen im Verhältnis zur Umsetzung und befragt das Team, ob sie die Schätzung noch mal so machen würden, stellt man fest: „Wenn wir nur das gemacht hätten, was in dem Item steht, hätte die Schätzung schon hingehauen.“ Kleinigkeiten hier und da zu ergänzen oder noch mal was zu refactoren, kostet am Ende mehr Zeit, als man denkt. Teilweise verliert man sich in Details und Edge Cases. Währenddessen warten andere für den Sprint vorgesehene Items sehnsüchtig auf ihre Umsetzung.

Gut geschriebene Backlog Items sind unerlässlich

Ein häufiger Grund ist die unzureichende Beschreibung der Backlog Items. Wie detailliert und präzise beschrieben das Backlog Item sein muss, ist abhängig vom Team und dessen Lernprozess dazu. Selbstverständlich ist es unabdingbar, den Nutzen des Backlog Items zu formulieren, sodass die Erarbeitung der Akzeptanzkriterien wesentlich einfacher fällt. 

Dazu eignet sich hervorragend das sogenannte Connextra Template. Das Schema “Als (Persona/Anwenderrolle) brauche ich (Funktion), um/damit (Nutzen).” Damit ist nachvollziehbar, für wen, was wozu entwickelt werden soll. Zur Beschreibung der sich daraus ableitenden Akzeptanzkriterien kann man sich an den INVEST-Kriterien orientieren (s. Wikipedia). 

Man kann sich immer fragen: “Was wird benötigt, um den Nutzen für den Anwender zu erreichen?“. Ich plädiere hier vor allem am Anfang dieses Lernprozesses für „Mehr ist mehr“. Das Team sollte lieber ein Akzeptanzkriterium mehr als zu wenig erfassen. Und warum beschreibt man nicht mal das, was man nicht machen möchte? So wird die Aufgabe klar von weiteren Backlog Items abgegrenzt und es wird verhindert, dass man mehr umsetzt, als das Backlog Item vorsieht.

Dem Backlog Item treu sein

Nachdem das Backlog Item gut beschrieben ist und vom Team als „ready“ eingestuft wurde, muss das Bewusstsein geschärft werden, sich an dessen Inhalt zu halten. Ein Backlog Item sollte grundsätzlich immer als unveränderlich im Sprint behandelt werden. Vermutlich könnten einige nun sagen: „Das ist doch nicht agil! Alles kann sich jederzeit verändern und man muss darauf reagieren!“ 

Das Team hat sich zusammen auf einen Plan für den Sprint festgelegt. Wenn die Items währenddessen einfach geändert werden, kann man nicht mehr einschätzen, welcher Mehrwert in dem Sprint geliefert wird. Das kann negative Konsequenzen auf zugesicherte Liefertermine haben. 

Folgende Fragen sollte man sich stellen, wenn während der Umsetzung von der Anforderung abgewichen wird: Hat sich die Kundenanforderung geändert? Ist diese Mehrarbeit wirklich wertsteigernd? Muss die Mehrarbeit genau jetzt getan werden, oder reicht es auch, sie später umzusetzen? Wer bezahlt die kleinen Extras, die wir jetzt zusätzlich machen? Das ist natürlich nur eine Auswahl an möglichen Fragestellungen und Problemen, die auftreten können. 

Sofern auf diese Fragen keine zufriedenstellende Antwort gefunden wird, dann muss die Mehrarbeit vermieden werden. Andernfalls kann mit dem Product Owner oder im ganzen Team darüber gesprochen werden, um zu entscheiden, was passieren soll. Es ist immer möglich, während der Entwicklung im Sprint gewonnene Erkenntnisse in neue Backlog Items zu gießen, die zur Wertsteigerung des Produktes beitragen oder aufgrund von technischer Notwendigkeit entstehen.

Verlässlichkeit durch genaue Vorhersagen der Umsetzungen

Wenn man sich an das oben beschriebene hält, und nur das, was im Backlog Item formuliert ist, umsetzt, dann ist die Schätzung eines Backlog Items brauchbar. Es ist ungemein hilfreich für die Auswertung einer Velocity und das Planen von Releases, verlässliche Zahlen zu haben. So kann man dem Kunden letztendlich das liefern, was ihm zugesichert wurde. Zuverlässige Lieferung und ein qualitativ hochwertiges Produkt sind die Basis für eine vertrauensvolle und produktive Zusammenarbeit mit den Kunden.

von Carolin Neufert

Der Beitrag Dem Backlog Item und seinen Akzeptanzkriterien treu sein erschien zuerst auf Masoona Consulting.

Vom Fachprozess zum initialen Backlog

Sind fachliche Prozessmodelle vorhanden, können diese für das agile Anforderungsmanagement bei der Digitalisierung und Automatisierung von Prozessen genutzt werden. Wie? Das erklären wir in diesem Blogbeitrag.

Digitalisierung von Prozessen anhand von Prozesspfaden

Soll ein Prozess digitalisiert werden, stellt sich oft die Frage: Wo fangen wir mit der Digitalisierung an? Was sind die ersten Epics und Stories? Eine mögliche Antwort kann unter Nutzung des fachlichen Prozessmodells, sofern es vorhanden ist, erarbeitet werden. Ein Prozess ist eine Abfolge von Aufgaben, die in einer bestimmten Reihenfolge in einem Prozessdurchlauf abgearbeitet werden. Die Ablaufreihenfolgen von Aufgaben sind nicht beliebig. Sie werden zu Wegen, i.d.R. als Pfade bezeichnet, aggregiert. Der am häufigsten durchlaufene Pfad wird als Happy Path bezeichnet. Dabei hat “happy” hier nicht unbedingt etwas mit einem “positiven” Prozessergebnis zu tun, es ist einfach nur der am häufigsten durchlaufene Pfad.

Diesen Pfad als erstes zu digitalisieren verspricht i.d.R. den größten Nutzen. Dabei sollte der Pfad von Anfang bis Ende digitalisiert werden, damit er von den Prozessbeteiligten vollständig und ohne App-Wechsel bearbeitet werden kann. Im ersten Schritt kann hierfür die Automatisierung von Aufgaben vernachlässigt werden. So können bspw. Prüfungen anhand von Daten oder Dokumenten zunächst von den Prozessbeteiligten manuell durchgeführt werden, bevor diese dann in einem weiteren Schritt automatisiert werden. Auch sollten nur die wichtigsten Aufgaben digitalisiert werden, der Ablauf also so einfach wie möglich gestaltet werden. In der obigen Abbildung ist hierfür ein minimaler Ablauf für die Durchführung einer Dienstreise inkl. deren Ablehnung, also deren “Nicht-Durchführung”, dargestellt. In der weiteren Prozessanalyse können diese Aufgaben dann weiter detailliert und ggf. auch neue Aufgaben identifiziert werden.

Epics und Stories prozessorientiert schneiden

Selbst die initiale Digitalisierung eines Happy Path ist aufgrund des Umfangs meist nicht mit einer Story zu schaffen, da diese dann zu groß wird. Es bietet sich daher an, ein Epic zu erstellen und alle Stories, die der initialen Digitalisierung des Happy Path dienen, in diesem Epic zusammenzufassen. Im Beispiel der Dienstreise wurden so zwei Epics erstellt: 1) Dienstreise durchführen oder nicht durchführen und 2) Antrag überarbeiten. Eine Aufspaltung des ersten Epics bzgl. der Durchführung (oberer und unterer Pfad) macht hier keinen Sinn, da für den Pfad der Ablehnung zum aktuellen Zeitpunkt keine weiteren Aufgaben vorgesehen sind.

Bei der initialen Digitalisierung von Pfaden kann es sinnvoll sein, die Aufgaben zunächst nicht zu detailliert abzubilden, um möglichst schnell eine Digitalisierung eines Pfades von dessen Beginn bis zu seinem Ende zu erreichen. Analog kann für die weiteren Pfade im Prozessmodell vorgegangen werden. Vor jeder Pfaddigitalisierung sind jedoch Aufwand und Nutzen abzuwägen. Selten durchlaufene Pfade können ggf. ganz entfallen und werden nicht digitalisiert. Die folgende Abbildung zeigt ein mögliches initiales Backlog für die Digitalisierung des Reiseantrags. Aus Sicht eines Minimum Viable Product (MVP) macht die Umsetzung dieser beiden Pfade Sinn – ohne Ablehnung ist das Produkt unvollständig. Die Überarbeitung von Anträgen könnte dagegen im MVP zunächst weggelassen werden und der Antrag stattdessen abgelehnt und neu gestellt werden.

Vorteile

Die Vorteile dieses Vorgehens sind vielfältig. Pfade werden von Anfang bis Ende digitalisiert und Medienbrüche schnell beseitigt bzw. sogar vermieden. Die Digitalisierung erfolgt nutzenorientiert und in nachvollziehbaren Schritten, die sich am i.d.R. gut kommunizierbaren fachlichen Prozessmodell orientieren. Sowohl Vorgehen als auch Digitalisierungsfortschritt sind somit für alle Beteiligten transparent. Ist ein Pfad initial digitalisiert, können für ihn Key Performance Indicator (KPIs), bspw. Durchlaufzeiten von Prozessinstanzen oder Bearbeitungszeiten von Aufgaben, vollständig erhoben werden. So kann die Prozesssteuerung schnell verbessert und wertvolle Informationen für die weitere Digitalisierung, insbesondere aber auch für die Automatisierung gewonnen werden. Mit KPIs kann bspw. die Frage beantwortet werden, welche manuellen Tätigkeiten denn tatsächlich besonders lang dauern.

Unsere Leistungen

Stellen Sie aktuell Überlegungen an, wie Sie das Backlog für Ihre zu digitalisierenden Prozesse aufbauen? Gerne beraten wir Sie hierbei bspw. mit einem Check Ihrer Fachprozesse oder Ihres bereits initial erstellten Backlogs. Den Aufbau eines Backlogs können Sie mit uns gemeinsam in unserem DigiLAB verproben.

von Michael Jacob und Carolin Neufert

Der Beitrag Vom Fachprozess zum initialen Backlog erschien zuerst auf Masoona Consulting.

Reviews vorbereiten: Weniger ist mehr

Wie viel Zeit investiert ihr in die Vorbereitung eures Reviews? Erstellt ihr zu jedem Ticket eures Boards Folien und Bildchen oder Diagramme? Habt ihr schon mal ein ROTI (return on time invested) zur Review-Vorbereitung gemacht? Sprich, ob sich die Zeit, die ihr in die Vorbereitung investiert habt, beim Review durch entsprechenden Output oder Outcome bezahlt gemacht hat?

Während des Reviews geht es darum, Feedback der Stakeholder einzuholen und mit ihnen über das Produkt und dessen Weiterentwicklung zu sprechen. Dieses Ziel sollte das Team im Blick behalten und Reviews mit Pragmatismus darauf ausrichten. Zudem zeigt meine Erfahrung, dass auch hier das Prinzip “keep it simple” oder “weniger ist mehr” sehr nützlich ist. Daher appelliere ich regelmäßig an die Teams, dass sie sich bei der Vorbereitung des Reviews auf das Nötigste beschränken und sich nicht in Folien, Formulierungen und Darstellungen verkünsteln.

Was müssen wir für ein Review vorbereiten? Einleitend kann eine Übersicht der Themen als Agenda auf einer Folie helfen. Ansonsten sollte der Fokus darauf liegen, das Produkt zu demonstrieren und den Austausch zwischen Team und Stakeholdern anzukurbeln. Das funktioniert nicht so gut, wenn sich hauptsächlich an Folien entlang gehangelt wird, statt zusammen auf das Produkt zu schauen. Neben dem Produkt können hier auch weitere ohnehin vorhandene Entwicklungsartefakte wie bspw. Prozessmodelle zum Einsatz kommen. Somit lässt sich die Vorbereitungszeit eines Reviews unter Umständen drastisch kürzen, denn wir brauchen nur noch eine Übersicht der Themen und müssen im Team klären, wer was wann demonstriert und welche technischen Voraussetzungen für die Demo erfüllt sein müssen.

Weiterhin muss im Blick behalten werden, dass alle Stakeholder zum Review eingeladen werden. Es ist durchaus sinnvoll, die Liste der Teilnehmer regelmäßig zu prüfen, so dass ggf. neue Interessenten eingeladen werden könnten.

Die Zeit, die mit formaler Vorbereitung gespart wird, kann man z.B. in die Qualitätssicherung des Produktes investieren oder in die Vorbereitung des nächsten Plannings. Denn sind wir mal ehrlich: Wollte diese Folien schon jemals jemand im Nachhinein sehen? Vermutlich nie bis selten. Investiert eure Zeit in das, was tatsächlich Mehrwert liefert und das Produkt vorwärts bringt. PowerPoint Folien sieht der Kunde nicht. 

von Carolin Neufert

Der Beitrag Reviews vorbereiten: Weniger ist mehr erschien zuerst auf Masoona Consulting.

Neue Partnerschaft mit der Business Process Automation Platform Flowable

Die Business Process Automation-Plattform (BPA) Flowable und masoona haben eine Partnerschaft geschlossen.

Flowable ist eine Low-Code-Plattform für die Digitalisierung und Automatisierung von Prozessen. Die Plattform bietet aufgrund ihrer Offenheit und Skalierbarkeit beste Voraussetzungen, um flexibel an individuelle Geschäfts- und Kundenerwartungen angepasst zu werden. 

masoona verfolgt in ihren Projekten immer das Ziel, möglichst schnell und ressourcenschonend ein erstes digitales Produkt live zu setzen. Dieses Vorgehen unterstützen der Low-Code-Ansatz von Flowable und die Integration von Case-Management in der Plattform. Prozesse können so von einfachen Workflows mit zunächst wenig Ablauflogik über mehrere Stufen hinweg zu immer feingranulareren detaillierten Workflows mit höherem Automatisierungsgrad entwickelt werden. Die einfache Anbindung externer Systeme ermöglicht es zudem, auch Aufgaben in Prozessen schnell und einfach zu automatisieren.

Mit unseren Erfahrungen in der Digitalisierung und Automatisierung von Prozessen bietet masoona zusammen mit Flowable alles Nötige, um Ihre Journey zu Ihren digitalen Prozessen Wirklichkeit werden zu lassen. Beginnend mit der Prozessidentifikation, über die Erhebung bis hin zur Implementierung von digitalen Prozessen und auch auch bei den begleitenden Aktivitäten wie Projekt- und Programmmanagement, der Fortschreibung Ihrer Fach- und IT-Architekturen sowie der Einführung neuer Technologien unterstützen wir Sie gerne. 

Wir freuen uns auf die Zusammenarbeit mit unserem neuen Partner in vielen spannenden Projekten in den nächsten Jahren! Weitere Informationen zu Flowable finden Sie hier: https://www.flowable.com/. Anbei finden Sie auch unseren OnePager für die schnelle Digitalisierung von Prozessen.

Sie wollen hands on die Digitalisierung von Prozessen erleben? Schauen Sie in unserem DigiLAB oder ProcessLAB vorbei. Gerne gestalten wir mit Ihnen gemeinsam prototypisch Ihren ersten digitalen Prozess und setzen ihn zusammen mit Ihnen auch digital um. 

Der Beitrag Neue Partnerschaft mit der Business Process Automation Platform Flowable erschien zuerst auf Masoona Consulting.

Sprint Planning: Priorisiere dein Sprint Backlog

Angenommen, unser Backlog ist gepflegt und priorisiert und das Planning gut vorbereitet. Im Planning wird dann zwischen Product Owner und Entwicklungsteam besprochen, was in den nächsten Sprint mitgenommen wird. Daraus ergeben sich das Sprintziel und die zu implementierenden Backlog Items. 

Warum passiert es dennoch so häufig, dass wir unser Sprintziel, auf das wir uns so eifrig committed haben, verfehlen? Ein Grund könnte sein, dass wir das Sprint Planning mit einer unsortierten Liste an Backlog Items beenden. Die Abarbeitung der Items verläuft dann nicht zwingend von oben nach unten ab, das Entwicklungsteam bearbeitet die aus ihrer Sicht „spannendsten“ Themen zuerst.

Eine Lösungsidee

Das Sprint Backlog sollte sich wie das Product Backlog verhalten. Beispielsweise lassen sich folgende Punkte sehr gut zur Bewertung der Wichtigkeit eines Items heranziehen: Value, Komplexität, Abhängigkeit und Testaufwand. 

• Value: Gibt es ein Kernfeature in diesem Sprint? Worauf wird sich der Kunde am meisten freuen, nach was sehnt er sich am meisten? Was bringt meinem Produkt die größte Wertsteigerung (durch den glücklichen Kunden)?
• Komplexität: Welches Item ist am komplexesten umzusetzen und bedeutet den meisten Aufwand und Gehirnschmalz? In welchem Item sehen wir das größte Risiko bei der Umsetzung? Bei welchem Item benötigen wir vermutlich länger zur technischen Einarbeitung? Welche Kleinigkeiten können wir für das Sprintende aufheben, um wenig Story Punkte zu verlieren, falls wir uns verplant haben?
• Abhängigkeiten: Sind wir bei der Umsetzung abhängig von anderen? Sind andere von diesem Item abhängig? Zugegeben, schlechte Lage, manchmal aber nicht vermeidbar, vor allem, wenn man teamübergreifend an einer Schnittstelle arbeitet. Sind andere von uns abhängig, sollten wir sicherstellen, auch fristgerecht zu liefern, das heißt, das Item mit als erstes fertigzustellen. 
• Testaufwand: Oft erleben wir es, dass Tester*innen vernachlässigt werden und erst ganz am Schluss eines Sprints ihre Tests durchführen und anpassen können. Wichtig beim Planning ist es, die Tester*innen zu involvieren und zu wissen, bei welchen Items sie die größten Testaufwände sehen, für die mehr Zeit benötigt wird. 

Investiert 5 Minuten in eure Sprint Backlog Priorisierung

Wenn wir wissen, welche Items uns am wichtigsten sind, fokussieren wir uns auf diese und es tut uns am Sprintende weniger weh, falls wir doch mal was liegen lassen müssen – vorausgesetzt, dass wir diese sortierte Liste im Sprint von oben nach unten abarbeiten. Zudem sollte damit das Sprintziel nicht in Gefahr sein, da alle dem Sprintziel zuträglichen Items hoch priorisiert sind. Das hilft uns schlussendlich ein positives Erlebnis für uns und die Stakeholder im Review zu schaffen, eine verlässliche Velocity aufzubauen und den Product Owner in seinen planerischen Tätigkeiten zu unterstützen.

von Carolin Neufert

Der Beitrag Sprint Planning: Priorisiere dein Sprint Backlog erschien zuerst auf Masoona Consulting.