Die Methode OMEGA
Erläuterungen zur Methode OMEGA
Objektorientierte Methode zur Geschäftsprozessmodellierung und -analyse
Stand: Mai 2012
Inhalt
1 Die OMEGA-Modellierungskonvention 4
2 Konstrukte der Methode OMEGA 4
3 Die Konstrukte in der Übersicht 5
4 Anordnung der Konstrukte bezogen auf einen Geschäftsprozess 10
5 Anordnung von Geschäftsprozessen 11
6 Kopplung von Geschäftsprozessen 11
7 Entscheidungen 12
8 Konnektoren 14
9 Meilensteine 15
10 Hierarchisierung und Aggregation von Geschäftsprozessen 16
Die Methode OMEGA
1 Die OMEGA-Modellierungskonvention
Die Methode OMEGA (Objektorientierte Methode zur Geschäftsprozessmodellierung und -analyse) entstand am Heinz Nixdorf Institut und wurde zusammen mit der UNITY AG weiterentwickelt. Ziel war eine Methode, welche einerseits die vollständige Modellie- rung einer Ablauforganisation in einem Modell ermöglicht und die sich andererseits mit- tels einfacher und prägnanter Visualisierung als Instrument zur anschaulichen Analyse und Planung von Leistungserstellungsprozessen eignet.
Die vollständige Modellierung einer Ablauforganisation bedeutet, sowohl die Objekte der Aufbau- als auch die Objekte der Prozessorganisation des Unternehmens in einer Graphik abzubilden. Dies geschieht durch Zuordnen von Organisationseinheiten zu Ge- schäftsprozessen.
Die Erfahrung zeigt, dass mit der Methode OMEGA modellierte Geschäftsprozessmodel- le intuitiv verständlich sind. Durch die Beschränkung auf die wesentlichen Objekte eines Geschäftsprozesses ist die Methode über alle Unternehmensebenen hinweg einsetzbar.
Die Modelle zeichnen sich durch eine hohe Flexibilität bei der Darstellung projekt- und unternehmensspezifischer Inhalte aus. Darüber hinaus lassen sich aus diesen Modellen die formalen Prozessspezifikationen für Produktdatenmanagementsysteme (z.B. Konst- ruktionsfreigabeprozess) und für Workflowmanagementsysteme ableiten.
2 Konstrukte der Methode OMEGA
Die Methode OMEGA stellt eine graphische Notation zur Verfügung, die alle wesentli- chen Sachverhalte anschaulich verdeutlicht, und den Modellierer bei der Modellentwick- lung weitestgehend von textuellen Angaben befreit. OMEGA bildet Prozessketten, die Informations- und Materialflüsse sowie die Parallelität von Prozessen graphisch ab.
Die Modell-Analyse besteht aus einer Auswertung der in der Modell-Entwicklung erfass- ten Sachverhalte und liefert Hinweise auf mögliche Schwachstellen. Für die Modellie- rung der Ablauforganisation stellt OMEGA die folgenden Konstrukte bereit:
▪ Geschäftsprozesse und Aktivitäten,
▪ Organisationseinheiten,
▪ Externe Objekte,
▪ Bearbeitungsobjekte,
▪ Technische Ressourcen,
▪ Kommunikationsbeziehungen.
Abbildung 1 gibt einen Überblick über die Konstrukte der Methode OMEGA. Die Bedeu- tung und die Notation der einzelnen Elemente werden nachfolgend detailliert erläutert.
Abbildung 1: Übersicht der OMEGA-Konstrukte
3 Die Konstrukte in der Übersicht
Organisationseinheit
Eine Organisationseinheit repräsentiert eine Stel- le, eine Abteilung, ein Team etc., die einen Prozess durchführt bzw. verantwortet. Eine Organisationsein- heit kann mehrfach in einem Prozessmodell verwen- det werden.
Geschäftsprozess
Ein Geschäftsprozess ist eine Folge logisch zusam- menhängender Aktivitäten zur Erbringung eines Er- gebnisses oder Veränderung eines Objekts (Trans- formation).
Er besitzt einen definierten Anfang (Auslöser oder In- put) und ein definiertes Ende (Ergebnis oder Output).
Ein Geschäftsprozess muss über die Kombination seines Namens und Zuordnung zu einem Hauptge- schäftsprozess eindeutig identifizierbar sein.
Organisationseinheit
Aktivität
Die Methode OMEGA
Externes Objekt außerhalb der Organisation Externes Objekt außerhalb des Untersuchungsbe- reichs und außerhalb des betrachteten Systems.
(z.B. Zulieferer, Auftraggeber)
Externes Objekt innerhalb der Organisation – außerhalb des Untersuchungsbereichs
Externes Objekt außerhalb des Untersuchungsbe- reichs, welches jedoch grundsätzlich zur Organisati- on des betrachteten Systems gehört. (z.B. unterneh- mensinterner Kunde)
Materialspeicher
Ein Materialspeicher unterstützt die Geschäftspro- zesse, indem er Materialobjekte speichert oder zur Verfügung stellt. Es ist zwischen Lagern und Puffern zu unterscheiden.
Lager: wenn der Materialspeicher mit einem be- standsführenden Geschäftsprozess in Verbindung steht.
Puffer: wenn Bestände nicht erfasst werden, kein be- standsführenden Geschäftsprozess.
IT-System
IT-Systeme sind Hardwarekomponenten, systemna- he Software, Applikationen oder Kombinationen dar- aus. Sie speichern Informationen, verarbeiten diese und stellen diese zur Verfügung.
Papierspeicher
Ein Papierspeicher unterstützt die Geschäftsprozes- se, indem er Papierinformationsobjekte speichert oder zur Verfügung stellt. (z.B. Ablageordner, Archiv, Lieferantenregister)
außerhalb der Organisation
innerhalb der Organisation
Materialspeicher
IT-System
Papier- speicher
Betriebsmittel
Ein Betriebsmittel unterstützt die Geschäftsprozes- se, indem es Material transformiert und Informati- onsobjekte (z.B. NC-Programme) speichert oder zur Verfügung stellt. Das Betriebsmittel selbst kann kein Material speichern. Es kann jedoch Informationsob- jekte (z.B. NC-Programme, Betriebsdaten) empfan- gen, speichern oder zur Verfügung stellen.
Papierinformationsobjekt
Ein Papierinformationsobjekt stellt ein Input- bzw.
Outputobjekt eines Geschäftsprozesses auf dem Medium Papier dar. Ein Papierinformationsobjekt wird durch seinen Namen eindeutig beschrieben.
Wird ein bestehendes Papierobjekt durch einen Ge- schäftsprozess geändert, so muss dieses über den Namen deutlich gemacht werden.
Mündliches Informationsobjekt
Ein mündliches Informationsobjekt stellt ein Input- oder Outputobjekt in mündlicher Form für einen Ge- schäftsprozess dar. Dabei handelt es sich um eine Information, die weder formal fixiert noch reprodu- zierbar ist. (z.B. persönliches Gespräch, telefonische Übermittlung eines Auftrags)
IT-Informationsobjekt
Ein IT-Objekt stellt ein digitales Bearbeitungsobjekt eines Geschäftsprozesses dar, der durch ein IT-Sys- tem bearbeitbar ist. Ein IT-Objekt entsteht, wenn ein Geschäftsprozess bei der Erzeugung eines Output- Objektes durch eine IT-Applikation (z.B. ERP-Sys- tem) unterstützt wird. (z.B. E-Mail, 3D-CAD-Modell- Datei)
Materialobjekt
Ein Materialobjekt ist ein Input- bzw. Outputobjekt ei- nes Geschäftsprozesses in Form von Material Damit kann der Material-/Produktfluss innerhalb eines Un- ternehmens abgebildet werden.
Betriebs- mittel
Papier- objekt
mündl.
Informations- objekt
IT-Objekt
Material- objekt
Die Methode OMEGA
Informationsgruppe
Eine Informationsgruppe besteht aus mehreren In- formationsobjekten. Dabei handelt es sich um eine beliebige Kombination aus IT-Objekten, Papierobjek- ten, mündlichen Informationsobjekten und Material- objekten. Sie stellt ein Input- oder Outputobjekt dar.
(z.B. Software-Paket inkl. Datenträger und Versand- dokumente)
Patient | Person
Ein Patient ist ein Input- bzw. Outputobjekt eines Geschäftsprozesses in Form eines Menschen. Pa- tienten werden behandelt, koordiniert bzw. durch die klinischen Prozesse geschleust. Eine Person kann geschult, transportiert, zugeordnet, etc. werden.
Kennzahl
Hinweis auf eine im Prozess genutzte Kennzahl zur Messung der Leistungsfähigkeit eines Prozesses bzw. seiner Ergebnisse. Die Definition der Kennzahl ist als Text oder Formel anzugeben.
Methode
Hinweis auf eine im Prozess genutzte Methode. Die Modellierung des Konstrukts Methode ist abhängig von der betrachteten Detaillierungsebene. Ab einem gewissen Detaillierungsgrad ist die Methode als eine Folge von Geschäftsprozessen darzustellen.
Fähigkeit
Das Symbol wird verwendet, um in einem Pro- zess eine besondere Fähigkeit (z. B. vorhandenes OMEGA-Know-how) zu kennzeichnen.
Potential
Das Symbol wird verwendet, um in einem Prozess ein Potenzial (z.B. fehlendes OMEGA-Know-how) im Ablauf zu kennzeichnen.
Infor- mations-
gruppe
Patient
Person
Kennzahl
Methode
Fähigkeit
Potenzial
Meilenstein
Meilensteine kennzeichnen Zwischenergebnisse und Entscheidungspunkte im Prozess- bzw. Projek- tablauf. Um einen Meilenstein festzustellen und die nachfolgenden Prozessschritte freizugeben, müssen definierte Ergebnisse vorliegen bzw. Ziele erreicht sein. Meilensteine werden in der Regel als Mess- punkte zur Erreichung von Gesamtprozesszielen genutzt. Meilensteine erhalten einen Identifikator. An einem Meilenstein sind die Personen anzugeben, die an der Abnahme- bzw. Freigabeentscheidung betei- ligt sind (kleines Quadrat). Der Entscheider ist her- vorzuheben (kleines dunkles Quadrat).
Konnektor
Verweis zwischen Prozessen
Eindeutigkeit über eine (alpha-)numerische Referenz.
Abgrenzung
Separation von Prozessen nach Domänen oder Ar- beitsaufgaben zur Komplexitätsreduktion.
Die Methode OMEGA
4 Anordnung der Konstrukte bezogen auf einen Geschäftsprozess
Abbildung 2: Anordnung der Konstrukte
Der Geschäftsprozess wird mittig in der oberen Hälfte seiner ausführenden Organisati- onseinheit platziert. Dem Geschäftsprozess kann in Ergänzung zu seiner Bezeichnung ein Identifikator (Nummer) zugeordnet werden. Dieser wird der Benennung des Ge- schäftsprozesses vorangestellt.
Der Name der Organisationseinheit steht innerhalb des Rahmens unten links.
Die technischen Ressourcen (Betriebsmittel, IT-Applikation, Papierspeicher, Material- speicher) sind entlang des unteren Randes der Organisationseinheit zu platzieren.
Der Raum unterhalb der Organisationseinheit kann für ergänzende Definitionen, Kom- mentare, Erläuterungen und Beschreibungen genutzt werden.
Die Verknüpfung zwischen Geschäftsprozessen, externen Objekten und technischen Ressourcen erfolgt durch die direkten und indirekten Kommunikationsbeziehungen, die als Pfeile dargestellt werden. Auf den Kommunikationsbeziehungen werden die Bear- beitungsobjekte (mündliche Information, IT-Objekt, Papierobjekt, Materialobjekt, Infor- mationsgruppe) angeordnet, die im Geschäftsprozess bearbeitet werden (Input-Objekte) bzw. aus ihm als Ergebnis hervorgehen (Output-Objekte).
Bearbeitungsobjekte durchlaufen einen Geschäftsprozess immer von links nach rechts – entsprechend gelangen Input-Objekte von links in den Geschäftsprozess und Output- Objekte verlassen ihn rechts.
5 Anordnung von Geschäftsprozessen
Um ein Geschäftsprozessmodell zu erhalten, ist es zunächst notwendig, die Geschäfts- prozesse selbst zu erzeugen und diese nach ihren Reihenfolgebeziehungen anzuord- nen. Auf diese Weise wird der prinzipielle Ablauf der Leistungserstellung modelliert. Die für die Geschäftsprozesse notwendigen Input- und Output-Objekte – d.h. die Bearbei- tungsobjekte – werden im nächsten Schritt angeordnet. Daraus ergeben sich die not- wendigen technischen Ressourcen für die einzelnen Geschäftsprozesse.
Die Geschäftsprozesse werden im Geschäftsprozessmodell entsprechend ihrer Rei- henfolgebeziehungen modelliert. Parallele Geschäftsprozesse sind untereinander an- zuordnen, sequentielle Prozesse werden horizontal von links nach rechts dargestellt.
Logische Abhängigkeiten zwischen Geschäftsprozessen sind in der Regel mit Hilfe der Konstrukte für Entscheidungen (vlg. Abbildung 4) zu modellieren.
Werden Geschäftsprozesse wiederholt durchgeführt, so werden sie nicht mehrfach dar- gestellt, da ein Geschäftsprozess nur einmal in einem Modell vorhanden sein darf.
6 Kopplung von Geschäftsprozessen
Geschäftsprozesse können auf verschiedene Arten mit Kommunikationsbeziehungen gekoppelt werden. Diese sind in Abbildung 3 dargestellt.
Direkte Kopplung: Eine direkte Kopplung zwischen Geschäftsprozessen liegt vor, wenn ein Geschäftsprozess einem anderen Geschäftsprozess ein Bearbeitungsobjekt direkt und unmittelbar übermittelt. Bei einer direkten Kopplung wird der Empfänger vom Sen- der zur Ausführung seiner Aktivität angestoßen.
Beispiel: Fertigungsauftrag wird an Fertigung gesandt und löst Produktion aus.
Indirekte Kopplung (Speicherkopplung): Bei der Speicherkopplung besteht keine direk- te logische und zeitliche Verknüpfung zwischen dem erzeugenden Geschäftsprozess und dem weiterverwendenden Geschäftsprozess. Sie sind indirekt über eine technische Ressource gekoppelt: Der erzeugende Geschäftsprozess speichert das Bearbeitungs- objekt in einer technischen Ressource (IT-Applikation, Materialspeicher etc.). Der weiter- verwendende Geschäftsprozess entnimmt es aus dieser, ohne dass die Prozesse direkt miteinander kommunizieren.
Beispiel: Auftrag wird erfasst und im ERP-System abgelegt; zu einem späteren Zeitpunkt wird der Auftrag bearbeitet und eine Bestätigung versandt.
Die Methode OMEGA
Abbildung 3: Direkte und indirekte Kopplung von Geschäftsprozessen
Kommunikationsbeziehungen zwischen Geschäftsprozessen und externen Objekten bzw. technischen Ressourcen erfolgen in der Regel über eine direkte Kopplung. Die indirekte Kopplung tritt vermehrt bei IT-unterstützten Arbeitsabläufen im Unternehmen auf. Kommunikationsbeziehungen, die kein Bearbeitungsobjekt übertragen, treten in den Geschäftsmodellen bei korrekter Anwendung der Methode OMEGA nicht auf.
7 Entscheidungen
Durch die Modellierung von Entscheidungen lassen sich logische Abhängigkeiten zwi- schen Geschäftsprozessen darstellen. OMEGA unterscheidet folgende Entscheidungen:
▪ UND-Verknüpfungen
▪ ODER-Verknüpfungen
▪ EXKLUSIV-ODER-Verknüpfungen
Entscheidungen können sowohl einen Prozess in mehrere Abschnitte verzweigen als auch mehrere Teilprozesse zusammenführen. Die Kriterien für EXKLUSIV-ODER-Ent- scheidungen sind neben den zugehörigen Kommunikationsbeziehungen anzugeben.
Der überwiegende Teil von Entscheidungen, die in Geschäftsprozessmodellen verwen-
Abteilung 2
4 Auftrag fertigen
IT-System
Abteilung 1
3 Auftrag einplanen
IT-System Fertigun
gsauftrag Fertigun
gsauftrag
schließlich UND-Verknüpfungen verwendet, ist die Benutzung des Konstrukts wahlfrei.
Wird das Konstrukt nicht modelliert, steht die Verzweigung bzw. die Verknüpfung zweier Kommunikationsbeziehungen für eine UND-Verknüpfung. Werden in einem Geschäfts- prozessmodell ODER- bzw. EXKLUSIV-ODER Verknüpfungen verwendet, sind die Kon- strukte zwingend zu verwenden. In diesem Fall gilt das auch für das Konstrukt der UND- Entscheidung.
Abbildung 4 gibt einen Überblick über die drei Entscheidungswege. Die Abbildungen 5 und 6 zeigen Modellierungsbeispiele für Entscheidungswege.
Abbildung 4: Übersicht Verknüpfungen
Abbildung 5: Beispiel einer UND-Verknüpfung
Die Methode OMEGA
Abbildung 6: Modellierungsbeispiel EXKLUSIV-ODER-Verknüpfung
8 Konnektoren
Durch das Modellieren von Kommunikationsbeziehungen zwischen Geschäftspro- zessen, die auf der Darstellungsebene weit entfernt sind, wird das Modell leicht un- übersichtlich. Um die Übersichtlichkeit des Prozessmodells zu wahren, können solche Kommunikationsbeziehungen mit Hilfe von Konnektoren unterbrochen werden. Die Konnektoren dienen dabei als Verweis zwischen den gekoppelten Geschäftsprozes- sen.
Abbildung 7: Richtungsunabhängige Überbrückung von graphischen Distanzen
9 Meilensteine
Meilensteine kennzeichnen Zwischenergebnisse und Entscheidungspunkte im Prozess- bzw. Projektablauf. Um einen Meilenstein festzustellen und die nachfolgenden Prozess- schritte freizugeben, müssen definierte Ergebnisse vorliegen bzw. Ziele erreicht sein.
Meilensteine werden in der Regel als Messpunkte zur Erreichung von Gesamtprozess- zielen genutzt. Meilensteine erhalten einen Identifikator. An einem Meilenstein sind die Personen anzugeben, die an der Abnahme- bzw. Freigabeentscheidung beteiligt sind (kleines Quadrat). Der Entscheider ist hervorzuheben (kleines dunkles Quadrat).
Kommunikationsbeziehung für den empfangenden Geschäftsprozess
Die Methode OMEGA
10 Hierarchisierung und Aggregation von Geschäftsprozessen
Für die Erstellung von Geschäftsprozessmodellen ist ein der Problemstellung angemes- sener Detaillierungsgrad (Modellierungstiefe) zu wählen. Unterschiede in der Modellie- rungstiefe innerhalb eines Modells (eines Prozessplots) sollten unbedingt vermieden werden. Die Wahl des Detaillierungsgrads hängt von der Komplexität des jeweiligen Untersuchungsbereichs und der Zielsetzung des Projekts ab.
Der Detaillierungsgrad eines Geschäftsprozessmodells kann variiert werden, indem – ausgehend von einer bisherigen Modellierungsebene – die Modell-Elemente aggregiert oder detailliert werden. Aggregierte Geschäftsprozessmodelle bieten den Vorteil einer geringeren Komplexität und geben, zum Beispiel in der Startphase eines Projekts, einen schnellen Überblick über die Ablauforganisation. Detaillierte Geschäftsprozessmodelle hingegen ermöglichen, Kernpunkte der Ablauforganisation näher zu betrachten.
Die Aggregations- und Dekompositionsmöglichkeiten der Methode OMEGA sollen aus- schnittweise anhand einer Aggregation von Geschäftsprozessen auf Abteilungsebene zu einem Hauptgeschäftsprozess auf Hauptabteilungsebene verdeutlicht werden (Ab- bildung 7). Folgende Regeln sind bei der Dekomposition eines übergeordneten Modells zu beachten. Die Organisationseinheiten der Geschäftsprozesse und des zugehörigen Hauptgeschäftsprozesses werden in einer einheitlichen Farbe modelliert.
Die Input- und Output-Objekte des Grobmodells müssen Input- und Output-Objekte der detaillierten Prozesskette sein. Sind also „Fertigungsunterlagen“ das Ergebnis des Ge- schäftsprozesses „Entwicklung durchführen“, müssen die „Fertigungsunterlagen“ auch aus den detaillierten Prozessen als Output-Objekt modelliert werden. Im Rückschluss sind durch die Aggregation die Kommunikationsbeziehungen zwischen den einzelnen Teilen der Prozesskette eines Hauptgeschäftsprozesses nicht mehr ersichtlich. So wird z.B. die Weiterleitung des Papierobjektes „Projektplan“ von „Entwicklung planen“ zu
„Entwicklung durchführen“ in dem Hauptgeschäftsprozess nicht modelliert. Bearbei- tungsobjekte, die die detaillierte Prozesskette verlassen, müssen auch im aggregierten Modell dargestellt werden.
Als Input- bzw. Output-Objekte für einen Hauptgeschäftsprozess werden die Bearbei- tungsobjekte des ersten bzw. letzten Geschäftsprozesses aggregiert. Alle weiteren In- formationsobjekte, die innerhalb des Modells auf unteren Ebenen vorhanden sind, treten auf Hauptabteilungsebenen nicht mehr auf.
Für die Aggregation der Bearbeitungsobjekte gelten die Regeln, dass gleichartige Ob- jekte aggregiert werden können (bspw. mehrere Papierobjekte zu einem Papierobjekt) und ungleichartige nicht aggregiert werden können (bspw. Informationsobjekt zu einem Materialobjekt)
Abbildung 9: Aggregation mehrerer Geschäftsprozesse zu einem Hauptprozess
