Digitale Geschäftsprozesse als UML Aktivitätsdiagramm entwerfen
https://bildung.social/@oerinformatik/113344907448138216
https://oer-informatik.de/geschaeftsprozess-digitalisieren-und-optimieren
tl/dr; (ca. 6 min Lesezeit): Auf Basis bestehender Geschäftsprozesse sollen die optimierten und digitalisierten Geschäftsprozesse entworfen werden. Zunächst die Übersicht aller Anwendungsfälle erstellt, die im Rahmen des Requirement Engineerings gewonnen wurde. Dann werden daraus die neuen Geschäftsprozesse abgeleitet und ermittelt, welche davon detaillierter modelliert werden müssen. Die Modellierung erfolgt diesmal mit einer Technik der Lösungsdomäne: dem UML-Aktivitätsdiagramm (Teil der Artikelserie zur Gestaltung und Entwicklung von Benutzeroberflächen für Geschäftsprozesse). (Zuletzt geändert am 22.10.2024)
Übersicht der Anforderungen an optimierte und digitale Geschäftsprozesse erhalten
Nachdem im vorigen Schritt im Rahmen einer Ist-Analyse das Umfeld, die Rahmenbedingungen, die Stakeholder und die bestehenden Geschäftsprozesse als BPMN analysiert wurden, soll es im folgenden Schritt um die Optimierung und Digitalisierung der Geschäftsprozesse gehen.
Digitalisierung ist kein Selbstzweck, sondern muss einem im Business-Case des Projekts niedergeschriebenen Benefit dienen, in dem 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äftprozesse 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 Anwendungfall liegt 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 Systen 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 aus zweierlei unterschiedlichen 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, Wissenstä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.
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 zu 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 der Anforderungs-Übersicht für eine 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 im 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 weigehend 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 unterschiedlichen 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, Misverständnisse über den Weg der Problemlösung mit Auftraggebenden / der Fachabteilung zu klären. Erstellte Diagramme, Listen, Tabellen lassen sich noch für alle erfassen - hier ist ein Reviewprozess 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 Anhängigkeit 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 einem Modellierungstool 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äftprozessen in 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 bekanntem BPMN der Ist-Analyse jetzt als Swimlanes übernehmen (Teilgebebende, Orga-Team) und um die eigentliche Konferenz-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 Modellierungtools so nicht anbieten: die Pin-Notation (orange Quadrate an Aktitivitä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 (grün), 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.
Als nächsten Schritt gilt es, aus diesem Ablauf die zugrunde liegenden UI-Zustände abzuleiten und zu modellieren.
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: “Digitale Geschäftsprozesse als UML Aktivitätsdiagramm entwerfen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/geschaeftsprozess-digitalisieren-und-optimieren veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/frontend. Stand: 22.10.2024.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
