Entwicklung eines Werkzeugs zur Modellierung von Geschäftsprozessen

Mikropolitische Analyse von Prozessen und Problemen des Qualitätsmanagements

Tesis , 2003 , 108 Páginas , Calificación: 2,0

Informática - Informatica de negocios

Diese Arbeit fasst 2 sehr unterschiedliche Themen zusammen:

1. Geschäftsprozessmodellierung mit der Entwicklung einer Beispielapplikation in Visio
2. Mikropolitik

Diese Themen wurden unter dem Gesichtspunkt des Qualitätsmanagements vereint.

Nach nunmehr 3 Jahren Berufserfahrung kann ich sagen, dass der mikropolitische Ansatz ein realistischer und nützlicher Ansatz für die Sichtweise auf die Prozesse einer Organisation ist.

Ich halte es von praktischer Relevanz wenn man in der Industrie mit Werkzeugen wie WebLogic Integration (wie ich) arbeitet, Prozesse programmiert und gestaltet und dabei auch den Blich auf die Personen, die diese Prozesse gestalten, legt.

Inhaltsverzeichnis

1 Einleitung

2 Das Semantische Objektmodell
2.1 Die Architektur des SOM-Ansatzes
2.1.1 Der Unternehmensplan
2.1.2 Die Geschäftsprozessebene
2.1.3 Die Anwendungssystemebene
2.2 Das Vorgehensmodell des SOM-Ansatzes
2.3 Das Aufgabenkonzept im SOM-Ansatz
2.3.1 Die Innen- und Außensicht einer Aufgabe
2.3.2 Abgrenzungskriterien für Aufgaben
2.3.2.1 Abgrenzung hinsichtlich ihres Lösungsverfahrens
2.3.2.2 Abgrenzung hinsichtlich ihres Automatisierungsgrades
2.4 Erfordernisse zur Modellierung der SOM-Geschäftsprozessmodellebene
2.4.1 Anforderungen aus den Sichten des Metamodells
2.4.1.1 Metamodell Geschäftsprozessebene: Interaktionssicht
2.4.1.2 Metamodell Geschäftsprozessebene: Ablaufsicht
2.4.2 Anforderungen aus den Produktionsregeln
2.4.3 Die Ableitung der Ablauf- aus der Interaktionssicht
2.4.4 Erweiterte semantische Anforderungen
2.4.5 Die Definition von IAS-Zerlegungsstufen
2.5 Bewertung des SOM-Ansatzes

3 Microsoft Visio
3.1 Gründe für den Einsatz von Microsoft Visio
3.2 Die wichtigsten Elemente von Microsoft Visio
3.2.1 Visio Shapes
3.2.1.1 Techniken zur Erstellung komplexer Shapes
3.2.1.2 1-D und 2-D Shapes
3.2.2 Das Visio ShapeSheet und seine Struktur
3.2.2.1 Wichtige Abschnitte im ShapeSheet
3.2.2.2 Wichtige Funktionen innerhalb des ShapeSheets
3.2.4 Beispiel eines „SmartShapes“
3.2.5 Bewertung des ShapeSheets
3.3 Der Aufbau einer Visio-Lösung
3.4 Programmierung in Visio
3.4.1 Das Visio-Objektmodell
3.4.2 Die integrierte Entwicklungsumgebung VBA
3.4.2.1 Visual Basic for Applications
3.4.2.2 Zugriff auf Zellen des ShapeSheet mit VBA
3.4.2.3 Performanceorientierte VBA-Programmierung
3.4.3 Visio-Ereignisprogrammierung
3.4.4 Die Darstellung der Visio-Modelle im Web
3.4.5 Visio und Microsoft .Net
3.4.6 Visio Add-ons und Add-ins

4 Realisierung der SOM-Geschäftsprozessmodellebene mit Visio
4.1 Die Vorgehensweise beim Entwurf der Visio-Lösung
4.2 Auswahl und Gestaltung geeigneter Shapes
4.2.1 Stencils zur Bereitstellung der Elemente
4.2.2 Shapes zur Repräsentation der Elemente
4.2.2.1 Diskurswelt- und Umweltobjektshape
4.2.2.2 Leistungstransaktions- und Transaktionsshape
4.2.2.3 Optimierung des Verbindungsverhaltens zwischen Objekten und Transaktionen
4.2.2.4 Aufgabenshapes
4.2.2.5 Shapes zur Darstellung der Ereignisse
4.2.3 Die Typisierung der Metaobjekte
4.2.4 Das Anlegen von Notizen an Modellelemente
4.3 Die Umsetzung der Produktionsregeln
4.3.1 Die Funktionsweise der entworfenen Masken
4.3.2 Transaktionszerlegung
4.3.3 Objektzerlegung
4.3.4 Spezialisierung von Diskurswelt-, Umweltobjekten und Transaktionen
4.3.5 Sequentielle und parallele Zerlegung von Transaktionen
4.3.6 Realisierung der Mehrstufigkeit
4.4 Die Definition und Behandlung von IAS-Zerlegungsstufen
4.4.1 Bewertung der Darstellung von Beziehungen durch Hyperlinks
4.4.2 Herstellung einer Beziehung zwischen IAS-Zerlegungsstufen
4.4.3 Diskussion der Konsistenz einer IAS-Zerlegungsstufe
4.5 Der Einsatz von Ereignissen
4.5.1 Ereignisorientierte Konsistenzprüfung beim Löschen von Transaktionen
4.5.2 Ereignisorientierte Konsistenzsicherung zwischen IAS-Zerlegungsstufen beim Löschen eines Modellelements
4.5.3 Ereignisorientierung beim Hinzufügen von Modellelementen
4.5.4 Konsistenzverletzung zwischen IAS-Zerlegungsstufen durch Anwendung von Produktionsregeln
4.5.5 Ereignisorientierte Prüfung von Verbindungsereignissen
4.5.6 Ereignisorientierte Prüfung auf eindeutige Namen
4.6 Das Vorgangsereignisschema
4.6.1 Der Aufbau des VES
4.6.2 Automatisches Hinzufügen und Benennen von Transaktionsereignissen
4.6.3 Diskussion der Automatisierbarkeit der Ablaufsicht
4.6.4 Die Behandlung von Aufgaben und Zielen
4.6.5 Beschreibung der Automatisierung von Transaktionsereignissen
4.7 Programmierung eines Visio Add-ons in C#
4.8 Überlegungen zu den einzelnen Seiten der Visio-Lösung
4.9 Bewertung der Visio-Lösung hinsichtlich der erzielten Ergebnisse
4.9.1 Schwachstellen in der Visio-Lösung
4.9.2 Möglichkeiten zur Weiterentwicklung der Visio-Lösung

5 Ziele einer mikropolitischen Analyse des Qualitätsmanagements
5.1 Erreichung einer realistischeren Betrachtungsweise
5.2 Darstellung des Einsatzes von Macht als natürliches Mittel zur Durchsetzung von Interessen
5.3 Ziele bezüglich des Qualitätsmanagements
5.3.1 Die Analyse der Formalisierungsprozesse in einer Organisation durch das Qualitätsmanagement
5.3.2 Analyse der Beziehungen funktionaler Gruppen einer Organisation
5.3.3 Analyse der Kommunikation des Unternehmens mit seiner Umwelt beim Prozess der Zertifizierung
5.3.4 Analyse der Ziele des Managements bezüglich TQM

6 Kennzeichen von Total Quality Management
6.1 Die ISO 9000 Norm
6.2 Das Qualitätshandbuch zur Darlegung der ISO 9000 Norm
6.3 Die Qualitätstechnik FMEA
6.4 Die Zertifizierung
6.4.1 Ziele einer Zertifizierung
6.4.2 Der Ablauf einer Zertifizierung

7 Mikropolitik
7.1 Crozier/Friedberg als Auslöser einer mikropolitischen Wende
7.2 Die politische Perspektive
7.3 Macht in der mikropolitischen Perspektive
7.3.1 Die Beherrschung der Unsicherheitsquelle
7.3.2 Typen von Macht in Organisationen
7.4 Mikropolitik als Spiel
7.4.1 Die Spielmetapher
7.4.2 Routine- und Innovationsspiele
7.5 Strategien und Taktiken in Organisationen
7.5.1 Die strategische Orientierung des Akteurs
7.5.2 Offensive und defensive Strategie
7.5.3 Mikropolitische Taktiken
7.6 Die Beziehungen zur Umwelt

8 Mikropolitische Analyse des Total Quality Managements
8.1 Die Spielarena des TQM
8.1.1 Spiel-Kontext
8.1.2 Spieler
8.1.3 Spiel-Ziele
8.1.4 Spiel-Einsatz und Spiel-Gewinne
8.1.5 Spiel-Material und Spiel-Regeln
8.2 Strategien, Taktiken in der Arena des TQM
8.2.1 Spiel-Strategien
8.2.1.1 Formalisierungsprozesse durch die ISO 9000 Norm
8.2.1.2 Job-Enrichment und Job-Enlargement: High-Trust Strategien
8.2.2 Spiel-Taktiken
8.2.2.1 Das kontinuierliche Verbesserungsmanagement
8.2.2.2 Kommunikationstaktiken
8.2.2.2.1 Das Erlernen von Techniken des Qualitätsmanagements
8.2.2.2.2 Der Einsatz von Plänen durch TQM-Promotoren
8.2.2.2.3 Die Kommunikation der Qualitätsstrategie
8.2.2.3 Taktiken bei der Zertifizierung
8.2.2.4 Manipulation als Verhinderungstaktik
8.2.2.5 Taktiken zwischen Vorgesetzten und Unterstellten hinsichtlich der Bewertung der Arbeitsqualität
8.2.2.6 Taktiken zwischen Management, Qualitätssicherung und Marketing
8.3 Aspekte einer empirischen Überprüfung

9 Zusammenführung und Anwendung der Ergebnisse hinsichtlich des Qualitätsmanagements

Abkürzungsverzeichnis

Abbildungsverzeichnis

Literaturverzeichnis
Verzeichnis der URL
URL von Microsoft
Sonstige URL

1 Einleitung

Betrachtet man Veröffentlichungen in der Produktionstechnik und im Qualitäts-management, 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 in dieser Leseprobe nicht enthalten

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 DV-technischen 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äftsprozess-modellebene 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 Unternehmens-plans“ [FeSi98,178]. Dieses Modell erläutert „ein System von Haupt- und Service-prozessen, 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 in dieser Leseprobe nicht enthalten

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 ereignis-gesteuerte 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.

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

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 Auf-zeichnung 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 Aufgaben-trä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äftsprozess-modellebene 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 in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

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).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Die Produktionsregeln nach [FeSi98,187]

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 Meta-modelle zu verknüpfen, indem es Bausteine dieser Metamodelle zueinander in Beziehung setzt. Die Ableitung der Ablauf- aus der Interaktionssicht soll über ein Beziehungsmeta-modell 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 Hilfs-punkte, 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 hinzugefügt, um dem Shape ein linienhaftes Verhalten zu ermöglichen. Für die später vorgestellte Visio-Lösung ist es wichtig, dass diese Endpunkte stets auch Connection Points (Verbindungspunkte) darstellen. Mit Hilfe dieser Connection Points können 1-D- an 2-D Shapes oder an Shapes mit benutzerdefinierten Connection Points „andocken“.

3.2.2 Das Visio ShapeSheet und seine Struktur

Die Basis von Shapes kann als eine Menge von Parametern bezeichnet werden, die dessen Aussehen und Verhalten bestimmen. Diese Daten werden im ShapeSheet zusammengefasst und für die Darstellung eines Shapes auf dem Bildschirm ausgewertet. „Shape und ShapeSheet [sind] unterschiedliche Ansichten der gleichen Datenmenge“ [Lel02,52]. Das ShapeSheet, welches eine tabellenartige Struktur besitzt, ist nach Funktionalitäten in einzelne Abschnitte aufgeteilt (vgl.[Lel02,53]). „In jedem Abschnitt des ShapeSheets sind andere, auf das jeweilige Shape bezogene Funktionalitäten abgelegt bzw. zusammengefasst, wobei die kleinste Informationseinheit die Zelle ist“ [Lel02,53]. Änderungen an den Shapes werden stets über Manipulationen des Inhalts von Zellen realisiert. Die Darstellung einer Zelle erfolgt im ShapeSheet durch die Sichten Wert und Formel. Formeln werden v.a. dazu verwendet, das Verhalten der Shapes durch Variablen oder Referenzen zu steuern. Visio wertet die Formel aus und wandelt sie zu einem Wert um, bei dem der Datentyp sowie die in dieser Zelle definierten Einheiten berücksichtigt werden. Das Eingeben von Konstanten wird hingegen dadurch realisiert, dass ein Wert, meist vom Typ Integer oder String, direkt in eine Zelle geschrieben wird. Je nach Element kann das ShapeSheet in seiner Struktur variieren und unterschiedliche Abschnitte enthalten. Ferner erscheinen bestimmte Abschnitte im ShapeSheet erst dann, wenn man eine bestimmte Funktionalität implementiert oder den Abschnitt über ein Menü manuell eingefügt hat. Jedes Dokument, jede Seite, jeder Stil, jedes gruppierte Shape, jedes Objekt eines anderen Programms oder jeder Master besitzt sein eigenes ShapeSheet, in dem alle Daten über das Objekt gespeichert werden (vgl.[Grab00,79] und [MSFT-ShapeSheet]). Für das Erlernen und Anwenden des ShapeSheet hat es sich als hilfreich und notwendig herausgestellt, die Microsoft Developer Collection zu verwenden, da hier eine umfassende ShapeSheet Referenz [MSFT-ShapeSheet] zu finden ist, welche in der sonstigen Literatur zu Microsoft Visio nicht bzw. nicht im benötigten Detaillierungsgrad vorhanden war.

3.2.2.1 Wichtige Abschnitte im ShapeSheet

Im Rahmen dieser Diplomarbeit wurde größtenteils mit der englischen Version von Microsoft Visio 2002 gearbeitet. Deshalb und weil diese geläufiger sind, soll für die im weiteren vorgestellten Begriffe, jeweils ihre englische Bezeichnung verwendet werden.

Scratch Section: Dieser Abschnitt, im Deutschen als „Entwurf“ bezeichnet, wird typischerweise dazu benutzt, komplexe und häufig vorkommende bzw. referenzierte Berechnungen zu isolieren. Zellen in diesem Abschnitt verarbeiten Einheiten auf zweierlei Weise: Während in den Zellen „Scratch.X“ und „Scratch.Y“ die eingestellte Einheit des Zeichenblattes benutzt wird, sind die Zellen „Scratch.A“ bis „Scratch.D“ ohne „Typisierung“. Man kann eine beliebige Einheit definieren, die dann auch zurückgegeben wird.

User-Defined Section: Ähnlich zum vorherigen Abschnitt können benutzerdefinierte Zellen Werte und Formeln speichern. Der Hauptunterschied zur Scratch Section besteht darin, eigene Zellnamen definieren zu können, wie z.B. „User.Const“ oder „User.TYPE“.

Custom Properties Section: Dieser Abschnitt dient ebenfalls zur Datenspeicherung. Zusätzlich zu User-Defined Cells können hierin in den Zellen „Type“ und „Format“ unterschiedliche Datentypen und Formatierungsmöglichkeiten ausgewählt werden. Über den Visio Menüpunkt „View-Custom Properties Window“ kann ein Fenster angezeigt werden, in dem die definierten Custom Properties unmittelbar nach Anklicken eines Shapes dem Anwender angezeigt werden (vgl.[Grab00,160f]).

Geometry Section: Dieser Abschnitt besteht aus Reihen, deren Zellen die Koordinaten für die Kanten der Linien und Bögen, aus denen das Shape-Objekt besteht, enthalten. Soll sich die Geometrie eines Shapes aus mehreren Teilelementen zusammensetzen, so können mehrere Geometry Sections eingefügt werden. Dies geschieht dann automatisch, wenn zwei Shapes über das Menü „Shape-Operations-Combine“ miteinander verbunden werden, und deren geometrische Beschreibungen nun innerhalb eines ShapeSheets zusammengefasst werden.

Control Section: Die wichtigste Möglichkeit, das Verhalten eines Shapes zu kontrollieren, ist das Hinzufügen von Controls. Diese erscheinen als „kleine gelbe Diamanten“, welche der Benutzer auswählen und bewegen kann. Je nach eingefügten Formeln reagiert die Geometrie oder die Textposition eines Shape auf Veränderungen, die an diesem „Control-Handle“ vorgenommen wurden. Ein Control besitzt im ShapeSheet die Zelle „Tip“. Zeigt der Mauszeiger genau auf ein Control, so wird dem Benutzer ein Wert angezeigt, der in dieser Zelle hinterlegt ist.

Action Section: Die sich in diesem Abschnitt befindenden Zellen erlauben es dem Benutzer, Makros oder Standardfunktionen über ein Kontextmenü auszuführen. Während sich die Namen der aufzurufenden Prozeduren in der Zelle „Action“ befinden, kann in der sich im ShapeSheet rechts davon befindenden Zelle „Menu“ eine Beschreibung dieser Funktion eingetragen werden, welche dem Benutzer erscheint, wenn er nach Markierung eines Shapes dessen Kontextmenü mit der rechten Maustaste aufruft.

Miscellaneous Section: Dieser Abschnitt, im Deutschen „Sonstiges“ genannt, enthält verschiedene Attribute von Shapes, wie z.B. die Möglichkeit, Controls ein- bzw. auszublenden oder Shapes nicht mehr markieren zu können. Weiterhin enthält er die Zelle „Comment“, die mit der Zelle „Tip“ der Controls Section verglichen werden kann. Wird der Mauszeiger auf das Shape gelegt, so erscheint dem Nutzer ein Wert, der in dieser Zelle definiert wurde.

3.2.2.2 Wichtige Funktionen innerhalb des ShapeSheets

Die Guard-Funktion: Diese Funktion schützt Ausdrücke in Zellen vor dem Löschen oder vor Veränderungen, welche durch Aktionen des Benutzers auf dem Zeichenblatt ausgelöst wurden. Zum Beispiel können durch die Befehle Guard(PinX) oder Guard(PinY) Koordinatenpunkte eines Shapes auf dem Zeichenblatt konstant gehalten werden.

Die Simulation von Ereignissen mit der DEPENDSON-Funktion: Diese Funktion kann in Abschnitten wie z.B. der Scratch Section, nicht aber in der Events Section, dazu benutzt werden, um durch Ereignisse Funktionen auszulösen. Durch den Befehl RUNADDON("my_prog.exe") + DEPENDSON(PinX) wird z.B. eine exe-Datei gestartet, sobald sich der Wert der Zelle „PinX“ verändert hat. Diese Veränderung in der Zelle stellt nun aus Sicht der Zelle in der sich der RUNADDON-Befehl befindet, ein vom Benutzer definiertes Ereignis dar (vgl.[MSFT-Press01,159f]).

Die SHAPETEXT-Funktion: Hierdurch ermöglicht es Visio, von einer beliebigen Zelle des ShapeSheet aus, den Text eines Shapes zu referenzieren. Mit der Funktion SHAPETEXT(Sheet.3!theText) wird z.B. der Text von Sheet.3 in die gewünschte Zelle geschrieben. Soll der Text desjenigen Shapes verwendet werden, auf den sich das ShapeSheet selbst bezieht, wird die Funktion SHAPETEXT(theText) verwendet (vgl.[MSFT-ShapeSheet]).

3.2.4 Beispiel eines „SmartShapes“

Abbildung in dieser Leseprobe nicht enthaltenAbbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Ein Visio „SmartShape“

Shapes, welche mit zusätzlichen Verhaltensweisen und Eigenschaften ausgestattet sind, werden in Visio als „SmartShapes“ bezeichnet (vgl.[MSFT-Press01,17]). Dieses Beispiel besteht aus zwei Shapes, welche zu einem übergeordneten Shape gruppiert wurden. Vom Verhalten lässt sich der Bogen sowohl entlang der X-Achse, als auch in Form seines Radius und seiner Ausrichtung verschieben bzw. vergrößern. Dies wird über Controls erreicht. Die Formel der Zelle „Scratch.C1“ der Scratch Section sorgt dafür, dass die absolute Differenz zwischen dem Mittelpunkt des Bogens und der Sehne nie größer wird, als die Hälfte der Breite des Shapes. Dies wird durch folgenden Ausdruck erreicht: =IF(Controls.Y1>Width/2;SETF("controls.y1";Width/2);IF(Controls.Y1
Width/2;SETF("controls.y1";-Width/2);FALSE))
Das referenzierte Control beschreibt dabei die Ausdehnung der Sehne. In den Zellen, in denen die Koordinaten des Textfeldes eingegeben werden, wird durch die Befehle =Controls.X3 bzw. =Controls.Y3 eine Referenz auf die Koordinaten eines weiteren Controls erzeugt.

3.2.5 Bewertung des ShapeSheets

Als Stärke kann der ähnliche Aufbau im Vergleich zu Microsoft Excel genannt werden, der es vielen Benutzern leicht erscheinen lässt, sich darin einzuarbeiten. Das ShapeSheet versteht sich als eine abgeschlossene Programmierumgebung, mit der man komplexe Funktionalität realisieren kann, ohne Quellcode in einer höheren Programmiersprache schreiben zu müssen (vgl.[Grab00,83]). In besonders hohem Maße können Zellen des ShapeSheet zur Datenspeicherung genutzt werden. Negativ zu bewerten ist hingegen die geringe Unterschiedlichkeit der einzelnen Abschnitte. Sowohl User-Defined Cells, Custom Properties oder auch Zellen der Scratch Section besitzen nur marginale Unterschiede und deren Zellinhalte könnten in dem vorgestellten Beispiel jederzeit auch Zellen anderer Abschnitte zugeordnet werden. Die Flexibilität des ShapeSheets führt beim Entwickeln einer Lösung deswegen zu einer gewissen Beliebigkeit. Grabowski sieht als weiteres Problem, „dass es sehr viele ShapeSheet-Zellen hinter jedem Shape gibt, sogar hinter einer simplen Linie“ [Grab00,83]. Weitere recht unangenehme Schwächen sind das Fehlen einer Druck- oder Exportfunktion für die Daten des ShapeSheets sowie die fehlende Möglichkeit, Werte und Formeln eines ShapeSheets in ein Anderes zu kopieren. Microsoft stellt ein Add-on zur Verfügung (vgl.[MSFT-PrintSheet]), welches diese Schwächen teilweise behebt, jedoch bereits in einer Standardlösung angeboten werden sollte und über dem hinaus für die deutsche Version von Visio 2002 nicht funktionsfähig ist.

3.3 Der Aufbau einer Visio-Lösung

Eine Visio-Lösung besteht in der Regel aus einem Dokument, welches mehrere Seiten enthält. Eines der wichtigsten Elemente einer Visio-Lösung sind sogenannte Stencils. Diese Dateien mit der Endung „vst.“ stellen sämtliche relevante Modellbausteine in Form von Mastern zur Verfügung, welche per „drag and drop“ auf die Zeichenfläche gezogen werden. Zwischen den Shapes und ihren Master bleibt danach eine Verbindung bestehen. Besondere Eigenschaften oder benutzerspezifische Daten werden vom Master in die daraus erstellten Shapes weitervererbt (vgl.[Lel02,35f]). Öffnet man über das Menü „Tools-Makros-Visual Basic Editor“ die Entwicklungsumgebung, wird automatisch die Hülle eines VBA-Projektes bereitgestellt. Diese Programmiersprache soll im kommenden Abschnitt hinsichtlich ihres Einsatzes mit Visio vorgestellt werden.

[...]

• Universidad: University of Bamberg
• Calificación: 2,0
• Autor: Christian Stark (Autor)
• Año de publicación: 2003
• Páginas: 108
• No. de catálogo: V20871
• ISBN (Ebook): 9783638246330
• ISBN (Libro): 9783656457343
• Idioma: Alemán
• Etiqueta: Entwicklung, Werkzeugs, Modellierung, Geschäftsprozessen, Analyse, Prozessen, Problemen, Qualitätsmanagements