Zurück im Ring: Warum ich mich wieder für das IT-Consulting entschieden habe (Teil 1)

Manchmal muss man einen Schritt zurücktreten, um zu erkennen, was einen wirklich antreibt. Ich möchte heute ganz offen darüber sprechen, warum ich wieder zurück ins IT-Consulting gegangen bin. Es ist eine Entscheidung, die sowohl meine persönlichen Erfahrungen widerspiegelt als auch eine ehrliche Einordnung einer Branche ist, die oft missverstanden wird.

Im zweiten Teil erfahrt Ihr dann warum ich mich bewusst für Masoona Consulting entschieden habe.

Die Suche nach der echten Herausforderung

Man muss ehrlich sein: Es gibt wahrscheinlich entspanntere Arbeitsumfelder, in denen man „einfacher“ sein Geld verdienen kann. Wer Beständigkeit und ein gleichbleibendes Arbeitsumfeld sucht, der ist im Consulting falsch.

Aber wer im Consulting arbeitet, will meistens mehr: Man will Leistung bringen, echte Herausforderungen meistern und sich ständig weiterentwickeln. Ich habe gemerkt, dass mir genau dieser „Drive“ gefehlt hat. Im Consulting wird man direkt an seinen Leistungen, seinem Wissen und dem Mehrwert gemessen, den man liefert. Das kann Druck erzeugen, ja – aber es ist auch unglaublich befriedigend, wenn man sieht, welchen direkten Einfluss die eigene Arbeit hat.

Ein Boot-Camp für die Karriere

Was mich am Consulting immer wieder fasziniert, ist die enorme Lernkurve. In kürzester Zeit gewinnt man Einblicke in Prozesse und Branchen, für die man anderswo Jahrzehnte bräuchte. Bei mir reicht das Spektrum von der Pharmaindustrie und Medizintechnik über Logistik bis hin zu Sportartikeln und der öffentlichen Hand.

Man lernt nicht nur Technologien kennen, sondern versteht, wie Unternehmen im Kern funktionieren – vom Vertrieb bis zur Produktion. Diese Breite an Erfahrungen ist ein Turbo für die persönliche Weiterentwicklung und baut einen Marktwert auf, der einem später alle Türen öffnet.

Und um auch hier ehrlich zu sein: Die Consulting Branche bietet gegenüber anderen Unternehmen den garantierten Vorteil, dass die Aussage „wir wollen dich fördern und weiterbilden“ keine leeres Versprechen ist sondern Kerninteresse des Unternehmens. Allein aus Umsatzgründen…

Die ungeschönte Wahrheit

Um authentisch zu bleiben, muss man auch über weitere Schattenseiten ansprechen, die es gibt, aber die jeder für sich bewerten und einordnen muss:

• Leistungsdruck: Man verkauft täglich seine Expertise und wird ständig bewertet. Das erfordert eine hohe Resilienz.
• Flexibilität: Aufgaben und Technologien ändern sich rasant, worauf man sich immer wieder neu einstellen muss.
• Reisetätigkeit: Gerade zu als Neueinsteiger gehört es oft dazu, mehrere Tage die Woche beim Kunden vor Ort zu sein.
• Berater – kein Entscheider: Man kann eine Lösung definieren und empfehlen, aber am Ende ist immer der Kunde der Entscheider. Das kann frustrierend sein.

Wie in meinem anderen Blogbeitrag ausführlich beschrieben, sind diese Punkte eine Frage der Perspektive – im Kern steht eine andere Frage.

Warum ich trotzdem „Ja“ sage

Trotz dieser Anforderungen überwiegen für mich die positiven Aspekte. Man trifft im Consulting auf ein Umfeld von „Machern“ – Menschen, die Lust haben anzupacken und gemeinsam etwas zu erreichen. Man ist dort, weil man sich bewusst dafür entschieden hat.

Die Belohnung dafür sind nicht nur eine leistungsgerechte Bezahlung und exzellente Aufstiegsmöglichkeiten, sondern vor allem die Freiheit, sich den eigenen Weg durch die gesammelten Erfahrungen selbst zu bauen.

Fazit von Teil 1: 

Die Rückkehr ins Consulting war für mich eine Entscheidung für das Wachstum und gegen den Stillstand. Doch Consulting ist nicht gleich Consulting. Im zweiten Teil erfahrt ihr, warum meine Wahl ganz gezielt auf Masoona Consulting gefallen ist und warum das Team und die Vision dort für mich den entscheidenden Unterschied machen.

Der Beitrag Zurück im Ring: Warum ich mich wieder für das IT-Consulting entschieden habe (Teil 1) erschien zuerst auf Masoona Consulting.

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.

Generative Künstliche Intelligenz (KI) erlebt derzeit einen starken Aufschwung – viele Unternehmen und Forschungseinrichtungen erkennen ihr Potenzial, vor allem in Bereichen wie Text- und Bildgenerierung, automatisierter Übersetzung, Softwareentwicklung und Wissensarbeit. So ergab eine Studie zur generativen KI in der deutschen Wirtschaft 2025, dass 91 % der befragten Unternehmen generative KI inzwischen als geschäftskritisch betrachten und 82 % ihre KI-Budgets erhöhen wollen. Generative KI-Modelle (z. B. Large Language Models wie ChatGPT) können große Mengen an unstrukturierten oder teilstrukturierten Daten verarbeiten, Muster erkennen, Texte automatisch generieren oder zusammenfassen. Vor diesem Hintergrund stellt sich die Frage: Inwieweit können generative KI-Modelle wie ChatGPT gezielt die Aufgaben im Anforderungsmanagements unterstützen? Besonders relevant sind dabei:

Anforderungsmanagement ist eine zentrale Disziplin im Software- und Systems Engineering. Es umfasst die systematische Erhebung, Analyse, Dokumentation, Modellierung, Validierung und Verwaltung von Anforderungen, die den Rahmen für die Entwicklung komplexer Systeme bilden. Ziel ist es, die Erwartungen der Stakeholder zu verstehen, diese in klare und überprüfbare Anforderungen zu überführen und ihre Umsetzung über den gesamten Lebenszyklus zu steuern. Entscheidend ist dabei nicht nur die Vollständigkeit und Nachvollziehbarkeit der Anforderungen, sondern auch ihre Konsistenz und Realisierbarkeit.

Im Anforderungsmanagement existieren verschiedene Teildisziplinen, die sich in ihren Aufgaben und Zielen ergänzen (vgl. Ebert, Systematisches Requirements Engineering: Anforderungen ermitteln, dokumentieren, analysieren und verwalten):

Für die Beantwortung der Frage, inwiefern eine KI unterstützen kann, betrachtet eine Reihe von Artikeln die einzelnen Teildisziplinen im Detail und gibt Aufschluss über die Potentiale, Chancen und Herausforderungen im Einsatz generativer KI in den Teildisziplinen des Anforderungsmanagement. Allen Artikeln liegt ein fiktives Beispiel zugrunde, das nachfolgend beschrieben wird. Den Abschluss bildet ein Artikel, der alle Ergebnisse zusammenfässt und die Betrachtung der Unterstützung durch eine generative KI mit einem Fazit abschließt.

Vorgehen

Anforderungserhebung anhand eines Beispielsystems

Zur Untersuchung der Potenziale wird ein fiktives Beispielsystem angenommen. Dieses umfasst ein einfaches Warenwirtschaftssystem mit drei zentralen Komponenten:

Dokumente für die Anforderungserhebung

Als Eingaben werden unterschiedliche, fiktive Dokumente erstellt, die typischerweise im Rahmen realer Projekte vorliegen können. Dazu zählen etwa Projektvorschläge, Beobachtungsprotokolle von Filial- oder Lagerarbeitern, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme oder erste Entwürfe von Benutzeroberflächen. Die Dokumente existieren bewusst in verschiedenen Dateiformaten – darunter docx, png, yaml und pdf. Ein Dokument liegt in handschriftlicher Form vor, wodurch eine direkte maschinelle Verarbeitung erschwert werden soll.

Auswahl der KI

Für die Untersuchung wird ChatGPT als generative KI ausgewählt. Zum Zeitpunkt der Durchführung der Bewertungen steht das Modell GPT-4o zur Verfügung, das durchgängig eingesetzt worden ist.

GPT-4o ist kein auf Anforderungsmanagement trainiertes Modell. Es verfügt daher nicht über tiefes Fachwissen zu branchenspezifischen Prozessen, Terminologien oder regulatorischen Rahmenbedingungen. Dennoch kann gerade diese breite und vielseitige Ausrichtung von Vorteil sein: Das Modell bringt ein großes Sprachverständnis mit, ist flexibel einsetzbar und kann Inhalte aus sehr unterschiedlichen Dokumentenformaten verarbeiten. Damit eignet es sich gut, um heterogene Eingaben zunächst strukturiert aufzubereiten. Für eine präzisere Anpassung an die jeweilige Domäne können im weiteren Verlauf Feintuning, Nachschulungen oder die Ergänzung durch domänenspezifisches Wissen erfolgen. Für den zugrundeliegenden Artikel wurde daher erst einmal bewusst ein untrainiertes Modell genutzt.

Durchführung

Der Prompt

Die Interaktion mit der KI erfolgt über einen klar strukturierten Prompt, der die Aufgabe vorgibt, aus verschiedenen Dokumenten die nötigen Informationen so zu extrahieren, dass sie dem Requirements-Engineer der Bewältigung in den Teildiszplinen im Anforderungsmanagement unterstützen. Die KI soll sowohl explizite als auch implizite Anforderungen erkennen und diese in einem einheitlichen, vorher festgelegten JSON-Format dokumentieren.

Das JSON-Format umfasst unter anderem Attribute wie Identifikationsnummer, Titel, Anforderungstext, Priorität, Kategorie, Modulzuordnung, Status, Modelle, Quellen, Testfälle, Stakeholder sowie Änderungsverfolgung. Diese Struktur erlaubt eine standardisierte Ablage und Nachvollziehbarkeit der Anforderungen. Unklare Attribute wie z.B. Kategorie, Status oder Relevanz sind der KI erklärt und mögliche Wertebereiche vorgegeben worden.

Die KI hat sich kooperativ gezeigt und hat den Upload der Dokumente ohne weitere Rückfragen angefordert. Die Ausgaben werden dabei stets als Teilergebnisse festgehalten, falls auf einen Stand zurückgerollt werden muss.

Bewertung

Für die Bewertung der Ergebnisse werden objektive Messkriterien definiert, die sich an den Teildisziplinen Erhebung, Analyse, Spezifikation und Modellierung orientieren.

Die Disziplinen Validierung und Verwaltung werden in dieser ersten Bewertung nicht vertieft. Die Validierung – also die Prüfung der Umsetzbarkeit – setzt Fachwissen von Softwaredesignern voraus und übersteigt den Rahmen dieser Auswertungen. Die Verwaltung hingegen beschränkt sich darauf, die erhobenen Anforderungen in einem geeigneten Format abzulegen, was durch die JSON-Struktur gewährleistet wird.

Abhängig von der Ergebnisqualität des Prompts, soll im Bedarfsfall die KI mit einem neuen Prompt angewiesen werden, Korrekturen vorzunehmen, um die Güte des Ergebnisses zu steigern. Auf diese Weise kann schrittweise erprobt werden, inwiefern sich die Leistungsfähigkeit durch iterative Anpassungen verbessert.

Ausblick

Die folgenden Artikel dieser Reihe werden detaillierter auf die einzelnen Teildisziplinen eingehen und die Ergebnisse der Bewertung vorstellen. Ziel ist es, differenziert darzulegen, in welchen Bereichen generative KI bereits heute einen praktischen Nutzen bietet und wo noch Forschungs- und Entwicklungsbedarf besteht.

Der Beitrag Das Potenzial von generativer KI im Anforderungsmanagement – Teil 1 der Blogserie erschien zuerst auf Masoona Consulting.

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.

In der heutigen schnelllebigen und technologiegetriebenen Welt stehen Unternehmen oft vor der Herausforderung, ihre Altsysteme zu modernisieren und neue Technologien nahtlos zu integrieren, um langfristig flexibel und erfolgreich zu bleiben. In der Digitalisierung spielt oft die Automatisierung mit Hilfe von Engines oder genauer gesagt Entscheidungsservices  eine sehr wesentliche Rolle, weshalb dieser Blog  eine innovative Lösung vorstellt, die den Einsatz verschiedener Entscheidungsservices zu einem einzigen Entscheidungsservice kombiniert und es ermöglicht, Altsysteme schnell in eine neue Systemlandschaft zu integrieren und schrittweise abzulösen.

Unterschiedliche Geschäftsbereiche erfordern oft unterschiedliche und spezialisierte Entscheidungssysteme. Die Kombination dieser Systeme bietet Flexibilität und Leistungsfähigkeit. Die Strategie, bewährte Technologien vorerst beizubehalten und nach und nach neue Technologien einzuführen, reduziert Risiken und ermöglicht eine gezielte Umstellung.

Unternehmen nutzen eine Vielzahl von Systemen, die aufgrund technologischer Unterschiede nicht gut miteinander kommunizieren können. Ausgetauschte Daten müssen immer wieder in ein neues Format konvertiert werden, um den Medienbruch zu überwinden. Die Ablösung von Altsystemen kann zeitaufwändig und komplex sein, insbesondere wenn es zu Ausfällen kommt. Der Umstieg auf neue Systeme erfordert oft umfangreiche Anpassungen und Datenübernahmen.

Moderne Automatisierungsengines oder auch Entscheidungsservices bieten Schnittstellen an, um ihre Funktionen, wie z.B. das Auswerten von Entscheidungen anhand von spezifischen Eingaben, zugänglich zu machen. Dies ist der Schlüssel für das Adapter Pattern, ein bewährtes Entwurfsmuster aus der Softwareentwicklung, das es ermöglicht, die Kommunikation zwischen verschiedenen Systemen zu erleichtern. Durch die Anwendung des Adapter Patterns kann ein Entscheidungsservice geschaffen werden, der die Funktionalität verschiedener Entscheidungsservices vereinheitlicht bereitstellt. Der Adapter realisiert eine einheitliche Sprache, welche die reibungslose Interaktion zwischen den verschiedenen Entscheidungsservices ermöglicht und nach außen hin für ein System einheitliche Schnittstelle zur Verfügung stellt. In der nachstehenden Abbildung kommuniziert ein System nicht mehr mir den unterschiedlichen Entscheidungsservices 1 und 2, welche unterschiedliche Methodensignaturen zum Abfragen und Auswerten von Entscheidungen bereitstellen, sondern nur noch mit dem Adapter, dem Entscheidungsservice 3. Das Ergebnis ist ein leistungsstarker Entscheidungsservice, der die Fähigkeiten verschiedener Automatisierungsengines nutzt. Unterschiedliche und bestehende Entscheidungsservices können so ohne Unterbrechung weiter genutzt werden, bis sie sukzessive durch ein einheitliches Entscheidungssystem ersetzt werden.

Die nachstehende Abbildung zeigt den Einsatz zweier Entscheidungsservices, welche auf einem unterschiedlichen Technologiestack aufsetzen. Daher bietet ihre Schnittstellen zwar gemeinsam Funktionen an, Modellinformationen zu bereitgestellten Entscheidungen auf dem jeweiligen Service auszulesen oder diese mittels Eingabeparameter abzufragen, jedoch unterscheiden sie sich in ihrer Art und Weise, wie zugegriffen wird. Dies wird in der nachstehenden Abbildung deutlich, in welcher der Entscheidungsservice 1 mit den Methoden “execute()” und “retrieveModels()” dargestellt ist und der Entscheidungsservice 2 von der Funktion her ähnliche aber andere Methoden mit den Signaturen “query()” und “modelInfo()” anbietet. Ein Adapter soll einem anfragenden System nur noch eine vereinheitlichte Schnittstelle bereitstellen, sodass ein System nicht mehr unterscheiden muss, welcher Service wie zu bedienen ist.

Da das Adapter Pattern flexibel und skalierbar ist, erfordert die Implementierung nur begrenzte Ressourcen. Die übergreifende Entscheidungssprache des Adapters kann in der Adaption weiterer Automatisierungengines wiederverwendet werden. Altsysteme können an den Adapter angebunden werden und dann schrittweise abgelöst werden. Die Unternehmen können die Vorteile unterschiedlicher Engines kombinieren und diese gemeinsam verwenden.

Die Kombination verschiedener Automatisierungsengines für Entscheidungen und die Einführung des Adapter Patterns ermöglichen es Unternehmen, ihre Systemlandschaft schrittweise zu modernisieren und neue Technologien effizient einzusetzen. Mit einem Entscheidungsservice von Entscheidungsservices und einer einheitlichen Entscheidungssprache steht einer erfolgreichen Transformation nichts mehr im Wege. Dieser Ansatz bietet Flexibilität, minimiert Ausfallzeiten und steigert die Effizienz, während bewährte Technologien vorerst beibehalten werden können. Unternehmen, die diese Strategie anwenden, werden sich langfristig als agil und zukunftsfähig erweisen.

von Patrick Dohrmann

Der Beitrag Modernisierung der eigenen Entscheidungsservices: Effiziente Integration von Altsystemen in die aktuellste Technologien durch den Einsatz von Adapter Pattern erschien zuerst auf Masoona Consulting.