Das Anforderungsmanagement beschäftigt sich mit der systematischen Erfassung, Dokumentation und Verwaltung von Anforderungen an ein zu entwickelndes System. Ziel ist es, sicherzustellen, dass das entstehende Produkt den Bedürfnissen und Erwartungen der Stakeholder entspricht. Eine zentrale Disziplin innerhalb dieses Prozesses ist die Anforderungserhebung, also die strukturierte Sammlung und Formulierung von Anforderungen aus unterschiedlichen Quellen, wie bereits im Überblicksartikel erwähnt worden ist.

Für die erfolgreiche Anforderungserhebung sind mehrere Faktoren entscheidend: Einerseits muss eine möglichst vollständige Sammlung relevanter Informationen gewährleistet sein. Andererseits kommt es darauf an, die erhobenen Anforderungen klar und präzise zu formulieren, um spätere Missverständnisse und Implementierungsfehler zu vermeiden.

Vor diesem Hintergrund stellt sich die Frage, wie Generative KI die Anforderungserhebung unterstützen kann. Insbesondere interessiert, ob sie in der Lage ist, aus den heterogene Eingabedokumente Anforderungen abzuleiten und konsistent zu formulieren, um so Arbeitsaufwand für Requirements Engineers zu reduzieren.

Ausgangslage

Im untersuchten Szenario ist  ein fiktives Warenwirtschaftssystem als Beispiel herangezogen worden. Dieses umfasst drei Ebenen:

Als Eingaben dienen manuell erstellte, fiktive Dokumente wie Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme oder Mockups. Diese lagen in unterschiedlichen Formaten vor (z. B. DOCX, PNG, YAML, PDF). Die Dokumente sind einem generativen Sprachmodell (ChatGPT 4o) übergeben worden, um daraus Anforderungen in ein strukturiertes, auswertbares CSV-Format zu überführen.

Vorgehen

Um die Ergebnisse möglichst objektiv zu bewerten, werden die Ausgaben anhand definierter Kriterien untersucht. Zunächst erfolgt ein Abgleich der von ChatGPT erhobenen Anforderungen mit den manuell erhobenen Anforderungen. Anschließend wird die KI gebeten, identifizierte Schwächen zu korrigieren.

Vollständigkeit der Anforderungen

Die Vollständigkeit der durch die KI entdeckten Anforderungen wird mit einem Abgleich gegenüber zuvor händisch erhobenen Anforderungen erzielt. Dabei werden Abweichungen in der Formulierung oder ein gewisser Interpretationsspielraum toleriert, solange der Kerninhalt vergleichbar bleibt.

Sprache der Anforderungen

Ein weiterer Fokus liegt auf der sprachlichen Konsistenz der Anforderungen. Als Maßstab gilt eine Ähnlichkeit zwischen Anforderungspaaren, wenn für ein bestimmtes Konzept konsistent dieselben Begriffe verwendet werden. Abweichungen entstehen insbesondere dann, wenn die KI alternative Begriffe oder unspezifische Formulierungen einsetzt.

Ergebnisse

Die manuelle Erhebung ergibt insgesamt 72 Anforderungen. Die KI hat zunächst 40 Anforderungen extrahieren können, von denen 9 nicht korrekt aus den Quelldokumenten abgeleitet sind. Eine detaillierte Analyse ergibt mehrere Ursachen:

Im weiteren Verlauf zeigten sich Stärken und Schwächen in der Zusammenarbeit mit der KI:

Fazit

Das Experiment zeigt, dass Generative KI in der Anforderungserhebung ein wertvolles Assistenzwerkzeug sein kann, insbesondere bei:

Allerdings bestehen deutliche Einschränkungen:

Insgesamt lässt sich festhalten: ChatGPT und vergleichbare Modelle eignen sich weniger als autonome Anforderungserheber, sondern vielmehr als dialogorientierte Assistenten. Im Zusammenspiel mit menschlicher Expertise können sie das Requirements Engineering durch Strukturierung, Vorschläge und Validierung sinnvoll ergänzen, jedoch nicht ersetzen.

Der Beitrag Das Potenzial von generativer KI in der Anforderungserhebung – Teil 3 erschien zuerst auf Masoona Consulting.

Das Anforderungsmanagement ist eine zentrale Disziplin in der Softwareentwicklung. Es umfasst alle Aktivitäten, die notwendig sind, um Anforderungen an ein System systematisch zu erheben, zu dokumentieren, zu prüfen und im Entwicklungsprozess fortlaufend zu pflegen. Eine wesentliche Teildisziplin innerhalb des Anforderungsmanagements ist die Anforderungsanalyse.

Die Anforderungsanalyse hat das Ziel, die Bedürfnisse und Erwartungen der Stakeholder präzise zu erfassen und in verständliche, überprüfbare sowie konsistente Anforderungen zu überführen. Dabei spielen mehrere Faktoren eine Rolle: die Eindeutigkeit der Formulierungen, die Nachvollziehbarkeit der Prioritäten, die Vermeidung von Redundanzen sowie die klare Zuordnung zu Stakeholdern.

Im vorliegenden Beitrag – aus der Serie mehrerer Artikel – soll untersucht werden, wie generative KI, konkret ChatGPT, in der Anforderungsanalyse eingesetzt werden kann. Das Ziel ist es herauszufinden, in welchen Bereichen eine Unterstützung sinnvoll möglich ist, wo Grenzen bestehen und welche Schlüsse sich daraus für die zukünftige Praxis ziehen lassen.

Ausgangslage

Als Grundlage dient ein fiktives Beispielprojekt: Ein Warenwirtschaftssystem, bestehend aus

Als Eingabedaten stehen verschiedene Dokumente zur Verfügung, darunter Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme und Mockups. Diese liegen in heterogenen Dateiformaten wie .docx, .png, .yaml oder .pdf vor.

Die Dokumente werden an ChatGPT (Version 4o) übergeben. Als Ausgabe wird ein CSV-Format gewählt, das sowohl menschenlesbar als auch in gängigen Tabellentools weiterverarbeitbar ist.

Vorgehen

Um die Ergebnisse möglichst objektiv beurteilen zu können, erfolgt die Bewertung anhand nachstehender definierter Kriterien. In einem zweiten Schritt wird die KI gezielt mit den erkannten Schwächen konfrontiert und gebeten, Korrekturen vorzunehmen.

Bewertung der Relevanz

Die Relevanz von Anforderungen wird anhand zweier Kriterien überprüft:

1. Stakeholder-Zuordnung: Jede Anforderung sollte einer Interessengruppe zugeordnet sein. Bewertet wurde auf einer Skala von 0 (keine Angabe) bis 2 (korrekte Stakeholder-Angabe).
2. Einschätzung der Wichtigkeit: Dies umfasst sowohl die Priorisierung in Muss-, Soll-, Kann-Anforderungen.

Bewertung der Redundanz

Um Redundanzen zu identifizieren, werden die Anforderungen paarweise miteinander verglichen und bewertet. Die Bewertung geschieht anhand der nachstehenden Kategorisierung. Demnach können Anforderungen

sein.

Ergebnisse

Relevanzbewertung

Die korrekte Stakeholder-Zuordnung hat ChatGPT in 66 % der Fälle erreicht. Fehler sind insbesondere dadurch entstanden, dass

Nach einer Korrekturschleife sind diese Mängel behoben worden. Die KI hat Namen durch passende Rollen ersetzt und Stakeholder für Dokumente ergänzt, in denen diese nur indirekt zu erkennen gewesen sind, etwa bei Schnittstellenspezifikationen oder Mockups.

Die Bewertung der Priorität ist deutlich schwächer ausgefallen: Nur 51 % der Anforderungen sind korrekt priorisiert. Häufige Probleme sind:

Auch nach weiteren Korrekturanweisungen bleibt die Qualität unbefriedigend. Die KI hat meist nur die Prioritätsstufen geändert, ohne die Anforderungstexte sprachlich zu präzisieren.

Redundanzbewertung

Bei der Redundanzanalyse zeigen die von ChatGPT genrierten Anforderungen deutlich bessere Ergebnisse. Von 1.225 möglichen Anforderungspaaren werden

Funktional gleiche Anforderungen stammen häufig aus unterschiedlichen Quelldokumenten, und werden daher mehrfach aufgeführt, ohne das bei bestehenden Anforderungen eine weiter Quelle ergänzt worden ist. Die ähnlichen Anforderungen lassen sich darauf zurückführen, dass Anforderungen nicht atomar formuliert gewesen sind und Aufzählungen von Eigenschaften des Softwaresystems enthalten haben.

Eine erneute KI-gestützte Prüfung hat zehn redundante Anforderungskandidaten identifiziert, welche die Anzahl funktional gleicher Anforderungspaare gesenkt hat. Die durch die KI entdeckten Redundanzen decken sich mit einer manuellen Überprüfung der von der KI identifzierten Anforderungen. Die KI Unterstützung ist in diesem Fall zuverlässig gewesen.

Fazit

Die Untersuchung zeigt, dass der Einsatz generativer KI in der Anforderungsanalyse sowohl Chancen als auch Grenzen mit sich bringt:

Weiterführende Überlegungen

Neben den genannten Aspekten ergeben sich weitere Schlussfolgerungen:

Zusammenfassend lässt sich festhalten: ChatGPT ist ein nützlicher Begleiter in der Anforderungsanalyse, insbesondere bei der Redundanzprüfung und in der Unterstützung bei Stakeholder-Zuordnungen. Schwächen bestehen vor allem bei der Priorisierung, da diese nicht allein aus Dokumenten abgeleitet werden kann. Generative KI ersetzt die Expertise menschlicher Analyst:innen nicht, bietet jedoch wertvolle Unterstützung, indem sie Routineaufgaben automatisiert und erste Analysen beschleunigt.

Der Beitrag Das Potenzial von generativer KI in der Anforderungsanalyse – Teil 2 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.

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.

Prozessdigitalisierung und -automatisierung sind für viele Kunden ein strategischer Baustein zur digitalen Transformation der gesamten Organisation. Masoona Consulting begleitet seine Kunden auf dem gesamten Weg von der Digitalisierung einzelner Prozessschritte bis hin zur integrierten und gesamtheitlichen Ende-zu-Ende-Automatisierung ihrer Geschäftsprozesse.

Wir fokussieren uns mit unseren Kompetenzen im Kontext des Business/IT- Alignments auf die Konzeption und Steuerung der digitalen Transformation. Die konkrete Umsetzung gestalten wir gemeinsam mit dem Kunden und unter Einbezug von ausgewählten kompetenten Partnern.

Aus konkreten Kundensituationen bei Digitalisierungsvorhaben unserer Kunden in diversen Branchen haben wir aus der Vielzahl von großen und kleinen Herausforderungen vier herausgeschält, die für uns besonders herausstechen und bei deren Bewältigung wir unsere Kunden unterstützen wollen.

In diesem Beitrag werde ich zwei dieser strategischen Herausforderungen und unsere Erfahrungen beim Umgang mit ihnen vorstellen, zum einen die Adaption und Beherrschung innovativer Technologien, zum anderen die Evolution der Fach- und IT-Architektur im Zuge der Digitalisierung von Prozessen.

Für die Ende-zu-Ende-Automatisierung eines Kernprozesses ist ein komplexer Mix innovativer Technologien notwendig. Es ist normal, dass die eine oder andere Technologie, wie bspw. Robotic Process Automation, Decision Automation oder Artificial Intelligence, für ein Unternehmen oder eine Behörde “Neuland” darstellt und die Fähigkeit zum effizienten und zielgerichteten Einsatz einer solchen Technologie (noch) nicht vorhanden ist. Heutzutage bieten sich zwei hier zwei Alternativen zur Lösung des Problems an: Outsourcing an einen externen Dienstleister ist die eine (1), Internalisierung von Produkten und des zur ihrer Nutzung benötigten Wissens die andere (2). Bei haben ihre Vor- und Nachteile: Während die erste Alternative davon befreit, neue Technologien in der eigenen Organisation zu adaptieren (im Extremfall mit PaaS – Process as a Service), bietet die zweite größtmögliche Freiheit und Flexibilität beim Einsatz der Technologien bzw. der sie implementierenden Produkte zur Unterstützung der eigenen Prozesse.

Beide haben jedoch ihre spezifischen Voraussetzungen: Ohne eine eigene leistungsfähige IT und die Bereitschaft in Softwareentwicklung zu investieren lässt sich Variante zwei nicht umsetzen. Was wie eine Binsenweisheit klingt, erleben wir leider sehr häufig: Auf der einen Seite besteht der Wunsch möglichst flexibel zu agieren und natürlich nur die am besten passenden Produkte, im Extremfall Eigenentwicklungen, in der eigenen Organisation einzusetzen. An einer adäquaten langfristig gesicherten Finanzierung, insbesondere auch zur Integration der einzelnen Komponenten miteinander, und dem Willen zu organisatorischen Änderungen mangelt es jedoch. Auch scheitert oft der Aufbau neuen Wissens und neuer Fähigkeiten in der eigenen Organisation – die langfristige Abhängigkeit von externem Know-how und damit einhergehende Kosten sind die Folge.

Eine weitere wichtige Herausforderung ist die Evolution, die Weiterentwicklung, der bestehenden Fach- und IT-Architektur. Prozessdigitalisierung beginnt nicht auf der grünen Wiese. Bestehende Digitalisierungsinseln in den Prozessen müssen miteinander verbunden, bestehende Prozessautomatisierungen zu einer Ende-zu-Ende-Digitalisierung und -automatisierung ausgebaut werden. Oder anders gesagt: Fach- und IT-Architekturen müssen mit dem Ziel einer Ende-zu-Ende-Digitalisierung und -automatisierung weiterentwickelt werden. Oftmals aber geschieht genau das nicht, sondern es werden entweder unpassende Tools, insbesondere Digitalisierungsplattformen, gekauft oder aber bestehende Inseln ausgebaut und mit bekannten, aber nicht geeigneten Technologien miteinander verbunden. Es wird lokal optimiert, die globale Steuerung fehlt und so werden auch die globalen Ziele verfehlt. Im Ergebnis bleibt die Prozessdigitalisierung und -automatisierung bruchstückhaft und große Nutzenpotenziale liegen weiterhin brach.

Wir unterstützen Sie dabei, diesen Herausforderungen zu begegnen. Mit unseren Erfahrungen aus konkreten Projekten unterstützen wir Sie bei Technologieauswahlentscheidungen, Pilotprojekten, bei der Internalisierung von Wissen und der Weiterentwicklung Ihrer Organisation. Gemeinsam mit Ihnen prüfen wir Ihre Ihre Fach- und IT-Architektur auf ihre Zukunftsfähigkeit, brechen Silos auf und entwickeln die Architekturen planvoll mit den Beteiligten unter Berücksichtigung der globalen Ziele weiter.

Habe ich Ihr Interesse geweckt? Sprechen Sie mich an! Sie erreichen mich per Mail unter michael.jacob@masoona.de. Gerne können Sie auch einen unverbindlichen Austauschtermin vereinbaren: https://calendly.com/michael-jacob-77/austausch

Der Beitrag Technologien und Architekturen in der Prozessdigitalisierung: Keine halben Sachen! erschien zuerst auf Masoona Consulting.