| Grundlagen - Geschäftsprozessmodellierung |
|
| Einleitung |
Auf die Analyse, Repräsentation und das Management von Wissen innerhalb von Organisation und ihrer Prozesse wurde schon immer viel Wert gelegt [KoPl00]. Es wurde viel an der Entwicklung und Evaluation von Ontologien für die Prozessmodellierung, der Spezifikation von Prozessmodellierungssprachen sowie der Methoden und Konzepte für die Geschäftsprozessmodellierung gearbeitet (vgl. z.B. [WaWe93], [Web97], [GrRo99], [EJLT99], [SuOs97], [Herb97], und [Öst95]). Geschäftsprozessmodelle können für verschiedene Zwecke genutzt werden:
- Dokumentation von Prozessen einer Organisation zur Unterstützung der Kommunikation
- Analyse von Geschäftsprozessen
- Simulation von Prozessen
- Unterstützung des Business Process Reengineerings
- Softwareentwicklung prozessorientierter Anwendungen
Geschäftsprozessmodelle stellen ein übliches Medium für die Kommunikation zwischen Fachleuten und Neueinsteigern dar. Sie repräsentieren domänensprezifische Konzepte und ermöglichen eine besser Weitergabe vorhandenen Wissens über die Organisation und ihrer Prozesse. Die Analyse von Geschäftsprozessen erfordert eine detaillierte Beschreibung von Geschäftsprozessmodellen sowie verwandter Konzepte (im Hinblick auf den Zweck der Analyse).
In Abhängig vom Ziel der Analyse muss eine Modellierungssprache bestimmte Sprachmittel zur Modellierung aller Aspekte innerhalb des Betrachtungswinkels zur Verfügung stellen. Analysen könnten zum Beispiel der Aufdeckung von Schwächen innerhalb bestehender Prozesse dienen. Entsprechende Sprachmittel, die von einer Prozessmodellierungssprache zur Verfügung gestellt werden, dienen der Ermittlung von Medienbrüchen, redundanten Prozessen oder anderen Verbesserungspotentialen. Eine weitergehende Optimierung ist abhängig vom Formalisierungsgrad der Beschreibung des Geschäftsprozessmodells. Die Anpassung und Änderung der Prozesse im Sinne eines Business Process Reengineerings könnte aufgrund identifizierter Schwächen notwendig werden.
|
| Geschäftsprozessmodellierung mit MEMO-OrgML |
MEMO (Multi-Perspective Enterprise Modelling) ist eine Methode zur Modellierung von Organisationen aus verschiedenen Sichten sowie auf unterschiedlichen Abstraktionsebenen. MEMO beinhaltet verschiedene Sprachen zur Modellierung von statischen, funktionalen und dynamischen Aspekten eines Unternehmens. Eine dieser Sprachen ist MEMO-OrgML (Organisation Modelling Language), mit deren Hilfe die Modellierung der Strukturen und Prozesse einer Organisation unterstützt wird. Ressourcen-Modellierung war innerhalb der ersten Konzeptualisierung von MEMO-OrgML nicht vorgesehen, wird jedoch in naher Zukunft hinzugefügt werden.
Ein einführendes Beispiel eines mit MEMO-OrgML modellierten Prozesses ist in der unteren Abbildung zu sehen. Ein Auftrag geht bei der Vertriebsabteilung ein, dessen Daten direkt anschließend geprüft werden (Prozess Nr. 1 'Check Data'). Bei gültigen Daten (Ereignis Nr. 4 'Valid Data') wird der Auftrag weiter bearbeitet, bei ungültigen Daten (Ereignis Nr. 3) wird er abgebrochen. Auf den Abbruch eines Auftrags folgt das Senden einer Ablehnungsnachricht an den Kunden in Prozess Nr. 9 ('Compose Rejection Message'). Eine weitere Bearbeitung des Auftrags umfasst die Eingabe der Daten in das Auftrags-Management-System (Prozess Nr. 2 'Enter Order') gefolgt von den parallel ausgeführten Prozessen 6, 7 und 8. Prozess Nr. 6 ist ein komponierter Prozess, der aus einem oder mehreren Subprozessen besteht. Der Prozess namens 'Compose Acceptance Message' (Nr. 7) stellt einen teilautomatisierten Prozess dar, der durch die Vertriebsabteilung ausgeführt wird. Prozess Nr. 8 ist ein vollständig automatisierter Prozess, durch den eine Standard-Email-Nachricht an den Kunden gesendet wird.
|
 |
| Die folgende Auflistung gibt einen kurzen Überblick der Sprachkonzepte und ihrer Notation in MEMO-OrgML.
|
| Prozesssymbole |
|
 | Abstrakter Prozess |
|
 | Aggregierter Prozess |
|
 | Manueller Prozess |
|
 | Teilautomatischer Prozess |
|
 | Automatischer Prozess |
|
 | Kontinuierlicher Prozess |
|
 | Vom Auftragnehmer durchgeführter Prozess |
|
 | Von autonomer Institution durchgeführter Prozess |
|
 | Von externer Organisation durchgeführter Prozess ('Black Box') |
|
|
| Dekompositionshierarchie |
|
 | Stellt die Dekompositionsbeziehung zwischen aggregierten bzw. abstrakten Prozesstypen und anderen Prozesstypen dar. |
|
|
| Ereignissymbole |
|
 | Start-Ereignis |
|
 | End-Ereignis |
|
 | Relevante Änderung des Informationsbestandes
(unspezifiziertes Ereignis) |
|
 | Nachricht eingetroffen |
|
 | Zeitbezogenes Ereignis -
Zeitintervall ist abgelaufen |
|
 | Zeitbezogenes Ereignis -
Zeitpunkt erreicht |
|
|
| Kontrollstrukturen |
|
 | Prozess erzeugt Ereignis |
|
 | Ereignis löst Prozess aus |
|
 | Parallele Ausführung |
|
 | Synchronisation nach der Terminierung einer der parallelen Prozesse |
|
 | Synchronisation nach der Terminierung aller paralleler Prozesse |
|
|
| Ausnahmen |
|
 | Ausnahmen werden systemweit festgelegt
(z.B. Zusammenbruch des Kommunikationskanals, Time-Out) |
|
|
| Anmerkungen (natürlichsprachlich) |
|
 | Hier können Bedingungen (Constraints) annotiert werden. |
|
 | Hier können sonstige Anmerkungen festgehalten werden. |
|
|
| Oben |
| Weitere Konzepte der Geschäftsmodellierung |
|
Neben den oben genannten prozessorientierten Konzepten gibt es zwei weitere Konzepte, die für eine prozessorientierte Modellierung von Organisationen zentral sind. Organisationseinheiten entsprechen Abteilungen, Geschäftsbereichen oder Rollen, die den Geschäftsprozessen als verantwortliche Akteure zugeordnet werden.
|
| Organisationseinheiten |
Die statische Struktur einer Organisation kann durch ein Organigramm beschrieben werden, das eine Organisation anhand ihrer Untereinheiten sowie deren Beziehungen zueinander darstellt. Das Meta-Modell zur Modellierung von Organigrammen ist in Teil a) der Abbildung auf der rechten Seite dargestellt. Eine abstrakte Organisationseinheit kann entweder eine Position oder eine Organisationseinheit repräsentieren. Jede Organisationseinheit stellt eine Komposition anderer abstrakter Organisationseinheiten dar. Eine Position dient der elementaren Beschreibung der Verantwortlichkeiten eines Mitarbeiters. Teil b) der rechten Abbildung zeigt ein Beispiel für ein Organigramm: Die dargestellte Firma besteht dabei aus drei Abteilungen: Einkauf, Produktion und Vertrieb.
Organisationseinheiten und Rollen sind den Geschäftsprozessen zugeordnete Elemente, welche sich auf menschliche Akteure beziehen, die für die Ausführung eines Geschäftsprozesses verantwortlich sind. Die hier beschriebenen Organisationseinheiten und Positionen können Geschäftsprozessen zugeordnet werden. Rollen sind in Organigrammen nicht notwendigerweise definiert, können jedoch Geschäftsprozessen zugeordnet werden.
|
|
 |
|
| Ressourcen |
|
Ressourcen sind bei der Prozessmodellierung essentiell [PSO99]. Prozesse und ihre Beziehungen beschreiben hauptsächlich dynamische Aspekte sowie die Reihenfolge von Ereignissen. Den Prozessen zugeordnete Ressourcen spezifizieren zusätzlich Subjekte und Objekte der Geschäftsprozesse. Ressourcen sind im Allgemeinen nicht in unbegrenzter Menge verfügbar (vgl. [Nübe01], [PSO99]). Infolgedessen muss die Nutzung von knappen Ressourcen bei der Analyse oder Simulation der Prozesse sowie der Entwicklung einer Workflow-Anwendung oder eines Informationssystems berücksichtigt werden. Da sich die Modellierungssprache für Ressourcen in MEMO-OrgML momentan in Entwicklung befindet, wird an dieser Stelle keine graphische Notation, jedoch eine kurze Einführung in das zugrunde liegende Meta-Modell gegeben. Ein Auszug dieses Meta-Modells ist in der folgenden Abbildung zu sehen. Die Klasse 'AbstractResource' stellt die Wurzel der Generalisierungshierarchie für Ressourcen dar. Jede Ressource hat einen Namen ('name: String'), eine textuelle Beschreibung ('description: String') und eine Liste von Attributen ('attributes[0..*]:ResourceAttribute'). Jedes Ressourcen-Attribut ist ein Name-Typ-Paar für die Spezifikation der benutzerdefinierten Attribute der Ressourcen.
|
 |
In der Prozessmodellierung unterscheidet man generell zwischen menschlichen, physischen und immateriellen Ressourcen. Eine menschliche Ressource ist eine Abstraktion unterschiedlicher Perspektiven auf die Mitarbeiter. Beispiele für solche Perspektiven sind konkrete Angestellte, durch Mitarbeiter erfüllte Rollen oder geschäftsorientierte Funktionen. Physische Ressourcen umfassen alle materiellen Objekte, die innerhalb eines Geschäftsprozesses benötigt werden. Beispiele für physische Ressourcen sind Produktionsstätten, Rohstoffe oder Computer Hardware. Im Gegensatz dazu besitzen immaterielle Ressourcen keine physische Erscheinungsform. Daten, Informationen, Software oder auch Wissen sind Beispiele für immaterielle Ressourcen.
Menschliche Ressourcen (Human Resources) sind Abstraktionen von Personen, Mitarbeitern, Rollen oder anderen Perspektiven auf die Mitarbeiterschaft. Sie können mit konkreten Personen oder Mitarbeitern einer Organisationen sowie abstrakten Organisationseinheiten in einem Organigramm assoziiert werden. Daher kann eine menschliche Ressource durch verschiedene Aspekte charakterisiert werden. Eine menschliche Ressource:
- kann eine aktive Rolle spielen
- kann für die Ausführung von E-Business-Prozessen verantwortlich sein
- benötigt spezielle Qualifikationen und Kompetenzen für ihren Job
Der Typ 'HumanResource' ist ein Untertyp von AbstractResource und besitzt die zwei Attribute 'qualification' und 'competenceProfile' vom Typ String. Die Qualifikation stellt ein objektiv beschreibbares Kriterium für die Fähigkeiten einer menschlichen Ressource dar. Normalerweise wird das Zeugnis über die Qualifikation von einer etablierten Ausbildungseinrichtung ausgestellt. Die Kompetenz einer menschlichen Ressource reflektiert die Eignung der Personen. Daher entspricht ein Kompetenzprofil der Summe relevanter persönlicher Stärken.
Physische Ressourcen umfassen alle innerhalb eines Geschäftsprozesses genutzten materiellen Objekte, die weder menschlich noch immateriell sind. Nach Heinen [Hei88, S. 242] kann im Kontext der industriellen Produktion zwischen nicht-konsumierbaren Ressourcen (Potentialfaktoren) und konsumierbaren Ressourcen (Repetierfaktoren) unterschieden werden. Potentialfaktoren werden während des Produktionsprozesses nicht verbraucht und sind somit auch danach verfügbar, während Repetierfaktoren entweder einen Teil des resultierenden Produktes ausmachen oder verbraucht werden, so dass sie nicht mehr verfügbar sind [SS01, S. 89 ff]. Wir abstrahieren an dieser Stelle von physischen Ressourcen, da diese im Kontext der Workflow-Anwendungen sowie der präsentierten Perspektiven irrelevant sind.
Immaterielle Ressourcen sind solche ohne physisches Erscheinungsbild. Software, im Sinne einer Menge von Programmen, die auf Computer-Hardware laufen, stellt eine zentrale Ressource im Prozess der Workflow-Unterstützung dar. Der Metatyp Software besitzt zwei Attribute: systemRequirements und scalability - beide vom Typ String. Systemvoraussetzungen werden in Form von Text modelliert und beschreiben die Umgebung für die Ausführung eines Softwaresystems (z.B. Prozessorarchitektur, minimaler Hauptspeicher oder Betriebssystem). Skalierbarkeit entspricht der Fähigkeit eine wachsende Anzahl von Clients zu unterstützen. Der Metatyp Information wurde entwickelt, um Informationen oder Wissen zu repräsentieren, die innerhalb der Workflows relevant sind. Als Attribute besitzt er name (eine symbolische Referenz auf eine Informationen-Instanz) und typeDefinition vom Typ String, der die Strukturierung der Informationen beschreibt. Beispiele für Informationen sind spezielle Kundendaten oder bestimmtes Unternehmenswissen.
|
| Oben |
