Digitalisierte Geschäftsprozesse mit dem UML-Aktivitätsdiagramm entwerfen

Digitalisierte Geschäftsprozesse mit dem UML-Aktivitätsdiagramm entwerfen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/geschaeftsprozesse-aktivitaetsdiagramm

Geschäftsprozesse, Digitalisierung, UML-Aktivitätsdiagramm, Anwendungsfalldiagramm, Use-Case-Diagramm, Partitionen, Swimlanes, Modellierungstechnik, BPMN, Digitalzwang, Kongress-App

tl/dr; (ca. 15 min Lesezeit): Steht fest, wo ein Prozess digitalisiert werden soll, geht es an den Entwurf der neuen Abläufe. Aus der Übersicht der Anwendungsfälle werden die neuen Geschäftsprozesse abgeleitet, und es wird entschieden, welche davon im Detail modelliert werden. Welche Modellierungstechnik dafür passt, hängt von einigen Randbedingungen ab; hier kommt das UML-Aktivitätsdiagramm als Technik der Lösungsdomäne mit Partitionen je System zum Einsatz. Am Beispiel einer Kongress-App zeigt sich, warum die Prozesse dabei oft neu geschnitten werden müssen (Teil der Artikelserie zur Gestaltung und Entwicklung von Benutzeroberflächen für Geschäftsprozesse) [AI-Assisted]. (Zuletzt geändert am 29.10.2026)

Dieser Artikel ist Teil einer Artikelreihe über Benutzerschnittstellen für Geschäftsprozesse: Ist-Analyse und Prozessanalyse: Geschäftsprozesse erfassen, bewerten und verbessern / Geschäftsprozesse digitalisieren und optimieren / Digitalisierte Geschäftsprozesse mit dem UML-Aktivitätsdiagramm entwerfen / Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen / Usability, User Experience und Barrierefreiheit: Software, die alle gern nutzen / GUI-Seiten mit Wireframes und Mockups entwerfen

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Übersicht der Anforderungen an optimierte und digitale Geschäftsprozesse erhalten

Welche Schwachstellen ein Prozess hat und wie Digitalisierung sie beseitigen kann, beschreibt der Artikel Geschäftsprozesse digitalisieren und optimieren. Grundlage ist die Ist-Analyse, in der das Umfeld, die Rahmenbedingungen, die Stakeholder und die bestehenden Geschäftsprozesse (z. B. als BPMN) erfasst wurden. Dieser Artikel geht den nächsten Schritt: Am Beispiel einer Kongress-App zeigt er, wie aus den Anforderungen die neuen, digitalisierten Geschäftsprozesse entstehen und wie ihr Ablauf mit dem UML-Aktivitätsdiagramm entworfen wird.

Digitalisierung ist kein Selbstzweck, sondern muss einem im Business-Case des Projekts niedergeschriebenen Benefit dienen, indem es konkrete Anforderungen umsetzt. Die systematische Anforderungsermittlung, -dokumentation, -analyse und -verwaltung muss also im Vorfeld oder parallel ablaufen, um die Grundlage für optimierte Geschäftsprozesse zu erhalten. Wir gehen davon aus, dass die Bedarfe erfasst und verstanden, die Anforderungen bereits weitgehend bekannt und dokumentiert sind.

Einen guten Überblick über alle funktionalen Anforderungen an das neue/erneuerte System bietet das UML-Anwendungsfall-Diagramm (Use-Case-Diagramm). Jedem Anwendungsfall liegen in der Regel ein oder mehrere Geschäftsprozesse zugrunde, die den im Anwendungsfall beschriebenen Nutzen generieren.

Neben den im Use-Case-Diagramm beschriebenen funktionalen Anforderungen muss das System natürlich auch die gestellten Qualitätsanforderungen umsetzen. Ein Punkt sei in diesem Zusammenhang hervorgehoben: Zu oft haben Digitalisierungsprozesse zur Folge, dass ein Digitalzwang entsteht, der unter zwei Gesichtspunkten kritisch hinterfragt und geprüft werden muss:

• Kann der Nutzen, den das System erzeugen soll, auch noch erreicht werden, wenn zentrale Systeme ausfallen (z. B. externe Dienste nicht mehr angeboten werden oder plötzlich hohe Kosten verursachen)?

• Kann der Nutzen, den das System erzeugen soll, barrierefrei erreicht werden, also auch unabhängig von bestimmten Endgeräten, Softwareversionen, Wissensständen, Fähigkeiten?

Bei allen Vorteilen, die die Digitalisierung von Prozessen bietet, muss bei der Umsetzung stets im Blick behalten werden, welche möglichen Abhängigkeiten und Einschränkungen damit einhergehen und minimiert werden müssen. Weitere Grenzen der Digitalisierung (persönlicher Kontakt, zusätzliche Kosten, Akzeptanz, Datenschutz) sind im Artikel Geschäftsprozesse digitalisieren und optimieren zusammengestellt.

Beispiel der Anforderungs-Übersicht für eine Kongress-App

Ein Ergebnis könnte die folgende Übersicht der funktionalen Anforderungen an eine Kongress-App sein, wie sie in folgendem UML-Anwendungsfalldiagramm (Use-Case-Diagramm) zusammengetragen wurde:

Geschäftsprozesse als digitale Geschäftsprozesse entwerfen und optimieren

Aus den vorliegenden Geschäftsprozessen (aus der Ist-Analyse) und den bekannten Anforderungen (aus dem Requirement Engineering) können nun neue optimierte und digitalisierte Geschäftsprozesse abgeleitet werden.

Im Rahmen der Digitalisierung werden häufig neue Apps erstellt oder vorhandene grundlegend umstrukturiert. Das hat zur Folge, dass auch die neuen Geschäftsprozesse anders aufgeteilt (geschnitten) sein können als die im Rahmen der Ist-Analyse ermittelten Prozesse. Es ist zunächst also ratsam, eine Liste der neuen Geschäftsprozesse zu erstellen, die mit Hilfe des neuen Systems bearbeitet werden sollen.

Beispiel: Geschäftsprozesse der Kongress-App

Anhand der Anwendungsfälle lassen sich folgende Kandidaten für Geschäftsprozesse identifizieren:

• Teilgebende reichen Sessionangebote ein

• Teilgebende können ihre Sessionangebote bearbeiten

• Teilgebende genehmigen den Zeitplan ihrer Sessionangebote

• Besuchende können Sessionübersichten (Themen-, Zeit- und Raumplan) und Details ansehen

• Besuchende können den Sessionplan mit Stichwörtern nach Sessions durchsuchen

• Besuchende können Sessions mit begrenzten Plätzen buchen

• Das Orga-Team genehmigt Sessions

• Das Orga-Team erstellt einen Zeitplan

• Das Orga-Team erstellt einen Raumplan

In unserem Fall decken sich also die Geschäftsprozesse weitgehend mit denen der Ist-Analyse.

Aus der Liste der erfassten Geschäftsprozesse werden nun diejenigen identifiziert, die im Detail modelliert werden sollen. Dies ist vor allem für komplexere Prozesse relevant, die über unterschiedliche Akteure, Subsysteme oder Verantwortlichkeiten verfügen. Eine detailliertere Modellierung hilft auch, wenn bei Geschäftsprozessen viele Entscheidungen getroffen werden müssen.

Die Modellierung zentraler Prozesse hilft auch dabei, Missverständnisse über den Weg der Problemlösung mit Auftraggebenden / der Fachabteilung zu klären. Diagramme, Listen und Tabellen sind in diesem Stadium noch für alle Beteiligten verständlich – ein Review gemeinsam mit der Fachabteilung ist hier also sehr sinnvoll.

Ablauf zentraler Geschäftsprozesse entwerfen

Diese Modellierung kann mit den gleichen Werkzeugen erfolgen, die auch bei der Ist-Analyse möglich waren (also z. B. Volltext, Stichpunkte, Tabellen, Flussdiagramme (UML-Aktivität, BPMN, eEPK)). Welche Werkzeuge zur Anwendung kommen, kann in Abhängigkeit von einer Reihe von Randbedingungen entschieden werden:

• Wie sehr unterscheidet sich der neue Geschäftsprozess vom bisherigen? (gering = ich nehme gleiche Modellierungstechnik)

• Wie gut ist unser Verständnis für den Prozess? (gering = ich nehme BPMN, da es das Prozessverständnis fördert)

• Wer ist am Entwurfs- und Reviewprozess beteiligt? (nicht-technische Fachabteilung: ich nehme Techniken, die sie kennen)

• Wie weit bin ich vom Prozess entfernt und habe die technische Lösung vor Augen? (Je technischer, desto UML-Aktivität)

Wenn die vorgenannten Fragen keine Festlegung auf ein Werkzeug zulassen, empfehle ich, sich langsam vom Prozess zu lösen und der Problemlösung anzunähern: mit einer Modellierungstechnik wie dem UML-Aktivitätsdiagramm, das Bestandteil der Lösungsdomäne ist, können Kontroll- und Datenflüsse bereits sehr nah an der Programmierung entworfen werden.

Es bietet sich an, die Abläufe bereits in Partitionen (Swimlanes) aufzuteilen, die den zu erstellenden Systemen entsprechen. Neben den Akteuren, die bei nicht-digitalisierten Geschäftsprozessen im Fokus stehen, sollte in dieser Modellierungsphase geklärt werden: Welches System bietet welche Dienste an? Nachrichten, die versendet werden, sollten nach Möglichkeit bereits einheitlich typisiert werden. Zudem kann so bereits der Umgang mit Fehlerzuständen in Form von Ausnahmen modelliert werden.

Beispiel: SessionAngebots-Workflow mit der Kongress-App

In unserem Beispiel soll es eine zentrale App sein, die sämtliche Dienste übernimmt. Wir können also die beiden Pools aus dem bekannten BPMN-Diagramm der Ist-Analyse jetzt als Partitionen (Swimlanes) übernehmen (Teilgebende, Orga-Team) und um die eigentliche Kongress-App ergänzen.

Bei der Modellierung fällt auf, dass reines Übertragen der vorher ermittelten Abläufe keinen Sinn ergibt: Wir müssen einzelne Aktivitäten ausgliedern, die im neuen Prozess gesondert umgesetzt werden müssen:

Die Zeit- und Raumplanung lässt sich nicht mehr sinnvoll in das Diagramm integrieren (da sie komplett eigene Abläufe beinhaltet). Die Erstellung des „Call for Participation“ ist nur lose durch eine Nachricht mit den anderen Aktivitäten verbunden, ebenso die Einreichung von Formulardaten. Der eigentliche Genehmigungsprozess wird für jedes Sessionangebot gesondert (parallel oder sequenziell) durchlaufen. Es zeichnet sich also schnell ab, dass wir die Aktivitäten anhand der neuen, an den Anforderungen orientierten Geschäftsprozesse aufteilen müssen und eine Gesamtübersicht mit dem UML-Aktivitätsdiagramm (anders als beim BPMN) wenig Sinn ergibt.

Hinweise zur Aktivitätsdiagramm-Notation: In dem Diagramm finden sich eine Reihe von Objektflüssen, die einige Modellierungstools so nicht anbieten: die Pin-Notation (orange Quadrate an Aktivitäten), die anzeigt, dass die Aktivität als Eingabeparameter Objekte vom Typ CfP Formulardaten erwartet, die beiden Datastores (blau), die Objekte vom Typ SessionAngebot und HilfsAngebot speichern, die beiden Nachrichten-Objekte (türkis), die das System an die Teilgebenden verschickt. Da mehrere CfP Formulardaten eingehen werden, wurde für die Aktivität kein Activity Final Node modelliert, der alle laufenden Prozesse stoppen würde, sondern lediglich Flow Final Nodes, die nur den jeweiligen Ablauf beenden.

Welches sind die Prozesse in unserem Beispiel, die aufgrund ihrer Komplexität oder Vielzahl an Akteuren modelliert werden sollten? Wie können die oben dargestellten Aktivitäten besser geschnitten und modelliert werden?

Fazit

Als erster Entwurfsschritt haben wir nun aus den Anforderungen und den bisherigen Geschäftsprozessen die Grundlage für die Realisierung geschaffen: die neuen digitalisierten Geschäftsprozesse, die mithilfe der neuen App umgesetzt werden sollen. Welche Modellierungstechnik dafür passt, hängt vom Abstand zum bisherigen Prozess, vom Prozessverständnis und von den Beteiligten ab; je näher die technische Lösung rückt, desto eher lohnt sich das UML-Aktivitätsdiagramm. Wichtig ist, die Prozesse so zu schneiden, dass jedes Diagramm einen klar abgegrenzten Ablauf zeigt.

Als nächsten Schritt gilt es, aus diesen Abläufen die zugrunde liegenden UI-Zustände abzuleiten und zu modellieren.

Leitfragen

1. Warum beginnt der Entwurf digitalisierter Geschäftsprozesse bei den Anforderungen und nicht bei der Technik? Antwort

Digitalisierung ist kein Selbstzweck: Sie soll den im Business-Case festgehaltenen Nutzen bringen, indem sie konkrete Anforderungen umsetzt. Deshalb müssen die Anforderungen vorher oder parallel ermittelt und dokumentiert sein; einen Überblick über die funktionalen Anforderungen gibt das UML-Anwendungsfalldiagramm. Siehe Abschnitt „Übersicht der Anforderungen an optimierte und digitale Geschäftsprozesse erhalten“

2. Welche beiden Fragen helfen, einen Digitalzwang als Qualitätsanforderung zu prüfen? Antwort

Erstens: Wird der Nutzen auch dann noch erreicht, wenn zentrale Systeme ausfallen, etwa wenn ein externer Dienst eingestellt wird oder plötzlich hohe Kosten verursacht? Zweitens: Ist der Nutzen barrierefrei erreichbar, also unabhängig von bestimmten Endgeräten, Softwareversionen, Wissensständen und Fähigkeiten? Siehe Abschnitt „Übersicht der Anforderungen an optimierte und digitale Geschäftsprozesse erhalten“

3. Wie gewinnst Du die Liste der neuen Geschäftsprozesse, und warum kann sie anders aussehen als in der Ist-Analyse? Antwort

Jedem Anwendungsfall liegen ein oder mehrere Geschäftsprozesse zugrunde; aus dem Anwendungsfalldiagramm leitest Du deshalb Kandidaten wie „Teilgebende reichen Sessionangebote ein“ oder „Das Orga-Team erstellt einen Raumplan“ ab. Weil für die Digitalisierung oft neue Apps entstehen oder vorhandene grundlegend umgebaut werden, können die neuen Prozesse anders geschnitten sein als die der Ist-Analyse. Siehe Abschnitt „Geschäftsprozesse als digitale Geschäftsprozesse entwerfen und optimieren“

4. Welche Geschäftsprozesse solltest Du im Detail modellieren, und welchen Nutzen hat das? Antwort

Vor allem komplexe Prozesse mit unterschiedlichen Akteuren, Subsystemen oder Verantwortlichkeiten und Prozesse, in denen viele Entscheidungen fallen. Die Modelle sind in diesem Stadium noch für alle verständlich und eignen sich für ein Review mit der Fachabteilung, um Missverständnisse über den Lösungsweg früh zu klären. Siehe Abschnitt „Geschäftsprozesse als digitale Geschäftsprozesse entwerfen und optimieren“

5. Nach welchen Randbedingungen wählst Du die Modellierungstechnik für den Entwurf aus? Antwort

Unterscheidet sich der neue Prozess kaum vom bisherigen, bleibt man bei derselben Technik. Ist das Prozessverständnis gering, hilft BPMN. Ist eine nicht-technische Fachabteilung am Review beteiligt, nimmt man Techniken, die sie kennt. Je näher die technische Lösung rückt, desto eher passt das UML-Aktivitätsdiagramm, mit dem sich Kontroll- und Datenflüsse nah an der Programmierung entwerfen lassen. Siehe Abschnitt „Ablauf zentraler Geschäftsprozesse entwerfen“

6. Warum teilst Du das Aktivitätsdiagramm in Partitionen je System auf, und was klärst Du dabei schon? Antwort

Neben den Akteuren rücken nun die Systeme in den Blick: Die Partitionen zeigen, welches System welche Dienste anbietet. Zugleich lassen sich die versendeten Nachrichten einheitlich typisieren und Fehlerzustände als Ausnahmen modellieren. Im Beispiel kommen zu den Partitionen Teilgebende und Orga-Team die Kongress-App hinzu. Siehe Abschnitt „Ablauf zentraler Geschäftsprozesse entwerfen“

7. Warum ergibt eine Gesamtübersicht aller Abläufe im Aktivitätsdiagramm wenig Sinn, und wie schneidest Du die Prozesse stattdessen? Antwort

Teile wie Zeit- und Raumplanung haben eigene Abläufe, der Call for Participation ist nur lose über eine Nachricht verbunden, und die Genehmigung läuft für jedes Angebot gesondert. Besser sind eigenständige Aktivitäten mit klarem Start und Ende (z. B. Call for Participation versenden, Angebot einreichen, Angebot genehmigen, Zeitplan und Raumplan erstellen), die über Nachrichten oder Datenspeicher verbunden sind; mehrfach durchlaufene Abläufe enden mit Flow Final Nodes statt mit einem Activity Final Node. Siehe Abschnitt „Beispiel: SessionAngebots-Workflow mit der Kongress-App“

Links und weitere Informationen

• Geschäftsprozesse digitalisieren und optimieren

• Übungsaufgaben zur Digitalisierung von Geschäftsprozessen

• Ist-Analyse und Prozessanalyse: Geschäftsprozesse erfassen, bewerten und verbessern und BPMN

• UML-Aktivitätsdiagramm und UML-Anwendungsfalldiagramm

• Anforderungen ermitteln und dokumentieren

• Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Digitalisierte Geschäftsprozesse mit dem UML-Aktivitätsdiagramm entwerfen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/geschaeftsprozesse-aktivitaetsdiagramm veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/software-entwurf/gui-entwurf. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]