Aktuelle Konzepte zur Geschäftsprozessmodellierung

Diplomarbeit von Philipp Wöss

Einleitung:

Ohne entsprechende Effektivitäts-, Effizienz- und Kostensenkungsprogramme kommen Unternehmen in den Hochlohnländern (Österreich, Deutschland, Frankreich, Schweiz, USA, etc.) heutzutage fast nicht mehr aus. Hohe Lohnnebenkosten, hohe Grundstückspreise und stetig steigende Energiekosten senken die Margen ständig. Nicht ausreichend definierte, eingeführte und gelebte Geschäftsprozesse führen zu Problemen, welche die Unternehmen vielfach in die Insolvenz treiben, da diese zum Beispiel nicht mal ihre Hauptkostentreiber kennen. Laut einer Studie der SAP Systems Integration AG messen 33% der befragten Unternehmen (im Rahmen der Befragung zum Thema "Total Cost of Ownership" im ERP-Umfeld) nicht mal ihre wichtigsten drei Hauptkostentreiber.

Das Geschäftsprozessmanagement hat genau das zum Ziel, nämlich durch eine Optimierung der Geschäftsprozesse eine Steigerung von Effizienz und Effektivität im Unternehmen hervorzurufen und gleichzeitig dessen Wert nachhaltig wachsen zu lassen.

Dass dies nicht nur eine in den Universitäten erfundene Theorie ist, sieht man an der im Juni 2006 von der IDS Scheer AG publizierten "Business Process Management Studie 2006". Dazu wurden ca. 150 IT-Entscheider deutscher Unternehmen und öffentlicher Verwaltungen über Qualität, Schwerpunkte und Ziele beim Geschäftsprozessmanagement befragt. Die Ergebnisse zeigen ein eindeutiges Bild:

- 80 Prozent der befragten Unternehmen beschäftigen sich stark bis sehr stark mit dem Thema Geschäftsprozessmanagement (2005: 67%).

- Knapp 70 Prozent der befragten Unternehmen bewerten die Leistungsfähigkeit der Geschäftsprozessorganisation nur mit befriedigend bis ausreichend.

- Bei nahezu 80 Prozent der befragten Unternehmen konnte die Marge durch eine Investition in Geschäftsprozessmanagement gesteigert werden.

Es gibt unterschiedliche Modelle zur Darstellung und Modellierung von Geschäftsprozessen. Je nach Anforderung eines einzelnen Unternehmens ist das eine oder andere Modell besser oder weniger gut dafür geeignet. Ziel dieser Diplomarbeit ist es nun, an Hand eines in der Arbeit entwickelten Kriterienkataloges die im deutschsprachigen Raum (Schweiz, Liechtenstein, Deutschland, Österreich) gebräuchlichen Modelle kritisch zu diskutieren.

Der Titel der vorliegenden Diplomarbeit lautet "Aktuelle Konzepte zur Modellierung von Geschäftsprozessen". Synonym wird zu "Konzepte zur Modellierung von Geschäftsprozessen" in dieser Arbeit das Wort "Model" verwendet.

Problemstellung:

Geschäftsprozesse sind in manchen Unternehmen, auch in jenen die sich laut der Studie der IDS Scheer AG [Idss06] damit auseinandersetzen, teilweise nur sehr rudimentär dokumentiert und zumeist noch weniger gelebt. Die Aufzeichnung, Analyse und Veränderung von ebendiesen bezeichnet man als Geschäftsprozessmodellierung oder "Business Process Modeling".

Es gibt verschiedene Modelle (Business Engineering, Architektur integrierter Informationssysteme, Knowledge Modeling Description Language etc.) für die Beschreibung von Geschäftsprozessen. Für unterschiedliche Einsatzzwecke in Organisationen sind die vorhandenen Modelle mehr oder weniger gut geeignet.

Die grundsätzliche Aufgabenstellung dieser Diplomarbeit lautet "Durchführung einer kritischen Analyse der aktuellen Konzepte zur Modellierung von Geschäftsprozessen im deutschsprachigen Raum mittels eines selbst entwickelten Kriterienkataloges.".

Die Forschungsfrage wird unterteilt in einzelne Arbeitsfragen, welche genau verifizierbar sind und im Laufe der Arbeit beantwortet werden. Die Forschungsfrage in dieser Arbeit lautet: "Welche Konzepte zur Modellierung von Geschäftsprozessen gibt es im deutschsprachigen Raum und wie können diese anhand eines selbst erstellten Kriterienkataloges bewertet werden?". Aus dieser Forschungsfrage lassen sich nun die Arbeitsfragen ableiten, welche den roten Faden durch die ganze Arbeit bilden werden.

Inhaltsverzeichnis:

	Inhaltsverzeichnis	II
	Abbildungsverzeichnis	VII
	Abkürzungsverzeichnis	VIII
	Literaturverzeichnis	IX
1.	EINLEITUNG	1
1.1	Problemstellung	2
1.2	Forschungsfrage	3
1.3	Arbeitsfragen	3
1.4	Wissenschaftliche/Praktische Relevanz	4
1.5	Persönliche Motivation	5
1.6	Forschungsstrategie	6
1.7	Theoretisches/Empirisches Vorgehen	7
1.8	Erwartetes Ergebnis	7
2.	THEORETISCHE GRUNDLAGEN	8
2.1	Begriffsbestimmungen	8
2.2	Grundlagen des Geschäftsprozessmanagements	10
2.2.1	Prozess	10
2.2.2	Geschäftsprozess	11
2.2.3	Geschäftsprozessmanagement	13
2.3	Auswahl der zu analysierenden Modelle	14
2.3.1	Business Engineering - Der St. Galler Ansatz	15
2.3.2	Architektur integrierter Informationssysteme - ARIS	15
2.3.3	Ganzheitliche Prozessmodellierung - GPM	16
2.3.4	Knowledge Modeling Description Language - KMDL	16
2.3.5	Unified Modeling Language - UML	17
2.3.6	Rational Unified Process - RUP	17
2.3.7	oose Engineering Process - OEP	18
2.3.8	Semantische Objektmodellierung - SOM	19
2.3.9	Performance Excellence	21
3.	DARSTELLUNG DER MODELLE	24
3.1	Business Engineering	24
3.1.1	Einführung	24
3.1.1.1	Ebenen des Business Engineerings	25
3.1.1.2	Dimensionen des Business Engineerings	26
3.1.2	Organisationsentwurf	27
3.1.2.1	Prozessmodell	27
3.1.2.2	Prozessvision	29
3.1.2.3	Leistungsanalyse	29
3.1.2.4	Ablauf-/Workflowplanung	30
3.1.2.5	Prozessführung	30
3.1.2.6	Architekturplanung	31
3.1.2.7	IT/Assessment, Kundenbeziehungsanalyse, aufgabenbezogene Analysen	31
3.1.2.8	Benchmarking, organisatorisches Monitoring	32
3.1.3	Datenentwurf	32
3.1.3.1	Datenmodell	34
3.1.3.2	Normalisierung	34
3.1.3.3	Semantische Datenmodellierung, objektorientierte Datenmodellierung	35
3.1.3.4	Schlüssel	35
3.1.3.5	Integritätsbedingungen	36
3.1.3.6	Codetabellen, Historisierung von Daten	37
3.1.3.7	Datenintegration	37
3.1.3.8	Implementierung des Datenmodells	38
3.1.4	Funktionsentwurf	40
3.1.4.1	Funktionsmodell	41
3.1.4.2	Ableitung von Transaktionen	42
3.1.4.3	Prüfung auf Vollständigkeit	42
3.1.4.4	Ableitung von Applikationen und Datenbanken	43
3.1.4.5	Transaktionsnetzwerk	43
3.1.4.6	Listen und Messages	44
3.1.4.7	Gestaltung der Benutzerschnittstelle	44
3.1.4.8	Kontrollstruktur	45
3.1.4.9	Autorisierung	45
3.1.4.10	Workflowkonstruktion	45
3.1.5	Referenzvorgehensmodell beim Business Engineering	46
3.1.6	Bewertung des Modells	46
3.2	Architektur integrierter Informationssysteme (ARIS)	48
3.2.1	Einführung	48
3.2.1.1	Beschreibungssichten	49
3.2.1.2	Beschreibungsebenen	50
3.2.2	Fachkonzept	51
3.2.2.1	Funktionssicht	52
3.2.2.2	Organisationssicht	52
3.2.2.3	Datensicht	53
3.2.2.4	Steuerungssicht	53
3.2.3	DV-Konzept	54
3.2.3.1	Funktionssicht	55
3.2.3.2	Organisationssicht	55
3.2.3.3	Datensicht	55
3.2.3.4	Steuerungssicht	55
3.2.4	Implementierung	56
3.2.4.1	Funktionssicht	56
3.2.4.2	Organisationssicht	56
3.2.4.3	Datensicht	56
3.2.4.4	Steuerungssicht	57
3.2.5	Bewertung des Modells	57
3.3	Ganzheitliche Prozessmodellierung (GPM)	58
3.3.1	Prozess-Sicht	60
3.3.2	Organisationsstruktursicht	60
3.3.3	Aktivitätsstruktursicht	61
3.3.4	Applikationsstruktursicht	61
3.3.5	Datenstruktursicht	61
3.3.6	Bewertung des Modells	62
3.4	Knowledge Modeling Description Language (KMDL)	63
3.4.1	Einführung	63
3.4.2	Ansatz der KMDL	64
3.4.3	Elemente der KMDL	65
3.4.3.1	Information	65
3.4.3.2	Aufgaben:	66
3.4.3.3	Stelle:	66
3.4.3.4	Person:	66
3.4.3.5	Wissensobjekt:	66
3.4.4	Wissenskonversion:	66
3.4.5	Klassifizierung von Wissensobjekten	67
3.4.6	Erzeugung von Informationen	67
3.4.7	Sichten der Knowledge Modeling Description Language	68
3.4.8	Referenzvorgehensmodell/Modellierungsschritte	69
3.4.9	Bewertung des Modells	70
3.5	Unified Modeling Language (UML)	71
3.5.1	Einführung	71
3.5.2	Bestandteile der UML	73
3.5.2.1	Dinge	73
3.5.2.2	Beziehungen	76
3.5.2.3	Diagramme der UML	77
3.5.3	Regeln der UML	77
3.5.4	Einheitliche Mechanismen in der UML	78
3.5.4.1	Spezifikationen	78
3.5.4.2	Details	79
3.5.4.3	Durchgängige Unterscheidungen	79
3.5.4.4	Erweiterungsmechanismen	79
3.5.5	Architektur	80
3.5.5.1	Anwendungsfallsicht	81
3.5.5.2	Entwurfssicht	81
3.5.5.3	Prozesssicht	81
3.5.5.4	Implementierungssicht	82
3.5.5.5	Einsatzsicht	82
3.5.6	Modellierungswerkzeuge	82
3.5.7	Bewertung des Modells	83
4.	KRITISCHE ANALYSE	84
4.1	Arbeitsfragen	84
4.2	Erstellung eines Kriterienkataloges zur Bewertung der Modelle	85
4.2.1	Einsatzbereich/Einsetzbarkeit	87
4.2.2	Das Modell/die Modellierungsarbeit	88
4.2.3	Verwaltung des Modells	90
4.2.4	IT-Systemvoraussetzungen	90
4.3	Bewertung der Modelle	91
4.3.1	Übersicht der Bewertung Plus/Minus-Schema	92
4.3.2	Übersicht der Bewertung/Punkteschema	93
4.4	Vergleich der Modelle	95
4.4.1	Einsatzbereich/Einsetzbarkeit	95
4.4.2	Das Modell/die Modellierungsarbeit	95
4.4.3	Verwaltung des Modells	96
4.4.4	IT-Systemvoraussetzungen	96
5.	ZUSAMMENFASSUNG	97
6.	AUSBLICK	101

Textprobe:

Kapitel 3.1.3, Datenentwurf:

"Der Datenentwurf bestimmt, welche Daten maschinell verarbeitet und gespeichert werden.".

Auf der strategischen Ebene des Datenentwurfes werden die prozessunabhängigen Datenbanken definiert und Standards für den Austausch von Daten zwischen unterschiedlichen inner - sowie zwischenbetrieblichen Applikationen festgelegt. Bei der Prozess- und Informationssystem-Ebene im Datenentwurf wird die Datenarchitektur als Rahmen verwendet. Für den einzelnen Prozess wird festgelegt, welche Daten dieser explizit benötigt.

Der Datenentwurf ist auf folgende Ziele auszurichten:

- Integration (alle Applikationen greifen auf eine gemeinsame Datenbank zu, Applikationen sollen sich gegenseitig verstehen).

- Korrektheit (keine Widersprüche, Regeln für die Korrektheit der Daten müssen formuliert sein).

- Generalisierung (Unabhängigkeit von einer konkreten Organisationsform).

- Abstimmung mit dem Organisationsentwurf (der Datenentwurf konkretisiert den Organisationsentwurf).

- Wirtschaftlichkeit (gemeinsames Oberziel; jedes Datenelement verursacht Kosten, denen der Nutzen gegenübergestellt werden muss).

Wie der Organisationsentwurf ist allerdings auch der Datenentwurf primär eine betriebswirtschaftliche und nur sekundär eine informationstechnische Aufgabe, welche allerdings einiges an Informatik-Grundverständnis voraussetzt.

Datenmodell:

Österle verwendet zur Veranschaulichung und zwecks der leichten Kommunizierbarkeit und Beschreibung der Datenwelt die vereinfachte Form des Entity-Relationship-Attribute-(ERA-) Modell, welches bereits in den 1970er Jahren von Prof. Peter Pin-Shan Chen entwickelt wurde.

Im Datenentwurf werden beispielsweise Kundendaten wie bei der Tabellenkalkulation als Tabelle behandelt, allerdings wird eine eigene Terminologie verwendet. Die gesamte Tabelle wird als Entitätsmenge bezeichnet, einzelne Zeilen heißen Entitäten. Die Spalten wiederum bezeichnet man als Attribute, diese stellen meist Eigenschaften wie beispielsweise die Postleitzahl oder den Ortsnamen dar. Eine einzelne Zelle enthält einen Attributwert. Ein Identifikationsschlüssel ist ein Attribut, welches jede Entität einer Entitätsmenge eindeutig definiert, er ist unveränderbar für die Dauer der Existenz der Entität. Ein Fremdschlüssel stellt eine Beziehung zu einem anderen Entitätstyp her (in dem dieser als Identifikationsschlüssel dient).

Die Beziehung zwischen unterschiedlichen Entitätstypen besteht aus deren Assoziation und Gegenassoziation. (Beispiel: Ein Kunde wohnt in einem Ort, in einem Ort gibt es n Kunden).

Normalisierung:

Das Entity-Relationship-Attribute-Modell stellt die Daten der betrieblichen Prozesse übersichtlich dar, es sagt allerdings nichts über die Qualität der Daten hinsichtlich Redundanzen und Einfachheit aus.

Semantische Datenmodellierung, objektorientierte Datenmodellierung:

Bei der semantischen Datenmodellierung wird das ERA-Modell, das nur einen Beziehungstypen kennt, um den klassenbildenden (fasst Gemeinsamkeiten von Entitätstypen zu einem neuen, umfassenden Entitätstypen zusammen) und den komplexbildenden Beziehungstyp (ordnet mehrere Entitäten eines Entitätstyps einem übergeordneten Entitätstyp zu, beispielsweise enthält ein Auftrag mehrere Auftragspositionen) erweitert. Die objektorientierte Datenmodellierung beschreibt nicht nur die Daten, sondern auch die Programmfunktionen, welche die Daten verwenden.

Schlüssel:

In den Ausführungen zum Datenmodell kamen bereits die Begriffe Identifikationsschlüssel und Fremdschlüssel vor. Im Datenentwurf zum Business Engineering gibt es allerdings noch mehrere Schlüssel für verschiedene Zwecke. Es werden sprechende Schlüssel, Primär- und Sekundärschlüssel, Sortierschlüssel und Matchcodes unterschieden.

Der Identifikationsschlüssel wird auch als künstlicher Schlüssel bezeichnet, er enthält keinerlei Informationen über Eigenschaften des (beispielsweise) Kunden, lediglich kennzeichnet er diesen eindeutig. Identifikationsschlüssel müssen die Eigenschaften Eindeutigkeit, laufende Zuteilbarkeit sowie kürze/leichte Schreibbarkeit aufweisen.

Sprechende Schlüssel hingegen bestehen selber aus einer oder mehreren Aussagen, die den Inhalt der Entität beschreiben, deshalb wird er auch als Klassenschlüssel bezeichnet. Einfache Auffindbarkeit von Artikeln im Lager sowie schnelles Zurechtfindung in Produktkatalogen beispielsweise sind Vorteile der sprechenden Schlüssel, das Platzen eines Schlüssels (wenn zum Beispiel ein Buchstabe als Kürzel dient ist man auf 26 Artikel/Gruppen beschränkt), die Reorganisation des Schlüssels bei Umgruppierungen in Produktgruppen, die Unmöglichkeit von netzartigen Gliederungen sowie oftmals schwierig zu definierende Eindeutigkeit sind die großen Probleme von sprechenden Schlüsseln. Im Informationszeitalter allerdings erübrigen sich diese Schlüssel, einen großen Anwendungsfall gibt es allerdings noch, die Europäische Artikelnummer (EAN) auf Artikel im Einzelhandel.

Nach dem Primärschlüssel organisiert und optimiert das Datenbankmanagementsystem die Speicherung der Daten, meist ist der Identifikationsschlüssel auch der Primärschlüssel. Für den Sekundärschlüssel wird zusätzlich zum Primärschlüssel ein Index zwecks schnellerer Auffindbarkeit und kürzerer Zugriffszeiten aufgebaut.

Der Sortierschlüssel ist ein Attribut und bestimmt die genaue Reihenfolge, in der die Entitäten in einer Liste oder Tabelle sortiert werden. Der Suchschlüssel ist ein sinnvollerweise meist indiziertes Attribut, über das eine Entität gesucht wird.

Ein Matchcode besteht aus mehreren abgekürzten oder mit Platzhaltern versehenen Suchbegriffen, welche in einer bestimmten Reihenfolge angeordnet sind.

Integritätsbedingungen:

"Integritätsbedingungen sind Regeln über die Zulässigkeit von Attributwerten. Sie dienen der Vermeidung von Widersprüchen in Datenbanken." .

Drei Integritätsbedingungen als Regeln für die Korrektheit der Datenbank werden unterschieden [Öste95, S.230ff]:

- Eindeutigkeitsbedingung (jeder Entitätstyp muss einen Identifikationsschlüssel besitzen).

- Referenzielle Integrität (jeder Attributwert in einem Fremdschlüssel muss gleichzeitig auch als Attributwert im Identifikationsschlüssel des dorthin referenzierten Entitätstyps zu finden sein).

- Wertebereichsbedingung (Jedem Attribut ist ein Wertebereich zugeordnet, in diesem sich der Wert bewegen kann).

Codetabellen, Historisierung von Daten:

Alle möglichen Entitäten eines Entitätstyps sind in einer Codetabelle zusammengefasst und dort auch aufgezählt. Werden Attributwerte an einem bestimmten Zeitpunkt geändert, so muss das Datenmodell diese zeitabhängig berücksichtigen (Historisierung von Daten).

Datenintegration:

Bei der Neugestaltung von Prozessen ist die Datenintegration eines der wichtigsten Merkmale. Sie verbindet die unterschiedlichen Applikationen über den Austausch von Daten. Firmenintern funktioniert die Integration der Daten meist schon recht gut, allerdings versagt der Datenaustausch von zwischenbetrieblichen Applikationen meist und die Daten müssen manuell ausgetauscht werden. Dies ist mit der Gefahr von Erfassungsfehlern, erhöhtem Zeitaufwand und höheren Kosten verbunden.

Unterschiedliche Formen der Datenintegration sind:

- Integration der Daten (verschiedene Applikationen, auch von unterschiedlichen Betrieben, benutzen die selben Daten und somit das selbe Datenmodell).

- Integration über Daten (verschiedene Applikationen verwenden eigene Datenbestände, welche manuell redundant aktuell gehalten werden, inkonsistente Datenhaltung zwischen der Synchronisation der Datenbestände).

Zwischen Applikationen können die Daten:

- synchron (Transaktion sendet Nachricht, unterbricht die Verarbeitung und wartet Antwort der korrespondierenden Transaktion ab) und; - asynchron (Transaktion sendet Nachricht und schließt damit Vorgang ab, eine Antwort wird nicht abgewartet) ausgetauscht werden.

Um den Austausch der Daten beziehungsweise die Integration der Daten zwischen Unternehmen zu erleichtern, wurde bereits in den 1980er Jahren Standards entwickelt, welche folgende Punkte regeln:

- welche Art von Dokumenten werden ausgetauscht (Auftrag, Rechnung).

- welche Attribute muss/kann/soll das Dokument enthalten (Kundenadresse).

- wie sollen die Daten im Dokument strukturiert sein.

Implementierung des Datenmodells:

In einem Informationssystem-Entwicklungsprojekt folgt auf den Datenentwurf die Konstruktion der Datenbank in einem konkreten Datenbanksystem. Das Datenmodell ist die Konstruktionszeichnung dafür.

"Ein Datenbanksystem besteht aus einem Datenbestand (Datenbasis) und Softwarekomponenten für die Datenverwaltung, dem sogenannten Datenbankmanagement-system.". Das relationale Datenbankmodell beschränkt sich auf die aus dem ERA-Modell bekannten Komponenten.

Zum Übertragen des konzeptionellen Datenmodells in ein Datenbankmanagementsystem benutzt man eine eigene Sprache, die Data Definition Language (DDL), sie spezifiziert die Entitätstypen, deren Attribute und Integritätsbedingungen.

Zum Erzeugen, Lesen, Modifizieren und Löschen von Entitäten und Entitätsmengen benutzen relationale Datenbankmanagementsysteme die Structured Query Language (SQL), und zwar die Sprachschicht Data Manipulation Language (DML). Die DDL ist eine weitere Sprachschicht der SQL.

Unterschiedliche Zugriffe:

- lesender Zugriff: unterschiedliche Operationen werden zur Definition von Teilmengen eines Datenbestandes verwendet (Projektion - Auswahl bestimmter Attribute aus Entitätsmengen durch "SELECT * FROM"; Selektion - Auswahl bestimmter Entitäten aus Entitätsmengen, welche bestimmte Bedingungen erfüllen durch "WHERE

- schreibender Zugriff: um Daten einer Datenbank zu ändern (Erzeugen einer Entität – durch "INSERT INTO * VALUES"; Modifizieren einer Entität – durch "UPDATE * SET * WHERE *"; Löschen einer Entität - durch "DELETE FROM * WHERE *").

Zwecks kürzerer Zugriffs- Antwortzeiten und um Computerressourcen zu sparen werden die Daten normalisiert. Die Normalisierung führt zu einfachen und redundanzarmen Datenmodellen. Man unterscheidet die Zusammenfassung von Entitätstypen (Verbesserung der Laufzeiteffizienz durch Vermeidung von Verbund-Operationen), die Aufteilung eines Entitätstyps (Aufteilung der Attribute eines Entitätstyps auf mehrere Entitätstypen zur Verbesserung der Laufzeiteffizienz durch Vermeidung von Projektions-Operationen oder Vorwegnahme der Selektions-Operationen) und die Aufnahme abgeleiteter Attribute (Speicherung von Berechnungsergebnissen).

Objektorientierte Datenbankmanagementsysteme verbinden die Programmfunktionen mit den Daten und werden hauptsächlich im technischen Bereich Anwendung (beispielsweise im Computer Aided Design (CAD).