Inhaltsverzeichnis

Inhaltsverzeichnis   II

1  Einleitung  1

2  Das Semantische Objektmodell  3

2.1  Die Architektur des SO-MAnsatzes  3

2.1.1  Der Unternehmensplan  3

2.1.2  Die Geschäftsprozessebene  4

2.1.3  Die Anwendungssystemebene  6

2.2  Das Vorgehensmodell des SO-MAnsatzes  6

2.3  Das Aufgabenkonzept im SO-MAnsatz  7

2.3.1  Die Innen- und Außensicht einer Aufgabe  7

2.3.2  Abgrenzungskriterien für Aufgaben  8

2.3.2.1  Abgrenzung hinsichtlich ihres Lösungsverfahrens  8

2.3.2.2  Abgrenzung hinsichtlich ihres Automatisierungsgrades  9

2.4  Erfordernisse zur Modellierung der SO-MGeschäftsprozessmodellebene  9

2.4.1  Anforderungen aus den Sichten des Metamodells  9

2.4.1.1  Metamodell Geschäftsprozessebene: Interaktionssicht  10

2.4.1.2  Metamodell Geschäftsprozessebene: Ablaufsicht  11

2.4.2  Anforderungen aus den Produktionsregeln  12

2.4.3  Die Ableitung der Ablauf- aus der Interaktionssicht  13

2.4.4  Erweiterte semantische Anforderungen  14

2.4.5  Die Definition von IAS-Zerlegungsstufen  14

2.5  Bewertung des SO-MAnsatzes  15

3  Microsoft Visio  16

3.1  Gründe für den Einsatz von Microsoft Visio  16

3.2  Die wichtigsten Elemente von Microsoft Visio  17

3.2.1  Visio Shapes  17

3.2.1.1  Techniken zur Erstellung komplexer Shapes  17

3.2.1.2  1-D und 2-D Shapes  17

3.2.2  Das Visio ShapeSheet und seine Struktur  18

3.2.2.1  Wichtige Abschnitte im ShapeSheet  19

3.2.2.2  Wichtige Funktionen innerhalb des ShapeSheets  20

3.2.4  Beispiel eines „SmartShapes“  21

3.2.5  Bewertung des ShapeSheets  22

3.3  Der Aufbau einer Visio-Lösung  22

3.4  Programmierung in Visio  23

3.4.1  Das Visio-Objektmodell  23

3.4.2  Die integrierte Entwicklungsumgebung VBA  23

3.4.2.1  Visual Basic for Applications  23

3.4.2.2  Zugriff auf Zellen des ShapeSheet mit VBA  25

3.4.2.3  Performanceorientierte VBA-Programmierung  25

3.4.3  Visio-Ereignisprogrammierung  27

3.4.4  Die Darstellung der Visio-Modelle im Web  27

3.4.5  Visio und Microsoft Net  28

II

3.4.6  Visio Add-ons und Add-ins  29

4  Realisierung der SO-MGeschäftsprozessmodellebene mit Visio  29

4.1  Die Vorgehensweise beim Entwurf der Visio-Lösung  29

4.2  Auswahl und Gestaltung geeigneter Shapes  30

4.2.1  Stencils zur Bereitstellung der Elemente  30

4.2.2  Shapes zur Repräsentation der Elemente  31

4.2.2.1  Diskurswelt- und Umweltobjektshape  31

4.2.2.2  Leistungstransaktions- und Transaktionsshape  31

4.2.2.3  Optimierung des Verbindungsverhaltens zwischen Objekten und  

Transaktionen   31

4.2.2.4  Aufgabenshapes  32

4.2.2.5  Shapes zur Darstellung der Ereignisse  32

4.2.3  Die Typisierung der Metaobjekte  33

4.2.4  Das Anlegen von Notizen an Modellelemente  33

4.3  Die Umsetzung der Produktionsregeln  34

4.3.1  Die Funktionsweise der entworfenen Masken  34

4.3.2  Transaktionszerlegung  35

4.3.3  Objektzerlegung  35

4.3.4  Spezialisierung von Diskurswelt-, Umweltobjekten und Transaktionen  35

4.3.5  Sequentielle und parallele Zerlegung von Transaktionen  36

4.3.6  Realisierung der Mehrstufigkeit  36

4.4  Die Definition und Behandlung von IAS-Zerlegungsstufen  36

4.4.1  Bewertung der Darstellung von Beziehungen durch Hyperlinks  37

4.4.2  Herstellung einer Beziehung zwischen IAS-Zerlegungsstufen  38

4.4.3  Diskussion der Konsistenz einer IAS-Zerlegungsstufe  39

4.5  Der Einsatz von Ereignissen  40

4.5.1  Ereignisorientierte Konsistenzprüfung beim Löschen von Transaktionen  40

4.5.2  Ereignisorientierte Konsistenzsicherung zwischen IAS-Zerlegungsstufen  

beim  Löschen eines Modellelements  40

4.5.3  Ereignisorientierung beim Hinzufügen von Modellelementen  41

4.5.4  Konsistenzverletzung zwischen IAS-Zerlegungsstufen durch Anwendung  

von  Produktionsregeln  41

4.5.5  Ereignisorientierte Prüfung von Verbindungsereignissen  42

4.5.6  Ereignisorientierte Prüfung auf eindeutige Namen  42

4.6  Das Vorgangsereignisschema  43

4.6.1  Der Aufbau des VES  43

4.6.2  Automatisches Hinzufügen und Benennen von Transaktionsereignissen  44

4.6.3  Diskussion der Automatisierbarkeit der Ablaufsicht  44

4.6.4  Die Behandlung von Aufgaben und Zielen  46

4.6.5  Beschreibung der Automatisierung von Transaktionsereignissen  47

4.7  Programmierung eines Visio Add-ons in C  47

4.8  Überlegungen zu den einzelnen Seiten der Visio-Lösung  48

4.9  Bewertung der Visio-Lösung hinsichtlich der erzielten Ergebnisse  49

4.9.1  Schwachstellen in der Visio-Lösung  50

4.9.2  Möglichkeiten zur Weiterentwicklung der Visio-Lösung  50

5  Ziele einer mikropolitischen Analyse des Qualitätsmanagements  52

5.1  Erreichung einer realistischeren Betrachtungsweise  52

III

5.2  Darstellung des Einsatzes von Macht als natürliches Mittel zur Durchsetzung von  

Interessen   55

5.3  Ziele bezüglich des Qualitätsmanagements  56

5.3.1  Die Analyse der Formalisierungsprozesse in einer Organisation durch das  

Qualit  ätsmanagement  56

5.3.2  Analyse der Beziehungen funktionaler Gruppen einer Organisation  56

5.3.3  Analyse der Kommunikation des Unternehmens mit seiner Umwelt beim  

Prozess  der Zertifizierung  56

5.3.4  Analyse der Ziele des Managements bezüglich TQM  57

6  Kennzeichen von Total Quality Management  57

6.1  Die ISO 9000 Norm  59

6.2  Das Qualitätshandbuch zur Darlegung der ISO 9000 Norm  59

6.3  Die Qualitätstechnik FMEA  60

6.4  Die Zertifizierung  61

6.4.1  Ziele einer Zertifizierung  61

6.4.2  Der Ablauf einer Zertifizierung  61

7  Mikropolitik  62

7.1  Crozier/Friedberg als Auslöser einer mikropolitischen Wende  62

7.2  Die politische Perspektive  62

7.3  Macht in der mikropolitischen Perspektive  63

7.3.1  Die Beherrschung der Unsicherheitsquelle  64

7.3.2  Typen von Macht in Organisationen  66

7.4  Mikropolitik als Spiel  67

7.4.1  Die Spielmetapher  67

7.4.2  Routine- und Innovationsspiele  68

7.5  Strategien und Taktiken in Organisationen  71

7.5.1  Die strategische Orientierung des Akteurs  71

7.5.2  Offensive und defensive Strategie  72

7.5.3  Mikropolitische Taktiken  72

7.6  Die Beziehungen zur Umwelt  73

8  Mikropolitische Analyse des Total Quality Managements  74

8.1  Die Spielarena des TQM  75

8.1.1  Spiel-Kontext  75

8.1.2  Spieler  75

8.1.3  Spiel-Ziele  76

8.1.4  Spiel-Einsatz und Spiel-Gewinne  77

8.1.5  Spiel-Material und Spiel-Regeln  78

8.2  Strategien, Taktiken in der Arena des TQM  78

8.2.1  Spiel-Strategien  78

8.2.1.1  Formalisierungsprozesse durch die ISO 9000 Norm  79

8.2.1.2  Job-Enrichment und Job-Enlargement: High-Trust Strategien  80

8.2.2  Spiel-Taktiken  81

8.2.2.1  Das kontinuierliche Verbesserungsmanagement  81

8.2.2.2  Kommunikationstaktiken  82

8.2.2.2.1  Das Erlernen von Techniken des Qualitätsmanagements  82

8.2.2.2.2  Der Einsatz von Plänen durch TQ-MPromotoren  82

8.2.2.2.3  Die Kommunikation der Qualitätsstrategie  83

IV

8.3 Aspekte einer empirischen Überprüfung 9 Zusammenführung und Anwendung der Ergebnisse hinsichtlich des Qualitätsmanagements 93 Abkürzungsverzeichnis 96 Abbildungsverzeichnis 97 Literaturverzeichnis 98 Verzeichnis der URL 102 URL von Microsoft 102 Sonstige URL 103

1 Einleitung

Betrachtet man Veröffentlichungen in der Produktionstechnik und im Qualitätsmanagement, so kann festgestellt werden, dass Begriffe wie „Prozess“, „Geschäftsprozess“ oder „Prozessorientierung“ eine immer größere Beachtung finden. Die Qualität der Prozesse eines Unternehmens wird dabei als ein zentraler Wettbewerbsfaktor angesehen. „Durch das Prozessdenken soll gerade das Bewusstsein dafür geschärft werden, dass die in Unternehmen etablierte Arbeitsteilung mit den fixierten Schnittstellen (auch zur Umwelt) keinen Sachzwang darstellt, sondern geändert werden kann“ [Göb01, 228]. Damit verbundene Strategien und Maßnahmen sind aber nur so gut wie die Mitarbeiter, welche diese umsetzen. Veränderungen, die die Interessen der beteiligten Personen übersehen oder übergehen, werden in vielen Fällen deren Ignoranz und Widerstand hervorrufen. Es ist zunächst Intention dieser Diplomarbeit, einen Ansatz vorzustellen und zu implementieren, mit dem Geschäftsprozesse methodisch dargestellt werden und damit zur Qualitätsverbesserung in einem Unternehmen beitragen können. Qualitätsmanagement wird im Rahmen dieser Arbeit unter der ganzheitlicheren Perspektive des Total Quality Management (TQM)-Ansatzes betrachtet, der den Mitarbeiter eines Unternehmens in den Mittelpunkt stellt und eine einseitige Fixierung auf prozessorientiertes Denken als unzureichend erachtet. Daraus ergibt sich einerseits die Frage, wodurch eine derartige Akteursperspektive eingenommen werden kann und andererseits, welche zusätzlichen Erkenntnisse daraus gewonnen werden können. Die Unterschiedlichkeit der beiden daraus resultierenden Aufgabenstellungen erfordert es zunächst, diese unabhängig voneinander zu bearbeiten und erst am Ende über das Thema Qualitätsmanagement zielführend miteinander zu verbinden. In den Kapiteln 2.1-2.4 werden zunächst die Grundlagen des Semantischen Objektmodells (SOM) beschrieben. Durch diesen Ansatz werden methodische Grundlagen zur Darstellung und Implementierung von Geschäftsprozessen erläutert. Aufbauend darauf werden in Kapitel 2.5 die Anforderungen, welche sich aus den Sichten des SOM-Geschäftsprozessmetamodells ergeben, abgeleitet. Danach wird in Kapitel 3 das Programm Microsoft Visio vorgestellt, mit Hilfe dessen das Werkzeug zur Modellierung der Geschäftsprozessebene des SOM-Ansatzes und damit zur Realisierung der definierten Anforderungen entwickelt werden soll. Nach Vorstellung und Bewertung der Ergebnisse dieser ersten Themenstellung in Kapitel 4 erfolgt ein Übergang zum

soziologischen Teil dieser Diplomarbeit. In ihm wird der aus der Organisationssoziologie stammende mikropolitische Ansatz verwendet, um Prozesse und Probleme des Qualitätsmanagements zu analysieren. Die damit verbundenen Ziele werden in Kapitel 5 vorgestellt. Wurden bereits im ersten Teil dieser Arbeit mehrere Beispiele aus dem Bereich des Qualitätsmanagements angeführt, so werden dessen zentrale Konzepte in Kapitel 6 erläutert. Ebenso ist es notwendig, dem Leser die begrifflichen und konzeptuellen Grundlagen des mikropolitischen Ansatzes zu vermitteln, was in Kapitel 7 erfolgen soll. Daran anschließend wird in Kapitel 8 die bereits angesprochene, mikropolitische Analyse des Qualitätsmanagements durchgeführt. Am Ende dieser Arbeit wird in Kapitel 9 gezeigt, wie die Ergebnisse beider Themenstellungen zusammengeführt werden können.

Abbildung 1: Vorgehensweise der Diplomarbeit

2 Das Semantische Objektmodell

Das Semantische Objektmodell (SOM) ist ein von Ferstl und Sinz entwickelter Ansatz zur Modellierung betrieblicher Systeme und zur Spezifikation von Anwendungssystemen (vgl.[FeSi95,1]). Ziel des SOM ist die Schaffung eines umfassenden, integrierten und durchgängigen Modellierungsansatzes zur strategischen Gesamtplanung eines betrieblichen Informationssystems und zur Entwicklung betrieblicher Anwendungssysteme.

In ihm wird „eine durchgängige Kopplung zwischen betrieblichen Prozessen und DVtechnischen Prozessen unterstützt“ [FeSi94a,1].

2.1 Die Architektur des SOM-Ansatzes

Das Objektsystem der Unternehmung wird im SOM-Ansatz durch ein umfassendes Modellsystem beschrieben. Zur Komplexitätsreduzierung „wird das Modellsystem in Teilmodellsysteme unterteilt, die jeweils einer Modellebene zugeordnet werden“ FeSi98,177]. Jedes Teilmodell beschreibt das Objektsystem vollständig aus einer gewissen Sichtweise. Die Menge der Teilsysteme sowie ihre Beziehungen beschreiben zusammen die Unternehmensarchitektur (vgl.[FeSi98,177]). Der SOM-Ansatz unterscheidet in der Unternehmensarchitektur die drei Modellebenen Unternehmensplan, Geschäftsprozessmodellebene und Anwendungssystemspezifikation. „Ein derartiges Gesamtmodell ist ein zentrales Hilfsmittel für eine permanente, evolutionäre Anpassung und damit für den Erhalt der Lebensfähigkeit der Unternehmung“ [FeSi94,9]. Im Folgenden sollen die einzelnen Modellebenen vorgestellt werden.

2.1.1 Der Unternehmensplan

Der Unternehmensplan bildet ein Modell der Außensicht des betrieblichen Systems (vgl.[FeSi98,177]). Dessen Beschreibung erfolgt informal in den Sichten Objektsystem und Zielsystem. Die strukturorientierte Sicht auf den Unternehmensplan wird als Objektsystem, die verhaltensorientierte Sicht als Zielsystem bezeichnet. Diese Sichten „beschreiben den Unternehmensplan in Form einer Spezifikation der Unternehmensaufgabe“ [Sinz97,11].

Die strukturorientierte Sicht enthält die Abgrenzung der Diskurswelt von seiner Umwelt, mit der sie in Form von Leistungsbeziehungen in Kontakt steht (vgl.[FeSi98,180]). Die Diskurswelt ist deshalb als offenes System und zielgerichtetes System zu verstehen (vgl.[FeSi94,6]). Im Zielsystem werden die Sach- und Formalziele sowie Erfolgsfaktoren, Strategien und Rahmenbedingungen des betrieblichen Systems definiert.

2.1.2 Die Geschäftsprozessebene

„Das Geschäftsprozessmodell ist das Teilmodellsystem der Innensicht des betrieblichen Systems. Es spezifiziert die Lösungsverfahren für die Realisierung des Unternehmensplans“ [FeSi98,178]. Dieses Modell erläutert „ein System von Haupt- und Serviceprozessen, die durch Leistungsbeziehungen miteinander verbunden sind. Hauptprozesse geben ihre Leistung an die Umwelt ab und tragen unmittelbar zur Sachzielerfüllung des betrieblichen Systems bei. Serviceprozesse stellen Leistungen für Hauptprozesse oder andere Serviceprozesse zur Verfügung“ [FeSi98,178]. Die SOM-Methodik sieht eine mehrstufige Verfeinerung von Geschäftsprozessmodellen vor. „Dabei werden die Leistungsbeziehungen sukzessive verfeinert und gleichzeitig die Lenkung der Geschäftsprozesse festgelegt“ [FeSi98,178]. Ein Geschäftsprozess kann aus drei Sichten betrachtet werden (vgl.[FeSi98,182]): In der Leistungssicht wird gezeigt, welche betrieblichen Leistungen von Geschäftsprozessen erstellt oder untereinander beauftragt werden. Unter Leistungen werden dabei Güter, Zahlungen oder Dienstleistungen verstanden. Eine Lenkungssicht gibt an, wie die an der Leistungserstellung beteiligten betrieblichen Objekte koordiniert werden. Betriebliche Objekte fassen eine Menge von Aufgaben zusammen. „Dabei wird das allgemeine Konzept der Objektorientierung auf die Bildung betrieblicher Aufgabenstrukturen angewandt“ [FeSi98,184]. Objekte verarbeiten Leistungs- und Lenkungspakete, die über Kommunikationskanäle als betriebliche Transaktionen ausgetauscht werden. Transaktionen sind als die verbindenden Elemente in einem System zusammenhängender Geschäftsprozesse anzusehen. In der strukturorientierten Sicht in Form des Interaktionsschemas (IAS) werden Objekte und Transaktionen stufenweise zerlegt. Ein Objekt kann nach dem hierarchischen Regelungsprinzip in ein Regler- und ein Regelstreckenobjekt zerlegt werden, die über Steuerungs (S)- und Kontrolltransaktionen (K) miteinander verbunden werden (vgl.[FeSi98,186]). Die Orientierung am Regelkreisprinzip wird in Abbildung 2 am Beispiel des Qualitätsmanagements verdeutlicht:

Abbildung 2: Gegenüberstellung Regelkreis in Anlehnung an [Pfei01,146] und Regelungsprinzip im SOM

In der Ablaufsicht der Geschäftsprozessebene des SOM-Ansatz wird ein Modellelement vorgestellt werden, mit dem die Störgrößen eines Regelkreises modelliert werden können. Zur Koordination zweier gleichrangiger betrieblicher Objekte wird im SOM-Ansatz die sogenannte „flache Koordination“ verwendet. Diese Koordination erfolgt nach dem Verhandlungsprinzip und wird durch die Transaktionsphasen Anbahnung (A), Vereinbarung (V) und Durchführung (D) beschrieben. Die Ablaufsicht zeigt die ereignisgesteuerte Aufgabendurchführung innerhalb der Objekte und wird als Vorgangs-Ereignis-Schema (VES) bezeichnet. Die Durchführung der Lösungsverfahren einer Aufgabe findet in Form von Vorgängen statt. „Entsprechend der gebildeten Detaillierungsschritte im Interaktionsmodell werden die Vorgänge der Aufgabendurchführung in Vorgangs-Ereignis-Schemata im Aufgabensystem zusammengefasst“ [KeTe97,130]. Unter „Verwendung eines Petri-Netz-Formalismus“ [FeHa95,4] wird ein Vorgang in einem Diskursweltobjekt durch ein Vorereignis angestoßen, gegebenenfalls über mehrere objektinterne Ereignisse abgebildet und ein Nachzustand erzeugt, der wiederum der Input eines nachfolgenden Vorgangs sein kann.

2.1.3 Die Anwendungssystemebene

Auf der dritten Modellebene wird die fachliche Spezifikation von Anwendungssystemen entwickelt. Diese sind „maschinelle Aufgabenträger, die Lösungsverfahren für automatisierte (Teil-)Aufgaben von Geschäftsprozessen bereitstellen“ [FeSi98,180]. Eine Anwendungssystemspezifikation besteht aus einem konzeptionellem Objektschema (KOS) und dem darauf aufbauenden Vorgangsobjektschema (VOS). Die Darstellung der konzeptuellen Objekte beruht auf einer objektorientierten Erweiterung des Strukturierten Entity-Relationship-Modells (SERM) (vgl.[FeSi91,20]) und umfasst konzeptuelle Objekttypen des Anwendungssystems und ihre Informationsbeziehungen. In der verhaltensorientierten Sicht legen Vorgangsobjekttypen das Zusammenwirken konzeptueller Objekttypen bei der Aufgabendurchführung fest (vgl.[FeSi98,180]). Die nichtautomatisierten Teile von Geschäftsprozessen und dazugehörige personelle Aufgabenträger gehören zur betrieblichen Organisation und werden im SOM-Ansatz nicht weiter berücksichtigt (vgl.[FeSi94a,2]).

2.2 Das Vorgehensmodell des SOM-Ansatzes

Die Vorgehensweise erfolgt im SOM-Ansatz unter dem Namen V-Modell (vgl.[FeSi98,179]). Dieses Methodik stellt die verschiedenen Modellebenen in einem linken und einem rechten Schenkel dar, welche die struktur- bzw. verhaltensorientierten Sichten repräsentieren.

1. Ebene

2. Ebene

Abbildung 3: Das Vorgehensmodell des SOM in Anlehnung an [FeSi92,2]

Die drei in Abbildung 3 dargestellten Ebenen korrespondieren dabei mit den Modellebenen der Unternehmensarchitektur. Der Abstand zwischen den beiden Schenkeln bedeutet, dass die Freiheitsgrade in der Modellierung beider Sichtweisen mit zunehmender Konkretisierung des Anwendungssystems von oben nach unten abnehmen. Die drei Ebenen werden idealtypisch von oben nach unten durchlaufen, wobei jeweils mit der strukturorientierten Sicht begonnen wird. „Die Modellierungsergebnisse sind innerhalb der korrespondierenden Sichten einer Ebene sowie zwischen den Sichten benachbarter Ebenen abzustimmen“ [FeSi98,179]. Abhängig von der Zielsetzung des Modellierers kann jedoch vom dargestellten Vorgehensmodell in der Praxis auch abgewichen werden (vgl.[FeSi98,180]).

2.3 Das Aufgabenkonzept im SOM-Ansatz

Die für die Organisationsgestaltung lange Zeit prägende Aufgabenanalyse (vgl.[Kah01,31]) steht beim SOM-Ansatz nicht im Vordergrund. Die Vorgehensweise mit einer Betonung der Prozessanalyse vor der Aufgabenanalyse gibt der Gestaltung der Ablauforganisation Vorrang gegenüber der Aufbauorganisation. Stellen, Abteilungen und Bereiche eines Unternehmens werden „bottom-up“ auf der Grundlage der prozessualen Anforderungen gebildet (vgl.[Kah01,32]). Die Detaillierung der Geschäftprozesse führt dabei stets auch zu einer Aufgabenzerlegung.

2.3.1 Die Innen- und Außensicht einer Aufgabe

Um mögliche Freiheitsgrade in den Phasen Spezifikation und Durchführung einer Aufgabe zu erhalten, differenzieren [FeSi98,87] zwischen der Innen- und Außensicht einer Aufgabe. Die Innensicht enthält Informationen über das Lösungsverfahren für die Aufgabendurch-führung und nimmt Bezug auf einen Aufgabenträgertyp. Deren Betrachtung ist nicht Teil der Geschäftsprozessmodellierung, welche

aufgabenträgerunabhängig zu gestalten ist. Die Außensicht definiert das Aufgabenobjekt, die Ziele der Aufgabe sowie die auslösenden Vorereignisse und die resultierenden Nachereignisse. Hierbei werden keine Aussagen über den Aufgabenträger und das Lösungsverfahren getroffen (vgl.[FeSi98,88]).

Abbildung 4: Die Struktur einer Aufgabe in Anlehnung an [FeSi93,13]

2.3.2 Abgrenzungskriterien für Aufgaben

2.3.2.1 Abgrenzung hinsichtlich ihres Lösungsverfahrens

Hierbei kann eine Aufgabe in drei Arten unterschieden werden (vgl.[FeSi98,31f]):

1. Transformationsaufgaben ohne Speicher

Dabei hängt der Output der Aufgabe ausschließlich von dessen Input ab. Im Bereich der Qualitätssicherung wären statistische Berechnungen von Stichproben oder die Aufzeichnung von Messergebnissen zu nennen.

2. Transformationsaufgaben mit Speicher

Der Output hängt nun vom Input und darüber hinaus von Informationen ab, die im Rahmen früherer Aufgabendurchführungen gesammelt wurden. Diese gespeicherten Informationen können im Rahmen der Aufgabendurchführung verändert werden. Ein Beispiel wäre die langjährige Bewertung eines Lieferanten, bei der sich die Liefererantenkennzahl aus dem Ergebnis einer aktuellen und dem Wert vorheriger Prüfungen zusammensetzt.

3. Entscheidungsaufgaben

Diese besitzen die selbe Struktur wie die genannten Aufgabentypen. Zusätzlich bekommt sie als Input Führungs- und Zielwerte. Eine Qualitätsprüfung wird dann zu einer Entscheidungsaufgabe, wenn der Aufgabenträger neben formalen Regeln einen Ermessensspielraum, zum Beispiel bei der Gewichtung der Prüfkriterien, besitzt.

2.3.2.2 Abgrenzung hinsichtlich ihres Automatisierungsgrades

Nach [FeSi98,S.47f] kann der Automatisierungsgrad einer Aufgabe drei mögliche Ausprägungen haben:

- Eine Aufgabe ist vollautomatisiert, wenn sie vollständig von maschinellen Aufgabenträgern durchgeführt wird.

- -Sie ist teilautomatisiert, wenn sie gemeinsam von personellen und maschinellen Aufgabenträgern durchgeführt wird und sie gilt als -

- nicht automatisiert, wenn sie ausschließlich von personellen Aufgabenträgern durchgeführt werden kann.

Der Automatisierungsgrad einer Aufgabe hängt von ihrem Zerlegungsgrad ab. So kann eine teilautomatisierte Aufgabe in mindestens eine vollautomatisierte und mindestens eine nichtautomatisierte Aufgabe zerlegt werden. Weiterhin kann der Blickwinkel vom Ist- auf den Sollzustand einer Aufgabe gelenkt werden. In diesem Fall wird deren Automatisierbarkeit bezüglich der genannten Kriterien untersucht. Die Analyse des Automatisierungsgrades bei Aufgaben und Transaktionen stellt einen wichtigen Übergang von der Geschäftsprozessmodellierung zur Anwendungssystemspezifikation dar.

2.4 Erfordernisse zur Modellierung der SOM-Geschäftsprozessmodellebene

Nach einer theoretischen Einführung in den SOM-Ansatz, sollen nun im Folgenden die Anforderungen definiert werden, welche bei einer Umsetzung der Geschäftsprozessmodellebene des SOM-Ansatzes in eine Visio-Lösung notwendig sind.

2.4.1 Anforderungen aus den Sichten des Metamodells

Zunächst werden die Anforderungen analysiert, welche sich direkt aus den Sichten des Metamodells der Geschäftsprozessebene ableiten lassen. Aus der Sicht des Modellierers gibt ein Metamodell einen Beschreibungsrahmen für das Modellsystem. Zusammen mit den Produktionsregeln, die in Kapitel 2.5.2 vorgestellt werden, spezifizieren sie „die Syntax und die formale Semantik von Geschäftsprozessmodellen“ [FeSi94,17]. Die Spezifikation umfasst also die Arten und Bedeutungen von Modellbausteinen sowie Beziehungen zwischen diesen und die Regeln für deren Verwendung. Anhand des

Metamodells können zentrale Anforderungen an Modelle wie Konsistenz und Vollständigkeit sowie Struktur- und Verhaltenstreue überprüft werden (vgl.[FeSi98,120f]). Ein Metamodell muss die Bewältigung der Komplexität des Modellierers unterstützen. „Aufgrund ihrer typmäßigen Komplexität ist es im allgemeinen jedoch nicht möglich, Modellsysteme in einer einzigen, geschlossenen Darstellung gegenüber dem Betrachter zu präsentieren“ [Sinz95,5]. Daher wird das Metamodell der Geschäftsprozessmodellebene des SOM in zwei Sichten dargestellt. Eine Sicht umfasst eine Teilmenge der Metaobjekte des Metamodells (vgl.[Sinz95,5f]). Im Folgenden sollen die einzelnen Sichten vorgestellt und Anforderungen daraus abgeleitet werden:

2.4.1.1 Metamodell Geschäftsprozessebene: Interaktionssicht

Dieses Teilmetamodell stellt die strukturorientierte Sicht auf das Metamodell dar und umfasst die Leistungs- und Lenkungssicht der Geschäftsprozessebene.

Abbildung 5: Teilmetamodell Interaktionssicht in Anlehnung an ([Schm99,20] und [Krbi97,102])

Es werden folgende Modellelemente benötigt:

Objekte: Diese treten in Form von Diskurs- und Umweltobjekten auf und können wiederum Diskurs- und Umweltobjekte enthalten. Die beiden Objektarten verhalten sich zueinander disjunkt.

Transaktionen: Eine Transaktion muss dabei genau zwei Objekte verbinden. Diese können in A-V-D- sowie in S- und K-Transaktionen unterschieden werden. Weiterhin dürfen nicht hierarchische Zerlegungen (Verhandlungsprinzip) keine S-K-Transaktionen

enthalten, in Zerlegungen von S-K-Transaktionen (Regelungsprinzip) dürfen keine A-V-oder D-Transaktionen vorkommen.

Leistungstransaktionen: Leistungen bilden Sachgüter oder Dienstleistungen ab, die Ergebnis der Leistungserstellung durch ein betriebliches (Teil-) Leistungssystem sind und einen Wert für einen Kunden haben. „Der Leistungsbegriff wird ergebnisbezogen verstanden, d.h. mit Leistung wird nicht die Durchführung von betrieblichen Aufgaben, sondern das Ergebnis der Leistungserstellung bezeichnet“ [Krbi97,104]. Zur Übergabe einer Leistung wird eine spezielle Art von D-Transaktion verwendet, die sogenannte Leistungstransaktion. „Da jedoch eine Leistungstransaktion in vielen Fällen genau eine Leistung transportiert, geht in diesen Fällen die Bezeichnung der Leistung aus der Bezeichnung der Leistungstransaktion hervor“ [Krbi97,101f]. Es wird daraus die Anforderung abgeleitet, dass eine Leistung mit einer Leistungstransaktion korrespondieren soll, allerdings eine Möglichkeit bestehen sollte, Ausnahmefälle zu kennzeichnen.

2.4.1.2 Metamodell Geschäftsprozessebene: Ablaufsicht

Abbildung 6: Teilmetamodell Ablaufsicht in Anlehnung an [Schm99,21]

Es werden folgende Modellelemente benötigt:

Aufgaben: Diese werden in Form von Vorgängen durchgeführt. Die theoretischen Grundlagen zum Beschreiben dieses Metaobjektes wurden in Kapitel 2.3.3 behandelt. Transaktionsereignisse: Während Transaktionen in der Struktursicht genau zwei Objekte verbinden, stellen diese in der Ablaufsicht Ereignisse dar, welche genau zwei Aufgaben verbinden.

Objektinterne Ereignisse: Diese verbinden genau zwei Aufgaben und verdeutlichen deren Reihenfolgebeziehung.

Umweltereignisse: Diese stellen Ereignisse dar, welche nicht durch Transaktions- oder objektinterne Ereignisse modelliert werden können. Nach [FeSi94,21] stellen Umweltereignisse z.B. das Eintreffen von Zeitpunkten oder den Ablauf von Zeitintervallen dar.

2.4.2 Anforderungen aus den Produktionsregeln

Die Differenzierung der Modellelemente des IAS erfolgt ausschließlich durch die Anwendung der Produktionsregeln (Abbildung 7).

Es kann als zentrale Anforderung bezeichnet werden, die dargestellten Regeln in der später beschriebenen Visio-Lösung umzusetzen. Sie können als Menge von gültigen Modellierungsschritten gekennzeichnet werden. Regel 1 erläutert die Zerlegung nach dem Regelungsprinzip: Es muss demnach die Möglichkeit vorliegen, ein Diskursweltobjekt in zwei Diskursweltobjekte zu zerlegen, welche durch eine S- und optional durch eine K-Transaktion miteinander verbunden sind. „Liegen beide dieser Transaktionsarten vor, handelt es sich um ein geregeltes, ohne Kontrolltransaktion um ein gesteuertes System“ [FeSi98,186]. Regel 2 besagt, dass ein Objekt in zwei Objekte zerlegt werden kann, welche optional durch eine Transaktion verbunden sind. Die Zerlegung nach dem Verhandlungsprinzip wird in Regel 5 beschrieben: Es muss die Möglichkeit bestehen, eine beliebige, zwei Diskursweltobjekte verbindende Transaktion, in eine D- und optional in eine V- oder A-Transaktion zu zerlegen, wobei eine V- sequentiell zu einer D-Transaktion und eine A- sequentiell zu einer V-Transaktion abzubilden ist. Nach Regel 6 darf eine beliebige Transaktion typerhaltend sowohl sequentiell als auch parallel zerlegt werden. Nach Regel 3 und 7 darf eine beliebiges Objekt bzw. eine beliebige Transaktion typerhaltend spezialisiert werden. Die Regeln 4, 8 und 9 erläutern die mehrstufige Anwendung der Zerlegungsregeln (vgl.[FeSi98,187f]).

2.4.3 Die Ableitung der Ablauf- aus der Interaktionssicht

Nach [Sinz97,4] besteht die Aufgabe eines Beziehungsmetamodells darin, zwei Metamodelle zu verknüpfen, indem es Bausteine dieser Metamodelle zueinander in Beziehung setzt. Die Ableitung der Ablauf- aus der Interaktionssicht soll über ein Beziehungsmetamodell dargestellt werden, welche deren Teilmetamodelle miteinander verbindet. In diesem Beziehungsmetamodell werden folgende Abbildungsregeln definiert: - Die Anzahl der Diskurs und Umweltobjekte muss der Anzahl der Vorgangsreihen des VES entsprechen. Unter einer Vorgangsreihe wird in dieser Diplomarbeit eine sich in einer horizontalen Reihe befindende Menge von Vorgängen bzw. Aufgaben verstanden, die sich auf genau ein Aufgabenobjekt beziehen.

- Der Aufgabenobjektname einer Vorgangsreihe muss den eindeutigen Namen eines Objektes des Interaktionsschemas besitzen.

- Die Anzahl der Transaktionen der letzten Zerlegungsstufe des Interaktionsschemas muss identisch mit der Anzahl der Transaktionsereignisse des VES sein, wobei eine Transaktion auf genau ein Transaktionsereignis abgebildet wird.

2.4.4 Erweiterte semantische Anforderungen

Die folgenden aufgestellten Anforderungen können nicht aus dem Metamodell abgeleitet werden, sondern sind Ergebnisse inhaltlicher Überlegungen, die den Modellierer bei einer zielgerichteten Vorgehensweise unterstützen sollen. Bereits an dieser Stelle sollte als semantische Bedingung für alle Modelle der Struktursicht vorgegeben werden, stets eindeutige Benennungen für Objekte und Transaktionen zu vergeben, um diese voneinander unterscheiden zu können. Im Prozess der Modellierung können Diskursweltobjekte nach Durchführung einer hierarchischen Transaktionszerlegung zusätzlich in steuernde und gesteuerte Objekte zerlegt werden. Eine weitere Regel gibt vor, dass diese gesteuerten Objekte nicht oder nur in Ausnahmefällen verhandeln dürfen. Weiterhin erscheint es sinnvoll, das Verbinden von Umweltobjekten mit S-K-Transaktionen zu vermeiden, da Umweltobjekte mit Diskursweltobjekten nur durch gegebenenfalls koordinierte Leistungstransaktionen verbunden sind. Es sollte dem Modellierer ebenfalls nicht ermöglicht bzw. erschwert werden, Transaktionen zwischen Umweltobjekten anzubringen. In beiden Fällen würden diese einer gesonderten Betrachtungsweise unterworfen und sollten dann jeweils als Diskursweltobjekt dargestellt werden.

2.4.5 Die Definition von IAS-Zerlegungsstufen

„In der SOM-Methodik beginnt die Erstellung eines Geschäftsprozessmodells mit der Abgrenzung von Diskurswelt und Umwelt sowie der Erfassung der Leistungsbeziehungen zwischen Diskurswelt und Umwelt“ [FeSi98,190]. Als Anforderung wird daraus abgeleitet, dass dem Modellierer ein Startpunkt zur Verfügung gestellt werden soll, bei dem er nur Leistungstransaktionen und Objekte modellieren darf. Der danach folgende Zerlegungsprozess von Objekten und Transaktionen soll in mehreren IAS-Zerlegungsstufen erfolgen. Eine IAS-Zerlegungsstufe ist dabei als ein für sich abgeschlossener Dokumentationsschritt des Modellierungsprozesses zu verstehen. Der Modellierer soll dabei frei entscheiden können, wann er eine neue IAS-Zerlegungsstufe

eröffnet. Dabei ist es eine grundsätzliche Anforderung, die Konsistenz zwischen erstellten IAS-Zerlegungsstufen zu wahren. Es soll für den Modellierer weiterhin möglich sein, sich auf eine einzelne Zerlegungsstufe zu konzentrieren, die Beziehung zwischen Zerlegungsstufen zu visualisieren und den Gesamtmodellierungsprozess nachvollziehen zu können.

2.5 Bewertung des SOM-Ansatzes

Die Stärke dieses Ansatzes besteht in seinem aufeinander abgestimmten Begriffssystem und seiner methodischen Durchgängigkeit, wodurch v.a. die Nachvollziehbarkeit der erzielten Modellierungsergebnisse unterstützt wird. Kritisch anzumerken ist jedoch, ob diese Stärken in der Praxis auch tatsächlich zum Nutzen eines Unternehmens eingesetzt werden können. Modelle mit einer relativ einfachen Problemstellung führen schnell, v.a. in der Verhaltenssicht, zu einer hohen Komplexität und damit Unübersichtlichkeit (vgl.[FeSi98,193]). Personen, welche darüber zu entscheiden haben, ob eine derartige Modellierungsmethodik eingeführt wird, werden berücksichtigen, dass das Expertenwissen zur Lösung einer betrieblichen Problemstellung meist implizit bei den Mitarbeitern eines Unternehmens liegt. Diese werden einen Ansatz, bestehend aus komplexen Modellkonstrukten und dem damit verbunden Lernaufwand, zunächst nur im geringen Umfang akzeptieren und demnach ihr fachliches Wissen nicht ausreichend in den Problemlösungsprozess einbringen. Die Einbeziehung aller Mitarbeiter ist allerdings für die Kopplung der betriebswirtschaftlichen bzw. DV-technischen Problemstellung und des erstellten Fachkonzepts äußerst wichtig.

Nach der erfolgten Herleitung der theoretischen Anforderungen an die zu erstellende Visio-Lösung, soll nun das Programm erläutert werden, mit welchem diese Anforderungen umgesetzt werden.

3 Microsoft Visio

Die Hersteller von Visio verfolgten seit der ersten Version im Jahre 1992 das Ziel, mit Hilfe dieses Programms die Erstellung standardisierter Geschäftsgrafiken zu unterstützen (vgl.[Lel02,14]). Diese Geschäftsdiagramme können dabei aus sehr verschiedenen Bereichen kommen: Zu nennen sind z.B. Organisationsdiagramme, Ablaufdiagramme, Raumpläne, technische Zeichnungen sowie Diagramme zur Daten-, Software- und der Netzwerkmodellierung (vgl.[Vis-Hb00,15ff]).

3.1 Gründe für den Einsatz von Microsoft Visio

Visio ist nicht fest in das Microsoft Office Packet integriert, wird jedoch sehr häufig neben dem Programm Microsoft Outlook von Unternehmen zusätzlich zu diesem Paket erworben und ist daher in Unternehmen weit verbreitet. Nicht nur aufgrund der gemeinsamen Programmiersprache Visual Basic for Applications (VBA) wird eine sehr gute Interoperabilität mit anderen Microsoft Produkten geboten. Die immer stärkere Integration von Visio in die Microsoft .Net Umgebung dürfte das Zusammenwirken mit den neuen .Net Programmiersprachen wie C# oder VB .NET in Zukunft noch fördern (vgl.[MSFT-Vis03]). Visio bietet im Bereich Daten- und Softwaremodellierung im Vergleich zu Produkten wie Rational, Together Control Center oder dem Innovator, eine ähnliche Funktionalität an, jedoch gilt die Qualität der Unterstützung bislang als nicht ausreichend, um diesen Produkten bei größeren Software-Projekten Konkurrenz bieten zu können (vgl.[McN02]). Die im Rahmen dieser Diplomarbeit verwendete Professional Edition von Visio 2002 ist dafür mit ca. 600 Euro erheblich billiger, als diese Produkte (vgl.[MID]) und Peter Coad, Gründer von TogetherSoft, ist der Meinung, „dass es nur eine Frage der Zeit ist, bis Rational von Microsoft Visio ersetzt wird“ [Coad02,22]. Während ungeübte Anwender sehr schnell in der Lage sind, Geschäftsdiagramme zu erstellen, bietet es professionellen Entwicklern die Möglichkeit, über das Visio ShapeSheet und mit Hilfe der angesprochenen Programmiersprachen, komplexe Lösungen zu entwerfen. „Von den ersten Projektideen in Form von Mind Maps, der Projektplanung mittels Gantt-Charts, über die strukturierte Darstellung in UML-Diagrammen bis hin zur [automatisierten Erstellung von Datenbanktabellen] gibt es viele Arbeiten, die durch Visio-Grafiken unterstützt werden können“ [Muel01]. Das Programm kann deshalb innerhalb eines Unternehmens von einem

wesentlich breiteren Anwenderkreis genutzt und die Modellierungsergebnisse können besser als bei anderen Modellierungsprogrammen kommuniziert werden. Gerade die im Bezug zum SOM-Ansatz aufgeworfene Kritik der relativ schlechten Kommunizierbarkeit, könnte durch den Einsatz einer Visio-Lösung ausgeglichen werden.

3.2 Die wichtigsten Elemente von Microsoft Visio

3.2.1 Visio Shapes

Alle grafischen Objekte um Zeichnungen und Diagramme zu erstellen, werden in Visio als Shapes, im Deutschen Schablonen, bezeichnet (vgl.[Lel02,20]). Weitere Arten von Shapes sind Seitenshapes, wobei die aktuelle Seite immer den Namen „Sheet!0“ besitzt, importierte Graphiken z.B. aus dem Computer Aided Design (CAD)-Bereich, um die, in einer Form von Kapselung, eine Shape-Hülle generiert wird sowie Hilfslinien und Hilfspunkte, die dem Nutzer beim Erstellen von Diagrammen unterstützen (vgl.[Lel02,21f]).

3.2.1.1 Techniken zur Erstellung komplexer Shapes

Visio bietet zu deren Erstellung zwei grundlegende Techniken an:

- Gruppierung: Hierdurch wird eine beliebige Sammlung von Shapes zu einer Gruppe vereint. Die Gruppe stellt selbst wiederum ein Shape dar.

- Die Anwendung von Mengenoperationen: Aus einer beliebigen Menge von Shapes werden durch Anwendung von mathematischen Mengenoperationen völlig neue Shapes erzeugt. Im Gegensatz zur Gruppierung sind hierbei die alten Shapes (außer durch das Rückgängig machen einer Aktion) nicht mehr vorhanden (vgl.[Lel02,23ff]).

3.2.1.2 1-D und 2-D Shapes

Visio unterscheidet zwei grundlegende Kategorien von Shapes: 1-D und 2-D Shapes. (vgl.[MSFT-Press01,34]). Die Begriffe eindimensional (1-D) und zweidimensional (2-D) beziehen sich nicht auf die räumliche Ausdehnung, sondern auf das jeweilige Verhalten eines Shapes. Ein 1-D Shape kann eine ganz normale 2-D Geometrie besitzen. Bei der Umwandlung eines 2-D Shapes in ein 1-D Shape werden dem Shape ein Anfangs- und ein Endpunkt hinzugefügt, nicht optisch, sondern in seinem weiter unten noch genauer erläuterten ShapeSheet. Zusätzlich werden diesem ShapeSheet mehrere Formeln