Notationen zur UML-Geschäftsprozessmodellierung. BPMN (Notation): Prozessbeschreibung. Geschäftsprozessmodellierung – Flussdiagramm
BPMN (Business Process Management Notation) ist eine Geschäftsprozessmodellierungssprache, die eine Zwischenverbindung zwischen Formalisierung/Visualisierung und Implementierung eines Geschäftsprozesses darstellt.
Vereinfacht ausgedrückt handelt es sich bei dieser Notation um eine Beschreibung der grafischen Elemente, die zur Erstellung eines Diagramms des Ablaufs eines Geschäftsprozesses verwendet werden.
Zumindest ist ein solches Schema erforderlich, um einen Geschäftsprozess danach aufzubauen und ihn für alle Teilnehmer klar zu regeln.
Es ermöglicht Ihnen maximal die nachträgliche Automatisierung von Geschäftsprozessen nach dem bestehenden Schema.
Geschichte von BPMN
Die erste Version der BPMN-Notation wurde im Mai 2004 veröffentlicht (BPMN 1.0). Die nächste Version erschien im Januar 2011 (BPMN 2.0). Im Januar 2013 veröffentlichte OMG schließlich die heute am häufigsten verwendete Version – BPMN 2.0.2.Grundlegende BPMN-Grafiken
Ein BPMN-Prozess ist jeder Geschäftsprozess, der durch Notation abgebildet wird. Prozesse bestehen aus Elementen, die im Diagramm jeweils mit einem speziellen Symbol gekennzeichnet sind.Die Elemente der BPMN-Notation sind Elemente eines grafischen Diagramms, aber auch Elemente des Geschäftsprozesses selbst.
Die Notation basiert auf folgenden grafischen Grundelementen:
- Pool und Bahnen
- Aktionen
- Gateways oder Forks
- Veranstaltungen
- Streams
- Artefakte
BPMN-Elemente „Pool“ und „Track“
Der gesamte Geschäftsprozess besteht aus Pools: einer Reihe von Vorgängen + Personen, die diese Vorgänge ausführen.
Der Pool umfasst beispielsweise alle Aktionen zum Laden und Versenden von Waren an den Kunden.
Dabei werden die sogenannten „Tracks“ identifiziert, aus denen sich jeder Pool zusammensetzt. In unserem Beispiel wird einer der Tracks die Erstellung von Dokumenten für die Verladung und den Versand von Waren sein, der zweite Track ist die physische Verladung der gewünschten Sendung auf das Auto und die Fahrt des Autos zum Kunden. Beide Wege ergänzen einander, laufen parallel, dienen aber im Allgemeinen dazu, die gleiche Phase des Geschäftsprozesses abzuschließen.
BPMN-Element „Aktion“
Eine „Aktion“ ist eine Arbeitseinheit, die während der Ausführung eines Geschäftsprozesses ausgeführt wird. Aktionen können entweder elementar (Aufgabe) oder komplex (Teilprozess) sein. Es gibt verschiedene Arten von Elementaraktionen, die sich in ihren Ausführungsbedingungen unterscheiden:
- Wiederholte Ausführung einer Aktion innerhalb eines einzelnen Prozesses. Beispielsweise kann für jede Position in einem Kundenauftrag die gleiche Aktion parallel ausgeführt werden.
- Die zyklische Aktion wird wiederholt ausgeführt, solange die angegebene Bedingung erfüllt ist.
 |
Abstraktes Problem | Wird verwendet, um eine einfache Aktion oder Operation zu bezeichnen, die innerhalb des aktuellen Geschäftsprozesses keiner weiteren Zerlegung unterliegt. |
 |
Unterprozess | Wird verwendet, um einen zerlegten Prozess anzuzeigen, der im betreffenden Prozess enthalten ist. Der Teilprozess wird in seinem Diagramm detaillierter beschrieben. |
 |
Prozess-Link | Wird verwendet, um einen Verweis auf einen der am häufigsten wiederholten Prozesse anzuzeigen. |
 |
Benutzeraufgabe | Wird verwendet, um die Aufgabe anzuzeigen, die eine Person ausführt. |
 |
Aufgabe zur Skriptausführung | Wird verwendet, um einen Prozessschritt anzuzeigen, bei dessen Erreichen das Skript automatisch ausgeführt wird. |
 |
Service-Anrufaufgabe | Wird verwendet, um einen Prozessschritt zu veranschaulichen, in dem ein Webdienst oder ein C#-Skript aufgerufen wird. |
 |
Integriertes Gehäuse | Wird verwendet, um eine nicht routinemäßige Aufgabe darzustellen, die von einer verantwortlichen Person oder Personengruppe überwacht wird. Fälle werden verwendet, wenn Sie unstrukturierte oder halbstrukturierte Aktivitäten innerhalb eines Prozesses schnell organisieren müssen. |
BPMN-Elemente „Fork“ oder „Gateway“
Unter Gateways werden Elemente verstanden, die die Verzweigung und Zusammenführung von Arbeitsabläufen bestimmen.BPMN beschreibt 7 Arten von Forks. Es gibt 2 Haupttypen:
| Exklusiv-Oder-Gate | Wird verwendet, um alternative Prozessabläufe oder konvergierende Kontrollflüsse zu erstellen. | |
| Paralleles Gateway | Wird verwendet, um parallele Pfade zu erstellen, ohne eine Bedingung auszuwerten, oder um Threads zusammenzuführen und parallele Threads der Prozessausführung zu synchronisieren. |
Ein Beispiel für die Verwendung eines Exklusiv-Oder-Gatters zum Erstellen alternativer Prozessthreads:
- Stufe 7. Anruf beim Kunden, um die Qualität der Dienstleistung zu bewerten.
- 1. Wenn der Kunde zufrieden ist, nehmen Sie eine positive Bewertung auf und schließen Sie den Geschäftsprozess ab.
- 2. Wenn der Kunde unzufrieden ist, finden Sie den Grund heraus.
Das weitere Schema kann stark verzweigt sein: Wenn der Kunde mit der Lieferung unzufrieden ist, muss er sich an den Leiter dieses Dienstes wenden; und wenn es um die Produktqualität geht, besteht der nächste Schritt darin, die Beschwerde an die Produktionsabteilung weiterzuleiten oder zu eskalieren (die Hierarchieebene anzuheben), um Informationen über eine solche Beschwerde an das höhere Management weiterzuleiten. Tatsächlich gehören Gateways zu den kritischsten und komplexesten Phasen von Geschäftsprozessen. Die Effizienz des gesamten Systems hängt maßgeblich davon ab, wie kompetent alle Bedingungen und Konsequenzen nach dem „Wenn...dann“-Prinzip formuliert werden.
BPMN-Element „Event“
Ein „Ereignis“ ist eines der Hauptelemente von BPMN und dient dazu, etwas zu beschreiben, das passieren sollte (im Gegensatz zu einer Aufgabe, bei der etwas getan werden sollte). Ein Ereignis könnte beispielsweise eine Vertragsunterzeichnung oder ein Gespräch mit einem Kunden sein.
Ereignisgrafiken in BPMN werden auf zwei Arten klassifiziert:
- Abhängig von der Position des Ereignisses im Prozessdiagramm:
| Startereignis (Einleiten eines Geschäftsprozesses) | |
| Zwischenveranstaltung | |
| Endereignis (Beenden eines Geschäftsprozesses). |
- Die Klassifizierung nach Veranstaltungstyp ist wie folgt:
| Einfache Veranstaltung | Stellt ein untypisiertes Ereignis dar. | |
| Nachrichtenereignis | Zeigt an, ob eine Nachricht gesendet oder empfangen wurde. | |
| Timer-Ereignis | Wird zur Modellierung regelmäßiger Ereignisse verwendet. Mit dem Timer lassen sich auch Zeitpunkte, Zeitintervalle und das Überschreiten eines Zeitlimits simulieren. |
BPMN-Elemente „Flows“
Ein Flow ist eine Abfolge von Aktionen, die durch einen Pfeil angezeigt wird. Das Element „Flow“ zeigt an, welche Aktion nach welcher Aktion ausgeführt werden muss. |
Kontrollfluss | Der Standardkontrollfluss wird nicht durch Bedingungen beeinflusst und verläuft nicht über Gateways, d. h. ist unkontrollierbar. |
 |
Bedingter Kontrollfluss | Wird verwendet, um zu zeigen, dass die weitere Ausführung eines Prozesses entlang eines bestimmten Threads nur dann erfolgt, wenn eine bestimmte Bedingung erfüllt ist. Eine Raute am unteren Rand des Pfeils wird hinzugefügt, wenn der bedingte Kontrollfluss von einem Prozess stammt. Die Raute wird nicht hinzugefügt, wenn der bedingte Kontrollfluss vom Gateway erfolgt. |
| Standard-Kontrollfluss | Es wird verwendet, wenn gezeigt werden muss, dass die weitere Ausführung eines Prozesses entlang eines bestimmten Threads nur dann erfolgt, wenn keine der angegebenen Bedingungen erfüllt ist. | |
 |
Nachrichtenfluss | Wird zur Anzeige der Kommunikation zwischen Prozessen verwendet – zeigt die Übertragung von Nachrichten oder Objekten von einem Prozess zu einem anderen Prozess oder einer externen Referenz an. |
 |
Verband | Wird zur Visualisierung der Beziehung zwischen Flusselementen und Objekten verwendet, die keine Flusselemente (Artefakte) sind. |
BPMN-Elemente „Artefakt“
Unter Artefakten werden in BPMN Objekte verstanden, die keinen direkten Einfluss auf die Ausführung eines Geschäftsprozesses haben. Dies können Dokumente, Daten, Informationen sein.Hauptarten von Artefakten:
 |
Gruppe von Objekten | Wird verwendet, um grafische Elemente derselben Kategorie zu gruppieren und das Diagramm leichter lesbar zu machen. |
 |
Textanmerkung | Wird zur Verdeutlichung des Diagramms verwendet – Kommentare und Erläuterungen, die die Lesbarkeit des Diagramms verbessern. |
| Datenobjekt | Wird verwendet, um Informationen über die Daten anzuzeigen, die während des Prozesses verarbeitet werden. |
Vorteile von BPMN
Die BPMN-Beschreibung eines Geschäftsprozesses hat mehrere Vorteile.Der erste ist die einfache Übersetzung von Diagrammen in ausführbare Modelle mithilfe einer Sprache zur formalen Beschreibung von Geschäftsprozessen.
Die Beschreibung von BPMN-Elementen ist für die meisten Teilnehmer an Geschäftsprozessen klar und bedarf oft keiner weiteren Erläuterung. Mit einem einfachen grafischen Ausdruck können Sie spezifische Vorschriften erstellen, die von den Mitarbeitern befolgt werden.
Neben der Tatsache, dass die Beschreibung der BPMN 2.0-Notation es den Mitarbeitern ermöglicht, zu verstehen, wie Geschäftsprozesse ablaufen, wird diese Notation von den meisten modernen Geschäftsmodellierungstools unterstützt, was den Import vorgefertigter Geschäftsprozessdiagramme in BPM-Systeme ermöglicht.
Elena Gaidukova, Marketinganalystin, Markenmanagerin für Lösungen auf Basis von , Spezialistin für Partnerschaftsbeziehungen.
Die Modellierung von Geschäftsprozessen ist zur klassischen Arbeit vieler Wirtschaftsanalysten im Rahmen der Optimierung von Geschäftsprozessen und der Standardisierung der Aktivitäten russischer Unternehmen geworden. Es gibt viele Notationen, die in bestimmten Fällen verwendet werden. Dieser Artikel ist einem Überblick über die Notationen der Geschäftsprozessmodellierung gewidmet.
VAD (v(Wert hinzugefügtes Kettendiagramm)
Die von Michael Porter in seiner Arbeit zur Unternehmensstrategie eingeführte VAD-Notation konzentriert sich auf die Modellierung von Geschäftsprozessen, die „Wert schaffen“ in Form von Dienstleistungen oder Produkten für den Kunden. Ein in VAD-Notation erstelltes Geschäftsprozessmodell bietet eine allgemeine, nicht detaillierte Sicht auf Geschäftsprozesse.
Mit der VAD-Notation können Sie die Liste und Beziehung von Geschäftsprozessen auf der obersten Ebene beschreiben, da Sie mit dieser Notation alle Geschäftsprozesse des Unternehmens in einem Modell darstellen können. In der VAD-Notation können Sie Beziehungen verwenden, die die Beziehung von Geschäftsprozessen relativ zueinander darstellen, während der Prozessfluss in dieser Notation überwiegend von links nach rechts verläuft.
Es gibt viele Varianten der VAD-Notation, die in verschiedenen Tools implementiert sind und jede über einen eigenen Symbolsatz verfügt, aber alle sehen ungefähr gleich aus – eine Reihe von Geschäftsprozessen, die oft durch „Vorgänger-Nachfolger“-Links miteinander verbunden sind.
Durch die Erweiterung dieser Notation im ARIS-Toolkit können Sie beispielsweise Bearbeiter, Risiken, Dokumente, Daten und vieles mehr an einem Geschäftsprozessmodell abbilden.
Neben der Modellierung der Geschäftsprozesslandkarte einer Organisation können Sie mit der VAD-Notation auch End-to-End-Geschäftsprozesse modellieren, wenn diese erstmalig definiert werden. Sie müssen jedoch verstehen, dass VAD nicht dazu gedacht ist, logische Bedingungen in einem Prozess zu modellieren, und dass es daher vom Management perfekt wahrgenommen wird. In der Praxis folgt nach der Modellierung von Geschäftsprozessen auf der obersten Ebene in der VAD-Notation eine detailliertere Modellierung von Geschäftsprozessen in anderen Notationen, auf die wir im Folgenden näher eingehen.
Das VAD-Notationsmodell kann in einer Vielzahl von Tools gezeichnet werden, beispielsweise in MS Visio und vielen anderen Tools zur Geschäftsprozessmodellierung.
Geschäftsprozessmodellierung – EPC (ereignisgesteuerte Prozesskette)
Die EPC-Notation wurde von Professor August Wilhelm Scheer im Rahmen der ARIS-Toolkit-Methodik entwickelt. Mithilfe eines Geschäftsprozesses wird dieser als Liste von Prozessschritten modelliert, die durch Ereignisse ausgelöst werden. Die Notation eignet sich zur späteren Regulierung eines Geschäftsprozesses sowie zur Analyse des Informationsflusses eines Geschäftsprozesses (eingehende/ausgehende Dokumente).
Die Freiheit der EPC-Notation ermöglicht die Beschreibung zusätzlicher Objekte im Rahmen der Geschäftsprozessmodellierung, wie zum Beispiel betriebliche Risiken, Kontrollverfahren, Masken, Informationssysteme, Indikatoren und vieles mehr.
Innerhalb der EPC-Notation wird der Prozess von oben nach unten modelliert und die Reihenfolge der Ausführung von Schritten/Funktionen/Aktionen/Operationen eines Geschäftsprozesses wird durch ein System von Ereignissen und logischen Bedingungen bestimmt. Als Ereignisse gelten in der EPC-Notation der Beginn und Abschluss von Prozessschritten sowie externe Ereignisse, die eine Reaktion der Organisation erfordern.
Das Geschäftsprozessmodell besteht aus „Ereignis-Funktion-Ereignis“-Sequenzen und logischen Operatoren „UND“, „ODER“, „exklusives ODER“, die Entscheidungen, Zustandsprüfung, Parallelisierung und Konvergenz der Abläufe des modellierten Geschäftsprozesses darstellen.
Es gibt viele Optionen für die EPC-Notation im Spalten- und Zeilenformat sowie mit unterschiedlichen Listen der verwendeten Objekte. Alle diese Optionen sind jedoch nur im ARIS-Toolkit verfügbar, während sie in anderen Tools, beispielsweise MS Visio oder Business Studio, verfügbar sind , EPC-Geschäftsprozessmodellierung ist nur im klassischen Format verfügbar.
Die Modellierung eines Geschäftsprozesses in der EPC-Notation ermöglicht es Ihnen, anschließend eine textliche oder tabellarische Regelung von Geschäftsprozessen zu erhalten, da ein korrekt gezeichnetes EPC-Modell in eine Satzfolge in gewöhnlicher Sprache umgewandelt werden kann, die als Grundlage für die Regelung dient. Aus diesem Grund gilt diese Notation als die bequemste für die Modellierung von Geschäftsprozessen zum Zwecke der anschließenden Analyse und Regulierung.
Modellieren Geschäft— Prozesse– BPMN (Geschäftsprozessmodell und Notation 2.0)
Die BPMN-Notation wurde vom Konsortium der Object Management Group (OMG) erstellt und dient der Modellierung von Geschäftsprozessen zum Zweck ihrer anschließenden Automatisierung. Die BPMN-Notation wird zur detaillierten Modellierung eines Geschäftsprozesses verwendet. Die Anzahl der Objekte in dieser Notation übersteigt 100, sodass Sie alle Nuancen des Verhaltens von Geschäftsprozessen beschreiben können, damit das Informationssystem das erstellte Modell in eine ausführbare Datei umwandeln kann Code.
Die Offenheit der BPMN-Notation und die Unterstützung durch die meisten Tools zur Geschäftsprozessmodellierung und -automatisierung haben diese Notation zu einem führenden Unternehmen in der Geschäftsprozessmodellierung gemacht.
In der BPMN-Notation können Sie zusätzlich zu den Schritten eines Geschäftsprozesses auch die Start-, Zwischen- und Endereignisse des Prozesses, Informationsflüsse und Nachrichtenflüsse modellieren. Unter den Merkmalen der Notation kann man die standardmäßige Verwendung des Modellierungsstils „Swim Lane“ hervorheben, bei dem der Darsteller als vertikaler oder horizontaler Streifen dargestellt wird, der an die Bahnen in einem Schwimmbad erinnert, und auf dieser Bahn finden die Aktionen statt /Operationen, die von diesem Ausführenden ausgeführt werden, werden gefunden.
Die Straffung eines Geschäftsprozesses im Swim-Lane-Format ermöglicht eine klare Übertragung der Verantwortung und des Arbeitsflusses zwischen den Prozessbeteiligten, erschwert jedoch gleichzeitig die Modellierung bei mehreren Mitausführenden in einem Vorgang .
Modelle, die in BPMN-Notation erstellt wurden, lassen sich oft nur schwer zu einer kohärenten Hierarchie zusammenfügen, da die Methodik ursprünglich zur Automatisierung von „End-to-End“-Geschäftsprozessen entwickelt wurde.
Die Anwendung der BPMN-Notation erfordert einige Erfahrung, wodurch sich die Zahl der Ersteller dieser Modelle häufig auf System- und Geschäftsanalysten beschränkt. Vertreter von Geschäftsbereichen modellieren Geschäftsprozesse eher selten in BPMN-Notation.
Trotz der grafischen Unterschiede sind die BPMN- und EPC-Notationen einander sehr ähnlich und können im ARIS-Toolkit bereits ineinander konvertiert werden, wenn auch mit gewissen methodischen Einschränkungen.
Geschäftsprozessmodellierung – Flussdiagramm
Der Name der Notation Flow Charting lässt sich am einfachsten mit Flussdiagramme übersetzen. Diese Notation erschien ursprünglich 1970 im ANSI-Standard und enthält einen sehr einfachen Zeichensatz.
Im Laufe der Jahre der Existenz der Flussdiagramm-Notation wurden viele Varianten von Flussdiagrammen gezeichnet, die Symbole zur Lösung verschiedener Probleme enthalten, beispielsweise zur Beschreibung von Materialflüssen, Rollen und Jobs, Ausrüstung, zur Analyse der Ein- und Ausgänge von Funktionen.
Tatsächlich waren Flussdiagramme die Vorläufer moderner Notationen zur Modellierung von Geschäftsprozessen und wurden bisher in den meisten Bildungseinrichtungen im Rahmen der Disziplinen der Informationstechnologie gelehrt.
Für die Flussdiagramm-Notation gibt es keinen starren Standard, der es Ihnen ermöglicht, Geschäftsprozesse aus verschiedenen Blickwinkeln zu modellieren und dem Modell nach Bedarf bestimmte Objekte hinzuzufügen. Auf diese Weise ist diese Notation der EPC sehr ähnlich, bietet aber noch mehr Freiheiten in der Anwendung. Die Freiheit der Anwendungsmöglichkeiten von Flow Charts und die Unterstützung der meisten kostengünstigen und sogar kostenlosen Geschäftsprozessmodellierungstools haben diese Notation für viele Unternehmen anwendbar gemacht.
Einer der Nachteile von Flussdiagrammen ist das Fehlen einer Standardliste von Objekten und Attributen, was die Kehrseite der „Freiheit“ dieser Notation darstellt. Dadurch können Sie denselben Geschäftsprozess in dieser Notation modellieren, sodass sich die Modelle erheblich voneinander unterscheiden.
Trotz der Tatsache, dass Geschäftsprozessmodelle in der Flussdiagramm-Notation recht häufig zu finden sind, wird sie höchstwahrscheinlich der Vergangenheit angehören und „strengeren Notationen“ Platz machen.
Modellieren Geschäft— Prozesse– IDEF (Integrierte Definitionssprache)
Die IDEF-Notation entstand in den 70er Jahren als US-Regierungsstandard, der sich auf die Inputs, Outputs, Mechanismen und Kontrollen eines Geschäftsprozesses konzentriert und die Prozesse einer Organisation in einer Hierarchie verknüpft. Das Schlüsselelement dieser Notation ist die Funktion, während alle anderen Objekte und Interaktionen mithilfe von Beziehungen modelliert werden.
Die Notation verwendet einen sehr einfachen Satz von Symbolen: Prozessrechtecke und Pfeile, die Eingaben, Ausgaben, Steuerungen und Mechanismen darstellen. Diese Notation zeichnet sich durch ein „eingebautes“ Nummerierungssystem für Geschäftsprozessschritte aus, mit dem Sie die Beziehungen zwischen übergeordneten Prozessen verfolgen können und untergeordnete Prozesse.
In Anbetracht der Geschichte dieses Standards und seiner relativ weit verbreiteten Verwendung ist er in vielen Modellierungstools implementiert. Dennoch kann diese Notation der ausgehenden Generation zugeschrieben werden, da sie immer weniger Unterstützer hat und Unternehmensvertreter diese „Chips“ häufig behandeln Skepsis.
UML (Einheitlich Modellieren Sprachen)
Die Unified Modeling Language (UML) ist eine Reihe von Notationen und Modellierungsmethoden zur Beschreibung von Anforderungen an Informationssysteme. Unter den UML-Notationen gibt es jedoch auch eine spezielle Notation, die speziell für die Modellierung von Geschäftsprozessen entwickelt wurde. UML wird von der Object Management Group (OMG) unterstützt, wodurch diese Methodik unter IT-Experten weit verbreitet ist.
Diese Notation ist EPC und BPMN sehr ähnlich, der einzige Unterschied besteht in der Anzeige logischer Operatoren und Ereignisse, und obwohl es viele Bücher zur UML-Notation gibt und sie von vielen Modellierungstools unterstützt wird, wird hauptsächlich das UML-Aktivitätsdiagramm verwendet für Systemanalyse und -design, und nur wenige Unternehmen verwenden UML zur Modellierung von Geschäftsprozessen
VSM (Wert Strom Kartierung)
Der Name der VSM-Notation kann ins Russische als Customer Value Stream Mapping übersetzt werden. Der ursprüngliche Name dieser Notation stammte von der Toyota Corporation, wo sie vermutlich erfunden wurde – Material and Information Flow Map.
Die VSM-Notation wurde als Teil der Lean Manufacturing-Methodik entwickelt und verwendet eine Reihe spezifischer Symbole zur Darstellung von Ressourcen- und Zeiteinsatzelementen für die Analyse der Geschäftsprozessleistung in Lean 6Sigma-Projekten. Eine Wertstromkarte stellt die physische Umgebung und den Fluss von Materialien und Produkten in der Produktion dar und wird verwendet, um Ressourcen- und Zeitinputs einem Prozess zuzuordnen und so Einblicke in die Produktivität zu geben
Der Zweck dieser Notation besteht darin, die Teilnehmer in die Analyse eines Geschäftsprozesses einzubeziehen, um sie zu ermutigen, selbstständig nach Optimierungsmöglichkeiten zu suchen. VSM-Modelle werden in der Regel in Projekten auf Flip Chart gezeichnet und erfordern keine ernsthaften Werkzeuge zur Modellierung von Geschäftsprozessen, da auf ihrer Grundlage Entscheidungen getroffen werden und das Modell selbst weder zur Grundlage für Vorschriften noch für IT-Lösungen wird.
Das Wichtigste bei der Erstellung eines Modells in der VSM-Notation ist das Ausfüllen temporärer Attribute für den Prozess, um nach „Engpässen“ und Orten mit übermäßiger Lagerhaltung zu suchen.
Diese Notation hat einen begrenzten Anhängerkreis und wird aufgrund der Spezifität der mit ihrer Hilfe gelösten Probleme in naher Zukunft in der breiten Öffentlichkeit der Wirtschaftsanalysten keine Verbreitung finden. Gleichzeitig haben viele Werkzeuge zur Geschäftsprozessmodellierung, beispielsweise ARIS, bereits Erweiterungen entwickelt, um die Geschäftsprozessmodellierung in dieser Notation zu unterstützen.
SIPOC
Die Abkürzung SIPOC steht für: Lieferant, Input, Prozess, Output, Kunde. Hierbei handelt es sich um eine Prozessdokumentationsvorlage, die in die Six Sigma-Methodik übernommen wurde. Dabei handelt es sich nicht einmal um eine Modellnotation, sondern um ein Tabellenformat, mit dem Sie einen Geschäftsprozess auf der obersten Ebene beschreiben können. Das SIPOC-Modell wird am effektivsten verwendet, wenn die Grenzen eines Geschäftsprozesses, interagierende Parteien und Prozess-Inputs/Outputs definiert werden.
Für SIPOC gibt es keine Notation, da es sich um eine einfache Tabelle mit entsprechenden Überschriften handelt, die es Ihnen ermöglicht, den ausgewählten Geschäftsprozess für die anschließende Analyse und Optimierung zu strukturieren.
Der Nutzen von SIPOC liegt im Gegensatz zu anderen Diagrammen in der Möglichkeit seiner Nutzung durch Mitarbeiter von Geschäftsbereichen, da es keine komplexe Logik und viele Objekte wie EPC- oder BPMN-Notationen enthält.
Geschäftsprozessmodellierung – Schlussfolgerungen
Deshalb habe ich mir einige Notationen zur Geschäftsprozessmodellierung angeschaut, die auf dem russischen Markt zu finden sind (sie werden ausführlicher im BPM-CBOK-Kapitel zur Geschäftsprozessmodellierung beschrieben). Welche Notation zur Verwendung gewählt werden soll, ist eine offene Frage. Um beispielsweise die Geschäftsprozesse einer Organisation auf der obersten Ebene zu modellieren, verwende ich die VAD-Notation für die primäre Modellierung eines zur Optimierung ausgewählten Geschäftsprozesses. Es ist einfacher, SIPOC zu verwenden VAD. Zur Erstellung detaillierter Modelle von Geschäftsprozessen – vereinfachtes BPMN zur Modellierung funktionsübergreifender Interaktion oder EPC zur detaillierten Modellierung, um den Informationsfluss und viele mit einem Geschäftsprozess verbundene Objekte zu formalisieren. Wenn Sie einen Geschäftsprozess in einem BPMS-System automatisieren müssen, kommt die BPMN-Notation nicht aus.
Kostenloses BPMN-Tool
Cawemo ist ein kostenloses Online-Tool zum Entwickeln, Besprechen und Teilen von BPMN-Diagrammen mit Ihrem Team.
Kostenloses BPMN-ToolRezension
Wir haben Tausenden von Menschen BPMN beigebracht und verwenden die Notation seit 2007 in unserer täglichen Projektarbeit. Nachfolgend finden Sie viele BPMN-Beispiele für häufige Modellierungsprobleme. Unabhängig von Ihrem spezifischen Projekt oder Ihrer Branche gibt es viele häufig gestellte Fragen zur Verwendung von BPMN. Unserer Erfahrung nach sind die meisten der folgenden BPMN-Beispiele für jeden BPMN-Benutzer nützlich.
Wir sind OMG 2009 als einflussreiches Mitglied beigetreten. Seitdem sind wir an der Entwicklung von BPMN 2.0 beteiligt.
BPMN-Beispiele
Geschäftsregeln und BPMN
Simulationsszenario
Nehmen wir an, wir möchten einen Prozess in BPMN modellieren und der Prozess ruft einige Geschäftsregeln auf. Wir verwenden das Beispiel der Erstellung einer Rechnung. Um eine Rechnung zu erstellen, müssen Sie den Rabatt berechnen. Die Bestellmenge und der Kundentyp sind die relevanten Kriterien für die Berechnung des Rabatts.
Dies ist ein sehr einfaches Beispiel, das uns zeigt, wo wir BPMN verwenden sollten und wo nicht.
Engine-Rollen Rechnung erstellen Rechnung anfordern Rabatt berechnen Rechnung erstellen Rechnung erstellt
Erläuterung
Bei der Simulation konzentrieren wir uns auf den Ablauf des Prozesses. In diesem Beispiel besteht der Prozess aus zwei Schritten. Der Rabatt wird vor der Rechnungserstellung berechnet. Das Ergebnis ist ein sehr einfacher Prozess.
Es macht keinen Sinn, die Berechnung des Rabatts selbst in einem BPMN-Modell zu modellieren (siehe Beispiel unten). Bei einem Entscheidungsbaum aus Regeln wachsen die Potenzen für jedes zusätzliche Kriterium exponentiell. Das ist nicht das, was wir in einem BPMN-Modell wollen.
Daher ist es sinnvoll, Prozesse und Geschäftsregeln zu trennen.
Erstellen Sie eine Rechnung. Machen Sie 2 % Rabatt. Fügen Sie 1 % Rabatt hinzu. Wer ist der Käufer? Rechnungsanforderung Betrag anfordern? Art des Käufers? Erstellen Sie eine Rechnung. Die Rechnung wurde erstellt. 3 % Rabatt gewähren. 4 % Rabatt gewähren. Wer ist der Käufer? 1 % Rabatt hinzufügen 1 % Rabatt hinzufügen 1000 - 1500 500 - 999 >2000< 500 Тип A Тип A Тип A обычный обычный обычный
Abhängige Instanzen
Simulationsszenario
Nehmen wir an, wir möchten einen Prozess mit passenden Instanzen modellieren. Wir verwenden ein einfaches Beispiel. Wenn für einen Kunden eine Bonitätsprüfung durchgeführt wird, möchten wir nicht, dass gleichzeitig eine weitere Bonitätsprüfung für denselben Kunden durchgeführt wird.
Der Grund kann darin liegen, dass die Gesamtzahl der durchgeführten Bonitätsprüfungen Einfluss auf das Ergebnis der Prüfung hat.
Nehmen wir an, wir führen eine Bonitätsprüfung für einen Kunden durch und erhalten gleichzeitig eine zweite Anfrage für denselben Kunden.
Allen Lösungen ist gemeinsam, dass jede neue Instanz vor Beginn der eigentlichen Bonitätsprüfung beispielsweise den Instanzmatch auf Datenebene prüfen muss.
Signalereignislösung
Bonitätsprüfung Abfragen anzeigen Ausgelöste Ereignisse anzeigen (mit ihnen) Laufende Instanzen desselben Kunden? und derselbe Kunde? Bonität überprüfen. Prüfung abgeschlossen. Prüfung abgeschlossen. In der Datenbank erfasst. Nein. Ja
Erläuterung
Ein Signalereignis ist die einfachste und kompakteste Möglichkeit, Interaktionen zwischen verschiedenen Instanzen zu modellieren. Das Problem mit dem Signal besteht darin, dass es als Broadcast fungiert und keine bestimmte Instanz anspricht. Streng genommen wird der Client also ignoriert und alle wartenden Instanzen fangen ihn ab.
Lösung für Nachrichtenereignisse
Bonitätsprüfung Anfragen prüfen Prüfen laufende Prozesse (gleicher Client) laufende Instanzen desselben Clients? Bonität prüfen Bonität bestätigt Käuferereignis erwarten? Auf ausstehende Fälle prüfen (vom selben Client). Instanzstart abgeschlossen. Ausstehende Instanz informieren. Datenbank. Datenbank. Nein, Nein, Ja, Ja
Erläuterung
Diese Lösung ist etwas komplizierter, da Sie den Empfänger (eine Instanz) der Nachricht bestimmen müssen. Dies führt zu einer zweiten Datenanforderung vor dem Ende der Instanz. Dies ist jedoch der richtige Weg, um das Problem zu lösen, das bei der Lösung eines Signalereignisses auftritt.
Lösung mit Timer und Schleife
Bonitätsprüfung Prüfanfragen prüfen laufende Prozesse (ein Benutzer) laufende Instanzen eines Mandanten? Bonitätsprüfung durchführen, etwas warten, Bonitätsdatenbank prüfen nein ja
Erläuterung
In diesem Beispiel benötigen wir keine Verbindung zwischen Instanzen. Die Instanz selbst prüft die Häufigkeit, ob sie zur Bonitätsprüfung übergehen kann. Der Nachteil besteht darin, dass es aufgrund der Schleife zu Verzögerungen und Overhead kommen kann.
Vier-Augen-Prinzip
Simulationsszenario
Wir wollen die folgende Situation mit BPMN 2.0 modellieren. Eine Anfrage (z. B. eine Zahlung) erfordert zwei Berechtigungen von zwei verschiedenen Personen. Die Prozess-Engine muss sicherstellen, dass beide Genehmigungen erfüllt sind, bevor die Anfrage genehmigt wird. Auch die manuellen Schritte zweier Genehmiger sollten im BPMN-Diagramm abgebildet werden. Die Genehmigungsentscheidung erfolgt über ein Aufgabenlistenportal.
Anwendungsfälle
Die Anwendungsfälle für diese Vorlage sind zahlreich. Hier sind einige Beispiele:
- Zahlungsgenehmigung
- Rechnungsgenehmigung
- Vertragsgenehmigung
Lösung als BPMN 2.0-Diagramm
1. Genehmiger Genehmigung angefordert Anfrage bewerten lesen und kommentieren Aufgabe abgeschlossen Prozesse in der Engine Anfrage bestätigen bestätigen oder zustimmen (1. Zeile) Bestätigt? Anfrage abgelehnt (1. Zeile) ablehnen oder bestätigen (2. Zeile) Bestätigt? Anfrage abgelehnt (2. Zeile) Anfrage bestätigt 2. Genehmiger bestätigt Anfragerate Anfrage lesen und kommentieren Aufgabe abgeschlossen nein ja ja nein
Erläuterung
Wir verwenden separate Pools für Process Engine, für den ersten Genehmiger und für den zweiten Genehmiger. So können wir klar definieren, wer welchen Prozess steuert.
Der Engine-Pool verwendet benutzerdefinierte Aufgaben. Diese benutzerdefinierten Aufgaben entsprechen den Aufgaben, die in der Aufgabenliste des 1. und 2. Genehmigers angezeigt werden.
Die Interaktion zwischen Benutzeraufgaben in der Engine und zwischen dem manuellen Prozess der Genehmiger wird mithilfe von Nachrichtenflüssen modelliert. Diese Nachrichtenflüsse kapseln die Dokumentationsschritte, die ein Assertor ausführen muss, um eine Benutzeraufgabe abzuschließen.
Die Aufgabenliste selbst ist nicht zur Reduzierung der Komplexität modelliert.
Variationen
Zulassung als abgebautes Becken
1. Abgleicher 2. Abgleicher Prozess-Engine Anforderung bestätigen, ablehnen oder bestätigen (1. Zeile) Bestätigt? Anfrage abgelehnt (1. Zeile) ablehnen oder bestätigen (2. Zeile) Bestätigt? Anfrage abgelehnt (2. Zeile) Anfrage bestätigt nein ja ja nein
Definieren eines Ziels mithilfe von LDAP
Erster Genehmiger, Anfrage bestätigen, Anfrage auswerten, Lese- und Kommentaraufgabe abgeschlossen, LDAP-Prozess-Engine, Anfrage bestätigen, ablehnen oder bestätigen (1. Zeile) Bestätigt? Anfrage abgelehnt (1. Zeile) ablehnen oder bestätigen (2. Zeile) Bestätigt? Anfrage abgelehnt (2. Zeile) Anfrage bestätigt 1. und 2. Genehmiger bestimmen 2. Genehmiger Anfragerate bestätigen Anfrage lesen und kommentieren Aufgabe abgeschlossen nein ja ja nein
Monatliche Abrechnung
Simulationsszenario
Dieses Beispiel erläutert ein sehr häufiges Problem bei der Strukturierung von BPMN 2.0-Diagrammen. Nehmen wir an, es gibt einen Anwalt, der seinen Mandanten Rechtsberatung anbietet. Der Service funktioniert wie folgt: Kunden können jederzeit Rechtsberatung in Anspruch nehmen. Der Anwalt erteilt die gewünschte Beratung und trägt die abrechnungsfähigen Stunden in die Arbeitszeittabelle des Mandanten ein. Wenn der Monat abgelaufen ist, ermittelt der CPA die abrechnungsfähigen Stunden anhand des Zeitplans und erstellt eine Rechnung.
Dieses Beispiel veranschaulicht ein sehr allgemeines Modellierungsszenario. Es sind nicht die Prozessschritte, die komplex sind, sondern die Struktur des Diagramms.
Lösung als BPMN 2.0-Diagramm
Anwaltsberatung Beratungsanfrage Beratung erteilen Zeit registrieren Anfrage bearbeitet Kundenzähler Kunde Monatliches Einkommen erfassen 1. Tag des Monats Abrechnungsfähige Stunden ermitteln Rechnung erstellen und senden Geld erhalten Rechnung abgeschlossen 14 Tage Erinnerung senden Nur eine pro Monat Mehrere pro Monat
Erläuterung
Der wichtigste Aspekt eines Diagramms ist seine Struktur.
Der Prozess der Rechtsberatung findet mehrmals im Monat statt. Die monatliche Abrechnung erfolgt nur einmal im Monat. Daher müssen diese beiden Prozesse als separate Pools modelliert werden.
Natürlich sind diese beiden Pools nicht völlig unabhängig voneinander. Wofür? Sie arbeiten mit denselben Daten – dem Stundenzettel des Kunden. Unsere Fähigkeit, eine solche datenbezogene Konnektivität zu modellieren, ist in BPMN sehr begrenzt. Dies liegt daran, dass BPMN eher kontrollflussorientiert als datenflussorientiert ist.
Wir können jedoch ein Data-Warehouse-Element verwenden, um diese Verbindung auf Datenebene zu modellieren.
Falsche Art zu modellieren
Anwaltsberatung Beratungsanfrage Beratung anbieten Zeit registrieren 1 nächsten Monat Abrechnungsstunden ermitteln Rechnung erstellen und senden Geld erhalten Rechnung abgeschlossen 14 Tage Erinnerung an den Kunden senden
Erklärung, warum das falsch ist
In diesem Beispiel werden beide Prozesse in einem gemischt. Dies ist bestenfalls eine sehr implizite Art der Modellierung. Dies würde bedeuten, dass für jede Rechtsberatung einmal im Monat eine Rechnung verschickt würde. Diese Modellierungsmethode ist in den meisten Fällen falsch.
Zusätzliche Informationen, die nach der Benutzeraufgabe erforderlich sind
Simulationsszenario
Nehmen wir an, wir möchten das folgende Szenario modellieren: Wir möchten eine benutzerdefinierte Aufgabe ausführen, die von einem Benutzer im Portal ausgeführt wird. Nach Abschluss der Benutzeraufgabe sind möglicherweise zusätzliche Informationen erforderlich. In diesem Fall sendet der Auftragsverarbeiter eine Informationsanfrage an einen anderen Benutzer (Lösung 1) oder technischen Dienst (Lösung 2).
Lösung 1: Informationen von einem anderen Benutzer anfordern
Der Benutzer ist angemeldet. Der Benutzer ist angemeldet. Process Engine. Aufgabe für den Benutzer. Es werden zusätzliche Informationen benötigt. Information? Informationen anfordern (vom Benutzer) ... nein ja
Lösung 2: Informationen beim technischen Service anfordern
Der Benutzer hat sich angemeldet. Einige technische Service-Prozess-Engine-Aufgaben für den Benutzer. Weitere Aufgaben erforderlich. Information? Anfrage senden Informationen erhalten... nein ja
Bearbeitung einer Reihe von Bestellungen vom Markt
Situation
Wir wollen mit BPMN 2.0 folgendes Szenario modellieren: Nehmen wir an, dass ein Unternehmen Bestellungen aus unterschiedlichen Vertriebskanälen erhält. Einer dieser Kanäle ist der Markt. In bestimmten Zeitabständen werden Bestellungen aus dem Markt schubweise entgegengenommen. Jede Bestellung in diesem Stapel muss vor der Eingabe in das ERP-System überprüft werden.
Lösung als BPMN 2.0-Diagramm
ERP-System Markt Bestellungen in ERP importieren Alle 10 Minuten Alle Bestellungen aus dem Markt sammeln Bestellvorgang Neue Einzelbestellung Bestelldaten prüfen Sind die Daten korrekt? Importieren einer Bestellung in das ERP-System. Eine Bestellung in Bearbeitung. Bestelldatum ist falsch. Alle in Bearbeitung befindlichen Bestellungen sind separat. Bestellung nein ja
Erläuterung
Dieses Beispiel zeigt ein sehr allgemeines Modellierungsszenario. Manchmal nennen wir dies das 1-zu-n-Problem. Eine Prozessinstanz (Import von Bestellungen) führt zu vielen separaten Prozessinstanzen eines anderen Prozesses (ERP-System). Typische Designs sind mehrere Instanzen oder Schleifen, die andere Prozesse mithilfe von Nachrichten (Nachrichtenströmen) starten.
Benutzeraufgaben neu zuweisen
Simulationsszenario
Nehmen wir an, wir müssen sicherstellen, dass eine bestimmte Benutzeraufgabe definitiv abgeschlossen wird. Daher müssen Benutzeraufgaben neu zugewiesen werden, sobald der aktuelle Beauftragte nicht verfügbar ist, beispielsweise aufgrund von Urlaub oder Krankheit.
Lösung 1: Messaging-Dienst und Umleitung
Die Notiz
Dies ist sinnvoll, wenn die Engine einen Dienst aufruft, um einen neuen Beauftragten zu ermitteln.
Lösung 2: Nachrichtenübermittlungsregeln und Umleitungsregeln
Der Benutzer hat sich angemeldet. Die Prozess-Engine ermittelt den Beauftragten für die Aufgabe des Benutzers. Der Beauftragte ist nicht verfügbar
Die Notiz
Dies ist sinnvoll, wenn die Engine die Regel-Engine aufruft, um einen neuen Beauftragten zu ermitteln.
Lösung 3: Nachrichtengrenzereignis und implizite Umleitung
Benutzer angemeldet. Process Engine-Benutzeraufgabe... Beauftragter nicht verfügbar
Die Notiz
Dies ist sinnvoll, wenn die Engine den neuesten Beauftragten beispielsweise anhand eines Ausdrucks ermittelt.
Zweistufige Eskalation
Simulationsszenario
Anhand des folgenden Beispiels veranschaulichen wir, wie eine zweistufige Eskalation mit BPMN 2.0 modelliert wird. Wenn wir Pizza wollen, bestellen wir sie. Manchmal dauert die Pizzalieferung länger und dauert mehr als 20 Minuten. Dann beschweren wir uns über den Lieferservice. Danach geben wir ihnen weitere 30 Minuten Zeit, um die Pizza zu liefern. Wenn sie dies nicht rechtzeitig tun, werden wir unsere Bestellung ablehnen und stornieren.
Lösung 1: Zwei ereignisbasierte Gateways
Pizza wird gesucht Pizza bestellen Pizza geliefert Pizza essen Pizza 30 Minuten aufgegessen Beim Lieferservice beschweren Pizza geliefert 20 Minuten Bestellung storniert Bestellung storniert
Vorteile dieser Lösung
Diese Lösung zeigt sehr deutlich, wie die zweistufige Eskalation funktioniert. Die Timer werden separat modelliert und dann ihre entsprechenden Eskalationsaktionen.
Nachteile dieser Lösung
Das ereignisbasierte Gateway ist kein intuitives BPMN-Symbol des BPMN-Standards, Erfahrung ist erforderlich.
Die Verwendung von zwei ereignisbasierten Gateways vergrößert das Modell und führt zu einer doppelten Pizza-Ereignisnachricht.
Lösung 2: Akzeptieren Sie den Auftrag mit aktivierten Timern
Pizza wird gesucht Pizza bestellen Pizza essen Pizza aufgegessen Beim Lieferservice beschweren Bestellung storniert Bestellung storniert Auf Pizza warten 50 Minuten 30 Minuten über Bestellung beschweren
Vorteile dieser Lösung
Dieses Modell ist kleiner als die erste Lösung und wahrscheinlich die Art und Weise, wie die meisten Entwickler das Problem in der Engine lösen werden. Da wir ein unterbrechungsfreies, angehängtes Timer-Ereignis verwenden, ist diese Lösung flexibler bei der Bearbeitung mehrerer Beschwerden (z. B. möchten wir uns alle 5 Minuten beschweren, bis 50 Minuten abgelaufen sind).
Nachteile dieser Lösung
Die Empfangsaufgabe ist für „Geschäftsleute“, die für einen solchen Wartezustand lieber Nachrichtenempfangsereignisse verwenden würden, normalerweise nicht intuitiv.
Die Funktionsweise von Interrupt- und Non-Interrupt-Timern erfordert ein tiefes Verständnis der damit verbundenen Ereignisse.
Lösung 3: Ein ereignisbasiertes Gateway mit einem gemeinsamen Timer
Pizza gesucht Pizza bestellen Pizza geliefert Pizza essen Pizza essen Die Zeit ist abgelaufen! Beschweren Sie sich über die Lieferung. Bestellung storniert. Bestellung storniert. Ist die Aufgabe abgeschlossen? Der Timer zeigte mehr, ja, nein
Vorteile dieser Lösung
Dieses Modell bietet eine kompakte und allgemeine Lösung des Problems. Wenn Sie von einer n-stufigen Eskalation sprechen, benötigen Sie diesen allgemeinen Ansatz, um große Diagramme zu vermeiden.
Nachteile dieser Lösung
Die allgemeine Lösung ist weniger offensichtlich als andere Lösungen. Wir sehen nicht die tatsächliche Dauer der Timer, da für beide Dauern derselbe Timer verwendet wird.
Diese Modellierungsmethode ist nicht geeignet, die zweistufige Eskalation schnell zu verstehen.
BPMN-Modellierungsstile
Vermeiden Sie möglichst das Überqueren von Bächen. Dadurch wird das Verständnis für BPMN-Prozessmodelle verbessert – sowohl für erfahrene als auch für unerfahrene BPMN-Benutzer.
Natürlich lässt sich dieses Problem nicht immer vollständig vermeiden. Bedenken Sie, dass es immer sinnvoll ist, etwas mehr Zeit in die Optimierung des Layouts zu investieren, damit die meisten Querströme eliminiert werden.
Die folgenden Beispiele veranschaulichen das Problem anhand eines abstrakten Beispiels.
Gutes Beispiel für Thread-Handling
Prozess gestartet, erste Aufgabe ausführen. Erforderliche Aktion? Aufgabe zwei abschließen Prozess abgeschlossen Aufgabe drei ausführen ok? ja Plan A Plan B nein
Gegenbeispiel
Der Prozess wurde gestartet. Aufgabe eins. Erforderliche Aktion? Aufgabe zwei ausführen Prozess abgeschlossen Aufgabe drei Ok? ja Plan A Plan B nein
Am wichtigsten ist, dass jedes BPMN-Symbol eine Beschriftung haben muss.
Ereignisse müssen mit dem Partizip „Objekt + Vergangenheit“ gekennzeichnet werden. Startereignisse sollten immer mit einem Prozessauslöser gekennzeichnet sein. Endereignisse müssen mit dem Endzustand des Prozesses gekennzeichnet werden.
Auch der Prozess (Pool) selbst muss immer markiert werden. Diese Bezeichnung muss den Namen des Prozesses und die Rolle, die ihn ausführt, angeben.
Aufgaben müssen mit Objekt + Verb beschriftet werden. Dies zwingt die Modellperson, sich auf das zu konzentrieren, was während der Aufgabe tatsächlich erledigt wird.
X-OR-Gateways müssen mit einer Frage gekennzeichnet werden. Die ausgehenden Sequenzströme müssen mit möglichen Antworten auf diese Fragen (Bedingungen) gekennzeichnet sein.
Gutes Namensbeispiel
Bestelldatum prüfena Bestellservice Bestellung erhalten Bestellung prüfen Bestellung prüfen Ist das Bestelldatum korrekt? Ist das Bestelldatum korrekt? Das Bestelldatum ist falsch ja nein
Allgemeine Version
Prozessname Rolle, die den Prozess ausführt Prozessauslöser Objekt + Verb Objekt + Partizip Erster Endzustand nach dem Ende des Prozesses Fragen? Der zweite Endzustand nach Prozessende Antwort 1 Antwort 2
Gegenbeispiel
Bestellung aufgegeben. Start prüfen. Status in Datenbank schreiben. Ende. Fehler. Ok
In diesem BPMN-Beispiel geht es um die Erstellung eines guten Layouts von Prozessmodellen. Je besser das Layout, desto höher der Grad des Verständnisses. Das wollen wir erreichen, wenn wir Prozessmodelle erstellen.
Wir haben festgestellt, dass symmetrische Strukturen das Verständnis von BPMN-Prozessmodellen erhöhen – sowohl für erfahrene als auch für unerfahrene BPMN-Benutzer.
Ein gutes Beispiel für ein symmetrisches Modell
Bereiten Sie einen Salat zu. Fühlen Sie sich hungrig. Wählen Sie ein Rezept. Welches Gericht? Nudeln kochen Essen essen Hunger wird gestillt Steak kochen Was sind die Zutaten? Wählen Sie: - Salat - Pasta - Steak Steak Nudelsalat Warme Speisen
Gegenbeispiel
Salat vorbereiten Hunger ist aufgetreten Rezept auswählen Welches Gericht? Nudeln kochen Essen essen Hunger wird gestillt Steak kochen Was sind die Zutaten? Wählen Sie: - Salat - Pasta - Steak Steak Nudelsalat warme Speisen
Gutes Beispiel für symmetrisches Muster 2
Frisches Produkt Bestellung geliefert altes Produkt gebraucht Bestellwert über 25.000 €? Bestellvorgang Lieferung organisieren Ware verpacken Bestellung ausliefern Bestellvorgang ja nein
Gegenbeispiel 2
Frische Produkte Alte Ware auf Lager liefern lassen Bestellen Sie einen Bestellwert von mehr als 25.000 €? Bestellung Lieferung durchführen Produkt Bestellung Lieferung Bestellvorgang ja nein
Der Grund ist einfach. Menschen neigen dazu, Aufgabengrößen zu interpretieren, obwohl sie im BPMN-Standard keine Semantik haben.
Manche Leute glauben, dass größere Aufgaben wichtiger sind als kleinere – laut BPMN ist das falsch.
Manche Leute glauben, dass große Aufgaben länger dauern als kleinere Aufgaben – das stimmt laut BPMN nicht.
Sie können diese Verwirrung leicht vermeiden, indem Sie dieselben Aufgabengrößen verwenden.
Ein gutes Beispiel für gleiche Aufgabengrößen
1. Genehmiger bestätigt Anforderung, Rate, Anforderung, Lese- und Kommentaraufgabe abgeschlossen
Gegenbeispiel
1. Genehmiger Anfrage bestätigen Anfrage gestellt Dokument und Kommentar gelöscht Aufgabe abgeschlossen
Das AS-IS-Modell oder „As-is“-Modell ist ein Modell der Geschäftsprozesse zum Zeitpunkt der Unternehmensbefragung und wird mit dem Ziel erstellt, zu verstehen, wie ein bestimmtes Unternehmen vom Standpunkt der Systemanalyse aus funktioniert. Dieses Modell wurde mit dem Ziel erstellt, Fehler und Engpässe zu identifizieren und Vorschläge zur Verbesserung der Situation zu formulieren.
Im zweiten Kapitel dieses Workshops haben wir bei der Untersuchung von Designmethoden und -technologien bereits ein Modell dieses Geschäftsprozesses erstellt. Daher werden wir in diesem Teil des Handbuchs dieses Modell nur anhand der während des Erhebungsprozesses gewonnenen Informationen klären.
Kontextmodell:
Titel: Verkauf von Fertigprodukten ab Lager.
Ziel: Umsatz steigern.
Standpunkt: Leiter der Vertriebsabteilung.
Eingabedaten: Rechnungskopie, Vertragskopie, Bestellung.
Ausgabedaten: Anfrage, Rechnung, Journalauszug, Bericht, Ablehnung der Auftragserfüllung.
Management: Sortiment an Verbindungselementen, aktueller Preis der Verbindungselemente, Satzung des Unternehmens, Vorschriften für die Vertriebsabteilung.
Mechanismen: Mitarbeiter der Vertriebsabteilung.
Das Kontextmodell ist in Abbildung 18 dargestellt.
Abb. 18. Kontextdiagramm
Fahren wir mit der Erstellung eines Zerlegungsdiagramms fort. Nach der Bearbeitung der Fragebögen können wir die Hauptfunktionen identifizieren: Prüfung der Bestellbereitschaft, Organisation der Zahlung, Organisation der Lieferung, Erstellung von Berichten. Das Zerlegungsdiagramm ist in Abbildung 19 dargestellt.
Abb. 19. Zerlegungsdiagramm
Lassen Sie uns das Interview analysieren und uns die tatsächliche Technologie der Arbeit des Vertriebsmitarbeiters ansehen. Basierend auf diesen Daten können die Hauptfunktionen zerlegt werden. Die Hauptfunktion „Prüfung der Auftragsbereitschaft“ lässt sich in folgende Aktionen unterteilen: Auswahl von Verträgen für das aktuelle Datum, Annahme von Bestellungen für das aktuelle Datum, Abgleich mit dem fertigen Produktprotokoll. Die Zerlegung ist in Abbildung 20 dargestellt.
Die Hauptfunktion „Organisation der Zahlung“ lässt sich in folgende Aktionen unterteilen: Berechnung des Zahlungsbetrags, Ausstellung einer Rechnung, Begleichen der Rechnung. Wir zerlegen die Hauptfunktion „Organisation der Ausgabe“ wie folgt: Ausgabe einer Anforderung, Benachrichtigung des Lagers über die Vorbereitung der Waren, Erstellung eines Auszugs für die Vertragsabteilung, Änderung des Verkaufsjournals. Wir zerlegen die Hauptfunktion „Berichte erstellen“ in die folgenden Aktionen: Datenanalyse, Datenerfassung, Drucken von Berichten. Die entsprechenden Diagramme sind in den Abbildungen 21, 22, 23 dargestellt.
Abb.20. Zerlegungsdiagramm A1
Abb.21. Zerlegungsdiagramm A2
Abb.22. Zerlegungsdiagramm A3
Abb.23. Zerlegungsdiagramm A4
Da Designer vor dem Ziel stehen, den Dokumentenfluss vor der Zerlegung von Prozessen zu automatisieren, ist es sinnvoll, das Dokumentenflussmodell zu berücksichtigen. In diesem Fall können Sie auf zwei Arten vorgehen: Betrachten Sie ein separates Dokumentenflussmodell und zerlegen Sie einzelne Geschäftsprozesse durch die Erstellung von DFD-Diagrammen.
⇐ Zurück567891011121314Weiter ⇒
Verwandte Informationen:
Suche auf der Website:
Notation des ARIS-Wertschöpfungskettendiagramms (ARIS VAD).
In Abb. 2.30 stellt eine der wichtigsten ARIS-Notationen vor – die ARIS VAD-Notation. Mit einem Wertschöpfungsprozesskettendiagramm werden die Geschäftsprozesse einer Organisation auf oberster Ebene beschrieben. In der Regel empfehlen Berater, die ARIS einsetzen, sechs bis acht Geschäftsprozesse der obersten Ebene zu identifizieren und diese in der ARIS-VAD-Notation zu beschreiben. Anschließend werden die resultierenden Top-Level-Prozesse in die ARIS VAD- oder ARIS eEPC-Notation zerlegt.
Modelle AS-IS und TO-BE
Betrachten wir die in Abb. dargestellten Objekte der ARIS VAD-Notation. 2.30.
Das Hauptobjekt der ARIS VAD-Notation ist die Wertschöpfungskette – ein Prozess oder eine Gruppe von Organisationsfunktionen, die der Erzielung eines Mehrwerts dienen. Objekte werden durch einen gepunkteten Pfeil miteinander verbunden, der den Typ „ist Vorgänger“ hat. Diese Art der Kommunikation zeigt, dass ein Prozess der Vorgänger eines anderen ist. Es ist jedoch offensichtlich, dass in der Praxis alle Grundprozesse zyklisch sind. Darüber hinaus verfügen sie über Feedback-Links. Daher ist der Begriff Vorgänger aus unserer Sicht unglücklich.
Zwischen den in Abb. 2.30 können materielle Ressourcen- und Informationsflüsse dargestellt werden, für deren Beschreibung Sie Objekte der Typen Cluster bzw. Fachbegriff verwenden können. Um die zur Ausführung des Prozesses erforderliche Infrastruktur zu beschreiben, werden in diesem Beispiel die Objekttypen „Produkt/Dienstleistung“ und „Informationsdienst“ ausgewählt. Die Auswahl der Objekttypen zur Darstellung realer Strömungen ist recht willkürlich. Zu Beginn der Prozessmodellierungsarbeit ist es sehr wichtig zu entscheiden, welche Objekttypen verwendet werden und welche realen Objekte sie darstellen. Im Fall des Beispiels in Abb. Ab Version 2.30 wäre es möglich, alle Flüsse (Information und Material) mithilfe von Objekten des Typs Fachbegriff darzustellen.
In Abb. Abbildung 2.30 zeigt auch Organisationseinheitsobjekte und zeigt die Einheiten an, die die entsprechenden Prozesse ausführen.
Objekte werden über Verbindungen eines bestimmten Typs miteinander verbunden (siehe Abb. 2.30). Beispielsweise wird der vom Cluster-Objekt angezeigte Informationsfluss in den ersten Prozess eingegeben und diesem über einen Pfeil des Typs „ist Eingabe für“ zugeordnet. Ein weiteres Beispiel ist der Verbindungstyp „executes“ zwischen Wertschöpfungsketten- und Organisationseinheitsobjekten. Der Beziehungstyp „wird von verwendet“ gibt an, dass das Produkt/die Dienstleistung von einem Prozess usw. verwendet wird. Die wichtigste Anforderung in der ARIS-Methodik ist daher die richtige Auswahl und Weiterverwendung von Verbindungen und Objekten eines bestimmten Typs.
In Abb. Abbildung 2.31 zeigt ein Beispiel eines Top-Level-Modells, ausgeführt in der ARIS VAD-Notation. Dieser Vorgang ist Ihnen bereits bekannt. Oben, in Abb. 2.16 wird der gleiche Prozess in der IDEF0-Notation dargestellt.
88____________________________ BB. Repin, V.G. Eliferow
Kapitel 2 Auswahl einer Methodik zur Beschreibung von Geschäftsprozessen________________________________ 89
Die Prinzipien zur Erstellung eines Top-Level-Prozessdiagramms in der ARIS-VAD-Notation unterscheiden sich deutlich von der IDEF0-Notation. Also. In der ARIS VAD-Notation können Pfeile zu jeder Seite des Wertschöpfungskettenobjekts führen. (Denken Sie daran, dass in der IDEF0-Notation jede Seite eines Aktivitätsobjekts (Funktion) Tiefe und Bedeutung hat.) In Abb. Abbildung 2.32 zeigt eine mögliche Situation in der ARIS VAD-Notation. wenn das Prozessdiagramm viele Rückmeldungen enthält, die nur für den Analysten verständlich sind, der das Modell erstellt hat.
Dieser Nachteil der ARIS-VAD-Notation kann dadurch behoben werden, dass die Möglichkeit einer besonderen Verwendung von Feedback-Links vorab festgelegt wird, wie z. B. in Abb. 2.33. Beachten Sie, dass dieser Ansatz bei ARIS-Spezialisten möglicherweise Kritik hervorruft, da er der Notation widerspricht. Wir sind jedoch der Meinung, dass dies durchaus akzeptabel ist, da die Top-Level-Modelle in der ARIS-VAD-Notation eigentlich nur als einfachste Möglichkeit zur grafischen Darstellung einer Prozesskette genutzt werden können.
Zum Abschluss der Überprüfung der ARIS VAD-Notation betonen wir noch einmal, dass diese Notation weitgehend illustrativ ist und nicht für die Erstellung komplexer Modelle von Prozessen auf der obersten Ebene einer Organisation gedacht ist.
90 V.V. Repin, V.G. Eliferow. Prozessansatz für das Management
2.7.2. ARIS eEPC-Notation – Erweiterung der IDEF3-Notation
Die ARIS eEPC-Notation (Extended Event Driven Process Chain) ist eine erweiterte ereignisgesteuerte Prozesskette.
Die Notation wurde von Spezialisten der IDS Scheer AG, Deutschland, insbesondere Professor Scheer, entwickelt. In der Tabelle 2.2 zeigt die wichtigsten in der Notation verwendeten Objekte.
Tabelle 2.2 Hauptobjekte, die beim Erstellen von eEPC-Diagrammen verwendet werden
Zusätzlich zu den in der Tabelle angegebenen Hauptobjekten. 2.2 können beim Erstellen eines eEPC-Diagramms viele andere Objekte verwendet werden. In der Praxis ist die Verwendung einer großen Anzahl von Objekten unterschiedlichen Typs unpraktisch, da dies die Größe des Modells erheblich erhöht und die Lesbarkeit erschwert.
91
Um die Bedeutung der ARJS-cEPC-Notation zu verstehen, betrachten Sie die wichtigsten verwendeten Objekttypen und Beziehungen (Abb. 2.34-2.38). In Abb. Abbildung 2.34 zeigt das einfachste ARIS eERS-Modell, das einen Teil des Geschäftsprozesses eines Unternehmens beschreibt.
Aus Abb. Abbildung 2.34 zeigt, dass die Verbindungen zwischen Objekten eine bestimmte Bedeutung haben und den Funktionsablauf innerhalb des Prozesses widerspiegeln. Der Pfeil, der Ereignis 1 und Funktion 1 verbindet, „aktiviert“ oder initiiert die Ausführung von Funktion 1. Funktion 1 „erstellt“ Ereignis 2, gefolgt vom logischen Operatorsymbol „AND“, das die Ausführung der Funktionen 2 und 3 „auslöst“.
Eine sorgfältige Analyse der ARIS eEPC-Notation zeigt, dass sie sich praktisch nicht von der IDEF3-Notation unterscheidet. Der wichtigste Unterschied zwischen ARIS eEPC ist das Vorhandensein eines „Event“-Objekts. Dieses Objekt wird verwendet, um im Modell die möglichen Ergebnisse der Ausführung von Funktionen anzuzeigen, je nachdem, welcher eine oder andere nachfolgende Zweig des Prozesses ausgeführt wird. Die ARIS eEPC-Notation wird offensichtlich gerade deshalb als erweitert bezeichnet, weil darin ein „Ereignis“-Objekt vorhanden ist (in IDEF3 gibt es kein solches Objekt). In Abb. 2.35 enthält Beispiele für die Verwendung von Logik- und Ereignissymbolen beim Erstellen von Modellen in der ARIS eEPC-Notation.
Beim Aufbau von Modellen in ARIS eERS sind folgende Regeln zu beachten:
1. Jede Funktion muss durch ein Ereignis ausgelöst und beendet werden
Ereignis;
2. Jede Funktion darf nicht mehr als einen Pfeil enthalten: „Ich starte
„shchi“ seine Ausführung, und es sollte nicht mehr als einen beschreibenden Pfeil enthalten
Abschluss der Funktion.
Neben diesen Regeln gibt es noch weitere wichtige Voraussetzungen für die Modellerstellung in ARIS. Sie können mit dem Methodenmaterial „ARIS-Methoden“ studiert werden. die gleichzeitig mit der Demoversion des Produkts auf dem Computer installiert wird, sowie in .
In Abb. Abbildung 2.36 zeigt die Verwendung verschiedener Objekte der ARIS eEPC-Notation bei der Erstellung eines Geschäftsprozessmodells.
92____________________________ BB. Repin, V.G. Eliferow.Prozessansatz für das Management
Aus Abb. 2.35 und 2.36 wird deutlich, dass ein Geschäftsprozess in der ARIS eEPC-Notation eine Abfolge von Prozeduren ist, die in der Reihenfolge ihrer Ausführung angeordnet sind. Es ist zu beachten, dass die tatsächliche Dauer von Eingriffen in ARIS eERS nicht visuell dargestellt werden kann. Dies führt dazu, dass es beim Erstellen von Modellen zu Situationen kommen kann, in denen einem Darsteller die Verantwortung übertragen wird
Kapitel 2 Auswahl einer Methodik zur Beschreibung von Geschäftsprozessen__________________________________________ 93
zwei Aufgaben gleichzeitig ausführen. Die beim Aufbau des SIM-YULA-Modells verwendete Logik ermöglicht es uns, die Verzweigung und Zusammenführung eines Geschäftsprozesses abzubilden. Um Informationen über die tatsächliche Dauer von Prozessen zu erhalten und die Auslastung des Personals im Prozess visuell darzustellen, können Sie andere Beschreibungstools verwenden, beispielsweise Gantt-Diagramme im MS Project-System.
Schauen wir uns Beispiele für die Verwendung der ARIS eEPC-Notation zur Beschreibung von Geschäftsprozessen an. In Abb. 2.37. Der Geschäftsprozess der Abwicklung einer Kundenbestellung wird dargestellt. Der gleiche Prozess ist in der IDEF3-Notation in Abb. dargestellt. 2.23.
Der Prozess beginnt mit dem Ereignis „Kundenbestellung erhalten“. Dieses Ereignis löst die Funktion „Bestellung im System aufgeben“ aus, die vom Leiter der Vertriebsabteilung ausgeführt wird. Zur Erledigung der Arbeiten nutzt er ein „Order Accounting System“. Das Ergebnis der Funktionsausführung wird durch das Ereignis „Auftragsabrechnung abgeschlossen“ angezeigt. Anschließend führt der Leiter der Vertriebsabteilung die Funktion „Analyse zur Produktkonformität durchführen“ durch. Das Ergebnis der Ausführung der Funktion sind zwei alternative Ereignisse: „Die Bestellung passt zum Artikel“ und „Die Bestellung passt nicht zum Artikel.“ Der Prozess verzweigt. Um die Verzweigung eines Prozesses anzuzeigen, wird ein logisches Operatorsymbol verwendet – exklusives „OR“.
Die Funktion „Kunden benachrichtigen, dass die Bestellung nicht ausgeführt werden kann“ kann in zwei Fällen ausgeführt werden: 1) Die Bestellung entspricht nicht dem Artikel und 2) Die Produktion ist unmöglich. Um diese Optionen im Prozessdiagramm anzuzeigen, wird das logische Operatorsymbol „OR“ usw. verwendet.
Wie aus Abb. ersichtlich ist. 2.37 unterscheidet sich das Prozessdiagramm in ARIS eERS vom Diagramm in IDEF3 durch das Vorhandensein von Objekten: Ereignisse, Dokumente, Anwendungssysteme und Positionen. Das Diagramm in ARIS eEPS ist optisch aussagekräftiger und wird besser wahrgenommen, allerdings ist die Größe dieses Diagramms deutlich größer als die Größe des IDEF3-Diagramms.
Der oben besprochene Prozess kann auch in der ARIS PCD-Notation (Process Chain Diagram) dargestellt werden – einer Variante von ARIS eEPC. In Abb. Abbildung 2.38 zeigt den Geschäftsprozess der Bearbeitung eines Kundenantrags in der ARIS PCD-Notation. Bei der Beschreibung dieses Prozesses werden alle Objekte verwendet, aus denen der in Abb. 1 dargestellte Prozess besteht. 2.37, sie sind jedoch in Form von Tabellenspalten angeordnet. Die erste Spalte stellt Ereignisse und einige logische Symbole dar, die zweite – Funktionen, die dritte – ein- und ausgehende Dokumente, die vierte – Arten von Anwendungssoftware und die fünfte – Positionen der am Prozess beteiligten Mitarbeiter. Diese Darstellung des Prozesses ist eher „Standard“. Es eignet sich besser für die Prozessdokumentation. Die Darstellung in der ARIS PCD-Notation weist jedoch einen erheblichen Nachteil auf: Sie kann effektiv für einfache (nicht mehr als fünf bis acht Funktionen), vorzugsweise lineare Prozesse, verwendet werden. Es ist umständlich, komplexe Prozesse mit verzweigter Logik mithilfe der ARIS-PCD-Notationen darzustellen, wie in Abb. deutlich zu sehen ist. 2.38.
94_________________________________ BB. Repin. V.G. Eliferow. Prozessansatz für das Management
Reis. 2.37. Beispiel für ein Prozessmodell
Kapitel 2 Auswahl einer Methodik zur Beschreibung von Geschäftsprozessen________________________________ 95
in AR1S eEPC-Notation.
96____________________________ V. V., Repin, V. G. Eliferow.Prozent WESENTLICHER MANAGEMENTANSATZ
Reis. 2.38. Verarbeitungsbeispiel
Kapitel 2 Auswahl einer Methodik zur Beschreibung von Geschäftsprozessen 9 7
AR1S PCD-Anwendungen und Notationen.
98 V.V. Repin, In G. Eliferov Prozessansatz für das Management
AR1S-Organigramm-Notation
Die ARIS Organizational Chan-Notation ist eine der wichtigsten ARIS-Notationen und dient der Erstellung von Diagrammen der Organisationsstruktur eines Unternehmens. Typischerweise wird dieses Modell zu Beginn eines Geschäftsprozessmodellierungsprojekts erstellt. Das Modell spiegelt die bestehenden Unternehmensbereiche in Form einer hierarchischen Struktur wider, wie in Abb.
Das Modell wird aus den Objekten Organisationseinheit, Position, Interne Person usw. aufgebaut.
Die in der Notation enthaltenen Verbindungsarten ermöglichen es, verschiedene Arten von Beziehungen zwischen Objekten der Organisationsstruktur abzubilden. In der in Abb. In Beispiel 2.39 wird das Unternehmen von einem Director verwaltet und der Verbindungstyp ist Organisationsmanager für. Die Hierarchie der Abteilungen wird mithilfe von Beziehungen des Typs „Besteht aus“ aufgebaut. Darüber hinaus können Positionen angegeben werden - Position und die Namen der tatsächlich besetzenden Mitarbeiter - Interne Person, Art der besetzten Verbindung.
Neben Modellen der Hierarchie von Abteilungen können auch Modelle der Hierarchie der Unterordnung in Projektteams, Gruppen etc. erstellt werden. Alle in den Modellen reflektierten Objekte können künftig bei der Erstellung von Geschäftsprozessmodellen verwendet werden. Beim Aufbau komplexer hierarchischer Strukturen kann die Zerlegung eingesetzt werden, um beispielsweise die Struktur einer Abteilung detaillierter darzustellen.
Kapitel 2 Auswahl einer Methodik zur Beschreibung von Geschäftsprozessen_________________________________ 99
Zurück78910111213141516171819202122Nächster
Modell wie besehen– Dies ist ein „Ist“-Modell, d. h. Modell eines bereits bestehenden Prozesses/Funktion. Prozessbefragungen sind ein wesentlicher Bestandteil jedes Systemerstellungs- oder Entwicklungsprojekts. Durch den Aufbau eines AS-IS-Funktionsmodells können Sie klar aufzeichnen, welche Prozesse im Unternehmen ablaufen und welche Informationsobjekte bei der Ausführung von Funktionen auf verschiedenen Detailebenen verwendet werden.
Basierend auf dem Modell WIE ES IST Zwischen den verschiedenen Phasen des Prozesses wird ein Konsens darüber erzielt, „wer was getan hat“ und was jede Phase zum Prozess beiträgt. Ausgangspunkt ist das AS-IS-Funktionsmodell um die Bedürfnisse des Unternehmens zu analysieren, Identifizierung von Problemen und Engpässen und Entwicklung eines Projekts zur Verbesserung von Geschäftsprozessen. Das AS-IS-Modell ermöglicht es uns herauszufinden, „was und wie wir jetzt tun“, bevor wir bestimmen, „was und wie wir morgen tun werden“. Durch die Analyse des AS-IS-Funktionsmodells können wir verstehen, wo die Problemsituation liegt, welche Vorteile neue Prozesse haben und welche Änderungen an der bestehenden Struktur der Prozessorganisation vorgenommen werden. Brauchen Sie Forschung Umstrukturierung(Erkennung und Beseitigung von Mängeln) in bestehenden Prozessen wird durch den Einsatz von Zerlegung (Analyse) erreicht, auch wenn die Funktionalität auf den ersten Blick offensichtlich ist.
Funktionsmodell AS-IS
Also zum Beispiel Schilder Ineffizienz bestehender Prozesse kann sein:
- nutzlose, unüberschaubare und duplizierende Funktionen;
- ineffektiver Dokumentenfluss (das richtige Dokument ist nicht zur richtigen Zeit am richtigen Ort);
- Mangel an Feedback zur Kontrolle (die Funktion wird durch ihr Ergebnis nicht beeinflusst), zur Eingabe (Objekte oder Informationen werden irrational verwendet) usw.
Bei der Erstellung eines AS-IS-Modells kann ein unerfahrener Analyst einen ziemlich häufigen Fehler machen – die Erstellung eines idealisierten Modells, insbesondere wenn das Modell unter dem Einfluss des Wissens (Standpunkts) des Managers erstellt wird. In der Regel weiß ein Manager, wie eine Funktion in Handbüchern und Stellenbeschreibungen ausgeführt werden soll, und weiß oft nicht, wie Untergebene die erforderlichen Funktionen tatsächlich ausführen. Daher werden Modelle genannt SOLLTE SEIN(wie es sein sollte) und falsche Informationen enthalten, die nicht weiter für die Analyse verwendet werden können.
Wenn Sie vor der Aufgabe stehen, die Arbeit einer Organisation zu beschreiben, stehen Ihnen riesige Mengen unorganisierter Informationen zur Verfügung. Wenn Sie ratlos sind und nicht wissen, wie Sie das alles angehen sollen, empfehle ich die folgende Abfolge von Maßnahmen:
2. Bestimmen Sie, welche Art von Geschäftsprozessmodell Sie erstellen müssen, und wählen Sie eine Liste von Methoden aus, die bei der Modellierung verwendet werden können (verwenden Sie den unten beschriebenen Leitfaden).
3. Vergleichen Sie Modellierungsmethoden und Notationen für Ihren Modelltyp und wählen Sie die richtige Methode für Sie aus:
- Methoden zur Modellierung von Geschäftsprozessen und Datenflüssen auf oberster Ebene;
- Methoden zur Modellierung von Arbeitsabläufen;
- Methoden zur Modellierung der Informationsstruktur.
4. Erstellen Sie ein Modell.
Ein Leitfaden zu Notationen und Methoden
Um nicht in alle möglichen Methoden und Notationen verwickelt zu werden, die zum Aufbau der gängigsten Organisationsmodelle (Managementmodelle – Geschäftsprozesse auf der obersten Ebene, Workflow-Modelle und Informationsmodelle – Informationsstruktur) verwendet werden, biete ich einen Leitfaden und an seine weiteren Einzelheiten.
Wenn Ihnen mindestens ein Name der Methodik oder Notation nicht bekannt ist, lesen Sie weiter. Wenn Ihnen alles bekannt, aber interessant ist und Sie Ihr Gedächtnis auffrischen möchten, werfen Sie einen kurzen Blick darauf.Klassische Methoden
Trotz ihrer Unterschiede, die hauptsächlich mit der Bezeichnung der Diagramme und den verwendeten Objekttypen zusammenhängen, sind moderne Methoden zur Beschreibung von Geschäftsprozessen nahezu identisch und stellen geringfügige Änderungen gegenüber klassischen Standards dar.
