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.

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.

Die Modellierung von Geschäftsregeln ist ein komplexer Prozess, der sich je nach Unternehmen und Branche, die ein Business Rule Management implementieren, unterscheiden kann. Die große Auswahl an Modellierungswerkzeugen und Automatisierungsmaschinen kann bei richtiger Anwendung eine wesentliche Unterstützung bieten. Neben Eigenschaften wie Verständlichkeit der modellierten oder programmierten Entscheidungsregeln für die Fachbereiche und Automatisierbarkeit durch die IT sollte für jeden Modellierer die Frage geklärt sein: Welcher Modellierungsansatz ist für den Einsatz von Entscheidungen vorzuziehen? 

Im Grunde lassen sich alle bekannten Modellierungsansätze in zwei zugrunde liegende Klassen unterteilen: ein problemorientiertes und ein lösungsorientiertes Modellierungsparadigma. Analog dem deklarativen Programmierparadigma ist das Vorgehen bei dem problemorientierten Modellierungsparadigma, das Problem zu beschreiben, also welche Entscheidung getroffen werden soll, und durch einen generischen Algorithmus die Lösung ableiten zu lassen, das heißt, wie das Ergebnis der Entscheidung lautet. Diesem Paradigma gegenüber steht die imperative Programmierung, bei der durch konkrete Anweisungen der genaue Lösungsweg vorgegeben wird. Übertragen auf das lösungsorientierte Modellierungsparadigma bedeutet dies, dass die Entscheidungsfindung konkret ausmodelliert wird.

Problemorientiertes Modellierungsparadigma

Die Idee hinter diesem Paradigma ist es, die Entscheidung als Problem zu formulieren, das durch ein generisches Lösungsverfahren gelöst werden kann. Hier kann es notwendig sein, das Problem in mehrere Teilprobleme aufzuteilen, die zuvor gelöst werden müssen. Ausgehend von bekannten Fakten, welche die Eingaben der Entscheidungsfindung sind, leitet das Lösungsverfahren für jedes Teilproblem neues Wissen ab, um mit diesem letztlich auf die Lösung des Problems und damit auf das Ergebnis der Entscheidung zu schließen. Probleme werden in dieser Modellierung mit Regeln definiert. 

Nehmen wir z.B. folgende Fakten an:

Wir wollen nun entscheiden, ob es eine Verbindung zwischen den Orten Aquarin und Easthaven gibt. Hierfür formulieren wir das Problem als eine Regel, die beschreibt:

Es gibt dann eine Verbindung zwischen zwei Orten A und B, wenn

Diese allgemeine Beschreibung einer Regel genügt nun, um herauszufinden, ob eine Verbindung zwischen Aquarin und Easthaven existiert. Das generische Lösungsverfahren würde zunächst schauen, ob eine direkte Verbindung zwischen beiden Orten bekannt ist. Falls nicht, würde das Verfahren Verbindungen mit bekannten Zwischenzielen in Betracht ziehen, zu denen Direktverbindungen bekannt sind.

Ein sehr bekannter Modellierungsansatz des problemorientierten Paradigmas ist das Business Rules Management System Drools. Es integriert eine eigene Engine, mit der sich u.a. Geschäftsregeln modellieren und automatisieren lassen. Ein weiterer bekannter Ansatz ist ein maschineller Lernalgorithmus, der nach vorherigem Training, basierend auf einer Eingabe, eine Entscheidung trifft. Solche Algorithmen bilden ebenfalls ein generisches Lösungsverfahren.

Lösungsorientiertes Modellierungsparadigma

Komplementär zum problemorientierten Modellierungsparadigma steht das lösungsorientierte. Der Modellierer gibt hier klar vor, welche Schritte zu unternehmen sind, damit eine Entscheidung aus einer Menge von Eingaben getroffen werden kann. Dabei wird der Lösungsweg genau modelliert. 

Hier finden sich viele Modellierungsansätze wieder, wie z.B. die Decision Model and Notation. Sie verfügt zum einen über ein eigenes Diagramm, mit welchem die Entscheidungen mit ihren Abhängigkeiten zu Eingaben und anderen Entscheidungen fachlich sehr gut dargestellt werden, zum anderen aber die Fähigkeit, durch eine Automatisierungsengine, wie Drools oder die Decision Engine der camunda BPM Plattform, ausgeführt zu werden. Der Lösungsweg wird durch die Modellierung einer Entscheidungslogik für eine Automatisierung vorgenommen. Eine Entscheidungslogik lässt sich z.B. durch eine Entscheidungstabelle modellieren, die aus einer Verknüpfung von Eingabeparametern eine Regel findet, welche die Ausgabe bestimmt.

Fazit

Die Modellierungsansätze des lösungsorientierten Paradigmas lassen sich meist grafisch modellieren, was den Lösungsweg für Fachabteilungen leichter verständlich skizziert. Ansätze des konträren problemorientierten Paradigmas sind der Implementierung durch die IT näher und schwerer begreiflich, da nicht gesehen werden kann, wie der Lösungsweg aussieht. Dennoch bieten diese Modellierungsansätze auch Vorteile. Durch ihre abstrakte Beschreibung der Entscheidung als Problem, ist sie von der Ausführung durch ein System entkoppelt. Sie hilft klarer zu formulieren, was entschieden werden soll und was das Problem ist, als es bei lösungsorientierten Ansätzen möglich ist. Wie der Lösungsweg bei Ansätzen des problemorientierten Paradigmas tatsächlich aussieht, bleibt dem Anwender jedoch verborgen. Selbst wenn der generische Lösungsweg bekannt ist, ist es schwierig, Rückschlüsse auf das Zustandekommen der Lösung zu ziehen.

von Patrick Dohrmann

Der Beitrag Der richtige Ansatz Ihre Entscheidungen zu modellieren 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.

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.

LowCode ist der Trend, das Zauberwort, für die schnelle Digitalisierung und Automatisierung von Prozessen.¹ Vorgefertigte konfigurierbare Bausteine, ergänzt um “klassischen” Code (meist in Form von Scripting), werden als eine der Lösungen für mehr Geschwindigkeit in der Digitalisierung gepriesen. Und eine höhere Geschwindigkeit ist ja gut, insbesondere wenn es gilt, einen Rückstand aufzuholen.

In diesem Blogbeitrag versuche ich zum einen die Frage zu beantworten, was Low Code ist und zum anderen, wie Low Code-Bausteine zur Digitalisierung und Automatisierung von Prozessen eingesetzt werden können.

Was ist eigentlich Low Code?

Einfach ausgedrückt: Applikationslogik, die mit visuellen Beschreibungssprachen dargestellt wird und aus vorgefertigten konfigurierbaren Bausteinen besteht, die miteinander verknüpft werden können. Die visuelle Darstellung wird um “klassischen” Programmcode ergänzt. Low Code-Plattformen sind Anwendungssysteme für die Entwicklung und die Ausführung von Low Code. Zu den Plattformen gehören bspw. Low Code Application Platforms, Business Process Automation Platforms und Robotic Process Automation Platforms.

Bevor wir jetzt aber zu Digitalisierung und Automatisierung von Prozessen mit Low Code-Bausteinen kommen, eine Vorbemerkung: Prozessdigitalisierung und -automatisierung sind immer eine Art von Softwareentwicklung. Egal ob Prozessabläufe und Algorithmen für einzelne automatisierte Aufgaben in Prozessen per Code oder per Low Code implementiert werden – am Ende entsteht immer ein Stück Software. Meine Erfahrung ist, dass diese Tatsache oft nicht erkannt oder nicht ausreichend berücksichtigt wird und dann insbesondere im Betrieb zu Problemen führt – unklare Betriebsprozesse, unklare Zuständigkeiten, unzureichende Updatefähigkeit aufgrund fehlender Dokumentationen etc. Wir sind also gut beraten, die Digitalisierung und Automatisierung von Prozessen – egal ob per Low Code oder nicht, egal ob mit Citizen Developern oder nicht – in unsere  Softwareentwicklungs- und Betriebsprozesse einzubetten. Und nicht Umgehungen dieser Prozesse zu schaffen – Low Code ist kein Ersatz für professionelle Softwareentwicklungs- und -betriebsprozesse (“Schatten-IT”), sondern eine Lösung für eine bestimmte Klasse von Implementierungsproblemen.

Digitalisierung und Automatisierung von Prozessen mit Low Code-Bausteinen

Arten von Bausteinen

Wenn wir nun Prozesse mit Low Code digitalisieren und automatisieren wollen, so benötigen wir Bausteine, mit denen wir diese Prozesse implementieren.² In erster Näherung kann eine grafische Beschreibungssprache wie bspw. die Business Process Model and Notation (BPMN³) als eine einfache Form dieser Bibliothek verstanden werden. Es werden Modellbausteine für spezifische Arten von Aufgaben (Tasks) zur Verfügung gestellt, die mit Hilfe von Parametern konfiguriert werden können. Diese Bausteine sind sehr flexibel einsetzbar, da sie sehr generisch sind: User Tasks für alle Arten von Benutzerinteraktionen, Service Tasks für alle Aufgaben, die per Aufruf eines Service automatisiert durchgeführt werden sollen. Ihr Nachteil – sie bilden nur sehr grundlegende für Prozessdigitalisierungen und -automatisierungen benötigte allgemeine Funktionalität ab.

Low Code-Plattformen bieten daher i.d.R. eigene Bibliotheken mit Bausteinen an, die höherwertige Funktionalität bereitstellen.⁴ Dies können Bausteine für die Anbindung von domänenspezifischen Services und Basisdiensten (“Services”) sein.⁵ Bausteine dieses Typs exponieren die Schnittstellen dieser Systeme für die Prozesse und schaffen so die Möglichkeit, aus Prozessen auf deren Funktionalitäten zuzugreifen. So könnte bspw. ein Baustein für die Erzeugung von Dokumenten bereitgestellt werden. Als Input nimmt der Baustein Metadaten zur Dokumentvorlage (bspw. eine eindeutige ID der Vorlage) und Daten, mit denen vordefinierte Felder in der Vorlage gefüllt werden, entgegen. Als Output gibt der Baustein einen Link auf das Dokument in einem Dokumentenspeicher zurück.

Bausteine können aber auch Funktionalitäten von Services  miteinander verknüpfen und so komplexere fachlich zusammenhängende Funktionalitäten bereitstellen. So könnte der Baustein zur Erzeugung von Dokumente mit Bausteinen zum Versand von Dokumenten bspw. per Mail oder über eine Druckstraße kombiniert werden. Er bietet damit die Erzeugung von Dokumenten und deren Versand an die Empfänger in einem Schritt an.

Entwicklung von Bausteinen

Für die effiziente Digitalisierung und Automatisierung von Prozessen mit Hilfe von Low Code ist es nun aber essentiell – und hier liegt abseits der Marketingversprechen genau die Herausforderung: passende Bausteine zur Verfügung zu haben, wenn sie benötigt werden. Häufig stehen zwar in der fachlichen Breite genügend Bausteine bereit, oft fehlt den Bausteinen aber die entsprechende fachliche Tiefe. Gerade wenn es um die Automatisierung komplexer Prozesse mit einem hohen Anteil fachlicher Logik geht.⁶ Ist dies der Fall, müssen neue Bausteine hinzu gekauft oder selbst entwickelt und bereitgestellt werden.

Werden gängige standardisierte Modellierungs- und Programmiersprachen von der Low Code-Plattform verwendet, so ist eine Eigenentwicklung i.d.R. mit keinem großen finanziellen Risiko verbunden und kann auch problemlos inhouse oder mit am Markt zugekauften Ressourcen durchgeführt werden. Zudem führt die Verwendung von offenen Standards zu einer geringeren Abhängigkeit von der verwendeten Low-Code Plattform. Als Beispiel seien hier Plattformen genannt, die auf der Modellierungssprache BPMN aufsetzen und für die Erweiterung der Plattform beliebige Programmiersprachen zulassen. Als Beispiel seien hier die BPM-Plattformen von Camunda⁷ und Flowable⁸ genannt.

Anders sieht es jedoch aus, wenn die Plattform ein geschlossenes System bildet und für Weiterentwicklungen proprietäre Modellierungs- und Programmiersprachen verwendet werden. Dann müssen Entwicklungsaufträge oftmals an spezialisierte Dienstleister oder gar an den Hersteller der Plattform vergeben werden, da das benötigte Wissen inhouse nicht vorhanden ist und es sich meist auch nicht lohnt, dieses Wissen aufzubauen.

Management des Lebenszyklus von Bausteinen

Der Lebenszyklus von Bausteinen muss gesteuert werden. Aus Sicht der nutzenden Prozesse sind diese nichts anderes als Schnittstellen. Daher kann das Management des Lebenszyklus auch analog zu Schnittstellen erfolgen. Je nachdem wer die Bausteine pflegt muss das Management mehr oder weniger formal erfolgen: Entwickelt und pflegt ein Team die Bausteine, die es benötigt, selbst, so kann die Abstimmung von Änderungen formlos im Entwicklungsteam, bspw. in den Refinements, erfolgen. Werden die Bausteine hingegen von einem zentralen Plattformteam bereitgestellt, so sind entsprechende teamübergreifende Abstimmungsprozesse und häufig auch formale Eskalationsinstanzen, bspw. für die Auflösung von fachlich konfliktären Anforderungen oder von Kapazitäts- und Terminkonflikten, vorzusehen.

Neue Versionen von Bausteinen stellen entweder abwärtskompatible Weiterentwicklungen dar (“minor version”) oder aber sie beinhalten “breaking changes”, also Inkompatibilitäten mit der alten Version (“major version”). Abwärtskompatible Weiterentwicklungen sind eher unkritisch – sobald die neue Version der Schnittstelle verfügbar ist, wird diese auch von allen Prozessen verwendet. Die Verantwortlichen der nutzenden Prozesse können dann frei entscheiden, ob und wann sie auch die erweiterte Funktionalität nutzen wollen.

Bei inkompatiblen Änderungen jedoch hat sich bei Schnittstellen als good practice die Lösung bewährt, neue Funktionalitäten als so genannte neue “major” Version bereitzustellen und für eine Übergangszeit sowohl die neue als auch die alte Version zu betreiben. In dieser Übergangszeit müssen die Schnittstellennutzer auf die neue Version migrieren. Dieses Konzept kann analog auf Bausteine übertragen werden.

Um den Lebenszyklus von Bausteinen managen zu können, müssen die Anbieter und Nutzer von Bausteinen bekannt sein. Auch hier kann analog zu Schnittstellen verfahren werden. Sowohl Anbieter als auch Nutzer von Bausteinen werden dokumentiert. In einfachen Fällen ist eine Intranet-Seite besser als gar nichts, in komplexen Fällen sollte diese Dokumentation toolgestützt erfolgen.

Idealerweise unterstützt die Low Code-Plattform das Management des Lebenszyklus von Bausteinen, indem sie Funktionalitäten für die Bereitstellung, die Versionierung und die automatisierte Dokumentation der Nutzung von Bausteinen bereitstellt.

Zusammenfassung

Low Code-Bausteine stellen ein wichtiges Instrument zur schnellen Digitalisierung und Automatisierung von Prozessen dar. Die einfache und effiziente Bereitstellung sowie Erweiterung von Bausteinen stellt bei komplexen fachlich tiefen Prozessen einen Erfolgsfaktor dar. Standardisierte Modellierungs- und Programmiersprachen leisten hier einen wichtigen Beitrag. Das Management des Lebenszyklus dieser Bausteine ist essentiell für die geordnete (Weiter-)Entwicklung von Prozessen und kann analog zum Management von Schnittstellen erfolgen.

Lust auf Mehr zu diesem Thema? Folgen Sie mir und masoona auf LinkedIn. Weitere Posts zu diesem Thema, u.a. mit Beispielen und technischen Umsetzungen, sind in Vorbereitung.

1. Vgl. bspw. “Gartner Forecasts Worldwide Low-Code Development Technologies Market to Growth in 2023”, https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023 ︎
2. Im Folgenden beziehe ich mich auf die Digitalisierung und Automatisierung von Prozessen auf der Basis von ablauforientierten Beschreibungssprachen. Andere Low Code-Technologien werden hier nicht betrachtet. ︎
3. Vgl. https://www.omg.org/spec/BPMN/2.0/ ︎
4. Für eine Übersicht vgl. bspw. “The Forrester Wave: Low-Code Development Platforms For Professional Developers, Q2 2021”, https://www.forrester.com/report/the-forrester-wave-low-code-development-platforms-for-professional-developers-q2-2021/RES161668?ref_search=0_1692967011739 ︎
5. Alternativ zur Anbindung von plattformexternen Services kann die Plattform die Funktionalitäten auch selbst bereitstellen. ︎
6. Von Forrester auch als “deep digital process automation” (DPA-deep) bezeichnet. Vgl. “The Forrester Wave – Software für digitale Prozessautomatisierung, Q3 2021”, https://www.forrester.com/report/the-forrester-wave-tm-digital-process-automation-software-q4-2021/RES176608?ref_search=3492107_1655903761272 ︎
7. https://camunda.com/ ︎
8. https://www.flowable.com/ ︎

Der Beitrag Low Code – Bausteine für eine schnelle und nachhaltige Digitalisierung von Prozessen erschien zuerst auf Masoona Consulting.

Einleitung

Hallo, ich bin Patrick, IT-Berater und Mitarbeiter bei Masoona Consulting. Ich habe mich vor mehr als einem Jahr hierher beworben und habe zuvor ebenfalls in der Beratung im Schwerpunkt Projektleitung und Digitalisierung gearbeitet. 

Neben dem Einsatz beim Kunden in für mich spannende und interessante Projekte, ist für mich auch ein ausgewogenes Verhältnis zu persönlichen Weiterentwicklungsthemen wichtig. Damit meine ich nicht etwa mich durch Schulungen und Zertifikate weiterzubilden, sondern mich auch in Themen einzuarbeiten und zu bearbeiten, die nicht nur mich weiterbringen, sondern auch für den Arbeitgeber einen Mehrwert bringen.

Beweggründe

Klar, in der Beratung ist jedermann im Einsatz beim Kunden. Da bleibt ein begrenzter Spielraum Themen für sich und die Firma voranzubringen. Daher sollte diese Zeit sinnvoll eingesetzt werden. Ich habe daher einen Arbeitgeber wie masoona Consulting  gesucht, bei dem ich nicht als Bodyleaser eingesetzt werde, sondern meine persönlichen Interessen und Fähigkeiten einsetzen und durch neue Herausforderungen weiter feilen kann. Und hierzu zählen nicht Budgets für Weiterbildungen! Hierfür habe ich einen Entwicklungsspielraum, in dem ich in Abstimmung mit den Firmenzielen meine eigenen Interessen im Bereich der Business Rules und deren Automatisierung platzieren und treiben kann. 

masoona Consulting setzt sich weiterhin dafür ein, nicht in irgendwelchen Projekten bei Kunden eingesetzt zu werden. Als Beratungsunternehmen für Digitalisierung und Automatisierung von Prozessen und Entscheidungen stehen zwar Kunden im Kontext dieser Themen im Fokus, jedoch wird auch darauf geachtet, dass persönliche Fähigkeiten optimal bei Kunden eingesetzt werden und zum Projekterfolg beitragen.

Unternehmenskultur

masoona Consulting hat flache Hierarchien und profitiert von einem regelmäßigen Austausch zu aktuellen Themen in der Digitalisierung. Die Offenheit miteinander äußert sich in einer gelebten Feedback-Kultur, die einem hilft, in seinen Themen oder auch Problemen voranzukommen. 

Abhängig vom Kunden ermöglicht  masoona Consulting ein flexibles Arbeitsmodell, das es ermöglicht, seine Arbeitszeiten frei einzuteilen und auch seinen Arbeitsort frei zu wählen. Für mich ist dies ein ganz attraktiver Benefit, da ich zum einen zur Firma bzw. zum Kunden einen etwas längeren Anreiseweg habe und zum anderen so Freizeit, Familie und Beruf sehr gut in Einklang bringen kann.

Fazit

Ich bin gespannt auf die kommenden Jahre und freue mich auf die weitere gute Zusammenarbeit.

Der Beitrag Patrick berichtet: „Mein Entschluss für masoona“ erschien zuerst auf Masoona Consulting.

Zwei Fragen, auf die wir immer wieder angesprochen werden. In diesem Beitrag versuchen Elmar und ich Antworten auf zu geben.

Zunächst aber die Antwort auf eine andere Frage die wir oft hören: Was bedeutet “masoona”? Die Antwort lautet: Das Wort selbst hat keine Bedeutung – wir wollten einfach einen Namen, der gut zu merken ist, über den man trotzdem reden kann. So zum Beispiel über die Aussprache der zwei “oo” – die wir hier natürlich nicht verraten. Die Unternehmung dahinter bedeutet uns alles. Mit ihr wollen wir unsere Vorstellungen von einer Beratung zur Digitalisierung und Automatisierung von Prozessen umsetzen.

Die masoona ist kein klassisches Start-up. Sowohl Elmar als auch Michael haben bereits in vielen IT-Projekten tatkräftig mitgewirkt. Darüber hinaus haben wir beide unsere Erfahrungen in Beratungsunternehmen gesammelt und daraus unsere Vision für die masoona entwickelt.

Fokus in der Beratung

Wir fokussieren uns auf den Markt der Prozessdigitalisierung und -automatisierung. Dies beinhaltet ausdrücklich auch die Entscheidungen in Prozessen. Wir wollen in diesem Markt erfolgreich bestehen und die Projekte unserer Kunden zum Erfolg zu führen. Deshalb bauen wir ein Team auf, dass passgenau die dafür erforderlichen Fähigkeiten und Erfahrungen mitbringt oder ggf. auch erst einmal selbst aufbaut. Wir wollen alle Aspekte der Entwicklung und des Betriebs dieser IT-Lösungen abdecken – von Anforderungsmanagement und -analyse über Development und Operations bis zur Steuerung der digitalen Transformation einer Organisation.

Fokus auf unsere Mitarbeiter*innen

Wir vertrauen unseren Mitarbeiter*innen und wertschätzen sie als Menschen und als Mitarbeiter*in. Dies ist die Basis zum einen unseres Unternehmenserfolgs und zum anderen wollen wir so auch unserer sozialen Verantwortung gerecht werden. Wir wollen ihnen eine langfristige Perspektive im Unternehmen geben. Dabei setzen wir auf eine moderne Arbeitswelt mit mobilem oder hybriden Arbeiten, aktuellstem Equipment und einer Bezahlung über dem Branchendurchschnitt. Wir leben agile Prinzipien auch in der masoona selbst und setzen auf die Kreativität und die Ideen unserer Mitarbeiter*innen.

Nachhaltige Beratung

Wir beraten unsere Kunden nachhaltig und in hoher Qualität, damit sich ihre Investitionen langfristig lohnen. Wir bauen Lösungen, mit denen unsere Kunden den größtmöglichen Nutzen erzielen. Wir arbeiten und kommunizieren fast ausschließlich digital. Die Mobilität unserer Mitarbeiter*innen im geschäftlichen wie im privaten Bereich sichern wir mit umweltfreundlichen Verkehrsmitteln, bspw. Öffis, E-Autos und Fahrrädern.

Der Beitrag Was macht masoona und was zeichnet uns aus? erschien zuerst auf Masoona Consulting.

Bei der Digitalisierung Ihrer Prozesse kommt ein komplexer Mix von Technologien und Produkten zum Einsatz, der gerade zu Beginn eher Startschwierigkeiten bereitet als tatsächlich effektiv zur raschen Umsetzung beiträgt. Um auch Ihre großen Ideen zum Fliegen zu bringen, setzt masoona auf Partner, deren Produkte sich schon bei vielen innovativen Kunden bewährt haben. 

GBTEC Software AG

GBTEC (www.gbtec.com) ist seit vielen Jahrzehnten als inhabergeführtes Unternehmen erfolgreich im BPM-Markt etabliert und weltweit bei namhaften Kunden aktiv.

Die BIC-Plattform (Design, Execution, Mining) deckt den gesamten BPM-Lebenszyklus ab: Von der klassischen Prozessmodellierung und unternehmensweiten Publikation über die Ausführung in einer Engine (BPMN, DMN, Low-code) bis zum Process Mining. 

masoona setzt hierbei auf die Vorzüge einer kompletten und integrierten Plattform. Mit BIC Process Design und Process Execution arbeiten fachliche Prozessmanager und die IT-Spezialisten gemeinsam in einem Werkzeug an der Digitalisierung ihrer Prozesse. Process Mining trägt zur Identifikation der Ist-Prozesse bei und hilft bei der Bewertung der Nutzenpotenziale einzelner Digitalisierungsvorhaben (z. B. über Anzahl der zu automatisierenden Prozessinstanzen, -pfade oder durch die Identifikation von Schwachstellen im Prozess).

camunda Services GmbH

camunda (www.camunda.com) ist weltweiter Marktführer für BPMN/DMN-Engines unter dem Open-Source-Lizenzmodell. BPM wird in diesem Ökosystem vom Entwickler und von der technischen Umsetzung her gedacht. Dies hat erhebliche Vorteile um schnell und leichtgewichtig Prozesse in komplexen IT-Landschaften zu automatisieren. Vor allem wenn Java strategisch von Seiten der IT gesetzt ist, liegt der Einsatz der camunda-Produkte bei der Prozessdigitalisierung nahe.

masoona setzt camunda in Kundenprojekten ein und realisiert auf Basis dieser Plattform digitale Prozesse. Auch unterstützen wir unsere Kunden bei der Integration der Plattform mittels Ergänzungen und Anpassungen in die kundenspezifische IT-Architektur und Anwendungslandschaft. So erreichen unsere Kunden schnell automatisierte Prozesse, auch in heterogenen und anspruchsvollen Umfeldern.

Red Hat

Red Hat (https://www.redhat.com/de) ist seit seiner Gründung dem Open-Source-Gedanken verpflichtet und steht seit Jahrzehnten für einige der einflussreichsten und am weitesten verbreiteten Open-Source-Produkte wie z.B. Keycloak, JBoss-Familie, Drools und Quarkus. Mit Kogito (https://kogito.kie.org) und Quarkus (https://quarkus.io) hat Red Hat einen neuen, spannenden Technologiestack am Start, mit dem sich Prozessdigitalisierung wie aus dem Lehrbuch cloud-native umsetzen lässt. masoona misst der Automatisierung von Entscheidungen und der Durchsetzung von Geschäftsregeln einen hohen Stellenwert bei. Häufig wird bei der Digitalisierung vorrangig auf die Prozessabläufe geachtet, womit das Potenzial komplexe Entscheidungen mit Geschäftsregeln zu automatisieren, ungenutzt bleibt. Red Hat bietet hier bewährte und zugleich innovativ weiterentwickelte Produkte wie Drools (https://www.drools.org).

Gemeinsam den erfolgreichen Weg finden!

masoona wählt seine leistungsfähigen Partner und seinen Technologie-Stack so aus, dass unsere Kunden ihre Prozessdigitalisierung erfolgreich gestalten können. Der optimalen Produkt- und Technologieauswahl kommt hierbei eine zentrale Bedeutung zu. Mit den Beratungsprodukten DigiLAB und ProcessLAB können diese für den Gesamterfolg grundlegenden Entscheidungen evaluiert und anhand von Ihren konkreten Anwendungsfällen gefällt werden.

Der Beitrag Starke Partner für Ihre digitalen Prozesse! erschien zuerst auf Masoona Consulting.