Es wird ein einfacher Weg aufgezeigt, wie man von der Geschäftsprozessgestaltung zu den Anwendungsfällen, den darin enthaltenen durch Software unterstützten Abläufen und den benötigten Geschäftsklassenmodellen mit deren Methoden kommt. Im Ergebnis ist es möglich, von den Methoden zu den unterstützten Geschäftsprozessen und zurück zu navigieren.
War es in den Anfängen der Softwareentwicklung noch ausreichend, Daten zu speichern, zu berechnen und auszuwerten, wird heute von einer Software verlangt, ganze Geschäftsprozessabläufe in Ihrer Komplexität abzubilden. Diese Anforderung kann nicht ausschließlich durch einen einfachen Softwareentwicklungsprozess erfüllt werden, es müssen dafür die zugrundeliegenden Geschäftsprozesse betrachtet werden.
Es wird aber nach wie vor, auch von großen Softwareberatungsunternehmen, versucht die Geschäftsprozessentwicklung in einen Softwareentwicklungsprozess zu pressen. Zum Erfolg kommt man aber nur, wenn akzeptiert wird, dass die Entwicklung und Modellierung der Geschäftsprozesse ein anderes Gewerk ist, als die Modellierung einer Softwarearchitektur und deren Realisierung in einem Stück Software. Jedes Gewerk braucht seine Spezialisten und sein eigenes Vorgehen.
Dabei ist es relativ einfach mit heutigen Werkzeugen leichtgewichtig, von den Geschäftsprozessen und deren Arbeitsschritten über die Anwendungsfälle mit ihren funktionalen Anforderungen bis zu den einzelnen Funktionen bzw. Methoden und Daten einer Klasse zu gelangen.
Es ist von erheblichem Vorteil, wenn bei einer Geschäftsprozessänderung die einzelnen betroffenen Anwendungsfälle mit deren Aktivitätsdiagrammen und die betroffenen Methoden der Klassen im unmittelbaren Zugriff sind. Nur dann kann man diese den Anforderungen gemäß anpassen.
Diese Softwareänderung hat eventuelle Auswirkungen auf Arbeitsschritte in unterschiedlichen Geschäftsprozessen, welches ein unerwünschter Seiteneffekt sein kann. Mit diesem Seiteneffekte kann man jetzt unmittelbar kontrolliert umgehen. Software ist somit nicht mehr als eigenständige Sache zu betrachten, sondern ist der integrierte und nicht abzukoppelnde Bestandteil von Geschäftsprozessen.
Inhaltsverzeichnis
Vor-Vorwort ... 4
Vorwort ... 5
Um was geht es in dieser Anleitung? ... 6
Um was geht es nicht in dieserAnleitung? ... 7
Definitionen ... 8
Einleitung ... 16
Der Analytiker ... 17
Anforderungen an den Analytiker ... 17
Anforderungen Geschäftsprozess-Analytiker ... 18
Anforderungen Anforderungs-Analytiker ... 18
Anforderungen objektorientierter Analytiker ... 18
Ineinandergreifende Aufgabengebiete ... 18
Aufgabengebiet Geschäftsprozess-Analytiker ... 19
Aufgabengebiet Anforderungs-Analytiker ... 19
Aufgabengebiet objektorientierter Analytiker ... 20
Sprache als Werkzeug ... 21
Umgang mit Prozessbeteiligten ... 22
Holschuld / Bringschuld ... 22
Das Modellierungs-Werkzeug ... 23
Beim Software-Auftraggeber ... 25
Geschäftsprozessanalyse ... 25
Umgang ... 26
Geschäftsprozess beschreiben ... 26
Geschäftsprozess darstellen ... 27
Geschäftsprozess spielen ... 28
Geschäftsprozess ändern ... 29
Granularität des Geschäftsprozesses ... 29
Modellierungsebenen ... 30
Geschäftsprozess-Notationselemente ... 30
Prozesslandkarte ... 30
Kernprozess und unterstützender Prozess ... 31
Globaler Subprozess ... 31
Prozessname ... 31
Geschäfts- bzw. Datenobjekt ... 32
Rolle ... 32
Sequenzfluss und Entscheidungsknoten ... 32
Prozessschritt ... 33
Ist-Prozess ... 36
Reengineering von Geschäftsprozessen aus einem IT-System ... 38
Ursprüngliche Anforderungen nachdokumentieren ... 39
Verfahrensentwicklung ... 39
Prozessbeteiligte ... 39
Grobe Anforderungen ... 41
Fragenkatalog ... 42
Geschäftsobjekte ... 43
EAF-Antrag ... 44
EAF-Antragsausfüllhilfe ... 46
EAF-Bescheid ... 47
EAF-Akte ... 48
Erste Schritte ... 49
Weiteres Vorgehen ... 58
Mehr Geschäftsobjekte ... 59
EAF-Antragsarchiv ... 59
EAF-SteuerID-Anfrage ... 59
EAF-SteuerID-Antwort ... 60
Weitere Schritte ... 60
Szenarien durchspielen ... 64
Geschäftsprozess und Anforderung ... 64
Umfeldanalyse ... 64
Anforderungen ... 64
Funktionale Anforderungen ermitteln ... 65
Anforderungen im Steckbrief ... 66
Anforderungen zerhackstücken ... 66
Benutzergeschichte (User-Story) ... 68
Soll-Prozess ... 70
Lastenheft ... 80
Lastenheft nicht-funktionaler Anforderungen ... 80
Lastenheft funktionaler Anforderungen ... 81
Die 180 Grad Drehung ... 82
Beim Software-Auftragnehmer ... 84
Anwendungsfallanalyse ... 84
Pflichtenheft ... 84
Pflichtenheft nicht-funktionaler Lösungen ... 85
Pflichtenheft funktionaler Lösungen ... 85
Objektorientierte Softwareentwicklung ... 86
Umgang ... 87
Modellieren und beschreiben ... 88
Der Anwendungsfall ... 88
Das Objekt ... 94
Die Klasse ... 95
Generalisierung / Vererbung ... 95
Polymorphie ... 96
Kapselung / Sichtbarkeit ... 97
Attribut ... 98
Methode ... 98
Nachricht ... 100
Objektbeziehung ... 100
Objektorientierte Analyse ... 102
Umgang ... 102
Geschäftsklassen ermitteln ... 103
Anwendungsfälle ermitteln ... 103
Anwendungsfall Akteur ... 108
Anwendungsfälle vorbereiten ... 110
Anwendungsfälle definieren ... 110
Anwendungsfälle spezifizieren ... 116
Anwendungsfall mit technischem Akteur ... 116
Anwendungsfall mit menschlichem Akteur ... 126
Fazit ... 132
Objektorientiertes Design ... 133
Weiterführende Literatur ... 134
BPMN ... 134
UML ... 134
Vor-Vorwort
Ursprünglich habe ich versucht, diese Publikation "genderneutral" zu schreiben. Es wurde der Text nicht nur länger durch die vielen '/' und ':', sondern auch zunehmend unleserlicher. Nicht zuletzt soll der Text vorlesbar sein.
Ich habe mich deshalb dazu entschlossen, zwei Versionen zu schreiben; eine in der maskulinen und eine in der femininen Sprachform.
Es sei hier postuliert; dass kein Geschlecht besser als ein anderes ist und alle geschlechtsspezifischen Ausdrücke austauschbar sind.
Ich hoffe, dass es zeitnah eine verbindliche Sprachregelung gibt, die allen Geschlechtern gerecht wird.
Diese Fassung ist in der maskulinen Sprachform verfasst. Es gibt zusätzlich eine (im Inhalt gleiche) Fassung in der femininen Sprachform.
Vorwort
War es in den Anfängen der Softwareentwicklung noch ausreichend, Daten zu speichern, zu berechnen und auszuwerten, wird heute von einer Software verlangt, ganze Geschäftsprozessabläufe in Ihrer Komplexität abzubilden.
Diese Anforderung kann nicht ausschließlich durch einen einfachen Softwareentwicklungsprozess erfüllt werden, es müssen dafür die zugrundeliegenden Geschäftsprozesse betrachtet werden.
Es wird aber nach wie vor, auch von großen Softwareberatungsunternehmen, versucht die Geschäftsprozessentwicklung in einen Softwareentwicklungsprozess zu pressen. Zum Erfolg kommt man aber nur, wenn akzeptiert wird, dass die Entwicklung und Modellierung der Geschäftsprozesse ein anderes Gewerk ist, als die Modellierung einer Softwarearchitektur und deren Realisierung in einem Stück Software. Jedes Gewerk braucht seine Spezialisten und sein eigenes Vorgehen.
Dabei ist es relativ einfach mit heutigen Werkzeugen leichtgewichtig, von den Geschäftsprozessen und deren Arbeitsschritten über die Anwendungsfälle mit ihren funktionalen Anforderungen bis zu den einzelnen Funktionen bzw. Methoden und Daten einer Klasse zu gelangen.
Es ist von erheblichem Vorteil, wenn bei einer Geschäftsprozessänderung die einzelnen betroffenen Anwendungsfälle mit deren Aktivitätsdiagrammen und die betroffenen Methoden der Klassen im unmittelbaren Zugriff sind. Nur dann kann man diese den Anforderungen gemäß anpassen.
Diese Softwareänderung hat eventuelle Auswirkungen auf Arbeitsschritte in unterschiedlichen Geschäftsprozessen, welches ein unerwünschter Seiteneffekt sein kann. Mit diesem Seiteneffekte kann man jetzt unmittelbar kontrolliert umgehen.
Software ist somit nicht mehr als eigenständige Sache zu betrachten, sondern ist der integrierte und nicht abzukoppelnde Bestandteil von Geschäftsprozessen.
Um was geht es in dieser Anleitung?
Die objektorientierte Softwareentwicklung mit UML hat nur auf die Geschäftsprozessmodellierung z.B. mit BPMN gewartet. Endlich kann Software im Ablaufkontext erstellt und dokumentiert werden.
Hier wird ein einfacher Weg aufgezeigt, wie man von der Geschäftsprozessgestaltung zu den Anwendungsfällen, den darin enthaltenen durch Software unterstützen Abläufen und den benötigten Geschäftsklassenmodellen mit deren Methoden kommt. Im Ergebnis ist es möglich, von den Methoden zu den unterstützten Geschäftsprozessen und zurück zu navigieren.
Für die Ausführungen wird in dieser Publikation versucht, eine eindeutige und allgemeingültige Sprache zu benutzen. Es wird weitestgehend auf Fachausdrücke verzichtet.
Es soll aufgezeigt werden, dass es sich um keine Geheimwissenschaft handelt, welche nur spezielle Experten beherrschen, sondern dass man auch mit einem leichtgewichtigen Ansatz zum Ziel kommen kann.
Der Fokus liegt auf der inhaltlichen Arbeit wie z.B. die Modellierung und der Dokumentation der einzelnen Arbeitsergebnisse.
Das Ziel ist, einen klaren Blick, der nicht durch Modewörter verschleiert ist, auf die einzelnen Sachverhalte zu ermöglichen. Begriffe wie Objekt, Prozess, Aktivität etc. sind für jeden Arbeitsschritt eindeutig definiert und abgegrenzt.
Es werden meist deutsche Ausdrücke benutzt. Das führt mitunter zu Ausdrücken wie 'Benutzergeschichte' für die 'User-Story'.
Um die folgenden Ausführungen verstehen zu können, werden Grundkenntnisse in BPMN und UML vorausgesetzt.
Um was geht es nicht in dieser Anleitung?
Auf den vollständigen Aufbau einzelner Dokumentarten wird verzichtet.
Die Anwendung von BPMN und UML hat in dieser Anleitung nur beispielhaften Charakter. Es geht nicht vorrangig um diese Notationen. Geschäftsprozesse können genauso gut in UML-Aktivitätsdiagrammen dargestellt werden.
Es wird sich nicht damit befasst, ob die einzelnen Arbeitsschritte vom Geschäftsprozess zu den Geschäftsklassenmodellen streng nacheinander nach dem Wasserfallmodell oder iterativ, agil in kleinen Schritten oder sonst wie durchlaufen werden sollen.
Budget oder Zeitpläne, welche ein Projekt beeinflussen, bleiben dabei unberücksichtigt.
Es wird nicht die Programmierung behandelt, sondern diese Anleitung endet mit der objektorientierten Analyse.
Einleitung
Der Start einer Softwareentwicklung fängt Idealerweise mit einem Handlungsablauf an, welcher ganz oder teilweise von einem Computerprogramm ausgeführt bzw. unterstützt werde soll. Der Handlungsablauf wird auch Geschäftsprozess genannt.
Geschäftsprozesse bilden die aktuellen bzw. gewünschten Tätigkeiten ab. Diese werden möglichst technikfrei beschrieben. Alle Handhabungen werden so beschrieben, wie Menschen sie mit 'Papier und Bleistift' ausführen würden.
Wenn 'Papier und Bleistift' nicht passt, wie z.B. bei einer Maschinensteuerung, kann versucht werden den Ablauf so zu beschreiben, als könnten die technischen Einheiten selbstständig agieren. Hört sich im erstem Moment etwas skurril an, aber der Satz " Wenn Sensor X200 mit einer Feldstärke von 123 getriggert wird, wird Ventil 32 für ein Zeitintervall von 20 sec. geöffnet. " liest sich nicht so gefällig wie " Wenn das Werkstück die Position 23 unter dem Gebläse erreicht hat, wird dieses von dem Position-23-Überwacher mit dem Gebläse XY exakt 20 Sekunden von Staub befreit. "
In dieser Anleitung wird die BPMN für die Modellierung von Geschäftsprozessen und die UML für die Modellierung der technischen Seite genutzt.
Ursprüngliche Prozessschritte in 'Papier und Bleistift', welche durch eine zu entwickelnde Software abgelöst werden, verbleiben im Model und werden als solche gekennzeichnet. Damit geht das Wissen über den ursprünglichen manuellen Ablauf nicht verloren.
Die technischen Vorgänge, welche in einem Geschäftsprozess abgebildet sind, werden in UML-Anwendungsfälle überführt. In diesen wird die Außenwirkung einer Software für einen Akteur, welcher ein Mensch oder auch ein technischer Akteur sein kann, beschrieben.
Die programmierten bzw. zu programmierenden Abläufe werden in Aktivitäts- und Sequenzdiagrammen in der Regel mittels Methoden von Geschäftsklassen beschreibe.
Wenn eine vorhandene Software neu entwickelt werden soll, und kein aussagekräftiger Geschäftsprozess vorhanden ist, hat sich bewährt, zuerst durch die Analyse der vorhandenen Software einen Geschäftsprozess in 'Papier und Bleistift' zu gestalten. Man denkt sich einfach: "wie würde ein Mensch das machen?". Erst wenn der Geschäftsprozess modelliert und womöglich verbessert ist, kann mit der technischen Analyse für die neue Software begonnen werden.
Der Analytiker
In heutigen Softwareentwicklungsprojekten werden Analytiker in unterschiedlichen Rollen benötigt. In jeder dieser einzelnen Rollen muss der Analytiker zusätzliche spezielle Anforderungen erfüllen.
Anforderungen an den Analytiker
Eine ausgeprägte Auffassungsgabe und ein hohes Abstraktionsvermögen sind unabdingbar, um die Aufgaben eines Analytikers zu erfüllen.
Der Analytiker muss sich sehr früh gründlich in das jeweilige Fachgebiet einarbeiten. Komplexe Zusammenhänge müssen verstanden werden. Die Fachtermini des Analysegebiets muss erfasst und genutzt werden, um mit den Prozessbeteiligten kommunizieren zu können. Eine hohe soziale Kompetenz wird ihm abverlangt, um Aussagen der Prozessbeteiligten richtig zu interpretieren.
Die Fähigkeit geduldig zuzuhören und zur richtigen Zeit die richtigen Fragen zu stellen benötigt einen ausgewogenen Kommunikationsstil (Stichwort "aktives Zuhören"). Manchmal kann einfaches Zuhören ohne jemanden zu stören eine Herausforderung sein. Um Sachverhalte mit einer Gruppe auf einen Nenner zu bringen, müssen mehrere Moderationstechniken beherrscht werden.
Grundsätzlich soll versucht werden, komplexe Themen zu vereinfachen. Dies kann zu dem Missverständnis führen, dass man eine hochkomplexe Thematik nicht verstanden hat. Häufig stellt sich nämlich heraus, dass ursprünglich einfache Abläufe durch anflanschen von zusätzlichen Anforderungen immer komplexer geworden sind. Jede neue Anforderung wurde an den Ablauf angepasst, welches den Ablauf noch unübersichtlicher macht. Aus diesem Teufelskreis kommt man nur heraus, wenn der Geschäftsprozess mit der grundsätzlichen Anforderung neu gestaltet wird. Da ist manchmal sehr viel Geduld und Ausdauer notwendig, den einzelnen Mitarbeitern die einfachere Struktur nahe zu bringen. Auch wenn man Konsens erreicht hat, den Prozess gänzlich neu aufzusetzen, wird oft in die alten Denkstrukturen zurückgefallen.
Als Analytiker ist man in der jeweiligen Rolle der Methodenspezialist.
Anforderungen Geschäftsprozess-Analytiker
Man muss als Geschäftsprozess-Analytiker nicht unbedingt das gesamte Wissen der Prozessverantwortlichen und Prozessbeteiligten haben. Durch neutrales und zielorientiertes Vorgehen muss sich der Geschäftsprozess-Analytiker bemühen, die Prozessbeteiligten bei der Festlegung ihrer Prozesse und Vorgaben zu motivieren und zu unterstützen. Der Geschäftsprozess-Analytiker darf gegebenenfalls Tipps geben, wie etwas funktionieren kann, aber es wird den Prozessbeteiligten überlassen, die Entscheidung über den Ablauf zu treffen. Nichts nervt mehr, als ein Analytiker, der durch seine Erfahrung die Prozessbeteiligten daran hindert, ihre eigenen Prozesse selbst zu gestalten.
Ein Geschäftsprozess-Analytiker muss sich in seiner Rolle bewusst sein, dass man leicht in die 'Erfahrungsfalle' tappt. Man glaubt manchmal, einen schon einmal gestalteten Prozess wieder zu erkennen und übersieht dabei, dass der vorliegende Ablauf nur so ähnlich aussieht.
Der Geschäftsprozess-Analytiker achtet darauf, dass die Abläufe in 'Papier und Bleistift-Sprache' (also verständlich), vollständig mit allen Informationen erstellt werden und nicht in eine technische Sicht abgleiten.
Anforderungen Anforderungs-Analytiker
Der Anforderungs-Analytiker ist mehr technisch orientiert. Es wird von ihm gefordert, die funktionalen und nicht funktionalen Anforderungen an das Software-System kurz und präzise zu formulieren. Zudem muss der Anforderungs-Analytiker bei der Ausschreibung und den Angebotsbewertungen mitwirken.
Anforderungen objektorientierter Analytiker
Der objektorientierte Analytiker gestaltet das Softwaresystem. In dieser Rolle muss das objektorientierte Paradigma nicht nur bekannt sein, sondern man muss 'objektorientiert denken' können. Es wird darauf noch im Kapitel 'Objektorientierte Softwareentwicklung' auf Seite 86 eingegangen.
Ineinandergreifende Aufgabengebiete
Die aufgeführten Analytiker-Rollen sind angeführt, um eine Abgrenzung der einzelnen Tätigkeiten vornehmen zu können.
Die Ergebnisse der Tätigkeiten haben in der Regel eine höhere Qualität, wenn sie von Analytiker-Teams ausgeführt werden.
Im Folgenden wird die verzahnt Zusammenarbeit der einzelnen Analytiker-Rollen dargestellt.
Aufgabengebiet Geschäftsprozess-Analytiker
Der Geschäftsprozess-Analytiker analysiert in einer Organisation die Geschäftsprozesse. Das Ziel ist die Arbeitsabläufe der Organisation zu ermitteln und ein allgemeines und klares Verständnis über den Ablauf des Ist-Prozesses zu schaffen.
Ein weiteres Ziel kann sein, die Abläufe zu optimieren.
Über eine Soll-Prozessmodellierung erarbeitet der Geschäftsprozess-Analytiker angestrebte Änderungen des Ist-Prozesses mit den Prozessbeteiligten. Ist eine technische Unterstützung angestrebt, wird die Rolle desGeschäftsprozess-Analytikers mit der Rolle des Anforderungs-Analytikers verknüpft. In diesem Fall wird alternativ zum manuellen Ablauf ein technisch unterstützter Ablauf modelliert.
Ist ein Ziel definiert, aber der erwünschte Ablauf mit seinen notwendigen Arbeitsschritten noch nicht vorhanden, muss der Geschäftsprozess-Analytiker eventuell einen Prozess erst kreieren bzw. entwickeln. In dem Fall muss sich der Geschäftsprozess-Analytiker zusätzlich mit dem fachlichen Umfeld und dem Vorgehen ggf. einer ganzen Branche auseinandersetzen, um für das anvisierte Ziel den effizientesten Ablauf zu modellieren.
Aufgabengebiet Anforderungs-Analytiker
Der Anforderungs-Analytiker ermittelt aus dem Soll-Prozess die funktionalen Anforderungen an eine technische Umsetzung. Er prüft, ob eine technische Umsetzung im ausreichenden Umfang vorhanden ist bzw. angeschafft werden kann oder neu erstellt werden muss.
Der Anforderungs-Analytiker prüft darüber hinaus die nicht funktionalen Anforderungen wie z.B. die Systemvoraussetzungen (Hardware, Betriebssysteme, Kommunikationsinfrastruktur etc.).
Wenn die Software selbst entwickelt werden soll, muss der Anforderungs-Analytiker sich zusätzlich mit einem Vorgehensmodell zur Softwareentwicklung, der Programmiersprache, Benutzeroberflächenrichtlinien, Standards, Mitarbeiterschulung etc. auseinandersetzen.
Aufgabengebiet objektorientierter Analytiker
Aus den Prozessschritten, welche von der IT unterstützt werden sollen, modelliert der objektorientierte Analytiker in der objektorientierten Analyse Anwendungsfälle, Geschäftsklassen, technische Abläufen in Aktivitätsdiagrammen und Sequenzdiagrammen. Dieses ist die Grundlage für das objektorientierte Design und die objektorientierte Programmierung.
Es wird dafür eine hohe technische Affinität erwartet. Er sollte sich in die Arbeitswelt eines Programmierers hinein versetzen können bzw. aus der Softwareentwicklung kommen. Erforderlich wird diese Rolle, wenn die Software in einer objektorientierten Sprache implementiert werden soll.
Eventuelle Anpassungen an den Soll-Prozessen, initiiert durch die objektorientierte Analyse, wird der Geschäftsprozess-Analytiker wiederum in Absprache mit den Prozessbeteiligten in den Soll-Prozess einarbeiten.
Wenn ein Prozess aus einem vorhandenen System ermittelt werden muss und keine Dokumentation über die zugrunde liegenden Geschäftsprozesse vorliegt, ist ein spezieller Software-Analytiker gefragt. Er muss den Quelltext lesen und verstehen und daraus im Idealfall einen Geschäftsprozess ableiten können.
Wenn modellbasiert gearbeitet wird, sind Modellverantwortliche zu etablieren. Diese haben über ihren Modellbereich den Überblick und die Hoheit, damit das Modell nicht durch unkoordinierte Änderungen korrumpiert wird.
Sprache als Werkzeug
Nicht zuletzt muss sich der Analytiker sprachlich einfach, schnörkellos und eindeutig auszudrücken wissen.
Wird etwas sehr kompliziert und damit schwer verständlich ausgedrückt, wird dieses auch häufig 'abgenickt', weil "der wird es schon wissen". Das ist aber keine Bereicherung für diejenigen, welche den Text lesen und verstehen müssen. Nachfragen, wie das gemeint sei, zeugt dann nicht unbedingt von der Unfähigkeit des Lesenden, sondern evtl. vom Unvermögen des Schreibenden.
Genauigkeit in der Sprache wird häufig aus sozialen Gründen vernachlässigt. Wir haben gelernt im Gespräch etwas vage zu bleiben, um dem Gegenüber die Möglichkeit der Mitgestaltung einzuräumen. Wenn wir einen einfachen Sachverhalt kompliziert darstellen, bekommt dieser gegebenenfalls etwas mehr Gewicht, respektive wir bekommen so etwas mehr Gewicht. Unpräzise interpretative Beschreibungen, verkompliziert und eventuell gespickt mit Fremdworten, ermöglichen uns häufig die Verschleierung eigener Unsicherheit.
Ungenauigkeiten zu erkennen, ist immer wieder eine hohe Herausforderung. Selbst Kleinigkeiten wie "Es wird der Zeitraum bis zum Datum des Zahlungsziels betrachtet." hat seine sprachliche Tücke; ist das Datum des Zahlungsziels mit im Fokus oder nicht? Hier fehlt noch ein Wort wie inklusive oder exklusive. Als hilfreich hat sich erwiesen, Texte durch nicht beteiligte Personen interpretieren zu lassen.
Auch werden Analytiker nicht nach der Anzahl der geschriebenen Worte bezahlt, sondern nach der kurzen prägnanten Analyse. Das wird nicht immer anerkannt; man muss sich dann mal anhören: "Und für diesen einfachen Ablauf haben Sie so lange gebraucht? Das hätten wir dann ja auch selbst machen können!". Ja, konnten sie nicht, deshalb wurde der Analytiker hinzugezogen, da war halt das Vereinfachen eines komplexen Ablaufes die aufwändige Wertschöpfung.
Die Einhaltung von sprachlichen Formalien und eine interpretationsfreie und exakte Beschreibungssprache anzustreben hilft meist weiter. Die Sprache muss als Werkzeug begriffen werden.
Umgang mit Prozessbeteiligten
Sehr wichtig ist der richtige Umgang mit dem einzelnen Prozessbeteiligten. Unabhängig von seinen Fähigkeiten hat jeder Prozessbeteiligte das Recht auf gleichbleibende Wertschätzung, auch wenn er dem Projekt kritisch gegenübersteht.
Holschuld / Bringschuld
Es sollte grundsätzlich versucht werden, die Holschuld durch Bringschuld zu ersetzen. Es müssen, wenn nicht schon vorhanden, eindeutige Ablagestrukturen für anfallende Dokumente und ein Benachrichtigungssystem etabliert werden. Alle Beteiligte werden über Beschlüsse, Erweiterungen, Änderungen etc. aktiv informiert. Beteiligte sollen nicht darauf angewiesen sein, selbst Informationshalden durchstöbern zu müssen, um auf dem neuesten Stand zu sein.
Aber Achtung! Bringschuld heißt nicht nur einfach alles jedem zu senden. Bewährt hat sich z.B. ein tägliches kurzes Treffen bei dem jeder Beteiligte seine Bringschuld einlösen kann.
Das Modellierungs-Werkzeug
Sie kennen das vielleicht, einen Geschäftsprozess oder Softwareentwurf in Prosa, der sich auf über 100 Seiten Text (Arial Schriftgrad 11 ohne grafischen Ablauf) verteilt. Schon die Anzahl der Seiten macht Angst, diese Menge an Informationen erfassen zu können. Die Meisten steigen spätestens bei der dritten Verzweigung im Text aus, weil sie nicht mehr wissen wo sie hergekommen sind bzw. wohin sie zurückblättern müssen. Wenn grafische Abläufe vorhanden sind, dienen diese nur der Anreicherung des Dokuments.
Vielleicht kennen Sie auch ein anderes Phänomen, eine Menge an Abläufen in einer Modellierungsnotation ohne viel Text. Manchmal sind nur die Kästchen und Linien bezeichnet. Nur Eingeweihte wissen, was da gemeint sein könnte. Implizites Wissen wird vorausgesetzt; neue Mitarbeiter haben es schwer. Nach einem Jahr weiß nicht mal mehr die Autorin, was er da modelliert hat.
Und dann gibt es häufig auch eine Mischform, in der die Informationen mal in Dokumenten als Prosatext und zusätzlich in grafischen Abläufen gehalten werden oder in grafischen Abläufen mit Verweisen auf irgendwelche Dokumente; ganz nach den Vorlieben der einzelnen Mitarbeiter. In diese Mischform ist es am schwierigsten zu arbeiten. Keiner weiß so genau, wo was beschrieben ist und was davon aktuell ist.
Es kann davon ausgegangen werden, dass eine Textverarbeitung kein Modellierungswerkzeug ersetzt und dass ein Modellierungswerkzeug die geschriebene Sprache nicht ersetzen kann. Prosa alleine ist also nicht geeignet, einen komplexen Ablauf eindeutig zu beschreiben sowie grafisch modellierte Abläufe ohne das geschriebene Wort nicht zufriedenstellend informieren.
Grafische Abläufe lassen sich einfacher überblicken. Das Navigieren fällt leichter. Ein Notationselement in einer Grafik, ob nun Geschäftsprozess, Prozessschritt, Anwendungsfall oder Klasse ohne eindeutiger Erklärung in Prosa, ist ein überflüssiges grafisches Element.
Es muss frühzeitig eingegriffen werden, wenn Mitarbeiter meinen, dass grafische Abläufe und deren Elemente in einer grafischen Notation wie BPMN oder UML ohne sprachliche Beschreibung ausreichen.
Ein grafisches Modellierungswerkzeug sollte "führendes System" sein. Das heißt, dass in dem Modellierungswerkzeug z.B. die Prozessschritte oder Klassen etc. als grafische Objekte mit ihren Eigenschaften und Beziehungen und ihren Beschreibungen verwaltet werden.
Ein gutes BPMN-Modellierungswerkzeug verwaltet zusätzlich die einzelnen fachlichen Anforderungen, welche die resultierenden Geschäftsprozesse bzw. Prozessschritte referenzieren.
Die Möglichkeit der Navigation von mehrfach verwendeten Prozessschritten zu den einzelnen unterschiedlichen Geschäftsprozessen ist eine Voraussetzung, um bei einer Prozessschrittänderung alle eventuell betroffenen Geschäftsprozessen zu identifizieren. Damit ermöglicht das Modellierungswerkzeug die Überprüfung, ob durch Änderung einer Anforderung andere Anforderungen weiter erfüllt bleiben.
Ein Modellierungswerkzeug für BPMN und UML sollte gewährleisten, dass man einem einzelnen Prozessschritt bzw. einer Gruppe von Prozessschritten (BPMN) einem Anwendungsfall (UML) zuordnen kann. Über die Anwendungsfälle müssen deren Aktivitätsdiagramme mit den einzelnen Methoden von Klassen erreichbar sein. Über die Methode einer Klasse müssen alle anderen UML-Diagramme referenziert werden können, welche diese Methode auch nutzen.
Sehr nützlich ist auch eine gegenseitige Referenzierung von Geschäftsobjekten aus dem BPMN-Geschäftsprozess zu Klassen im UML-Model.
Das alles sollte weitestgehend automatisch, ansonsten intuitiv, zu bewerkstelligen sein. Zusätzlich sollte die Referenzierung bidirektional (also auch von der Methode einer Klasse bis zur Anforderung im Prozessschritt) ausgelegt sein.
Wenn in einem Aktivitätsdiagramm Methoden von Klassen genutzt werden, muss das Modellierungswerkzeug die Möglichkeit bieten, zusätzlich zur Beschreibung der aufgerufenen Methode eine Beschreibung für den Aufruf dieser Methode im jeweiligen Aktivitätsdiagramm zu erstellen. Nur so kann man kontextspezifische Informationen wie z.B. Parameterwerte formulieren.
Wenn das vorhandene Modellierungswerkzeug obige angesprochene Voraussetzungen nicht erfüllt, kann man sich mit sprachlich eindeutigen Verweisen helfen. Dieses bedingt aber, dass alle Mitarbeiter diese Verweise in allen Arbeitsschritten diszipliniert vornehmen.
Ein Modellierungswerkzeug ersetzt nicht fundierte Kenntnisse in der Geschäftsprozess- bzw. objektorientierten UML-Modellierung und einen klaren sprachlichen Formulierungsstiel.
Der Einsatz eines grafisches Modellierungswerkzeugs erleichtert die Modellierung von Abläufen (ob nun Geschäftsprozesse oder technische Abläufe), erhöht aber die Anforderungen (ein Programm will beherrscht sein).
Beim Software-Auftraggeber
Das hier vorgestellte Vorgehen kann nur funktionieren, wenn der Auftraggeber einer Software die spezifischen Geschäftsprozesse verstehen und unterstützt haben möchte. Das Unterfangen, die Geschäftsprozesse zu modellieren, muss akzeptiert und die Kosten dafür transparent sein. Die Verantwortung für die Entscheidung, die betroffenen Geschäftsprozesse zu modellieren und eventuell neu zu gestalten liegt alleine bei dem Auftraggeber. Es muss dem Auftraggeber klar sein, dass ein Geschäftsprozessmodell ein abgegrenztes Gewerk (in Anlehnung an die Bauwirtschaft) ist.
Geschäftsprozessanalyse
Geschäftsprozesse müssen so modelliert sein, dass ein gemeinsames Verständnis über die Wertschöpfungskette erreicht wird. Eine verständliche Geschäftsprozessmodellierung hat dadurch einen vielschichtigen Nutzen für alle Prozessbeteiligte.
Nur wenn Geschäftsprozesse transparent dokumentiert werden, sind diese vermittel- und gestaltbar.
Es können daraus eindeutige Arbeitsanweisungen z.B. an die Mitarbeiter, die in verschiedenen Rollen am Geschäftsprozess teilnehmen, abgeleitet werden.
Sollte eine Zertifizierung z.B. nach ISO 9000 angestrebt werden, sind transparente Geschäftsprozesse dafür eine Bedingung.
Zusätzlich ist durch eine zeitliche und finanzielle Bewertung der einzelnen Prozessschritte eine bessere Abschätzung der Laufzeit und eine einfachere Kostenkontrolle bzw. Kostenschätzung möglich.
Über einen Geschäftsprozessablauf hat man die Möglichkeit, angedachte IT-Unterstützung in einem klaren Arbeitskontext einzuordnen. Resultierende Anwendungsfälle lassen sich über einen referenzierten Geschäftsprozessablauf in eine Reihenfolge bringen. Die UML bietet keine ausreichende Modellierungsmöglichkeit, um eine abzuarbeitende Reihenfolge von Anwendungsfällen darzustellen.
Nicht zuletzt liegt der Vorteil in einer vorhandenen Geschäftsprozessmodellierung darin, dass der Prozessablauf auch nach Entwicklung einer technischen Unterstützung bzw. Umsetzung weiterhin für die Geschäftsprozessbeteiligten erhalten bleibt.
Sollte die technische Umsetzung neu erstellt werden müssen (z.B. wegen neuer technischer Infrastruktur, neuer Programmiersprache oder ähnlichem), ist eine aufwändige Anforderungsanalyse nicht mehr notwendig.
Es hat sich bewährt das Geschäftsprozessmodellierungsteam personell wachsen zu lassen. Ein Anfangs schon zu großes Team liefert ggf. keine homogene Arbeit. Verschiedene Vorgehensweisen können zu erheblichen Reibungsverlust führen. Lieber einen Kern von eingeschworenen Modellierern langsam aufstocken und dann aufteilen.
Umgang
Um Geschäftsprozesse nicht in eine technische Sicht abgleiten zu lassen, hat es sich bewährt, immer in 'Papier und Bleistift' zu modellieren. Ein Prozessschritt bekommt z.B. nicht einen Datensatz im XML-Format, sondern eine "Rechnung", "Lieferschein" oder ein "Formular XY". Auch ein Geschäftsprozess, welcher modelliert wird um technisch umgesetzt zu werden oder schon umgesetzt ist, wird so modelliert, als ob es diese technische Unterstützung nicht gibt. Man erzielt dadurch eine rein fachliche Klarheit und ermöglicht ein einfaches 'Nachspielen' des Prozesses durch Personen.
Geschäftsprozess beschreiben
Eine vollständige verständliche Beschreibung eines jeden Prozessschrittes ist Voraussetzung, um diesen auch noch nach einiger Zeit zu verstehen. Es werden in einer Beschreibung eines Prozessschrittes niemals alle "relevanten Daten" bearbeitet, sondern jede notwendige Information zur Bearbeitung mit sprechenden Namen benannt.
Einen Prozessschritt mit der Beschreibung: "Die Rechnung wird nach den allgemein gültigen Richtlinien geprüft." wird so nicht akzeptieren. Erst wenn alle zu prüfenden Sachverhalte, am besten noch mit einer Begründung warum, aufgeschrieben werden, kann damit produktiv weitergearbeitet werden. Ob ein Mitarbeiter die Rechnung prüfen, oder ob dieses für elektronische Rechnungen ein Programm machen soll, ist zunächst unerheblich. Die Information was da wie und warum geprüft wird ist obligatorisch; zumal sich die 'allgemein gültigen Richtlinien' jederzeit durch Neuinterpretation ändern können.
Wenn in einem Prozess mit Gegenständen, wie z.B. einer Rechnung, hantiert wird, werden alle notwendigen Inhalte ermittelt und mit allen Anforderungen und Einschränkungen beschrieben.
Es wird im Geschäftsprozess nichts gespeichert, sondern an einem namentlich benannten Ort (vielleicht in eine Akte?) abgelegt. Der Geschäftsprozess lebt gegebenenfalls länger als die technologische Unterstützung und Festplatten gibt es wahrscheinlich nur, weil das dauerhafte Vorhalten aller Informationen im Arbeitsspeicher eines Rechners (noch) zu teuer ist. Evtl. wird das "Speichern einzelner Datensätze" in einer Datenbank in naher Zukunft ein Anachronismus sein. Die ersten Schritte sind mit den "nichtmechanischen Festplatten", kurz "SSD" schon gemacht.
Bei Nominalisierungen wie z.B. 'Fehlerprüfung' sollte der dahinter liegende Prozess genau untersucht und beschrieben und bei einem wachsenden Umfang als solcher modelliert werden.
Wichtig ist, dass alle Prozessschritte, auch die ohne IT-Bezug, in gleicher Qualität modelliert werden! Es wird ein Prozessablauf ohne Interpretationsspielraum abgebildet.
Es soll versucht werden, von einem groben Prozessablauf (den auch z.B. ein Vorgesetzter oder „nicht Eingeweihter" nachvollziehen kann) auszugehen und dann durch den Einsatz von Sub-Geschäftsprozessen eine ausreichende Granularität zu erreichen. In jeder Ansicht soll der Geschäftsprozess einen Überblick über den Ablauf ermöglichen; also nicht zu viele Prozessschritte enthalten.
Ziel ist, bei allen Prozessbeteiligten einen Konsens im Verstehen zu erreichen. Es ist nicht ausreichend, ausschließlich ein Diagramm zu malen und dieses zu beschriften, sondern es wird jeder Prozessschritt genau (in Prosa und gegebenenfalls unterstützt durch Tabellen und Bildern) beschrieben. Wenn nicht aus dem Diagramm ersichtlich, muss die Rolle benannt werden, der ein Prozessschritt zugeordnet ist.
Notwendig ist die Angabe des benötigten Inputs, welcher benötigt wird, um den Prozessschritt abzuarbeiten. Wenn die benötigten Informationen nicht vom Vorläuferprozessschritt geliefert werden, ist die Angabe der Herkunft wichtig. "Was ist nötig um eine benannte Wertschöpfung von einer benannten Rolle wie, wenn wichtig in welcher Zeit und/oder zu welchen Kosten und in welcher Qualität zu erbringen"?
Es wird immer das Ergebnis des Prozessschritts und der Output beschrieben.
Einen Prozess muss nicht jeder verstehen. Wenn ein fachlicher Prozess bzw. die erklärende Beschreibung von einem nicht an der Geschäftsprozessmodellierung beteiligten Fachmann verstanden wird, ist dass ausreichend; wenn nicht, sollte der Prozess besser modelliert bzw. beschrieben werden.
Geschäftsprozess darstellen
Eine klare Vorgabe, wie eine Geschäftsprozessmodellierung aussehen und beschrieben werden soll ist Voraussetzung, um bei den Prozessbeteiligten Vertrauen zu erzeugen. Das soll nicht bedeuten, dass die Granularitätsstufen bzw., Modellierungsebenen festgelegt werden müssen. Hier darf man dem analytischen Verstand und nicht zuletzt dem Gefühl vertrauen.
Es ist nicht unerheblich, für die grafische Darstellung der Geschäftsprozesse die gewählte Notation bzw. die Verwendung einer Untermenge (Subset) der verfügbaren Notationselemente, festzulegen. Die Anzahl der zu benutzenden Notationselemente sollte so klein wie möglich und so groß wie nötig sein. Auf jeden Fall sollten keine "werkzeugspezifischen", vom Standard abweichende, Notationselemente genutzt werden.
Es kommt bei der grafischen Darstellung der Geschäftsprozesse nicht auf "technische" bzw. "architektonische" Raffinesse an, sondern auf das Prozessverständnis der Prozessbeteiligten. Es können z.B. Datenobjekte verwendet werden. Wenn die Prozessbeteiligten besser damit zurechtkommt, in jedem Prozessschritt die notwendigen Eingangs-Informationen und das Ergebnis in Prosa oder als Bild (z.B. ein Formular kommt rein und wird ausgefüllt weitergereicht) zu beschreiben, muss man dieses so tun.
Damit die grafischen Darstellungen der Geschäftsprozesse von allen Beteiligten ohne zusätzlichen Lernaufwand "gelesen" werden können, ist eine projektweite Einhaltung von transparenten Modellierungsrichtlinien notwendig. Die Modellierungsrichtlinien können iterativ erweitert werden. Zu beachten ist aber auch, eine Überregulierung zu vermeiden, um die Modellierung nicht zu behindern. Das zu verwendende Modellierungswerkzeug sollte mit seinen evtl. vielen Möglichkeiten nicht Maßstab sein.
Geschäftsprozess spielen
Gute Ergebnisse werden erzielt, wenn die Geschäftsprozesse im Team bestehend aus mindesten zwei Analytikern und mehreren Prozessbeteiligten bei Arbeitstreffen modelliert werden. Durch die unterschiedlichen Sichtweisen der beteiligten Teilnehmer kann eine hohe Qualität erreicht werden.
Um einen Geschäftsprozessablauf zu prüfen, können die einzelnen Teilnehmer die einzelnen Prozessschritte 'spielen', also die spezifische Rolle einnehmen. Es ist sehr hilfreich, wenn die an der Geschäftsprozessmodellierung beteiligten Personen den Geschäftsprozess in ihrer Rolle abwickeln. Es wird dann in der Regel die gewünschte Qualität des Inputs klarer gefordert, man ist ja jetzt unmittelbar betroffen. Schnell stellt sich heraus, was noch für das angestrebte Ergebnis fehlt, um für den nächsten Prozessschritt einen akzeptablen Input zu gewährleisten.
Der Geschäftsprozess ist dann valide, wenn die einzelnen Prozessschritte in ihrer Reihenfolge ohne Missverständnisse durchgespielt werden können.
Geschäftsprozess ändern
Geschäftsprozesse sind oft auch ohne gewollter Prozessumgestaltung einer permanenten Veränderung unterworfen. Diese Veränderungen sind notwendig, um den sich schnell wechselnden Anforderungen gerecht zu werden. Veränderungen bzw. Änderungsvorschläge sollten nicht unterbunden oder sonst wie verhindert werden weil damit evtl. die teuer analysierten Geschäftsprozesse gefährdet sein könnten.
Änderungsvorschläge müssen positiv betrachtet werden. Wenn sich daraus Verbesserungen ergeben, müssen diese wertgeschätzt und als Änderung des Geschäftsprozesses eingeführt werden.
Wenn der zu ändernde Geschäftsprozesses von Software unterstützt bzw. abgewickelt wird, ist ggf. auch diese anzupassen.
Um diesen Umstand gerecht zu werden, müssen die Modelle der Geschäftsprozesse zeitnah an die akzeptierten Gegebenheiten angepasst werden. Um dieses zu gewährleisten, ist es vorteilhaft, für eine Gruppe von Geschäftsprozessen oder Datenobjekten mindestens einen Verantwortlichen zu benennen. Dessen Tätigkeit und Interessen, sein Modell aktuell und sauber zu halten, muss im Unternehmen anerkannt sein und mit dem notwendigen Mandat unterstützt werden.
Granularität des Geschäftsprozesses
Was ist das richtige Maß? Da gehen die Meinungen weit auseinander und das richtige Maß für alle gibt es nicht!
Es sollen die Geschäftsprozesse so granular modelliert sein, dass alle Beteiligte den Prozessablauf vollständig ohne Nachfrage nachspielen können. Wenn die textuelle Beschreibung eines einzelnen Prozessschrittes zu groß wird, die Konzentration über Gebühr beansprucht oder durch Alternativabläufe zu unverständlich wird, sollte dieser Prozessschritt in einzelne Prozessschritte einem Sub-Geschäftsprozess aufgelöst werden. Die Prosabeschreibung des Sub-Geschäftsprozesses beschreibt den Ablauf dann gröber mit dem Hinweis, dass der genaue Ablauf aus den einzelnen Prozessschritten ersichtlich ist.
Ist für einen Beteiligten der Ablauf zu feingranular oder wird in seinen einzelnen Schritten zu 'mächtig', kann es helfen, logische Bereiche in Sub-Geschäftsprozessen zusammen zu fassen und diese nur zu 'öffnen', wenn Interesse am genauen Ablauf besteht.
Modellierungsebenen
Manchmal ist man versucht, vor der Geschäftsprozessanalyse Modellierungsebenen festzulegen, wie zum Beispiel: "Ein Sub-Prozess darf keinen weiteren Sub-Prozess enthalten." oder "Nur in der Kernprozessebene darf die Kommunikation mit externen Geschäftspartnern modelliert sein.".
Es gibt nicht die goldene Regel wie z.B. "Es gibt bei uns genau 3 Ebenen…". Wenn ein Prozessschritt nicht ausreichend in Prosa erklärt werden kann, wird er eben, wie schon erwähnt, als Sub-Geschäftsprozess feiner ausmodelliert, wahlweise mit oder ohne Beschreibungsanpassung. Wenn die Beschreibung nach wie vor den jetzt feiner granulierten Ablauf in seiner Genauigkeit beschreiben soll, muss dieser bei Ablaufänderung mitgeändert werden. Auch wenn dieses als Redundant bezeichnet werden muss.
Geschäftsprozess-Notationselemente
In diesem Kapitel wird nicht auf alle Geschäftsprozess-Notationselemente eingegangen, sondern nur diese herausgestellt, bei denen es unterschiedliche Auffassungen geben kann.
Prozesslandkarte
Das beauftragende Management ist begeistert, wenn nach kurzer Zeit eine Prozesslandkarte mit den wichtigsten Prozessarten erstellt ist und die ersten Abläufe im Unternehmen durch sinnvolles aneinander reihen von Kernprozessen modelliert erscheinen. Wird meist als Grafik an die Wand geworfen und sieht natürlich nach einem Superablauf aus; aber keiner weiß, was wie im Einzelnen gemacht wird; muss das Management ja auch nicht wissen.
Schwer zu vermitteln ist dann später, dass die Arbeit jetzt erst anfängt. Erinnert ein bisschen an Prototypenbau, da meinte auch oft das Management, wenn es ein paar Dialogmasken sieht, das wäre alles schon so gut wie fertig. Zudem wird die Modellierungsgeschwindigkeit von ganz schnell immer langsamer, da es ja irgendwann doch genau werden muss. Das wird vom Management nicht immer verstanden.
Bessere Ergebnisse erzielt man, wenn sich darauf konzentriert wird, eine grobe Prozesslandkarte aufzubauen. Die Prozesslandkarte hilft, die bekannten Prozesse aufzulisten und zu strukturieren. Jeder Prozess, welcher modelliert werden soll, wird als solcher gekennzeichnet.
Im Folgenden werden die Prozesse nach einer Priorisierung bearbeitet und nach Fertigstellung als solches markiert.
Für die Prozesslandkarte sollte nicht die BPMN genutzt werden, da es sich nicht um einen eindeutigen Ablauf handelt. Als Beispiel dafür mag gelten, dass der Einkauf ein Produkt wie Rotwein einmal im Jahr einkauft, einlagert und dann sukzessive über mehrere Jahr verkauft. Es folgt also auf den Einkauf nicht immer direkt der Verkauf.
Die Prozesslandkarte soll während der Modellierung der einzelnen Geschäftsprozesse erweitert und angepasst werden.
Kernprozess und unterstützender Prozess
Ob ein Geschäftsprozess nun ein Kern- oder ein unterstützender Geschäftsprozess ist, liegt im Auge des Betrachters. Der Prozesseigner sieht häufig seinen Geschäftsprozess als Kernprozess und die anderen Geschäftsprozesse als unterstützende Prozesse. Aus einer anderen Perspektive kann ein Kernprozess aber auch nur ein einfacher, einzelner Prozessschritt sein; wer möchte da hingehen und die Geschäftsprozesse gleich zu Anfang klassifizieren.
Brisanz bekommt die Zuordnung der Geschäftsprozesse zu einzelnen Prozessarten, wenn diese mit zusätzlichen unterschiedlichen Anforderungen oder Einschränkungen verknüpft werden. Besonders weil die Definition von unterstützenden Geschäftsprozessen häufig den Verdacht aufkommen lässt, dass diese ausgelagert werden könnten.
Globaler Subprozess
Wenn ein Subprozess mehrfach in verschiedenen Prozessen als globaler Subprozess verwendet wird, muss darauf geachtet werden, dass dieser nicht mit unterschiedlich definierten Sequenzflüssen (transportieren z.B. unterschiedliche Datenobjekte) eingebunden wird ohne dass für jeden Sequenzfluss ein entsprechendes Startereignis im globalen Subprozess existiert. In diesem Fall muss der globale Subprozess für jeden Sequenzfluss ein entsprechendes Startereignis bekommen oder es müssen einfließenden Sequenzflüsse ein gleiches Datenobjekt transportieren.
Prozessname
Prozessnamen enthalten ein Substantiv verbunden mit einem Verb. Manchmal gibt es Diskussionen, ob es nun 'EinkaufWeißeWare', 'WeißeWareEinkauf', 'Einkaufen WeißeWare' oder 'WeißeWare einkaufen' heißen soll. Es sollte sich auf eine Notation geeinigt werden.
Wenn eine Nummerierung gewünscht wird, sollte es diese ausschließlich ohne Kontextbezug geben.
Die Geschäftsprozessart sollte nicht im Namen kodiert genutzt werden, da bei einer Änderung der Geschäftsprozessart der Namen in allen erstellten Dokumenten, wo dieser Name genutzt wird, angepasst werden muss.
Geschäfts- bzw. Datenobjekt
Häufig wird sich auf das sogenannten Geschäfts- bzw. Datenobjekt gestürzt. Eine Inflation von diesen Objekten ist zu beobachten, wenn z.B. Datenbankentwickler oder Programmierer mit der Geschäftsprozessmodellierung betraut werden. Es entstehen dann umfangreiche Datenbankmodelle, welche die fachlichen Mitarbeiter oft verwirren.
Viel Geschäfts- bzw. Datenobjekte suggerieren eine hohe und schnelle Wertschöpfung. Man hat ja viel auf der Tapete. Prozessschritte werden eher wie Datenmanipulierschritte gestaltet. Im Verlauf der Modellierung muss immer mehr Rücksicht auf die vorhandenen Daten und die bislang modellierten Abläufe genommen werden (Änderungen eines Datenobjektes beeinträchtigen Geschäftsprozessabläufe).
Es sollte soweit wie möglich Gegenständlich geblieben werden. Wenn die Prozessbeteiligten schon in einer technischen Sprache sprechen, muss versucht werden, wieder auf die fachlichen Gegenstände zurück zu kommen. Also z.B. von einem Datensatz mit Rechnungsdaten auf eine Rechnung zu kommen, welche man dann von einem Prozessschritt zum andern weiterreicht.
Jedes Geschäftsobjekt muss eine eindeutige Beschreibung haben.
Rolle
In einigen Projekten wird anfangs kein Wert auf Rollen gelegt. Es scheint zu reichen, wenn Prozessschritte einer Abteilung zugeordnet waren.
Wenn man früh Rollen definiert, ist der Mehrwert nicht zu unterschätzen.
Die Prozessverantwortlichen bekommen durch die Zuordnung einer eindeutige Rolle zu einem Prozessschritt eine Vorlage, Mitarbeiter gezielt über die Rollen Aufgaben in bestimmten Prozessen zuzuweisen.
Sequenzfluss und Entscheidungsknoten
Es gibt Projekte, in denen festgelegt wird, dass jeder Entscheidungsknoten eine Bezeichnung bekommt wie z.B. "ermittelter Wert ist positiv" und die zwei abgehenden Sequenzflüsse ein "Ja" oder "Nein". Das hatte mehrere Nachteile. Zum einen ist man mit den beiden möglichen Sequenzflüsse doch sehr eingeschränkt und zum anderen sind die Leser verwirrt, wenn von einem Entscheidungsknoten z.B. mit der Negation "Wert ist nicht valide" zwei Sequenzflüsse "Ja" und "Nein" abgehen.
Die größte Akzeptanz bekommt man mit Entscheidungsknoten ohne Bezeichnung und Sequenzflüssen mit einer sprechenden kurzen Bezeichnung. Wahlweise kann dem Entscheidungsknoten als Bezeichnung eine Frage gegeben werden, wie z.B. "Farbe?" und die einzelnen Sequenzflüsse bekommen unter anderem die Bezeichnungen "Rot", "Grün" und "Gelb".
Prozessschritt
Damit Prozessschritte einfach verfasst und gelesen werden können, kann eine Schablone helfen alle wichtigen Informationen für einen Prozessschritt aufzunehmen:
- Name des Prozesses bzw. Prozessschritts
Der Name des Prozessschrittes sollte immer das Tun mit Etwas
ausdrücken und sollte so kurz wie möglich sein. Der Name muss
eindeutig sein.
- Aufgabe des Prozesses bzw. Prozessschrittes
Kurze Beschreibung was hier passiert, am besten in ein, zwei Sätzen.
- Motivation
Kurze Beschreibung, warum dieser Prozessschritt benötigt wird. Es kann
hier auf die jeweiligen Anforderungen verwiesen werden, wenn diese die
Notwendigkeit beschrieben haben.
- Rollen bzw. Akteure
Die Bezeichnung des Akteurs, der diesen Prozessschritt abarbeitet.
- Input
Was bekommt der Akteur übergeben, um diesen Prozessschritt abarbeiten
zu können. Das kann eine Rechnung, Antrag, anderweitige Information
oder ein beliebiges Werkstück sein. Die Bezeichnung und Beschreibung
muss eindeutig sein.
- Textuelle Beschreibung
Es wird in eindeutiger Prosa beschrieben, welche Arbeitsmittel nötig
sind, um eine benannte Wertschöpfung, von einem benannten Akteur wie,
in welcher Qualität, und wenn notwendig in welcher Zeit und/oder zu
welchen Kosten, erbringen zu können.
Es wird die Sprachform Präsens benutzt. Worte wie "kann", "würde"
"eventuell" etc. werden vermieden. Es werden nicht alle relevanten Daten
geprüft, bearbeitet oder ähnliches, sondern es werden die
einzelnen Informationen benannt und es wird beschrieben was damit genau
geschieht. Ziel soll es sein, dass "jeder mit der notwendigen
Qualifikation" nach dem Lesen dieser Beschreibung ohne Nachfrage die Rolle
einnehmen kann und das gewünschte Ergebnis erzielt.
Wenn es alternative Tätigkeiten des Akteurs gibt, sollte zuerst der
Standardablauf und dann die alternativen Abläufe beschrieben werden.
- Ergebnis
Es wird das Ergebnis bzw. es werden die möglichen Ergebnisse des
Prozessschrittes aufgeführt. Es sollte unbedingt die
Wertschöpfung ersichtlich sein.
- Output
Was bekommt der Akteur des Folgeprozessschritts übergeben, um diesen
abzuarbeiten. Es kann auch mehrere verschiedene Outputs geben. Ansonsten
gilt hier das gleiche wie für den Input.
- Status
Nicht immer ist es möglich, bei der Prozessmodellierung alle
benötigten Informationen zu erhalten. Wenn Details zurzeit nur
rudimentär bekannt sind, kann dieser Prozessschritt nur wage
beschrieben werden. Um die Modellierung des Ablaufs nicht durch Ermittlung
der benötigten Details auszubremsen, ist es häufig notwendig, die
fehlenden Details später zu ermitteln um diese in der Beschreibung des
Prozessschrittes nachzutragen.
Dann wäre zum Beispiel der Status: 'in Arbeit' mit Hinweis was noch
fehlt.
Es muss sichergestellt sein, dass diese Prozessschritte zu finden sind bzw.
nicht vergessen werden können.
- Referenzen
Abhängig von den Möglichkeiten des eingesetzten
Modellierungswerkzeugs müssen Referenzierungen eventuell manuell
vorgenommen werden. In welchen Prozessen bzw. Prozessabläufen und
Diagrammen wird dieser Prozessschritt genutzt und wenn eine
Systemunterstützung angestrebt oder schon vorhanden ist, welche
funktionalen und nicht funktionalen Anforderungen gibt es.
Um zu den Anwendungsfällen navigieren zu können, ist eine
Referenzierung zu diesen notwendig.
- Kosten / Zeitverhalten eines Prozessschrittes
Nicht unbedingt wichtig für eine Softwareerstellung, aber unabdingbar
für die Entscheidung für alternative Geschäftsprozesse ist
eine Betrachtung der Kosten und des Zeitverhaltens. Wenn jeder
Prozessschritt Parameter für seine durchschnittlichen Kosten und sein
durchschnittliches Zeitverhalten bekommt, können auf einfachste
Weiße die Gesamtkosten und die Gesamtzeit eines Prozessdurchlaufs
ermittelt werden. Dieses könnte die Entscheidung erheblich
beeinflussen, ob nun der eine oder der andere Geschäftsprozess gelebt
werden soll.
Der Fantasie sind hier keine Grenzen gesetzt, welche Parameter noch zum Zuge kommen können. Folgende Parameter könnten noch möglich sein:
- Bearbeiter-Historie bzw. aktuell Verantwortlicher.
- Wie kommt das eine oder andere Vorgehen bei der Kundschaft an.
- Welche Ökobilanz hat ein Geschäftsprozess.
- Wie bewerten Mitarbeiter in der gegebenen Rolle den Prozessschritt?
- ...
Diese Schablone erhebt nicht den Anspruch auf Vollständigkeit. Möglicherweise sind zusätzliche Informationen gewünscht. Eine festgelegte Schablone gilt für alle Prozessschrittbeschreibungen im Projekt.
Da viele Modellierungswerkzeuge eine recht eingeschränkte Möglichkeit der Textverarbeitung bieten, ist man häufig versucht, ein externes Textverarbeitungsprogramm zu nutzen. Dann ist es notwendig, einen Verweis auf das Textverarbeitungsdokument in der Prozessbeschreibung einzufügen.
[...]
- Citar trabajo
- Helmut Jakoby (Autor), 2023, Modellbasiert vom Kundenwunsch zum Programm. BPMN <-> UML, Múnich, GRIN Verlag, https://www.grin.com/document/1309757
