scieee Science in your language
[en] (orig)
U
N
I
V
E
R
S
I
T
Ä
T
U
L
M
·
S
C
I
E
N
D
O
·
D
O
C
E
N
D
O
·
C
U
R
A
N
D
O
·
Universit¨
at Ulm
Fakult¨
at f¨
ur Informatik
Abteilung Datenbanken
und Informationssysteme
Diplomarbeit
Visualisierungskonzepte für
Prozessinformationen
vorgelegt von
Max Moldmann
Februar 2006
Gutachter: Prof. Dr. Peter Dadam, Universit¨
at Ulm
Dr. Manfred Reichert, Assoc. Prof., Universit¨
at Twente, NL
Betreuer: Dipl. Inf. Ralph Bobrik, Universit¨
at Ulm
Kurzfassung
Die bisherigen und gegenw¨
artigen Forschungs- und Entwicklungsarbeiten im Rahmen von
Prozess-Management-Systemen (PMS) konzentrieren sich bisher auf theoretische, techni-
sche und implementierungsspezifische Aspekte. Diese Arbeit besch¨
aftigt sich dagegen mit
der Visualisierung von Prozessinformationen. Am Markt werden fortgeschrittene Werk-
zeuge f¨
ur Prozess-Monitoring und Analyse angeboten. Die bis zum heutigen Stand ver-
f¨
ugbaren PMS bieten allerdings nur recht eingeschr¨
ankte M¨
oglichkeiten, die vom System
verwalteten Prozessinformationen (Modell- und Laufzeitdaten) darzustellen.
Die Zielsetzung dieser Arbeit ist es zu untersuchen, welchen Anforderungen eine leistungs-
f¨
ahige Prozessvisualisierungskomponente gen¨
ugen muss. Es gilt alle Aspekte von Prozess-
informationen zug¨
anglich zu machen, wie z. B. den Datenfluss oder temporale Aspekte.
Durch die Darstellungen sollen Zusammenh¨
ange sichtbar werden. Weiterhin gilt es die
Visualisierungsbed¨
urfnisse unterschiedlicher Benutzer zu erf¨
ullen. Am Lifecycle eines Pro-
zesses beteiligen sich u. a. Prozess-Modellierer und -Verantwortliche, Management, Anwen-
der. Dies hat ein großes Spektrum an unterschiedlichen Aufgabentypen, etwa entwerfen,
informieren, entscheiden und die Forderung nach unterschiedlichen Abstraktionsniveaus
zur Folge, denen eine Darstellung gerecht werden muss.
Diese Anforderungen lassen sich durch unterschiedliche Ans¨
atze erf¨
ullen. Verschiedene
Darstellungsformen wie Prozessgraphdarstellung, Swimlane-Darstellung, Kalenderdarstel-
lung, Tabellendarstellung, Interaktionsdiagramm, Datenflussdiagramm und Matrixdarstel-
lung werden als Werkzeuge zur L¨
osung unterschiedlichster Aufgaben entwickelt. Ver-
schiedene Darstellungsarten wie Schema-, Instanz-, Multi-Instanz- und Multi-Schema-
Darstellungen erm¨
oglichen Detail- bis hin zu ¨
Ubersichtsdarstellungen. Weiterhin werden
Funktionen zur dynamischen Einblendung von Prozessaspekten vorgeschlagen und die
View-Bildung, zur Erzeugung unterschiedlich komplexer Sichten auf Prozesse diskutiert.
Umfangreiche Interaktions- und Navigationsm¨
oglichkeiten auf Prozessdaten werden vor-
geschlagen. Die vorgestellten L¨
osungen beziehen Forschungsergebnisse zu Usability und
Interface-Design mit ein, um auch Gebrauchstauglichkeit sicherzustellen.
Inhaltsverzeichnis
1. Einleitung 1
1.1. Einordnung .................................... 1
1.2. Das Ziel ...................................... 3
1.3. Motivation .................................... 5
2. Grundlagen und Einführung 9
2.1. Visualisierung von Prozessdaten ......................... 9
2.1.1. Prozessinformationen .......................... 10
2.1.2. Darstellungsarten ............................. 16
2.1.3. Organisationsmodell ........................... 18
2.2. Ans¨
atze zur Prozessvisualisierung ........................ 19
2.2.1. Ver¨
anderungen an der Grafik ...................... 20
2.2.2. Ver¨
anderungen an der Struktur ..................... 20
2.3. Zusammenfassung ................................ 22
3. Anforderungsanalyse 23
3.1. Goal-Directed-Design ............................... 24
3.2. Ziele nach Benutzergruppen ........................... 26
3.2.1. Bearbeiter / Anwender ......................... 30
3.2.2. Prozessverantwortlicher / Abteilungsleiter ............... 30
3.2.3. Management ............................... 31
3.2.4. IT ..................................... 31
3.2.5. Externer Mitarbeiter / Kunde ..................... 31
3.2.6. Prozessmodellierer ............................ 31
3.3. Zusammenfassung ................................ 31
4. Verwandte Arbeiten 33
4.1. Informationsvisualisierung ............................ 33
4.1.1. Kognitions- und Wahrnehmungsforschung ............... 34
4.1.2. Usability ................................. 37
4.1.3. Interface-Design ............................. 38
4.1.4. Styleguides und Normen ......................... 41
4.1.5. Zusammenfassung ............................ 43
4.2. Existierende Visualisierungsl¨
osungen ...................... 44
4.2.1. Business Process Management (BPM) Werkzeuge ........... 45
4.2.2. Projektplanung .............................. 52
4.2.3. Prozessneutrale Visualisierungssoftware ................ 53
4.2.4. Zusammenfassung ............................ 55
i
Inhaltsverzeichnis
5. Grafische Aspekte der Prozessdarstellung 57
5.1. Farben ....................................... 57
5.1.1. Kontraste ................................. 58
5.2. Ebenen ...................................... 59
5.3. Notationen .................................... 60
5.3.1. Knoten .................................. 61
5.3.2. Kanten .................................. 63
5.3.3. Ausf¨
uhrungsmarkierungen ........................ 69
5.4. Orientierung ................................... 70
5.5. Zusammenfassung ................................ 70
6. Darstellungsformen für Prozessdaten 73
6.1. Prozessgraphdarstellung ............................. 75
6.1.1. Blockstruktur ............................... 79
6.1.2. Zeitleiste ................................. 80
6.1.3. Implementierungsaspekte ........................ 81
6.2. Swimlane-Darstellung .............................. 82
6.2.1. Implementierungsaspekte ........................ 88
6.3. Kalenderdarstellung ............................... 88
6.3.1. Dynamische Zeitachse .......................... 94
6.4. Tabellendarstellung ................................ 94
6.4.1. Implementierungsaspekte ........................100
6.5. Interaktionsdiagramm ..............................100
6.5.1. Notwendige Voraussetzungen ......................103
6.6. Datenflussdiagramm ...............................103
6.7. Matrixdarstellung .................................105
6.7.1. Notwendige Voraussetzungen ......................117
6.7.2. Implementierungsaspekte ........................117
6.7.3. Bedingungen im Kontrollfluss ......................117
6.8. Zusammenfassung ................................118
7. Interaktionen auf Prozessinformationen 123
7.1. View-Bildung ...................................123
7.1.1. Aggregation ................................125
7.1.2. Reduktion .................................126
7.2. Aktivit¨
aten markieren ..............................126
7.2.1. Wichtige einfache Markierungsregeln ..................127
7.2.2. Regelbaukastensystem ..........................127
7.3. Detailansicht & Tooltipps ............................130
7.4. Aufgabenbereich .................................130
7.5. Navigation ....................................134
7.6. Prozesshistorie ..................................138
7.6.1. On-Line Verlaufsinformationen .....................138
7.7. Zusammenfassung ................................139
ii
Inhaltsverzeichnis
8. Ausblick 141
8.1. Sicherheitsaspekte ................................141
8.2. Partitionierbarkeit von Prozessinformationen .................142
8.3. Anpassung des Nutzer-Interface an Prozessmodelle ..............143
8.4. Mitbestimmung des Betriebsrates ........................144
8.5. Fazit ........................................144
A. Glossar 147
B. Literaturverzeichnis 151
iii
Tabellenverzeichnis
2.1. ¨
Ubersicht ¨
uber die Prozessinformationen .................... 14
3.1. Benutzergruppen mit Beschreibung ....................... 27
3.2. ¨
Ubersicht ¨
uber die Fragestellungen und Aufgaben der Benutzergruppen –
Teil 1 (Bearbeiter/Anwender, Prozessverantwortlicher/Abteilungsleiter, Ma-
nagement) ..................................... 29
3.3. ¨
Ubersicht ¨
uber die Fragestellungen und Aufgaben der Benutzergruppen –
Teil 2 (IT, Externer Mitarbeiter/Kunde, Prozessmodellierer) ........ 30
6.1. Varianten der Swimlane-Darstellung ...................... 85
6.2. Varianten der Matrixdarstellung ........................106
6.3. Darstellungsarten mit Darstellungszielen und Einordnung der Werkzeuge
nach Benutzerzielen ...............................119
6.4. M¨
ogliche Werkzeuge zum L¨
osen der Aufgaben der Benutzergruppen – Teil 1
(Bearbeiter/Anwender, Prozessverantwortlicher/Abteilungsleiter, Manage-
ment) .......................................120
6.5. M¨
ogliche Werkzeuge zum L¨
osen der Aufgaben der Benutzergruppen – Teil 2
(IT, Externer Mitarbeiter/Kunde, Prozessmodellierer) ............121
7.1. Beispiele f¨
ur die Markierungsfunktion .....................129
7.2. Aufgaben im Aufgabenbereich ..........................133
8.1. Kurzkritik f¨
ur Zugriffsschutz durch Metamodell-Unterst¨
utzung .......141
8.2. Kurzkritik f¨
ur Zugriffsschutz durch Views ...................142
iv
Abbildungsverzeichnis
1.1. Architekturmodell Process-Warehouse ..................... 4
1.2. Beispielprozess Change Management – Ausschnitt alte Version ....... 6
1.3. Beispielprozess Change Management – Ausschnitt neue Version ....... 7
2.1. Schematischer Ablauf der Prozessvisualisierung ................ 10
2.2. M¨
oglichkeiten der Zuordnung von Kontrollfluss-Informationen zu Aktivit¨
aten 15
2.3. Darstellungsarten f¨
ur die Visualisierung .................... 16
2.4. Konzepte zur Visualisierung ........................... 20
2.5. Ausschnitt aus dem Netzplan des Donau-Iller-Nahverkehrsverbundes . . . . 21
3.1. Ontologisches Designdiagramm ......................... 23
3.2. Schema des Goal-Directed-Design Entwurfskonzeptes – Teil 1 ........ 24
3.3. Schema des Goal-Directed-Design Entwurfskonzeptes – Teil 2 ........ 24
3.4. Photoshop Variationen¨
ubersicht ......................... 25
3.5. Schema f¨
ur die Einordnung der Benutzergruppen ............... 28
4.1. Kategorisierung von Prozessorientierter Visualisierungssoftware ....... 45
5.1. Wirkung von Kontrast in Tabellen ....................... 58
5.2. Symbolreduktion durch Integration ....................... 62
5.3. Nutzung von Metaphern ............................. 62
5.4. Knoten und Feldmarkierungen ......................... 63
5.5. Variationen von Kanten ............................. 64
5.6. Semantik Darstellungsm¨
oglichkeiten ...................... 66
5.7. Verdeutlichen der Blockstruktur ......................... 66
5.8. Darstellung von Prozessschnittstellen ...................... 68
5.9. Ausf¨
uhrungszust¨
ande von Aktivit¨
aten (bereit, laufend, abgebrochen, fehl-
geschlagen, abgeschlossen) ............................ 70
5.10. Knoten bei horizontaler oder vertikaler Prozessdarstellung .......... 70
5.11. Darstellung von Aktivit¨
atenknoten mit unterschiedlich vielen Attributen . . 71
6.1. ¨
Ubersicht ¨
uber die Darstellungsformen mit dargestellten prim¨
aren Prozess-
aspekten ...................................... 74
6.2. Prozessgraphdarstellung ............................. 76
6.3. Ausschnitt aus Change Management Prozess – Wirkung perspektivischer
Darstellung .................................... 79
6.4. Prozessgraph mit Blockstruktur ......................... 80
6.5. Prozessgraph mit Blockstruktur und ge¨
offnetem Unterprozess ........ 80
6.6. Orthogonales Layout ............................... 82
v
Abbildungsverzeichnis
6.7. Hierarchisches Layout .............................. 82
6.8. Prozessgraph in Swimlane-Darstellung ..................... 83
6.9. Prozessgraph in geschachtelter Swimlane-Darstellung ............. 84
6.10. Beispiel einer horizontalen Platzersparnis bei der Swimlane- gegen¨
uber der
Prozessgraphdarstellung ............................. 85
6.11. Kalenderdarstellung ............................... 89
6.12. Kalenderdarstellung in Multi-Instanz Variante ................. 92
6.13. Planungszeiten in der Kalenderdarstellung ................... 93
6.14. M¨
ogliche Balkenkonfigurationen in der Kalenderdarstellung ......... 93
6.15. Tabellendarstellung des Change-Management-Prozesses – Einfache Tabelle
(ohne Hierarchie) ................................. 95
6.16. Tabellendarstellung des Change-Management-Prozesses – Normale Tabelle . 96
6.17. Interaktionsdiagramm – Schnittstellen zwischen Abteilungen .........102
6.18. Datenflussdiagramm – Dokument: change request ...............104
6.19. Matrixdarstellung - Ausf¨
uhrungseinheiten und Systeme ...........107
6.20. Matrixdarstellung - Ausf¨
uhrungseinheiten und Dokumente ..........108
6.21. Matrixdarstellung - Ausf¨
uhrungseinheiten und Dokumente mit Tooltipp . . 108
7.1. Ablauf Prozessvisualisierung mit Views ....................124
7.2. Selektionsdialog in Apples iTunes ........................128
7.3. Spotlight im MacOS X System-Einstellungs-Dialog ..............128
7.4. Beispiel f¨
ur Markierungsregeln .........................129
7.5. Aufgabenbereich in Microsofts Powerpoint ...................131
7.6. Konfiguration der Anzeige der Prozessdetails .................132
7.7. Vertikale und horizontale Navigation in Prozesshierarchie ..........133
7.8. Zur¨
uck-Funktion mit benannten Aktionen im Internet Explorer .......135
7.9. ¨
Ubersichtsfenster aus Adobe Photoshop ....................136
7.10. Tabs im Hauptfenster mit verschiedenen Darstellungen ............136
7.11. Navigation im Amazon Shop ..........................137
vi
1
Einleitung
1.1. Einordnung
Prozess-Management-Systeme (PMS) optimieren Arbeitsabl¨
aufe in Unternehmen. Hierf¨
ur
werden Gesch¨
aftsprozesse in ihre einzelnen Arbeitsschritte zerlegt und f¨
ur die Verwen-
dung in einem PMS modelliert. PMS bieten u. a. folgende Funktionalit¨
at im Umgang mit
Prozessen: Ausf¨
uhrung, Automatisierung, Steuerung, Monitoring und Analyse.
F¨
ur den Umgang mit Prozessen werden außer einem meist auf Kennzahlen basierenden
Monitoring auch leistungsf¨
ahige Visualisierungsm¨
oglichkeiten von Prozessinformationen
ben¨
otigt. Markt¨
ubliche PMS zeigen allerdings genau auf diesem Gebiet große Einschr¨
an-
kungen, was die M¨
achtigkeit der Darstellung, ihre Konfigurierbarkeit, die Interaktions-
m¨
oglichkeiten, View-Bildung und allgemein ihre Gebrauchstauglichkeit angeht.
Warum Prozess-Management?
Heute gibt es viele Gr¨
unde [RD00], die vorhandenen Strukturen und Prozesse in Unter-
nehmen zu erfassen, zu analysieren und zu optimieren. Einige sind die Verbesserung der
Produktqualit¨
at oder der Wirtschaftlichkeit und die Reduzierung der Zeit zwischen Pro-
duktzyklen. Hierbei auf die Unterst¨
utzung durch rechnergest¨
utzte Werkzeuge zu setzen,
liegt auf der Hand. Diese helfen bei der Modellierung und Analyse von Arbeitsabl¨
aufen.
Eine hochgradige Arbeitsteilung impliziert naturgem¨
aß die Gefahr von Reibungsverlus-
ten. Daher ist die Optimierung der Abl¨
aufe unumg¨
anglich. Dieser Optimierungsprozess
kann durch Rechnersysteme gest¨
utzt werden. PMS sorgen daf¨
ur, dass die n¨
otige Koordi-
nierungsarbeit, die einen Overhead darstellt, nicht so groß wird, dass die Synergieeffekte
durch die Arbeitsteilung nicht in großen Teilen wieder zunichte gemacht werden. Arbeits-
teilung hat also nicht nur positive Effekte, denn f¨
ur den Einzelnen ist der Zusammenhang
seiner Teilaufgabe mit dem Gesamtprozess oft nicht mehr erkennbar. Die Optimierung von
Gesch¨
aftsprozessen endet beispielsweise oft an Abteilungsgrenzen. Es besteht auch die Ge-
fahr, dass eine Teilaufgabe zum reinen Selbstzweck wird. Nach dem britischen Historiker
1
1. Einleitung
Cyril Northcote Parkinson [Park05], der sich mit der B¨
urokratie der britischen Admiralit¨
at
besch¨
aftigte, bl¨
ahen sich Aufgaben selbstst¨
andig soweit auf, bis sie die ganze verf¨
ugbare
Zeit ausf¨
ullen.
Notwendigkeit von m¨
achtigen Visualisierungskonzepten
Aufgebl¨
ahte Abl¨
aufe machen Unternehmen unbeweglich. Der hohe Wettbewerbsdruck er-
fordert jedoch rasche Anpassung an ver¨
anderte Rahmenbedingungen. D. h. es ist erw¨
unsch-
tes Ziel, dass ein PMS ein Unternehmen in die Lage versetzt, Prozesse zu verschlanken,
zu optimieren, und Gesch¨
aftsprozesse st¨
andig anzupassen und zu ¨
andern (siehe Schema-
Evolution [RD98]). Optimal w¨
are, wenn s¨
amtliche betriebliche Abl¨
aufe durchg¨
angig rech-
nergest¨
utzt abgebildet werden. Ein positiver Nebeneffekt liegt im dadurch verbesserten
Wissensmanagement [Jabl01]. Mit dem Ausscheiden von Mitarbeitern verlieren Unterneh-
men das oftmals nur implizite Wissen ¨
uber Abl¨
aufe. Ein Großteil dieses Wissens kann in
PMS gespeichert und verwaltet werden.
Ein PMS kann als Informationssystem aufgefasst werden. Die Benutzerschnittstelle eines
solchen Systems muss in der Lage sein, seinen Anwendern m¨
achtige Hilfsmittel zur Seite zu
stellen, die es trotz großer Informationsmengen erlauben, schnell und effizient die gesuchten
Informationen zu finden. Die L¨
osung hierf¨
ur sind leistungsf¨
ahige, an die jeweilige Aufgabe
angepasste Visualisierungen. Die Herausforderung liegt darin, trotz den zwischen komple-
xen Ablaufpl¨
anen bestehenden logischen Abh¨
angigkeiten und komplizierten Datenfl¨
ussen,
dem Anwender zu erm¨
oglichen, den n¨
otigen ¨
Uberblick zu verschaffen.
Zum Detailgrad der Abbildung von Abl¨
aufen in Prozessen
Die Entwicklung von neuen Arbeitsprozessen ist sehr aufwendig. Es gilt, die richtige Gra-
nularit¨
at zu finden, in der Arbeitsabl¨
aufe im PMS abgebildet werden. Dabei gibt es zwei
Extremf¨
alle. Eine sehr grobk¨
ornige Abbildung zerlegt einen Prozess nur in die notwen-
digsten Schritte. Das andere Extrem ist eine feink¨
ornige Abbildung, die f¨
ur jeden noch so
kleinen Arbeitsschritt eine separate Aktivit¨
at vorsieht.
Der Vorteil einer hohen Aufl¨
osung liegt darin, dass sehr viel Wissen ¨
uber die Abl¨
aufe im
System gespeichert werden kann. Eine feink¨
ornige Einteilung aber erh¨
oht den Aufwand f¨
ur
die Erstellung und sp¨
atere Anpassungen. Außerdem w¨
achst mit h¨
oherem Detaillierungs-
grad die Anzahl der Aktivit¨
aten eines Prozesses und damit die Anzahl der Eintr¨
age in
den Arbeitslisten der Bearbeiter, was sie dann auch f¨
ur kleine Routineaufgaben an den
Bildschirm zwingt.
Relativ grobk¨
ornige Aufl¨
osungen haben den Vorteil, dass die resultierenden Darstellungen
eine geringere Komplexit¨
at aufweisen. Eine ¨
ubersichtliche Visualisierung gelingt bei weni-
ger komplexen Prozessen nat¨
urlich leichter. F¨
ur sp¨
atere Prozess¨
anderungen reduziert sich
der Aufwand.
Der Zielkonflikt zwischen Granularit¨
at und Anpassbarkeit ließe sich zumindest f¨
ur den
Anwender abmildern, indem zwischen verschiedenen manuellen Prozessschritten unter-
schieden wird: Zwischen solchen, die in den Arbeitslisten auftauchen und solchen, die nur
der detaillierteren Beschreibung des Arbeitsablaufs dienen. Geeignete Ansichten verbergen
dann bei Bedarf die Details.
2
1.2. Das Ziel
1.2. Das Ziel
Diese Arbeit setzt sich mit der Frage auseinander, wie Prozessdaten aus PMS visualisiert
werden k¨
onnen. Es wird aufgezeigt, welche M¨
oglichkeiten bestehen, um:
➣Prozessinformationen grafisch aufzubereiten
➣Prozessinformationen mit ver¨
anderter Strukturierung darzustellen
Außer Optimierungen der grafischen Repr¨
asentation kann also versucht werden, die Pro-
zessinformationen aus einer anderen Sichtweise zu betrachten. Damit ist die Darstellung
eines Prozesses nicht mehr auf die Struktur festgelegt, in der er modelliert wurde.
Weiterhin wird gezeigt, wie Prozessinformationen mit organisatorischen Strukturdaten
(Organisationsmodell) angereichert werden. Ein weiteres Ziel besteht darin, m¨
oglichst vie-
le zusammenh¨
angende Informationen aus den verf¨
ugbaren Prozessdaten zu extrahieren.
Dabei bildet die Anzeige von Prozessdaten also die reine Visualisierung und nicht deren
Editieren, den Fokus. Nat¨
urlich sind ad¨
aquate Visualisierungsformen von Prozessen die
Grundvoraussetzung, um diese effektiv bearbeiten/editieren zu k¨
onnen.
Durch die in den letzten Jahren steigende Bedeutung von Benutzerschnittstellen als An-
satzpunkt f¨
ur Verbesserungen bei Produktivit¨
at und Nutzerakzeptanz gewinnen Usability-
Betrachtungen mehr und mehr Gewicht. Entsprechende Aspekte sowie Erkenntnisse der
Kognitionsforschung k¨
onnen als Basis dienen, um an die Bed¨
urfnisse der Benutzer ange-
passte Visualisierungskonzepte zu entwickeln.
Ausgangspunkt der nachfolgenden Betrachtungen ist ein Architekturmodell wie es Abbil-
dung 1.1 zeigt. Eine Prozessvisualisierungskomponente greift auf eine globale Datenbasis
mit Prozessinformationen aus einem heterogenen Verbund prozessorientierter Informati-
onssysteme zu. Das in der Abbildung gezeigte Process-Warehouse integriert Prozessdaten,
die teilweise auf unterschiedlichen Prozess-Metamodellen basieren. Im Idealfall speichert
diese Datenbank auch die passenden Organisationsmodelle.
Diese Arbeit leistet Vorarbeiten f¨
ur die Implementierung einer Prozessvisualisierungskom-
ponente. Eine solche Komponente basiert auf einem Prozess-Metamodell. Dies wird hier
nicht explizit festgelegt, denn im praktischen Einsatz ist es nicht sinnvoll, auf ein starres
Modell zu setzen. Andernfalls w¨
are die Darstellung von Prozessen, die auf komplexeren
Prozessmodellen basieren, eingeschr¨
ankt. Die hier vorgestellten Visualisierungskonzepte
sind daher weitgehend unabh¨
angig von den Ausdrucksm¨
oglichkeiten des zugrunde gelegten
Prozess-Metamodells. Erst f¨
ur die tats¨
achliche Implementierung der Visualisierungskom-
ponente ist es notwendig, genauere Modelldetails, wie darzustellende Kantentypen oder
unterst¨
utzte Verzweigungen festzulegen.
Vision dieser Diplomarbeit ist es aus (Gesch¨
afts-) Prozessen das enthaltene Wissen zu
extrahieren und falls m¨
oglich, mit Wissen aus einem Organisationsmodell angereichert auf
vielf¨
altige Weisen darzustellen.
Eine Visualisierungskomponente ist im ¨
ubrigen keine Monitoring-Komponente, wenngleich
sich sicherlich einige Funktionen ¨
uberschneiden k¨
onnen. Diese Abgrenzung ist notwendig,
da diese beiden Anwendungstypen teilweise gegens¨
atzliche Zielsetzungen haben. Ziel von
Monitoring ist in erster Linie die Analyse laufender Prozessinstanzen. Hierzu dient die
3
1. Einleitung
Prozessviewer-
Komponente
Process-Warehouse
PMS ’A’ PMS ’C’PMS ’B’
Prozessinformationen Organisationsmodelle
Abbildung 1.1.: Architekturmodell Process-Warehouse
(Echtzeit-)Erfassung von aussagekr¨
aftigen Kennzahlen ¨
uber Durchsatzzeiten, Kostenent-
wicklungen und ¨
Ahnliches. Dadurch lassen sich fr¨
uhzeitig Flaschenh¨
alse bei der Prozess-
ausf¨
uhrung erkennen. Das Ziel von Visualisierung ist die ansprechende und ¨
ubersichtliche
Darstellung einzelner Prozess-Modelle oder -Instanzen. ¨
Uberschneidungen zum Monitoring
ergeben sich, wenn ¨
Ubersichtsdarstellungen vieler Prozesse erzeugt werden.
Gliederung
Hauptgegenstand dieser Arbeit bilden Visualisierungskonzepte f¨
ur Prozessdaten. Diese bil-
den das Herz einer k¨
unftigen Prozessvisualisierungskomponente. In Kapitel 2wird zun¨
achst
eine ¨
Ubersicht dazu gegeben, auf welche Arten Prozesse visualisiert werden k¨
onnen und
welche Prozessinformationen auftreten. Daran schließt sich eine Einf¨
uhrung ¨
uber Ans¨
atze
zu Visualisierungskonzepten von Prozessdaten an. Es folgt eine Anforderungsanalyse in
Kapitel 3. Hier werden m¨
ogliche Benutzer einer Prozessvisualisierungskomponente kate-
gorisiert. Die jeweilige Benutzergruppe ist durch spezifische Motivationen oder Benutzer-
ziele charakterisiert. Die Entwicklung und Systematisierung von Visualisierungskonzepten
beginnt also mit der Analyse der Anforderungen der typischen Benutzer in einem Pro-
zessumfeld. Kapitel 4wirft einen Blick auf bereits am Markt erh¨
altliche Programme und
die dort anzutreffenden Visualisierungsl¨
osungen sowie auf den Stand der Forschung in den
Bereichen Visualisierung, Usability, Wahrnehmungsforschung und Interface-Design. Den
Kern der Arbeit, die Visualisierungskonzepte, bilden die zwei folgenden Kapitel. Es geht
einerseits um grafische Aspekte und andererseits um Darstellungsformen. Beide Kapitel
verfolgen unterschiedliche Ans¨
atze zur Verbesserung der Prozessvisualisierung, deren Er-
gebnisse sich f¨
ur die endg¨
ultige Darstellung kombinieren lassen. Kapitel 5widmet sich der
Frage, wie man durch ¨
Anderungen an der grafischen Darstellung, also durch Ver¨
anderung
4
1.3. Motivation
von Farben, Formen und Symbolen Ansichten erzeugen kann, die auf die Belange der Be-
nutzer zugeschnitten sind und ihnen ¨
ubersichtlich das pr¨
asentieren, was in der aktuellen
Situation sinnvoll ist. Zudem kommen die in Kapitel 4zusammengef¨
uhrten Erkenntnis-
se aus der Kognitions-, Wahrnehmungs- und Usability-Forschung zur Anwendung, um
Informationsdarstellungen zu finden, die der menschlichen Wahrnehmung m¨
oglichst gut
entsprechen. Die besprochenen grafischen Aspekte werden im Kapitel 6wieder aufgegrif-
fen. Eine Visualisierungskomponente f¨
ur Prozessinformationen sollte eine m¨
oglichst breite
Palette an Darstellungsm¨
oglichkeiten der Daten bieten. In Kapitel 6werden verschiedene
Ansichten f¨
ur Prozessdaten behandelt. Bei jeder Darstellungsform bildet jeweils ein Aspekt
aus den verf¨
ugbaren Prozessinformationen den Fokus der Darstellung. Insbesondere wer-
den die entwickelten Ansichten hinsichtlich Restriktionen und spezifischer Probleme (z. B.
bez¨
uglich Layout) untersucht. Kapitel 7beschreibt m¨
ogliche Benutzerinteraktionen auf
Prozessdarstellungen, z. B. Historiendarstellung oder Navigation in Prozessen. Auch auf
die View-Bildung wird eingegangen, die ein m¨
achtiges Konzept darstellt unterschiedliche
Sichten auf einen Prozess zu erm¨
oglichen. Den Abschluss bildet Kapitel 8mit Anmerkun-
gen ¨
uber offene Fragen und einem Fazit. Als roter Faden und Bewertungskriterium dient
die Frage nach der Gebrauchstauglichkeit und die Anwendung von Erkenntnissen aus der
Wahrnehmungsforschung.
1.3. Motivation
Ein Ziel dieser Arbeit ist es, die ¨
ublichen Prozessgraphdarstellungen zu verbessern. Ab-
bildung 1.2 zeigt einen Ausschnitt aus einem Change-Management-Prozess in Business
Process Management Notation (BPMN) [Bpmi03a]. Die Darstellung zeigt verschiedene un-
tereinander verbundene Objekte: Aktivit¨
aten, Ausf¨
uhrungseinheiten, Systeme und Do-
kumente. Jeder Objekttyp hat eine eindeutige Form und Farbe. Die schwarzen Kanten
zwischen den Aktivit¨
aten und die hellgrauen Kanten f¨
ur Ausnahmebehandlungen bilden
den Kontrollfluss ab. Die Aktivit¨
aten am oberen Rand zeigen den Elternprozess. Schon in
diesem kleinen Ausschnitt erscheint die Darstellung sehr un¨
ubersichtlich.
Abbildung 1.3 zeigt den gleichen Prozess, es wurden jedoch viele Verbesserungsvorschl¨
age
eingearbeitet, die in dieser Arbeit gemacht werden. Durch die Integration der verschie-
denen Objekte zu einem Aktivit¨
atenknoten reduziert sich die Anzahl von Symbolen und
Farben. Die Struktur des Prozesses ist leichter erfassbar. Um die ¨
Ubersichtlichkeit weiter
zu steigern, wurde der Elternprozess ausgeblendet und die Dokumente an den oberen Rand
verschoben. Die gesamte Darstellung wirkt ruhiger und aufger¨
aumter.
¨
Ublicherweise werden Informationen ¨
uber Prozesse als Prozessgraphen dargestellt. Diese
stellen aber nur eine m¨
ogliche Darstellungsform von Prozessinformationen dar. Denn außer
der Optimierung der grafischen Repr¨
asentation ist die Zielsetzung dieser Arbeit, die in den
Prozessdaten enthaltenen Informationen zu nutzen, um dem Benutzer auch alternative
Darstellungsformen anzubieten. So lassen sich Zeitinformationen nutzen, um einen Prozess
in Form einer Kalenderansicht darzustellen.
5
1. Einleitung
request
comments
CR
manager
provide
comments
planning
expert
construction
expert
quality
expert
provide
comments
provide
comments
approve CR
CR approval
board
commenting approval
CR modification
required
CR infeasible
change
request
eval-
uation
change
request
eval-
uation
planning
expert
provide
comments
CR
manager
request
evaluation provide
evaluation
planning
expert
purchase
expert
quality
expert
provide
evaluation
provide
evaluation
purchase
system
planning
system
evaluation
CR infeasible
CR modification
required
expertise
evaluation
(planning)
evaluation
(purchase)
evaluation
(quality)
change
request
Abbildung 1.2.: Beispielprozess Change Management – Ausschnitt alte Version
6
1.3. Motivation
change
request eval-
uation
expertise evaluation
(planning) evaluation
(purchase) evaluation
(quality)
change
request
CR modification
required
CR infeasible
CR infeasible
CR modification
required
request
evaluation
App
CR
manager
Role
provide
evaluation
App
planning
expertRole
planning
system
provide
evaluation
App
purchase
expertRole
planning
system
provide
evaluation
App
quality
expertRole
request
comments
App
CR
manager
Role
provide
comments
App
planning
expertRole
provide
comments
App
planning
expertRole
provide
comments
App
construction
expertRole
provide
comments
App
quality
expertRole
approve CR
App
CR approval
boardRole
Abbildung 1.3.: Beispielprozess Change Management – Ausschnitt neue Version
7
2
Grundlagen und Einführung
Dieses Kapitel f¨
uhrt in das Thema Prozessvisualisierung ein. Daher wird zun¨
achst darauf
eingegangen, aus welchen Einzelinformationen Prozessdaten bestehen und wie sie struktu-
riert sind. Anschließend wird darauf eingegangen, welche Darstellungsarten f¨
ur Prozesse
ben¨
otigt werden. Prozesse k¨
onnen beispielsweise zur Laufzeit mit Ausf¨
uhrungszust¨
anden
oder nur als schematisches Modell dargestellt werden. Einzelne Prozesse k¨
onnen darge-
stellt werden oder Gruppen von Prozessen. Am Ende des Kapitels wird die grunds¨
atzliche
Idee vorgestellt, wie sich die Prozessvisualisierung verbessern l¨
asst und auf welchem Weg
ein umfassendes Konzept f¨
ur die Aufbereitung von Prozessdaten gefunden werden kann.
2.1. Visualisierung von Prozessdaten
F¨
ur die Prozessvisualisierung erscheint es unerheblich, wie die im Prozesskontext vorkom-
menden Informationen zusammenh¨
angen oder in welcher Form sie gespeichert sind.
Aus dem Szenario einer unternehmensweiten Prozesshierarchie, mit Prozessen, die von
unterschiedlichen PMS verwaltet werden, ergeben sich f¨
ur eine Visualisierungskomponente
wichtige Punkte. F¨
ur den Benutzer soll es transparent sein, auf welchem PMS die Prozesse
laufen. Weiterhin soll der Benutzer in großen Prozessen navigieren k¨
onnen.
Am Anfang der Visualisierung steht die Frage, aus welchen Daten Prozessinformationen
bestehen und welches explizit darin kodierte Wissen wie dargestellt werden soll.
Mindestanforderung f¨
ur die Visualisierung von Prozessen sind:
➣Prozessmodell
➣Datenmodell
➣Visualisierungsmodell
9
2. Grundlagen und Einf¨
uhrung
Optionale Informationen sind Strukturdaten wie Organisationsmodelle. Ein Process-Ware-
house kann die Prozessinformationen zu Prozess-, Daten- und Organisationsmodell sam-
meln und f¨
ur die Visualisierung bereitstellen (siehe Abbildung 2.1).
Daten aus Process-Warehouse
Prozessmodell Datenmodell Organisations-
modell
Konfiguration der
Viewerkomponente
Visualisierung Visualisierungs-
modell
Abbildung 2.1.: Schematischer Ablauf der Prozessvisualisierung
Das Prozess-(Meta)Modell gibt den Rahmen vor, wie Prozesse modelliert werden k¨
onnen.
Es legt fest, welche Arten von Verkn¨
upfungen es zwischen Aktivit¨
aten gibt. Es definiert,
welche Ausf¨
uhrungszust¨
ande es gibt und legt fest, wie ein- und ausgehende Datenfl¨
usse
modelliert werden. Das Datenmodell legt die Attribute fest, die in Aktivit¨
aten hinterlegt
werden.
Das Visualisierungsmodell geh¨
ort nicht zu den Prozessdaten, sondern es legt das Aussehen
ihrer Visualisierungsdaten fest. Ein wesentliches Merkmal des Visualisierungsmodells be-
steht darin, dass es nicht statisch ist. Vielmehr liegt das Augenmerk auf der Anpassbarkeit
f¨
ur die jeweiligen Benutzer. Es ist auch nicht statisch, sondern l¨
asst sich an die Bed¨
urfnisse
der Benutzer anpassen.
Einem Prozess liegt ein Schema zugrunde. Zur Definition eines solchen Schemas geh¨
ort die
Beschreibung eines Netzplanes, der aus Knoten (Aktivit¨
aten) und Kanten (Weiterschal-
tungslogik) besteht. Weiterhin besitzt ein Schema verschiedene Attribute (z. B. Prozess-
verantwortlicher, Start-/Endzeit oder zugeordnetes Produkt/Objekt).
Das Datenmodell legt fest, welche zugeordneten Attribute ein Schema enth¨
alt. Einigen
dieser Attribute werden erst dann Werte zugeordnet, wenn ein Prozess ausgef¨
uhrt bzw.
instanziiert wird.
Instanziierte Prozesse werden Instanzen genannt. Das PMS ¨
ubernimmt die Koordination
¨
uber die Ausf¨
uhrung der Instanzen.
Nach dieser kurzen Einf¨
uhrung in die Struktur der Prozesse ist noch anzumerken, dass die
Aktivit¨
aten in den Prozessen wiederum ganze Prozesse kapseln k¨
onnen, auf diese Art und
Weise und auch durch Spr¨
unge im Kontrollfluss zu anderen Prozessen entstehen hierarchi-
sche Workflows.
2.1.1. Prozessinformationen
Viele Informationen eines Prozesses stecken in seinen Aktivit¨
aten. Und diese Aktivit¨
aten
sind letztlich Datenstrukturen, die Attribute haben wie Name der Aktivit¨
at, Beschrei-
10
2.1. Visualisierung von Prozessdaten
bungstext, Start-/Endzeit, Frist (engl. Deadline), Kosten und ¨
Ahnliches. Weiterhin werden
jeder Aktivit¨
at Objekte mit Dokumenten und Daten, Ressourcen und eine oder in Sonder-
f¨
allen auch mehrere Ausf¨
uhrungseinheiten zugeordnet (z. B. bei Abstimmungen oder dem
Vieraugenprinzip).
Der Kontrollfluss bildet die Ausf¨
uhrungsabfolge der einzelnen Aktivit¨
aten ab. Er ist expli-
zit durch die Struktur des Netzplanes definiert. In den Kanten sind (durch die Kantenty-
pen) alle weiteren Informationen gespeichert, um den Rest des Kontrollflusses abzubilden,
zum Beispiel bedingte Verzweigungen, Synchronisierungskanten, Schleifen und Ausnahme-
behandlungen.
Die Informationen ¨
uber die Dokumente und Daten bilden den Datenfluss. Er ist je nach
verwendetem Metamodell implizit oder explizit modelliert. Wenn der Datenfluss implizit
gegeben ist, werden die ein- und ausgehenden Dokumente der Aktivit¨
aten im Hinblick auf
den Kontrollfluss ausgewertet.
Die Aktivit¨
aten werden selten komplett mit allen dazugeh¨
origen Informationen darge-
stellt, da dies zu un¨
ubersichtlich w¨
are. Dem Benutzer wird nur das angezeigt, was er
aktuell zur Erreichung seines Zieles ben¨
otigt. Dies impliziert eine flexible Konfigurierbar-
keit der Darstellung. Der Name einer Aktivit¨
at wird nahezu immer angezeigt, alle anderen
Prozessinformationen sind mehr oder weniger optional.
Die Prozessinformationen setzen sich also aus folgenden Einzelteilen zusammen, die ¨
uber
die Visualisierung letztendlich zug¨
anglich sein sollen:
➣Aktivit¨
aten
Der Benutzer soll erkennen k¨
onnen, aus welchen Aktivit¨
aten sich ein Prozess
zusammensetzt.
➣Objekt Ausf¨
uhrungseinheit
Jeder Aktivit¨
at ist eine ausf¨
uhrende Einheit zugeordnet (in Spezialf¨
allen,
wie dem 4-Augenprinzip oder Abstimmungen, auch mehrere). Dieser Bear-
beiter der Aktivit¨
at kann ein Individuum, ein automatisches System, eine
Rolle/Funktion und/oder eine Organisationseinheit sein.
➣Objekt Ressourcen
Jeder Aktivit¨
at sind Ressourcen zugeordnet, z. B. Applikationen und Syste-
me, die w¨
ahrend der Ausf¨
uhrung der Aktivit¨
at verwendet werden.
➣Objekt Dokumente/Daten
Jeder Aktivit¨
at sind ein- und ausgehende Datenverbindungen zu Datenban-
ken oder Dokumenten zugeordnet, auf die w¨
ahrend der Ausf¨
uhrung der Ak-
tivit¨
at zugegriffen wird. Es ist Aufgabe des Metamodells dabei Unterscheid-
barkeit herzustellen zwischen Daten die f¨
ur jede Instanz extra anfallen (lokale
Dokumente oder Daten) und globale Daten auf die jede Instanz zugreift.
➣Kontrollfluss
Abfolge der Aktivit¨
aten, Informationen ¨
uber bedingte Ausf¨
uhrung, Schleifen,
Ausnahmen (engl. exceptions), Aufrufe von anderen Prozessen in hierarchi-
schen Prozessen (Verweise/Spr¨
unge zu anderen Prozessen) und Synchronisa-
tionsinformationen (Synchronisationskanten).
11
2. Grundlagen und Einf¨
uhrung
➣Datenfluss
Der Datenfluss ist meist durch den Kontrollfluss implizit definiert. Er zeigt
den Weg der Daten und Dokumente durch den Prozess.
➣Aktivit¨
atenattribute aus dem Datenmodell
Den Aktivit¨
aten werden verschiedene Attribute, z. B. Zeitangaben, Priorit¨
at,
Kosten, usw. zugeordnet.
➣Prozessattribute aus dem Datenmodell
Auch Prozesse haben diverse Attribute, wie z. B. Zeitangaben, Prozessver-
antwortlicher, ein zugeordnetes Produkt oder Objekt, u. a.
➣Zusammenh¨
ange
Zwischen allen genannten Informationen bestehen auch Zusammenh¨
ange, die
nicht explizit kodiert sind, die jedoch implizit mit in den Prozessinformatio-
nen stecken. Hierf¨
ur gilt es Werkzeuge zu entwickeln, die diese Zusammen-
h¨
ange sichtbar machen k¨
onnen.
Hinter der Information zur Ausf¨
uhrungseinheit muss nicht zwangsl¨
aufig ein menschlicher
Bearbeiter stecken. Prozessschritte k¨
onnen sich auf manuelle T¨
atigkeiten oder auf automa-
tische Abl¨
aufe beziehen. Es existieren die folgenden vier Arten von Ausf¨
uhrungseinheiten
[WfMC99]:
➣System
Ein automatisches System ist f¨
ur den Prozessschritt verantwortlich, dies kann
ein Computersystem oder eine Maschine sein.
➣Person
Meist sind die Ausf¨
uhrungseinheiten Mitarbeiter. Selten wird einer Aktivit¨
at
direkt eine bestimmte Person zugeordnet. Oft wird der einer Aktivit¨
at zuge-
ordnete Bearbeiter indirekt adressiert, z. B. ¨
uber seine Rolle oder Funktion
und/oder die Organisationseinheit, der er angeh¨
ort. Im Folgenden wird nicht
mehr zwischen System und Person unterschieden, der Einfachheit halber wird
nur von Bearbeitern gesprochen.
➣Rolle (Funktion)
Eine Ausf¨
uhrungseinheit kann ¨
uber eine im Organisationsmodell enthaltene
Rolle beschrieben werden. Alternativ k¨
onnen auch Fertigkeiten oder Attribu-
te aufgelistet sein, die die Person erf¨
ullen muss, damit das PMS dementspre-
chend eine Person ausw¨
ahlt, die diese Aktivit¨
at ausf¨
uhren soll. Eine Rolle
ist eine Funktion, die eine Person innerhalb einer Organisation innehat. Hier
geschieht bei der Beschreibung der Ausf¨
uhrungseinheit einer Aktivit¨
at kei-
ne konkrete Zuordnung zu einer Person. Es ist die Aufgabe des PMS, zur
Laufzeit eine konkrete Zuordnung zu bestimmen. Es kann auch ein Koordi-
nator definiert werden, der benachrichtigt wird, falls die Zuordnung zu einer
konkreten Person durch das PMS scheitern sollte, weil z. B. alle m¨
oglichen
Bearbeiter momentan belegt sind. Meist geschieht die Zuordnung zur Lauf-
zeit durch das PMS nicht konkret, sondern alle zur Ausf¨
uhrung in Frage
kommenden Personen erhalten den Eintrag zur Ausf¨
uhrung dieser Aktivit¨
at
in ihrer Arbeitsliste. Der Erste, der diese Aktivit¨
at dann tats¨
achlich ¨
uber-
12
2.1. Visualisierung von Prozessdaten
nimmt, wird Bearbeiter. Bei allen anderen wird der Eintrag wieder aus der
Arbeitsliste entfernt.
➣Organisationseinheit
Organisatorischen Einheiten wie Abteilungen k¨
onnen Prozessschritte zuge-
ordnet sein, in diesem Fall bekommen alle Mitglieder dieser Organisations-
einheit die T¨
atigkeit in ihre Arbeitsliste, bis der Erste den Auftrag annimmt.
Alternativ kann auch der Abteilungsleiter die Aktivit¨
at zugeteilt bekommen,
um sie an eine bestimmte Person zu delegieren.
Die Angabe einer Rolle als Ausf¨
uhrungseinheit hat den Vorteil, dass die Zuweisung von
Aufgaben effizienter geschehen kann als bei einer konkreten Personenzuordnung. Denn
Rollen sind in einer Organisation meist nicht eindeutig einer Person, sondern einer Gruppe
von Personen mit denselben F¨
ahigkeiten zugeordnet. Somit kann z. B. die Person mit
der geringsten Arbeitsbelastung die Aktivit¨
at oder Aufgabe zugeordnet bekommen. Bei
Krankheit oder anders bedingten Ausf¨
allen ger¨
at die Ausf¨
uhrung des Prozesses so nicht ins
Stocken, da nicht nur eine Person zur Ausf¨
uhrung in Frage kommt. In solchen F¨
allen ist es
aber trotzdem sinnvoll, wenn das Organisationsmodell auch Vertreter f¨
ur Personen oder
Rollen definiert. Erw¨
ahnenswert ist in diesem Zusammenhang der Worst-Case, wenn alle
Vertreterregelungen fehlschlagen. Dann muss das Schema des Prozesses mit Techniken der
Schema-Evolution [Rind04] im laufenden Betrieb ge¨
andert werden. Auch so etwas sollte
langfristig direkt in einer Prozessvisualisierungskomponente erm¨
oglicht werden.
Außer einer expliziten Rollenangabe ist es in vielen Systemen auch m¨
oglich, den sp¨
ateren
Bearbeiter durch einen Satz von F¨
ahigkeiten zu beschreiben, welche f¨
ur die Bearbeitung
der Aufgabe notwendig sind. Es ist dann Aufgabe des PMS, die Zuordnung zu einer Rolle
durchzuf¨
uhren.
Bei der Visualisierung eines laufenden Prozesses kann dem Benutzer die Ausf¨
uhrungs-
einheit auf drei unterschiedliche Weisen repr¨
asentiert werden. Je nach Erfordernis: als
konkrete Personenzuordnung, als Rolle oder als Zugeh¨
origkeit des Bearbeiters zu einer
Organisationseinheit. Der letzte Fall ist besonders dann interessant, wenn von Interesse
ist, welche Teile eines Prozesses, also welche Aktivit¨
aten, welchen unterschiedlichen Orga-
nisationseinheiten zugeordnet sind.
Wo der Benutzer die konkrete Personenzuordnung als Ausgabe w¨
unscht, kann es den Fall
geben, dass bei noch nicht gestarteten Aktivit¨
aten als Ausf¨
uhrungseinheit eine Rolle oder
eine Organisationseinheit angegeben ist. Falls nun diese Vorgaben durch das Organisati-
onsmodell nicht eindeutig einer Person zuordenbar sind, muss auf die Ausgabe der Rolle
zur¨
uckgegriffen werden, bis das PMS eine konkrete Zuordnung vorgenommen hat.
Da eine Visualisierungskomponente nicht nur Instanzen darstellen k¨
onnen soll, sondern
auch Prozessschemata, muss klar sein, welche Informationen schon vor der Instanziierung
zur Anzeige zur Verf¨
ugung stehen. Tabelle 2.1 (→S. 14) zeigt eine Auflistung der wich-
tigsten Prozessinformationen. Die Tabelle ist unterteilt in Informationen, die schon in
einem Prozessschema gespeichert sein k¨
onnen und in Informationen die erst zur Laufzeit
bestimmt werden. Letztlich sind aber erst nach Beendigung eines Prozesses alle instanz-
spezifischen Informationen komplett verf¨
ugbar. Die Attribute und die Objekte von Akti-
vit¨
aten sind in der Tabelle zur besseren Unterscheidung noch einmal besonders mit ’ATT
’ oder ’OBJ ’ markiert.
13
2. Grundlagen und Einf¨
uhrung
Informationsaspekte Beschreibung und Beispiele
Verf¨
ugbare Informationen eines Schemas
ATT Aktivit¨
atenname (kurzer) Name, der die Funktion der Aktivit¨
at
beschreibt.
OBJ Ausf¨
uhrungseinheiten hier typischerweise nur Rolle, Funktion oder
Organisationseinheit, keine Personen oder
Systeme
OBJ Systeme F¨
ur die Ausf¨
uhrung der Aktivit¨
at ben¨
otigte
Systeme und Applikationen
OBJ Dokumente und Daten lesende und schreibende Datenbankzugriffe oder
beteiligte Dokumente
ATT Aktivit¨
atenbeschreibungstext N¨
ahere textuelle Beschreibung der Aktivit¨
at
ATT Zeiten (aktivit¨
atsbezogene) typische Dauer, Fristen, sp¨
atester Startzeitpunkt
ATT Kategorie Einteilung der Aktivit¨
aten in semantische Klassen
wie z. B. Ablaget¨
atigkeit oder konzeptionelle
T¨
atigkeit
ATT andere weitere vom Datenmodell abh¨
angige
Aktivit¨
atenattribute, z. B. Fixkosten
Kontrollflussaz. B. Ausf¨
uhrungsbedingungen bei alternativen
Verzweigungen
Verf¨
ugbare Informationen einer Instanz
OBJ Zugeordnetes Produkt oder
Objekt
Produkte, z. B. verschiedene Fahrzeugmodelleb
OBJ Zugeordneter Kunde Verschiedene Unternehmenskundenc
OBJ Ausf¨
uhrungseinheiten typischerweise Personen oder auch (automatische)
Systeme oder Organisationseinheit [Team,
Projekt, (Arbeits-)Gruppe, Abteilung,
Unternehmen, Organisation]
OBJ Prozessverantwortlicher Person, die die Verantwortung ¨
uber die
Prozessinstanz hat
ATT Zeiten (aktivit¨
atsspezifische) tats¨
achliche Start-/Endzeit, Bereitzeit
ATT Zeiten (instanzspezifische) Start-/Endzeit
ATT andere weitere vom Datenmodell abh¨
angige
Aktivit¨
atenattribute, z. B. aktuelle Kosten
aDer Kontrollfluss ist weder Objekt, noch Attribut von Aktivit¨
aten. Aktivit¨
aten werden durch den Kon-
trollfluss verbunden
bDiese Information ist f¨
ur Multi-Instanz-Darstellungen wichtig, um die Instanzen nach Produkt gruppieren
zu k¨
onnen
cDiese Information ist f¨
ur Multi-Instanz-Darstellungen wichtig, um die Instanzen nach Kunden gruppieren
zu k¨
onnen
Tabelle 2.1.: ¨
Ubersicht ¨
uber die Prozessinformationen
Wenn in dieser Arbeit von Aktivit¨
at die Rede ist, ist meist nur der Name der Aktivit¨
at
gemeint – also der Aktivit¨
atsbezeichner – nicht das gesamte Datenobjekt mit zugeordneten
Attributen. Ein anderweitiger Gebrauch des Wortes ist aus dem Kontext ersichtlich.
Eine sehr wichtige Feststellung ist, dass der eine Teil der Prozessinformationen aktivit¨
aten-
und der andere instanzspezifisch ist. Aktivit¨
atsspezifische Informationen sind immer mit
Aktivit¨
aten verkn¨
upft. Die instanzspezifischen Informationen sind dagegen mit einer In-
14
2.1. Visualisierung von Prozessdaten
stanz verkn¨
upft. Nur die Prozessattribute aus dem Datenmodell aus der obigen Auflistung
sind instanzspezifische Informationen, alle anderen sind aktivit¨
atsspezifisch. Erstaunlicher-
weise lassen sich diese beiden verschiedenen Arten von Prozessinformationen nun in den
verschiedenen Darstellungskonzepten nicht mischen. Entweder ist eine Darstellung auf die
Aktivit¨
aten hin ausgerichtet oder auf die Instanzinformationen. Eine Prozessgraphdarstel-
lung ist beispielsweise auf die Aktivit¨
aten ausgerichtet und in der resultierenden Darstel-
lung ist eigentlich kein Platz f¨
ur den Prozessverantwortlichen, das zugeordnete Produkt
oder Objekt oder die Startzeit.
B
Bedingung Y
Bedingung X
C
D
Ausgangssituation
Fall 1: Zuordnung zu Startaktivität
A
A
A → B
Fall 2: Zuordnung zu Zielaktivität
A
B
B
C
D
C
D
B → C unter
Bedingung X
B → D unter
Bedingung Y
B → C unter
Bedingung X
B → D unter
Bedingung Y
A → B
Abbildung 2.2.: M¨
oglichkeiten der Zuordnung von Kontrollfluss-Informationen zu Aktivit¨
aten
Die Darstellung des Kontrollflusses ist ein Problem bei Visualisierungsformen, die den
Kontrollfluss nicht in Form von (beschrifteten) Kanten darstellen k¨
onnen, beispielswei-
se bei Tabellen, die nur Aktivit¨
aten auflisten. Wie Abbildung 2.2 zeigt, k¨
onnen diese
15
2. Grundlagen und Einf¨
uhrung
Kontrollfluss-Informationen den Aktivit¨
aten zugeordnet werden. Dadurch kann bei tabel-
lenbasierten Darstellungen zumindest textuell auf den Kontrollfluss hingewiesen werden.
Daf¨
ur m¨
ussen die Netzkanten, die zwei Aktivit¨
aten miteinander verbinden, jedoch eindeu-
tig einer der beiden Aktivit¨
aten zugeordnet werden.
Die Kontrollfluss-Informationen lassen sich besser auf die Aktivit¨
aten verteilen, wenn Be-
dingungen als Ausf¨
uhrungsbedingungen begriffen werden und sie der Aktivit¨
at am Ende
der Kante zugeordnet werden. Bei einer großen Verzweigung im Prozessablauf m¨
ussen all
die vielen Bedingungen nun nicht im Zusammenhang mit der einzelnen Aktivit¨
at, die am
Beginn der Verzeigung steht, angezeigt werden. Auf diese Weise lassen sich auch leicht alle
Aktivit¨
aten in einer Tabelle markieren, an die Ausf¨
uhrungsbedingungen gekn¨
upft sind, da
nicht ¨
uberpr¨
uft werden muss, ob in der Vorg¨
angeraktivit¨
at eine Bedingung hinterlegt ist.
Und im Fall von Verkn¨
upfungen entscheidet ohnehin die Zielaktivit¨
at dar¨
uber, ob eine
’Und’ oder ’Oder’ Weiterschaltung erfolgt.
2.1.2. Darstellungsarten
Prozess
Multi-Instanz-
Darstellung
Schema-Darstellung (Einzel-)Instanz-
Darstellung
Aggregierte Multi-
Instanz-Darstellung Parallele Multi-
Instanz-Darstellung
Multi-Schema-
Darstellung
Abbildung 2.3.: Darstellungsarten f¨
ur die Visualisierung
Abbildung 2.3 zeigt mit welchen Darstellungsarten die Prozessdaten aus einem PMS dar-
gestellt werden k¨
onnen.
Schema-Darstellung
Prozessschemata legen den ganzen Prozessablauf fest, der Kontrollfluss ist gem¨
aß dem
Prozess-Metamodell modelliert und dem Prozess und allen Aktivit¨
aten sind Attribute aus
dem Datenmodell zugeordnet. Die Attribute enthalten schon die notwendigen Werte, damit
Instanzen die dem Schema zugeordnet sind sofort gestartet werden k¨
onnen. Unter Prozess-
visualisierung wird meist die Darstellung bereits laufender Prozesse (also Instanzen) ver-
16
2.1. Visualisierung von Prozessdaten
standen. Was ein Schema von einer Instanz unterscheidet, sind haupts¨
achlich die fehlenden
Laufzeitinformationen. Eine Schema-Darstellung eignet sich dazu, Prozesse zu entwerfen,
zu ver¨
andern oder zu analysieren. Sie dient dazu, Zusammenh¨
ange zu verdeutlichen und
sich einen ¨
Uberblick ¨
uber den logischen Ablauf zu verschaffen. Damit ist eine Schema-
Darstellung bereits sehr aussagekr¨
aftig. Sie zeigt Aktivit¨
aten sowie deren Eigenschaften
(oder Attribute), zugeordnete Datenfl¨
usse und Ressourcen (z. B. zur Ausf¨
uhrung von Akti-
vit¨
aten ben¨
otigte Applikationen und IT-Systeme). Informationen zu Ausf¨
uhrungseinheiten
umfassen ¨
ublicherweise Rollenangaben (aus dem Organisationsmodell); eine Zuordnung
von konkreten Bearbeitern erfolgt ¨
ublicherweise erst zur Laufzeit. Prozessschemata k¨
on-
nen hierarchisch organisiert sein. In diesem Fall hat ein Schema Verbindungen in andere
Teile der Prozesshierarchie. Einzelne oder alle Aktivit¨
aten eines Schemas sind dann Platz-
halter f¨
ur Aufrufe von Teilprozessen. F¨
ur erfahrene Anwender sollten daher, aggregierte
Aktivit¨
aten von normalen Aktivit¨
aten in der Darstellung unterscheidbar sein.
Instanz-Darstellung
Auf Instanzebene werden eventuell angegebene Rollen bei den Ausf¨
uhrungseinheiten zu
konkreten Bearbeiterinformationen aufgel¨
ost. Nicht ausgef¨
uhrte Pfade im Workflow k¨
on-
nen zur besseren ¨
Ubersichtlichkeit ausgeblendet werden. Dadurch ist auch der Daten-
fluss genauer bestimmt, da er vom Kontrollfluss abgeleitet wird. Die Aktivit¨
aten erhalten
zus¨
atzlich Zustandsmarkierungen (z. B. gestartet, abgeschlossen) und die Prozesshistorie
kann dargestellt werden.
Multi-Instanz-Darstellung
Falls mehrere Instanzen eines Prozessschemas vorliegen, kann der Benutzer eine Multi-
Instanz-Darstellung w¨
unschen. Hier sollen ¨
Ubersichtsdarstellungen f¨
ur den n¨
otigen ¨
Uber-
blick sorgen. Oftmals ist auch die Rede von Prozess-Cockpit oder -Dashboard. Die einzel-
nen Prozessinstanzen k¨
onnen (je nach Prozess-Metamodell) folgende Zust¨
ande haben:
➣gestartet
➣nicht gestartet
➣pausiert
➣abgeschlossen
Diese Zust¨
ande und der jeweilige (Ausf¨
uhrungs-)Fortschritt der Instanzen k¨
onnen visuali-
siert werden. Es wird zwischen zwei Darstellungsvarianten unterschieden. Instanzen k¨
on-
nen entweder ’aggregiert’ oder ’parallel’ dargestellt werden. Eine aggregierte Darstellung
zeigt das (Prozess-)Schema dieser Instanzen, angereichert um Informationen zum jeweili-
gen Ausf¨
uhrungsfortschritt der Instanzen. Details einzelner Instanzen k¨
onnen dabei nicht
angezeigt werden, nur aggregierte Werte wie beispielsweise Durchschnittskosten. Eine par-
allele Darstellung listet alle Instanzen (parallel) untereinander auf. Die Informationen zu
jeder einzelnen Instanz werden somit separat visualisiert. Einzelne Prozessinformationen
m¨
ussen somit nicht aggregiert werden. Allerdings m¨
ussen die einzelnen Instanzen in platz-
sparender komprimierter Form f¨
ur diese Art der Darstellung aufbereitet werden (z. B.
als Meilenstein-Ansicht). Der Benutzer hat die M¨
oglichkeit, sich aus einer solchen Multi-
Instanz-Darstellung gezielt eine einzelne Instanz zu w¨
ahlen, um sich diese mit allen Details
anzeigen zu lassen.
17
2. Grundlagen und Einf¨
uhrung
Multi-Schema-Darstellung
Einen Spezialfall und eine Schwierigkeit f¨
ur die Visualisierung stellt die Anforderung
dar, Multi-Schema-Darstellungen zu unterst¨
utzen. Denkbare Anwendungsf¨
alle ergeben sich
¨
uberall dort, wo an einem Produkt oder Objekt mehrere unterschiedliche Prozesse betei-
ligt sind. Eine einzige Darstellung erm¨
oglicht so dem Benutzer eine ¨
Ubersicht ¨
uber diese
Prozesse.
Ein Beispiel w¨
aren verschiedene Change-Management-Prozesse, die f¨
ur verschiedene Teile
eines Gesamtprodukts initiiert wurden. Die einzelnen Change-Management-Prozesse k¨
on-
nen dabei f¨
ur jedes Bauteil unterschiedlich aussehen. Eine ¨
Ubersichtsdarstellung zeigt dann
alle laufenden Change-Management-Prozesse dieses Produkts. Es k¨
onnen dabei nat¨
urlich
mehrere Instanzen eines Prozessschemas laufen.
Nativ l¨
asst sich so etwas nur in einer Kombination von aggregierter und paralleler Multi-
Instanz-Darstellung visualisieren (siehe letzter Abschnitt). Eine besonders ¨
ubersichtli-
che Darstellung ergibt sich, wenn die verschiedenen Prozessschemata auf eine gemein-
same View abgebildet werden. Verschiedene Change-Management-Prozesse lassen sich so
beispielsweise auf die Grundelemente Initialisierung, Evaluation, Realisierung und Ab-
schluss zur¨
uckf¨
uhren. Damit wird eine Multi-Schema-Darstellung auf eine Multi-Instanz-
Darstellung zur¨
uckgef¨
uhrt. Damit k¨
onnen Multi-Schema-Darstellungen auch mit Darstel-
lungskonzepten angezeigt werden, die nur den Multi-Instanz Fall beherrschen.
Schema-Versionen-Darstellung
Ganz am Rande der Betrachtungen dieser verschiedenen Darstellungsformen bleibt noch
eine ganz andere Visualisierungsanforderung zu erw¨
ahnen: Die Gegen¨
uberstellung von mo-
difizierten Prozessschemata erfordert eine gesonderte Herangehensweise. Unter anderem
durch die Schema-Evolution entstehen neue Versionen von einzelnen Schemata. Um die
¨
Anderungen von einer Version zur N¨
achsten nachzuvollziehen, wird eine besondere Dar-
stellung ben¨
otigt. Hierf¨
ur bietet sich eine Prozessgraphdarstellung an. Die Schema-Version
mit den meisten Knoten bietet hierf¨
ur die Grundlage, die restlichen Versionen werden dazu
in Beziehung gesetzt. Farbcodierungen der Knoten und Kanten zeigen die Versions¨
ande-
rungen.
2.1.3. Organisationsmodell
PMS referenzieren im Allgemeinen ein Organisationsmodell des Unternehmens. ¨
Ublicher-
weise ist damit nur das Organisationsmodell gemeint, das die Personalstruktur abbildet.
F¨
ur die Prozessvisualisierung sind jedoch alle Informationen hilfreich, die es erlauben, Res-
sourcen zu kategorisieren/organisieren. Wenn also Modelle existieren, die z. B. die Struktur
von IT-Landschaften erfassen, sind dies ebenfalls Organisationsinformationen, die im Kon-
text dieser Arbeit als Organisationsmodell aufgefasst werden.
Eventuell existiert auch f¨
ur die Dokumente und Daten eines Unternehmens eine verwaltete
organisierte Struktur, wie ein Dokumenten-Management-System. Mithilfe solcher Informa-
tionen ist es z. B. in Darstellungen m¨
oglich, Dokumente nach Kategorien zu gruppieren.
Wie viele solcher Modelle in der Realit¨
at vorliegen, ist nicht entscheidend. Es geht hier
um die Idee, dieses Wissen ¨
uber die Umgebung in der die Prozesse laufen f¨
ur die Visua-
18
2.2. Ans¨
atze zur Prozessvisualisierung
lisierung zu nutzen. Deswegen werden in dieser Arbeit alle Modelle unter dem Namen
Organisationsmodell geb¨
undelt.
Das Organisationsmodell l¨
asst sich als hierarchisch gegliedertes Ressourcenverzeichnis be-
schreiben. Personen aber evtl. auch IT-Systeme, Maschinen und Dokumente sind dabei in
einer ’1:n’-Beziehung den verschiedenen Organisationsstrukturen des Unternehmens oder
auch zu externen Partnern zugeordnet. Innerhalb des Unternehmens sind das ¨
ublicher-
weise Zuordnungen zu Abteilungen, (Projekt-)Teams und (Arbeits-)Gruppen. Das Modell
enth¨
alt auch Rollen, sie spezifizieren die verschiedenen Funktionen innerhalb der Organisa-
tion. In einem Labor gibt es z. B. die Rollen Arzt, MTA und Chemiker. Einer Rolle k¨
onnen
einzelne oder mehrere Personen zugeordnet werden und je nach Komplexit¨
at des Modells
sogar Priorit¨
aten und Zeitbedingungen. Auch Stellvertreterrollen oder -Regelungen k¨
on-
nen definiert sein. Den Aktivit¨
aten eines Prozessschemas sind solche Rollen zugeordnet.
Anhand der Informationen aus dem Organisationsmodell kann dann das PMS zur Laufzeit
den Aktivit¨
aten konkrete Bearbeiter zuordnen.
F¨
ur die Prozessvisualisierung sind Organisationsmodelle relevant, weil es durch die in den
Modellen gespeicherten Informationen m¨
oglich ist, Prozessdaten damit anzureichern. Da-
mit wird es m¨
oglich, alle Aktivit¨
aten, die von Mitarbeitern einer Abteilung bearbeitet
werden, gesondert zu markieren. Dies kommt der ¨
Ubersichtlichkeit zugute, wenn der Be-
nutzer des Systems beispielsweise nur an den Teilen des Prozesses interessiert ist, an denen
nur diese Abteilung beteiligt ist.
2.2. Ansätze zur Prozessvisualisierung
Der vorangehende Abschnitt hat eine ¨
Ubersicht der zu visualisierenden Prozessinformatio-
nen gegeben. Ausgangspunkt der nachfolgenden Betrachtungen bildet das Konzept Pro-
zessgraphdarstellung. Dieses wird analysiert, um weitere Darstellungsformen zu finden, die
dessen Nachteile nicht teilen. Auch sollen f¨
ur neue Darstellungsformen andere Prozessa-
spekte als die Prozessstruktur im Vordergrund stehen.
Abbildung 2.4 illustriert die Herangehensweise dieser Arbeit, um zu einer besseren Vi-
sualisierung von Prozessinformationen zu gelangen. Sie zeigt, zwei grundlegende Ans¨
atze,
die Prozessvisualisierung, ausgehend von der Prozessgraphdarstellung, zu optimieren. Der
erste Ansatz beruht darauf, die grafische Darstellung zu optimieren. Der zweite Ansatz
besteht darin, die bestehende Struktur der Prozessdaten zu ¨
andern und sie anders darzu-
stellen. Wichtig hierbei ist insbesondere die Feststellung, dass es sich hier um orthogonale
Konzepte handelt. Das heißt, auch ver¨
anderte Strukturen profitieren von der Optimierung
der grafischen Repr¨
asentation. Beide Ans¨
atze werden daher im Folgenden kombiniert.
Diese Arbeit widmet sich Verfahren der automatischen Generierung von Prozessgrafiken.
Diese ¨
Ubersicht ¨
uber Ans¨
atze zur Prozessvisualisierung w¨
are allerdings ohne die Erw¨
ah-
nung von dynamischen Darstellungen nicht vollst¨
andig.
Dynamische Darstellungen sind Grafiken mit dynamischen Inhalten denen Prozessdaten
zugeordnet sind. Auf diese Weise k¨
onnen Arbeitsabl¨
aufe eines Prozesses besonders reali-
t¨
atsnah dargestellt werden. Der Benutzer muss eine Darstellung nicht mehr interpretieren,
wenn sie genau seinem Gedankenmodell entspricht. Prozesse eines Verkehrsleitstandes las-
sen sich beispielsweise auf der Grundlage eines Liniennetzplanes wie in Abbildung 2.5
19
2. Grundlagen und Einf¨
uhrung
Prozessgraph-
Darstellung
Veränderung an
Graphik
Veränderung an
Struktur
View
Darstellungsform
Reduktion
Aggregation
Farbe
Form
Notation
Informationsebene
Markierung
Abbildung 2.4.: Konzepte zur Visualisierung
visualisieren. Produktionsabl¨
aufe k¨
onnen anhand einer schematischen Darstellung der Fa-
brik dargestellt werden. Allerdings erfordern dynamische Darstellungen eine manuelle
Zuordnung von Prozessdaten auf dynamische Objekte einer Darstellung. Dennoch kann
sich der Aufwand zur Erstellung einer dynamischen Darstellung lohnen.
2.2.1. Veränderungen an der Grafik
In diesem und dem folgendem Abschnitt werden die beiden wichtigsten Herangehensweisen
an die Aufgabenstellung beschrieben. Gleichzeitig wird in die weitere Strukturierung der
Arbeit eingef¨
uhrt:
Kapitel 5widmet sich der Frage, f¨
ur welche Komponente einer grafischen Darstellung
Verbesserungen erzielbar sind und was beachtet werden sollte, um benutzerfreundliche
Darstellungen zu erzeugen. Dazu wird auf die in Kapitel 4zusammengestellten Forschungs-
ergebnisse zur¨
uckgegriffen. Dieses Kapitel behandelt Teilaspekte wie den Einsatz von Far-
ben und deren Anwendung in Form von Kontrasten. Beides kann verwendet werden, um
verschiedene Informationsebenen in Darstellungen einzuziehen. Weiterhin wird f¨
ur eine
Prozessgraphdarstellung eine Notation ben¨
otigt, die die Konventionen festlegt, in welcher
Form die Informationen aus den Prozessdaten in eine grafische Darstellung umgesetzt
werden sollen.
2.2.2. Veränderungen an der Struktur
Der Ansatz, die grafische Darstellung von Prozessansichten zu optimieren, l¨
asst sich mit
dem nachfolgend beschriebenen Ansatz, die Struktur der Prozessdaten zu ver¨
andern, kom-
binieren. Daher fließen die Erkenntnisse aus Kapitel 5in die verschiedenen in Kapitel 6
pr¨
asentierten Darstellungsformen mit ein. Dabei l¨
asst sich zwar nicht alles auf jede Dar-
20
2.2. Ans¨
atze zur Prozessvisualisierung
Abbildung 2.5.: Ausschnitt aus dem Netzplan des Donau-Iller-Nahverkehrsverbundes
stellungsform anwenden, aber vor allem die Ansichten, die eng mit der Prozessgraphdar-
stellung verwandt sind, orientieren sich stark daran.
Prozessdaten beschreiben einen gerichteten Graphen mit definiertem Start und m¨
oglicher-
weise mehreren Endpunkten. Die Prozessgraphdarstellung ist somit die nat¨
urlichste Form,
der Prozessvisualisierung. Die Knoten eines Prozessgraphen stellen die Aktivit¨
aten des
Prozesses dar; jede Aktivit¨
at umfasst eine Menge von Attributen und zugeordneten Objek-
ten, (z. B. die Ausf¨
uhrungseinheit). Dies entspricht der Sicht und dem (Gedanken-)Modell
eines Prozessmodellierers.
An der Graphstruktur muss bei der Prozessdarstellung nicht starr festgehalten werden.
Einerseits besteht die M¨
oglichkeit Views (siehe Abschnitt 7.1) auf den Prozessdaten zu
erzeugen, andererseits kann eine ganz andere Sichtweise auf die Prozessinformationen, zu
einer Neu-Anordnung der Prozessdaten f¨
uhren. Ein anderes Ziel als die Darstellung des
Kontrollflusses, z. B. das Ziel Zeitaspekte zu visualisieren, f¨
uhrt so zu einer Kalenderdar-
stellung – die Struktur der Daten wird ver¨
andert. Die verschiedenen Benutzerziele, auf
die im Kapitel 3eingegangen wird, f¨
uhren so zu neuen Darstellungsformen (siehe Goal-
Directed-Design Abschnitt 3.1).
Kapitel 6gliedert sich in Abschnitte zu den verschiedenen Konzepten. Diese Abschnitte
sind jeweils nach dem gleichen Muster strukturiert. Nach einer kurzen Einf¨
uhrung folgt
ein Beispiel. Danach wird die M¨
achtigkeit des Konzepts diskutiert. Es werden Fragen
gekl¨
art, wie gut sich Prozesse verschiedener Komplexit¨
at darstellen lassen, beispielsweise
Prozesse mit Schleifen, hierarchische Prozesse oder mehrere Prozesse gleichzeitig, als Multi-
21
2. Grundlagen und Einf¨
uhrung
Instanz-Ansicht in aggregierter oder paralleler Form. Es wird behandelt, welche Informa-
tionsaspekte die Darstellung abdeckt, etwa in Bezug auf Aktivit¨
atendetails, Kontrollfluss
und damit zusammenh¨
angende (Ausf¨
uhrungs-)Abh¨
angigkeiten, Datenfluss und zeitliche
Aspekte. Weiterhin wird diskutiert, aus welchen Gr¨
unden sich der Kontrollfluss mehr oder
weniger gut darstellen l¨
asst, mitsamt seinen Bestandteilen wie Verzweigungen und Schlei-
fen, Spr¨
ungen oder Ausnahmen. Weiterhin wird gekl¨
art, welchen Stellenwert das Organi-
sationsmodell in der Darstellung hat, oder wo die Unterschiede zwischen Schema-, Instanz-
und Multi-Instanz-Darstellungen liegen. Je nach M¨
achtigkeit des Prozess-Metamodells lie-
ßen sich noch weit mehr Spezialf¨
alle betrachten, die genannten Aspekte sollen aber zur
Einsch¨
atzung und Bewertung der M¨
achtigkeit der einzelnen Darstellungsformen gen¨
ugen.
Es schließt sich eine Untersuchung der spezifischen Vorteile und Nachteile der jeweili-
gen Darstellungsform an. Wenn sich von einzelnen Darstellungsformen konzeptbedingt
noch verschiedene m¨
ogliche Varianten ergeben, werden diese ebenfalls vorgestellt. Auch
Multi-Instanz-Ansichten werden ber¨
ucksichtigt. Des Weiteren kann die Anpassung an ver-
schiedene Benutzerprofile (z. B. Anf¨
anger oder Experte) zu weiteren Varianten f¨
uhren. Die
Darstellungen unterscheiden sich dann nur in der Komplexit¨
at. Schließlich werden noch
Konfigurationsm¨
oglichkeiten aufgelistet, die dem Benutzer speziell f¨
ur die jeweilige Dar-
stellungsform angeboten werden k¨
onnen. Auch auf besondere notwendige Voraussetzungen
f¨
ur die Darstellung oder besondere Implementierungsaspekte wird in entsprechenden Un-
terkapiteln eingegangen.
2.3. Zusammenfassung
In diesem Kapitel wurde eine ¨
Ubersicht ¨
uber die Struktur und den Inhalt von Prozessin-
formationen gegeben. Um flexible Informationsm¨
oglichkeiten f¨
ur den Benutzer zu schaffen,
braucht es Schema-, Instanz- und Multi-Instanz-Darstellungen. Um m¨
achtige Darstellun-
gen zu realisieren, ist die Integration von organisatorischem Wissen ¨
uber die Struktur
von Ressourcen wie Personal, Daten & Dokumenten und Systemen in die Prozessinfor-
mationen wichtig. Dieses Strukturwissen wird hier unter dem Begriff Organisationsmodell
zusammengefasst.
Visualisierungskonzepte bilden eine Einheit aus Farben, Formen, Notationen, Strukturie-
rung und Nutzerinteraktionen. Ausgehend vom Konzept Prozessgraphdarstellung sollen
¨
uber Ver¨
anderungen an der grafischen Repr¨
asentation und ¨
Anderungen an der Struktur
der Prozessdaten, eine verbesserte Prozessgraphdarstellung und neue Konzepte entwickelt
werden.
Im folgenden Kapitel werden die Anforderungen an eine Prozessvisualisierungskomponen-
te, vor allem wie sie sich aus der Sicht ihrer Benutzer stellen, untersucht.
22
3
Anforderungsanalyse
Am Anfang dieses Kapitels steht die Frage, welchen Anforderungen ein Informationssystem
gen¨
ugen muss, das Prozessinformationen darstellen soll und wie die Rahmenbedingungen
daf¨
ur aussehen. Der Design-Theoretiker Gui Bonsiepe [Bons96, S.15] beschreibt ein onto-
logisches Designdiagramm (Abbildung 3.1) dessen Mittelpunkt das Interface darstellt. Es
verbindet die drei Bereiche
➣Benutzer
➣Zu bew¨
altigende Aufgabe
➣Werkzeug, f¨
ur die Bearbeitung dieser Aufgabe
Im Abschnitt 3.2 werden die Benutzer und ihre Aufgaben diskutiert. Das Werkzeug sind
die sp¨
ater im Kapitel 6beschriebenen Visualisierungskonzepte.
“Durch das [...] Interface wird der Handlungsraum des Nutzers von Produkten
gegliedert. Das Interface erschließt den Werkzeugcharakter von Objekten und
den Informationsgehalt von Daten. Interface macht Gegenst¨
ande zu Produkten.
Interface macht aus Daten verst¨
andliche Informationen.” (Gui Bonsiepe)
Interface
Benutzer
Aufgabe Werkzeug
Abbildung 3.1.: Ontologisches Designdiagramm
23
3. Anforderungsanalyse
Vor dem Kontext der Entwicklung einer Prozessvisualisierungskomponente ist auch das
Entwicklungsparadigma interessant. Im Allgemeinen geht der Entwicklung einer Software
eine Anforderungsanalyse voraus. Ein h¨
aufiger Fehler ist ein funktionszentrierter Ansatz
(engl. Form follows function ), bei dem eine Liste der gew¨
unschten Funktionen als Grundlage
f¨
ur die Entwicklung eines Systems dient. Programmierer denken bei Produkten h¨
aufig in
Kategorien wie Funktionen und Features. Das ist nachvollziehbar, denn das entspricht im
Allgemeinen der Art und Weise, wie Entwickler Software produzieren [CR03, S.19].
3.1. Goal-Directed-Design
Anliegen dieser Arbeit ist es, die Grundlagen f¨
ur eine Prozessvisualisierungs-Engine zu
schaffen, die es den Nutzern erlaubt ihre Ziele zu erreichen und die nicht einfach nur
m¨
oglichst viele Funktionen anbietet. Alan Cooper [CR03, S.18] war ein Pionier von auf das
(Benutzer-)Ziel ausgerichteten Softwareentwicklungsprozessen. Die Abbildungen zeigen die
Struktur seines Goal-Directed-Design Ansatzes. 3.2 &3.3.
Audit
Scope Interview Observations Personas Goals
Activity
Result
Define interest and
constraints of project Review what exists
(e.g. documents) Discuss values,
issues, expectations Apply ethnographic
research techniques Define typical users Deduce what users
want
lead to
desired outcomes market research
competitors
related technology
management
domain experts
customers
partners
usage patterns
potential users
their activities
their environments
their interactions
their objects (tools)
primary
secondary
supplemental
negative
served (indirectly)
customer
end
experience
technical
Abbildung 3.2.: Schema des Goal-Directed-Design Entwurfskonzeptes – Teil 1
Goals Requirements Scenarios Elements Framework Spec
Activity
Result
Deduce what users
want Imagine a system to
help users reach goals Tell stories about
using the system Derive components
bases on users Organize the
components Refine details;
describe models
drive
end
experience
technical
problem definition
vision definition
design imperatives
functional & data needs
technical constraints
(May require changes in
scope.)
context
key path
validation
key path variants
necessary use
edge case use
information objects
functional objects
functional actions
context of use
object relationships
conceptual groupings
principles
patterns
logic / narrative flow
navigation structure
apperance
flow / behavior
Abbildung 3.3.: Schema des Goal-Directed-Design Entwurfskonzeptes – Teil 2
Die Schritte dieses Entwicklungsprozesses dienen als Rahmen dieser Arbeit. Sie legen die
Grundlage f¨
ur eine am Bedarf der potenziellen Anwender ausgerichteten Komponente
zur Prozessvisualisierung. Goal-Directed-Design ist zielorientiert und nicht funktions- oder
aufgabenorientiert. Zuerst wird der Benutzer mit seinen Zielen gesehen. Um sein Ziel zu
erreichen, wird er nacheinander verschiedene Einzelaufgaben abarbeiten, indem er die vom
Programm bereitgestellten Funktionen nutzt. Wenn die Software mit dem Ziel entwickelt
wurde, dass sie in erster Linie einen bestimmten Satz von Funktionen bieten soll, wird
24
3.1. Goal-Directed-Design
der Anwender gezwungen, sich nach dem Programm zu richten. Effizientes Arbeiten wird
dann m¨
oglich, wenn die Funktionen der Software auf die m¨
oglichen Ziele der Benutzer hin
ausgerichtet sind.
Ein gutes Beispiel hierf¨
ur liefert die Photoshop Variations¨
ubersicht (siehe Abbildung 3.4).
Wie in einem Farbkreis sind Variationen des Bildes mit mehr Gr¨
un, Gelb, Rot, Magen-
ta, Blau oder Cyan um die Originalversion in der Mitte angeordnet. Wenn eine Variante
gew¨
ahlt wird, kann ausgehend von dieser weiter gew¨
ahlt werden, bis das gew¨
unschte Er-
gebnis erreicht ist. Auf diese Weise kann ein Bild auch schrittweise erhellt oder abgedunkelt
werden. Dieses Interface orientiert sich an dem mentalen Modell eines Grafikers, der sich
f¨
ur das Bild interessiert, nicht f¨
ur abstrakte numerische Werte.
Abbildung 3.4.: Photoshop Variationen¨
ubersicht
Am Anfang eines Entwicklungsprozesses steht die Formulierung der Zielsetzung und der
Randbedingungen. Die Zielsetzung geschah bereits in Kapitel 1.
Im Kapitel 4, schließt sich die Auseinandersetzung mit bereits existierenden L¨
osungen und
deren Einschr¨
ankungen an (engl. Audit). Auf ein Gespr¨
ach mit potenziellen Nutzern (engl.
Interview) und die Beobachtung ihrer typischen Arbeitsweisen (engl. Observation) muss
im Rahmen dieser theoretischen Arbeit jedoch verzichtet werden. Abbildung 3.2 zeigt diese
25
3. Anforderungsanalyse
beiden Schritte daher grau markiert. Bei der Entwicklung einer konkreten Visualisierungs-
l¨
osung w¨
are dies jedoch unerl¨
asslich. Eine sp¨
atere Arbeit k¨
onnte Visualisierungskonzepte
f¨
ur ein konkretes Projekt untersuchen und daf¨
ur auch eine ausf¨
uhrliche Analyse vorneh-
men, beispielsweise f¨
ur das Change Management in der Automobilindustrie oder f¨
ur ein
Krankenhausinformationssystem.
Der Abschnitt 3.2 widmet sich der Definition der typischen Benutzer eines solchen Systems
(Personas) [CR03, S.55]. Von diesen lassen sich dann die Ziele ableiten (engl. User Goals),
die mithilfe der Software erf¨
ullt werden sollen. Wo in anderen Projekten oft schon Benut-
zer und Werkzeuge feststehen, stellt sich hier nicht nur die Frage nach der Gestaltung des
Interface, sondern vor allem die Suche nach geeigneten Werkzeugen, also Visualisierungs-
konzepten, um diese Ziele m¨
oglichst ohne Umwege zu erf¨
ullen.
3.2. Ziele nach Benutzergruppen
Die Benutzer der zuk¨
unftigen Anwendung sollen dem von Cooper definierten Satz von
Nutzermodellen zugeordnet werden. Der erste Schritt besteht darin, den Anwenderkreis
zu interviewen und ihre typischen Arbeitsweisen zu beobachten. Ausgehend von diesen
Informationen muss dann versucht werden, den Typus des Prim¨
arnutzers und dann den
Typus der anderen Anwender zu charakterisieren. Die folgende Auflistung dient der Ab-
grenzung der verschiedenen Typen voneinander. Die Zuordnung der Anwender zu den
Nutzermodellen ist dann korrekt, wenn alle folgenden Anforderungen erf¨
ullt sind:
➣primary
F¨
ur diesen Prim¨
arnutzer wird das Interface entwickelt. Alle anderen Nut-
zer werden im Großen und Ganzen mit der Ausrichtung des Interface auf
den Prim¨
arnutzer zufrieden gestellt. Eine Ausrichtung des Interface auf an-
dere Nutzer w¨
urde den Prim¨
arnutzer nicht zufrieden stellen. Aber wenn die
Aufgabenunterst¨
utzung der Prim¨
arnutzer das Ziel ist, dann sind die ande-
ren Nutzer zumindestens nicht unzufrieden. Wichtig zum Verst¨
andnis der
Nutzermodelle ist: Wenn es mehr als einen Prim¨
arnutzer gibt, dann muss
ein Produkt auch mehrere Interfaces anbieten, da sich die unterschiedlichen
Zielsetzungen der Prim¨
arnutzer nicht unter einem Interface erf¨
ullen lassen!
➣secondary
Sekund¨
arnutzer werden mit dem Interface des/eines Prim¨
arnutzers zufrieden
gestellt, sie fordern nur einige wenige Zusatzanforderungen.
➣supplemental
Zu diesem Nutzerkreis geh¨
oren Personen, die weder Prim¨
ar- noch Sekun-
d¨
arnutzer sind. Ihre Bed¨
urfnisse werden komplett von einem der Interfaces
erf¨
ullt.
➣customer
Hier werden die Bed¨
urfnisse von Auftraggebern erfasst, nicht die von End-
nutzern. (Werden wie Sekund¨
arnutzer behandelt)
➣served
Diese Personengruppe z¨
ahlt nicht zu den Nutzern des Produkts, sie sind nur
indirekt Beteiligte. Hierdurch kann beispielsweise ¨
uberpr¨
uft werden, ob der
26
3.2. Ziele nach Benutzergruppen
Einsatz einer neuen Software auch positive Auswirkungen auf Kunden hat.
(Werden wie Sekund¨
arnutzer behandelt)
➣negative
F¨
ur diese Personengruppe soll das Produkt nicht entworfen werden. Dies
dient zur Abgrenzung und Konkretisierung des eigentlichen Ziels. So k¨
onnte
z. B. festgelegt werden, dass Power-User nicht die angepeilte Zielgruppe sind.
Diese sechs Nutzermodelle repr¨
asentieren jeweils unterschiedliche Gruppen von Handlungs-
weisen, Zielen und Motivationen. Diese Einteilung garantiert Vollst¨
andigkeit, da sich jede
Person mindestens einer dieser Gruppen zuordnen l¨
asst.
Ziel ist es einen Satz markanter Personas mit ihren Zielen, Motivationen und Bed¨
urfnissen
zu erstellen. Bei der Anwendungsentwicklung dienen dann diese Personas als Messlatte. Sie
helfen den Entwicklern, den von den Benutzerzielen abgeleiteten gew¨
unschten Features,
Priorit¨
aten zuzuordnen.
Personas repr¨
asentieren Verhaltensweisen. Sie sind keine Job-Beschreibungen, weil diese
nicht zwangsl¨
aufig ¨
ubereinstimmen m¨
ussen. An dieser Stelle soll jedoch eine Liste von
wichtigen Zielpersonengruppen f¨
ur eine Visualisierungskomponente gen¨
ugen, wie sie Ta-
belle 3.1 zeigt.
Benutzergruppe Bed¨
urfnisse, Verhaltensweisen
Bearbeiter / Anwender W¨
unscht einen guten ¨
Uberblick ¨
uber kommende und
laufende Aufgaben. Nutzt die gegebenen Werkzeuge ohne
große Anpassungen
Prozessverantwortlicher /
Abteilungsleiter
W¨
unscht umfassende Visualisierungsm¨
oglichkeiten, um
einen Prozess aus vielen Perspektiven untersuchen zu
k¨
onnen. W¨
unscht Anpassbarkeit der Werkzeuge an
spezielle Aufgabestellungen
Management /
Gesch¨
aftsf¨
uhrung
W¨
unscht eine kompakte ¨
Ubersicht ¨
uber viele
Prozessinstanzen. Details sind nicht von Interesse
IT W¨
unscht Informationen ¨
uber den Datenfluss und beteiligte
Systeme und Anwendungen. Interessiert sich viel f¨
ur
Zusammenh¨
ange, weniger f¨
ur konkrete Prozessabl¨
aufe
Externer Mitarbeiter / Kunde W¨
unscht Einblick in die Einbindung des Kunden in den
Prozess, also teilweise Details, teilweise nur ¨
Ubersicht
Tabelle 3.1.: Benutzergruppen mit Beschreibung
Das heißt, wir beschr¨
anken uns im Folgenden auf primary, secondary und supplemental
Personas. Als negative Persona w¨
are der Gesch¨
aftsprozessentwickler (oder Prozessmodel-
lierer) zu nennen, der neue Prozessschemata entwirft. Der Fokus dieser Arbeit ist eine
Visualisierungskomponente. Wenn die Software auch an Prozess-Entwickler gerichtet w¨
a-
re, w¨
urden diese eine weitere primary Persona ergeben, die dann auch ein extra Interface
erfordert.
Einzelne Aufgaben oder Benutzerziele, aber auch ganze Benutzergruppen, lassen sich auch
nach dem in Abbildung 3.5 gezeigten Schema voneinander abgrenzen. Dies geschieht auf
zwei unabh¨
angigen Ebenen. Aufgaben haben einen bestimmten Aufgabentyp (Entwer-
fen, Entscheiden, Informieren) und Detailgrad (¨
Ubersicht, Zusammenhang, Details). Ein
27
3. Anforderungsanalyse
Halbkreis symbolisiert die Gesamtheit aller Aufgaben. Die eine Ebene der Aufgaben, bei-
spielsweise des Managements, umfassen davon nur einen Teilbereich: Sie lassen sich im
Allgemeinen den Aufgabentypen ’Informieren’ und ’Entscheiden’ zuordnen, innerhalb die-
ser Aufgabentypen aber nur dem Detailgrad ’¨
Ubersicht’. Jede Benutzergruppe l¨
asst sich
auf diese Weise einem definiertem Teilbereich der Gesamtheit aller Aufgaben zuordnen.
Entwerfen
(A1)
Zusammenhang
(D2)
Übersicht
(D1)
Details
(D3)
Informieren
(A3)
Entscheiden
(A2)
Aufgabentyp
Detailgrad
Abbildung 3.5.: Schema f¨
ur die Einordnung der Benutzergruppen
Manager w¨
unschen ihren Aufgaben entsprechend daher eine stark vereinfachte (aggregier-
te) ¨
Ubersicht auf Prozesse, w¨
ahrend Prozessbeteiligten eher ein Ausschnitt des Prozes-
ses, mit den f¨
ur sie relevanten Aktivit¨
aten, in hohem Detailierungsgrad angezeigt wird
[BRB05].
Die Tabellen 3.2 und 3.3 auf den beiden folgenden Seiten listen beispielhafte Aufgaben
und Fragestellungen der verschiedenen Benutzergruppen auf:
28
3.2. Ziele nach Benutzergruppen
Aufgabe (Fragestellung) Aufgabentyp Detailgrad
Bearbeiter/Anwender
Entwerfena
Entscheiden
Informieren
¨
Ubersicht
Zusammenhang
Details
Liste aktueller Aufgaben √ √
Welche Aufgabe hat Priorit¨
at? √ √
Wie ordnet sich eine Aufgabe ins Umfeld
ein?
√ √
Welche anderen Anwender sind noch an dem
Prozess beteiligt?
√ √
Welche Aufgaben stehen in naher Zukunft
an?
√ √
Was ist schon alles erledigt? (Motivation) √ √
Prozessverantwortlicher/Abteilungsleiter
View-Bildung √ √ √
Anpassung des Prozessschemas an
ver¨
anderte Bedingungen
√ √
Zeit-Kontrolle (Plan/Ist Vergleich) √ √ √
Wie groß sind die Pufferzeiten? √ √ √
Was hat sich in der letzten Zeit getan? √ √
Welche Meilensteine wurden erreicht? √ √
¨
Uberblick gewinnen √ √
Wie ist der aktuelle Stand? √ √
Wie sieht der Daten-/Dokumentfluss aus? √ √
Wer kommuniziert mit wem? √ √
K¨
onnen alle Fristen eingehalten werden? √ √
Wie sind die Mitarbeiter ausgelastet? √ √
Wie ist die Kostenentwicklung? √ √ √
Management
Wie ist der Status aller Instanzen? √ √
Wie groß ist die Gesamtbearbeitungsdauer
der Instanzen? (Durchsatz)
√ √ √
Wie sind die Mitarbeiter ausgelastet? √ √ √
Wie ist die Kostenentwicklung? √ √ √
K¨
onnen alle Fristen eingehalten werden? √ √
Zeit-Kontrolle (Plan/Ist Vergleich) √ √
¨
Ubersicht ¨
uber Instanzen: Welche Bearbeiter
sind den Aktivit¨
aten zugeordnet?
√ √
aSiehe Abbildung 3.5
Tabelle 3.2.: ¨
Ubersicht ¨
uber die Fragestellungen und Aufgaben der Benutzergruppen – Teil 1 (Be-
arbeiter/Anwender, Prozessverantwortlicher/Abteilungsleiter, Management)
29
3. Anforderungsanalyse
Aufgabe (Fragestellung) Aufgabentyp Detailgrad
IT
Entwerfena
Entscheiden
Informieren
¨
Ubersicht
Zusammenhang
Details
Welche Daten fallen im Laufe eines
Prozesses an?
√ √ √
Welche Anwendungen sind an welchen
Prozessen beteiligt?
√ √
Zu welchen Personen wandern die Daten? √ √
Zu welchen Systemen wandern die Daten? √ √
Externer Mitarbeiter/Kunde
Welche Meilensteine wurden in den
verschiedenen Instanzen erreicht?
√√
¨
Uberblick ¨
uber wichtige Abschnitte des
Prozesses (geeignete View)
√ √ √
Wo findet im Prozess Kommunikation
zwischen den Firmen statt?
√ √ √
Wo im Prozess ist der Mitarbeiter/Kunde
beteiligt?
√ √ √ √
Prozessmodellierer
Prozessschema entwerfen √ √
View-Bildung √ √ √
Fristen und typische Ausf¨
uhrungsdauer
festlegen
√ √ √
Schema¨
anderungen durchf¨
uhren √ √
aSiehe Abbildung 3.5
Tabelle 3.3.: ¨
Ubersicht ¨
uber die Fragestellungen und Aufgaben der Benutzergruppen – Teil 2 (IT,
Externer Mitarbeiter/Kunde, Prozessmodellierer)
3.2.1. Bearbeiter / Anwender
Die Bearbeiter ben¨
utzen die Prozessvisualisierung haupts¨
achlich als Informationssystem.
Es werden auch anhand der gelieferten Informationen Entscheidungen getroffen, in welcher
Reihenfolge Aufgaben bearbeitet werden. Meist sind die Nutzer an Detailinformationen
von einzelnen Aktivit¨
aten interessiert oder am Zusammenhang ihrer Aufgaben mit denen
anderer Bearbeiter in der Prozesskette.
3.2.2. Prozessverantwortlicher / Abteilungsleiter
Die Aufgaben dieser Nutzergruppe lassen sich grob in zwei Bereiche aufteilen, die norma-
len administrativen Aufgaben eines Abteilungsleiters und Arbeiten am System, wie die
30
3.3. Zusammenfassung
Bildung von Views f¨
ur andere Bearbeiter oder ¨
Anderungen am Prozessschema. Adminis-
trative Aufgaben sind ¨
Uberpr¨
ufungen ob Fristen oder Kostengrenzen eingehalten werden
k¨
onnen, welche Fortschritte zu verzeichnen sind oder wie die Arbeit unter den Mitarbeitern
aufgeteilt ist.
3.2.3. Management
Das Management wird wenig Interesse an ausf¨
uhrlichen Details von Prozess-Spezifikatio-
nen haben. Um einen Gesamt¨
uberblick zu erm¨
oglichen, braucht ein Manager Werkzeu-
ge, um Abl¨
aufe von den Details abstrahierend zusammenzufassen (Aggregation). Ideal
sind Multi-Instanz-Ansichten, die die wichtigsten Informationen zum Fortschritt der Pro-
zessabl¨
aufe liefern. Die wichtigsten Prozessaspekte f¨
ur das Management sind Fortschritt,
Zeitplanung, Mitarbeiter und Kosten.
3.2.4. IT
Aufgaben, die sich durch Prozessvisualisierung erledigen lassen, sind sicher nur ein klei-
ner Teilausschnitt des Aufgabenspektrums von IT-Verantwortlichen. Prozess-Monitoring,
Data-Mining und spezialisierte Datenbankabfragen d¨
urften wesentlich wichtigere Informa-
tionsquellen darstellen. Daher listet die Tabelle 3.3 auch nur wenige beispielhafte Aufgaben
auf, die sich per Prozessvisualisierung l¨
osen lassen.
3.2.5. Externer Mitarbeiter / Kunde
Prozessdetails spielen in diesem Kontext nur selten eine Roll; das Informieren ¨
uber den
Auftragsstatus und Interaktionen zwischen dem Kunden und der Firma stehen im Vor-
dergrund des Interesses. Geeignete Views werden ben¨
otigt, die f¨
ur die Aufgabe nur die
wichtigsten Abschnitte im Prozessablauf detailliert zeigen.
3.2.6. Prozessmodellierer
Auch wenn der Prozessmodellierer hier nicht im eigentlichen Interesse liegt, so profitiert er
doch automatisch von guten Visualisierungsm¨
oglichkeiten. Wenn das PMS Schema¨
ande-
rungen gut unterst¨
utzt, k¨
onnen Prozesse im laufenden Betrieb st¨
andig den Erfordernissen
angepasst und verbessert werden.
3.3. Zusammenfassung
In diesem Kapitel wurde mit dem Goal-Directed-Design ein Software-Entwicklungskonzept
vorgestellt, das keinen funktionszentrierten Ansatz hat, sondern den Fokus auf die Be-
nutzerziele legt. F¨
ur dieses Entwicklungskonzept wurden Benutzerkategorien einer Pro-
zessvisualisierungskomponente aufgestellt. Die Ziele dieser Benutzergruppen werden un-
tersucht und dienen als Motivation zur Entwicklung von entsprechenden Visualisierungs-
konzepten.
31
3. Anforderungsanalyse
Im folgenden Kapitel werden einerseits existierende Visualisierungsl¨
osungen untersucht
und andererseits werden Arbeiten aus den Bereichen Wahrnehmungsforschung, Usability
und Interface-Design ausgewertet. Dies bildet die Grundlage f¨
ur die Konzeption dieser
Arbeit.
32
4
Verwandte Arbeiten
Das Thema Visualisierungskonzepte f¨
ur Prozessinformationen ber¨
uhrt vor allem zwei Be-
reiche: Einerseits die Theorie der Informationsvisualisierung und andererseits bereits exis-
tierende Visualisierungsl¨
osungen aus dem Marktumfeld von Workflow Management Syste-
men (WfMS). Eine Auseinandersetzung mit diesen Themenbereichen bildet die Grundlage
f¨
ur die Konzeption dieser Arbeit.
Den Anfang macht ein ¨
Uberblick ¨
uber die Informationsvisualisierung, indem Arbeiten aus
daran beteiligten und angrenzenden Forschungsbereichen im Hinblick auf Prozessdatenvi-
sualisierung ausgewertet werden. Dazu geh¨
oren u. a. die Kognitions- und Wahrnehmungs-
forschung, der Themenkomplex Usability-Engineering und das Interface-Design.
Im zweiten Teil dieses Kapitels werden existierende Visualisierungsl¨
osungen ausgewertet.
Dabei wird zwischen verschiedenen Software-Kategorien unterschieden. Es werden Soft-
warepakete aus dem Bereich Business Process Management (BPM) daraufhin untersucht,
welche M¨
oglichkeiten sie dem Anwender bieten, Prozesse zu visualisieren. Insbesonde-
re wird dabei auf ihre Prozessmodellierungs- und Monitoring-Komponenten eingegangen.
Weiterhin werden die Prozessmodelle der BPM Werkzeuge studiert, da sie die Grenzen der
Prozessvisualisierung festlegen. Die zweite Produktkategorie bildet Prozessneutrale Visua-
lisierungssoftware. Diese Werkzeuge sind nicht auf den Umgang mit Prozessen spezialisiert
oder festgelegt. Es gibt also kein Prozess-Modell, das die Visualisierung begrenzt. Im Hin-
blick auf ihre Eignung f¨
ur die Prozessvisualisierung werden Produkte aus dem Bereich
Leitstand-Visualisierung und Entwicklungstools f¨
ur die Eigenentwicklung von Prozess-
Visualisierungsl¨
osungen untersucht.
4.1. Informationsvisualisierung
Usability und Interface-Design sind Begriffe die sich alle unter dem Schlagwort Mensch-
Maschine-Interaktion HCI einordnen lassen. HCI ist ein interdisziplin¨
arer Forschungszweig
33
4. Verwandte Arbeiten
von Psychologen, Informatikern, Grafikern, Ergonomieexperten und Soziologen. Eine gute
Einf¨
uhrung zum Themengebiet HCI bietet Ben Shneiderman in seinem Buch ’Designing
the User Interface’ [SP05].
Die Gestaltung der Benutzerschnittstelle entscheidet letztlich ¨
uber die Produktivit¨
at der
Nutzer und der Akzeptanz des Gesamtsystems. Usability oder Softwareergonomie erhalten
bei der Softwareentwicklung mehr und mehr Gewicht.
Methoden des Usability-Engineering werden herangezogen, um die Qualit¨
at einer Software
zu messen. Fast jedes Produkt, vielleicht mit Ausnahme von Produkten, die nur f¨
ur die
interne Nutzung eines sehr begrenzten Nutzerkreises vorgesehen sind und die nicht nur
einen propriet¨
aren Werkzeugcharakter haben, muss es sich gefallen lassen, auf Benutzbar-
keit hin untersucht zu werden. Auch eine Visualisierungskomponente zur Darstellung von
Prozessen sollte im Hinblick auf gute Usability entwickelt werden. Denn die perfekte Visua-
lisierung ist nicht die, die einen Prozess in jeder nur denkbaren Art und Weise darstellen
kann, sondern die, mit der die Benutzer ihre Ziele am besten erreichen k¨
onnen.
Die Produktivit¨
at eines Unternehmens kann besonders dann gesteigert werden, wenn die
Produktivit¨
at jedes Einzelnen gesteigert wird.
4.1.1. Kognitions- und Wahrnehmungsforschung
Alles Wissen im Bereich Mensch-Maschine-Interaktion baut letztlich auf der Kognitions-
und Wahrnehmungsforschung auf. Wesentliche Erkenntnisse der Kognitionsforschung, die
in den 50er und 60er Jahren gemacht wurden, sind nach wie vor aktuell. Die wichtigsten
Prinzipien der Wahrnehmungsforschung sind seit Anfang des 19. Jahrhunderts bekannt.
Beide Forschungsfelder sind aber nach wie vor aktiv, denn immerhin sind ca. 60% unseres
Gehirns mit der Wahrnehmung, die nat¨
urlich auch eng mit der Kognition gekoppelt ist,
besch¨
aftigt.
Diese Forschungsfelder liefern Hinweise, welchen Prinzipien die Diagrammgestaltung, die
f¨
ur die Prozessvisualisierung eine wichtige Rolle spielt, folgen sollte, um gute Lesbarkeit
(engl. readability) zu gew¨
ahrleisten. Gute Kenntnis der menschlichen Wahrnehmung er-
m¨
oglicht es, darauf abgestimmte grafische Darstellungen zu erzeugen.
“Bilder sagen mehr als tausend Worte” (alte Volksweisheit)
Die Gestaltpsychologie (Gestalttheorie) begr¨
undete die heutige Wahrnehmungsforschung.
Ihre Anf¨
ange nahm sie 1912 mit der ersten wichtigen Arbeit von Max Wertheimer [Wert12],
der mit seinen Arbeiten die grundlegenden bis heute wichtigen Ideen zur Gestaltwahr-
nehmung lieferte. Gestaltwahrnehmung bezeichnet die Muster- und Objekterkennung der
menschlichen Wahrnehmung.
Aus der Gestaltpsychologie kennen wir heute die grundlegenden Prinzipien der Wahrneh-
mungsorganisation (engl. perceptual organising principles) [Ware00, S.203-212] [DOL02,
Dodd02]. Diese Prinzipien beschreiben, wie die Objektwahrnehmung beim Menschen funk-
tioniert – also wie der Mensch Elemente eines Bildes gruppiert:
34
4.1. Informationsvisualisierung
➣Gesetz der Pr¨
agnanz/guten Gestalt/Einfachheit
(engl. principle of pr¨
agnanz1)
Objekte werden am ehesten erkannt, wenn sie regelm¨
aßig, systematisch, ein-
fach oder symmetrisch sind. Dies ist das wichtigste Gestaltgesetz, es ist die
Grundlage f¨
ur alle anderen Prinzipien.
➣Gesetz der N¨
ahe (engl. principle of proximity)
Elemente, die sich in relativer r¨
aumlicher N¨
ahe zueinander befinden, werden
als zusammengeh¨
orig erkannt.
➣Gesetz der ¨
Ahnlichkeit (engl. principle of similarity)
Je ¨
ahnlicher sich Elemente in Bezug auf Form, Farbe, Helligkeit, Gr¨
oße oder
Orientierung sind, desto eher werden sie auch als zusammengeh¨
orig erkannt.
➣Gesetz der Kontinuit¨
at/guten Fortsetzung
(engl. principle of continuity/continuation)
Strukturen, die aus kontinuierlichen Konturen (also ohne abrupte Richtungs-
¨
anderungen) gebildet werden, kann das Auge eher als Objekte wahrnehmen.
➣Gesetz der Geschlossenheit (engl. principle of closure)
Geschlossene Konturen werden als Objekte erkannt, Menschen k¨
onnen aber
auch unvollst¨
andige Formen als Ganzes erkennen, indem sie die fehlenden
Teile durch fr¨
uhere Erfahrungen erg¨
anzen.
➣Gesetz der Symmetrie (engl. principle of symmetry)
Symmetrische Strukturen werden sehr viel leichter als andere erkannt.
➣Gesetz der Relativen Gr¨
oße (engl. principle of relative size)
Kleinere Elemente eines Musters werden eher als Objekte erkannt als die
gr¨
oßeren. Senkrechte und waagrechte Ausrichtung erleichtert die Erkennung
von Objekten.
➣Gesetz des gemeinsamen Schicksals
(engl. principle of common fate)
Elemente die sich gleichf¨
ormig bewegen (im Gegensatz zu anderen Elementen
der Darstellung) werden als eine Einheit wahrgenommen.
➣Gesetz der Verbundenheit (engl. priciple of connectedness)
Zur Erg¨
anzung wird dieses Prinzip in die Liste mit aufgenommen. Die klassi-
sche Gestaltpsychologie kennt nur die Obengenannten. Es handelt sich wohl
um ein von der Gestaltpsychologie ¨
ubersehenes Gesetz. Palmer und Rock
[PR94] zeigen, dass die Verbundenheit ein st¨
arkeres Organisationsprinzip ist
als N¨
ahe, Farbe, Gr¨
oße und Form. D. h. wenn Elemente durch eine Linie ver-
bunden sind, werden sie als zusammengeh¨
orig erkannt, auch wenn sie sonst
keinerlei ¨
Ahnlichkeit aufweisen.
Diese Gestaltgesetze sollten nicht verwechselt werden mit ¨
ahnlichen Prinzipien bez¨
uglich
Tiefen- und Entfernungswahrnehmung. Dort gibt es beispielsweise auch ein ’principle of
relative size’. Es bleibt auch anzumerken, dass die Zusammenstellung dieser Gestaltgesetze
nicht als vollst¨
andig angesehen werden kann, da je nach Quelle andere Zusammenstellungen
1Der von den Deutschen Wertheimer and Koffka gepr¨
agte Begriff, wurde in der englischen Literatur so
¨
ubernommen.
35
4. Verwandte Arbeiten
der Prinzipien zu finden sind. Vollst¨
andigkeit ist aber auch nicht notwendig, da es nur
darum geht, sich die wesentlichen Prinzipien zunutze zu machen, die sich eignen, um gute
Darstellungen f¨
ur Informationen zu finden.
Auch Studien, in denen Augenbewegungen verfolgt wurden, haben zu einem besseren Ver-
st¨
andnis der grundlegenden Prinzipien von menschlicher Wahrnehmung und Erkennen
gef¨
uhrt. Auch aus diesen Studien folgt, dass Designer verwandte Informationen durch
¨
ortliche N¨
ahe, grafische Begrenzungen oder ¨
Ahnlichkeit von Helligkeit, Farbe oder Ori-
entierung gruppieren sollten. Generell sollte darauf geachtet werden, dass die grafische
Aufbereitung aller Informationselemente auf dem Bildschirm konsistent und vorhersagbar
ist [Will00].
Das zweite Forschungsgebiet, die Kognitionsforschung, liefert viele Hinweise f¨
ur das Inter-
face-Design und damit auch f¨
ur die Diagrammerstellung. Die engen Grenzen des Kurz-
zeitged¨
achtnisses [Mill56,Mill68] sind beispielsweise schon lange bekannt. Beim Interface-
Design sollte ber¨
ucksichtigt werden, dass im Kurzzeitged¨
achtnis nur etwa sieben Infor-
mationseinheiten (engl. chunks) abgelegt werden k¨
onnen. Die Wahrnehmung ist sehr eng
an das Kurzzeitged¨
achtnis gekoppelt, d. h. es sollten beispielsweise nicht zu viele Farben
gleichzeitig verwendet werden. Denn wenn das Kurzzeitged¨
achtnis, dass sich merkt wof¨
ur
die Farben stehen, ¨
uberlastet wird, verringert sich die Arbeitsgeschwindigkeit betr¨
achtlich,
da nun das Langzeitged¨
achtnis mitbenutzt werden muss. Dies gilt nat¨
urlich nicht nur f¨
ur
Farben, sondern f¨
ur alle Arten von dargestellter Information.
Die konsistente Nutzung von Farben und Formen sorgt f¨
ur Erfahrungswerte, die sich das
Gehirn merkt. Erst dadurch wird ein schnelles Erfassen von Informationen erm¨
oglicht.
Unser Wahrnehmungsapparat erm¨
oglicht uns durch eine F¨
ahigkeit, deren Auswirkungen
das Prinzip/Gesetz der Verbundenheit beschreibt, selbst durch kurzes oberfl¨
achliches An-
schauen auf den wahrscheinlichen Inhalt zu schließen [Mill68]. Das Sichern von Konsistenz
jedweder Art ist im Allgemeinen das wichtigste Konzept f¨
ur gute Benutzeroberfl¨
achen.
Wenn man versteht, wie die menschliche Objektwahrnehmung funktioniert, kann man auch
gut wahrnehmbare Informationsobjekte gestalten. Daher lassen sich aus diesen Informa-
tionen Gestaltungshinweise f¨
ur Netzplan-Diagramme (engl. node-link diagram) ableiten
[Ware00, S.225]. Geschlossene Konturen repr¨
asentieren darin Objekte oder Entit¨
aten:
1. Die Form einer geschlossenen Kontur kann den Typ einer Entit¨
at repr¨
asentieren.
2. Die Farbe einer umschlossenen Region kann den Typ einer Entit¨
at repr¨
asentieren
oder ein Attribut der Entit¨
at.
3. Die Gr¨
oße einer umschlossenen Region kann den Stellenwert der Entit¨
at repr¨
asen-
tieren oder ein einzelnes skalares Attribut der Entit¨
at.
4. Linien, die eine geschlossene Kontur in Regionen partitionieren, k¨
onnen Einzelaspek-
te einer Entit¨
at voneinander abgrenzen.
5. Regionen von geschlossenen Konturen k¨
onnen aggregiert werden, dies wird als Ver-
bundstruktur wahrgenommen.
6. Wo sich einzelne geschlossene Konturen innerhalb einer gr¨
oßeren geschlossenen Kon-
tur befinden, kann dies konzeptuelle Zugeh¨
origkeit repr¨
asentieren.
7. Geschlossene Konturen, die geordnet im Raum platziert sind, k¨
onnen eine konzep-
tuelle Ordnung widerspiegeln.
36
4.1. Informationsvisualisierung
8. Verbindungslinien zwischen Entit¨
aten repr¨
asentieren irgendeine Art von Beziehung.
9. Verbindungslinien k¨
onnen verschiedene Farben oder andere grafische Aspekte, wie
z. B. Linienst¨
arke oder Muster haben, um die Art einer Beziehung zu repr¨
asentieren.
10. Die Dicke einer Verbindungslinie kann den Stellenwert einer Beziehung ausdr¨
ucken
oder ein skalares Attribut wie z. B. einen prozentualen Beitrag oder die H¨
ohe eines
Geldtransfers.
11. Die Form von Konturen kann andeuten, dass Entit¨
aten in einer bestimmten Ver-
wandtschaft stehen, z. B. eine halbkreisf¨
ormige Einbuchtung einer Kontur und eine
dazu passende Kontur mit einer halbkreisf¨
ormigen Ausbuchtung
12. Die N¨
ahe von Entit¨
aten kann Gruppen repr¨
asentieren.
Es gibt jedoch auch Kritik an der Gestalttheorie [Huss84], denn sie hat haupts¨
achlich eine
beschreibende Gestalt, keine geschlossene Theorie. Sie hat nur eine vage Terminologie,
denn elementare analytische Kategorien werden nicht exakt definiert, wie z. B. Einfachheit
und ¨
Ahnlichkeit. Die Bewertung von Experimenten erfolgt mit offenen Wertungskategorien
wie z. B. Vertrautheit, ¨
Ahnlichkeit oder gute Figur. Die Gestalttheorie rechtfertigt sich
haupts¨
achlich durch die Anwendung von Ex-Post-Analysen.
Studien weisen aber immer wieder darauf hin, dass die Gestalttheorie die Realit¨
at gut
beschreibt. Nach Ryan und Schwartz [RS56] scheinen beispielsweise Konturen eine der
wichtigsten Aspekte unserer Wahrnehmung zu sein. Sie zeigen, dass Objekte nur anhand
ihrer Konturen deutlich schneller erkannt werden als echte fotografische Abbildungen.
4.1.2. Usability
Eine Software hat eine gute Usability, wenn sie f¨
ur den Benutzer gut benutzbar, benut-
zerfreundlich, leicht zu bedienen, zug¨
anglich, nachvollziehbar, klar verst¨
andlich, jederzeit
verf¨
ugbar und bereit ist. Dieser Versuch, Usability im Allgemeinen zu beschreiben, klingt
sehr vage und subjektiv. Nur wenn es um die Entwicklung einer bestimmten Software,
f¨
ur einen bestimmten Nutzerkreis, innerhalb eines bestimmten Kontextes geht, dann kann
systematisch vorgegangen werden.
Die ISO-Norm 9241 definiert Usability folgendermaßen [ISO 98]:
“Usability ist das Ausmaß, in dem ein Produkt durch einen bestimmten Benut-
zer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte
Ziele effektiv, effizient und mit Zufriedenheit zu erreichen.”
Um Benutzbarkeit zu erreichen, werden Messinstrumente (Usability-Metriken) ben¨
otigt.
Klassische Messinstrumente aus dem Bereich des Usability-Engineering sind z. B. Proto-
kollierungssoftware, Protokollierungsvideos, Vergleichs-/Benchmark-Aufgaben oder Frage-
b¨
ogen [Schu05].
Diese Messinstrumente liefern Daten und mit Hilfe von geeigneten Messgr¨
oßen wird Usabi-
lity dann messbar gemacht. Alle Messgr¨
oßen lassen sich in die drei schon in der Definition
von Usability genannten Bereiche unterteilen:
➣Effektivit¨
at
Wie genau und komplett ist das Ergebnis, das erreicht wurde?
37
4. Verwandte Arbeiten
➣Effizienz
Stehen Aufwand und Ergebnis in einem angemessenen Verh¨
altnis?
➣Zufriedenheit
Ist der Nutzer mit dem Produkt zufrieden und wird nicht frustriert?
Diese Aspekte spielen f¨
ur den Maßstab der Gebrauchstauglichkeit die entscheidende Rolle.
Wichtig f¨
ur die Festlegung von Messkriterien ist prim¨
ar ihre Messbarkeit [MR04]. Beispie-
le f¨
ur Messgr¨
oßen sind ben¨
otigte Zeit (f¨
ur die Erledigung einer bestimmten Aufgabe),
Fehlerraten, Flexibilit¨
at oder Erlernbarkeit.
Die Messinstrumente liefern subjektive und objektive Daten. Subjektive Daten sind die
Zufriedenheit eines Benutzers oder dessen Einstellung zur untersuchten Software. Die ob-
jektiven Daten unterteilen sich weiter in quantitativ messbare Gr¨
oßen wie Fehlerh¨
aufigkeit
und in qualitative Daten z. B. Problembeschreibungen.
Die Analyse der Usability einer Mensch-Maschine-Interaktion beginnt mit der Eingrenzung
und Untersuchung des Nutzerkreises und der Bestimmung des Kontextes, f¨
ur den die Soft-
ware geschaffen wird. Die Definition der Benutzer geschieht ¨
uber relevante Eigenschaften,
die die Benutzer untereinander abgrenzen. In erster Linie sind dies die unterschiedlichen
Aufgaben und Ziele. Aber auch Alter, Benutzungsh¨
aufigkeit oder Erfahrung (Anf¨
anger
und Experten) sind relevant. Im Kapitel 3geschah dies durch Einteilung in Benutzer-
gruppen, die sich voneinander durch die Ziele ihrer Interaktionen unterscheiden. An die
Definition dieser Interaktionsziele schließt sich die Definition der Aufgaben an, deren Erf¨
ul-
lung zum Erreichen der Benutzerziele notwendig sind. Und schließlich geh¨
ort zum Kontext
noch die Beschreibung der Arbeitsaustattung, der Arbeitsbedingungen und die Definition
der Messinstrumente. Diese letzten drei Schritte, k¨
onnen im Rahmen dieser grundlegen-
den Entwurfsarbeiten f¨
ur eine Visualisierungskomponente entfallen. In den Entwurf fließen
jedoch allgemeine Usability und Interface-Design Erkenntnisse ein.
4.1.3. Interface-Design
Im Umfeld von Usability und GUI Design hat sich Ben Shneiderman einen Namen gemacht.
Seine acht goldenen Regeln des ’Dialogue Design’ werden sehr h¨
aufig zitiert [SP05]. Gleich
die erste Regel lautet: Strebe nach Konsistenz. So breit das Spektrum an Schlagw¨
ortern
im Kontext des Interface-Design auch ist, Konsistenz ist der Schl¨
usselbegriff, um gut funk-
tionierende Mensch-Maschine-Schnittstellen zu entwickeln.
Konsistenz von Benutzerschnittstellen ist schwer zu definieren. Innerhalb einer Anwendung
k¨
onnen zwei Arten unterschieden werden:
➣Interne Konsistenz (auch engl. orthogonality)
Interne Konsistenz bezeichnet die Anforderung, dass Unterschiede und ¨
Ahn-
lichkeiten der verarbeiteten Objekte ihre Entsprechung in ihrer grafischen
Repr¨
asentation haben. ¨
Ahnliche Konzepte sollen auch ein visuelles Attribut
(z. B. Form oder Farbe) gemeinsam haben. Einzelne Objekte k¨
onnen durch
verschiedene solcher (orthogonaler) Attribute ausgezeichnet sein. Das erm¨
og-
licht dem Anwender die damit assoziierten Konzepte richtig zu rekombinieren.
➣Externe Konsistenz
Konsistenz im Sinne von ¨
Ubereinstimmungen zwischen realer Welt und der
38
4.1. Informationsvisualisierung
fiktiven Darstellung. Da die Prozessvisualisierung kaum Ber¨
uhrungspunkte
mit der realen Welt hat, ist die externe Konsistenz hier in diesem Zusammen-
hang nicht von so großer Bedeutung. In einer Darstellung, in der manuelle
und automatische Prozessschritte dargestellt werden, erh¨
alt man jedoch ei-
ne intuitive, weil f¨
ur den Mensch konsistente Darstellung wenn ein stilisiertes
Hand-Symbol, ein Kopf oder ein Mensch manuelle Aktivit¨
aten repr¨
asentieren.
Automatisch oder maschinell ausgef¨
uhrte Aktivit¨
aten k¨
onnen dagegen durch
ein ’Bildschirm und Tastatur’-Symbol oder ein Zahnrad kenntlich gemacht
werden.
In diese Kategorie f¨
allt auch die Konformit¨
at zu ¨
ublichen Konventionen der
verwendeten Plattform (z. B. Windows). Die Lernkurve ist umso niedriger, je
eher der Benutzer bekannte Konzepte wiederfindet. Die externe Konsistenz
gibt also auch den Grad der ¨
Ahnlichkeit zu Software aus demselben Kontext
an.
Viele Prinzipien des Interface-Design lassen sich letztlich auf die Schaffung von Konsistenz
zur¨
uckf¨
uhren:
“Die wichtigste Art von Konsistenz, ist die Konsistenz des Interface mit den
Erwartungen des Benutzers.” (Bruce Tognazzini)
Der sicherste Weg, die Benutzererwartungen an ein konkretes Interface herauszufinden,
ist Benutzertests (engl. user testing) durchzuf¨
uhren [Togn04]. Es gibt dennoch wichtige
allgemein g¨
ultige Designprinzipien. Anwender sollen beispielsweise das Interface verstehen
k¨
onnen, ihre Aktionen sollen f¨
ur sie vorhersehbare Folgen haben und sie m¨
ussen das Gef¨
uhl
haben, dass sie das Interface kontrollieren und nicht das Interface sie kontrolliert [SP05].
Die folgende Liste f¨
uhrt wichtige Punkte auf, die f¨
ur das Interface-Design ber¨
ucksichtigt
werden sollten. Auf die einzelnen Punkte wird anschließend kurz eingegangen:
➣Vorhersagbarkeit
➣Zur¨
uck und Undo
➣Angemessene Reaktionszeit (Antwortzeit)
➣Aufwand minimieren
➣Eindeutigkeit (engl. unambiguity)
➣Einfachheit (engl. economy)
➣Anzeige des Systemstatus
➣Fehlervorbeugung
➣Flexibilit¨
at
➣¨
Asthetisches und minimalistisches Design
Vorhersagbarkeit
Alle angebotenen Funktionen sollten f¨
ur den Benutzer zu vorhersagbaren Ergebnissen
f¨
uhren. Das f¨
angt damit an, dass die Namen von Funktionen angemessen gew¨
ahlt sind
[SP05].
39
4. Verwandte Arbeiten
Zur¨
uck und Undo
Es sollte immer einen Weg zur¨
uck geben, sei es in einer Dialogfolge oder wenn es dar-
um geht, die Auswirkungen der letzten Operation(en) r¨
uckg¨
angig zu machen. Auch bei
normalen Bedienschritten w¨
urde das Nichtvorhandensein einer solchen Funktion f¨
ur den
Anwender einen unn¨
otig hohen Aufwand darstellen. Selbst wenn zu jeder Funktion eine
komplement¨
are Funktion existiert, m¨
ussten diese einzeln aufgerufen werden. Ein ’Zur¨
uck’-
Button reduziert den Aufwand auf einen Mausklick pro Schritt. Auch eine ’Zur¨
uck’ oder
’Undo’ Funktion braucht Vorhersagbarkeit f¨
ur den Benutzer, das impliziert, dass das Pro-
gramm auch textuell anzeigen k¨
onnen sollte, welche Aktion nun r¨
uckg¨
angig gemacht wird.
Alan Cooper weißt darauf hin, dass die Undo-Funktion weit untersch¨
atzt wird. Eine m¨
ach-
tige Undo-Funktion k¨
onnte es z. B. m¨
oglich machen, nur die drittletzte Operation r¨
uck-
g¨
angig zu machen, die letzten beiden aber beizubehalten. Traditionelles Undo und Redo
ist dazu nicht in der Lage [CR03, S.161].
Angemessene Reaktionszeit
Erstaunlicherweise h¨
angt die allgemeine Produktivit¨
at nicht nur von der Reaktionszeit,
also der Geschwindigkeit des Interface ab, sondern auch von der Fehlerrate des Menschen
und wie leicht es ist, die Auswirkungen dieser Fehler wieder zu beseitigen [Mill68]. Unter-
suchungen haben gezeigt, dass Antwortzeiten von mehr als 15 Sekunden sich sehr negativ
auf die Produktivit¨
at auswirken. Die Fehlerrate steigt an und die Zufriedenheit nimmt ab.
Interaktionen die weniger als eine Sekunde dauern, k¨
onnen die Produktivit¨
at dagegen stei-
gern, allerdings f¨
uhren sie bei komplexen Aufgabenstellungen auch zu h¨
oheren Fehlerraten
[SP05, S.457].
Beim Beginn von rechenintensiven Operationen, die den Benutzer zum Warten zwingen,
sollte dies signalisiert werden, wenn m¨
oglich sogar mit Einblendung der erwarteten Dauer
der Operation. Das Interface sollte jederzeit reaktionsf¨
ahig bleiben und auch deutlich si-
gnalisieren, dass etwas geschieht. Es sollte hierbei auch eine M¨
oglichkeit f¨
ur den Benutzer
geben die Operation abzubrechen, sobald zu erwarten ist, dass sie einige Sekunden dauern
k¨
onnte. Ideal ist es, wenn Teilergebnisse schon vorab auf dem Schirm erscheinen, beim
Layouting eines Graphen dieser z. B. St¨
uck f¨
ur St¨
uck vor den Augen des Benutzers aufge-
baut wird. Dieser Punkt betrifft auch die Vorhersagbarkeit. Der Benutzer erwartet, dass
das System reagiert. Die Geduld wird maßgeblich durch Zeitr¨
aume strapaziert, in denen
sich f¨
ur den Benutzer nicht sichtbar etwas tut. Auch beim Aufbau einer langen Tabelle
erscheint dem Benutzer nur die Zeit bis zum Aufbau der ersten Bildschirmseite als Reak-
tionszeit des Systems. Die Zeit bis zur endg¨
ultigen Fertigstellung der Tabelle ist f¨
ur den
Benutzer dann nur von sekund¨
arer Bedeutung. Sobald das Interface eine erste Reaktion
zeigt, kann der Benutzer anfangen die weiteren Schritte zu planen, die Zeit vorher muss
der Benutzer erdulden.
Aufwand minimieren
St¨
andiges Design-Ziel sollte sein, den Aufwand (engl. excise) f¨
ur den Anwender zum Errei-
chen seines Zieles zu minimieren [CR03, S.135]. Seine Ziele erreicht der Benutzer dadurch,
dass er Teilaufgaben erledigt. Hier lassen sich zwei verschiedene Arten von Teilaufgaben
unterscheiden. Einige dienen direkt der Erreichung des Ziels, andere sind nur Aufwand.
Die Fenster einer Anwendung umzupositionieren ist ein typisches Beispiel f¨
ur unn¨
otigen
Aufwand, wenn dies vermeidbar oder automatisierbar w¨
are.
40
4.1. Informationsvisualisierung
Aufwand l¨
asst sich auch reduzieren, indem sich Funktionen zuletzt benutzte Eingabepara-
meter merken, oder Listen h¨
aufig benutzter Eingaben (engl. most recently used) vorhalten.
Ganz allgemein sollen Anwendungen nicht Funktionen anbieten, sondern Benutzern helfen
ihre Ziele zu erreichen (Stichwort: Goal-Directed-Design siehe Abschnitt 3.1).
Eindeutigkeit
Unzweideutigkeit der grafischen Symbole ist notwendig, um eine eindeutige Interpretation
der grafischen Repr¨
asentation zu gew¨
ahrleisten [LLW+01].
Einfachheit
Wenig unterschiedliche und einfache Symbole reduzieren die grafische Komplexit¨
at und
verbessern dadurch die Zug¨
anglichkeit [LLW+01].
Anzeige des Systemstatus
Die Anwendung sollte den Anwender jederzeit dar¨
uber informiert halten, was das Sys-
tem tut. Dies sollte innerhalb angemessener Zeit durch ein geeignetes Feedback geschehen
[NM94, Heuristic evaluation].
Fehlervorbeugung
Besser als gute Fehlermeldungen, ist es fehlertr¨
achtige Aktionen im vornherein zu ent-
sch¨
arfen oder sie durch den Benutzer best¨
atigen zu lassen [NM94, Heuristic evaluation].
Flexibilit¨
at
Erfahrene Nutzer sollten die M¨
oglichkeit haben h¨
aufig benutzte Funktionen an ihre Be-
d¨
urfnisse anzupassen [NM94, Heuristic evaluation].
¨
Asthetisches und minimalistisches Design
Dialoge sollten keine irrelevanten oder selten gebrauchten Informationen zeigen. Jede zu-
s¨
atzliche Information mindert die relative Sichtbarkeit der wichtigen Informationen [NM94,
Heuristic evaluation].
4.1.4. Styleguides und Normen
Im Abschnitt 4.1.3 wurde zuvor die Wichtigkeit von Konsistenz f¨
ur die Gestaltung von
Benutzeroberfl¨
achen geschildert. Einen maßgeblichen Beitrag dazu leistet die Einhaltung
von Normen und die Orientierung an Styleguides.
Styleguides sind Richtlinien, die f¨
ur eine konsistente Gestaltung, ergonomische Bedienung
und eine einheitliche Optik sorgen sollen. Sie bestehen h¨
aufig aus Zusammenstellungen von
Regeln und Empfehlungen zur Gestaltung von Applikationen und Dialogen. Styleguides
basieren auf Normen und Erkenntnissen aus Benutzertests [Heid02].
Gr¨
unde f¨
ur den Einsatz von Styleguides sind:
➣Sicherstellen von Qualit¨
at und Konsistenz einer Applikation
➣Konsistenz zwischen verschiedenen Applikationen
➣Reduzierte Entwicklungszeiten
41
4. Verwandte Arbeiten
➣Zufriedenheit und Bediensicherheit beim Anwender
Einige Beispiele f¨
ur Styleguides und Normen:
➣ISO 9241 Norm [ISO 98]
Diese Norm zur Qualit¨
atssicherung von Software und Webangeboten be-
schreibt in insgesamt 17 Teilen die Anforderungen an ergonomische Benut-
zerschnittstellen. Besondere Bekanntheit hat dabei der Teil 10 ’ISO 9241-
10’ erlangt, der Software-ergonomische Grunds¨
atze der Dialoggestaltung be-
schreibt. Das Entwurfskonzept des Goal-Directed-Design entspricht einer prak-
tischen Umsetzung dieses Teils der Norm.
➣W3C Web Content Accessibility Guidelines 2.0 [W3C 06b]
Das Ziel dieser Richtlinie ist es die Zug¨
anglichkeit von Webinhalten zu erh¨
o-
hen. Vor allem f¨
ur ¨
Altere und Menschen mit Behinderungen wie Blindheit
oder Farbenblindheit sollen Inhalte benutzbarer werden. Weiteres Ziel ist es,
die Inhalte unabh¨
angig vom verwendeten Anzeigemedium zu machen. Da-
mit sind Webseiten nicht nur von Browsern, sondern auch f¨
ur Screenreader,
Suchmaschinen, PDA, Drucker, etc. abrufbar/darstellbar. Die Grundprinzipi-
en dieser Norm sind: Wahrnehmbarkeit, Bedienbarkeit, Verst¨
andlichkeit und
Kompatibilit¨
at zu fr¨
uheren und k¨
unftigen Standards.
Bundesbeh¨
orden sind im Rahmen der ’Barrierefreie Informationstechnik-Ver-
ordnung’ (BITV) [BMI 02] verpflichtet, Webinhalte besonders zug¨
anglich zu
gestalten, was der Umsetzung dieser W3C Norm in Version 1.0 vom Mai 1999
entspricht.
➣Apple Human Interface Guidelines [Appl87]
Umfassende Richtlinien f¨
ur die Entwickler von MacOS-Software.
Die International Organization for Standardization (ISO) [ISO 06] hat noch viele weite-
re Normen entwickelt, die sich mit Usability-Themen auseinander setzen (z. B. ISO/TR
16982, ISO 14915, ISO 23973). Eine ¨
Ubersicht ¨
uber einige weitere der f¨
ur Usability rele-
vanten ISO-Normen liefert [Jaco03].
Die Firma Apple begann sehr fr¨
uh, faktische Standards f¨
ur die Interface-Gestaltung zu
setzen. Schon 1987 erschienen die Apple Human Interface Guidelines [Appl87]. Der Apple
Human Interface Evangelist Bruce Tognazzini [Togn92] hatte damals die Aufgabe f¨
ur Kon-
sistenz im Interface-Design zu sorgen. Er sollte die Entwickler ¨
uberzeugen, keine eigenen
Interfaces zu strukturieren, sondern sich an die Apple Richtlinien zu halten. Damals wie
heute ist diese Konsistenz die wichtigste Richtschnur, um zu m¨
oglichst intuitiv bedienbaren
Benutzerobfl¨
achen zu kommen. Diese Richtlinien werden seither aktuell gehalten.
Die Apple Guideline enth¨
alt beispielsweise auch Hinweise, wie viele Funktionen eine Soft-
ware anbieten sollte. Wenn bei der Gestaltung des Interface Probleme auftreten, empfiehlt
sie nicht alle m¨
oglichen Funktionen anzubieten, sondern nur diejenigen mit denen 80%
der typischen Nutzer ihre Ziele erreichen k¨
onnen. Diese Vorgehensweise f¨
uhre oftmals zu
deutlich einfacheren und eleganteren Oberfl¨
achen. Wo versucht wird, auch die W¨
unsche
von den restlichen 20%, den Power-Usern, zu erf¨
ullen, kann das Ergebnis m¨
oglicherweise
f¨
ur die anderen 80% unbrauchbar werden.
42
4.1. Informationsvisualisierung
4.1.5. Zusammenfassung
Gute Visualisierungsl¨
osungen beachten die St¨
arken und Schw¨
achen des menschlichen
Wahrnehmungssystems, um m¨
oglichst viele Informationen in einer Darstellung unterzu-
bringen. Sie minimieren jedoch auch den Aufwand f¨
ur das Erfassen und f¨
ur das Ged¨
achtnis
[Will94]. Usability-Betrachtungen liefern die Grundlage f¨
ur gelungenes Interface-Design.
Viele Design-Richtlinien lassen sich daher direkt aus Studien zur menschlichen Wahrneh-
mung und Kognition ableiten. Ein Schl¨
usselbegriff f¨
ur das Interface-Design ist Konsis-
tenz.
Die wichtigsten Prinzipien bei der Visualisierung sind:
➣Kontrast
Unterschiedliche Prozessaspekte auch unterschiedlich darstellen
➣Wiederholung
Die durchg¨
angige Verwendung der gleichen Konzepte f¨
uhrt zu Konsistenz
➣Ausrichtung der Elemente
Die richtige Anordnung entscheidet dar¨
uber, ob die Informationen in einem
Fluss gelesen werden k¨
onnen
Weitere wichtige Prinzipien sind:
➣Klare Darstellung von Beziehungen zwischen Prozessinformationen
➣Klare Gliederung der dargestellten Informationen
➣Klare Navigationsm¨
oglichkeiten
➣Gute Lesbarkeit
➣Gebr¨
auchliche Ausdrucksweisen
Der Kontrast l¨
asst sich auch durch das Prinzip der Eindeutigkeit (siehe 4.1.3) beschreiben.
Alle Symbole der verwendeten grafischen Notation sollten unterschiedliche Formen (Um-
risse) haben. Prinzipiell w¨
are auch Farbe als Unterscheidungsmerkmal denkbar. Formen
sind aber bessere Bedeutungstr¨
ager. Farbe ist dennoch wichtig f¨
ur die Visualisierung, aber
sie eignet sich nicht gut, um unterschiedliche Symbol-Notationen zu kennzeichnen. Sie
kann hier aber unterst¨
utzend wirken. Beispielsweise k¨
onnten die verschiedenen Symbolfor-
men als redundante Visualisierung zus¨
atzlich noch mit unterschiedlichen Farben hinterlegt
werden, was den Wiedererkennungswert erh¨
oht. Dies sollte jedoch mit Vorsicht geschehen,
da Farben leicht zu viel Aufmerksamkeit auf sich ziehen.
Die Gr¨
oße und Ausrichtung von Symbolen kann genutzt werden, um eine Bedeutung zu
transportieren. Die Ersatzrepr¨
asentation f¨
ur mehrere Aktivit¨
aten, die zusammengefasst
wurden, k¨
onnte beispielsweise etwas gr¨
oßer ausfallen, um damit anzudeuten, dass das
Symbol mehr Information in sich tr¨
agt als eine einfache Aktivit¨
at. Es gilt allerdings auch,
dass Graphen im allgemeinen ruhiger und strukturierter wirken, wenn alle Knoten von
gleicher Gr¨
oße sind.
Zusammenh¨
ange zwischen Symbolen, k¨
onnen auf unterschiedliche Arten deutlich gemacht
werden [LLW+01].
➣Symbole k¨
onnen andere Symbole enthalten
➣Symbole ber¨
uhren oder ¨
uberlappen sich
43
4. Verwandte Arbeiten
➣Symbole werden miteinander verbunden
➣Symbole werden nahe beieinander positioniert
Ein Symbol, das ein anderes enth¨
alt, kann hierarchische Beziehungen repr¨
asentieren. Ein
in den aktuellen Prozess eingeblendeter Unterprozess sollte daher umrahmt werden. Be-
schriftungen von Symbolen werden direkt im Symbol platziert, bei anderen Beschriftungs-
methoden steigt die grafische Dichte der Darstellung unn¨
otig an.
Das ¨
Uberlappen, Verbinden und in der N¨
ahe Platzieren wird nur f¨
ur nicht hierarchische Be-
ziehungen verwendet. N¨
ahe ist im Vergleich zu Verbundenheit und ¨
Uberlappen/Ber¨
uhren
kein pr¨
azises Konzept. Es k¨
onnte beispielsweise dennoch verwendet werden, um Dokumen-
te einer Aktivit¨
at zuzuordnen.
Die Anordnung der Aktivit¨
aten sollte der zeitlichen Aktivierungsreihenfolge entsprechen.
Ein orthogonales Layout f¨
ur einen Graphen eignet sich daher nicht gut, da die Aktivit¨
a-
ten in rechteckigen Strukturen angeordnet werden, die zwar sehr kompakt sind, aber die
Ausf¨
uhrungsreihenfolge nicht wiederspiegeln.
Einen empfehlenswerten Kurz¨
uberblick ¨
uber alle Aspekte, die die Lesbarkeit von Darstel-
lungen betreffen, liefert van Vliet et al. [KDV02]. Insgesamt sind Usability und Interface-
Design gut untersuchte Forschungsbereiche, sie liefern sehr viele direkt verwertbare Hin-
weise zur Entwicklung von Prozessvisualisierungsl¨
osungen.
4.2. Existierende Visualisierungslösungen
Im Folgenden soll untersucht werden, was existierende Visualisierungsl¨
osungen bieten, wel-
che Einschr¨
ankungen sie haben und inwiefern sie f¨
ur eine umfassende Prozessvisualisierung
geeignet sind.
Grunds¨
atzlich lassen sich zwei Kategorien von Software zur Prozessvisualisierung unter-
scheiden. Zum einen prozessorientierte Werkzeuge und prozessneutrale Software.
➣Prozessorientierte Visualisierungssoftware
besitzt ein vordefiniertes Prozess-Metamodell das einen festen Satz an Be-
schreibungskonstrukten enth¨
alt. Sie dient speziell dem Umgang mit Gesch¨
afts-
prozessen. Nachteile sind die durch das Metamodell begrenzte Ausdrucks-
m¨
achtigkeit und h¨
aufig nur eingeschr¨
ankte Visualisierungsm¨
oglichkeiten.
➣Prozessneutrale Visualisierungssoftware
Hierbei handelt es sich um Software zur Visualisierung von beliebigen In-
halten. Einige Werkzeuge unterst¨
utzen explizit das Anzeigen von aus Knoten
und Kanten bestehenden Graphen. Software dieser Kategorie besitzt kein zu-
grunde liegendes Prozess-Metamodell. Damit sind beliebige Prozesse darstell-
bar. Visualisierung ist teilweise nur eine von mehreren unterst¨
utzten Funk-
tionen. Nachteile sind ein hoher Initialaufwand f¨
ur das Mapping zwischen
Prozessdaten und Darstellung und das Fehlen von spezialisierten Editoren.
Die sich ergebenden Vorteile sind große Flexibilit¨
at bei der Visualisierung
von Prozessen und Herstellerunabh¨
angigkeit bei Verwendung offener Stan-
dards wie Scalable Vector Graphics (SVG) [W3C 06a].
44
4.2. Existierende Visualisierungsl¨
osungen
4.2.1. Business Process Management (BPM) Werkzeuge
Abbildung 4.1 zeigt die Kategorien f¨
ur prozessorientierte Visualisierungssoftware. Die meis-
ten Werkzeuge fallen unter die Bezeichnung BPM Werkzeuge. Am Markt existieren gr¨
oßere
Suiten wie z. B. WebSphere von IBM, die die ganze Bandbreite von Modellierung, Analyse,
Monitoring und Steuerung abdecken und spezialisierte Tools f¨
ur einzelne dieser Bereiche.
Zu einer ganz anderen Kategorie geh¨
ort Projektplanungssoftware wie MS Project.
Prozessvisualisierungs-
software
BPM Werkzeuge Projektplanung
MS Project
Prozess-Modellierung
und Analyse
BOC ADONIS
IDS Scheer AG
ARIS Toolset
IntraWare Bonapart
iGrafx
FlowCharter 2005
IBM WebSphere
Business Integretion
(WBI) Workbench
Adesso LeuSmart
Prozess-Monitoring
Bristol Technology
TransactionVision
IBM WebSphere
Business Integration
Monitor (WBI Monitor)
IDS Scheer AG ARIS
Process Performance
Manager (PPM)
Prozess-Steuerung
Staffware
WebSphere MQ
Workflow
Collaxa
Orchestration Server
Ultimus
Lotus Domino
Vitria BusinessWare
Abbildung 4.1.: Kategorisierung von Prozessorientierter Visualisierungssoftware
In den folgenden Abschnitten werden einige der am Markt befindlichen Visualisierungs-
werkzeuge kurz vorgestellt, wobei der Fokus auf der jeweiligen (Prozess-)Visualisierungs-
komponente und deren M¨
oglichkeiten, St¨
arken und Schw¨
achen liegt. Eine ausf¨
uhrliche
Analyse vieler Werkzeuge findet sich in [RR03].
Prozessmodellierung & Analyse
Werkzeuge zur Prozessmodellierung unterst¨
utzen die Designer von Gesch¨
aftsprozessen
beim Entwurf und der Verifikation auf der Grundlage eines vorgegebenen Prozess-Metamo-
dells. Analysem¨
oglichkeiten bilden die Grundlage f¨
ur eine Optimierung vorhandener Pro-
zesse.
IntraWare Bonapart
Bonapart ist Teil der IntraWare CRMSuite [Intr01]. Das in Bonapart verwendete Me-
tamodell ist objektorientiert, unterst¨
utzt aber auch die klassische Zusammensetzung aus
Funktions-, Daten-, Organisations- und Prozess-Sicht. Die Modellierung der Prozesse er-
folgt graphbasiert. Der Datenfluss wird implizit durch den Kontrollfluss modelliert (Me-
45
4. Verwandte Arbeiten
tapher: ’Weiterreichen von Dokumenten’). Prozesse k¨
onnen mittels statischer Analysen
(z. B. Konsistenzchecks) und dynamischer Analysen (in Verbindung mit Simulationen)
untersucht werden.
Visualisierung ist mit dem Prozess-Editor m¨
oglich. Bonapart kann nur Prozessschemata
visualisieren, keine Instanzen. Kanten verbinden die verschiedenen Symbole f¨
ur Aktivi-
t¨
aten, Daten, Systeme und Rollen. Es gibt keine expliziten Konstrukte zur Modellierung
von Verzweigungen und Schleifen. Die Art eines Split- oder Join-Knotens wird implizit
durch Ein-/Ausgangsbedingungen festgelegt. Es lassen sich Verzweigungswahrscheinlich-
keiten anzeigen. Parallele Verzweigungen sind implizit daran erkennbar, dass alle ausgehen-
den Kanten die ¨
Ubergangswahrscheinlichkeit 100% besitzen. Daten, Systeme und Rollen
lassen sich f¨
ur die Ausgabe wahlweise ausblenden. Die Darstellung von Symbolen l¨
asst sich
flexibel konfigurieren. Benutzerdefinierte (Aktivit¨
aten-)Attribute sind m¨
oglich und k¨
onnen
in bestimmtem Umfang auch visualisiert werden. Das Layout geschieht manuell durch den
Benutzer.
IDS Scheer AG ARIS Toolset
Das ARIS Toolset [SH99,Sche01,Sche02] und seine Zusatzkomponenten unterst¨
utzen das
klassische Sichtenmodell (vgl. Bonapart) und bietet zus¨
atzlich vielf¨
altige Erweiterungen.
Das Prozess-Metamodell basiert auf Ereignis-Prozessketten (EPK). Aktivit¨
aten die als
Funktionen dargestellt werden, m¨
ussen daher immer alternierend mit Ereignissen ange-
ordnet sein. Kontroll- und Datenfluss k¨
onnen getrennt voneinander modelliert werden.
Verschiedene Verzweigungstypen k¨
onnen explizit modelliert werden. Prozesse k¨
onnen ani-
miert werden und statisch oder dynamisch analysiert werden. Die M¨
oglichkeit zur Simu-
lation besteht ¨
uber eine Zusatzkomponente.
Die Prozessvisualisierung erfolgt in ARIS mit dem Prozess-Editor. Das Aussehen der Sym-
bole kann ver¨
andert werden, es steht aber nur eine begrenzte Auswahl zur Verf¨
ugung. Es
ist m¨
oglich die EPK-Ereignisse auszublenden, dadurch wird die Prozessdarstellung ¨
uber-
sichtlicher. Die Anzeige von benutzerdefinierten Attributen ist m¨
oglich. In der animierten
Simulation werden in begrenztem Umfang Ausf¨
uhrungszust¨
ande gezeigt. Es kann farblich
unterschieden werden, ob eine Aktivit¨
at bereits aktiviert/abgeschlossen oder ob sie noch
nicht aktiviert worden ist.
Adesso LeuSmart
Bei LeuSmart [ades01] dienen FunSoft-Netze [DGS95] als Grundlage des Prozess-Metamo-
dells. FunSoft-Netze sind abstrakte Petrinetze. Das Prozessmodell unterst¨
utzt damit Pro-
zess-, Daten und Organisationssicht. Der Datenfluss wird implizit durch den Kontrollfluss
modelliert. Eine explizite Modellierung von Kontrollflussverzweigungen ist nicht m¨
oglich.
LeuSmart bietet Prozessanimation, statische und (durch Simulation) dynamische Analy-
sen.
Die Visualisierung von Prozessen erfolgt in LeuSmart mit dem Prozess-Editor. Die konkre-
te Semantik von Verzweigungen wird aus der Visualisierung nicht ersichtlich. Die fehlende
Trennung zwischen Kontroll- und Datenfluss tr¨
agt zu un¨
ubersichtlichen Prozessdarstellun-
gen bei. Die Konfiguration der Darstellung der Symbole beschr¨
ankt sich auf eine kleine
Auswahl. Benutzerdefinierte Attribute werden nicht unterst¨
utzt. Welche vordefinierten At-
tribute angezeigt werden sollen, ist nicht konfigurierbar. Einzelne Modellelemente k¨
onnen
nicht ausgeblendet werden.
46
4.2. Existierende Visualisierungsl¨
osungen
IBM WebSphere Business Integration Workbench (WBI Workbench)
Die WBI Workbench von IBM dient der Modellierung und Analyse von Gesch¨
aftsprozessen
[Cava03,Peis05]. Das Prozessmodell basiert auf azyklischen Aktivit¨
atennetzen. Schleifen
lassen sich aber ¨
uber Spezialkonstrukte integrieren. Auch bedingte Verzweigungen werden
vom Metamodell ber¨
ucksichtigt. Kontroll- und Datenfluss lassen sich jeweils explizit mo-
dellieren. Benutzerdefinierte Aktivit¨
atenattribute sind nicht vorgesehen. Zeitliche Aspekte
k¨
onnen nur begrenzt modelliert werden. Es k¨
onnen nur einfache Deadlines in Form relati-
ver Zeitangaben angegeben werden.
Organisationsmodell und Prozessmodell k¨
onnen in Repositories verwaltet werden, somit
k¨
onnen gr¨
oßere Teams Prozessmodelle gemeinsam entwickeln. Die WBI Workbench enth¨
alt
ein UML-Modellierungswerkzeug und ein Werkzeug zur Erstellung von Benutzermasken
(Xform-Designer). Diese Masken k¨
onnen dann einzelnen Aktivit¨
aten zugeordnet werden.
F¨
ur die Optimierung von Gesch¨
aftsprozessen bietet WBI Workbench statische und dyna-
mische Analysen basierend auf Simulationen an.
Zu IBM Websphere geh¨
ort auch das WfMS MQ Workflow. Die vom Modellierungswerkzeug
WBI Workbench erstellten Prozessmodelle lassen sich dort verwenden. In MQ Workflow
laufende Instanzen lassen sich mit einer auf den Visualisierungsm¨
oglichkeiten von WBI
Workbench aufsetzenden Komponente namens IBM WebSphere Business Integration Mo-
nitor visualisieren (siehe Abschnitt auf S. 50).
Bei der Visualisierung sind benutzerdefinierte Symbole m¨
oglich. Unterprozesse lassen sich
’aufklappen’, diese werden dann unterhalb des Elternprozesses dargestellt. Bei den Ak-
tivit¨
aten wird ein Z¨
ahler sichtbar, sobald sie wegen einer Schleife mehrmals ausgef¨
uhrt
wurden. Kontroll- und Datenfluss werden konsequent getrennt durch die Verwendung un-
terschiedlicher Kantenarten. Zus¨
atzlich kann der Datenfluss auch ausgeblendet werden.
Aktivit¨
atenattribute sind per Mausklick zugreifbar.
BOC ADONIS
ADONIS [JK01,KJS96,KK01] bietet mit EPKs und einem propriet¨
aren Metamodell zwei
unterschiedliche Metamodell-Typen zur Modellierung von Gesch¨
aftsprozessen an. Des Wei-
teren z¨
ahlt ADONIS zu den Computer-Aided-Software-Engineering (CASE) Tools und
bietet damit eine ganze Reihe weiterer Modellierungswerkzeuge z. B. f¨
ur UML Aktivit¨
a-
tendiagramme und Organisationsmodelle an.
F¨
ur das EPK-Metamodell gelten die Aussagen zu ARIS (siehe Abschnitt auf S. 46). Dort
k¨
onnen Kontroll- und Datenfluss getrennt voneinander modelliert werden. Beim proprie-
t¨
aren Metamodell von ADONIS l¨
asst sich dagegen kein Datenfluss modellieren. Der Kon-
trollfluss kann hinreichend modelliert werden. Benutzerdefinierte Attribute gibt es nicht.
ADONIS bietet M¨
oglichkeiten zu statischen Analysen und Simulationen an. Die Prozess-
darstellung kann nicht konfiguriert werden.
iGrafx FlowCharter 2006
Die iGrafx Produktfamilie [iGra06] enth¨
alt FlowCharter 2006 f¨
ur die Prozessmodellierung
und SixSigma f¨
ur die Analyse und Simulation. Prozesse werden mit BPMN modelliert.
Benutzerdefinierte Aktivit¨
atsattribute sind m¨
oglich. Die Visualisierung erfolgt als BPMN-
Swimlane-Darstellung, wobei die Aktivit¨
aten je nach zugeordneter Rolle einer horizontalen
47
4. Verwandte Arbeiten
Partition zugeordnet werden. Alle Aktivit¨
aten, die einer Rolle zugeordnet sind, werden
somit ¨
ubersichtlich horizontal angeordnet.
Zusammenfassung
Die in diesen Abschnitten vorgestellten Werkzeuge erlauben Prozessmodellierung und Ana-
lyse auf semantisch hoher Ebene. Vom zugrunde liegenden Modellierungsparadigma ist die
Ausdrucksm¨
achtigkeit, die Visualisierung und deren Verst¨
andlichkeit sehr stark abh¨
angig.
Petrinetz und EPK basierte Metamodelle tragen nicht zu einer ¨
ubersichtlichen Visuali-
sierung bei. Benutzerdefinierte Aktivit¨
atenattribute sind leider nicht ¨
uberall m¨
oglich. Der
gravierendste Nachteil bei allen Modellierungswerkzeugen ist die fehlende M¨
oglichkeit zur
Visualisierung von Prozessinstanzen. ¨
Ubliche Darstellungsform f¨
ur die Prozesse ist die
Graphdarstellung, FlowCharter 2006 dagegen setzt auf eine sehr ¨
ubersichtliche Swimlane-
Darstellung.
Die vorgestellten Modellierungswerkzeuge bieten teilweise Exportschnittstellen f¨
ur WfMS
an. Einige WfMS werden im Abschnitt Prozess-Steuerung (siehe Abschnitt auf S. 49) vor-
gestellt.
Im folgenden Abschnitt werden Prozess-Monitoring Werkzeuge vorgestellt. Sie sind im
Gegensatz zu den vorgestellten Prozessmodellierungswerkzeugen in der Lage, laufende
Prozesse zu visualisieren. Der IDS Process Performance Manager (PPM) und der IBM
WebSphere Business Integration Monitor (WBI Monitor) sind eng mit den Modellierungs-
Tools aus dem jeweils gleichen Haus gekoppelt. Sie verwenden f¨
ur die Visualisierung der
Prozessinstanzen dieselbe Darstellungsform wie auf Modellierungsebene. Beide Werkzeuge
importieren die Daten zu den Prozessinstanzen aus dem jeweiligen WfMS.
Prozess-Monitoring
Process Performance Management (PPM) Werkzeuge lassen sich zum Themengebiet Pro-
zess-Monitoring einordnen. Sie erlauben eine Analyse laufender Gesch¨
aftsprozesse anhand
von Echtzeitdaten. Datenquelle sind h¨
aufig Repositories, die Informationen ¨
uber Prozesse
und Gesch¨
aftsdaten aus verschiedenen WfMS und aus Anwendungssystemen integrieren.
Der Schwerpunkt liegt dabei auf der gemeinsamen Aufbereitung von vielen Gesch¨
aftspro-
zessen mithilfe von zeit-, kosten- und qualit¨
atsbezogener Kennzahlen. Im Rahmen dieser
Untersuchung ist vor allem interessant, dass PPM-Systeme oftmals die Visualisierung ein-
zelner Prozessinstanzen erm¨
oglichen.
IDS Scheer AG ARIS Process Performance Manager (PPM)
Der ARIS Process Performance Manager (ARIS PPM) [IDS 03] erm¨
oglicht es Leistungs-
daten zu laufenden Gesch¨
aftsprozessen automatisiert zu ermitteln. Die gelieferten Infor-
mationen erm¨
oglichen system¨
ubergreifende Visualisierung und Auswertung von Prozessin-
stanzen. Schwachstellen in den Prozessen bei Kosten und Bearbeitungszeiten lassen sich so
aufdecken. Verschiedene Datenquellen wie Historiendaten und Belege werden vom ARIS
PPM Repository nach ihrer zeitlichen Abfolge sortiert und zu EPK-Prozessinstanzen zu-
sammengesetzt. Diese (virtuellen) Prozessinstanzen lassen sich visualisieren. Dazu reichert
ARIS PPM die Prozessketten mit Attributen, wie z. B. Bearbeitern, aus den hinterlegten
Prozessmodellen an. Auch einzelne Prozessinstanzen k¨
onnen visualisiert werden, allerdings
48
4.2. Existierende Visualisierungsl¨
osungen
werden nur die bisherigen Prozessverl¨
aufe wiedergegeben, zuk¨
unftige Prozessschritte feh-
len in der Darstellung. Diese Einschr¨
ankung stellt allerdings eine sehr starke Restriktion
dar.
Gesch¨
aftsf¨
alle aus dem PPM Repository, k¨
onnen an das ARIS Toolset ¨
ubergeben werden
und dort zum Re-Design von Gesch¨
aftsprozessen verwendet werden.
IBM WebSphere Business Integration Monitor (WBI Monitor)
Die WBI Monitor Komponente geh¨
ort zu MQ Workflow (siehe Abschnitt auf S. 50).
Sie erlaubt das gleichzeitige Monitoring vieler Gesch¨
aftsprozesse mittels statistischer Ana-
lysen (z. B. zu Kosten- und Zeiteigenschaften). Vor dem Kontext dieser Arbeit ist aber
eher die M¨
oglichkeit zur Visualisierung einzelner Prozessinstanzen interessant. Dabei wird
dieselbe grafische Darstellungsform wie bei WBI Workbench gew¨
ahlt (vgl. Abschnitt auf
S. 47), jedoch um farbcodierte Zustandsinformationen angereichert. Die Datengrundlage
des WBI Monitors wird einerseits durch den Zugriff auf die Modelldaten der WBI Work-
bench und andererseits durch den Zugriff auf die Ausf¨
uhrungs-/Instanzdaten (z. B. Audit
Trails) aus MQ Workflow gebildet.
Ausgew¨
ahlte Mengen von Prozessinstanzen k¨
onnen in tabellarischer Form dargestellt wer-
den. Jede Zeile repr¨
asentiert dabei eine Prozessinstanz. Die in den Spalten angezeigten
Attribute (z. B. Startzeit, Bearbeitungsdauer, Kosten und Prozessverantwortlicher) sind
konfigurierbar, jedoch werden benutzerdefinierte Attribute nicht unterst¨
utzt.
Bristol Technology TransactionVision
Vom Hersteller wird TransactionVision den Bereichen BPM und Business Activity Moni-
toring zugeordnet [Bris05]. Das Werkzeug erm¨
oglicht Monitoring und Analyse laufender
Gesch¨
aftsprozesse. Es lassen sich diverse Kenngr¨
oßen errechnen u. a. Transaktionszeiten.
Schwachstellen in den Prozessen wie ¨
Uberlastsituationen lassen sich gut erkennen. Transac-
tionVision erlaubt das ¨
Uberwachen von Service-Leveln ¨
uber komplette Gesch¨
aftstransak-
tionen. Benutzer k¨
onnen sich jederzeit ¨
uber den Status ihrer Transaktionen informieren.
Alle Daten k¨
onnen in einer Datenbank gespeichert werden. Daraus lassen sich Berichte
¨
uber Gesch¨
aftsprozesse generieren, die Auskunft ¨
uber das Zeitverhalten und ¨
uber Ver-
¨
anderungen ¨
uber verschiedene Zeitr¨
aume geben. Im Gegensatz zu ARIS PPM liegt der
Fokus auf kurz laufenden Gesch¨
aftstransaktionen und damit verbundenen Echtzeitanfor-
derungen.
Prozess-Steuerung
In diesem Abschnitt werden die Visualisierungsf¨
ahigkeiten verschiedener marktg¨
angiger
WfMS untersucht. Außerdem wird kurz auf das jeweilige Metamodell eingegangen. Die
Hauptaufgabe von WfMS ist die Prozessausf¨
uhrung, jedoch bieten die Systeme meist auch
Modellierungs- und Monitoring-Komponenten, welche zur Prozessvisualisierung zum Ein-
satz kommen k¨
onnen. WfMS bieten typischerweise keine M¨
oglichkeiten f¨
ur den Import
von produktfremden Prozess- und Laufzeitdaten, daher gestatten sie ausschließlich das
Monitoring und die Visualisierung der von ihnen ausgef¨
uhrten Prozessinstanzen.
49
4. Verwandte Arbeiten
Staffware Staffware
Bei Staffware k¨
onnen Prozesse grafisch modelliert werden. Es gibt Editor f¨
ur den Entwurf
von Bildschirmmasken und umfangreiche Schnittstellen f¨
ur den Export von Laufzeitda-
ten in externe Visualisierungskomponenten. Allerdings werden die Prozessmodelle nicht
exportiert.
Das Prozess-Metamodell ist sehr m¨
achtig. Es erm¨
oglicht nicht nur bedingte und parallele
Verzweigungen und Schleifen. Interessant sind M¨
oglichkeiten bei Frist¨
uberschreitungen
Alternativaktivit¨
aten zu starten. Datenflussbeziehungen zwischen Aktivit¨
aten werden nur
implizit festgelegt. Temporale Aspekte werden nicht ausreichend unterst¨
utzt.
Die Visualisierung laufender Prozessinstanzen ist eine Minimall¨
osung. Der Grafik ist ledig-
lich der Kontrollfluss und die aktuell ausgef¨
uhrte Aktivit¨
at zu entnehmen. Bereits ausge-
f¨
uhrte und nicht ausgef¨
uhrte Aktivit¨
aten sind nicht unterscheidbar. Aktivit¨
atenattribute
sind nicht darstellbar.
Von der Firma e-FACT GmbH wird f¨
ur Staffware eine externe Visualisierungskomponente
namens ProcessReports angeboten [e-FA00]. Diese basiert auf der Visualisierungskompo-
nente von iGrafx (siehe Abschnitt auf S. 47). Da Staffware keinen externen Zugriff auf das
Prozessmodel zul¨
asst, muss mittels eines iGrafx Tools ein zum Staffware-Prozessmodell
korrespondierender Prozessgraph erstellt und mit den Staffware-Daten verkn¨
upft werden.
Daraus resultiert eine ansprechende Swimlane-Darstellung, die nun verschiedene Zeitat-
tribute und die jeweilige Zielanwendung anzeigt. Ausf¨
uhrungszust¨
ande werden durch ver-
schieden eingef¨
arbte Aktivit¨
aten repr¨
asentiert. Der relative Zeitaufwand von abgeschlos-
senen Aktivit¨
aten wird intelligent ¨
uber unterschiedlich intensive Farbt¨
one visualisiert. Die
Darstellung ist weitgehend konfigurierbar.
Eine Prozess-Monitoring Software namens Staffware Process Monitor erm¨
oglicht die Ana-
lyse vieler Prozessinstanzen gleichzeitig. Einzelinstanzen lassen sich als EPKs darstellen.
Es handelt sich nicht um eine Eigenentwicklung, sondern um eine angepasste Version des
Process Performance Managers (PPM) von IDS Scheer (siehe Abschnitt auf S. 48).
IBM WebSphere MQ Workflow
IBM WebSphere [IBM 03b,IBM 03a] bietet vielf¨
altige Komponenten f¨
ur die Modellie-
rung (WBI Workbench siehe Abschnitt auf S. 47), das Monitoring (WBI Monitor siehe
Abschnitt auf S. 49) und die Ausf¨
uhrung von Workflows [LR99]. MQ Workflow selbst bie-
tet auch eine Oberfl¨
ache f¨
ur das Monitoring von Prozessinstanzen. Weitaus m¨
achtiger ist
jedoch der WBI Monitor. Diese und andere Zusatzkomponenten werden durch sehr viele
(offen gelegte) Import/Export Schnittstellen (siehe [IBM 03b]) f¨
ur Modell- und Instanzda-
ten angebunden. Das Metamodell wurde bereits im Abschnitt ¨
uber die WBI Workbench
beschrieben.
Vorbildlich ist die durchg¨
angig durch alle Komponenten konsistente Nutzung derselben
Modellierungs- und Visualisierungsans¨
atze. Die Visualisierung von Prozessinstanzen ist
intuitiv und konfigurierbar. Die Ausdrucksm¨
achtigkeit des Prozess-Metamodells ist einge-
schr¨
ankt.
Eine relativ neue Entwicklung ist die Unterst¨
utzung des BPEL4WS Standards [IBM,03]
zur Beschreibung von Gesch¨
aftsprozessen mit Webservices. Die IBM WebSphere Business
50
4.2. Existierende Visualisierungsl¨
osungen
Integration Server Foundation unterst¨
utzt dies seit Version 5.1 [Spal05]. Die erste Im-
plementierung fand sich beim Collaxa BPEL Orchestration Server (siehe Abschnitt auf
S. 51).
Vitria BusinessWare
Bei Vitria BusinessWare handelt es sich um ein typisches Enterprise Application Inte-
gration (EAI) Werkzeug, das allerdings Workflow-Funktionen anbietet. Es sorgt f¨
ur die
Integration von Anwendungen und Prozessen (z. B. SAP R3). F¨
ur Gesch¨
aftsprozesse ist
die Ankopplung an Anwendungssysteme wichtig, BusinessWare bietet hierf¨
ur viele Kon-
nektoren zur Anbindung an Standardsoftware (SAP R/3) und Datenbanken. Zudem gibt
es umfangreiche Exportschnittstellen f¨
ur den Process Performance Manager von IDS (siehe
Abschnitt auf S. 48).
Gesch¨
aftsprozesse werden durch UML Statecharts abgebildet, deren Zustands¨
uberg¨
ange
mittels Java codiert werden. Kontrollfl¨
usse werden also mittels Statecharts modelliert.
Diese kann BusinessWare auch aus dem CASE-Tools Rational Rose importieren. Die
Komponente Automator stellt den Prozess-Editor dar. Zustands¨
uberg¨
ange werden auf der
Grundlage von Event-Condition-Action (ECA) Regeln in Java codiert. Externe Ereignisse
(von Anwendungen) k¨
onnen gut integriert werden. Hierarchische Prozessmodelle werden
unterst¨
utzt. Der Datenfluss ist lediglich implizit definiert. Als Ausf¨
uhrungseinheiten von
Aktivit¨
aten k¨
onnen nur die beiden Entit¨
atstypen Benutzer und Gruppe genutzt werden.
Semantisch h¨
oherwertige Beschreibungskonzepte sind nicht vorgesehen.
Insgesamt bietet BusinessWare ein ausdrucksstarkes Metamodell. Jedoch sind Prozesse
nicht vollst¨
andig grafisch modellierbar und der eingebettete Java-Code f¨
uhrt zu nicht ana-
lysierbaren Modellen.
Zum Prozess-Monitoring dient die Komponente Cockpit. Alternativ k¨
onnen Prozessdaten
in ARIS PPM ¨
ubernommen werden. In Cockpit lassen sich einzelne oder mehrere Prozess-
instanzen auch mit komplexen Anfragen auswerten. Prozessgraphdarstellungen lassen sich
nicht darstellen (das verwendete komplexe Metamodell eignet sich auch nicht gut daf¨
ur).
Benutzer k¨
onnen sich Arbeitslisten anzeigen lassen.
Alternativ k¨
onnen Instanzdaten (Audit Trails) nach ARIS PPM exportiert werden (siehe
Abschnitt auf S. 48).
Collaxa BPEL Orchestration Server
Collaxa bietet eine m¨
achtige Engine f¨
ur die Definition und Steuerung von Webservice-
Flows. Technische Grundlage bildet die Gesch¨
aftsprozess-Beschreibungssprache BPEL4WS
(auch WS-BPEL) [IBM,03]. Collaxa bietet hierzu noch eigene Erweiterungen wie manuelle
Schritte und Kontrollflusskonstrukte.
Im Rahmen dieser Arbeit sind vor allem die angebotenen M¨
oglichkeiten zu Visualisierung
und Monitoring laufender Prozessinstanzen interessant. Die BPEL Console bietet u. a. auch
ansprechende visuelle Darstellungen einzelner Prozessinstanzen [Coll03]. Der Status von
Aktivit¨
aten wird sowohl farblich als auch symbolisch hervorgehoben. Temporale Aspekte
werden kaum unterst¨
utzt, da dies in BPEL4WS bisher nicht vorgesehen ist. Insgesamt
sind die gebotenen Visualisierungsm¨
oglichkeiten eher an Experten gerichtet.
51
4. Verwandte Arbeiten
Ultimus Ultimus Workflow Suite 4
Ultimus ist ein Workflow-System das speziell f¨
ur die Definition und Steuerung von Formu-
lar- und Dokumentfl¨
ussen konzipiert wurde [Ulti02]. Prozessmodelle k¨
onnen mithilfe des
Workflow Designer modelliert und angezeigt werden. Den Aktivit¨
aten k¨
onnen entweder
Windows-Anwendungen oder mit dem Ultimus Form Designer erstellte Formularvorlagen
zugeordnet werden. Mithilfe des Werkzeugs Administrator ist die Visualisierung von Pro-
zessinstanzen und umfassendes Prozess-Monitoring m¨
oglich. Daten zu Prozessinstanzen
k¨
onnen exportiert werden, Prozessmodelle dagegen nicht.
Der Ultimus Administrator erm¨
oglicht das Monitoring laufender Prozessinstanzen. ¨
Uber
ein Query-Interface kann die Menge der gerade relevanten Prozessinstanzen eingegrenzt
werden. Diese k¨
onnen ¨
uber Reports ausgewertet und analysiert werden. Einzelne Instan-
zen lassen sich als Prozessgraph darstellen. Die Aktivit¨
atenzust¨
ande sind farbcodiert. Die
Art einer Verzweigung kann der Grafik nicht entnommen werden, das Symbol f¨
ur parallele
und alternative Verzweigungen ist identisch. Die Darstellung kann mit unterschiedlichen
Zoomstufen erfolgen. Unterprozesse k¨
onnen ausgeblendet werden, die Attribute der stell-
vertretenden Aktivit¨
aten zeigen dann aggregierte Werte ihrer Sub-Workflows an (z. B.
Kosten). Interessant ist, dass sich der Anwender ¨
uber die Tabellen informieren kann, wel-
che Daten von einer bestimmten Aktivit¨
at gelesen bzw. geschrieben worden sind.
Ultimus bietet den Benutzern Arbeitslisten, in denen anstehende Aktivit¨
aten, entspre-
chend ihrer Dringlichkeit kategorisiert, angezeigt werden k¨
onnen.
IBM Lotus Workflow
Auch Lotus Workflow (LWF) zielt auf formularbasierte Workflows ab. LWF ist keine
Workflow-Engine, die Ausf¨
uhrung wird von Lotus Notes verwaltet. Daher ist die Funk-
tionalit¨
at im Vergleich zu klassischen WfMS eingeschr¨
ankt. Anstelle von beliebigen An-
wendungen k¨
onnen nur Notes Dokumente und Datenbanken angekoppelt werden. Mithilfe
eines grafischen Editors werden Prozesse modelliert. Diese k¨
onnen in einem XML-Format
exportiert werden und enthalten eine vollwertige Beschreibung des Prozesses.
Die M¨
achtigkeit des Metamodells ist f¨
ur einfache formularbasierte Workflows ausreichend.
Der Datenfluss wird implizit definiert. Zeitaspekte werden nicht unterst¨
utzt.
LWF bietet eine Visualisierungskomponente f¨
ur das Monitoring laufender Prozessinstan-
zen. Die verwendeten Symbole sind konfigurierbar. Unterst¨
utzte Aktivit¨
atenzust¨
ande sind
lediglich ’nicht gestartet’ und ’gestartet’ (farblich codiert). Pop-up-Fenster zeigen zuge-
h¨
orige Attribute an. Termin¨
uberschreitungen sind nicht darstellbar. Insgesamt bietet der
Viewer interessante Ans¨
atze, was Konfigurations- und Visualisierungsm¨
oglichkeiten an-
geht.
4.2.2. Projektplanung
Die behandelten Prozessmodellierungswerkzeuge und WfMS unterst¨
utzen Zeitaspekte und
deren Visualisierung nicht ad¨
aquat. Daher wird an dieser Stelle exemplarisch das Projekt-
Management-Werkzeug MS Project betrachtet.
52
4.2. Existierende Visualisierungsl¨
osungen
Microsoft MS Project
MS Project ist ein Projektplanungs- und Verwaltungswerkzeug [Schw03]. Projekte wer-
den durch sequenzielle oder parallele Vorg¨
ange (Aktivit¨
aten) modelliert, denen eine Zeit-
dauer, Ressourcen und ein Bearbeiter zugeordnet werden k¨
onnen. Das Projekt wird als
Gantt-Diagramm (Balkendiagramm) dargestellt, d. h. jede Aktivit¨
at wird durch einen Bal-
ken repr¨
asentiert, dessen L¨
ange der geplanten Dauer der Aktivit¨
at entspricht. Datenfl¨
usse
k¨
onnen nicht erfasst werden. Die Zuordnung von Bearbeitern und Ressourcen ist jedoch
m¨
oglich. Bedingte Verzweigungen und Schleifen k¨
onnen nicht modelliert werden. Laufzeit-
daten werden nicht verwaltet, Projektfortschritte werden manuell erfasst. Sie erscheinen
als schwarze Balken innerhalb der Aktivit¨
atenbalken. Temporale Aspekte werden gut un-
terst¨
utzt, z. B. lassen sich Pufferzeiten und Fristen darstellen. Die Aktivit¨
aten k¨
onnen
hierarchisch angeordnet werden, ’Unterprozesse’ lassen sich ausblenden.
4.2.3. Prozessneutrale Visualisierungssoftware
Software-Tools dieser Kategorie haben kein zugrunde liegendes Prozess-Metamodell. Sie
sind daher nicht direkt vergleichbar mit den zuvor genannten Tools. Da es in diesem
Dokument aber um die Visualisierung von Prozessinformationen geht, denen ein Prozess-
Metamodell zugrunde liegt, beschr¨
ankt sich die Betrachtung dieser Werkzeuge einzig auf
die Art und Weise wie hier Prozesse visualisiert werden und darauf, ob die verwende-
ten Visualisierungskonzepte auch auf die Darstellung von modellierter Prozessinformati-
on ¨
ubertragbar sind. Die Verwendung prozessneutraler Visualisierungssoftware verursacht
einen h¨
oheren Initialaufwand als bei BPM-Werkzeugen, bietet gegen¨
uber solchen prozess-
orientierten Ans¨
atzen mit ’starrem’ Metamodell und eingeschr¨
ankter Visualisierungskom-
ponente aber auch zahlreiche Vorteile. Insbesondere l¨
asst sich eine an die Bed¨
urfnisse der
jeweiligen Anwendung angepasste Prozessvisualisierung erzielen.
Leitstand-Visualisierung
In Abschnitt 2.2 wurden verschiedene Ans¨
atze zur Prozessvisualisierung diskutiert. Dabei
wurden auch Dynamische Darstellungen erw¨
ahnt. Die folgenden Werkzeuge unterst¨
utzen
die Entwicklung solcher Darstellungen.
Nat¨
urlich k¨
onnen mithilfe solcher Systeme aber auch ’normale’ Prozessdarstellungen er-
zeugt werden, die sich f¨
ur das Echtzeit-Monitoring von Prozessinstanzen eignen.
in GmbH sphinx open
Sphinx open (in GmbH) [in -03] erlaubt die Echtzeit-Visualisierung von 2D-Grafiken f¨
ur
das Web und die dynamische Anbindung dieser Grafiken an beliebige Datenbest¨
ande. Bis-
herige Einsatzgebiete von sphinx open sind die Visualisierung von Prozessleitsystemen,
Produktionsabl¨
aufen, Verkehrsleitsystemen sowie von Steuerungs- und ¨
Uberwachungssys-
temen in Energieversorgungsnetzen. Aufgrund seiner generischen Architektur und An-
wendungsneutralit¨
at eignet sich sphinx open prinzipiell aber auch f¨
ur die Visualisierung
komplexer Entwicklungsprozesse. Mit dem leistungsf¨
ahigen Grafikeditor von sphinx open
k¨
onnen SVG Grafiken importiert oder aber eigene anspruchsvolle 2D-Vektorgrafiken er-
zeugt werden. Prinzipiell k¨
onnen somit auch Prozessdiagramme realisiert werden. Die ein-
zelnen Objekte der Darstellung k¨
onnen dynamisch ¨
uber das sphinx open API manipuliert
53
4. Verwandte Arbeiten
werden. Objekte k¨
onnen gruppiert und kombiniert werden und als Schablonen abgelegt
werden. Dies ist auch f¨
ur die Erstellung von Prozessdiagrammen n¨
utzlich. Den Objekten
lassen sich ¨
uber das API andere Farbattribute zuweisen, sie lassen sich drehen und ver-
schieben. Das sp¨
atere Verhalten l¨
asst sich auch im Editor simulieren. Sphinx open API
ist als Java-Klassenbibliothek, als JavaBean und als C/C++ -Bibliothek verf¨
ugbar. Damit
lassen sich, die mit dem Editor erstellten Grafiken in eigene Anwendungen integrieren. Mit
den ca. 300 angebotenen Funktionen d¨
urfte nahezu jede Visualisierungsanforderung erf¨
ullt
werden. Beispielsweise k¨
onnen neue Grafikobjekte zur Laufzeit erstellt werden und es ist
stufenloses Zoomen in den Grafiken m¨
oglich. F¨
ur Sphinx open existieren Erweiterungs-
module, wie DConnect zur komplexen Datenanbindung (JDBC, Socket, Bussysteme etc.)
oder Controls zur Erstellung interaktiver Steuerelemente. sphinx EMP ist ein Enterprise
Monitoring Portal. Es erfasst ¨
uber Standardschnittstellen und Adaptoren f¨
ur propriet¨
are
Systeme Prozessdaten, Daten aus Produktivsystemen, Leitsystemen und Data-Warehouses
in einer Datenbank. Diese Daten werden zentral aufbereitet und ¨
uber das Inter-/Intranet
auch personalisiert zur Verf¨
ugung gestellt.
COPA-DATA GmbH zenOn
Die Software zenOn [COPA06] wurde speziell f¨
ur den Bereich der Industrieautomation
entwickelt. Anwendungsbereiche gehen von Maschinensteuerungen bis hin zu Leitstand-
visualisierungen. Die Darstellung kann anstatt ¨
uber die Visualisierungskomponente auch
¨
uber Webseiten erfolgen. Die Programmier-Schnittstellen sind insgesamt weniger m¨
achtig
als die Sphinx open L¨
osung.
Gefasoft GraphPic
GraphPic [Gefa04] ist ein modulares System f¨
ur das Monitoring technischer Anlagen, die
Messwerterfassung (MDE) und f¨
ur Leitst¨
ande in der Fertigungsumgebung. Grundlage des
Systems sind ein Grafikeditor und ein Modul zur dynamischen Darstellung der Grafiken.
Messwerte k¨
onnen zur Erfassung und Archivierung in einer Datenbank abgelegt werden.
Diese Daten k¨
onnen angezeigt und ¨
uber Diagramme analysiert werden.
Inosoft VisiWinNET
VisiWinNET [Inos03] zielt, ebenso wie die beiden vorangehend vorgestellten Systeme, auf
die Realisierung einfacher Bedien- und Monitoring-Applikationen bis hin zu komplexen
Leitstandanwendungen. Auch ansonsten bestehen viele Gemeinsamkeiten zu zenOn und
GraphPic. Die Visualisierung basiert auf Visual Basic oder C#, ActiveX und diversen
Standardschnittstellen (u.a. COM / DCOM, ODBC).
Visualisierungskomponenten
Im Folgenden werden einige kommerzielle Komponenten vorgestellt, die sich in Eigenent-
wicklungen f¨
ur die Prozessvisualisierung integrieren lassen, um als Visualisierungsgrund-
lage zu dienen.
ILOG Views
Die Firma ILOG bietet Grafikbibliotheken mit Programmierschnittstellen f¨
ur C++ und
Java an [ILOG06]. Diverse Diagramme (z. B. Kuchen- und Liniendiagrammen) und die
54
4.2. Existierende Visualisierungsl¨
osungen
f¨
ur die Prozessvisualisierung wichtigen Graphdarstellungen (mitsamt Layouting), BPMN-
Swimlane-Darstellungen und Gantt-Diagramme lassen sich erzeugen. Die erzeugten Gra-
fiken lassen sich f¨
ur die webbasierte Anzeige nach SVG exportieren. Die Firma bietet
außerdem einen frei verf¨
ugbaren BPMN-Modeller zum Erstellen von Prozessen in BPMN-
Notation an. F¨
ur die Visualisierung von Prozessdaten und Organisationsstrukturen ist das
angebotene hierarchische Layout interessant. Auch inkrementelles Layout und die Anima-
tion von Ver¨
anderungen am Layout werden unterst¨
utzt.
yWorks yFiles
yFiles ist eine umfangreiche Java Klassenbibliothek [yWor06b], die Layout-Algorithmen
und Komponenten bereitstellt f¨
ur die Visualisierung von Graphen. Weiterhin enth¨
alt sie
auch eine große Sammlung von Graphenalgorithmen. Unter den unterst¨
utzten Layout-
Algorithmen sind hierarchisches und orthogonales Layout f¨
ur die Graphdarstellung inter-
essant. Auch zyklische Graphen werden unterst¨
utzt. Das hierarchische Layout unterst¨
utzt
auch die Anordnung in Swimlanes. Inkrementelles Layout und Animation werden ebenfalls
unterst¨
utzt. Weiterhin sind die in der Bibliothek enthaltenen Routing-Algorithmen wei-
testgehend konfigurierbar. Es lassen sich auch nachtr¨
aglich weitere Kanten zu existierenden
Graphen hinzuf¨
ugen. Zusatzmodule erweitern die Funktionalit¨
at z. B. um die M¨
oglichkeit
der Ausgabe als SVG-Grafik. Eine Dokumentation der API findet sich in [yWor06a].
oreas GoVisual
GoVisual ist eine plattformunabh¨
angige Grafikbibliothek zur Visualisierung von Graphen
mit Programmierschnittstellen f¨
ur C++, Java, .NET sowie COM [orea04]. Es werden
verschiedene Layout-Algorithmen unterst¨
utzt, beispielsweise hierarchisches Layout und
orthogonales Layout. Allerdings werden Graphen mit Untergruppierungen (engl. nested
graph) nur f¨
ur das orthogonale Layout unterst¨
utzt.
AbsInt aiSee
aiSee der Firma AbsInt ist das kommerzielle Nachfolgeprodukt [AbsI06] des an der Univer-
sit¨
at des Saarlandes entwickelten VCG-Projektes (Visualisierung von Compiler Graphen).
Ein hierarchisches Layout f¨
ur die Graphdarstellung wird unterst¨
utzt, ebenso wie zykli-
sche Graphen, Untergruppierungen und animierte Layout-Ver¨
anderungen. Die Entwickler
betonen die schnellen Algorithmen und die Eignung f¨
ur große Graphen (bis zu 1 Million
Knoten). Ein Export nach SVG ist m¨
oglich. Die enthaltene Visualisierungskomponente
erm¨
oglicht eine Fish-Eye Ansicht. Inkrementelles Layout wird nicht unterst¨
utzt. Knoten
k¨
onnen nur einen Bezeichner tragen. Beschriftete Kanten werden nicht unterst¨
utzt.
4.2.4. Zusammenfassung
Aus der Untersuchung diverser Prozessmodellierungswerkzeuge wurde deutlich, dass diese
ausschließlich Prozessschemata visualisieren k¨
onnen, Instanzdarstellungen sind nicht m¨
og-
lich. Die Modellierung erfolgt meist anhand von Prozessgraphdarstellungen. Die Modellie-
rungskomponente von iGrafx (siehe Abschnitt 4.2.1) setzt auf eine Swimlane-Darstellung.
MS Project eine Software aus dem Bereich Projektplanung liefert die Erkenntnis, dass auch
Gantt-Diagramme sehr m¨
achtige Werkzeuge darstellen, um Zeitaspekte von Prozessen zu
visualisieren.
55
4. Verwandte Arbeiten
Werkzeuge zum Prozess-Monitoring unterst¨
utzen die Visualisierung von einzelnen Pro-
zessinstanzen, jedoch bestehen f¨
ur die Darstellung nur sehr wenige Freiheitsgrade. Die
gebotenen Visualisierungs- und Interaktionsm¨
oglichkeiten sind im Allgemeinen nicht be-
sonders ansprechend und nur begrenzt konfigurierbar. Diese Ergebnisse sind allerdings
nicht verwunderlich, die St¨
arke solcher Monitoring-Software ist eher die prozess¨
ubergrei-
fende Analyse. Der WBI Monitor erlaubt es, Informationen zu Prozessinstanzen in einer
konfigurierbaren Tabelle ¨
ubersichtlich darzustellen. Ultimus zeigt den Einsatz von Tabellen
als sortierte Arbeitslisten. Ein weiterer interessanter Aspekt ist, dass in den Werkzeugen
Views auf virtuelle Prozessinstanzen hergestellt werden. Das heißt, Einzelprozesse werden
zu einem virtuellen Verbundprozess zusammengeschlossen und in dieser Form untersucht.
Weiterhin ist der Aufbau von Process-Warehouses ein guter Ansatz f¨
ur die Prozessda-
tenintegration [Miha05]. Das Problem der meisten existierenden L¨
osungen ist denn auch,
dass sie meist nur die eigenen Prozessmodelle visualisieren k¨
onnen, das Ziel aber ist eine
system¨
ubergreifende Visualisierung.
Die betrachteten Architekturen zur Prozess-Steuerung erm¨
oglichen durch offene Schnitt-
stellen den Zugriff auf Prozessdaten. Dadurch wird es prinzipiell m¨
oglich, externe Visua-
lisierungskomponenten f¨
ur die Darstellung der Prozessinstanzen zu verwenden. Leider ist
nur der Import von Prozessmodellen m¨
oglich, jedoch nicht der Import von Laufzeitdaten.
Damit kommen die integrierten Visualisierungskomponenten nicht f¨
ur die system¨
ubergrei-
fende Visualisierung in Frage.
Keines der vorgestellten Systeme erf¨
ullt Anforderungen an die Visualisierung von Prozess-
instanzen wie:
➣Flexible Konfigurierbarkeit der Darstellungen
➣Dynamisches Ein-/Ausblenden einzelner Prozessaspekte (z. B. Datenfluss, Aktivit¨
a-
tenattribute)
➣Bildung von Views
➣Einbeziehung zeitlicher Aspekte (z. B. Visualisierung von Frist¨
uberschreitungen)
➣Hohe Ausdrucksm¨
achtigkeit des zugrunde liegenden Metamodells
Die vorgestellten Leitstandvisualisierungsl¨
osungen dagegen, zeichnen sich gerade durch
eine hohe Konfigurierbarkeit aus, sie eignen sich allerdings von ihrer Funktionalit¨
at her
besser f¨
ur das Monitoring industrieller Fertigungsprozesse als f¨
ur die Visualisierung von
Prozessinstanzen. Die in Abschnitt 2.2 vorgestellten dynamischen Darstellungen sind ihre
Dom¨
ane.
Als Basis f¨
ur die Darstellung von Prozessgraphen, in einer Prozessvisualisierungskompo-
nente, sind Visualisierungsl¨
osungen wie z. B. yFiles, sehr gut geeignet. Sie erm¨
oglichen
eine flexible Konfigurierung der Darstellung. Benutzer k¨
onnen zwischen hierarchischem
oder orthogonalem Layout w¨
ahlen. Aspekte der Darstellung k¨
onnen dynamisch eingeblen-
det werden, inkrementelle Layout-Algorithmen spielen hier ihre St¨
arke aus. Jedoch muss
im Einzelfall ¨
uberpr¨
uft werden, ob die Implementierung der Visualisierungskomponenten
auch performant genug ist, f¨
ur Darstellungen mit vielen Aktivit¨
aten. Anwender tolerie-
ren sp¨
urbare Wartezeiten bei Ver¨
anderungen an der Darstellung im Allgemeinen nur sehr
wenig. Grafische Darstellungen sollten sich ohne Verz¨
ogerungen fl¨
ussig verschieben und
zoomen lassen.
56
5
Grafische Aspekte der Prozessdarstellung
In Kapitel 2wurde vorgeschlagen, grafische und strukturelle Aspekte der Prozessvisuali-
sierung zu untersuchen. Diese beiden Ans¨
atze sollen jeweils unabh¨
angig voneinander zu
einer verbesserten Prozessvisualisierung beitragen.
In diesem Kapitel werden die grafischen Aspekte diskutiert. Die grafische Repr¨
asentation
von Prozessgraphdarstellungen soll optimiert werden. Die wichtigsten Einzelaspekte von
grafischen Darstellungen sind Farben und Formen. Das Aussehen von Prozessgraphen wird
durch Notationen, die u. a. die Form von Knoten und Kanten beschreiben festgelegt. Auf
der Grundlage der in Abschnitt 4.1 vorgestellten Konzepte f¨
ur die Informationsvisuali-
sierung, wird eine grafische Notation f¨
ur die Graphdarstellung entwickelt. Diese soll der
menschlichen Wahrnehmung entgegenkommen, aber auch rein praktischen Gesichtspunk-
ten Rechnung tragen, um etwa kompakte Darstellungen zu erm¨
oglichen.
5.1. Farben
Farben sind nicht nur Gestaltungsmittel. Wenn Farben konsistent immer wieder f¨
ur diesel-
ben Dinge stehen, erh¨
ohen sie den Wiedererkennungswert. Bei der Verwendung von Farben
gilt es einiges zu beachten. Beispielsweise sollte die direkte Kombination von Vordergrund-
und Hintergrundfarbe aus den drei Grundfarben Rot, Gr¨
un und Blau unbedingt vermieden
werden. Wegen der stark unterschiedlichen Wellenl¨
angen hat das Auge Schwierigkeiten,
jeweils beide Farben zu fokussieren und scharf zu sehen [This00, S.93] (Chromostereopsis-
Effekt).
Die Farbe Rot sollte nicht f¨
ur normale Inhalte in den Darstellungen verwendet werden. Sie
bietet sich an, um wichtige Dinge zu markieren, denn das menschliche Auge ist nicht, wie
es zu erwarten w¨
are, den Verh¨
altnissen der Natur angepasst, wo verschiedenste Gr¨
unt¨
one
vorherrschen. Vielmehr hat der Mensch zu 64% Sinneszellen f¨
ur Rot, zu 34% f¨
ur Gr¨
un und
nur zu 2% f¨
ur Blau. Und das, obwohl in der Natur die Farbe Rot am seltensten vorkommt,
z. B. bei der Glut des Feuers und bei Blut [This00, S.125].
57
5. Grafische Aspekte der Prozessdarstellung
Der HSL-Farbraum bietet sich an, um aufeinander abgestimmte Farben f¨
ur die Darstellung
zu finden. Stark ges¨
attigte Farben wirken schwer und haben die Tendenz sich in den
Vordergrund zu dr¨
angen. Weniger ges¨
attigte Farben lassen sich besser als Hintergrundfarbe
einsetzen.
“Ein buntes Bild wirkt unruhig, ein Bild das aufeinander abgestimmte Farben
verwendet wirkt harmonisch und ruhig.” (Frank Thissen) [This00, S.126]
Eine Einf¨
uhrung, wie man solche Farbkombinationen generiert, liefert John December’s
Webseite [Dece05]. Eine weitere Webseite besch¨
aftigt sich auch mit der Harmonielehre, sie
bietet zum interaktiven Ausprobieren auch einen Farbmischer [RH00].
Farben sind ein wichtiges Gestaltungsmittel. Farben ziehen die Aufmerksamkeit auf sich,
das ist ein großer Vorteil. Sie k¨
onnen dazu eingesetzt werden, dass Benutzer sich schneller
orientieren und schneller zum Ziel navigieren k¨
onnen. Es ist jedoch wichtig, darauf zu ach-
ten, dass sich die Farbe gut in das Zusammenspiel mit dem anderen Gestaltungsmitteln,
also Symbolen und Text integriert. Zu viele Farben machen Darstellungen un¨
ubersichtlich.
Zum Markieren sollten, wegen der Limitierungen des menschlichen Kurzzeitged¨
achtnisses,
maximal sieben Farben gleichzeitig verwendet werden (vgl. Abschnitt 4.1.1). Es ist al-
lerdings ohnehin so, dass beim Menschen die Farbwahrnehmung auf 6 bis 12 gleichzeitig
dargestellte und dabei noch sicher unterschiedene Farben begrenzt ist. Wo dennoch zwin-
gend eine eindeutige Farbkodierung vieler unterschiedlicher Zusammenh¨
ange gefordert ist,
ist die Kombination von Farbt¨
onen, Helligkeiten und Mustern eine gute L¨
osung, eine Viel-
zahl eindeutiger Kodierungen zu erzeugen.
5.1.1. Kontraste
H¨
aufig geht es aber nicht darum Dingen explizit eine Farbe zuzuweisen, sondern dem Auge
Kontraste anzubieten, an denen es Strukturen erkennen kann. Leichte Kontraste dienen
dazu, die Struktur einer Informationsdarstellung zu betonen. Auf hohe Kontraste sollte
¨
uberall dort geachtet werden, wo Text in einer Darstellung erscheint oder wo Teile der Dar-
stellung die Aufmerksamkeit auf sich ziehen sollen. Hohe Kontraste erleichtern das Lesen
und Betrachten und helfen Erm¨
udungserscheinungen entgegenzuwirken. Ihr Einsatz sollte
aber durchaus gezielt erfolgen, da hohe Kontraste dazu f¨
uhren von anderem abzulenken,
wie Abbildung 5.1 zeigt.
Die Text in
Tabelle einer
lenkt kontrast-
vom ärmeren
Text ab Tabelle
Abbildung 5.1.: Wirkung von Kontrast in Tabellen
Eine Tabelle l¨
asst sich beispielsweise am besten lesen, wenn Text m¨
oglichst kontrastreich
erscheint und auf einen leichten Kontrast zwischen den Zeilen und Spalten geachtet wird.
58
5.2. Ebenen
Der Betrachter profitiert von diesen F¨
uhrungslinien, da sie helfen, beim Betrachten einer
Zeile nicht zu verrutschen. In hellen Farbt¨
onen hinterlegte Zellen k¨
onnen zusammengeh¨
o-
rige Informationen markieren (siehe Abbildung 5.1).
Durch Farben und Kontraste lassen sich Informationsgruppen optisch voneinander trennen
oder absichtlich einander zuordnen [CR03, S.242]. Unterschiedlich starke Kontrastabstu-
fungen k¨
onnen f¨
ur unterschiedlich starke Zusammenh¨
ange zwischen Informationen stehen.
Besonders große Kontraste dienen als bewusste Trenner zwischen Informationen (siehe
Abschnitt 5.2).
Zur Unterscheidung einander ¨
ahnlicher Informationen k¨
onnen Farben dienen, die im HSL-
Farbraum sehr nah beieinander liegen und sich nur in der Farbhelligkeit leicht unterschei-
den. Das Modifizieren der Helligkeit erzeugt einen Effekt der N¨
ahe f¨
ur das menschliche
Auge. Farben f¨
ur einander un¨
ahnliche oder gar kontr¨
are Informationen lassen sich finden,
indem man sie so w¨
ahlt, dass sie im HSL-Farbkreis m¨
oglichst weit voneinander entfernt
liegen. Genau gegen¨
uber liegt immer die Komplement¨
arfarbe mit dem gr¨
oßtm¨
oglichen
Kontrast. Der optische Effekt von Ferne kommt durch starkes ¨
Andern des Farbtones zu-
stande. Diese optische N¨
ahe (Ferne) assoziiert das Gehirn gleich mit der logischen N¨
ahe
(Ferne) der dargestellten Informationen.
5.2. Ebenen
Ziel dieser Arbeit ist es, m¨
oglichst viel n¨
utzliche Information aus Prozessinformationen
zu extrahieren und derart aufzubereiten, dass der Anwender es m¨
oglichst einfach hat, die
gesuchten Informationen zu finden. Die Prozessinformationen bestehen jedoch nicht nur
einfach aus Einzelinformationen. Aus dem Zusammenhang l¨
asst sich weitere Information
extrahieren, da zwischen den Einzelinformationen Verbindungen auf inhaltlicher Ebene
bestehen.
Letztlich ist ein Anzeigemodul f¨
ur Prozessinformationen ein Informationssystem. Die ver-
schiedenen Informationssorten, die ein Informationssystem darstellen soll, stehen in einer
Art Verwandtschaftsbeziehung (Relation) zueinander, wobei eine Informationssorte zur
anderen, entweder eine große N¨
ahe oder Distanz aufweisen kann.
Ein Beispiel hierf¨
ur sind Relationale Datenbanken, ihre Tabellen sind durch Prim¨
ar- und
Fremdschl¨
ussel untereinander verkn¨
upft. Zwei Tabellen k¨
onnen so nun direkt miteinander
verbunden sein oder aber entfernt ¨
uber mehrere andere Tabellen.
Wenn nun verschiedene Informationssorten in einer Darstellung gemischt werden, kann
man den Benutzer darin unterst¨
utzen, diese verschiedenen Informationskategorien aus-
einander zu halten. ¨
Ublicherweise geschieht dies durch unterschiedliche Notationen der
grafischen Repr¨
asentationsformen. Das menschliche Gehirn profitiert jedoch davon, wenn
m¨
oglichst viele Unterschiede erkennbar sind. Jedes erkennbare Merkmal tr¨
agt dazu bei,
dass das Gehirn Informationen kategorisiert.
Was bedeutet nun N¨
ahe und Distanz bei Prozessinformationen? Letztlich geht es um
Objekte und um ihre Beziehungen untereinander. Folgende Objekte werden in den Dar-
stellungsformen unterschieden:
➣Aktivit¨
aten
59
5. Grafische Aspekte der Prozessdarstellung
➣Ausf¨
uhrungseinheit
➣Systeme
➣Daten/Dokumente
Diese Objekte bilden die Knoten des darzustellenden Graphen1(siehe dazu auch 5.3). Der
Kontrollfluss, der die Prozessstruktur abbildet und der Daten-/Dokumentfluss bilden die
Kanten des Graphen, d. h. die Beziehungen zwischen den Objekten ab.
In einer Prozessgraphdarstellung gilt es beispielsweise die Einzelinformationen wie (Aktivi-
t¨
aten-)Knoten, Kontrollfluss und Daten-/Dokumentfluss optisch voneinander zu trennen.
Die Aktivit¨
aten und der Kontrollfluss haben dabei viel miteinander zu tun, sie stehen sich
nah.
Diese verschiedenen Informationsebenen k¨
onnen durch unterschiedliche Farbgebung dar-
gestellt werden. Dies bietet sich an, da Farben sich gut eignen, um Objekte in Kategorien
einzuordnen [KDV02]. Abbildung 1.3 (→S. 7) zeigt, dass Gruppen von ¨
ahnlichen Farben
(Farbton) f¨
ur sich jeweils nah verwandte Informationen stehen k¨
onnen. F¨
ur Dokumente
wird hier beispielsweise ein helles Gelb, f¨
ur den Dokumentfluss ein sattes Gelb verwendet.
Aktivit¨
aten und Kontrollfluss dagegen, sind in Schwarz und Graut¨
onen gehalten. Auf die-
se Weise kann der Mensch leicht zwischen Kontroll- und Datenfluss unterscheiden, aber
gleichzeitig auch wahrnehmen, dass Dokumente und Dokumentfluss zusammengeh¨
oren.
Wo mehrere solcher Farbgruppen gleichzeitig verwendet werden, sollten sie untereinander
hohe Kontraste aufweisen, um dem Auge die klare Trennung zwischen den Farbgruppen
leichter zu machen (siehe Abschnitt 5.1.1).
Van Vliet et al. [KDV02] weisen darauf hin, das bei mehreren solcher visuellen Ebenen, eine
Ebene eindeutig als Hauptebene identifizierbar sein sollte. Dies kann beispielsweise durch
leuchtende Farben, starke Kontraste, dicke Linien oder platzieren in der Darstellungsmitte
geschehen.
Unter Anwendung von Transparenz k¨
onnen sich Informationsebenen auch lokal ¨
uberlap-
pen. Damit k¨
onnen Verbindungslinien auch durch Objekte einer anderen Ebene gef¨
uhrt
werden, ohne dass die Lesbarkeit sonderlich darunter leidet. Die Linienf¨
uhrung (engl. Rou-
ting) unterliegt damit weniger Bedingungen. Linienz¨
uge k¨
onnen so k¨
urzer ausfallen und
reduzieren die Komplexit¨
at der Darstellung. Colin Ware weist jedoch auch daraufhin, das
Transparenzen auch die Wahrnehmung st¨
oren k¨
onnen [Ware00, S.222].
5.3. Notationen
Um Gesch¨
aftsprozesse darzustellen, bietet es sich an, grafische Notationen von Standards
wie BPMN [Bpmi03a] von der BPMI [Bpmi03b] oder UML 2.0 [Omg 05b] von der OMG
[Omg 05a] zu verwenden. Die erste Version des UML Standards wurde 1997 ver¨
offentlicht.
Der erste Entwurf zu BPMN erschien 2003. Die ¨
alteste Spezifikation sind die noch heute
genutzten IDEF-Sprachen [NIST93a,NIST93b]. Sie entstanden in den 80er Jahren und
wurden zuerst vom amerikanischen Verteidigungsministerium genutzt. Die beiden neueren
Standards haben den Vorteil, das die resultierenden Diagramme nicht nur von Fachleu-
ten gelesen werden k¨
onnen. Darum dienen sie dieser Arbeit ebenfalls als Grundlage der
1Es k¨
onnen auch zwecks ¨
Ubersichtlichkeit mehrere Objekte zu einem Knoten geb¨
undelt werden
60
5.3. Notationen
weiteren Betrachtungen. Notationen, die sich daran anlehnen, profitieren vom Wiederer-
kennungswert2, da UML und BPMN inzwischen eine recht hohe Verbreitung gefunden
haben und sich relativ ¨
ahnlich sind. Ein Vergleich dieser beiden Notationen findet sich in
[Whit04].
Die beste Notation f¨
ur eine Prozessvisualisierungskomponente ist aber nicht notwendiger-
weise BPMN oder UML, denn bei beiden liegt der Fokus auf Genauigkeit und Unmissver-
st¨
andlichkeit. Das Ziel dieser Arbeit gebietet jedoch als oberste Pr¨
amisse, die ¨
Ubersicht-
lichkeit beim Darstellen komplexer Prozesse zu gew¨
ahrleisten. Daher sind die folgenden
Betrachtungen f¨
ur eine geeignete Notation nur von Usability-Maßst¨
aben geleitet.
5.3.1. Knoten
Es gilt folgende Objekte in der Darstellung unterzubringen: Aktivit¨
aten, Ausf¨
uhrungs-
einheit, Systeme und Daten/Dokumente. Die erste Maßnahme zu mehr ¨
Ubersichtlichkeit,
beispielsweise gegen¨
uber BPMN, ist, alle diese Objekte in einem Aktivit¨
atenobjekt zu
kombinieren. Das bringt folgende Vorteile mit sich:
➣Eine Prozessdarstellung besteht aus weniger Objekten (Knoten)
➣Eine Prozessdarstellung besteht aus weniger verschiedenen Symbolen (¨
außerlich un-
terscheidbare Knoten)
➣Die Darstellung ist weitgehend unabh¨
angig von der Anzahl eingeblendeter Prozess-
aspekte
➣Es werden in der Darstellung keine Verbindungskanten mehr ben¨
otigt, die die ver-
schiedenen Objekte mit dem Aktivit¨
atenobjekt verbinden
In Netzpl¨
anen werden von der Wahrnehmung alle umschlossenen Konturen als Knoten
erkannt. Es geht darum, an die Wahrnehmung m¨
oglichst gut angepasste Knotenformen zu
verwenden. Ein Knoten hat eine bestimmte Form, eine bestimmte Gr¨
oße, eine bestimmte
Farbe und praktische Aspekte, wie z. B. eine gute Unterteilbarkeit f¨
ur die Darstellung von
Unterobjekten.
Eine naheliegende Form sind Rechtecke. Denn unter den Gesichtspunkten effektive Platz-
ausnutzung, guter Beschriftbarkeit und guter Unterteilbarkeit sind sie gegen¨
uber allen
anderen Formen im Vorteil.
Eckige Formen, wie Rechtecke oder sonstige Vielecke, sind letztlich Konturen, die aus Li-
nien mit abrupten Richtungs¨
anderungen bestehen. Es ist aber f¨
ur das Auge viel einfacher,
weichen Rundungen zu folgen [Ware00, S.207]. Da nun aber andere runde Formen wie
Kreis und Ellipse sich nicht so praktisch verwenden lassen, liegt es nahe, als bevorzugte
Knotenform Rechtecke mit abgerundeten Ecken zu verwenden.
Abbildung 5.2 zeigt das Ergebnis dieser Symbolintegration.
Nat¨
urlich k¨
onnen auf diese Weise auch diverse Attribute wie Kosten oder Bearbeitungs-
dauer direkt in der Darstellung angezeigt werden. Wenn alle Knoten die gleiche Gr¨
oße
aufweisen, f¨
uhrt das zu einer strukturierten ¨
ubersichtlichen Darstellung. Das Knoteninne-
re ist leicht eingef¨
arbt, um das Objekt mehr vom Hintergrund abzuheben.
2siehe Usability Kapitel 4.1
61
5. Grafische Aspekte der Prozessdarstellung
provide evaluation
planning expert
planning system
expertise
evaluation (planning)
provide evaluation
planning system
planning expert
expertise evaluation
(planning)
Abbildung 5.2.: Symbolreduktion durch Integration
Metaphern
Den Benutzern kann bei der Orientierung durch den gezielten Einsatz von Metaphern ge-
holfen werden. Der Vorteil von Metaphern ist, dass der Umgang mit ihnen nicht erlernt
werden muss. Mit Metaphern ausgezeichnete Informationen sprechen f¨
ur sich (siehe Ab-
bildung 5.3). Es ist im Allgemeinen nicht m¨
oglich, nur Metaphern zu verwenden, sobald
das der Visualisierung zugrunde liegende Metamodell benutzerdefinierte Attribute zul¨
asst.
Hier w¨
are es zu aufwendig, solchen Attributen manuell passende Metaphern zuzuordnen.
Wenn Metaphern verwendet werden sollen, bietet es sich daher an, einen Satz einfach
einpr¨
agsamer Metaphern f¨
ur die h¨
aufigsten Aktivit¨
atsattribute bereitzuhalten und alle
anderen Attribute schriftlich zu benennen.
Interface design
software developer
design guideline
Interface design
software developer
design guideline
ROLE
DOCUMENT
Abbildung 5.3.: Nutzung von Metaphern
Markierungen
H¨
aufig ist es sinnvoll, einer Darstellung mehr Aussagekraft zu verleihen, indem einzelne
Elemente besonders hervorgehoben werden. ¨
Ublicherweise geschieht dies durch besondere
Farbgebung (siehe Abschnitt 5.1) [CR03, S.242]. Ein bestimmter Informationsaspekt wird
dazu ausgewertet und je nach Ergebnis werden die Elemente in der Darstellung markiert.
Bekannt ist dieses Prinzip von Tabellenkalkulationen, diese bieten Funktionen an, um
Geldbetr¨
age gr¨
un oder rot hinterlegt darzustellen, je nachdem ob es sich um positive oder
negative Betr¨
age handelt.
Dieses Prinzip kann auch bei der Prozessvisualisierung angewendet werden. Denn f¨
ur den
Benutzer sind nicht alle Informationen gleich wichtig, was aber in einer Darstellung, in der
62
5.3. Notationen
alles gleichm¨
aßig dargestellt ist, suggeriert wird [CR03]. Abbildung 5.3 zeigt die folgenden
Markierungsm¨
oglichkeiten:
➣Farbhinterlegung
➣Umrahmungen
➣Aktivit¨
aten Ampel (Licht: rot, gelb oder gr¨
un)
➣Aktivit¨
aten Symbol
activity
property 1
property 2
Knotenmarkierungen Feldmarkierungen
activity
property 1
property 2
activity
property 1
property 2
activity
property 1
property 2
activity
property 1
property 2
activity
property 1
property 2
activity
property 1
property 2
activity
property 1
property 2
Abbildung 5.4.: Knoten und Feldmarkierungen
Die Ampel kann beispielsweise dazu dienen unterschiedliche Kosten- beziehungsweise Zeit-
spannen zu visualisieren. W¨
ahrend die ¨
ubrigen Markierungsarten eher einzelne Sachver-
halte herausstellen.
5.3.2. Kanten
Die Aufgabe von Verbindungskanten ist es, Verbundenheit zwischen Knoten auszudr¨
ucken.
Die menschliche Wahrnehmung versucht mit dem Auge Strukturen zu erfassen, dabei ori-
entiert es sich stark an eckigen Kanten. Eckige Kanten lenken die Aufmerksamkeit auf sich.
Da die Kanten eines Prozessgraphen aber in sich keine Information tragen, außer durch
eine m¨
ogliche Beschriftung, sollte es vermieden werden, dass die Darstellung der Kanten
viel Aufmerksamkeit auf sich lenkt. Bei der Darstellung von Kanten sollten daher abrupte
Richtungs¨
anderungen vermieden werden [Ware00, S.207]. Dies geht auf das Gestaltgesetz
der ’Guten Fortsetzung’ zur¨
uck. D. h. es bleibt die Wahl zwischen geraden Direktverbin-
dungen und rechtwinkliger Linienf¨
uhrung mit gebogenen Kanten. Prinzipiell m¨
oglich w¨
are
63
5. Grafische Aspekte der Prozessdarstellung
damit auch eine organische Linienf¨
uhrung, aber dem Auge f¨
allt es bei geordneterer Linien-
f¨
uhrung einfacher Strukturen zu erkennen. Abbildung 5.5 zeigt M¨
oglichkeiten, auf welche
Art und Weise sich zwei Objekte miteinander verbinden lassen.
activity A
activity B
activity D
activity C activity E
activity A
activity B
activity D
activity C activity E
activity A
activity B
activity D
activity C activity E
AB
C
activity A
activity B
activity D
activity C activity E
D
Wahrnehmungspsychologisch günstige Linienführung
Ungünstige Linienführung
Abbildung 5.5.: Variationen von Kanten
Die grafische Repr¨
asentation einer Pfeilrichtung sollte m¨
oglichst wenig Aufmerksamkeit
auf sich ziehen. Eventuell kann sogar darauf verzichtet werden, eine Pfeilrichtung abzu-
bilden. Die r¨
aumliche Anordnung der Knoten und ein expliziter Startknoten k¨
onnen die
konzeptuelle Ordnung auch ohne Pfeilspitzen repr¨
asentieren (siehe Gestaltungshinweis Nr.
7 in Abschnitt 4.1.1).
F¨
ur die folgenden Kantentypen sollten unterschiedliche grafische Repr¨
asentationen ver-
wendet werden:
➣Kontrollflusskante
Es existieren noch weitere Untertypen, wie Schleifen (engl. Loop) und Aus-
nahmen (engl. exception), die wiederum unterscheidbar sein sollen.
➣Datenflusskante
Auch hier existieren noch weitere Untertypen, wenn zwischen Zugriffstypen
wie Lesen, Schreiben unterschieden werden soll.
Die im Abschnitt 5.2 ¨
uber Ebenen schon angesprochenen Farbebenen kommen hier wieder
zum Zuge. Die beiden Obertypen von Flusskanten k¨
onnen ¨
uber unterschiedliche Farbge-
bung verschiedenen Ebenen zugeordnet werden, sodass das Auge sich auf einzelne Infor-
mationsebenen der Darstellung konzentrieren kann. Zur weiteren Abgrenzung k¨
onnen auch
unterschiedliche Linienst¨
arken, Farbhelligkeiten oder Muster zur Anwendung kommen. Es
64
5.3. Notationen
bietet sich allerdings an, diese letztgenannten Diversifikationsm¨
oglichkeiten den jeweiligen
Untertypen vorzubehalten. Eine Besonderheit stellen Kanten f¨
ur die Ausnahmebehand-
lung dar, diese geh¨
oren zwar zum Kontrollfluss, sollten aber dennoch auch farblich von
diesem getrennt werden, beispielsweise durch die Signalfarbe Rot.
Semantik
Ein sequenzieller Kontrollfluss ist leicht nachzuvollziehen. F¨
ur den Fall, dass mehrere Kon-
trollflusskanten eine Aktivit¨
at zum Ziel haben oder eine Aktivit¨
at verlassen, werden ¨
ub-
licherweise grafische Repr¨
asentationen f¨
ur die semantischen Verzweigungs- und Verkn¨
up-
fungsoperationen verwendet, um es den Anwendern zu erleichtern den Kontrollfluss einfach
nachzuvollziehen. Die m¨
oglichen Verzweigungstypen gibt das zugrunde liegende Metamo-
dell vor. Im Folgenden sind die Standardoperationen aufgelistet:
➣Oder-Verzweigung
Ein oder mehrere Pfade werden aufgrund von erf¨
ullten Bedingungen gew¨
ahlt.
➣Und-Verzweigung (Parallelisierung)
Alle ausgehenden Pfade werden gew¨
ahlt (→Alle Bedingungen sind identisch).
➣Exklusiv-Oder-Verzweigung
Genau ein Pfad wird gew¨
ahlt. Dies l¨
asst sich erreichen, indem sich die ¨
Uber-
gangsbedingungen gegenseitig ausschließen.
➣Und-Verbindung
Zur Weiterschaltung m¨
ussen alle eingehenden Pfade abgearbeitet sein (→Die
Aktivit¨
at bildet Rendezvous-Punkt).
➣Oder-Verbindung
Zur Weiterschaltung muss nur ein eingehender Pfad abgearbeitet sein.
Dies sind die ¨
ublichen Join- und Split-F¨
alle, komplexere Metamodelle k¨
onnen weitere
Routing-Regeln anbieten, etwa eine ’N-aus-M’-Join Regel.
Um die grafische Komplexit¨
at gering zu halten, sollten m¨
oglichst wenige Symbole einge-
f¨
uhrt werden. Es ist m¨
oglich, komplett auf grafische Symbole f¨
ur die Standard Join/Split-
F¨
alle zu verzichten. F¨
ur die Und-Verzweigung und f¨
ur die Und-Verbindung muss kein gra-
fisches Symbol verwendet werden, sie sind beide ohnehin nicht an Bedingungen gekn¨
upft,
die dargestellt werden m¨
ussten. Auch die anderen Verkn¨
upfungsarten k¨
onnen ohne Sym-
bol auskommen und trotzdem eindeutig sein. Bei (Exklusiv-)Oder-Verzweigungen werden
hierf¨
ur die jeweiligen Weiterschaltungsbedingungen als Kantenbeschriftungen angezeigt.
Oder-Verbindungen k¨
onnen mittels ’Oder’ als Kantenbeschriftung eindeutig gemacht wer-
den.
Weitere (komplexere) Split/Join Konstrukte k¨
onnen bei Bedarf zus¨
atzlich eingef¨
uhrt wer-
den. Zur Unterscheidung von den bereits angesprochenen Semantik-Konstrukten werden
sie durch ein kleines Verzweigungssymbol (mit entsprechender Beschriftung) eingeleitet
(Split) oder abgeschlossen (Join). BPMN nutzt einen Diamanten als Entscheidungssym-
bol, wie es aus Flussdiagrammen bekannt ist und UML einen Diamanten oder einen kleinen
Balken, je nachdem ob es sich um eine ’Oder’ oder ’Und’ Verzweigung handelt.
Abbildung 5.6 zeigt einige Variationen der Darstellungsm¨
oglichkeiten. Der Vorteil eines
dedizierten Symbols f¨
ur Oder-Verzweigungen ist, das auf die Einblendung der Bedingungen
verzichtet werden kann. Bei Bedarf sind die Bedingungen via Tooltipp abrufbar.
65
5. Grafische Aspekte der Prozessdarstellung
activity E
Und-Split / Oder-Join (1) Und-Split / Oder-Join (2)
activity A
activity B
activity D
activity E
Oder
Oder
Oder-Split (2) / N-aus-M Join
activity A
activity B
activity D
activity E
2-von-3
activity C Oder
activity C
activity A
activity B
activity D
activity C
Oder-Split (1) / Oder-Join
activity A
activity B
activity D
activity E
Bedingung Z
Bedingung X Oder
Oder
activity C Oder
Bedingung Y
ODER-Split
1. <Bedingung X>
2. <Bedingung Y>
3. <Bedingung Z>
Abbildung 5.6.: Semantik Darstellungsm¨
oglichkeiten
Blockstruktur
Bei Prozessen, die symmetrische Bl¨
ocke aufweisen, kann dem Betrachter die resultierende
Blockstruktur sehr einfach wie in Abbildung 5.7 grafisch anschaulich dargestellt werden.
Dies hilft bei komplexen Kontrollfl¨
ussen den ¨
Uberblick ¨
uber die Semantik des Prozess-
graphen zu behalten bzw. ihn in kurzer Zeit zu durchschauen. Die Abbildung zeigt auch,
dass diese Bl¨
ocke auch zu Interaktionszwecken dienen k¨
onnen. Der linke Block ist ausge-
w¨
ahlt und stellt dem Benutzer eine ’Minimieren’-Schaltfl¨
ache bereit, um die Darstellung
der Verzweigung einzuklappen.
alternative branch
alternative branch
activity A
activity B
activity D
activity Eactivity C
ODER-Split
1. <Bedingung X>
2. <Bedingung Y>
3. <Bedingung Z>
activity A
activity B
activity D
activity E
Bedingung Z
Bedingung X
activity C
Bedingung Y
Abbildung 5.7.: Verdeutlichen der Blockstruktur
66
5.3. Notationen
Kontrollflusskante
Das Prozess-Metamodell kann verschiedene Kantentypen unterscheiden. Eine Unterst¨
ut-
zung verschiedener Typen hat den Vorteil, dass bei der Visualisierung selektiv einzelne
Kantentypen dynamisch ein- und ausgeblendet werden k¨
onnen.
Die folgende Liste zeigt verschiedene Kantentypen:
➣Normale Kontrollflusskante
➣Sprungkante
➣Ausnahmekante, wird bei Ausnahmebehandlungen aktiviert
➣Schleifenkante
➣Synchronisationskante (Sync-Kante)
Bei allen Kantentypen, mit Ausnahme der Sync-Kante, handelt es sich um Ausf¨
uhrungs-
kanten auf denen die Weiterschaltung der Prozessausf¨
uhrung stattfindet. Sync-Kanten
werden eingesetzt, wenn z. B. in parallelen Zweigen gewisse Reihenfolgebeziehungen ein-
gehalten werden m¨
ussen.
Spr¨
unge, Verweise und Prozessschnittstellen
Sprungkanten repr¨
asentieren in erster Linie ebenfalls Kontrollfl¨
usse, diese ¨
Ahnlichkeit soll-
te auch in der grafischen Darstellung einer Sprungkante wiederzufinden sein. Es ist aber
denkbar, ihnen eine leicht abweichende Farbe zuzuweisen, die sofort verdeutlicht, dass es
sich hier nicht um eine normale Kontrollflusskante handelt. Es ist wichtig, dem Benutzer
anzudeuten, ob es sich um einen weiten oder einen nahen Sprung handelt. Eine Analogie
stellen Links auf Webseiten dar, der Benutzer sch¨
atzt es, wenn durch die Auszeichnung
eines Links f¨
ur ihn vorhersehbar ist, ob er mit einem Klick darauf, nur innerhalb der Sei-
te navigiert, oder ob er damit den aktuellen Bereich verl¨
asst und auf eine andere Seite
wechselt.
¨
Ublicherweise wird immer nur ein einzelner Prozess aus einer Prozesshierarchie dargestellt.
Prozesse k¨
onnen aber Sprungkanten enthalten, die von einem Prozess zu einem anderen
verweisen. Diese Verweise (Spr¨
unge) ben¨
otigen eindeutige Zielangaben. Navigation in hier-
archischen Prozessen erfordert daher einen eindeutigen Namensraum.
Zwischen drei Arten von Spr¨
ungen kann unterschieden werden3:
1. Spr¨
unge zu anderen Aktivit¨
aten innerhalb des Prozesses.
2. Spr¨
unge in benachbarte Prozesse derselben Schicht
3. Sonstige Spr¨
unge zu anderen Schichten eines hierarchischen Workflows
Fall 1 wird nur bei Bedarf eingesetzt, um innerhalb eines Prozesses lange Verbindungs-
kanten zu umgehen, die das Lesen des Prozesses erschweren. In den F¨
allen 2 und 3 kann
auch von Prozessschnittstellen gesprochen werden, da hier nicht Aktivit¨
aten das Ziel sind,
sondern andere Prozesse. Statt eines Verweises auf einen anderen Prozess, k¨
onnen die be-
teiligten Prozesse auch zu einer Gesamtdarstellung ’verwebt’ werden. Dies erscheint aber
nur bei wenig komplexen Prozessen sinnvoll. Bei Fall 2 reicht eine relative Zielangabe, bei
3Abbildung 7.7 (→S. 133) zeigt zur Verdeutlichung einen Ausschnitt aus einer Prozesshierarchie. Ein
Sprung zu einem benachbarten Prozess w¨
are hier beispielsweise von ’bewerten’ zu ’kommentieren’.
67
5. Grafische Aspekte der Prozessdarstellung
Fall 3 ist eine absolute Zielangabe aus dem Namensraum notwendig. Eine schriftliche Be-
schreibung einer absoluten Zielangabe w¨
are z. B. der Prozess <production> der obersten
Ebene besitzt einen Unterprozess <quality management>, dort soll wiederum der Unter-
prozess <change management> aufgerufen werden. Die grafischen Repr¨
asentationen der
F¨
alle 1 bis 3 zeigt Abbildung 5.8.
change
management
activity A activity B
change management
activity A activity B
change management
[<production>\<quality management>]
activity A activity B
Weiter Sprung in Prozesshierarchie (Zielangabe absolut)
Naher Sprung zu benachbartem Prozess (Zielangabe relativ)
Sprung zu anderer Aktivität
activity C
activity D activity A
activity A activity B
Sprung in Prozesshierarchie mit Rückkehr
activity D
activity B
Abbildung 5.8.: Darstellung von Prozessschnittstellen
68
5.3. Notationen
Datenflusskante
Da es Lese- und Schreibkanten gibt, sollte dies auch eine Darstellung klar ersichtlich wie-
dergeben. Zwei verschiedene, aber dennoch gen¨
ugend ¨
Ahnlichkeit aufweisende Repr¨
asen-
tationen werden also ben¨
otigt. Zwei M¨
oglichkeiten w¨
aren beispielsweise:
➣D¨
unne Lesekante und dicke Schreibkante
➣Heller Farbton der Lesekante und satter Farbton der Schreibkante
Die Symbolik soll dabei ein ¨
Uberschreiben eines Wertes andeuten, die auffallendere Linie
¨
uberschreibt die Andere.
5.3.3. Ausführungsmarkierungen
Sowohl Aktivit¨
aten, als auch Kontrollflusskanten k¨
onnen Informationen ¨
uber den Ausf¨
uh-
rungszustand transportieren.
Die m¨
oglichen Kantenzust¨
ande sind:
➣nicht aktiviert
➣aktiviert
➣deaktiviert (diese Kante wird nie durchlaufen)
Kanten kommen in den Zustand ’deaktiviert’, wenn ihr Pfad bei einer Verzweigung nicht
ausgew¨
ahlt wurde.
Die Ausf¨
uhrungszust¨
ande von Aktivit¨
aten k¨
onnen vielf¨
altiger sein. Hier nur einige Bei-
spiele:
➣nicht bereit
➣bereit
➣laufend
➣abgebrochen
➣fehlgeschlagen
➣abgeschlossen
Eine Prozessvisualisierungskomponente muss dem Anwender bei der Darstellung von lau-
fenden Instanzen die Aktivit¨
atenausf¨
uhrungszust¨
ande anzeigen. Auch bei abgeschlossenen
Instanzen ist dies hilfreich, um gew¨
ahlte und abgew¨
ahlte Verzweigungspfade im Nachhin-
ein nachvollziehen zu k¨
onnen. Die Kantenmarkierungen sind hingegen weniger wichtig,
schließlich kann durch die Zust¨
ande der Aktivit¨
aten auch auf sie geschlossen werden.
M¨
ogliche grafische Repr¨
asentationen sind Knotenfarben oder speziell eingeblendete Sym-
bole. Gegen Knotenfarben spricht, dass diese die Markierungsfunktion einschr¨
anken (siehe
Abschnitt 5.3.1). Abbildung 5.9 zeigt einige Symbole, diese k¨
onnen z. B. links oben ¨
uber
den Aktivit¨
atenknoten eingeblendet werden oder innerhalb des Knotens, links des Aktivi-
t¨
atennamens.
69
5. Grafische Aspekte der Prozessdarstellung
Abbildung 5.9.: Ausf¨
uhrungszust¨
ande von Aktivit¨
aten (bereit, laufend, abgebrochen, fehlgeschla-
gen, abgeschlossen)
5.4. Orientierung
Darstellungen sollten vom Anwender so konfiguriert werden k¨
onnen, dass die resultie-
renden Graphen von links nach rechts, oder von oben nach unten ausgerichtet angezeigt
werden k¨
onnen. Diese im westlichen Kulturkreis ¨
ublichen logischen Anordnungen zeigen
die Abbildungen Abbildung 5.11 und 5.10. Eine internationale Software sollte jedoch auch
bei Bedarf an das asiatische Denkmodell anpassbar sein und von rechts nach links laufende
Prozessdarstellungen anbieten.
Horizontale Ausrichtung Vertikale Ausrichtung
activity A
property 1
property 2
activity A
property 1 property 2
activity B
property 1
property 2
activity C
property 1
property 2
activity B
property 1 property 2
activity C
property 1 property 2
Abbildung 5.10.: Knoten bei horizontaler oder vertikaler Prozessdarstellung
Abbildung 5.11 zeigt Knotenkonfigurationen f¨
ur die vertikale und horizontale Graphdar-
stellung. Je nachdem wie viele zus¨
atzliche Attribute direkt in der Darstellung erscheinen
sollen, wird eine entsprechende Knotenrepr¨
asentation verwendet. Das Ziel der, f¨
ur die
vertikale und horizontale Darstellung, jeweils angepassten Knotenkonfigurationen ist ei-
ne effiziente Platzausnutzung, um m¨
oglichst viele Aktivit¨
aten auf einer Bildschirmseite
darstellen zu k¨
onnen.
5.5. Zusammenfassung
In diesem Kapitel wurde eine praktische grafische Notation f¨
ur Graphdarstellungen ent-
wickelt. Unter anderem wurde hierf¨
ur der effiziente Einsatz von Farben und Kontrasten
angesprochen sowie getrennte Informationsebenen beispielsweise f¨
ur Kontroll- und Daten-
fluss.
Den Ausschnitt eines Change-Management-Prozesses, sowohl in BPMN als auch im Ver-
gleich dazu die hier entwickelte Notation, zeigten schon die Abbildungen 1.2 und 1.3
(→S. 6), auf die an dieser Stelle noch einmal verwiesen wird.
70
5.5. Zusammenfassung
activity
property 1 property 2
activity
property 1
activity activity
property 1
property 2
activity
property 2property 1 property 3
activity
property 1 property 2
property 3 property 4
Platzoptimierung für horizontale Graphdarstellung
Platzoptimierung für vertikale Graphdarstellung
Abbildung 5.11.: Darstellung von Aktivit¨
atenknoten mit unterschiedlich vielen Attributen
Im folgenden Kapitel werden nun alternative Darstellungsformen f¨
ur Prozessinformationen
vorgestellt.
71
6
Darstellungsformen für Prozessdaten
Die Konzepte aus dem Kapitel 5¨
uber grafische Aspekte stehen orthogonal zu den in diesem
Kapitel behandelten Darstellungskonzepten1. Daher lassen sich all diese Konzepte f¨
ur die
Prozessvisualisierung kombinieren.
Welche Darstellungen sind f¨
ur Prozessinformationen außer den ¨
ublichen Prozessgraphen
denkbar? In Kapitel 3wurden Benutzeranforderungen herausgearbeitet. Hier soll aber eine
andere Herangehensweise gew¨
ahlt werden, um herauszufinden, welche Darstellungstypen
sinnvoll sind. Die Betrachtung der Tabelle 2.1 mit der Auflistung der Prozessinformatio-
nen zeigt, welche Informationstypen in Prozessinformtionen stecken. Daraus ergibt sich
der Ansatz, Darstellungen zu entwickeln, die jeweils einen dieser Informationsaspekte auf-
greifen und diesen gut visualisieren k¨
onnen. Das Ergebnis ist Abbildung 6.1. Sie zeigt
die verschiedenen Darstellungsformen und die Prozessinformationen, die jeweils im Fokus
stehen.
In den folgenden Abschnitten werden diese Darstellungsformen vorgestellt und ihre M¨
ach-
tigkeit diskutiert. D. h. es wird darauf eingegangen, welche Prozessinformationen ¨
uber-
haupt darstellbar sind und welche spezifischen Vorteile und Restriktionen die einzelnen
Darstellungsformen haben. Weiterhin existieren f¨
ur einige der Konzepte auch Variationen,
die diskutiert werden.
Generell ist wichtig, dass der Benutzer beim Arbeiten mit verschiedenen Darstellungen
nahtlose ¨
Uberg¨
ange beim Wechsel zwischen zwei Darstellungen vorfindet.
1Der Begriff Darstellungskonzept bezieht sich auf den strukturellen Aspekt. Von einem Visualisierungs-
konzept wird erst durch das Zusammenspiel mit vielen anderen Konzepten, wie grafischen Konzepten,
Bedienkonzepten oder dem View-Konzept gesprochen.
73
6. Darstellungsformen f¨
ur Prozessdaten
Prozesstruktur
Bearbeiter
Ressourcen (Systeme,
Applikationen)
Dokumente
Daten-/Dokumentfluss
Interaktionen
Zusammenhänge zwischen
zwei Prozessaspekten
Aktivitäteneigenschaft aus
dem Datenmodell
Zusammenhänge innerhalb
eines Prozessaspektes
Datenflußdiagramm
Zeit Kalender
Swimlane
Tabelle
Prozessgraph
Interaktionsdiagramm
Matrix
Abbildung 6.1.: ¨
Ubersicht ¨
uber die Darstellungsformen mit dargestellten prim¨
aren Prozess-
aspekten
74
6.1. Prozessgraphdarstellung
Aspekte, die beim Umschalten von einem Darstellungskonzept zum anderen m¨
oglichst
erhalten bleiben sollen, sind:
➣Gezeigter Bildschirmausschnitt
Der Benutzer arbeitet meist auf einem Ausschnitt des aktuell dargestellten
Prozesses. Wird auf eine andere Darstellung gewechselt, sollte wieder, soweit
m¨
oglich, derselbe Prozessausschnitt dargestellt werden. Dadurch l¨
asst sich
eine komplette Neuorientierung vermeiden.
➣Merkmale der aktuellen View
Falls m¨
oglich sollten die Darstellungsmerkmale ¨
ubernommen werden, etwa
ausgeblendete Prozessaspekte (z. B. Daten & Dokumente).
➣Markierte Elemente (vgl. Abschnitt 5.3.1)
Vom Benutzer markierte Elemente bleiben erhalten.
Durch einen solchen Ansatz ist der Benutzer nicht auf eine einmal gew¨
ahlte Darstellungs-
form festgelegt.
6.1. Prozessgraphdarstellung
Die St¨
arke dieser Darstellungsform liegt darin, die logische Struktur eines Prozesses zu
verdeutlichen. Die Darstellung als Netzplan ist die klassische Visualisierungsform f¨
ur Pro-
zesse. Sie stellt einen Prozess so dar, wie er meist vom Prozessdesigner auch entworfen
wurde. Die Prozessgraphdarstellung ist die nat¨
urliche Umsetzung des Gedankenmodells,
das Benutzer im allgemeinen, vor allem aber Prozessdesigner haben.
Beispiel
Abbildung 6.2 zeigt ein Beispiel f¨
ur eine Prozessgraphdarstellung. Die drei Aktivit¨
aten
’design’, ’marketing planning’ und ’production planning’ laufen parallel ab, ’design’ und
’mass-production development’ dagegen sequenziell. Bei einer solchen Darstellung ist kon-
figurierbar, welche und wie viele Attribute bei der Darstellung eines Aktivit¨
atenknotens
mit angezeigt werden (siehe Abbildung 5.11). Hier sind es die Bearbeiterzuordnung und
die beteiligten Dokumente. Je nachdem, mit welcher Zielsetzung der Benutzer die Graph-
darstellung verwendet, gibt es daf¨
ur eine passende Konfiguration, die eben gerade die
Informationen zeigt, die der Benutzer in diesem Moment ben¨
otigt.
Das Benutzerinterface muss eine M¨
oglichkeit bieten, die Knotenkonfiguration schnell um-
zuschalten. Dies kann in einer seitlichen Funktionsleiste im ’Aufgabenbereich’ geschehen
(siehe Abschnitt 7.4).
Eine weitere Funktionsleiste k¨
onnte weitere (Detail-)Informationen zum gerade gew¨
ahlten
Knoten anzeigen. Wenn der Mauszeiger ¨
uber einem Knoten verharrt, zeigen eingeblendete
Kurzinformationen (engl. tooltips) zus¨
atzlich weitere Informationen an.
M¨
achtigkeit des Konzeptes
Die Graphdarstellung ist sehr m¨
achtig. Sie ist nicht umsonst die native Darstellungsform
f¨
ur Prozesse. Vor allem der Kontrollfluss ist sehr gut nachvollziehbar. Verzweigungen im
Ablauf mitsamt Verzweigungsbedingungen lassen sich sehr gut darstellen, auch Schleifen,
75
6. Darstellungsformen f¨
ur Prozessdaten
start stop
design
OU: development division
car-series-technology-
roadmap
mass-production
development
OU: development division
car-series-technology-
roadmap
marketing
planning
OU: production division
production-technology-
roadmap
production
planning
OU: production division
N.A.
Abbildung 6.2.: Prozessgraphdarstellung
Ausnahmen (engl. exceptions) und sonstige Abh¨
angigkeiten (z. B. Sync-Kanten) passen
sehr nat¨
urlich in diese Darstellung. Nur wenn sich der Benutzer f¨
ur Einzelheiten aus dem
Prozessablauf interessiert, kann die Swimlane-Darstellung (siehe Abschnitt 6.2) Ansichten
erzeugen, die an den anstehenden Arbeitsschritt speziell angepasst sind.
Alle Aktivit¨
atenattribute und -Objekte lassen sich bei Bedarf darstellen. Die Visualisierung
des Datenflusses l¨
asst sich unabh¨
angig von der restlichen Darstellung zuschalten.
Das Organisationsmodell spielt in diesem Konzept praktisch keine Rolle, es k¨
onnen zwar
Informationen daraus dargestellt werden, wie z. B. die Zuordnung einer Aktivit¨
at zu einer
Abteilung ¨
uber die Auswertung des zugeh¨
origen Objektes ’Ausf¨
uhrungseinheit’, aber die
eigentliche Darstellung erfolgt unabh¨
angig vom Organisationsmodell. Es ist dennoch hilf-
reich, wenn die Markierungsfunktion (siehe Abschnitt 7.2) verwendet wird, um z. B. alle
Aktivit¨
aten zu markieren, die auf ein bestimmtes Dokument lesend zugreifen.
Das Konzept eignet sich sowohl f¨
ur Schema- und Instanzdarstellung als auch, mit leichten
Modifikationen f¨
ur Multi-Instanz-Darstellungen. Sogar hierarchische Prozesse lassen sich
darstellen, dies ist der ¨
Ubersichtlichkeit allerdings nicht immer zutr¨
aglich. Einzelne Unter-
prozesse lassen sich jedoch noch gut in die Darstellung eines Prozesses integrieren. Wenn
eine Aktivit¨
at andere Aktivit¨
aten kapselt, kann der Benutzer entweder diesen gekapselten
Subprozess in einer extra Darstellung visualisieren lassen oder die bisher versteckten Ak-
tivit¨
aten in die Darstellung integrieren lassen. Der ¨
Ubersichtlichkeit halber werden solche
Bl¨
ocke gesondert markiert, oder farblich hinterlegt (siehe Abbildung 6.4).
76
6.1. Prozessgraphdarstellung
Vor- und Nachteile
Ein großer Vorteil der Prozessgraphdarstellung ist die leichte Zug¨
anglichkeit der erstellten
Prozessabbildungen. Sie sind f¨
ur viele Benutzergruppen intuitiv erfassbar. Und mithilfe der
weiten Konfigurierbarkeit der Darstellung lassen sich viele Problemstellungen mit dieser
Darstellungsform l¨
osen.
Die Graphdarstellung hat allerdings auch Nachteile, etwa dass entsprechende Darstellun-
gen sehr schnell einen großen Platzbedarf erfordern. Dies hat auch zu den ¨
Uberlegungen
f¨
ur diese Arbeit gef¨
uhrt und der Suche nach alternativen Darstellungsformen.
Die Darstellung stellt den Kontrollfluss und die Aktivit¨
aten in den Mittelpunkt der Be-
trachtungen, das f¨
uhrt dazu, dass einige Bereiche der Prozessinformationen nicht optimal
dargestellt werden k¨
onnen. Der Datenfluss l¨
asst sich nur aus einer Gesamtperspektive be-
trachten, es f¨
allt schwer, den Bearbeitungsweg einzelner Dokumente zu verfolgen. Auch
die Interaktionen zwischen den verschiedenen Bearbeitern stecken zwar letztlich in der
Darstellung, ließen sich aber sehr viel deutlicher darstellen. Temporale Aspekte lassen
sich nur als textuelles Datum visualisieren, die Art der Darstellung sagt sonst nichts ¨
uber
die Dauer von Aktivit¨
aten aus. Aus der Darstellung lassen sich nur sehr schlecht Zusam-
menh¨
ange zwischen verschiedenen Prozessaspekten ableiten. Es ist beispielsweise schwer
herauszufinden, welche Bearbeiter mit welchen Dokumenten zu tun haben, da die Doku-
mente in der Darstellung prim¨
ar nur mit den Aktivit¨
aten zusammen dargestellt werden.
Und schließlich l¨
asst sich die Prozessgraphdarstellung nicht gut f¨
ur den Zweck einer Multi-
Instanz-¨
Ubersichtsdarstellung verwenden. Es ist keine parallele Darstellung der Instanzen
m¨
oglich, nur eine aggregierte Darstellung. Diese ist aufgrund ihrer Gr¨
oße f¨
ur eine ¨
Uber-
sichtsdarstellung relativ un¨
ubersichtlich.
M¨
ogliche Variationen
Varianten der Schema- und Instanzdarstellung existieren nicht, jedoch l¨
asst sich das Aus-
sehen der Darstellung ¨
uber die Knotenkonfiguration variieren, aber die dargestellten Infor-
mationen ¨
andern sich hierdurch nicht. Prinzipiell zeigt die Prozessgraphdarstellung immer
alle Aktivit¨
aten an. Durch geeignete Views (7.1) l¨
asst sich dies ¨
andern. Damit lassen sich
beispielsweise Ansichten erzeugen, bei denen nur noch die Aktivit¨
aten einzelner Mitarbei-
ter angezeigt werden. Bei Instanzdarstellungen lassen sich zus¨
atzlich alle nicht gew¨
ahlten
Ausf¨
uhrungspfade ausblenden (siehe Abschnitt Konfigurationsm¨
oglichkeiten 6.1).
Multi-Instanz-Darstellung
Eine aggregierte Multi-Instanz-Darstellung l¨
asst sich realisieren, indem eine Status-Infor-
mation ¨
uber jedem Knoten eingeblendet wird. Dies kann ein segmentierter Balken sein,
der in jedem Segment farbcodiert ¨
uber den Aktivit¨
atenstatus (abgeschlossen, laufend, be-
reit, nicht bereit, etc.) Auskunft gibt. Alternativ k¨
onnten auch mehrere gestapelte Balken
jeweils die Anzahl der Aktivit¨
aten anzeigen, die einen bestimmten Status haben. Die De-
tailansicht (siehe 7.3) kann dann aufschl¨
usseln, in welchen Instanzen eine Aktivit¨
at einen
bestimmten Ausf¨
uhrungsstatus hat.
In den Knoten lassen sich bei dieser Darstellung nur aggregierte Informationen zu den
Aktivit¨
aten darstellen. Also beispielsweise nur Rollenangaben statt konkreter Mitarbei-
77
6. Darstellungsformen f¨
ur Prozessdaten
terzuordnungen und Minimum-, Maximum- und Durchschnittsangaben zu (Bearbeitungs-
)Zeiten oder Kosten.
Konfigurationsm¨
oglichkeiten
Die folgende Liste zeigt wichtige Einstellungen f¨
ur die Prozessgraphdarstellung. Auf die
fett markierten Eintr¨
age wird anschließend kurz eingegangen.
➣Darstellungsvariante w¨
ahlen
➣Graph-Ausrichtung horizontal oder vertikal
➣Vertikal-Perspektive an/aus
➣Knotenkonfiguration
➣View-Konfiguration: Daten-/Dokumentfluss an/aus
➣View-Konfiguration: Schleifen an/aus
➣View-Konfiguration: Ausnahmen an/aus
➣Darstellung der Blockstruktur2
➣Zeitleiste an/aus
➣Tats¨
achlichen Ausf¨
uhrungspfad markieren
➣Noch nicht aktivierte Aktivit¨
aten transparent darstellen
➣Deaktivierte Aktivit¨
aten ausblenden
Vertikal-Perspektive an/aus
Routenplaner in Autos und im Internet [Maps06] stellen mehr und mehr auf eine perspek-
tivische Ansicht um, da so mehr Raum auf die Darstellungsfl¨
ache projiziert werden kann.
Einen Vergleich der Graphdarstellung mit und ohne perspektivische Verzerrung zeigt Ab-
bildung 6.3. Das erste Bild ben¨
otigt, durch, dass nach hinten kippen, weniger H¨
ohe, somit
k¨
onnen bei gleicher Darstellungsh¨
ohe tiefere Verzweigungen dargestellt werden. Es bietet
sich dabei an, falls technisch m¨
oglich, die gelbe Dokumentationsebene nicht zu verzerren.
Knotenkonfiguration
Der Anwender kann w¨
ahlen, wie die Aktivit¨
atenknoten in dieser graphbasierten Darstel-
lungsform aussehen sollen (siehe 5.3.1). Damit f¨
ur den Benutzer vorhersehbar ist, wie sich
die Darstellung ¨
andern wird, erfolgt die Auswahl visuell anhand von kleinen Thumbnails
der zur Auswahl stehenden grafischen Knotenrepr¨
asentationen.
Tats¨
achlichen Ausf¨
uhrungspfad markieren
Bei einer Instanzdarstellung werden hiermit die gew¨
ahlten Ausf¨
uhrungskanten fett mar-
kiert oder alternativ werden die nicht gew¨
ahlten grau gef¨
arbt und auch die nicht aktivierten
Knoten werden grau gef¨
arbt. Mithilfe der n¨
achsten Funktion k¨
onnen deaktivierte Knoten
komplett aus der Darstellung entfernt werden.
2siehe Abschnitt 6.1.1
78
6.1. Prozessgraphdarstellung
change
request eval-
uation
expertise evaluation
(planning) evaluation
(purchase) evaluation
(quality)
change
request
CR modification
required
CR infeasible
CR infeasible
CR modification
required
request
evaluation
App
CR
manager
Role
provide
evaluation
App
planning
expertRole
planning
system
provide
evaluation
App
purchase
expertRole
planning
system
provide
evaluation
App
quality
expertRole
request
comments
App
CR
manager
Role
provide
comments
App
planning
expertRole
provide
comments
App
planning
expertRole
provide
comments
App
construction
expertRole
provide
comments
App
quality
expertRole
approve CR
App
CR approval
boardRole
Abbildung 6.3.: Ausschnitt aus Change Management Prozess – Wirkung perspektivischer Dar-
stellung
Noch nicht aktivierte Aktivit¨
aten transparent darstellen
Noch nicht aktivierte Aktivit¨
aten einer Instanz werden transparent dargestellt, um den
Ausf¨
uhrungsfortschritt zu verdeutlichen.
Deaktivierte Aktivit¨
aten ausblenden
Bei Instanz-Darstellungen werden hiermit alle Pfade des Prozesses ausgeblendet, die nicht
durchlaufen wurden, um die Darstellung ¨
ubersichtlicher werden zu lassen.
6.1.1. Blockstruktur
Ein Ansatz zur Verbesserung der ¨
Ubersichtlichkeit einer Prozessgraphdarstellung besteht
darin, zusammenh¨
angende Strukturen im Graphen (z. B. Parallel-Verzweigungen oder Schlei-
fenbl¨
ocke) besonders zu markieren. Dies hilft dem Benutzer einen schnellen ¨
Uberblick ¨
uber
den Kontrollfluss zu erhalten.
Um dies zu erm¨
oglichen, sollte der dargestellte Prozess ein zugrunde liegendes Prozessmo-
dell haben, das dem Konzept der regelm¨
aßigen Blockstrukturierung gen¨
ugt (BPMN nennt
dies Full-Blocked), also einen blockstrukturierten Kontrollfluss aufweisen, in dem Kon-
trollstrukturen wie Schleifen, Sequenzen und Verzweigungen auf Bl¨
ocke mit eindeutiger
Start-/Endaktivit¨
at abgebildet werden (siehe dazu [Rein93]). Die einzelnen Blockstruktu-
ren d¨
urfen sich nicht ¨
uberschneiden, k¨
onnen aber beliebig ineinander verschachtelt sein.
Dies f¨
uhrt zu einer symmetrischen Strukturierung des Kontrollflussgraphen (engl. sym-
metrical control structures), da eine Aufsplittung an einem Knoten beginnt und es auch
genau einen Knoten gibt, an dem die Zweige wieder zusammengef¨
uhrt werden.
Das an der Universit¨
at Ulm entwickelte ADEPT Prozess-Metamodell [DR03] ist block-
strukturiert. Dies bringt noch weitere Vorteile mit sich, etwa bei Schema¨
anderungen, wenn
diese im laufenden Betrieb m¨
oglich sein sollen. Dies erfordert zur Laufzeit automatische
Korrektheitsanalysen, die bei symmetrischen Kontrollfl¨
ussen besonders effizient m¨
oglich
werden. Aber auch die Prozessmodellierung l¨
asst sich vereinfachen, weil syntaxgesteuerte
Editoren eingesetzt werden k¨
onnen.
79
6. Darstellungsformen f¨
ur Prozessdaten
Aber selbst wenn Prozesse keinen komplett symmetrisch strukturierten Kontrollflussgra-
phen haben, lassen sich ¨
uber eine Graphanalyse blockstrukturierte Graphteile ermitteln,
diese k¨
onnen dann in der Visualisierung mit farbigen Bl¨
ocken hinterlegt werden, um dem
Benutzer das Erfassen des Kontrollflusses zu erleichtern. Einen Beispielprozess mit hinter-
legter Blockstruktur zeigt Abbildung 6.4. Die Aktivit¨
at ’B-I’ kapselt einen Unterprozess,
darauf weist das Plus-Symbol im Knoten hin. Abbildung 6.5 zeigt denselben Prozess, wobei
der Unterprozess nun ge¨
offnet wurde, und damit in die Darstellung integriert wurde.
Das zweite Bild zeigt einen hellblau hervorgehobenen Block, der beispielsweise durch Ankli-
cken oder l¨
angeres Verweilen derart eingef¨
arbt worden ist. Dieser selektierte Block l¨
asst
sich ¨
uber das nun eingeblendete Minus-Symbol zusammenfalten.
sequence loop
FAILURE
Start A LSB-I LE
LOOP
JEnd
Abbildung 6.4.: Prozessgraph mit Blockstruktur
sequence loop
parallel branch
parallel branch
sequence
conditional branch
FAILURE
Start
Process: B-I
A LSB
C
G
D
E
F
H
SYNC I LE
LOOP
JEnd
Abbildung 6.5.: Prozessgraph mit Blockstruktur und ge¨
offnetem Unterprozess
Die Farben dieser Bl¨
ocke weisen dabei keinen hohen Kontrast auf, um von der eigentlichen
Information nicht abzulenken (siehe Abschnitt 5.1.1).
6.1.2. Zeitleiste
Eine unten am Darstellungsfenster angebrachte Zeitleiste dient dazu, die Historiendarstel-
lung zu steuern und grobe Informationen ¨
uber die zeitliche Einordnung der Aktivit¨
aten zu
80
6.1. Prozessgraphdarstellung
liefern. Die Zeitleiste besteht aus zwei unterschiedlich gef¨
arbten Bereichen, Vergangenheit
und Zukunft. Die Skala verl¨
auft linear, es werden nur die Startzeiten der Aktivit¨
aten an-
gezeigt. Wenn der Mauszeiger ¨
uber einer Aktivit¨
at verharrt, kann als Zusatzinformation in
der Zeitleiste ein Zeitbalken eingeblendet werden, der Auskunft ¨
uber Dauer und Endzeit
der Aktivit¨
at gibt. Weiterhin k¨
onnen Zeitpunkt der Aktivierung, Fristen und damit der
Zeitspielraum f¨
ur die Ausf¨
uhrung der Aktivit¨
at visualisiert werden.
Sobald der Schieberegler, der den Zeitpunkt der Prozessdarstellung festlegt, bewegt wird,
ver¨
andern sich die Ausf¨
uhrungszust¨
ande entsprechend. Falls die Historie in einem Fenster
angezeigt wird, zeigt dieses die Eintr¨
age bis zum gew¨
ahlten Zeitpunkt an oder markiert
deutlich den Bereich, ab dem die Zukunft beginnt (d. h. durch graues Einf¨
arben der in der
Zukunft liegenden Eintr¨
age).
Auch der Umgang mit On-Line-Verlaufsinformationen kann ¨
uber diese Zeitleiste erfolgen
(siehe dazu Abschnitt 7.6.1). Beim Eintreffen neuer Informationen k¨
onnen zwei M¨
oglich-
keiten f¨
ur die Reaktion des Interface eingestellt werden. Entweder l¨
ost der Anwender die
Aktualisierung der Darstellung manuell aus oder sie wird automatisch aktualisiert.
Die Zeitleiste stellt eine hilfreiche Erg¨
anzung f¨
ur die Prozessgraphdarstellung dar, die
temporale Aspekte nicht gut darstellen kann. Das Konzept der Zeitleiste ist von der Ka-
lenderdarstellung abgeleitet (siehe Text und Abbildungen in Abschnitt 6.3).
6.1.3. Implementierungsaspekte
Grundlegend f¨
ur Graphdarstellungen sind Layout-Algorithmen [RBRB06]. Die Aufgabe
dieser Algorithmen ist es, die Kanten und Knoten des Netzplans so zu platzieren, dass
die Darstellung gut strukturiert erscheint und somit schnell erfassbar ist. Gutes Layouting
tr¨
agt zu Usability bei. In Abschnitt 4.1 erw¨
ahnte Usability-Prinzipien sind daher auch
Anforderungen an einen Layout-Algorithmus:
➣Ausrichtung der Elemente
➣N¨
ahe
➣Erzeugte Graphen sollen m¨
oglichst ¨
uberschneidungsfrei sein
Erw¨
ahnenswert sind u. a. die folgenden Layout Algorithmen:
➣Orthogonales Layout (siehe Abbildung 6.6)
Ein relativ einfacher Layout Algorithmus, der ¨
außerst kompakte Darstellun-
gen erm¨
oglicht. Objekte werden rechtwinklig ohne ¨
Uberschneidungen ange-
ordnet. Jedoch f¨
allt es schwer die Strukturierung zu erfassen.
➣Hierarchisches Layout (siehe Abbildung 6.7)
Ein sehr komplexer Layout Algorithmus, er erzeugt ’stromorientierte’ Gra-
phen. Dies kommt der menschlichen Wahrnehmung entgegen und erleichtert
so das Erfassen der logischen Zusammenh¨
ange. Aktivit¨
aten, die weiter rechts
platziert sind, sind logisch abh¨
angig von weiter links platzierten.
➣Inkrementelles Layout
Dieser Algorithmus stellt einen Aufsatz auf einen der herk¨
ommlichen Layout-
Algorithmen dar, d. h. es gibt z. B. einen inkrementellen hierarchischen Layout-
Algorithmus. Ausgehend von einem einmal erzeugten Layout kann das Ein-
81
6. Darstellungsformen f¨
ur Prozessdaten
/ Ausblenden von Graphteilen m¨
oglichst darstellungsneutral erfolgen, wenn
Techniken des inkrementellen Layouts verwendet werden.
Powered by yFiles
Start
activity A
activity D
activity B
activity C
End
Abbildung 6.6.: Orthogonales Layout
Start activity A
activity D
activity B activity C
End
Abbildung 6.7.: Hierarchisches Layout
Die Vorteile eines ’Inkrementellen Layouters’ kommen in Verbindung mit einer Animati-
onskomponente besonders zur Geltung. Bei ¨
Anderungen am Graphen, z. B. beim Ausklap-
pen bisher zusammengefasster Aktivit¨
aten, beh¨
alt der Benutzer leichter den ¨
Uberblick, da
¨
Anderungen am Graphen vor den Augen des Benutzers geschehen und er sich nicht an
eine pl¨
otzlich eingeblendete, neue Darstellung gew¨
ohnen muss.
6.2. Swimlane-Darstellung
Die Swimlane-Darstellung ist eine Ableitung aus der Prozessgraphdarstellung, bei der die
Aktivit¨
aten in Partitionen aufgeteilt dargestellt werden. Der Netzplan wird also bez¨
uglich
eines Ressourcentyps in horizontale ’Pools’ (Partitionen) aufgeteilt. Wenn ein Ressourcen-
typ nunterschiedliche Ressourcen hat, enth¨
alt der resultierende Netzplan f¨
ur jede Ressour-
ce diesen Typs einen Pool. Im einfachsten Fall, wenn es keine zwei Ressourcen desselben
Typs gibt, ist die Swimlane-Darstellung ’identisch’ mit der Prozessgraphdarstellung.
Die Aktivit¨
aten des urspr¨
unglichen Netzplanes werden den verschiedenen Pools zugeord-
net. Alle Aktivit¨
aten, die sich nicht zuordnen lassen, weil sie die entsprechende Ressource
82
6.2. Swimlane-Darstellung
nicht verwenden, werden einem weiteren Ersatzpool zugeordnet. Jede Darstellung enth¨
alt
also insgesamt noder n+1 Pools. UML bezeichnet diese Pools als Partitionen.
Beispiel
Abbildung 6.8 zeigt ein einfaches Beispiel einer Swimlane-Darstellung. Der Benutzer kann,
wie bei der Prozessgraphdarstellung, frei konfigurieren, welche Aktivit¨
atendetails in der
Darstellung mit angezeigt werden sollen. N¨
ahere Details kann eine Tooltipp-Information
oder eine Aktivit¨
atendetailansicht im Aufgabenbereich anzeigen (siehe Abschnitt 7.4).
development
division
production division
start
design
marketing
planning
production
planning
Role
mass-production
development
stop
Abbildung 6.8.: Prozessgraph in Swimlane-Darstellung
Besitzt ein Ressourcentyp einen Obertyp, ein Beispiel w¨
are die Ressource ’Mitarbeiter’
mit Obertyp ’Abteilung’, kann der Netzplan in Pools nach Abteilungen kategorisiert oder
gruppiert werden. Jeder Mitarbeiter muss dabei genau einer Abteilung zugeordnet werden
k¨
onnen. Jeder einzelne Abteilungs-Pool ist dann weiter in (Swim-)Lanes unterteilt, f¨
ur
jeden Mitarbeiter eine. Dies erzeugt dann eine geschachtelte Darstellung. Ein Beispiel
zeigt Abbildung 6.9.
M¨
achtigkeit des Konzeptes
Da die Swimlane-Darstellung eine Erweiterung der Prozessgraphdarstellung ist, treffen
alle Aussagen ¨
uber deren M¨
achtigkeit hier genauso zu. Jedoch ist es nun m¨
oglich, Zu-
sammenh¨
ange zwischen einzelnen Prozessressourcen und Aktivit¨
aten besser darzustellen.
Auch das Interaktionsdiagramm und die Matrixdarstellung dienen dazu, Zusammenh¨
an-
ge in den Prozessinformationen herauszuarbeiten, hierbei handelt es sich aber um sehr
spezialisierte Darstellungsformen f¨
ur spezielle Aufgaben.
In der Swimlane-Darstellung kann der Kontrollfluss nicht mehr so ¨
ubersichtlich darge-
stellt werden und die Darstellungskomplexit¨
at ist daher konzeptbedingt gegen¨
uber der
Prozessgraphdarstellung erh¨
oht. Deshalb wird hier auf die Darstellung der Blockstruktur
verzichtet (vgl. Abschnitt 6.1.1), es kann ohnehin nicht garantiert werden, dass parallele
Aktivit¨
aten lokal beieinander platziert sind. Schleifen, Spr¨
unge, Ausnahmen und Sync-
Kanten lassen sich wie bei der Prozessgraphdarstellung anzeigen, jedoch erschwert die
parallele Darstellung des Prozesses das Erfassen.
83
6. Darstellungsformen f¨
ur Prozessdaten
production
automation gruop design groupseries planning gruop
production logistics
gruop
production division development division
start
marketing
planning
production-technology-
roadmap
design
car-series-technology-
roadmap
Role
mass-production
development
car-series-technology-
roadmap
stop
production
planning
N.A.
Abbildung 6.9.: Prozessgraph in geschachtelter Swimlane-Darstellung
Das Organisationsmodell spielt in diesem Darstellungskonzept eine wesentlich gr¨
oßere Rol-
le als bei der Prozessgraphdarstellung. Die Unterteilung ist zwar, unabh¨
angig vom Orga-
nisationsmodell, nach den Prozessressourcen m¨
oglich. Aber oft verhilft erst das Orga-
nisationsmodell zur gew¨
unschten ¨
Ubersichtlichkeit, indem Ressourcen zusammengefasst
werden. Beispielsweise k¨
onnen die Mitarbeiter statt in vielen getrennten Lanes, innerhalb
von Abteilungs-Lanes dargestellt werden.
Die Swimlane-Darstellung ist ein m¨
achtiges Werkzeug f¨
ur die Bildung von Views, an-
hand der Informationen aus dem Organisationsmodell. Durch geeignetes Zusammenfassen
kann es auch seine St¨
arken zum Untersuchen von Kommunikationsstrukturen, zwischen
verschiedenen Organisationseinheiten innerhalb eines Prozesses, ausspielen.
Wie bei der Prozessgraphdarstellung lassen sich Schema-, Instanz- und Multi-Instanz-
Darstellungen erzeugen. Auch hierarchische Prozesse lassen sich darstellen, indem Aktivi-
t¨
aten aus Unterprozessen in die Darstellung mit eingebettet werden. In der resultierenden
Darstellung kann dann allerdings nicht mehr so leicht zwischen Aktivit¨
aten des Eltern- und
des Kindprozesses unterschieden werden. Mit den M¨
oglichkeiten der Markierungsfunktion
(siehe 7.2.1), l¨
asst sich aber beispielsweise die Prozessherkunft farblich kodieren.
Vor- und Nachteile
Prinzipiell weist die Swimlane-Darstellung ¨
ahnliche Vor- und Nachteile wie die Prozess-
graphdarstellung auf. Bei Swimlane-Darstellungen werden jedoch Zusammenh¨
ange zwi-
schen einer Ressource des Prozesses und den Aktivit¨
aten deutlich besser sichtbarer. Dieser
Vorteil wird mit einer geringeren ¨
Ubersichtlichkeit des Kontrollflusses ’erkauft’. Vor allem
Verzweigungen im Kontrollfluss k¨
onnen nicht mehr so ¨
ubersichtlich dargestellt werden.
Dies f¨
allt jedoch nicht sehr ins Gewicht, da die Prozessgraphdarstellung weiterhin als
84
6.2. Swimlane-Darstellung
Darstellungsform zur Verf¨
ugung steht. Je nach Prozess und gew¨
ahlter Darstellungsvarian-
te (siehe n¨
achster Abschnitt) k¨
onnen einige Prozesse aber sehr viel kompakter als bei der
Prozessgraphdarstellung dargestellt werden (siehe Abbildung 6.10), wenn der Nutzer nicht
darauf besteht, dass die ein- und ausgehenden Kontrollflusskanten mittig in den Knoten
ein- bzw. austreten.
<a><b>
start stop
Swimlane Prozessgraph
start stop
1
2
4
5
<c>
3 6
1
<a>
2
<b>
3
<c>
4
<a>
5
<b>
6
<c>
Abbildung 6.10.: Beispiel einer horizontalen Platzersparnis bei der Swimlane- gegen¨
uber der Pro-
zessgraphdarstellung
Weitere algorithmische Probleme, das Layout betreffend, sind im Abschnitt Implementie-
rungsaspekte 6.2.1 beschrieben.
M¨
ogliche Variationen
Die folgende Tabelle listet die Prozessressourcen auf, mit denen der urspr¨
ungliche Netzplan
in Pools unterteilt werden kann.
Ressource Beschreibung
Ausf¨
uhrungseinheit Die gebr¨
auchlichste Nutzung von Swimlane-Darstellungen
sammelt jeweils alle Aktivit¨
aten einer Rolle, eines Bearbeiters
oder einer Organisationseinheit in einem Pool
System Alle Aktivit¨
aten, die auf dem gleichen System laufen oder mit der
gleichen Applikation arbeiten, sind in einem Pool angeordnet
Dokument Alle Aktivit¨
aten, denen dasselbe Dokument zugeordnet ist, sind
in einem Pool angeordnet
Tabelle 6.1.: Varianten der Swimlane-Darstellung
Weitere spezielle Varianten von Swimlane-Darstellungen sind je nach Anwendungsfall
denkbar. Beispielsweise eine Partitionierung der Aktivit¨
aten in reine Kostenstellen und
in wertsch¨
opfende Aktivit¨
aten.
Die Voraussetzung f¨
ur Swimlane-Darstellungen ist die eindeutige Partitionierbarkeit der
Prozessinformationen (siehe 8.2).
85
6. Darstellungsformen f¨
ur Prozessdaten
Schema- & Instanz-Darstellung
Variante 1: Swimlane nach Ausf¨
uhrungseinheiten
In dieser Darstellung lassen sich im Besonderen die Interaktionen der verschiedenen Aus-
f¨
uhrungseinheiten miteinander visualisieren. Durch die Informationen im Organisations-
modell entsteht eine geschachtelte Darstellung, die der Benutzer bei Bedarf auseinander
falten kann.
Variante 2: Swimlane nach Systemen
Diese Variante kann dazu dienen, zu veranschaulichen, welche Prozessteile auf welchen
Systemen oder Applikationen abgewickelt werden. Voraussetzung f¨
ur eine eindeutige Dar-
stellung ist, dass jeder Aktivit¨
at maximal ein System oder eine Applikation zugeordnet
ist.
Variante 3: Swimlane nach Dokumenten
Aus dieser Darstellung ist sehr gut ersichtlich, welche Aktivit¨
aten auf ein Dokument zu-
greifen und in welcher Reihenfolge, die am Prozess beteiligten Dokumente bearbeitet wer-
den. Voraussetzung f¨
ur eine eindeutige Darstellung ist, dass jeder Aktivit¨
at maximal ein
Dokument oder ein Datenbankeintrag zugeordnet ist.
Multi-Instanz-Darstellung
Auch bei der Swimlane-Darstellung ist eine Multi-Instanz-Darstellung m¨
oglich, umgesetzt
wird dies analog zur Prozessgraphdarstellung (siehe 6.1). Das Ziel einer Multi-Instanz-
Darstellung ist, den Fortschritt der einzelnen Instanzen einander gegen¨
uberzustellen. Das
Ziel der Swimlane-Darstellung ist es jedoch Zusammenh¨
ange aufzuzeigen. Die Visualisie-
rung des Multi-Instanz-Falles kombiniert diese beiden Ziele. Notwendige Voraussetzung
f¨
ur die Darstellung als Swimlane ist lediglich, das sich alle Instanzen gleichermaßen in die
gleichen Lanes einordnen lassen.
Variante 1: Swimlane nach Ausf¨
uhrungseinheiten
Der Vorteil dieser Darstellung ist, dass die Prozess-Fortschritte der verschiedenen Organi-
sationseinheiten miteinander verglichen werden k¨
onnen. Auf diese Weise k¨
onnen Engp¨
asse
erkannt werden.
Bei dieser Darstellung werden in den Lanes nicht die Mitarbeiter angegeben, sondern
ausschließlich Rollen- oder Funktionsangaben, da diese nicht von Instanz zu Instanz ab-
weichen.
Variante 2: Swimlane nach Systemen
Diese Variante d¨
urfte vor allem bei der Fertigung interessant sein, um beispielsweise zu
untersuchen, ob alle Systeme gleichm¨
aßig ausgelastet werden.
Variante 3: Swimlane nach Dokumenten
Wo der Fortschritt bei der Bearbeitung von Dokumenten von Interesse ist, kann diese
Darstellung sinnvoll sein. Voraussetzung hierf¨
ur ist, dass jede Aktivit¨
at genau einem Do-
kument zuordenbar ist.
86
6.2. Swimlane-Darstellung
Konfigurationsm¨
oglichkeiten
➣Darstellungsvariante w¨
ahlen
➣Graph-Ausrichtung horizontal oder vertikal
➣Vertikal-Perspektive an/aus
➣Knotenkonfiguration
➣Graph neu zeichnen
➣Historiendarstellung (mit Timeline)
➣¨
Ubersichtsstreifen einblenden
➣Deaktivierte Aktivit¨
aten ausblenden
➣Lanes zusammenfassen
Vertikal-Perspektive an/aus
Diese Konfigurationsm¨
oglichkeit wurde schon bei der Prozessgraphdarstellung angespro-
chen (siehe 6.1). Da Swimlane-Darstellungen sehr viel H¨
ohe ben¨
otigen, kann die Vertikal-
Perspektive hier besonders zu einer besseren ¨
Ubersichtlichkeit beitragen.
Knotenkonfiguration
Der Anwender kann hier wie bei der Prozessgraphdarstellung (siehe Abschnitt 6.1) die
grafische Knotenrepr¨
asentation w¨
ahlen.
Graph neu zeichnen
Wie im n¨
achsten Abschnitt (6.2.1) beschrieben, wird eine Implementierung N¨
aherungsal-
gorithmen zur Layout-Gestaltung verwenden. Nach Ablauf einer kurzen Zeitspanne (ca.
f¨
unf Sekunden) wird die bisher beste L¨
osung Grundlage des Layouts. Dadurch kann die
Reaktionszeit des Interface f¨
ur den Benutzer ertr¨
aglich gehalten werden. Die Berechnung
von besseren Layout-L¨
osungen kann aber im Hintergrund weiterlaufen. Somit bekommt
der Benutzer die M¨
oglichkeit, bei einer nicht zufriedenstellenden Darstellung, auf ein ver-
bessertes Layout zu wechseln.
¨
Ubersichtsstreifen einblenden
Bei Visualisierungen mit vielen Lanes verteilen sich die Aktivit¨
aten des dargestellten Pro-
zesses sehr stark. Das f¨
uhrt dazu, dass innerhalb einer Lane große Abst¨
ande zwischen den
Aktivit¨
aten auftreten k¨
onnen. Zu einer besseren ¨
Ubersicht f¨
ur den Benutzer verhilft hier
die gleichzeitige Darstellung eines ¨
Ubersichtsfensters (siehe Abschnitt 7.5). Eine Alterna-
tive dazu bietet die Implementierung eines schmalen ¨
Ubersichtsstreifens unterhalb jedes
Pools oder jeder Lane. Dieser Streifen zeigt miniaturisiert auf der verf¨
ugbaren Breite alle
Aktivit¨
atenknoten und markiert den derzeit dargestellten Bereich.
Deaktivierte Aktivit¨
aten ausblenden
Bei Instanzdarstellungen werden alle Pfade des Prozesses ausgeblendet, die nicht durch-
laufen wurden, um die Darstellung ¨
ubersichtlicher werden zu lassen.
87
6. Darstellungsformen f¨
ur Prozessdaten
Lanes zusammenfassen
Um die ¨
Ubersichtlichkeit durch eine reduzierte Anzahl von Swimlanes zu erh¨
ohen, kann
der Benutzer gezielt manuell einzelne Lanes zu einer zusammenfassen. Alle Aktivit¨
aten
der gew¨
ahlten Lanes werden danach in nur einer Lane dargestellt. Dies d¨
urfte vor allem
bei Prozessen mit vielen Lanes sinnvoll sein, wo aber nur wenige Aktivit¨
aten den einzelnen
Lanes zugeordnet sind. Auch k¨
onnen Lanes die im Moment nicht von gr¨
oßerem Interesse
sind, auf diese Art und Weise zusammengefasst werden.
6.2.1. Implementierungsaspekte
Eine gute ¨
ubersichtliche Swimlane-Darstellung zu erzeugen ist keine triviale Aufgabe. Dies
ist somit auch eines der gr¨
oßten Probleme dieses Darstellungskonzeptes, falls die ben¨
otigte
Rechenzeit f¨
ur das Layouting sich f¨
ur die Anwender st¨
orend bemerkbar macht.
F¨
ur eine Implementierung ist wichtig, dass f¨
ur diese Darstellung, wie auch schon f¨
ur die
Prozessgraphdarstellung, prinzipiell dieselben Layout-Algorithmen zum Einsatz kommen.
Allerdings wird die Komplexit¨
at des Layout-Problems noch dadurch erh¨
oht, dass auf-
grund der zus¨
atzlichen Nebenbedingungen bestimmte Aktivit¨
aten jeweils im gleichen Pool
positioniert werden m¨
ussen. Dazu kommt ein Optimierungsproblem, denn es existiert min-
destens eine Anordnung der Pools, f¨
ur die die Summe ¨
uber alle horizontalen Weganteile
der Kontrollflusskanten minimal ist. Diese Anordnung sollte in der Darstellung angestrebt
werden, da dann die ¨
Ubersichtlichkeit maximal ist, weil die Kontrollflusskanten am we-
nigsten von der restlichen Darstellung ablenken. Außerdem ergibt sich der Zusatznutzen,
dass Pools, die viel miteinander zu tun haben, r¨
aumlich nah beieinander liegen.
Bei einer Poolanzahl von nliegt allerdings die untere Schranke der Komplexit¨
at zur Be-
stimmung dieser optimalen Anordnung bei n!, da es entsprechend viele M¨
oglichkeiten gibt,
die Pools anzuordnen. Das heißt, es m¨
ussten n! Layouts berechnet werden, um das beste
Layout zu finden. Da aber schon das Berechnen eines einzigen Layouts viel Rechenzeit
beansprucht, erscheint dies nicht als gangbarer Weg. F¨
ur das Layout wird keine exakte
L¨
osung ben¨
otigt, als Ziel gen¨
ugt eine N¨
aherungsl¨
osung. Die entscheidende Vorgabe bleibt,
die Reaktionszeit des Interface gering zu halten. Es gilt also, heuristische Verfahren, ge-
netische Algorithmen, Ameisenalgorithmen oder ¨
ahnliche N¨
aherungsverfahren zur L¨
osung
des Problems heranzuziehen. Zum Zeitpunkt der Drucklegung existierte keine, dem Autor
bekannte, Literatur zu diesem Swimlane Layout Problem. Alle existierenden Algorithmen
berechnen Layouts auf der Grundlage einer vorher festgelegten Pool-Reihenfolge.
Solange keine Algorithmen zur L¨
osung dieses Problems existieren, d¨
urfte es ein gangbarer
Weg sein, die Pools mit den meisten Knoten in die Mitte der Darstellung zu sortieren, um
die Wegstrecken statistisch zu reduzieren.
6.3. Kalenderdarstellung
Die St¨
arke dieser Darstellungsform liegt darin, zeitliche Projektierungsaspekte zu visuali-
sieren. Die Kalenderdarstellung, auch Balkenplan oder Gantt-Diagramm genannt, entsteht,
wenn ein Prozessgraph auf die Zeitachse projiziert wird. Ein einfaches Diagramm kann als
Variante eines Netzplanes gesehen werden, bei dem die Aktivit¨
aten auf der X-Achse nach
88
6.3. Kalenderdarstellung
Startzeit angeordnet sind und z. B. die L¨
ange der Aktivit¨
atensymbole ihre Dauer repr¨
asen-
tieren. Jede Aktivit¨
at wird als (Zeit-)Balken in einem Kalender dargestellt, der Startzeit,
Endzeit und Dauer der Aktivit¨
at visualisiert.
Beispiel
Abbildung 6.11 zeigt eine Kalenderdarstellung. Auf der linken Seite befindet sich eine
Tabelle hier k¨
onnen Detailinformationen zu den Aktivit¨
aten angezeigt werden. Die L¨
ange
der Balken entspricht jeweils der Dauer der Aktivit¨
at. Ein kleinerer Balken im Inneren gibt
hier Aufschluss, zu wie viel Prozent eine Aktivit¨
at abgeschlossen ist. Der innere Balken ist
gr¨
un, wenn eine Aktivit¨
at in ihrem Zeitplan ist, gelb, wenn der Zeitplan nicht eingehalten
wurde, aber noch keine Frist verletzt wurde. Gelbe Aktivit¨
aten zeigen also an, wo Pufferzeit
verbraucht wird. Rote Aktivit¨
aten schließlich haben eine Frist verletzt. Bei der roten und
der gelben Aktivit¨
at zeigt ein senkrechter Strich jeweils den Zeitpunkt des geplanten Endes
der Aktivit¨
at. Zeile 4 zeigt eine Ausnahmebehandlung an, die bei Bedarf an dieser Stelle
angesprungen wird. Die Kreise am Ende der Balken in den Zeilen 3 und 22 zeigen an,
dass danach Einsprungpunkte von Ausnahmen sind. Die Balken mit dem Stern am Ende
signalisieren, dass diese Aktivit¨
aten Ausnahmen ausl¨
osen k¨
onnen.
No Activity 2217 2010 2711 281512 2423
1initiate change request
2determine CR manager
generate expertise
6generate expertise
7generate expertise
8generate expertise
9request evaluation
10 provide evaluation
11 provide evaluation
12 provide evaluation
13 request comments
14 provide comments
15 provide comments
conclude CR
3instruct expertise
Mar 2006
2619921 2514 291613 18
19
18
17
16 provide comments
provide comments
approve CR
start realization
22
21
20 realize CR (construction)
start realization
realize CR (production)
Apr 2006
13 45
Participant
CR initiator
contact person
CR manager
car body engineer
electronic engineer
motor engineer
development chief
CR manager
planning expert
purchase expert
quality expert
CR manager
planning expert
planning expert
construction expert
quality expert
CR approval board
CR manager
construction engineer
CR manager
production engineer
CR manager23
modify CR4
5
Abbildung 6.11.: Kalenderdarstellung
89
6. Darstellungsformen f¨
ur Prozessdaten
M¨
achtigkeit des Konzeptes
Die Kalenderdarstellung ist auch die ¨
ubliche Darstellungsform von Projektplanungssoft-
ware (siehe Abschnitt 4.2.2), da hier der Zeitaspekt am besten ber¨
ucksichtigt ist. Die
Darstellung kann sowohl Instanzen als auch Schemata visualisieren, bei einem Schema
allerdings nur die Planungszeiten. Bei Instanzen k¨
onnen mithilfe der tats¨
achlichen Zei-
ten auch Soll-Ist Vergleiche angestellt werden. Weiterhin k¨
onnen der kritische Pfad und
Pufferzeiten visualisiert werden.
Der Kontrollfluss l¨
asst sich bei der Prozessgraphdarstellung deutlich besser darstellen. In
Gantt-Diagrammen werden ¨
ublicherweise nur einfache Kontrollfl¨
usse mit parallelen Ver-
zweigungen, aber ohne bedingte Verzweigungen, Schleifen und Ausnahmen visualisiert. Es
lassen sich zwar L¨
osungen f¨
ur die Darstellung dieser Kontrollflussaspekte finden, jedoch
gewinnen die resultierenden Prozessansichten dadurch nicht an ¨
Ubersichtlichkeit. Um be-
dingte Verzweigungen darstellen zu k¨
onnen, wird ein zweiter Kantentyp ben¨
otigt. Schleifen
zeigen bis zur ersten Ausf¨
uhrung auf eine fr¨
uher eingeplante Aktivit¨
at. Sobald sie aktiviert
wird, werden die in ihr enthaltenen Aktivit¨
aten wiederholt ausgef¨
uhrt und hintereinander
in den Projektplan eingef¨
ugt, erst danach folgt der restliche Prozessablauf. Daher ist in
solchen F¨
allen der urspr¨
ungliche Kontrollfluss nicht mehr gut sichtbar. Ausnahmebehand-
lungen werden im Projekt mit eingeplant, Aktivit¨
aten die Ausnahmen ausl¨
osen, erhalten
eine besondere Markierung. Der Datenfluss bleibt bei Kalenderdarstellungen ganz außen
vor.
Das Organisationsmodell ist bei der Ressourcen-orientierten Variante dieser Darstellung
sehr hilfreich. Hierarchische Prozesse k¨
onnen dargestellt werden, wobei die Aktivit¨
aten
von Eltern- und Kindprozess gut unterscheidbar bleiben. Eine besondere St¨
arke sind sehr
¨
ubersichtliche Multi-Instanz und Multi-Schema-Darstellungen.
Vor- und Nachteile
Die ¨
Ubersichtlichkeit der Darstellung des Kontrollflusses ist eingeschr¨
ankt. Vor allem zeit-
liche Abh¨
angigkeiten stellt ein solches Diagramm aber gut dar. Außer Zeitplanungen lassen
sich auch die Personalplanung und die Auslastung von Maschinen/Systemen ¨
ubersichtlich
visualisieren.
M¨
ogliche Variationen
Schema- & Instanz-Darstellung
Variante 1: Sortiert nach Startzeit / Aktivit¨
aten-orientiert
Das ist die ¨
ubliche Variante einer Kalenderdarstellung. Sie wirkt ¨
ubersichtlich, da die
einzelnen Aktivit¨
atenbalken von links nach rechts geordnet erscheinen. Wenn eine noch
laufende Instanz dargestellt wird und einzelne Startzeiten noch nicht verf¨
ugbar sind, wird
stattdessen topologisch sortiert. Auf der linken Seite kann eine Tabelle dargestellt werden,
die Informationen zu jeder einzelnen Zeile – also zu den einzelnen Aktivit¨
aten – zeigt.
Die erste Spalte zeigt dabei den Namen der jeweiligen Aktivit¨
at, ansonsten k¨
onnen wie
bei der Tabellendarstellung (siehe Abschnitt 6.4) weitere Aktivit¨
ateneigenschaften einge-
blendet werden. Wenn man auf diese Tabelle verzichtet, gewinnt man mehr Raum f¨
ur
90
6.3. Kalenderdarstellung
die eigentliche Darstellung, es muss dann allerdings jeder Balken mit dem Aktivit¨
atenna-
men beschriftet werden. Bei Anzeige der Tabelle kann diese Beschriftung beliebige andere
Informationen anzeigen, wie etwa den Namen des Bearbeiters.
Bei hierarchischen Prozessen wird unterhalb einer Aktivit¨
at, die einen Unterprozess kap-
selt, dieser eingef¨
ugt dargestellt. Nach der letzten Aktivit¨
at des Unterprozesses folgt die
n¨
achste Aktivit¨
at des Elternprozesses.
Variante 2: Ressourcen-orientiert
Auf der y-Achse werden (alle) Ressourcen eines Typs aufgetragen. Alle Aktivit¨
aten, die
sich eine Ressource teilen, bilden dabei eine Gruppe. Die Gruppe besteht dann aus so vielen
Zeilen, wie es Aktivit¨
aten gibt, die diese Ressource nutzen. Es zeigt, welche Aktivit¨
aten
sich eine Ressource teilen. Auch die Auslastung oder ¨
Uberlastung einer Ressource kann so
visualisiert werden. Einen Auszug aus den w¨
ahlbaren Ressourcen bietet Tabelle 2.1. Die
einzelnen Gruppen lassen sich zu einer Zeile zusammenfassen, sodass beispielsweise alle
Aktivit¨
aten eines Mitarbeiters gesammelt in einer Zeile erscheinen.
Die Voraussetzung f¨
ur eine solche Darstellung ist die eindeutige Partitionierbarkeit der
Prozessinformationen (siehe 8.2).
Multi-Instanz-Darstellung
Eine aggregierte Darstellung ist hier wegen der differierenden Ausf¨
uhrungszeiten der In-
stanzen nicht m¨
oglich. Auch eine parallele Darstellung w¨
urde nur in einer sehr un¨
uber-
sichtlichen Darstellung resultieren. Mehrere Instanzen lassen sich nur darstellen, indem
Aggregation und parallele Darstellung kombiniert werden. Jede Instanz wird auf eine
Kalenderzeile reduziert. Die Instanzen werden untereinander dargestellt. F¨
ur die n¨
otige
Aggregation gibt es mehrere M¨
oglichkeiten. Entweder existiert eine spezielle View (siehe
Abschnitt 7.1) oder die Prozessinformationen enthalten eine Phasen- oder Meilenstein-
Einteilung.
Variante 1: Ressourcen-orientiert
Analog zur Ressourcen-orientierten Variante der Schema- & Instanz Darstellung, l¨
asst sich
dieses Prinzip auf alle laufenden Instanzen eines PMS ausweiten. Der Anwender w¨
ahlt bei-
spielsweise eine Bearbeiteransicht und zur Eingrenzung eine Abteilung. Die resultierende
Kalenderdarstellung zeigt dann die Auslastung jedes Mitarbeiters (alle Aktivit¨
aten).
Variante 2: Mehrere Instanzen
Abbildung 6.12 zeigt eine solche Darstellung. Einige Change Management Prozesse werden
hier reduziert auf die Bestandteile Evaluationsphase, Realisierungsphase und Abschluss-
phase dargestellt. Das Ergebnis ist eine sehr ¨
ubersichtliche informative ¨
Ubersichtsdarstel-
lung. Die Farbgebung, Balken im Inneren der Phasen oder Symbole wie das Ausrufezeichen
in der Abbildung weisen beispielsweise auf Verz¨
ogerungen beim Ablauf hin.
91
6. Darstellungsformen f¨
ur Prozessdaten
Variante 3: Mehrere Instanzen aus verschiedenen Schemata
Auf die besondere Problematik von Multi-Schema-Darstellungen weist Abschnitt 2.1.2 hin.
Analog zu Variante 1 l¨
asst sich die Visualisierung von Instanzen verschiedener Schemata
realisieren. Alle Instanzen eines Schemas werden dabei wie in Variante 1 dargestellt. Es
ist aber auch m¨
oglich, alle Schemata auf ein Grundschema zur¨
uckzuf¨
uhren. Damit k¨
onnen
v¨
ollig unterschiedliche Prozesse sehr ¨
ubersichtlich miteinander verglichen werden.
KW 41 heute KW 42
change request
Produkte
A-Klasse
Aufhängung HL
B-Klasse
Wischerautomatik
EPS Testfall 4b
Zündung optimieren
Klappern Front-Airbag R
← Log Vorhersage →
Realisierungsphase
!
Abbildung 6.12.: Kalenderdarstellung in Multi-Instanz Variante
Konfigurationsm¨
oglichkeiten
Konfigurationsm¨
oglichkeiten sind:
➣Darstellungsvariante w¨
ahlen
➣Zeiten einblenden
➣Balkenkonfiguration
➣Ausnahmen einblenden
➣Schleifen einblenden
➣Deaktivierte Aktivit¨
aten ausblenden
➣Aktivit¨
aten aller alternativer Ausf¨
uhrungspfade markieren
Zeiten einblenden
Da Zeiten wie die Fristen nicht immer von Interesse sind, lassen sie sich ein- und ausblen-
den. Eingeblendet erscheinen sie beispielsweise als rotes Kreuz. Welche Zeiten angezeigt
werden k¨
onnen, zeigt Abbildung 6.13.
Balkenkonfiguration
Hier kann das Aussehen der Aktivit¨
atenbalken ge¨
andert werden. Dies geschieht analog zur
Prozessgraphdarstellung (→6.1). Beispiele hierf¨
ur zeigt Abbildung 6.14. Hier sind zu einer
Variante jeweils drei F¨
alle abgebildet:
➣Normale Ausf¨
uhrung der Aktivit¨
at (gr¨
uner Balken).
➣Die Aktivit¨
at braucht schon l¨
anger als die geplante Endzeit, aber die gesetzte Frist
wurde noch nicht ¨
uberschritten (gelber Balken).
92
6.3. Kalenderdarstellung
geplante Startzeit
geplante Endzeit
Fristtatsächliche Startzeit
Fortschritt
wahrscheinliche Endzeit
CR Manager
Abbildung 6.13.: Planungszeiten in der Kalenderdarstellung
➣Die Aktivit¨
at konnte nicht innerhalb der gesetzten Frist abgeschlossen werden (roter
Balken).
Der linke Balkentyp erm¨
oglicht sehr ¨
ubersichtliche Darstellungen, wenn die Markierungen
f¨
ur geplante Start- & Endzeiten und Fristen ausgeblendet werden. Bei Verwendung des
rechten Balkentyps zeigen sich die verf¨
ugbaren Pufferzeiten sehr deutlich. Wenn die Akti-
vit¨
aten bald nach der geplanten Startzeit beginnen, zeigen sich viele gr¨
une Zonen, sonst
Rote.
Abbildung 6.14.: M¨
ogliche Balkenkonfigurationen in der Kalenderdarstellung
Im Inneren der Aktivit¨
aten-Balken kann entweder ein prozentualer Fortschrittsbalken an-
gezeigt werden oder ein Zeitbalken, der die tats¨
achlich seit Start der Aktivit¨
at vergangene
Zeit visualisiert. Sobald eine Aktivit¨
at l¨
anger als die geplante Dauer braucht, verl¨
angert
sich der Balken entsprechend. Prozentuale Fortschrittsbalken sind vor allem dann sinnvoll,
wenn die dargestellten Aktivit¨
aten Unterprozesse haben, dann zeigen die Balken deren
Fortschritt an.
Auf der rechten Seite der Balken lassen sich auch Texte (Aktivit¨
atenattribute) einblenden,
ohne die Lesbarkeit der Darstellung signifikant zu verschlechtern.
Deaktivierte Aktivit¨
aten ausblenden
Bei Instanz-Darstellungen werden alle nicht durchlaufenen Pfade des Prozesses ausgeblen-
det, um die Darstellung ¨
ubersichtlich zu gestalten.
Aktivit¨
aten aller alternativen Ausf¨
uhrungspfade markieren
F¨
ur die Zeit und Ressourcenplanung ist es wichtig, Aktivit¨
aten, die in jedem Fall ausge-
f¨
uhrt werden, von Aktivit¨
aten zu unterscheiden, die nicht in jedem Fall ausgef¨
uhrt wer-
den, d. h. Aktivit¨
aten, an deren Ausf¨
uhrung Bedingungen gekn¨
upft sind. Mithilfe dieser
Funktion k¨
onnen alle Aktivit¨
aten markiert werden, die sich in jeweils alternativen Aus-
f¨
uhrungspfaden befinden. Dies unterst¨
utzt die im Abschnitt 7.2.1 ¨
uber Markierungsregeln
93
6. Darstellungsformen f¨
ur Prozessdaten
angesprochene Funktion, die bei Selektion einer einzelnen Aktivit¨
at alle Aktivit¨
aten mar-
kiert, die sich in alternativen Ausf¨
uhrungspfaden befinden.
6.3.1. Dynamische Zeitachse
Die Unterteilung der Zeitachse entscheidet maßgeblich dar¨
uber, wie gut eine Kalenderdar-
stellung nutzbar ist. Microsoft Project bietet drei Ansichten, eine Tages-, eine Wochen- und
eine Monatsansicht. Auf den ersten Blick scheint eine solche Einteilung zu gen¨
ugen. Auf
diese Weise werden zwar ¨
Ubersichten ¨
uber verschiedene Zeitr¨
aume funktional erm¨
oglicht,
den Anwendern gen¨
ugt diese Einteilung jedoch nicht. Wichtiges Nutzerziel ist, sich eine
¨
Ubersicht ¨
uber Projekte und Teilprojekte zu verschaffen. Das bedeutet, dass die Zeitein-
teilung der Darstellung sich nach der jeweiligen (Teil-)Projektdauer richten soll. Wenn der
Nutzer die ¨
Ubersicht ¨
uber ein z. B. 6-w¨
ochiges oder 24-monatiges Projekt haben m¨
ochte,
dann ist eines seiner Ziele, eine Darstellung die genau diesen Projektzeitrahmen umfasst.
Vom Programm gesetzte Einschr¨
ankungen wie Wochen- und Monatsansichten wird der
Nutzer eher als hinderlich ansehen.
Letztlich handelt es sich nur um eine 1:1-Funktions¨
ubernahme von Kalendern auf Papier.
Jedoch kann eine Visualisierung auf dem Bildschirm deutlich mehr leisten, hier ist auch
eine dynamische Darstellung m¨
oglich. Beispielsweise ein Zeit-Scrollbalken, der nicht an
Monatsgrenzen halt macht. Oder eine Art Fish-Eye-View Ansicht, bei der nicht f¨
ur alle
Eintr¨
age gleichviel Platz vorgesehen ist, sondern ein Einzelner in der Mitte der Darstellung
gr¨
oßer ist und mehr Details anzeigt [Coop05].
6.4. Tabellendarstellung
Eine Tabelle kann sehr viele Informationen kompakt darstellen, in der Beispieltabelle 6.16
wird 3-mal mehr Information wiedergegeben, wie bei einer Prozessgraphdarstellung auf
gleichem Raum (vgl. Abbildung 1.3 →S. 7).
Beispiel
Das Beispiel aus Abbildung 6.15 zeigt eine Tabelle, die man auch als Aufgaben- oder
Aktivit¨
atenliste bezeichnen k¨
onnte, da die Zeilen topologisch nach der Aktivit¨
atsstruktur
geordnet sind. Die semantische Struktur ist zur besseren Lesbarkeit durch farbige Bl¨
ocke
untermalt. Dasselbe Prinzip ist auch schon bei der Prozessgraphdarstellung zum Tragen
gekommen (siehe Abbildung 6.4).
Die Beispieltabelle in Abbildung 6.16 deutet die M¨
oglichkeit an, Bl¨
ocke von Aktivit¨
a-
ten zur besseren ¨
Ubersicht zusammenzuklappen, um die Darstellung auf das momentan
Wesentliche zu begrenzen. Daf¨
ur bietet sich eine Baumstruktur an, wie sie die Benutzer
beispielsweise vom Windows Explorer her kennen. In einer solchen Baumstruktur l¨
asst
sich ein hierarchischer Prozess nat¨
urlich abbilden. Die Baumstruktur setzt allerdings eine
ganz bestimmte Sortierung voraus. Eine solche Tabelle l¨
asst sich dann nicht mehr nach
anderen Kriterien sortieren.
94
6.4. Tabellendarstellung
Außer einer an den Aktivit¨
aten orientierten Auflistung sind aber auch andere Auflistungen
denkbar. Solche Tabellen k¨
onnen nach allen Ressourcentypen sortiert sein, z. B. nach Aus-
f¨
uhrungseinheiten, Systemen oder Dokumenten, wobei wieder jede Zeile f¨
ur eine Aktivit¨
at
steht. Auch bei diesen anderen Sortierungen kann die ¨
Ubersichtlichkeit der Darstellung
durch Untermalung mit farbigen Bl¨
ocken verbessert werden. Bei einer Sortierung etwa
nach Organisationseinheit bilden alle der gleichen Einheit zugeordnete Aktivit¨
aten-Zeilen
einen Block. Dies kann geschachtelt erfolgen, ¨
ahnlich wie in Abbildung 6.16 dargestellt.
Jedoch f¨
arbt das Interface, bei vielen Hierarchiestufen, h¨
ochstens zwei oder drei ein (z. B.
Arbeitsgruppe, Abteilung, Ressort), da die Hinterlegung sonst zu viel Aufmerksamkeit auf
sich zieht.
function role system documents in documents out
initiate change request CR initiator
determine CR manager contact person
instruct expertise CR manager
generate expertise car body engineer CAD system
generate expertise electronic engineer CAD system
generate expertise motor engineer CAD system
generate expertise development chief CAD system
request evaluation CR manager
provide evaluation planning expert planning system
provide evaluation purchase expert planning system
provide evaluation quality expert planning system
request comments CR manager
provide comments planning expert
provide comments planning expert
provide comments construction expert
provide comments quality expert
approve CR CR approval board
start realization CR manager
realize CR (construction) construction engineer CAD system
start realization CR manager
realize CR (production) production engineer production planning
conclude CR CR manager
change request
modify CR
AND block
change request expertise->car body
change request expertise->electronic
change request expertise->motor
change request expertise expertise
EXCEPTION block ( CR modification required Ö modify CR, CR infeasible Ö conclude CR )
AND block
change request expertise
change request expertise
change request expertise
EXCEPTION block ( CR modification required Ö modify CR, CR infeasible Ö conclude CR )
AND block
evaluation change request
evaluation change request
evaluation change request
evaluation change request
evaluation change request
change request
CR modification required Ö modify CR
CR modification required Ö modify CR
Abbildung6.15.:Tabellendarstellung des Change-Management-Prozesses – Einfache Tabelle (ohne
Hierarchie)
M¨
achtigkeit des Konzeptes
Die Tabellendarstellung eignet sich auch f¨
ur sehr große Prozesse, denn kein anderes Kon-
zept bietet derart kompakte Darstellungen. Allerdings kann der Kontrollfluss praktisch
nicht dargestellt werden. In einer Tabellenvariante, in der die Aktivit¨
aten in den Zeilen so
sortiert sind, dass sequenziell ausgef¨
uhrte Aktivit¨
aten immer einen Block bilden, l¨
asst sich
der Kontrollfluss rudiment¨
ar abbilden. Bei gr¨
oßeren Schachtelungstiefen bringt aber auch
dies keine gen¨
ugende ¨
Ubersicht mehr ¨
uber den Kontrollfluss. Hinweise auf Verzweigungen,
Schleifen, Ausnahmen und Spr¨
unge (siehe Abschnitt 5.3.2) lassen sich in den Tabellen-
spalten unterbringen, praktikabler d¨
urften jedoch Symbole sein, ¨
uber denen Tooltipps die
Details zu Verzeigungsbedingungen und ¨
Ahnlichem anzeigen. Um die mangelhafte Darstel-
95
6. Darstellungsformen f¨
ur Prozessdaten
id function role system documents in documents out jump destination
1
1.1 CR initiator
1.2 contact person
2
2.1 CR manager
2.2
2.3 car body engineer CAD system
2.4 electronic engineer CAD system
2.5 motor engineer CAD system
2.6 development chief CAD system
3
3.1 request evaluation CR manager
3.2 provide evaluation planning expert planning system
3.3 provide evaluation purchase expert planning system
3.4 provide evaluation quality expert planning system 2.2 modify CR
8.1 conclude CR
4
4.1 request comments CR manager
4.2 provide comments planning expert
4.3 provide comments planning expert
4.4 provide comments construction expert
4.5 provide comments quality expert 2.2 modify CR
8.1 conclude CR
5
5.1 approve CR CR approval board
6
6.1 start realization CR manager 2.2 modify CR
6.2 realize CR (construction) construction engineer CAD system 2.2 modify CR
7
7.1 start realization CR manager
7.2 realize CR (production) production engineer production planning
8
8.1 conclude CR CR manager
main process (level 1)
5 initiation
5 initiate change request change request
5 determine CR manager
expertise
5 instruct expertise
modify CR
5 AND block
5 generate expertise change request expertise->car body
7 generate expertise change request expertise->electronic
5 generate expertise change request expertise->motor
generate expertise change request expertise expertise
evaluation
EXCEPTION block
AND block
change request expertise
change request expertise
change request expertise
®CR modification required
°CR infeasible
commenting
EXCEPTION block
AND block
evaluation change request
evaluation change request
evaluation change request
evaluation change request
®CR modification required
°CR infeasible
approval
evaluation change request
realization in construction
change request
®CR modification required
®CR modification required
realization in production
conclusion
Abbildung 6.16.: Tabellendarstellung des Change-Management-Prozesses – Normale Tabelle
lung des Kontrollflusses zu kompensieren, kann die Darstellung, wenn eine Zeile selektiert
ist, mit kleinen Markierungen auf Folgeaktivit¨
aten aufmerksam machen.
Das Organisationsmodell hat bei dieser Darstellung keine besondere Bedeutung, jedoch
k¨
onnen dadurch beispielsweise in einer Spalte die Abteilungen aufgelistet werden, zu denen
der Bearbeiter der Aktivit¨
at geh¨
ort. Dies erfolgt, indem die Abteilungsinformation aus
dem Organisationsmodell von der Bearbeiterinformation abgeleitet wird. Dadurch k¨
onnen
zusammengeh¨
orige Aktivit¨
aten, die alle einer Abteilung zuzurechnen sind, durch farbig
markierte Bl¨
ocke hervorgehoben werden.
Dargestellte Prozessinformationen
Die Verzweigungsstruktur eines Prozesses, der durch den Kontrollfluss festgelegt wird,
wird aus einer Tabelle nur dann ersichtlich, wenn sie topologisch sortiert ist. In diesem Fall
k¨
onnen Aktivit¨
aten die logische Bl¨
ocke bilden, in der Tabelle gruppiert dargestellt werden.
Sobald eine Tabelle nach anderen Kriterien sortiert wird, kann der Informationsaspekt des
Kontrollflusses nur noch insoweit wiedergegeben werden, indem eine Tabellenspalte, die
topologische ID jeder Aktivit¨
at anzeigt. Das Benutzer-Interface kann jedoch Funktionen
anbieten, die jeweilige(n) Folgeaktivit¨
at(en) zur aktuell selektierten Aktivit¨
at optisch in
der Tabelle zu markieren. Die auch zum Kontrollfluss geh¨
origen Informationen zu Verzei-
gungsbedingungen, Ausnahmen, Schleifen und Spr¨
ungen lassen sich in zus¨
atzlichen Spalten
darstellen oder in Tooltipps unterbringen, jedoch bleibt bei einer Tabellendarstellung die
Wiedergabe des Kontrollflusses prinzipbedingt mangelhaft. Der Datenfluss l¨
asst sich nur
96
6.4. Tabellendarstellung
implizit darstellen, indem in den Aktivit¨
atenzeilen ein- und ausgehende Dokumente an-
gezeigt werden. Den Mittelpunkt der Darstellung bilden immer die Aktivit¨
aten mit den
ihnen zugeordneten Informationen. Diese k¨
onnen nach jedem Kriterium sortiert werden.
Eine Multi-Instanz Variante erm¨
oglicht auch den Zugriff auf den instanzbezogenen Teil
der Prozessinformationen (z. B. zugeordnetes Produkt).
Vor- und Nachteile
Tabellen bieten eine sehr kompakte Darstellung von Prozessabl¨
aufen. In keiner anderen
Darstellungsform lassen sich so viele Aktivit¨
aten auf begrenztem Bildschirmplatz unter-
bringen. Und selbst bei großen Prozessen ist nur vertikales Scrollen n¨
otig, um den Prozess-
verlauf zu verfolgen. Tabellen k¨
onnen eine ’unbegrenzte Menge’ von Aktivit¨
atendetails in
ihren Spalten anzeigen.
Durch Multi-Instanz-Ansichten k¨
onnen viele Instanzen desselben Schemas effektiv mit-
einander verglichen werde; auf Wunsch werden vorhandene Informationen aggregiert oder
Details von mehreren Instanzen untereinander dargestellt.
Prozessgraphen zeigen die Prozessstruktur sehr viel intuitiver an, als das bei Tabellen
m¨
oglich ist. Bei großen Prozessen mit großen Schachtelungstiefen kann die ¨
Ubersicht sehr
schnell verloren gehen. Bei nicht blockstrukturierten Prozessen l¨
asst sich die Struktur be-
sonders schlecht darstellen, da in solchen F¨
allen Sprungziele an andere Stellen der Tabelle
angegeben sind und die Tabelle, selbst bei einer Sortierung nach Ausf¨
uhrungsreihenfolge,
nicht mehr sequenziell gelesen werden kann. Jedoch d¨
urfte f¨
ur Benutzer dieser Darstel-
lungsform die Prozessstruktur meist von untergeordneter Bedeutung sein.
M¨
ogliche Variationen
Variation 1: Arbeitsliste
Um sich schnell einen ¨
Uberblick ¨
uber die aktuellen und anstehenden T¨
atigkeiten innerhalb
eines Prozesses zu verschaffen, reicht eine einfache Arbeits- oder Aktivit¨
atenliste aus. Sie
zeigt nur Aktivit¨
aten und die ihnen zugeordneten Bearbeiter an. Dabei k¨
onnten aktuell
in der Ausf¨
uhrung befindliche Aktivit¨
aten und/oder ausf¨
uhrungsbereite Aktivit¨
aten dar-
gestellt werden. Die Darstellung macht auch deutlich, ob das PMS ausf¨
uhrungsbereiten
Aktivit¨
aten jeweils einen konkreten Bearbeiter zugeordnet hat. Bereit-Zeiten3Priorit¨
aten
oder Deadlines lassen sich ebenfalls einblenden. Außer nach Bearbeitern, kann diese Liste
auch nach allen anderen genannten Kriterien sortiert werden.
Das Konzept einer Liste f¨
ur einen Grund-Prozess l¨
asst sich leicht f¨
ur den Multi-Instanz-
Fall erweitern. Dann wird nur eine weitere Spalte notwendig, die den Prozess kennzeichnet,
dem die jeweilige Aktivit¨
at zugeordnet ist. Das erm¨
oglicht dann auch, die T¨
atigkeiten nach
Prozessen zusammenzufassen. Falls ein Kundenattribut gegeben ist, k¨
onnen die Aufgaben
auch nach Kunden zusammengefasst werden. Optional ist es m¨
oglich, die Liste nach Akti-
vit¨
aten zu sortieren, sodass gleiche Aktivit¨
aten untereinander erscheinen. Somit kann der
Bearbeiter effizienter arbeiten, indem er gleiche Arbeitsschritte am St¨
uck bearbeitet.
Eine Arbeitsliste, die speziell f¨
ur einen konkreten Mitarbeiter dargestellt wird, zeigt nat¨
ur-
lich nur die ihm zugeordneten, ausf¨
uhrungsbereiten Aktivit¨
aten beziehungsweise die vom
3Ein Zeitstempel, der anzeigt, wann eine Aktivit¨
at in den Zustand ’bereit zur Ausf¨
uhrung’ wechselte.
Eine Abarbeitung nach Bereit-Zeit entspricht dem FIFO-Prinzip.
97
6. Darstellungsformen f¨
ur Prozessdaten
PMS noch nicht zugeordneten Aktivit¨
aten, f¨
ur die er als m¨
oglicher Bearbeiter in Frage
kommt. Diese beiden Sorten von Aktivit¨
aten k¨
onnen auch gruppiert dargestellt werden.
Zur Motivation sollten auch bereits erledigte Aktivit¨
aten aufgelistet werden k¨
onnen. Als
weitere Anwendungsm¨
oglichkeit lassen sich in naher Zukunft anstehende Aktivit¨
aten auf-
listen. Hierf¨
ur werden aktuell laufende Instanzen entsprechend ausgewertet.
Variation 2: Einfache Tabelle
Abbildung 6.15 zeigt den gesamten Change Management Prozess, die ausgegrauten Ein-
tr¨
age am Anfang der Tabelle repr¨
asentieren hier beendete Aktivit¨
aten. Sie deuten an,
wie weit die Prozessausf¨
uhrung fortgeschritten ist. Fett formatierte Eintr¨
age sind aktuell
laufende Aktivit¨
aten. Die Tabelle l¨
asst sich nicht umsortieren, sie zeigt die Aktivit¨
aten
immer in einer Reihenfolge an, in der die Blockstruktur soweit m¨
oglich visualisiert wird.
Aktivit¨
aten, die sequenziell ausgef¨
uhrt werden, stehen dadurch immer untereinander und
sind durch eine Linie voneinander abgetrennt. Parallel ausgef¨
uhrte Aktivit¨
aten werden da-
gegen durch keine Linie getrennt. Ausnahmebehandlungsaktivit¨
aten (hier: ’modify CR’)
erscheinen ebenfalls als Eintr¨
age. Die Stellen, an denen solche Ausnahmen ausgel¨
ost wer-
den k¨
onnen, zeigen die Ausnahmebedingungen und die jeweiligen Sprungziele.
Variation 3: Normale Tabelle
Jede Zeile hat hier eine eindeutige Nummerierung, die von der topologischen Sortierung
abgeleitet ist. Dies erlaubt es, die Tabelle nach jeder beliebigen Spalte zu sortieren und
dennoch die Ausf¨
uhrungsreihenfolge im Blick zu behalten.
Durch das Sortieren nach einer Spalte, entstehen in dieser Spalte Gruppen mit gleichen
Elementen. Wenn z. B. nach Bearbeitern sortiert wird, bilden alle Zeilen (die jeweils f¨
ur
eine Aktivit¨
at stehen), die einem bestimmten Bearbeiter zugeordnet sind, eine Gruppe.
Diese Gruppen werden besonders gekennzeichnet, z. B. durch farbige Hinterlegung, analog
zur Hervorhebung der Blockstruktur bei der ’Einfachen Tabelle’.
Auch eine Sortierung nach mehreren Kriterien (Spalten) ist m¨
oglich, beispielsweise prim¨
ar
nach Dokumenten und sekund¨
ar nach Bearbeitern. Dadurch kann sich der Anwender einen
¨
Uberblick verschaffen, an wie vielen Stellen im Prozess ein und derselbe Bearbeiter an
einem Dokument arbeitet.
Die Details, die in den Spalten angezeigt werden, sind beliebig konfigurierbar. Details,
die besonders h¨
aufig von Interesse sind, k¨
onnen vom Benutzer in den am weitesten links
stehenden Spalten angeordnet werden, um h¨
aufiges horizontales Scrollen zu vermeiden.
Ein komfortables System bietet dem Benutzer das Speichern und Wiederherstellen von
Spaltenkonfigurationen an, sodass die ben¨
otigten Informationen zu Aktivit¨
aten schnell zur
Verf¨
ugung stehen. Dies kann in Analogie, zur Prozessgraphdarstellung erfolgen. Ebenso
kann die Knotenkonfiguration ¨
uber ein Fenster im Aufgabenbereich schnell umgeschaltet
werden.
Variation 4: Hierarchische Tabelle
Im Gegensatz zu den bisher diskutierten Tabellentypen zeigt Abbildung 6.16 einen hier-
archischen Prozess ¨
uber zwei Ebenen. Da Aktivit¨
aten eines Prozesses wiederum andere
Prozesse kapseln k¨
onnen, ist es gegebenenfalls sinnvoll solche integrierten Darstellungen
98
6.4. Tabellendarstellung
erzeugen zu k¨
onnen. Innerhalb der ersten Prozess-Ebene, die aus acht Schritten besteht,
sind ihre Kindprozesse eingebettet.
In der dargestellten Tabelle sind Aktivit¨
aten, die bereits in der Vergangenheit ausgef¨
uhrt
worden sind, grau hinterlegt. Blockstrukturen sind nicht nur farbig hinterlegt, sondern
lassen sich auch zusammenfalten, um die Darstellung bei Bedarf auf das Wesentliche re-
duzieren zu k¨
onnen.
Multi-Instanz Tabelle
Es sind Tabellenansichten denkbar und auch sinnvoll, die eine ¨
Ubersicht zu allen Instanzen
eines Prozessschemas verschaffen.
Was die Navigation anbelangt, erm¨
oglicht das Benutzer-Interface von den Multi-Instanz-
Ansichten aus, beispielsweise per Kontextmen¨
u wieder zu (Einzel-)Instanz-Darstellungen
zur¨
uckzuwechseln.
Variation 1: Multi-Instanz ¨
Ubersicht
Jede Zeile der Tabelle stellt eine Instanz dar. In den Spalten stehen Informationen zur je-
weiligen Instanz, prinzipbedingt jedoch keine Informationen zu den einzelnen Aktivit¨
aten.
Angezeigt werden kann in Tabellenspalten beispielsweise der Prozessstatus oder die aggre-
gierten Gesamtkosten, gesch¨
atzte Kosten, gesch¨
atzter Abschlusszeitpunkt und ¨
ahnliche
Instanzbezogene Informationen. Eine sinnvolle Angabe ist auch das zugeordnete Produkt
(oder Objekt). Weitere wichtige Informationen ¨
uber die Instanzen liefern beispielsweise
das Instanziierungsdatum, die zuletzt aktivierte Aktivit¨
at und dessen Bearbeiter oder das
Datum der letzten ¨
Anderung. Nach allen Spalten kann sortiert werden.
Der Prozessstatus kann durch einen einfachen grafischen Prozentbalken visualisiert wer-
den, der angibt, wie viele seiner Aktivit¨
aten bereits durchlaufen sind. Auch eine Angabe
des erwarteten fr¨
uhesten Abschlusszeitpunktes ist bei gegebenen durchschnittlichen Bear-
beitungszeiten m¨
oglich.
Hier ist auch eine Baumstruktur nach Art des Windows Explorer m¨
oglich. Die Einteilung
in Ordner kann via Produktangabe oder z. B. Kalenderwoche zur Instanziierungszeit er-
folgen. Auf diese Weise ist sogar eine Multi-Schema-¨
Ubersichtsdarstellung m¨
oglich, wenn
die Prozesshierarchie als Baumstruktur wiedergegeben wird.
Variation 2: Multi-Instanz-Ansicht
Bei diesem Ansatz werden die Aktivit¨
aten des zugrunde liegenden Prozessschemas aufge-
listet und in den Spalten m¨
ogliche aggregierte Werte angezeigt. Interessant d¨
urften vor
allem Minimal-, Maximal- und Durchschnittswerte sein (d. h. Kosten). Werte die sich nur
als Mengen darstellen lassen, wie beispielsweise die verschiedenen den Aktivit¨
aten zuge-
ordneten Ausf¨
uhrungseinheiten, lassen sich nur ¨
uber eingeblendete Tooltipps oder ¨
uber
eine Detailansicht im Aufgabenbereich (siehe Abschnitt 7.4) darstellen. Das zugeh¨
orige
Tabellenfeld kann aber zumindest ¨
uber die Mengenkardinalit¨
at Auskunft geben. Eine Ta-
bellenspalte zeigt einen segmentierten Balken mit einem Segment pro Instanz. Die Seg-
mente geben ¨
uber eine Farbcodierung entsprechend ¨
uber Aktivit¨
atenstatus (abgeschlossen,
laufend, bereit, nicht bereit, etc.) Auskunft; alternativ kann dies ¨
uber eine einfache Pro-
zentangabe geschehen, die f¨
ur die Anzahl der bereits abgeschlossenen Aktivit¨
aten steht.
99
6. Darstellungsformen f¨
ur Prozessdaten
Variation 3: Multi-Instanz Aktivit¨
atenprojektion
Im Zusammenhang mit Variante 2 k¨
onnte schnell der Wunsch aufkommen, einzelne Akti-
vit¨
aten verschiedener Instanzen direkt miteinander zu vergleichen. Zu diesem Zweck kann
eine Ansicht generiert werden, die genau eine ausgew¨
ahlte Aktivit¨
at f¨
ur alle Instanzen in
eine Tabelle projiziert. Das heißt, f¨
ur jede Instanz in einer Zeile jeweils die Informationen
¨
uber die entsprechende Aktivit¨
at dieser Instanz anzeigt. Auf diese Art und Weise lassen
sich parallel ablaufende Instanzen detailliert ¨
uberwachen und die Werte in den Tabellen-
eintr¨
agen m¨
ussen nicht mehr aggregiert werden, da jede Zeile f¨
ur eine Instanz steht.
Der Benutzer kann direkt in der Reihenfolge der logischen Blockstruktur (oder alternativ
in topologischer Reihenfolge) vorw¨
arts oder r¨
uckw¨
arts zur n¨
achsten Aktivit¨
at im Prozess
schalten. Denkbar w¨
are auch die M¨
oglichkeit bei eingeblendetem ¨
Ubersichtsfenster (sie-
he Abschnitt 7.5) per Doppelklick direkt zu einer anderen Aktivit¨
at zu wechseln. Dieses
¨
Ubersichtsfenster zeigt immer an, welche Aktivit¨
at im Moment dargestellt wird.
Konfigurationsm¨
oglichkeiten
Konfigurationsm¨
oglichkeiten sind:
➣Darstellungsvariante w¨
ahlen
➣Spalten konfigurieren
➣Blockmarkierungen an/aus
➣Zeilen mit deaktivierten Aktivit¨
aten ausblenden
Blockmarkierungen an/aus
Der Benutzer kann festlegen, ob mehrere untereinander liegende Zeilen als Block markiert
werden sollen, falls sie sich gruppieren lassen; etwa alle Aktivit¨
aten, deren Bearbeiter der
gleichen Abteilung angeh¨
oren.
Zeilen mit deaktivierten Aktivit¨
aten ausblenden
Bei Instanz-Darstellungen werden alle Aktivit¨
aten-Zeilen ausgeblendet, die nicht durch-
laufen wurden, so dass eine ¨
ubersichtliche Darstellung resultiert.
6.4.1. Implementierungsaspekte
Große Tabellen brauchen schnell mehr als eine Bildschirmseite Platz. Daher sollte das
Scrolling so implementiert werden, dass die Spaltenbeschriftung immer am oberen Rand
sichtbar bleibt. Je nach Tabelle bleibt so eventuell auch der linke Rand immer sichtbar, bei-
spielsweise wenn die erste Spalte grafisch die Gruppierung der einzelnen Zeilen zueinander
markiert.
6.5. Interaktionsdiagramm
Das Interaktionsdiagramm und die Matrixdarstellung (siehe Abschnitt 6.7), nehmen ei-
ne Sonderstellung unter den bisher er¨
orterten Darstellungsformen ein. Wie Abbildung 6.1
100
6.5. Interaktionsdiagramm
(→S. 74) zeigt, lehnen sich Prozessgraph, Swimlane, Kalender und Tabelle, was die Struk-
turierung der Darstellung angeht, haupts¨
achlich an die Prozessstruktur an. Die Matrixdar-
stellung dagegen zeigt die Zusammenh¨
ange zwischen jeweils zwei Prozess-Aspekten. Die
Aufgabe des Interaktionsdiagramms ist es wiederum, Informationsfl¨
usse ad¨
aquat zu visua-
lisieren. Sie stellen eine Abstraktion aus dem Prozessablauf dar.
Die hier gew¨
ahlte Form ist an Sequenzdiagramme, bekannt z. B. aus UML 2.0
[Omg 05b], angelehnt. Sequenzdiagramme sind auch unter dem Namen Message Sequence
Charts (MSC) bekannt. Die Aufgabe von Sequenzdiagrammen ist es, das Interobjektver-
halten zu beschreiben, d. h. den Austausch von Nachrichten zwischen einzelnen Objekten
– ihre Interaktion. Weil der Begriff Interaktion besser als der Begriff Sequenz beschreibt,
dass es hier um die Darstellung des Informationsflusses geht, wird hier der Name Interak-
tionsdiagramm gew¨
ahlt.
Die prim¨
are Zielsetzung besteht darin, die Interaktion zwischen zwei Abteilungen zu visua-
lisieren. Damit lassen sich auch die beiden weniger komplexen Interaktions-Szenarien ’Be-
arbeiter - Bearbeiter’ und ’Bearbeiter - Abteilung’ darstellen. Letztlich l¨
asst sich die Kom-
munikation zwischen verschiedensten Organisationseinheiten, etwa von Arbeitsgruppen
visualisieren. Wenn Zugriff auf unternehmens¨
ubergreifende Prozesse besteht, k¨
onnen auch
die Kommunikationsschnittstellen zwischen zwei Unternehmen ausgewertet werden.
Sobald der Anwender zwei Organisationseinheiten ausgew¨
ahlt hat – das k¨
onnen im ein-
fachsten Fall auch zwei Rollenangaben oder Personen sein – besteht der erste Schritt darin,
Interaktionen aus den vorhandenen Prozessdaten zu extrahieren. Hierf¨
ur werden die Aus-
f¨
uhrungseinheiten, der am Prozess beteiligten Aktivit¨
aten, untersucht, ob sie einer der
beiden ausgew¨
ahlten Organisationseinheiten zugeordnet sind. Mithilfe der beiden folgen-
den Regeln, lassen sich dann die Stellen eines Prozesses herausfiltern, wo Interaktionen
zwischen den beiden ausgew¨
ahlten Organisationseinheiten stattfinden k¨
onnen:
1. Der Zugriff auf ein Dokument erfolgt nacheinander von beiden Ausf¨
uhrungseinheiten.
2. Zwei unmittelbar aufeinanderfolgende Aktivit¨
aten, die den beiden Ausf¨
uhrungsein-
heiten zugeordnet sind.
Dies sind zwei notwendige Bedingungen f¨
ur eine Interaktion, hinreichende Bedingungen
k¨
onnen nur definiert werden, wenn das verwendete Metamodell Interaktionen explizit de-
klariert.
Beispiel
Abbildung 6.17 zeigt ein Interaktionsdiagramm zwischen zwei Abteilungen. In der Pro-
zessablaufreihenfolge werden nacheinander alle Schnittstellen innerhalb des Prozesses zwi-
schen den beteiligten Ausf¨
uhrungseinheiten dargestellt. Die an der Schnittstelle beteiligten
Aktivit¨
aten werden dargestellt, hier mit Nennung der jeweiligen Bearbeiter. Schnittstellen
k¨
onnen aus mehreren in Reihe oder parallel ablaufenden Interaktionen bestehen. Die ein-
zelnen Schnittstellen sind optisch durch einen Trennstrich voneinander getrennt. Die Art
einer Interaktion ist sofort aus der Kantenfarbe ersichtlich.
Durch die oben genannten Regeln, lassen sich zwei Arten des Informationsflusses unter-
scheiden: Kontrollflussinteraktion und Datenflussinteraktion. Diese k¨
onnen, wie im Bei-
spiel, auch kombiniert auftreten. ¨
Uberall wo Daten ausgetauscht werden, sind die betei-
ligten Dokumente (oder Daten) entlang der Interaktionskante aufgelistet.
101
6. Darstellungsformen f¨
ur Prozessdaten
Development
parallel
Management
provide comments
quality expert
provide comments
planning expert
request comments
CR manager
provide evaluation
planning expert
request evaluation
CR manager
generate expertise
development chief
change requestchange request
Legende
Kontrollflussinteraktion
Datenflussinteraktion
Abbildung 6.17.: Interaktionsdiagramm – Schnittstellen zwischen Abteilungen
M¨
achtigkeit des Konzeptes
Das Interaktionsdiagramm in der hier beschriebenen Form ist von MSC-Darstellungen ab-
geleitet, eine Verwandtschaft zur Swimlane-Darstellung besteht jedoch auch. In Swimlanes
k¨
onnen mit Hilfe geeigneter Zusammenfassungen der Lanes ¨
ahnliche Darstellungen erzeugt
werden. Dort sind sie jedoch nicht auf zwei Organisationseinheiten begrenzt. Interaktions-
diagramme sind jedoch im Allgemeinen ¨
ubersichtlicher.
Die Anwendungsm¨
oglichkeiten zur Darstellung von Interaktionen beschr¨
anken sich nicht
auf die Auswahl zweier beliebiger Organisationseinheiten. Allgemein k¨
onnen zwei beliebige
disjunkte Mengen aus der Gesamtheit aller Organisationseinheiten f¨
ur die Visualisierung
herangezogen werden. Als Datenbasis k¨
onnen einzelne Schemata oder Instanzen dienen. Es
k¨
onnen aber auch viele Prozessschemata gleichzeitig auf Interaktionen untersucht werden.
Es ist somit auch m¨
oglich, dass sich ein Anwender (zumindest auf Rollenbasis) alle Kom-
munikationsschnittstellen zu Mitarbeitern aus anderen Abteilungen oder zu allen anderen
Mitarbeitern visualisieren lassen kann. F¨
ur konkrete Bearbeiter gelingt dies jedoch nicht,
da die Bearbeiterinformationen mehrerer Instanzen desselben Schemas beim Aggregieren
verloren gehen beziehungsweise durch Rollenangaben ersetzt w¨
urden.
Die Darstellung ber¨
ucksichtigt die Ablaufreihenfolge und es wird zwischen sequenziell und
parallel ablaufenden Interaktionen unterschieden. Oder- & Und-Verzweigungen lassen sich
¨
uber beschriftete Gruppierungen (siehe Abbildung 6.17) unterscheiden. Verzweigungsbe-
dingungen lassen sich ¨
uber Tooltipps in Erfahrung bringen. Schleifen lassen sich durch
Symbole an den einzelnen Prozessschnittstellen kenntlich machen. Die Darstellung von
Interaktionen l¨
asst sich auf einzelne Schemata und Instanzen begrenzen. Es k¨
onnen aber
auch Spr¨
unge mit ausgewertet werden oder ganze Teile aus der Prozesshierarchie auf In-
teraktionen hin untersucht werden.
102
6.6. Datenflussdiagramm
Synchronisationskanten k¨
onnen auch f¨
ur Interaktionen stehen. Bei Bedarf k¨
onnte so noch
eine dritte Interaktionsregel (siehe oben) eingef¨
uhrt werden: ”Eine Synchronisationskante
verbindet zwei Aktivit¨
aten, die den beiden Ausf¨
uhrungseinheiten zugeordnet sind.“
Vor- und Nachteile
Interaktionsdiagramme stellen ein ¨
außerst effizientes Visualisierungskonzept dar. Die er-
zeugten Darstellungen sind sehr ¨
ubersichtlich, auch weil konzeptbedingt maximal eine Ver-
zweigungstiefe angezeigt wird. Mithilfe von Interaktionsdiagrammen erh¨
alt der Anwender
sehr schnell eine kompakte Sicht auf den Prozess mit den gew¨
unschten Informationen.
Auch Prozessverantwortliche oder andere Personen, die f¨
ur andere Anwender Views er-
stellen, finden hierin ein geeignetes Werkzeug um personalisierte Views f¨
ur bestimmte
Nutzerkreise, beispielsweise Unternehmenskunden zu erstellen.
M¨
ogliche Variationen
Es existieren keine besonderen Varianten. Durch die vielen m¨
oglichen Kombinationen von
Organisationseinheiten erh¨
alt die Darstellung jedoch auch eine starke Variabilit¨
at. Bei der
Darstellung einer Instanz werden Oder-Verzweigungspfade, die nicht gew¨
ahlt wurden grau
markiert. Nicht ausgef¨
uhrte Aktivit¨
aten erhalten eine entsprechende Zustandsmarkierung
(siehe Abschnitt 5.3.3). Wenn die Kommunikationsschnittstellen mehrerer Schemata dar-
gestellt werden, wird der jeweilige Herkunftsprozesses angezeigt.
Konfigurationsm¨
oglichkeiten
Als graphbasierte Darstellungsart, ¨
ahneln die Konfigurationsm¨
oglichkeiten denen der Pro-
zessgraphdarstellung. Weitere Konfigurationsm¨
oglichkeiten sind:
➣Organisationseinheiten w¨
ahlen
➣Spr¨
ungen (Verweisen) zu anderen Prozessen folgen
Spr¨
ungen (Verweisen) zu anderen Prozessen folgen
Der Benutzer kann festlegen, ob auch weitere mit dem Schema verbundene Schemata f¨
ur
die Suche nach Interaktionen mit herangezogen werden sollen.
6.5.1. Notwendige Voraussetzungen
Der Einsatz von Interaktionsdiagrammen wird lediglich durch die, im Organisationsmodell
beschriebenen, Organisationseinheiten begrenzt.
6.6. Datenflussdiagramm
Datenflussdiagramme (DFD) sind vor allem als Modellierungssicht und Teil von UML
bekannt. Entwickler erstellen im Rahmen der Analyse diese Diagramme. Das Ziel der
Prozessvisualisierung geht jedoch in die andere Richtung, Diagramme sollen hierf¨
ur auto-
matisch erzeugt werden.
103
6. Darstellungsformen f¨
ur Prozessdaten
¨
Ahnlich wie bei den UML-Datenflussdiagrammen ist das Ziel dieser Darstellungsform den
Daten- und Dokumentfluss darzustellen. Jedoch wird immer nur ein Dokument oder eine
Datenstruktur f¨
ur die Visualisierung ausgew¨
ahlt. Die Darstellung erfolgt anhand einer
abstrakten Graphdarstellung.
Beispiel
Abbildung 6.18 zeigt ein Datenflussdiagramm des Dokuments ’change request’ aus dem
Change-Management-Prozess. In der gezeigten Prozessansicht erscheinen alle an der Bear-
beitung des Dokuments beteiligten Aktivit¨
aten in Ausf¨
uhrungsreihenfolge. Verzweigungen
werden dabei normal dargestellt. Die Kanten sind je nach Zugriffstyp farblich markiert.
Die Zuordnung ist aus der Legende ersichtlich (siehe Abschnitt 7.4).
provide comments
planning expert
initiate change
request
CR initiator
generate expertise
electrical engineer
generate expertise
car body engineer
generate expertise
motor engineer
provide evaluation
planning expert
provide evaluation
purchase expert
provide evaluation
quality expert
provide comments
planning expert
provide comments
construction expert
provide comments
quality expert
start realization
CR manager
change request
change request
Legende
Schreiben / Erzeugen (rot)
Lesen (grün)
Abbildung 6.18.: Datenflussdiagramm – Dokument: change request
M¨
achtigkeit des Konzeptes
Die Darstellung erlaubt es den Ablauf eines Prozesses aus der Sicht eines Dokumentes zu
verfolgen. Der Kontrollfluss l¨
asst sich analog zur Prozessgraphdarstellung anzeigen, bleibt
aber auf die jeweilige Sicht begrenzt. Außer prozess-lokalen Dokumenten, l¨
asst sich auch
der Dokumentfluss (eines global zugreifbaren Dokumentes) in Prozesshierarchien verfolgen.
Auch eine aggregierte Multi-Instanz Darstellung ist m¨
oglich.
Vor- und Nachteile
Durch die sehr begrenzte View ist der Datenfluss selbst bei großen Prozessen gut nach-
vollziehbar. Wenn zwingend mehr als ein Dokumentfluss dargestellt werden soll, muss
beispielsweise auf eine Swimlane-Darstellung ausgewichen werden, die die Aktivit¨
aten zu
gew¨
unschten Dokumenten/Daten in jeweils verschiedenen Lanes f¨
uhrt.
M¨
ogliche Variationen
Außer der vorgestellten Variante, die den Datenfluss eines Dokumentes innerhalb eines
Schemas oder einer Instanz anzeigt, l¨
asst sich auch eine prozess¨
ubergreifende Variante
und eine Multi-Instanz Dokumenten¨
ubersicht realisieren.
104
6.7. Matrixdarstellung
Prozessübergreifendes Datenflussdiagramm
Diese Variante erm¨
oglicht, dass Dokumente, die innerhalb einer Prozesshierarchie an ver-
schiedenen Stellen (Prozessen) verwendet werden, ebenso in einer Datenflussansicht darge-
stellt werden k¨
onnen, wie lokale Dokumente eines Prozesses. Hierf¨
ur wird die Ausf¨
uhrungs-
reihenfolge innerhalb der Prozesshierarchie bestimmt. Daraus wird ein Datenflussgraph er-
zeugt. Die Ausf¨
uhrungsreihenfolge muss nicht in eine Sequenz zerlegbar sein: unbestimmte,
bedingte oder parallele Ausf¨
uhrungsfolgen, werden in entsprechende Verzweigungsstruk-
turen umgesetzt. Der Graph stellt initial nur einen Knoten pro beteiligtem Prozess dar.
Prozesse, die mehrere Aktivit¨
aten enthalten, die auf das Dokument zugreifen, lassen sich
analog zur Darstellung von Subprozessen ¨
offnen (vgl. Abbildung 5.7 →S. 66).
Multi-Instanz Variante
Mehrere Instanzen eines Schemas werden aggregiert dargestellt, indem eine Status-Infor-
mation ¨
uber jedem Knoten eingeblendet wird. Dies kann ein segmentierter Balken sein, der
in jedem Segment farbcodiert ¨
uber den Aktivit¨
atenstatus (abgeschlossen, laufend, bereit,
nicht bereit, etc.) der aggregierten Aktivit¨
aten Auskunft gibt. Diese Variante kann dazu
verwendet werden, sich schnell einen ¨
Uberblick ¨
uber den Fortschritt/Zustand, beispiels-
weise jedes ’change request’ Dokumentes der angezeigten Instanzen zu verschaffen.
Konfigurationsm¨
oglichkeiten
Als graphbasierte Darstellungsart, ¨
ahneln die Konfigurationsm¨
oglichkeiten denen der Pro-
zessgraphdarstellung.
6.7. Matrixdarstellung
Die bisher vorgestellten Darstellungsformen erlauben die Visualisierung aller m¨
oglichen
Aspekte von Prozessinformationen. Es fehlt noch eine Darstellung, die es erlaubt, Zusam-
menh¨
ange zwischen all diesen Aspekten darzustellen. Daraus ergibt sich ganz nat¨
urlich die
Darstellung von je zwei dieser Aspekte als Matrix, die solche Verbindungen explizit ma-
chen. Von dieser Darstellungsform existieren verschiedene Varianten, es gibt keine explizite
Hauptform. Die m¨
oglichen Variationen der Matrixdarstellung zeigt Tabelle 6.2.
Die Felder der Matrix sind Kreuzungspunkte, definiert durch jeweils ein Element aus zwei
Informationsaspekten. Jedes Feld steht f¨
ur einen Ausschnitt aus den Prozessinformationen.
Bei diesen Prozess-Ausschnitten handelt es sich immer um eine ganze (oder auch mehrere)
Aktivit¨
aten. Da es aber zu un¨
ubersichtlich w¨
are, alle Informationen zu einer Aktivit¨
at
direkt in der Matrix anzuzeigen, w¨
ahlt der Benutzer einzelne Attribute aus, die dann in der
Darstellung erscheinen. Weitere Informationen k¨
onnen durch Tooltipps und durch seitlich
eingeblendete Detailinformationen (z. B. im Aufgabenbereich 7.4) dargestellt werden. In
F¨
allen, in denen die Information dazu ausreicht, ob ¨
uberhaupt ein Zusammenhang zwischen
zwei Informationsaspekten besteht, kann das Matrixfeld auch einfach nur ein H¨
akchen
zeigen. Diese Abstraktion sollte als Voreinstellung dienen, da sie zu den einfachsten und
¨
ubersichtlichsten Darstellungen f¨
uhrt.
105
6. Darstellungsformen f¨
ur Prozessdaten
Dimension 1
(vertikal)
Dimension 2
(horizontal)
besondere Information
Schema & Instanz Darstellung
Aktivit¨
at Ausf¨
uhrungseinheitaStatus der Aktivit¨
at (z. B. beendet,
gestartet, abgebrochen)
Aktivit¨
at Dokument lesen/schreiben, Reihenfolge der Zugriffe,
Zeit des letzen Zugriffs
Aktivit¨
at System -
Ausf¨
uhrungseinheit Dokument lesen/schreiben, Reihenfolge der Zugriffe,
Zeit des letzten Zugriffs, zugeordnete
Aktivit¨
at
Ausf¨
uhrungseinheit System zugeordnete Aktivit¨
at
Dokument System zugeordnete Aktivit¨
at
Multi-Instanz-Darstellung
ProzessbAusf¨
uhrungseinheit -
Prozess Dokument -
Prozess System -
Prozess Aktivit¨
at -
aAusf¨
uhrungseinheit steht hier f¨
ur Bearbeiter, Rolle oder Organisationseinheit
bDie Begriffe Prozess und Instanz werden hier in diesem Kontext synonym verwendet
Tabelle 6.2.: Varianten der Matrixdarstellung
Wenn es f¨
ur einen Kreuzungspunkt mindestens eine Aktivit¨
at in den Prozessinformationen
gibt, diese also die beiden durch die Elemente definierten Bedingungen erf¨
ullt, ist das Ma-
trixfeld nicht leer. Das impliziert auch, das es F¨
alle gibt, bei denen ein Kreuzungspunkt f¨
ur
mehrere Aktivit¨
aten steht. Dies muss dann, dem Benutzer entsprechend signalisiert wer-
den. Entweder werden dann direkt die Attribute aus mehreren Aktivit¨
aten angezeigt oder
eine Zahl gibt an, wie viele Aktivit¨
aten sich hinter dem jeweiligen Eintrag verstecken.
Beispiel
Ein einfaches Beispiel, wie eine solche Matrixdarstellung aussehen k¨
onnte, liefert Abbil-
dung 6.19. Die Darstellung zeigt in einer Dimension alle an einem Prozess beteiligten
Ausf¨
uhrungseinheiten an und in der anderen Dimension die beteiligten Systeme.
In den Schnittpunkten der beiden Informationsdimensionen l¨
asst sich im einfachsten Fall,
wie in der Abbildung gezeigt, darstellen, ob ¨
uberhaupt ein Zusammenhang zwischen diesen
beiden Objekten besteht. Oft bietet es sich auch an, an dieser Stelle weitere Information
¨
uber einen bestehenden Zusammenhang einzublenden.
Abbildung 6.20 zeigt ein weiteres Beispiel einer Matrixdarstellung. Es spiegelt das ge-
naue Gegenteil des einfachen Beispiels wieder. Es werden die Ausf¨
uhrungseinheiten und
Dokumente eines Prozesses gegen¨
ubergestellt. Jeder Eintrag zeigt an, ob das betreffende
Dokument durch den jeweiligen Bearbeiter gelesen (gr¨
une Markierung) und/oder geschrie-
ben wird (rote Markierung).
Die Zahl hinter jedem Eintrag weist darauf hin, in welcher wahrscheinlichen Reihenfolge
die Aktivit¨
aten mit Lese- und Schreibzugriffen im Prozesskontext angeordnet sind. Diese
Zusatzinformation ist dann von Interesse, wenn ein Benutzer nicht nur wissen will, welche
106
6.7. Matrixdarstellung
System
Division Role CAD system planning system production planning
Management CR Manager
Construction car body engineer 3
electronic engineer 3
motor engineer 3
construction expert
construction engineer 3
production engineer 3
quality expert
Development development chief 3
planning expert 3
Accounting purchase expert 3
others contact person
CR initiator
CR approval board
Abbildung 6.19.: Matrixdarstellung - Ausf¨
uhrungseinheiten und Systeme
Aktivit¨
at oder welcher Bearbeiter auf ein Dokument zugreift, sondern wenn f¨
ur ihn die
logische Abfolge, in der Aktivit¨
aten auf das jeweilige Dokument zugreifen ebenfalls relevant
ist. Dies ist notwendig, da die Matrixdarstellung ohne diesen Zusatz keine R¨
uckschl¨
usse
auf die Prozessstruktur erlaubt. Jede Zahl ist dabei eindeutig einer Aktivit¨
at zugeordnet,
vorausgesetzt, die Reihenfolge ist eindeutig bestimmbar. Bei parallelen Aktivit¨
aten ist dies
nur m¨
oglich, wenn die Start- und Endzeiten bekannt sind. Diese Zeiten m¨
ussen allerdings
¨
uberlappungsfrei oder die Aktivit¨
aten durch Synchronisierungskanten geordnet sein.
Die Matrixdarstellung zeigt immer nur einen kleinen Anteil der insgesamt verf¨
ugbaren
Prozessinformationen an. Prinzipbedingt lassen sich nur wenige Zusatzinformationen in
den Matrixfeldern unterbringen, ohne dass die ¨
Ubersichtlichkeit verloren geht. Eine Pro-
zessgraphdarstellungen bleibt dagegen auch bei vielen angezeigten Aktivit¨
atendetails noch
’einigermaßen’ lesbar. Abbildung 6.21 zeigt auch hier eine M¨
oglichkeit, durch eingeblen-
dete Tooltipps, mehr mit einem Matrixfeld in Zusammenhang stehende Information zur
Anzeige zu bringen.
Tooltipps lassen sich in jeder Darstellungsform einsetzen. Im Kontext der Matrixdarstel-
lung m¨
ussen allerdings f¨
ur jede Darstellungsvariante andere Details in den Tooltipps dar-
gestellt werden, denn jede Kombination von Prozessaspekten in den beiden Matrixdimen-
sionen zeigt jeweils einen anderen Anteil der verf¨
ugbaren Prozessinformationen an, und
damit sind es auch jeweils andere Zusatzinformationen die per Tooltipp sinnvoll eingeblen-
det werden k¨
onnen.
Wenn in den Matrixfeldern den Aktivit¨
aten zugeordnete Dokumente angezeigt werden,
erscheinen diese gleich als anklickbarer, verkn¨
upfter Link zum jeweiligen Dokument.
Falls dargestellte Informationen in Listenform nicht mehr in ein Matrixfeld passen, wie
im Fall einer Vielzahl von mit der Aktivit¨
at verkn¨
upften Dokumenten, k¨
onnen sie in einer
aufklappbaren Liste dargestellt werden.
107
6. Darstellungsformen f¨
ur Prozessdaten
Document expertise evaluation
Division Role change request electronic car body motor quality planning purchase
Management CR Manager 10
Construction car body engineer 23
electronic engineer 23
motor engineer 23
construction expert 8
construction engineer
production engineer
quality expert 687
Development development chief 45444
planning expert 687
Accounting purchase expert 6 7
others contact person
CR initiator 1
CR approval board 9
Abbildung 6.20.: Matrixdarstellung - Ausf¨
uhrungseinheiten und Dokumente
Document expertise evaluation
Division Role change request (3) quality planning purchase
Management CR Manager 10
Construction car body engineer 23
electronic engineer 23
motor engineer 23
construction expert 8
construction engineer
production engineer
quality expert 68 7
Development (2) 4 4,6 5 8 7
Accounting purchase expert 67
others contact person
CR initiator 1
CR approval board 9
[4] generate expertise
expertise:[electronic | car body | motor]
last access: 8 min
Role development chief
System CAD system
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[6] provide evaluation
expertise
last access: 3.12.05 15:08
Role planning expert
System planning system
Abbildung 6.21.: Matrixdarstellung - Ausf¨
uhrungseinheiten und Dokumente mit Tooltipp
M¨
achtigkeit des Konzeptes
Das Matrixkonzept eignet sich nicht f¨
ur die Darstellung des Kontrollflusses. Verzweigun-
gen, Schleifen und Ausnahmen lassen sich daher schlecht abbilden. Verzweigungsbedin-
gungen des Kontrollflusses ließen sich zwar als Eintrag in den Matrixfeldern prinzipiell
anzeigen. Tooltipps eignen sich hierf¨
ur aber besser. Diese k¨
onnen auch weitere Informa-
tionen anzeigen etwa zu Ausnahmen oder zu einem Schleifenz¨
ahler.
Der Datenfluss l¨
asst sich nur bedingt verfolgen. Zwar lassen sich sehr viele Informationen
zu Dokumenten darstellen etwa wo und durch wen diese verwendet werden. Die Reihenfolge
der Zugriffe l¨
asst sich dagegen nicht exakt bestimmen. Dies ist wiederum eine Konsequenz
daraus, dass der Kontrollfluss in einer Matrix nicht abgebildet werden kann.
Dieses Konzept profitiert sehr vom Vorhandensein von umfangreichen Organisationsmo-
dellen, denn damit k¨
onnen die f¨
ur die Matrixdimensionen gew¨
ahlten Prozessaspekte, wie
Aktivit¨
at, Ausf¨
uhrungseinheit, Dokument und System in einer hierarchischen Ordnung
dargestellt werden und zu Oberkategorien zusammengefasst werden. Dies macht die An-
zeige von großen Prozessen deutlich ¨
ubersichtlicher.
Die Matrixdarstellung eignet sich sowohl f¨
ur die Darstellung von Schemata, als auch f¨
ur
Instanzen. Die Zielsetzung, Zusammenh¨
ange aufzuzeigen, wird auch schon bei der Dar-
stellung eines Schemas gut erreicht. Wesentliche Vorteile hat eine Instanzdarstellung nicht
108
6.7. Matrixdarstellung
mehr, es sei denn der Benutzer interessiert sich f¨
ur Laufzeitdetails, wie z. B. die konkreten
Bearbeiter der Aktivit¨
aten eines Prozesses.
In den Schema- und Instanz-Darstellungen lassen sich aktivit¨
atszentrierten Prozessinfor-
mationen besonders gut darstellen; instanzbezogenen Prozessinformationen wie zugeord-
netes Produkt, Prozessverantwortlicher oder aggregierte Gesamtkosten machen hier wenig
Sinn. Die Multi-Instanz-Darstellungen gleichen das aus, hier lassen sich aktivit¨
atszentrierte
Daten nicht direkt darstellen, sondern lediglich in aggregierter Form ¨
uber alle Aktivit¨
aten
eines Prozesses. Eine Ausnahme bildet die Multi-Instanz Variante ’Prozess & Aktivit¨
at’
(→S. 116), die von den Darstellungsm¨
oglichkeiten her eher zu den Schema- und Instanz-
Darstellungen zu rechnen ist.
Auch Multi-Instanz-Darstellungen sind m¨
oglich. Mehrere Varianten sind hier m¨
oglich, bei-
spielsweise kann eine Prozessliste als neue Matrixdimension eingeblendet werden. Optional
kann eine Prozessliste in eine hierarchische Ordnung gebracht werden, indem eine Gruppie-
rungsebene nach Produkt (beziehungsweise Objekt) eingezogen wird. Damit ist es m¨
oglich
nur, die Instanzen zu beobachten, die einem bestimmten Produkt zugeordnet sind.
Hierarchische Prozesse lassen sich prinzipiell darstellen. Dies wirft aber erhebliche Pro-
bleme auf, die aber l¨
osbar sind. Die Darstellung hierarchischer Prozesse ist eine Konfi-
gurationsm¨
oglichkeit (siehe unten). Es d¨
urfte nicht immer gew¨
unscht sein, dass nicht nur
der aktuelle Prozess ausgewertet wird, sondern auch all seine Unterprozesse oder Verwei-
se (Spr¨
unge) an andere Stellen eines hierarchischen Workflows. Details dieser Probleme
werden im folgenden Abschnitt diskutiert.
Vor- und Nachteile
Die Vorteile der Matrix-Darstellung liegen darin, dass allgemeine Zusammenh¨
ange zwi-
schen den Prozess-Aspekten Aktivit¨
at, Ausf¨
uhrungseinheit, Dokument und System gut
darstellbar sind. Der Fokus liegt auf der Gegen¨
uberstellung von Aspekten, im Gegensatz
zu den anderen Darstellungen, wo die Aspekte zwar angezeigt werden, aber Beziehungen
unter ihnen nicht leicht ersichtlich sind.
Ein wichtiger Vorteil der Matrixdarstellung ist, dass sich Informationen gut zusammenfas-
sen lassen, wenn ein Organisationsmodell die n¨
otigen Hinweise ¨
uber die Zusammenh¨
ange
liefert. So zeigt beispielsweise Abbildung 6.20, dass in einer Aktivit¨
at auf den kompletten
Datensatz (z. B. ’expertise’) zugegriffen wird, in anderen dagegen nur auf einzelne Be-
reiche (z. B. ’expertise->electronic’). Abbildung 6.21 zeigt nur noch den ¨
ubergeordneten
Datensatz (hier ’expertise’). Des weiteren lassen sich mit den Daten aus dem Organisati-
onsmodell beispielsweise alle Bearbeiter oder Rollen, die einer Abteilung zugeordnet sind,
eben dieser zuordnen (hier ’development’).
Dieses Zusammenfassen f¨
ordert das Problem zutage, wie nun die Informationen aus meh-
reren Matrixfeldern zu einem Matrixfeld aggregiert werden k¨
onnen. Je nach Art der dar-
gestellten Daten, k¨
onnen dies z. B. Durchschnittswerte oder Listen sein, wie in Abbil-
dung 6.21 (→S. 108) dargestellt. Die Daten k¨
onnen auch auf andere Weise aggregiert
werden. Mit der Aggregation besch¨
aftigt sich Abschnitt 7.1.1.
Weitere Nachteile dieser Darstellung liegen darin, dass sich die logische und zeitliche Akti-
vit¨
atenabfolge nicht gut visualisieren l¨
asst. Nur wenn eine Matrixdimension die Aktivit¨
a-
ten in topologischer Sortierung auflistet, sind R¨
uckschl¨
usse auf die Ausf¨
uhrungsreihenfolge
109
6. Darstellungsformen f¨
ur Prozessdaten
m¨
oglich, ansonsten gibt es nur noch die M¨
oglichkeit einer expliziten Nummerierung (wie
in Abbildung 6.20 vorgenommen). Nur eine optische Markierung kann den Benutzer in
die Lage versetzen, auf den ersten Blick Aktivit¨
aten in der Matrix zu erkennen, welche
zu einer Schleife geh¨
oren. Auch Aktivit¨
aten die zu externen Prozessen geh¨
oren und bei
der Darstellung von hierarchischen Prozessen durch Sprungkanten erreicht wurden, k¨
on-
nen durch ein Symbol gekennzeichnet werden. Vor allem aber ist wichtig, das Aktivit¨
aten
markiert werden, an deren Ausf¨
uhrung Bedingungen gekn¨
upft sind, also Aktivit¨
aten nach
bedingten Verzweigungen oder Ausnahmebehandlungen (siehe dazu 6.7.3).
Des Weiteren lassen sich mit der Matrixdarstellung immer nur zwei Aspekte gegen¨
uber-
stellen. Zudem lassen sich aus Gr¨
unden der besseren ¨
Ubersichtlichkeit, nur recht wenige
Details in den Matrixfeldern unterbringen.
Wenn es hierarchische Prozesse gibt und der Benutzer bei der Auswertung eines Prozesses
also auch dessen Unterprozesse in der Matrixdarstellung mit ber¨
ucksichtigt haben m¨
ochte,
wirft dies viele Fragen auf, die im Folgenden diskutiert werden:
Problem 1: ¨
Anderungen an den Eintr¨
agen der Matrixdimensionen
Prinzipiell gibt es zwei F¨
alle die Matrixdimensionen betreffend, die im Zusammenhang mit
hierarchischen Prozessen betrachtet werden m¨
ussen:
Fall 1: Aktivit¨
aten als Matrixdimension gew¨
ahlt
Wo eine Aktivit¨
at einen Unterprozess kapselt, kann dieser aufgeklappt werden. Die
Auswertung erscheint f¨
ur den Anwender konsistent, wenn Unterprozesse erst mit dem
Ausklappen ber¨
ucksichtigt werden. Gegebenenfalls sollte auch eine Maximaltiefe f¨
ur
die Auswertung vom Benutzer angegeben werden k¨
onnen. Wo jedoch Unterprozesse
in der ersten Matrixdimension aufgeklappt werden, kann es notwendig werden auch
die zweite Matrixdimension anzupassen, wenn dadurch neue Bearbeiter, Systeme
oder Dokumente der zweiten Dimension an die bestehenden Eintr¨
age der Spalten
hinten angef¨
ugt werden m¨
ussen – ’Hinten anf¨
ugen’, weil sich dadurch die ¨
Anderung
des Aufbaus der Tabelle f¨
ur den Benutzer am wenigsten st¨
orend bemerkbar macht.
Der ¨
Ubersichtlichkeit halber werden immer nur die Bearbeiter, Systeme und Doku-
mente dargestellt, die auch von den eingeblendeten Aktivit¨
aten verwendet werden.
Fall 2: Aktivit¨
aten sind nicht als Matrixdimension gew¨
ahlt
Auch hier k¨
onnen sich die Eintr¨
age in den Matrixdimensionen ¨
andern, wenn die
Unterprozesse des zu untersuchenden Prozesses mit ausgewertet werden. Da hier
jedoch nicht, wie in Fall 1, der Benutzer direkt steuern kann bis zu welcher Tiefe
Unterprozesse mit ausgewertet werden sollen, ist hier eine explizite Angabe (Konfi-
gurationsm¨
oglichkeit) n¨
otig.
Problem 2: Eintr¨
age in den Matrixfeldern
Was aber zeigen nun die Matrixfelder an, wenn die Prozesse hierarchisch ausgewertet wer-
den? Zuerst einmal ist es sinnvoll, die Matrixfelder farblich zu kodieren, je nachdem, zu
welchem Prozess die dahinterliegende Aktivit¨
at geh¨
ort. In einer Legende im Aufgabenbe-
reich k¨
onnten die verwendeten Farben einzeln aufgeschl¨
usselt werden (siehe 7.4). Weiterhin
gibt es hier auch wieder verschiedene F¨
alle zu betrachten, je nachdem welche Inhalte ein
Matrixfeld zeigt.
110
6.7. Matrixdarstellung
Fall 1: Anzeige von aggregierbaren Attributen (z. B. Kosten oder Bearbeitungszeit)
Wenn eine Aktivit¨
at des dargestellten Prozesses einen Kindprozess kapselt und von
diesem auch Aktivit¨
aten in der Darstellung erscheinen, dann zeigt das der kapselnden
Aktivit¨
at zugeordnete Matrixfeld die aggregierten Gesamtkosten des Kindprozesses
an und einige weitere Felder zeigen einzelne Kosten von Aktivit¨
aten dieses Kind-
prozesses an. Aus der Darstellung muss ersichtlich sein, dass Einzelelemente und
aggregiertes Element logisch zusammengeh¨
oren. Auch dies kann durch geschickte
Farbgebung erfolgen. Beispielsweise kann das aggregierte Element eine ges¨
attigte
Hintergrundfarbe erhalten, die anderen Elemente eine helle Hintergrundfarbe des
selben Farbtons (siehe Abschnitt 5.1); oder sie erhalten alle dieselben Farben und
der Text des aggregierten Elementes wird fett ausgezeichnet.
Fall 2: Anzeige aller anderen Attribute oder auch Anzeige eines H¨
akchens zur Zuordnung
oder Anzeige von Prozess- oder Aktivit¨
atenlisten.
In diesem Fall ergeben sich keine Besonderheiten.
Problem 3: Bedingungen im Kontrollfluss
Aber auch damit sind noch nicht alle Besonderheiten aufgez¨
ahlt. Denn bei der Darstellung
von aggregierten Werten gibt es zwei besondere F¨
alle zu beachten. Ist der Kontrollfluss,
wegen bedingten Ausf¨
uhrungspfaden, die zum Darstellungszeitpunkt noch nicht aufgel¨
ost
sind, noch nicht vorherbestimmt, dann gilt:
Fall 1: Bedingte Verweise zu anderen Prozessen.
Wo Verweise (Spr¨
unge) zu anderen Prozessen vorkommen, kann es sein, dass diese
durch eine davor liegende Oder-Verzweigung nur bedingt ausgef¨
uhrt werden. Wenn
Verweise zu anderen Prozessen nicht ber¨
ucksichtigt werden sollen, ergibt sich kein
Problem. Im Falle einer Ber¨
ucksichtigung, k¨
onnen sich neue Eintr¨
age in den Matrix-
dimensionen ergeben (z. B. durch weitere Bearbeiter). Es kommt durch die Ber¨
uck-
sichtigung des Verweises aber in jedem Fall zu neuen Matrixeintr¨
agen. Diese m¨
ussen
den Benutzer optisch darauf hinweisen, das es sich bei den dahinter liegenden Akti-
vit¨
aten um nur bedingt Ausgef¨
uhrte handelt. Wo ein Matrixfeld einen aggregierten
Wert anzeigt, kann dann wegen der unbestimmten Ausf¨
uhrung die Ausgabe als ’von-
bis’ Wert erfolgen oder der bedingte Wert in Klammern.
Fall 2: Bedingte Ausf¨
uhrungspfade im Kontrollfluss von Unterprozessen
Es liegt der Fall vor, dass ein Unterprozess mit eingeblendet wird. Das Matrixfeld,
dessen dahinter liegende Aktivit¨
at diesen Unterprozess kapselt, zeigt dann einen ag-
gregierten Wert f¨
ur den (gesamten) Unterprozess. Wenn dieser einen unbestimmten
(weil bedingten) Kontrollfluss enth¨
alt, erfolgt die Ausgabe in diesem Matrixfeld als
’von-bis’ Wert.
Konsequenzen, die sich aus bedingten Kontrollfl¨
ussen f¨
ur die Matrixdarstellung ergeben,
behandelt Abschnitt 6.7.3.
M¨
ogliche Variationen
Andere Varianten als die in Tabelle 6.2 aufgelisteten sind nicht sinnvoll, denn nur von
Aktivit¨
at, Ausf¨
uhrungseinheit, Dokument und System existiert eine abgeschlossene Men-
ge von Elementen, die alle mindestens einmal in den Prozessinformationen vorkommen.
111
6. Darstellungsformen f¨
ur Prozessdaten
Alle anderen Attribute, wie z. B. Kosten oder Prozessverantwortliche, bieten f¨
ur eine Ma-
trixdarstellung entweder nicht gen¨
ugend Diversifizierung oder sie lassen sich besser in einer
Tabellendarstellung darstellen. Dort lassen sich dann beispielsweise auch Zusammenh¨
ange
wie Kosten & Systeme untersuchen, indem die Tabelle prim¨
ar nach Systemen sortiert wird
und sekund¨
ar nach Kosten (siehe Abschnitt 6.4). Bei Multi-Instanz Matrixdarstellungen
werden dagegen auch Prozesslisten, Produkte (oder Objekte) und Kunden zu sinnvollen
Matrixdimensionen, da auch hier jeweils eine endliche abgeschlossene Menge von Elemen-
ten existiert.
In den Matrixfeldern lassen sich in jeder Variante beliebige Aktivit¨
atenattribute und Ob-
jekte anzeigen (aktivit¨
atsbezogene Informationen). Zus¨
atzlich gibt es bei einigen Varianten
besondere Informationen, die nur dort besonders passend sind. Diese listet die Tabelle auf.
Außer den aktivit¨
atsbezogenen Prozessinformationen, gibt es noch instanzbezogenen (wie
z. B. der Prozessverantwortliche). In einer Matrixdarstellung ist beides nicht kombinierbar.
Die meisten Multi-Instanz Varianten sind jedoch instanzbezogen, sie k¨
onnen explizit nur
diesen Teil der Prozessinformationen darstellen.
Zun¨
achst werden die Varianten f¨
ur die Schema- & Instanz-Darstellung betrachtet, an-
schließend die Varianten f¨
ur die Multi-Instanz-Darstellung. Der erstgenannte Informati-
onsaspekt stellt im Folgenden immer die erste Matrixdimension dar, d. h. die Zeilen sind
der ersten Dimension zugeordnet, die Spalten der zweiten.
Generell ließen sich die beiden beteiligten Aspekte jeweils beliebig als Dimension 1 und 2
einteilen, aber da ’Nicht alles was m¨
oglich ist, gut ist’, stehen die Aktivit¨
aten stets in der
vertikalen Dimension. Dadurch werden mehr Einheitlichkeit erreicht, sowie die ¨
Ubersicht-
lichkeit und Wiedererkennbarkeit gef¨
ordert. In der Tabellendarstellung sind Aktivit¨
aten
stets vertikal angeordnet. Wenn in einer Matrix die Aktivit¨
aten nicht dargestellt werden,
stehen stattdessen die Ausf¨
uhrungseinheiten in der vertikalen Dimension, was auch bei der
Kalenderdarstellung und bei der Swimlane-Darstellung h¨
aufig der Fall ist.
Schema- & Instanz-Darstellung
Variante 1: Aktivit¨
at & Ausf¨
uhrungseinheit
Den Aktivit¨
aten eines Prozesses werden die ihnen zugeordneten Ausf¨
uhrungseinheiten ge-
gen¨
ubergestellt. Im nicht zusammengefalteten Grundzustand, enth¨
alt jede Zeile genau ein
gef¨
ulltes Matrixfeld, da jeder Aktivit¨
at ein Bearbeiter zugeordnet ist. Jedem Bearbeiter
k¨
onnen aber mehrere Aktivit¨
aten zugeordnet sein.
Durch ein Organisationsmodell ist es m¨
oglich die Ausf¨
uhrungseinheiten zu abstrahieren
und je nach Wunsch einzelne Eintr¨
age in der Darstellung zusammenzufassen, also bei-
spielsweise zu Organisation, Abteilung, (Projekt-)Team oder (Arbeits-)Gruppe. Um die
Darstellung nicht zu ¨
uberfrachten, bietet das Interface außerhalb der Darstellung, also
beispielsweise im Aufgabenbereich (vgl. Abschnitt 7.4) eine Konfigurationsseite, auf der
einstellbar ist, welche dieser Unterteilungen angezeigt werden sollen. Dort kann der Benut-
zer auch w¨
ahlen, ob die hinterlegten Informationen zur Ausf¨
uhrungseinheit (wo m¨
oglich)
in konkrete Bearbeiter aufgel¨
ost werden sollen oder ob die Ausf¨
uhrungseinheiten, wie im
Prozess modelliert, angezeigt werden sollen, z. B. als Rollenangabe (siehe Sorten von Aus-
f¨
uhrungseinheiten 2.1). Dies kann zur Folge haben, dass Eintr¨
age in der Matrixdimension
112
6.7. Matrixdarstellung
’Ausf¨
uhrungseinheit’ mit konkreten Bearbeiterangaben und unkonkreten Bearbeiterinfor-
mationen, wie z. B. Rollenangaben gemischt erscheinen. Aber auch diese gemischten Ein-
tr¨
age lassen sich durch das Organisationsmodell meist problemlos zusammenfassen, wenn
es nur eine m¨
ogliche Zuordnung gibt. Nur wenn die Bearbeiterinformation sehr unkonkret
als Menge von Fertigkeiten oder Attributen erscheint, kann es F¨
alle geben, die nicht mehr
automatisch vom Programm einer bestimmten Organisationseinheit zugeordnet werden
k¨
onnen.
Aktivit¨
aten dagegen lassen sich zun¨
achst einmal nicht weiter aggregieren. Nur im Rahmen
von hierarchischen Prozessen lassen sich Aktivit¨
aten, die alle zu einem ¨
ubergeordneten
Prozess geh¨
oren, zusammenfassen. Um ein reibungsloses Zusammenspiel der verschiede-
nen Darstellungsformen zu erm¨
oglichen, w¨
are es f¨
ur den Benutzer aber sinnvoll, mehre-
re Aktivit¨
aten, die er in einer Prozessgraphdarstellung zusammengefasst hat, auch nach
dem Umschalten zur Matrixdarstellung genauso zusammengefasst wieder vorzufinden. Die
Darstellung zusammengefasster Aktivit¨
aten orientiert sich am Beispiel von zu Abteilungen
zusammengefassten Ausf¨
uhrungsinformationen (siehe Abbildung 6.21).
Wenn besonders viele Informationen zu einzelnen Aktivit¨
aten oder Bearbeitern gew¨
unscht
sind, macht es Sinn, zur Tabellendarstellung (siehe Abschnitt 6.4) zu wechseln und diese,
je nach Bedarf, nach Aktivit¨
aten oder nach Bearbeitern zu sortieren. Denn, wie schon
im Abschnitt ’Vorteile und Nachteile’ beschrieben, bietet die Matrixdarstellung nur wenig
Platz zur Anzeige von Details.
Variante 2: Aktivit¨
at & Dokument
In dieser Kombination sind die Zusammenh¨
ange ersichtlich, welche Dokumente oder Da-
ten an einer Aktivit¨
at beteiligt sind. Auch wird sofort deutlich an wie vielen Aktivit¨
aten
ein Dokument beteiligt ist und, bei entsprechender Konfiguration, ob Daten gelesen oder
geschrieben werden. Je nach Prozessmodell k¨
onnen aber auch noch andere Arten des Do-
kumentenzugriffs unterschieden werden, wie Erzeugen, Anf¨
ugen oder L¨
oschen. Wenn wie
in Abbildung 6.20 eine Farbkodierung daf¨
ur verwendet wird, schl¨
usselt eine Legende (sie-
he Legende im Aufgabenbereich 7.4) die Farbzuordnungen auf. Zus¨
atzlich geben Tooltipps
¨
uber den Eintr¨
agen Auskunft ¨
uber den jeweiligen Zugriffstyp.
Außer dem Dokumentenzugriff ist f¨
ur die Eintr¨
age der Matrixfelder h¨
aufig auch die Bear-
beiterinformation interessant, da Dokumente und Bearbeiter sehr nah verwandte Prozes-
saspekte darstellen.
Da ein Dokument w¨
ahrend seiner Erstellung meist an mehreren Aktivit¨
aten beteiligt ist,
wird es hier h¨
aufig eine im Vergleich zu den anderen Varianten relativ dicht besetzte Matrix
ergeben.
Außer Aktivit¨
aten (bei hierarchischen Prozessen) k¨
onnen auch Dokumente hierarchisch
strukturiert sein, wenn dazu ein entsprechendes Organisationsmodell durch ein Dokumenten-
Management-System oder eine Datenbank gegeben ist. Damit lassen sich dann auch die
Dokumente zu Gruppen zusammenfassen, wie in Abbildung 6.20 zu sehen ist.
Variante 3: Aktivit¨
at & System
Diese Variante zeigt welche Systeme oder Applikationen von den einzelnen Aktivit¨
aten
verwendet werden. Jede Zeile enth¨
alt h¨
ochstens ein gef¨
ulltes Matrixfeld, da jeder Aktivit¨
at
113
6. Darstellungsformen f¨
ur Prozessdaten
(normalerweise) maximal ein System (oder eine Applikation) zugeordnet ist. Jedem System
sind allerdings h¨
aufig mehrere Aktivit¨
aten zugeordnet.
Mit entsprechenden Informationen aus einem (IT-)Organisationsmodell, lassen sich auch
hier die Systeme hierarchisch darstellen. Damit lassen sich Subsysteme zu einem Eintrag
zusammenfassen und k¨
onnen somit helfen, eine große Matrix ¨
ubersichtlicher zu machen.
Variante 4: Ausf¨
uhrungseinheit & Dokument
Diese Variante l¨
asst es zu, sich etwas von den Aktivit¨
aten zu l¨
osen. Hier werden die Do-
kumente und ihre Bearbeiter gegen¨
ubergestellt. Aber auch hier zeigen die Matrixfelder
wieder Aktivit¨
atenattribute an, denn in den Matrixfeldern werden wieder einzelne oder
mehrere Aktivit¨
aten selektiert. Dies gilt auch f¨
ur die beiden folgenden Varianten.
Diese Variante d¨
urfte h¨
aufig eine kompakte Matrix ergeben, da die Zahl der am Prozess
beteiligten Bearbeiter kleiner oder gleich der Anzahl der Aktivit¨
aten ist. Auch die Zahl der
Dokumente d¨
urfte selten gr¨
oßer als die Zahl der Aktivit¨
aten sein. Daf¨
ur wird ein Doku-
ment w¨
ahrend seiner Erstellung meist von mehreren Bearbeitern ver¨
andert, erg¨
anzt oder
begutachtet, was dazu f¨
uhrt, dass die Matrix, im Vergleich zu den anderen Kombinationen,
relativ dicht besetzt sein wird.
Es ist m¨
oglich, dass hinter einem Matrixfeld mehr als eine Aktivit¨
at steckt, wenn ein und
derselbe Bearbeiter mit demselben Dokument in mehreren Aktivit¨
aten arbeitet. Dass ein
Matrixfeld mehrere Aktivit¨
aten abdeckt, geschieht aber auch dann, wenn Dokumente und
Ausf¨
uhrungseinheiten, entsprechend den Organisationsmodell-Informationen, zusammen-
gefasst werden. Abbildung 6.21 zeigt genau dies. In der Zeile, in der mehrere Bearbeiter
zu einer Abteilung zusammengefaltet sind, informiert die Zahl in Klammern hinter dem
Abteilungsnamen ¨
uber die Anzahl der Bearbeiter, die hier zusammengefasst wurden.
Variante 5: Ausf¨
uhrungseinheit & System
¨
Ahnlich wie bei der Variante Ausf¨
uhrungseinheit & Dokument, werden hier die in den
Aktivit¨
aten verwendeten Systeme (oder Applikationen) und die jeweiligen Bearbeiter ge-
gen¨
ubergestellt. Es kann auch vorkommen, das einzelne Kombinationen von Ausf¨
uhrungs-
einheit und System in mehreren Aktivit¨
aten gleichermaßen auftreten. Und wie in den
Varianten zuvor, lassen sich auch hier einzelne Eintr¨
age in beiden Matrixdimensionen zu-
sammenfassen. Also m¨
ussen auch hier die Matrixfelder dem Benutzer signalisieren, wenn
mehr als eine Aktivit¨
at von einem Eintrag zusammengefasst wird.
Variante 6: System & Dokument
Variante 6 ist die letzte fehlende Kombination der Aspekte Aktivit¨
at, Ausf¨
uhrungseinheit,
Dokument und System. Diese Variante ist eigentlich nicht unbedingt notwendig, denn die
genannten vier Elemente k¨
onnen die gleichen Informationen zu Tage f¨
ordern. Der Vollst¨
an-
digkeit halber sei diese Variante hier aber aufgef¨
uhrt. Man kann aus ihr ersehen, an wie
vielen Stellen im Prozess ein und dasselbe Dokument in Verbindung mit unterschiedlichen
Systemen verarbeitet wird.
Diese Gegen¨
uberstellung d¨
urfte die kleinste Matrix ergeben, sie kann zudem recht d¨
unn
besetzt sein, denn hinter einem Eintrag k¨
onnen mehrere Aktivit¨
aten stecken, auf die die
Kombination von Dokument und System zutrifft.
114
6.7. Matrixdarstellung
Multi-Instanz-Darstellung
Auch die Matrixdarstellung eignet sich daf¨
ur, Informationen zu mehreren Instanzen eines
Schemas gleichzeitig anzuzeigen. Hierzu werden als neue Matrixdimension die Prozesse
herangezogen, die jeweils in der ersten Dimension, anstelle der Aktivit¨
aten (wie bei der
Schema- und Instanzdarstellung) dargestellt werden. Diese k¨
onnen nach Produkt/Objekt
oder Kunde gruppiert werden. Dies erm¨
oglicht z. B. , gezielt Prozesse in der Matrix zu
untersuchen, die alle dem gleichen Kunden zugeordnet sind. Das Interface bietet dem Be-
nutzer alternativ die Option, die Instanzen nach anderen Kriterien zu sortieren, was dann
allerdings die Gruppierung z. B. in Produktgruppen verhindert. Sinnvoll ist beispielsweise
die Sortierung nach Startzeit der Instanz, um so schnell zu erkennen, ob einzelne Instanzen
im Vergleich zu den anderen lange Bearbeitungszeiten aufweisen.
Variante 1: Prozess & Ausf¨
uhrungseinheit
Diese und die folgenden drei Varianten stellen das ¨
Aquivalent zur Multi-Instanz Tabellen-
¨
ubersicht dar (siehe Abschnitt 6.4), in der jede Zeile f¨
ur einen Prozess (oder eine Instanz)
steht.
Diese Variante dient dazu, einen ¨
Uberblick zu erhalten, welche Bearbeiter mit welchen
Prozessen besch¨
aftigt sind. Der Benutzer kann so Listen der Instanzen erhalten, mit de-
nen einzelne Bearbeiter zu tun haben. Dar¨
uber hinaus k¨
onnen auch in Multi-Instanz-
Darstellungen weitere Informationen in den Matrixfeldern dargestellt werden.
Die Matrixfelder selektieren in dieser und in den beiden folgenden Varianten jedoch nicht
mehr einzelne oder mehrere Aktivit¨
aten eines Prozesses, sondern immer alle Aktivit¨
aten
eines Prozesses gleichzeitig. Daher lassen sich die aktivit¨
atsbezogenen Informationen, wie
z. B. Fristen, nur in aggregierter Form darstellen. Allerdings k¨
onnen hier nun die instanz-
spezifischen Informationen, wie z. B. die Prozessverantwortlichen, angezeigt werden.
Variante 2: Prozess & Dokument
Diese eher spezielle Variante sei der Vollst¨
andigkeit halber aufgelistet. Sie macht nur Sinn,
wenn der Anwender nach Dokumenten forschen m¨
ochte, die in mehreren Prozessen ver-
wendet werden. Ansonsten verh¨
alt sich diese Variante analog zur Variante ’Prozess &
Ausf¨
uhrungseinheit’.
Variante 3: Prozess & System
Wo der Wunsch besteht, die Prozesse daraufhin zu untersuchen, inwieweit sie auf die
gleichen Systeme und Applikationen zugreifen, ist diese Variante interessant. Ansonsten
verh¨
alt sie sich analog zur Variante ’Prozess & Ausf¨
uhrungseinheit’.
Variante 4: Prozess & Produkt (Objekt)
Die Elemente in der ersten Matrixdimension k¨
onnen nur dann zu Produktgruppen zu-
sammengefasst werden, wenn die dort gelisteten Instanzen nach den ihnen zugeordneten
Produkten sortiert werden. Wenn der Benutzer eine andere Sortierung w¨
unscht, bekommt
er durch diese Variante die M¨
oglichkeit, die Prozessinformationen dennoch nach Produkt-
gruppen zu gliedern.
115
6. Darstellungsformen f¨
ur Prozessdaten
Variante 5: Prozess & Aktivit¨
at
Bei der Schema- und Instanzdarstellung werden die Aktivit¨
aten nie in der zweiten Matrix-
dimension angeordnet, diese Darstellung erg¨
anzt die drei vorangegangenen Varianten. Im
Gegensatz zu den anderen Multi-Instanz Varianten m¨
ussen die dargestellten Aktivit¨
atsat-
tribute hier nicht aggregiert werden, da in dieser Darstellung jede einzelne Aktivit¨
at jedes
Prozesses genau einem Matrixfeld zugeordnet wird. Auf diese Weise k¨
onnen die Instanzen
effektiv miteinander verglichen werden, solange jeweils nur ein einzelner Aspekt Gegen-
stand der Untersuchung ist. Ein typisches Beispiel w¨
are die Untersuchung der Kosten.
Konfigurationsm¨
oglichkeiten
Dieser Abschnitt kl¨
art, welche Konfigurationsm¨
oglichkeiten sich f¨
ur den Benutzer beim
Umgang mit der Matrixdarstellung ergeben. Hierbei werden nur Punkte genannt, die spe-
ziell f¨
ur die Matrixdarstellung gelten. Das (farbige) Markieren von Aktivit¨
aten gilt bei-
spielsweise generell in allen Darstellungsformen (siehe dazu Abschnitt 7.2).
Konfigurationsm¨
oglichkeiten sind:
➣Darstellungsvariante w¨
ahlen
➣Matrixfeld-Eintr¨
age konfigurieren
➣Tooltipp-Anzeige f¨
ur jede Variante extra konfigurieren
➣Auswahl von Organisationsmodell-Informationen
➣Hierarchische Prozesse ber¨
ucksichtigen
➣¨
Ubersetzung von Rollenangaben in Bearbeiter
Darstellungsvariante w¨
ahlen
Es gibt keine Standard-Darstellungsform f¨
ur Matrizen, der Benutzer w¨
ahlt zwischen ver-
schiedenen Schema- und Instanz-Darstellungen oder zwischen Multi-Instanz-Darstellun-
gen
Matrixfeld-Eintr¨
age konfigurieren
In jeder Variante steht ein Satz von anzeigbaren Attributen zur Verf¨
ugung aus denen der
Benutzer eine Teilmenge f¨
ur die Darstellung ausw¨
ahlen kann. Wird kein Attribut f¨
ur die
Anzeige gew¨
ahlt, zeigt die Darstellung nur ein H¨
ackchen, statt der ausgew¨
ahlten Attribute
(siehe Abbildung 6.19).
Tooltipp Anzeige f¨
ur jede Variante extra konfigurieren
Anders als bei den anderen Darstellungskonzepten, kann die Tooltipp-Anzeige hier nicht
global f¨
ur jede Variante gleichsam konfiguriert werden, sondern f¨
ur jede Variante separat.
Denn bei jeder Darstellungsvariante stehen f¨
ur den Benutzer andere Prozessaspekte im
Mittelpunkt des Interesses und die jeweils naheliegenden Zusatzinformationen, die ein
Tooltipp anzeigen k¨
onnte, ¨
andern sich damit auch.
116
6.7. Matrixdarstellung
Auswahl von Organisationsmodell-Informationen
Der Benutzer kann w¨
ahlen, in welchem Umfang die Daten aus dem Organisationsmodell
f¨
ur die Darstellung herangezogen werden. Bei einer Darstellung mit der Ausf¨
uhrungseinheit
als Matrixdimension kann beispielsweise eine Auswahl erfolgen, welche Firmenstrukturen,
also z. B. Team, Projekt, (Arbeits-)Gruppe, Abteilung, Unternehmen und Organisation
mit in die Strukturierungshierarchie der Matrixdimension aufgenommen werden. Diese
Auswahl muss auf Konsistenz ¨
uberpr¨
uft werden, da Arbeitsgruppen beispielsweise abtei-
lungs¨
ubergreifend zusammengesetzt sein k¨
onnen, was eine Baumstruktur bei gleichzeitiger
Anzeige der Abteilungen verhindert.
Hierarchische Prozesse ber¨
ucksichtigen
Standardeinstellung f¨
ur die Matrixdarstellung ist, dass nur die aktuelle Prozessinstanz
(oder Schema) ausgewertet wird und Spr¨
unge in andere Teilprozesse oder Unterprozesse
nicht verfolgt werden. Bei Bedarf ist es m¨
oglich, Unterprozesse bis zu einer vom Benut-
zer gew¨
ahlten Tiefe mit zu ber¨
ucksichtigen, was aber die Komplexit¨
at der Darstellung
erh¨
oht.
¨
Ubersetzung von Rollenangaben in Bearbeiter
Bei der Instanzdarstellung kann der Benutzer w¨
ahlen, ob das Programm – soweit m¨
oglich
– konkrete Bearbeiter anzeigt, anstatt der auf Schemaebene getroffenen Rollenangaben.
Analog dazu, ist auch die R¨
uckrichtung m¨
oglich, also die ¨
Ubersetzung von Bearbeiter- in
Rollenangaben.
6.7.1. Notwendige Voraussetzungen
Zusammenfaltbare Matrixdimensionen sind nur mit entsprechenden Zusatzinformationen
¨
uber das Organisationsmodell m¨
oglich (siehe Abschnitt 2.1.3).
6.7.2. Implementierungsaspekte
Eine Matrixdarstellung kann leicht mehr als eine Bildschirmseite ben¨
otigen. Daher wird
das Scrolling so implementiert, dass dem Benutzer beim Betrachten des Inhaltes st¨
andig
die Spalten- und Zeilenbeschriftungen angezeigt werden. Wenn Informationen aus dem Or-
ganisationsmodell dazu herangezogen werden, um die Eintr¨
age in den Matrixdimensionen
in eine hierarchische Ordnung zu bringen, die auseinander- und zusammengefaltet werden
kann, dann verbrauchen die Spalten- und Zeilenbeschriftungen selbst reichlich Platz. Daher
wird auch von diesen immer nur ein scrollbarer Ausschnitt gezeigt, um dem eigentlichen
Inhalt der Darstellung nicht zu viel Bildschirmplatz zu nehmen.
6.7.3. Bedingungen im Kontrollfluss
An einigen Stellen wurde bei der Vorstellung der Matrixdarstellung schon deutlich, dass
Bedingungen im Kontrollfluss Probleme mit sich bringen. Der Grund daf¨
ur ist, dass der
Kontrollfluss bei dieser Darstellungsform konzeptbedingt nicht dargestellt werden kann.
Dies hat Konsequenzen f¨
ur die Visualisierung.
117
6. Darstellungsformen f¨
ur Prozessdaten
Die Grundidee der Matrixdarstellung ist, dass Zusammenh¨
ange aus der Gesamtmenge al-
ler Aktivit¨
aten eines Prozesses dargestellt werden sollen. Die Matrixdarstellung orientiert
sich daf¨
ur nicht am Kontrollfluss. Wenn alle Matrixeintr¨
age optisch identisch dargestellt
w¨
urden, w¨
urde dies suggerieren, dass alle Aktivit¨
aten w¨
ahrend des Prozessverlaufs ausge-
f¨
uhrt werden. Die Eintr¨
age einer Matrix lassen jedoch keinerlei R¨
uckschl¨
usse dar¨
uber zu,
wie wahrscheinlich es ist, dass eine mit einem Matrixfeld assoziierte Aktivit¨
at ausgef¨
uhrt
wird. Daher ist es notwendig, dem Benutzer Matrixeintr¨
age, die nicht zwingend zutreffen,
zu signalisieren. Dies betrifft nicht nur Aktivit¨
aten hinter Oder-Verzeigungen, sondern
auch Aktivit¨
aten die aufgrund von Ausnahmebehandlungen ausgef¨
uhrt werden. Nur bei
bereits abgelaufenen Instanzen und Prozessen mit deterministischer Aktivit¨
atenabfolge
sind von dem Problem nicht betroffen. Jedoch sollten, wenn schon Laufzeitdaten (auch
f¨
ur Teilbereiche) vorliegen, Eintr¨
age von Aktivit¨
aten in abgew¨
ahlten Verzweigungspfaden
nicht entfernt werden, sondern beispielsweise grau dargestellt werden.
Matrixfelder mit bedingten Aktivit¨
aten werden daher farbig markiert. Ideal ist es, wenn
der dargestellte Prozess automatisch analysiert werden kann und die Farbhelligkeit die
jeweilige Ausf¨
uhrungswahrscheinlichkeit widerspiegelt. Aktivit¨
aten deren Ausf¨
uhrung an
zwei Bedingungen gekn¨
upft sind, k¨
onnen so etwa dunkler dargestellt werden. Dies l¨
asst
sich noch ausbauen, indem Historiendaten (engl. audit trails) vergangener Prozessabl¨
aufe
statistisch ausgewertet werden.
Erst durch die Hinweise auf Kontrollflussbedingungen, k¨
onnen Anwender die von einem
Prozess genutzten Ressourcen richtig auswerten. In einer Matrix, die beispielsweise Doku-
mente und Bearbeiter gegen¨
uberstellt, wird dadurch sichtbar, welche Dokument-bearbei-
tenden Aktivit¨
aten nur bedingt ausgef¨
uhrt werden.
6.8. Zusammenfassung
Das Kapitel stellt die Darstellungskonzepte Prozessgraph, Swimlane, Kalender, Tabelle, In-
teraktionsdiagramm, Datenflussdiagramm und Matrix vor und diskutiert deren spezifische
Vor- und Nachteile, Variationen der Darstellung und die Grenzen ihrer Einsetzbarkeit.
Nach der Vorstellung der Darstellungskonzepte ist es interessant zu untersuchen, inwieweit
sich diese als Werkzeuge zur Bearbeitung der Fragestellungen der Benutzer eignen. Daf¨
ur
werden sie ebenso wie schon die Benutzer in das in Kapitel 4vorgestellte Schema (siehe
Abbildung 3.5) eingeordnet. Das Ergebnis zeigt Tabelle 6.3.
Damit lassen sich nun den Fragestellungen aus dem Abschnitt 3.2 (’Ziele nach Benut-
zergruppen’) Werkzeuge zuordnen, die geeignet sind, um die Aufgaben zu erf¨
ullen. Dies
zeigen Tabelle 6.4 und Tabelle 6.5.
118
6.8. Zusammenfassung
Konzept Ziel Aufgabentyp Detailgrad
l
Entwerfena
Entscheiden
Informieren
¨
Ubersicht
Zusammenhang
Details
Prozessgraphdarstellung Kontrollfluss √ √ √ √
Swimlane-Darstellung Zusammenh¨
ange innerhalb
eines Prozessaspektes
√ √ √
Kalenderdarstellung Zeitliche Aspekte aus den
Prozessinformationen
√ √ √
Tabellendarstellung Zusammenh¨
ange innerhalb
eines Prozessaspektes
√√ √ √
Interaktionsdiagramm Interaktionen zwischen
verschiedenen
Organisationseinheiten
√√ √
Datenflussdiagramm Dokument-/Datenfluss √√ √
Matrixdarstellung Zusammenh¨
ange zwischen
zwei Prozessaspekten
√√ √ √
aSiehe Abbildung 3.5
Tabelle 6.3.: Darstellungsarten mit Darstellungszielen und Einordnung der Werkzeuge nach Be-
nutzerzielen
119
6. Darstellungsformen f¨
ur Prozessdaten
Aufgabe (Fragestellung) Werkzeug
Bearbeiter/Anwender
Liste aktueller Aufgaben Tabelle (Arbeitsliste)
Welche Aufgabe hat Priorit¨
at? Tabelle (Arbeitsliste)
Wie ordnet sich eine Aufgabe ins Umfeld ein? Prozessgraph, Swimlane
Wer hat außer mir mit dem Prozess zu tun? Matrix, Swimlane, Tabelle,
Interaktionsdiagramm
Welche Aufgaben stehen in naher Zukunft
an?
Tabelle (Arbeitsliste), Prozessgraph
Was ist schon alles erledigt? (Motivation) Tabelle (Arbeitsliste), Prozessgraph
Prozessverantwortlicher/Abteilungsleiter
View-Bildung Swimlane, Prozessgraph
Anpassung des Prozessschemas Prozessgraph, Swimlane
Zeit-Kontrolle (Plan/Ist Vergleich) Kalender
Pufferzeiten bestimmen Kalender
Was hat sich in der letzten Zeit getan? Kalender (Instanz & Multi-Instanz
Varianten), Prozessgraph
Welche Meilensteine wurden erreicht? Kalender (Instanz & Multi-Instanz
Varianten), Tabelle (Instanz & Multi-Instanz
¨
Ubersicht)
¨
Uberblick gewinnen Prozessgraph, Swimlane, Kalender
Wie ist der aktuelle Stand? Kalender (Instanz & Multi-Instanz
Varianten), Tabelle (Instanz & Multi-Instanz
¨
Ubersicht), Prozessgraph
Wie sieht der Daten-/Dokumentfluss aus? Datenflussdiagramm, Swimlane,
Prozessgraph
Wer kommuniziert mit wem? Interaktionsdiagramm, Swimlane
K¨
onnen alle Fristen eingehalten werden? Kalender
¨
Ubersicht ¨
uber Mitarbeiterauslastung Kalender
¨
Uberblick ¨
uber Kosten Tabelle, Matrix
Management
Status aller Instanzen nach Meilensteinen /
nach Fristen / in Prozent
Kalender (Multi-Instanz Varianten 2 & 3),
Tabelle (Multi-Instanz ¨
Ubersicht)
¨
Ubersicht ¨
uber Instanzen:
Gesamtbearbeitungsdauer (Durchsatz)
Tabelle (Multi-Instanz ¨
Ubersicht)
¨
Ubersicht ¨
uber Mitarbeiterauslastung Kalender (Ressourcen-orientierte
Multi-Instanz Variante)
¨
Uberblick ¨
uber Kosten Tabelle, Matrix
K¨
onnen alle Fristen eingehalten werden? Kalender (Multi-Instanz Varianten 2 & 3)
Zeit-Kontrolle (Plan/Ist Vergleich) Kalender
¨
Ubersicht ¨
uber Instanzen:
Bearbeiterzuordnung zu Aktivit¨
aten
Matrix, Kalender (Ressourcen-orientierte
Multi-Instanz Variante)
Tabelle 6.4.: M¨
ogliche Werkzeuge zum L¨
osen der Aufgaben der Benutzergruppen – Teil 1 (Bear-
beiter/Anwender, Prozessverantwortlicher/Abteilungsleiter, Management)
120
6.8. Zusammenfassung
Aufgabe (Fragestellung) Werkzeug
IT
Welche Daten fallen im Laufe eines Prozesses an? Datenflussdiagramm,
Matrix, Tabelle, Swimlane,
Prozessgraph
Welche Anwendungen sind an welchen Prozessen beteiligt? Matrix
Zu welchen Personen wandern die Daten? Datenflussdiagramm,
Matrix
Zu welchen Systemen wandern die Daten? Datenflussdiagramm (mit
eingeblendeten Systemen),
Matrix
Externer Mitarbeiter/Kunde
Status aller Instanzen nach Meilenstein Kalenderdarstellung
(Instanz & Multi-Instanz
Varianten)
¨
Uberblick ¨
uber wichtige Abschnitte des Prozesses (geeignete
View)
Prozessgraph, Swimlane
¨
Ubersicht ¨
uber die Kommunikation mit der Firma Interaktionsdiagramm,
Swimlane
¨
Ubersicht ¨
uber eigene Prozessbeteiligung Prozessgraph,
Interaktionsdiagramm
Prozessmodellierer
WF-Schema entwerfen Prozessgraph, Swimlane,
Kalender
View-Bildung Swimlane, Prozessgraph
Fristen und typische Ausf¨
uhrungsdauer festlegen Kalender
Schema¨
anderungen durchf¨
uhren Prozessgraph, Swimlane
Tabelle 6.5.: M¨
ogliche Werkzeuge zum L¨
osen der Aufgaben der Benutzergruppen – Teil 2 (IT,
Externer Mitarbeiter/Kunde, Prozessmodellierer)
121
7
Interaktionen auf Prozessinformationen
Dieses Kapitel erg¨
anzt die beiden vorangegangenen Kapitel, welche den verschiedenen
Konzepten der Prozessvisualisierung gewidmet sind, mit den Interaktionsm¨
oglichkeiten,
die sich aus der Bereitstellung dieser Konzepte f¨
ur die Benutzer einer Prozessvisualisie-
rungskomponente ergeben.
Die verschiedenen Darstellungsm¨
oglichkeiten sind Werkzeuge (siehe Abbildung 3.1
→S. 23), die von einer Software zur Nutzung angeboten werden. Erst wenn die Werkzeuge
sich an die Bed¨
urfnisse der Benutzer anpassen lassen und sie damit in die Lage versetzen
ihre Ziele zu erreichen, erzeugen sie einen Mehrwert. Benutzerinteraktionen betreffen aber
nicht nur die Anpassung von Werkzeugen, sondern auch die Integration dieser Werkzeuge
in eine Benutzeroberfl¨
ache. In diesem Kapitel werden verschiedene Aspekte der Benutzero-
berfl¨
ache beschrieben, die mit der Nutzung der Darstellungskonzepte im Zusammenhang
stehen. Dies sind z. B. Navigationsaspekte und die Prozesshistorie.
Benutzerinteraktionen, auf den Darstellungen, betreffen zum einen die Konfigurationsm¨
og-
lichkeiten der grafischen Darstellung, zum anderen Hilfestellungen, um gesuchte Informa-
tionen zu finden. Hinzu kommen M¨
oglichkeiten f¨
ur das Ein- und Ausblenden von Teilen
der Prozessinformationen (z. B. Ausblenden des Datenflusses). Diese Interaktion ist aber
letztlich eine Operation auf Views.
Views, Bildung von Views und Operationen auf Views werden im folgenden Abschnitt
diskutiert.
7.1. View-Bildung
Eine View (oder auch Sicht) ist eine Abbildung eines Prozesses auf eine Untermenge der
vorliegenden Informationen. Eine View kann dar¨
uber hinaus um Informationen aus einem
Organisationsmodell angereichert werden. Darstellungen, die auf Views basieren, lassen
sich den Bed¨
urfnissen der Nutzer anpassen.
123
7. Interaktionen auf Prozessinformationen
Views stellen einen m¨
achtigen Aspekt der Prozessvisualisierung dar. Wichtig hierbei ist,
dass sie unabh¨
angig sind, von den bisher besprochenen Aspekten der Visualisierung: Ka-
pitel 5behandelte den Aspekt der grafischen Repr¨
asentation, Kapitel 6die Darstellungs-
formen also die strukturelle Repr¨
asentation. Wichtigste Eigenschaft des View-Konzeptes
ist, dass Views auf alle Darstellungsformen gleich wirken. Die Konzepte View, Grafik und
Darstellung stehen also f¨
ur die Visualisierung orthogonal zueinander. Die einzige Ein-
schr¨
ankung besteht darin, dass nicht alle Darstellungsformen die gleichen Prozessaspekte
visualisieren k¨
onnen.
Sinnvollerweise arbeiten Visualisierungskomponenten f¨
ur ein PMS von vornherein nur auf
Views. Dadurch kann auch gesteuert werden, welche Prozessinformationen bestimmte Be-
nutzer betrachten k¨
onnen. Außer diesen Sicherheitsaspekten (siehe Abschnitt 8.1) haben
View-Konzepte noch ganz praktische Vorteile:
Views k¨
onnen, analog zu den Views auf Tabellen in Datenbanksystemen, kombinierte An-
sichten von mehreren Prozessen erzeugen. Beispielsweise k¨
onnen bei hierarchischen Pro-
zessen einzelne Aktivit¨
aten ganze Subprozesse kapseln. Kapselt ein Prozess mit seinen
Aktivit¨
aten viele Subprozesse, kann es sinnvoll sein, eine View zu erzeugen, die einen vir-
tuellen Prozess darstellt, in dem alle Subprozesse aus dem ¨
ubergeordneten Prozess expan-
diert dargestellt werden. Eine solche View w¨
urde dann nur die Aktivit¨
aten in der zweiten
Ebene aus Abbildung 6.16 enthalten.
Den Ablauf der Prozessvisualisierung mit einem solchen Konzept zeigt Abbildung 7.1.
Das Bild zeigt die beiden wesentlichen Operationen, die zur View-Bildung durchgef¨
uhrt
werden k¨
onnen, Aggregation und Reduktion. Weitergehende Untersuchungen zu Views
und m¨
ogliche Operationen zur Bildung von Views auf Prozessdaten werden in [Klot04]
diskutiert.
Daten aus Process-Warehouse
Prozessmodell Datenmodell Organisations-
modell
Konfiguration der
Viewerkomponente
Visualisierung Visualisierungs-
modell
Viewbildung
Aggregation Reduktion
Abbildung 7.1.: Ablauf Prozessvisualisierung mit Views
124
7.1. View-Bildung
Aggregation und Reduktion dienen in erster Linie dazu, die Komplexit¨
at einer Darstellung
zu vermindern, sie k¨
onnen aber auch dazu verwendet werden Informationen zu verber-
gen.
7.1.1. Aggregation
Mit Aggregation ist im Prozesskontext in erster Linie Graphaggregation gemeint, also das
Zusammenfassen von zusammenh¨
angenden Teilgraphen zu einer virtuellen Ersatzaktivit¨
at,
die die damit ersetzten Aktivit¨
aten zur F¨
orderung der ¨
Ubersichtlichkeit b¨
undelt.
Arten der Aggregation:
➣Zusammenfassen einer Abfolge von Aktivit¨
aten zu einer Aktivit¨
at
➣Zusammenfassen mehrerer Prozess-/Aktivit¨
ats-Attribute
➣Gruppierung von Ressourcen eines Typs unter eine Obermenge
Aggregation beschr¨
ankt sich also nicht auf das Zusammenfassen von Aktivit¨
aten. Im All-
gemeinen steht Aggregation f¨
ur das Verdichten von Informationen, der Begriff ist wie
beim Data-Warehousing zu verstehen. Dort gibt es Fakten und darauf angewendete Ag-
gregatfunktionen, um Fakten zusammenzufassen. Es ist jedoch zu beachten, dass nicht
alle Fakten aggregierbar sind. Es ist hierf¨
ur vor allem die Typvertr¨
aglichkeit von Fakt
und Aggregatfunktion wichtig. Die Fakten von Prozessinformationen sind in erster Linie
die Aktivit¨
aten mit ihren Eigenschaften (siehe Tabelle 2.1). Es lassen sich beispielsweise
nur Fakten, die alle vom Typ Kosten sind, zu einer Gesamtsumme aggregieren. In der
Darstellung muss dann deutlich erkennbar sein, wo solche aggregierten Daten angezeigt
werden.
Im Rahmen einer View kann einzelnen Fakten, wie z. B. den eben genannten Kosten, eine
Standardaggregatfunktion zugewiesen werden. Der Aufgabenbereich (siehe Abschnitt 7.4)
bietet dazu ein Fenster, in dem der Benutzer die Zuordnungen von Fakten und Aggregat-
funktion ¨
andern kann und auch sonstige Einstellungen zur gegenw¨
artig angezeigten View
vornehmen kann.
M¨
ogliche Aggregatfunktionen sind z. B. Summe, Anzahl, Maximum, Minimum oder Mit-
telwert, aber auch statistische Funktionen wie Standardabweichung oder Besonderheiten
wie eine Top-N Angabe. Nicht jede Funktion macht in jedem Zusammenhang Sinn, trotz-
dem kann die Wahl der Aggregation dem Benutzer ¨
uberlassen werden. Es k¨
onnten aber
auch in einer eingeschr¨
ankten View bereits aggregierte Daten vordefiniert sein.
Andere Fakten, z. B. Informationen zu Ausf¨
uhrungseinheiten, lassen sich ¨
uber Mengenbil-
dung zusammenfassen. Wenn z. B. zwei Aktivit¨
aten mit den Bearbeitern A und B zusam-
mengefasst werden, tr¨
agt die neue stellvertretende Aktivit¨
at die Information zur Ausf¨
uh-
rungseinheit ’Bearbeiter A, B’. Durch Informationen aus dem Organisationsmodell l¨
asst
sich daf¨
ur eventuell auch eine Darstellung finden wie ’Abteilung X (2)’ – zwei Bearbeiter
aus Abteilung X.
Bei Fakten mit endlichem Wertebereich, z. B. der Aktivit¨
atenzustand, lassen sich auch
Ordnungen finden. Sollen z. B. Aktivit¨
aten zusammengefasst werden, welche beispielsweise
die Zust¨
ande ’beendet’ und ’laufend’ haben, wird der Wert des aggregierten Fakts auf
’laufend’ gesetzt. Nur, wenn alle aggregierten Aktivit¨
aten den Zustand ’beendet’ haben,
kann dies der gemeinsame Zustand sein (vergleiche [Klot04, S.27]).
125
7. Interaktionen auf Prozessinformationen
Eine Besonderheit stellt das Zusammenfassen von Prozessinformationen unter Einbezie-
hung eines Organisationsmodells dar. Es k¨
onnen beispielsweise zusammengeh¨
orige Infor-
mationen logisch gruppiert werden. Beispielsweise k¨
onnen mehrere Bearbeiter zu einer
oder mehreren Abteilungen gruppiert/aggregiert werden, was der ¨
Ubersichtlichkeit der
Darstellung zugute kommt. Detailinformationen, die die urspr¨
unglichen (nicht zu Abtei-
lungen gruppierten) Bearbeiter auflisten, k¨
onnen an anderer Stelle der Oberfl¨
ache darge-
stellt werden (siehe dazu Abschnitt 7.4).
Auch die Informationen zum Ausf¨
uhrungszustand k¨
onnen vom Anwender zur Aggregation
herangezogen werden. Bei einer laufenden Prozessinstanz k¨
onnen schon beendete Aktivi-
t¨
aten oder noch weit in der Zukunft liegende nicht aktivierte Aktivit¨
aten zusammengefasst
werden, sodass eine ¨
Ubersicht ¨
uber den aktuell anstehenden Prozessbereich entsteht.
7.1.2. Reduktion
Bei der Graphreduktion werden Informationsaspekte entfernt, dies k¨
onnen einzelne Akti-
vit¨
aten oder ganze Teilgraphen sein oder auch Aktivit¨
atenattribute, die f¨
ur die Erledigung
der Aufgabe ohnehin keine Rolle spielen.
Die Auswahl auszuschneidender Aktivit¨
aten erfolgt meist anhand von:
➣Aktivit¨
atsattributen
➣Zeitausschnitten
➣Rollen (Ausf¨
uhrungseinheiten)
➣Dokumente/Daten
➣Systeme/Anwendungen
M¨
ogliche Anwendungen w¨
aren beispielsweise: Nur Aktivit¨
aten darzustellen, die einer be-
stimmten Rolle zugeordnet sind. Aktivit¨
aten entfernen, deren Bearbeiter zu einer bestimm-
ten Abteilung geh¨
oren. Teilgraphen verbergen, die notwendige Schritte im Falle eines Feh-
lers enthalten. Manche Attribute wie z. B. Kosten oder Dauer sind sensible Informationen,
die durch eine View ausgeblendet werden k¨
onnen.
Die Reduktion kann auch sehr gut als Filterfunktion beispielsweise in großen Tabel-
len(darstellungen) verwendet werden.
7.2. Aktivitäten markieren
Meist zeigt eine Darstellung viel zu viele Informationen auf einmal an und es werden
alle Elemente gleich stark betont. Aber in der Praxis sind dem Benutzer einige Elemente
wichtiger als andere [CR03]. Dem Benutzer muss daher ein Werkzeug an die Hand gegeben
werden, mit dem er festlegen kann, welche Elemente in der Darstellung besonders hervor-
gehoben oder markiert bzw. mit mehr Details dargestellt werden sollen. ¨
Ublicherweise
geschieht das Hervorheben meist durch Farbe und Form (siehe Abschnitt 5.3.1).
Diese Funktion dient dazu, bestimmte Aktivit¨
aten in den Darstellungen zu markieren.
Dies erfolgt mehr im Sinne von ’Hervorheben’ und nicht ’Selektieren’. Dies ist n¨
utzlich,
126
7.2. Aktivit¨
aten markieren
um in großen Prozessen schnell einen ¨
Uberblick zu gewinnen, indem die f¨
ur die aktuelle
Aufgabe relevanten Aktivit¨
aten hervorgehoben dargestellt werden.
Wie aber erfolgt nun die Auswahl der zu markierenden Informationen? F¨
ur das System
erfolgt eine solche Auswahl ganz allgemein ¨
uber Regeln – ¨
uber Ausdr¨
ucke, die unter be-
stimmten Bedingungen wahr werden. Hierf¨
ur werden die verf¨
ugbaren Einzelelemente der
Prozessinformationen mit Boolschen Funktionen zu Ausdr¨
ucken verkn¨
upft (siehe Tabel-
le 7.1).
Sinnvolle, h¨
aufig gebrauchte Auswahlkriterien f¨
ur das Markieren von Aktivit¨
aten stellt
das Interface dem Benutzer zum sofortigen Zugriff jederzeit bereit. Andere speziellere
Regels¨
atze kann der Benutzer in einem Regelbaukasten erstellen.
7.2.1. Wichtige einfache Markierungsregeln
Alle folgenden Regeln beziehen sich immer auf eine bereits gew¨
ahlte Ausgangsaktivit¨
at,
da diese Regeln Beziehungsaspekte zwischen Aktivit¨
aten beschreiben. H¨
aufig gebrauchte
naheliegende Markierungsfunktionen sind:
➣Vorg¨
angeraktivit¨
at(en)
➣Nachfolgeraktivit¨
at(en)
➣Aktivit¨
aten in alternativen Ausf¨
uhrungspfaden
Nicht in jedem Kontext der verschiedenen Darstellungsformen machen alle Punkte dieser
Liste Sinn. In der Prozessgraphdarstellung ist die Bestimmung der Vorg¨
angeraktivit¨
at
trivial, nicht jedoch in einer Tabellen- oder Matrixdarstellung.
Die Funktion ’Aktivit¨
aten in alternativen Ausf¨
uhrungspfaden’ markiert alle Aktivit¨
aten,
die sich in den anderen Zweigen einer Oder-Verzweigung befinden; d. h. es werden Aktivi-
t¨
aten markiert, die sich relativ zur gew¨
ahlten Aktivit¨
at in alternativen Ausf¨
uhrungspfaden
befinden.
7.2.2. Regelbaukastensystem
Die Regeln, die die Markierungsfunktion steuern, m¨
ussen dem Programm bekannt gemacht
werden. Eine benutzerfreundliche L¨
osung f¨
ur einen Regelbaukasten zeigt Abbildung 7.2.
Dort dienen die Regeln zur Erstellung einer Abspielliste. Weil der Benutzbarkeit hier mehr
Priorit¨
at einger¨
aumt wird als der Funktionsvielfalt, k¨
onnen hier allerdings keine Und &
Oder Regeln miteinander kombiniert werden.
Einfacher, aber weniger m¨
achtig, wird das Markieren ¨
uber ein Kontextmen¨
u, das je nach
Situation sinnvolle M¨
oglichkeiten anbietet. Befindet sich der Mauszeiger beispielsweise in
einer Graphdarstellung ¨
uber einer Aktivit¨
at, der die Rolle Kundenbetreuer zugeordnet ist,
erscheint im Kontextmen¨
u ’Markiere Aktivitäten von Kundenbetreuer’ zur Auswahl. Durch
die Auswahl dieser Option werden alle Aktivit¨
aten in der Darstellung, auf die die Regel
Rolle=Kundenbetreuer zutrifft, optisch hervorgehoben.
Eine Hervorhebung kann optisch auch signalisiert werden, indem alles andere, was nicht
markiert werden soll, mehr in den Hintergrund ger¨
uckt wird. Apple zeigt dies wiederum
eindrucksvoll in MacOS X (siehe Abbildung 7.3).
127
7. Interaktionen auf Prozessinformationen
Abbildung 7.2.: Selektionsdialog in Apples iTunes
Abbildung 7.3.: Spotlight im MacOS X System-Einstellungs-Dialog
Alle gerade aktiven Regeln sollte das Programm anzeigen k¨
onnen. Neue Regeln k¨
onnen
aufgenommen werden, Bestehende ver¨
andert oder gel¨
oscht werden. Jeder Regel ist eine
bestimmte Markierungsart zugeordnet. Nur, wenn diese Markierungsarten sich kombinie-
ren lassen (z. B. Linienst¨
arke und Farbe, vgl. 5.3.1), kann ein einzelnes Element auch
durch verschiedene Regeln mehrfach markiert werden, ansonsten kommt nur die Markie-
rung nach der ersten Regel zum Zuge. Abbildung 7.4 zeigt alle Aktivit¨
aten mit der Rolle
’Kundenbetreuer’ mit einem fetten Rahmen und zus¨
atzlich bei allen Aktivit¨
aten, die auf
128
7.2. Aktivit¨
aten markieren
das Dokument ’Kostenvoranschlag’ zugreifen, das entsprechende Element farbig markiert.
Durch die unterschiedlichen Markierungsarten lassen sich mehrere Regeln auf eine Akti-
vit¨
at anwenden.
Angebot erstellen
Vertriebsleiter
Kostenvoranschlag
Vertrags-
verhandlung
Kundenbetreuer
Vertrag
Kosten
analysieren
Kundenbetreuer
Kostenvoranschlag
Abbildung 7.4.: Beispiel f¨
ur Markierungsregeln
Tabelle 7.1 zeigt beispielhaft m¨
ogliche Markierungsregeln. In Abschnitt 5.3.1 werden m¨
og-
liche Markierungen f¨
ur Elemente aufgelistet.
Markierungsregel Beschreibung
Bearbeiter = Herr Maier Einfache Regel. Alle Aktivit¨
aten, die einer bestimmten
Person zugeordnet sind
Bearbeiter =
Prozessverantwortlicher
Regel mit Variable. Alle Aktivit¨
aten, die der
Prozessverantwortliche selbst durchf¨
uhrt
Rolle = Kundenbetreuer Alle Aktivit¨
aten, denen ein Kundenbetreuer zugeordnet ist
Abteilung = Vertrieb Alle Aktivit¨
aten, die dem Vertrieb zugeordnet sind
Dokument = Kostenvoranschlag Alle Aktivit¨
aten, die auf das Dokument Kostenvoranschlag
zugreifen
Dokument.lesend =
Kostenvoranschlag
Objektorientierte Regel. Alle Aktivit¨
aten, die auf das
Dokument Kostenvoranschlag lesend zugreifen
Kosten >= 500 Alle Aktivit¨
aten, deren Kosten 500 EUR ¨
ubersteigen
Endzeit >Datum - 3 Tage Alle Aktivit¨
aten, die in sp¨
atestens drei Tagen abgeschlossen
sein m¨
ussen
Frist <= 1 Tag Alle Aktivit¨
aten, f¨
ur deren Ausf¨
uhrung eine Frist von
maximal einem Tag vorgesehen ist
Abteilung = Abteilung(
Prozessverantwortlicher ) UND
N¨
achste Aktivit¨
at. Abteilung
!= Abteilung(
Prozessverantwortlicher )
Markierung unter Anwendung mehrerer Regeln. Alle
Aktivit¨
aten, die eine Folgeaktivit¨
at einer anderen
Abteilung haben
Kategorie = Konzeptionelle
T¨
atigkeit
Alle Aktivit¨
aten markieren, die semantisch als
Konzeptionelle T¨
atigkeit klassifiziert sind. Andere
T¨
atigkeitstypen k¨
onnten gleichzeitig auch markiert werden
(in anderer Farbe)
identisch(System) &&
¨
uberlappend(Zeit)
Alle Aktivit¨
aten markieren, die zum gleichen Zeitpunkt auf
das gleiche System zugreifen
Abteilungen farbkodieren Alle Aktivit¨
aten des Prozesses werden (jeweils
unterschiedlich) farblich markiert
Prozesse farbkodieren Bei hierarchischen Prozessen: Die Aktivit¨
aten werden
farbkodiert, je nachdem, zu welchem (Unter-)prozess sie
geh¨
oren
Tabelle 7.1.: Beispiele f¨
ur die Markierungsfunktion
129
7. Interaktionen auf Prozessinformationen
Auswahlmen¨
us f¨
ur h¨
aufig benutzte Regeln und f¨
ur die im aktuellen Kontext zur Wahl
stehenden Parameter k¨
onnen den Benutzer beim Erstellen der Regeln unterst¨
utzen. Je
einfacher die Verwendung dieser Funktion, desto eher wird sie verwendet. Einige Mar-
kierungen k¨
onnten auch als Standardmarkierung f¨
ur bestimmte Darstellungsformen z. B.
Prozessgraph eingestellt werden, so beispielsweise die farbliche Hinterlegung der Aktivit¨
a-
ten entsprechend des Aktivit¨
atentyps.
Weiter soll auf die regelbasierte Markierung von Aktivit¨
aten nicht eingegangen werden,
sie stellt nur einen Randaspekt im Rahmen der Prozessvisualisierung dar.
7.3. Detailansicht & Tooltipps
Es ist nicht sinnvoll alle verf¨
ugbaren Prozessdetails im Hauptfenster anzuzeigen. Um eine
Darstellung ¨
ubersichtlich zu halten, werden dort nur die notwendigsten Informationen
visualisiert:
➣Alle Informationen, die notwendig sind, damit sich der Benutzer in der Darstellung
zurechtfindet
➣Die eigentlich gesuchte Information
Alle weiteren Details, die f¨
ur den Benutzer weiterhin noch von Bedeutung sind, werden in
zus¨
atzlichen Informationsfenstern untergebracht. Hierf¨
ur selektiert der Benutzer eine Ak-
tivit¨
at (also einen Knoten, eine Zeile oder Zelle – je nach gew¨
ahlter Darstellung) woraufhin
Detailinformationen ¨
uber die Aktivit¨
at in diesem Fenster angezeigt werden. Wenn keine
Aktivit¨
at ausgew¨
ahlt ist, zeigt dieses Fenster allgemeine Informationen ¨
uber den Prozess,
also beispielsweise instanzbasierte Informationen, wie den Prozessverantwortlichen oder
Start- und Endzeiten der Prozessinstanz (siehe Tabelle 2.1).
Um dem Benutzer sehr schnell zus¨
atzliche Informationen zu einzelnen Elementen der Dar-
stellung zug¨
anglich zu machen, stellen Tooltipps eine geeignete M¨
oglichkeit dar. Sie k¨
onnen
außer Detailinformationen zu Aktivit¨
aten auch weitergehende Informationen zu Dokumen-
ten, Systemen, Organisationsmodell oder zu den Historiendaten anzeigen.
7.4. Aufgabenbereich
Mit dem Aufgabenbereich ist eine Werkzeugleiste gemeint, in der Eclipse Rich Client
Platform [Ecli06] werden solche Zusatzfenster ’View’ genannt.
Bildschirmplatz ist bei komplexer Software Mangelware. Eine Anwendung die Prozesse
visualisieren kann, braucht außer der eigentlichen Darstellung, ein ¨
Ubersichtsfenster, eine
Historienansicht, eine Detailansicht und M¨
oglichkeiten zum schnellen ¨
Andern von Konfi-
gurationsparametern. Viele der genannten Ansichten brauchen aber nicht gleichzeitig auf
dem Schirm dargestellt zu werden, sie k¨
onnen sich h¨
aufig auch eine umschaltbare Werkzeu-
gleiste teilen. Daher bietet sich eine Oberfl¨
ache an, die schnell an das jeweilige Bed¨
urfnis
des Benutzers angepasst werden kann.
Ein Beispiel f¨
ur eine gute L¨
osung, um eine aufger¨
aumte, Platz sparende Benutzerober-
fl¨
ache zu schaffen, findet sich z. B. bei Microsofts PowerPoint. Abbildung 7.5 zeigt, wie
130
7.4. Aufgabenbereich
dort eine seitliche Leiste eingeblendet werden kann, ¨
uber die viele verschiedene Folien-
Layouts schnell ¨
ubernommen werden k¨
onnen. Solche seitlichen Funktionsleisten werden
meist Aufgabenbereich genannt. Die Abbildung zeigt auch, dass dieser Aufgabenbereich
viele verschiedene Aufgaben erf¨
ullt, zwischen denen umgeschaltet werden kann. In einer di-
rekten Umsetzung k¨
onnte in den graphbasierten Darstellungsformen Graph und Swimlane
das Aussehen der Aktivit¨
atenknoten schnell ge¨
andert werden.
Abbildung 7.5.: Aufgabenbereich in Microsofts Powerpoint
Ein Aufgabenfenster kann also beispielsweise die (Darstellungs-)Konfiguration f¨
ur die mo-
mentan aktive Darstellungsform enthalten. Je nach gew¨
ahlter Darstellung gibt es unter-
schiedlichen Konfigurationsbedarf. In einer Graphdarstellung gibt es z. B. mehr Einstel-
lungsm¨
oglichkeiten als f¨
ur die Matrixdarstellung. Dort k¨
onnten die verschiedenen zu kon-
figurierenden Einstellungen auch auf mehrere Aufgabenfenster verteilt werden.
131
7. Interaktionen auf Prozessinformationen
Wo der Platz einer seitlichen Funktionsliste nicht ausreicht, kann auch auf andere L¨
osungen
wie einen modalen Einstellungsdialog zur¨
uckgegriffen werden. Es bietet sich beispielswei-
se an, die Einstellungen, welche Prozessinformationen direkt in der Darstellung angezeigt
werden, welche in einer Detailansicht und welche als Tooltipp-Information, in einem ge-
meinsamen Konfigurationsdialog, wie ihn Abbildung 7.6 zeigt, unterzubringen. Da diese
drei Einstellungen nicht unabh¨
angig voneinander sind.
Anzeige der Prozessdetails konfigurieren für <Graphdarstellung>
Per Drag & Drop auswählen
wo welche Informationen
angezeigt werden
Startzeit
Endzeit
Minimale Details Speichern...
Aktivitäten Informationen Aktivitätendetail
Informationen
Konfiguration laden / speichern
Anzeigen
Dokumente
System Zeiten
Bearbeiter Löschen…
Suchen
Verfügbare Aktivitätendetails
Tooltip Informationen
Aktivität
Schema
Liste lesend
Letzter Zugriff
Letzte Änderung
Liste schreibend
System
Letzter Bearbeiter
Zeiten
Instanz
Prozessverantwortlicher
Status
Abteilung
Dokumente/Daten
Bearbeiter
Aktivität
Name
Bearbeiter
Rolle
System
Name
Dokumente
Liste lesend
Aktivität
Name
Bearbeiter
Rolle
Abteilung
Liste schreibend
Dokumente
Letzter Zugriff
Letzte Änderung
Letzter Bearbeiter
Abbildung 7.6.: Konfiguration der Anzeige der Prozessdetails
Die Tabelle 7.2 zeigt eine ¨
Ubersicht, welche Aufgaben ein Aufgabenbereich erf¨
ullen k¨
onn-
te.
Navigation
Der Aufgabenbereich Navigation, wird nur in einer Umgebung mit Zugriff auf eine Ge-
sch¨
aftsprozesshierarchie ben¨
otigt, denn dann ben¨
otigt der Benutzer umfassendere Naviga-
tionsm¨
oglichkeiten. Hier besteht die M¨
oglichkeit in der direkten Umgebung des aktuellen
Prozesses zu navigieren, alle Prozesse, mit denen der Aktuelle in irgendeiner Verbindung
steht, sind direkt anw¨
ahlbar, also Elternprozess, Kindprozesse und andere Prozesse an
beliebigen Stellen in der Prozesshierarchie, zu denen ein Prozess Verkn¨
upfungen im Kon-
trollfluss aufweist. Abbildung 7.7 zeigt die Prozesshierachie ausgehend vom Prozess ’¨
Ande-
rungen durchf¨
uhren’, hier wird deutlich, dass hier in vertikaler Richtung im Prozessbaum
hoch- und runternavigiert werden kann und in horizontaler Richtung links und rechts zu
benachbarten Prozessen.
Details in Aktivit¨
aten / Tooltipp / Detailfenster
Die Einstellung welche Aktivit¨
atendetails direkt an der Aktivit¨
at in Tooltipps oder im De-
tailfenster angezeigt werden, kann hier im Aufgabenbereich erfolgen, oder z. B. gemeinsam
132
7.4. Aufgabenbereich
Aufgabe Beschreibung
Navigation Navigation in hierarchischen Workflows. Vertikale Links zu
Elternprozess und Kindprozessen, horizontale Links zu
Vorg¨
anger- und Nachfolgerprozess und Verkn¨
upfungen zu
anderen Prozessen
Detailinformation Zeigt detailliertere Informationen ¨
uber eine selektierte
Aktivit¨
ata
Darstellungskonfiguration Einstellungen von Farben, Formen, Komplexit¨
at (Datenkanten,
Schleifen, etc.)
Details in Aktivit¨
aten/
Tooltipp/Detailfenster
Einstellung welche Aktivit¨
atenattribute wo dargestellt werden
View-Konfiguration Einstellungen zur aktuell dargestellten View
Historie Anzeige von Historieninformationen
Legende Aufschl¨
usseln der Bedeutungen von Farben, speziellen
Markierungen, Zuordnung von Nummern in der Darstellung zu
Aktivit¨
aten (siehe Abbildung 6.20), etc.
asiehe Detailansicht 7.3
Tabelle 7.2.: Aufgaben im Aufgabenbereich
Änderung durchführen (CR)
entscheiden umsetzen
Expertise 3Expertise 2Expertise 1
CR initialisieren kommentierenProduktionbewerten
Abbildung 7.7.: Vertikale und horizontale Navigation in Prozesshierarchie
in einem Konfigurationsdialog, wie ihn Abbildung 7.6 zeigt. Kontextmen¨
us ¨
uber den Ak-
tivit¨
aten erlauben es direkt zu diesen Einstellungsfenstern zu springen, denn das Interface
sollte die Funktionen dort anbieten, wo der Benutzer sie ben¨
otigt, also beim Betrachten
der Aktivit¨
aten.
View-Konfiguration
Die View-Konfiguration listet vorgenommene Reduktionen auf und die f¨
ur die Aggregation
wichtigen Zuordnungen von Fakten zu Aggregatfunktionen (siehe dazu Abschnitt 7.1).
Historienanzeige
Die Historienanzeige ist an eine Zeitleiste (siehe Abschnitt 6.1.2) gekoppelt, ¨
uber die aus-
gew¨
ahlt wird, bis zu welchem Datum die Informationen ¨
uber den Prozessablauf angezeigt
werden. Es k¨
onnte auch die M¨
oglichkeit angeboten werden, nur bestimmte Aspekte aus
der Historie anzuzeigen, beispielsweise nur ¨
Anderungen an Daten oder Dokumenten.
133
7. Interaktionen auf Prozessinformationen
Die Auswahl einer Aktivit¨
at k¨
onnte die Anzeige der Historie auf die Eintr¨
age diese Ak-
tivit¨
at betreffend einschr¨
anken. Analog w¨
urde die Auswahl eines Dokuments alle Zugriffe
auf das Dokument auflisten.
Legende
Die Legende kann beim ersten Aufruf einer Darstellung automatisch im Aufgabenbereich
angezeigt werden. Was die Aufschl¨
usselung von farblichen Kodierungen in einer Darstel-
lung betrifft, muss ganz allgemein beim Einsatz von Farben darauf geachtet werden, dass
die Zahl der Farben sieben m¨
oglichst nicht ¨
ubersteigt. Weniger ist hier sinnvoller. Falls die-
se Farbanzahl nicht ausreicht, k¨
onnen einzelne Farben auch f¨
ur zwei oder mehr unterschied-
liche Dinge stehen. Diese Farbkodierung soll das Erfassen des Inhaltes einer Darstellung
beschleunigen, also die Perzeption verbessern. Eine exakte Zuordnung ist nicht notwendig,
w¨
are aber als Konfigurationsoption f¨
ur den besonderen Bedarf denkbar. Allerdings kann
sich das menschliche Gehirn im Mittel nur sieben verschiedene Dinge auf einmal merken,
darunter fallen auch Farbzuordnungen. Zudem bekommen Farbenblinde schnell Probleme
beim Auseinanderhalten von Farben, wenn zu viele gleichzeitig verwendet werden.
7.5. Navigation
Innerhalb einer Software, die Gesch¨
aftsprozesse anzeigt, gibt es drei Arten von Navigation
([CR03]):
➣Navigation innerhalb eines Prozesses
➣Navigation zwischen verschiedenen Darstellungen eines Prozesses
➣Navigation zwischen verschiedenen Instanzen eines Prozesses
➣Navigation in hierarchischen Workflows
Außer dieser prozesszentrierten Navigation ist auch die Navigation auf dem Benutzer-
Interface einer Visualisierungskomponente wichtig. Die meisten Funktionen werden tra-
ditionell in Men¨
us oder in Toolbars untergebracht. Da es f¨
ur den Benutzer mehr Navi-
gationsaufwand bedeutet, mit Men¨
us zu arbeiten, weil ihre Inhalte vor dem Anklicken
nicht sichtbar sind, werden h¨
aufig benutzte Funktionen besser in Symbolleisten, Paletten
oder ¨
Ahnlichem untergebracht. ¨
Ublicherweise gibt es in Applikationen zwei Funktionsbl¨
o-
cke. Einige Funktionen stehen jederzeit zur Verf¨
ugung, andere sind nur bei bestimmten
Darstellungen verf¨
ugbar. Dies gilt auch f¨
ur die hier diskutierte Art von Software. Um
die Bedienoberfl¨
ache nicht mit Schaltfl¨
achen zu ¨
uberfrachten, bietet es sich an, die dar-
stellungsspezifischen Funktionen auf eine gesonderte Symbolleiste auszulagern. Je nach
aktiver Darstellung werden in dieser nur die gerade hier m¨
oglichen Funktionen angebo-
ten. Tastenkombinationen zum schnellen Erreichen der meisten Funktionen erleichtern die
Bedienung zus¨
atzlich.
Die Visualisierungskomponente soll eine Vorw¨
arts/R¨
uckw¨
arts Aktionshistorie ¨
ahnlich ei-
nem Internet Browser bieten. Dies ergibt sich aus dem im Usability Kapitel angesproche-
nen Designprinzipien Zur¨
uck und Undo (siehe Abschnitt 4.1.3). F¨
ur den Benutzer ist es
bequem, wenn ¨
uber ein Auswahlmen¨
u gezielt eine der letzten Ansichten gew¨
ahlt werden
kann. Dazu ist es notwendig den Aktionen Namen zuzuweisen wie ’Switch to Processgraph’,
134
7.5. Navigation
’Switch to Calendar’ oder ’Hide Documents’. Die Abbildung 7.8 zeigt diese Funktion am
Beispiel eines Browsers, wo die Namensgebung allerdings kein Problem darstellt, denn die
Namen der besuchten Webseiten sprechen f¨
ur sich.
Abbildung 7.8.: Zur¨
uck-Funktion mit benannten Aktionen im Internet Explorer
Navigation innerhalb eines Prozesses
Selbst einzelne Prozesse k¨
onnen eine enorme Komplexit¨
at aufweisen. Daher gilt es den
Benutzer bei der Navigation innerhalb eines Prozesses, durch geeignete Hilfsmittel zu
unterst¨
utzen.
Das ¨
ublichste Navigationswerkzeug sind Scrollbars. Genau diese Form der Navigation gilt
es allerdings soweit wie m¨
oglich zu vermeiden, denn es ist f¨
ur den Nutzer die schwierigste
Art und Weise zu navigieren. Leider lassen sich selbst kleinere Prozesse kaum auf einer
Bildschirmseite unterbringen. Daher muss dem Nutzer m¨
oglichst viel Hilfestellung gegeben
werden.
Eine kompakte Darstellung reduziert den Navigationsbedarf. Je nach anzuzeigendem Pro-
zess kann eine horizontale oder eine vertikale Ausrichtung der Prozessdarstellung den vor-
handenen Bildschirmplatz besser ausn¨
utzen. Der Benutzer kann zwischen diesen beiden
Orientierungen wechseln, wenngleich die meisten Nutzer aus dem westlichen Kulturkreis,
die Informationsaufnahme von links nach rechts bevorzugen.
Um eine kompaktere Darstellung zu erzeugen, bietet das Interface eine einfache M¨
oglich-
keit, schnell zwischen verschiedenen Schemata oder Aktivit¨
atenknoten-Konfigurationen
(engl. Styles) hin- und herzuwechseln. So k¨
onnen einerseits kleinere Knotenrepr¨
asenta-
tionen gew¨
ahlt werden. Andererseits kann die Anzahl der in einem Knoten angezeigten
Attribute verkleinert werden (siehe dazu Abbildung 5.11 →S. 71).
Je kleiner die Darstellung der Aktivit¨
atenknoten, desto mehr ¨
Uberblick ¨
uber den Prozess
gewinnt der Nutzer.
Ein ¨
Ubersichtsfenster, das den Gesamtprozess als Thumbnail enth¨
alt, sorgt f¨
ur den n¨
o-
tigen ¨
Uberblick. Ein ideales Beispiel stellt das ¨
Ubersichtsfenster von Adobe Photoshop
dar (Abbildung 7.9). Der im Hauptfenster sichtbare Ausschnitt ist markiert und kann
verschoben werden, wodurch sich der angezeigte Ausschnitt im Hauptfenster ¨
andert. In
einigen Programmen wird der gerade nicht sichtbare Bereich leicht grau hinterlegt, sodass
135
7. Interaktionen auf Prozessinformationen
gleich zwei optische Merkmale darauf hinweisen, wo sich der gerade sichtbare Bereich be-
findet. Zus¨
atzlich kann in dem Photoshop ¨
Ubersichtsfenster stufenlos oder in Schritten
heraus- und hineingezoomt werden. F¨
ur die Verwendung des Konzeptes ¨
Ubersichtsfenster
im Prozessumfeld sollte darauf geachtet werden, dass im ¨
Ubersichtsfenster die momentan
selektierte Aktivit¨
at sowie markierte Aktivit¨
aten deutlich erkennbar sind.
Abbildung 7.9.: ¨
Ubersichtsfenster aus Adobe Photoshop
F¨
ur den Anwender bedeutet es viel Navigationsaufwand, wenn oft zwischen ¨
Uberblick ge-
winnen und Details begutachten gewechselt werden muss. Eine praktikable L¨
osung hierf¨
ur
ist, das Konzept des ¨
Ubersichtsfensters auszuweiten und bei Bedarf zwei Fenster, die sich
den Bildschirm teilen, anzuzeigen. Das erste Fenster zeigt den Prozess im ¨
Uberblick (mit
einem minimalistischen Schema), das andere zeigt einen Ausschnitt mit den notwendigen
Details. Im ersten Fenster ist jederzeit der Ausschnitt markiert, der im zweiten Fenster
angezeigt wird.
Navigation zwischen verschiedenen Darstellungen eines Prozesses
Die Standard-Darstellungsform ist die Prozessgraphdarstellung. Via Kontextmen¨
u oder
Symbolleiste kann zu anderen Darstellungsformen gewechselt werden. Darstellungen k¨
on-
nen in Tabs gespeichert werden1.
Abbildung 7.10.: Tabs im Hauptfenster mit verschiedenen Darstellungen
1Dieses Bedienkonzept ist den meisten Benutzern gel¨
aufig, sei es von Tabellenkalkulationsprogrammen
oder vom Tabbed Browsing bei Internet Browsern.
136
7.5. Navigation
Navigation zwischen verschiedenen Instanzen eines Prozesses
Die umfassendste Navigationsm¨
oglichkeit bietet eine explorerartige Auflistung aller Pro-
zessinstanzen, wie sie in Variante 1 der Tabellendarstellung beschrieben ist (6.4). Nat¨
urlich
k¨
onnen auch alle Multi-Instanz-Darstellungen dazu genutzt werden eine bestimmte Instanz
eines Prozesses zu w¨
ahlen.
Navigation in hierarchischen Workflows
Als globale Navigationswerkzeuge eignen sich baumartige Darstellungen der ganzen Pro-
zesshierarchie. Dies kann grafisch erfolgen, wie bei einem Organigramm oder in einer explo-
rerartigen Auflistung. Letztgenannte wird auch zur Navigation zwischen Instanzen eines
Prozesses verwendet (siehe oben). In ihrer Multi-Schema-Auspr¨
agung (siehe Abschnitt
6.4), kann sie Prozesse, ihre Unterprozesse und Instanzen auflisten. Zus¨
atzlich k¨
onnen in
der Tabellenstruktur interessante Informationen wie der Prozessfortschritt oder ¨
Ahnliches
angezeigt werden. Auf diese Weise l¨
asst sich auch in großen Prozesshierarchien navigie-
ren. Die Prozessauswahl ¨
uber grafische Darstellungen wird indes bei großen Hierarchien
schnell un¨
ubersichtlich. Die Vorteile beider Konzepte lassen sich allerdings kombinieren,
indem neben der Explorer-Liste eine verkleinerte grafische Darstellung der Prozesshierar-
chie in einem ¨
Ubersichtsfenster (vgl. Abschnitt 7.5) angezeigt wird. Weiterhin kann zur
Unterst¨
utzung der Aufgabenbereich ’Navigation’ eingeblendet werden (siehe Abschnitt
7.4).
F¨
ur die lokale Navigation bietet sich das bew¨
ahrte und einfache Konzept einer Navigati-
onsspur (engl. breadcrumb trail) an. Sie zeigt, wo sich der Benutzer in der Prozesshierar-
chie befindet. Umsetzungen finden sich beispielsweise bei den Kategorien von Ebay oder
Amazon (siehe Abbildung 7.11). Auf ¨
ahnliche Weise soll dem Benutzer stets eingeblendet
werden, wo er sich in einem großen hierarchischen Prozess befindet.
Es ist wichtig, dass diese Navigationsinformation jederzeit sichtbar bleibt, im Gegensatz
beispielsweise zu Hinweisen auf Detailinformationen, die nur in einem eingegrenzten Kon-
text von Interesse sind. Weiterhin muss f¨
ur den Benutzer ersichtlich sein, dass es sich um
eine hierarchische Ordnung handelt und nicht um gleichberechtigte Links zu anderen Pro-
zessen. Der Schl¨
ussel hierzu ist die Verwendung eines eindeutigen Trenners wie ’>’ und
’→’ anstatt z. B. ’:’ [Niel01].
Weiterhin steht dem Nutzer der Aufgabenbereich Navigation (siehe Abschnitt 7.4) zur
Verf¨
ugung, um zu benachbarten Prozessen (des aktuellen Prozesses) zu springen.
Abbildung 7.11.: Navigation im Amazon Shop
137
7. Interaktionen auf Prozessinformationen
7.6. Prozesshistorie
Oftmals interessiert nicht nur der aktuelle Zustand eines Prozesses, sondern auch seine
Historie. Diese Prozesshistorie kann in der Historienansicht im Aufgabenbereich (siehe
Abschnitt 7.4) eingeblendet werden.
Animation (Replay)
Die Informationen aus der Ablaufhistorie k¨
onnen dazu genutzt werden, um in den Dar-
stellungsformen Prozessgraph und Swimlane, die Ausf¨
uhrungsfolge der Aktivit¨
aten einer
Prozess-Instanz vom Start des Prozesses bis zur Gegenwart animiert darzustellen. Der
Benutzer kann somit verfolgen, wie an den einzelnen Aktivit¨
aten, w¨
ahrend des Ablaufs
des Prozesses, die verschiedenen Aktivit¨
atenzust¨
ande (z. B. aktiviert, laufend, beendet)
durchlaufen werden.
7.6.1. On-Line Verlaufsinformationen
Informationen ¨
uber aktuelle Zustands¨
anderung an laufenden Prozessen sind nicht nur f¨
ur
eine Visualisierungskomponente interessant. Auch normale Workflow-Clients sind mit ih-
rem Server verbunden, damit ihre Arbeitslisten aktualisiert werden k¨
onnen. Eine Visua-
lisierungskomponente bucht in ¨
ahnlicher Weise Updates ¨
uber die Prozessausf¨
uhrung bei
einem Server. In einem großen System ist zu erwarten, dass sich am Informationsstand des
Systems laufend etwas ¨
andert. Aber nicht alle Informationen sind f¨
ur den Benutzer inter-
essant. Filterfunktionen sollten angeboten werden, damit selektiert werden kann, welche
Updates der Server liefern soll. Die verschiedenen angebotenen Darstellungsformen zeigen
unterschiedliche Informationen. F¨
ur den Benutzer ergeben sich damit drei F¨
alle:
➣Fall A Update an der eingeblendeten Darstellungsform
➣Fall B Update, das nur in einer anderen Darstellungsform sichtbar ist
➣Fall C Update an Prozessen, die momentan nicht angezeigt werden oder an
Prozessteilen, die nicht zur aktuellen Sicht der Visualisierungskomponente
geh¨
oren2
Nur in den F¨
allen A und B soll der Benutzer informiert werden. Neu verf¨
ugbare Verlaufs-
informationen werden im Normalfall nicht sofort ohne Hinweis zur Anzeige gebracht, da
dies vom Benutzer ¨
ubersehen werden k¨
onnte oder den Arbeitsablauf st¨
oren k¨
onnte. Neue
Verlaufsinformationen werden daher solange gesammelt, bis der Benutzer die Darstellung
aktualisiert. Ein dezent kurz am Bildschirmrand eingeblendetes Popup-Fenster weist den
Benutzer auf Updates hin. Ein Klick darauf bringt die neuen ¨
Anderungen zur Anzeige
und wenn n¨
otig, wird der dargestellte Bildschirmbereich an die richtige Stelle verschoben.
Außer dem kurz eingeblendeten Popup-Fenster zeigt das Interface eine Markierung, die
¨
uber neue Verlaufsinformationen informiert.
2mehr zum Sichtenkonzept siehe Abschnitt 7.1
138
7.7. Zusammenfassung
7.7. Zusammenfassung
Die View-Bildung ist ein m¨
achtiges Werkzeug um Prozessinformationen auf das Wesentli-
che zusammenzufassen und zu reduzieren. Sie l¨
asst sich parallel zu den in Kapitel 5und 6
vorgestellten grafischen und strukturellen Aspekten anwenden, um die Prozessvisualisie-
rung signifikant zu verbessern.
In diesem Kapitel wurden außerdem sinnvolle Funktionen f¨
ur den Umgang mit Prozessin-
formationen vorgestellt. Werkzeugleisten erschließen dem Anwender einer Visualisierungs-
komponente diese Funktionsvielfalt. Um die ¨
Ubersichtlichkeit zu verbessern und um ge-
w¨
unschte Informationen schneller zu finden kann der Benutzer Markierungsregeln verwen-
den und anlegen. Die Detailansicht dient dazu, die eigentliche Prozessansicht von Details
zu befreien, um die Darstellungskomplexit¨
at zu verringern. Navigationsl¨
osungen, sowohl
innerhalb von Prozessen, als auch in Prozesshierarchien wurden vorgestellt.
139
8
Ausblick
In den folgenden Unterkapiteln wird kurz auf einige in dieser Arbeit nicht n¨
aher betrachtete
Aspekte eingegangen. So werden Sicherheitsaspekte angesprochen, da Prozessinformatio-
nen in Unternehmen ¨
außerst wertvolle Ressourcen darstellen. Weiterhin geht es um das
Problem, der nicht eindeutigen Partitionierbarkeit von Prozessinformationen. Den Ab-
schluss bildet ein Fazit der erzielten Ergebnisse.
8.1. Sicherheitsaspekte
Nicht jeder Anwender eine Prozessvisualisierungskomponente soll auf den kompletten
Prozess-Pool eines Unternehmens zugreifen k¨
onnen. Insbesondere wenn Kunden, zwecks
Kooperation oder Information, Einblick in Arbeitsprozesse erhalten sollen, gilt es ihnen nur
ausgew¨
ahlte Teilbereiche zug¨
anglich zu machen. Es gibt nun zwei naheliegende Ans¨
atze
f¨
ur den Aufbau von Mechanismen f¨
ur den Zugriffsschutz.
Im Metamodell verankerter Zugriffsschutz
Das Metamodell kann Erweiterungen f¨
ur den Zugriffsschutz erhalten. So k¨
onnen Attribu-
ten beispielsweise Sicherheitsschichten zugeordnet werden, um damit die Sichtbarkeit von
Attributen zu regeln und Zugriffsmodi wie nur lesen oder lesen & schreiben. Tabelle 8.1
listet Vor- und Nachteile dieser Methode auf.
Kurzkritik
+ Aufwand beim Erstellen, ¨
Andern des Metamodells, aber schnelles Zuteilen von
Zugriffsrechten m¨
oglich
– Ausdrucksm¨
achtigkeit stark begrenzt, Sonderf¨
alle erfordern hohen Aufwand
– hoher administrativer Aufwand
Tabelle 8.1.: Kurzkritik f¨
ur Zugriffsschutz durch Metamodell-Unterst¨
utzung
141
8. Ausblick
Nutzung von Views f¨
ur den Zugriffsschutz
Der Zugriffsschutz kann auch personen- oder rollenbezogen durch die Restriktion auf vor-
bereitete Views erfolgen. Verschiedenen Benutzergruppen werden also explizit Views zu-
geordnet, die sie f¨
ur die Erledigung ihrer jeweiligen Aufgabe ben¨
otigen. Andere Bereiche
der Prozesshierarchie sind nicht zugreifbar. Tabelle 8.2 listet Vor- und Nachteile dieser
Methode auf.
Kurzkritik
+ hohe Sicherheit
+ Zugriff genau an Bedarf anpassbar, erh¨
oht auch die ¨
Ubersichtlichkeit
– Aufwand beim Zuteilen der Zugriffsrechte, aber bereits erstellte Views k¨
onnen
wiederverwendet werden
Tabelle 8.2.: Kurzkritik f¨
ur Zugriffsschutz durch Views
Die Visualisierungskomponente k¨
onnte mit einer Art Basis-View f¨
ur den jeweiligen Benut-
zer gestartet werden, beziehungsweise der Benutzer k¨
onnte auf einige Basis-Views Zugriff
haben, von denen er eine zu Beginn seiner Sitzung l¨
adt. Der Benutzer kann sich eigene
Views erstellen (und abspeichern). Diese sind allerdings immer von einer Basis-View ab-
geleitet, d. h. sie stellen immer nur eine Untermenge der in der Basis-View festgelegten
Prozessinformationen dar. Die Ableitung von einer Basis-View ließe sogar zu, dass sich
administrativ fernsteuerbar an den vom Benutzer selbst angelegten Views nachtr¨
aglich
Rechte hinzuf¨
ugen oder entfernen (engl. add/revoke rights) ließen.
8.2. Partitionierbarkeit von Prozessinformationen
Bei den Darstellungskonzepten, die sehr auf das Organisationsmodell zur¨
uckgreifen, wie
Swimlane und Kalender, existieren Hauptformen oder Varianten, die voraussetzen, dass
sich die in einem Prozess enthaltenen Aktivit¨
aten eindeutig bez¨
uglich einer Ressource
partitionieren lassen. Dies kann jedoch im Allgemeinen nicht garantiert werden, vor allem,
weil PMS die Zuordnung von mehreren Objekten eines Typs zu einer Aktivit¨
at erlauben,
um die M¨
achtigkeit der Prozessmodellierung nicht einzuschr¨
anken.
Sobald einzelnen Aktivit¨
aten mehr als ein beteiligter Bearbeiter zugeordnet wird, l¨
asst sich
eine solche Aktivit¨
at in der R¨
uckrichtung nicht mehr eindeutig einem Bearbeiter zuordnen.
Im Falle der Swimlane-Darstellung beispielsweise, l¨
asst sich eine Aktivit¨
at dann nicht mehr
eindeutig einer (Bearbeiter-)Lane zuordnen.
F¨
ur die verschiedenen Ressourcen (Ausf¨
uhrungseinheit, Dokumente/Daten, Systeme/An-
wendung) existieren F¨
alle mit nicht eindeutigen Zuordnungen:
➣Die Umsetzung des Vieraugenprinzips erfordert mehrere Ausf¨
uhrungseinheiten
➣Aktivit¨
aten k¨
onnen mehrere zugeordnete Bearbeiter in verschiedenen Rollen aufwei-
sen, etwa verantwortlich, bearbeitet, ber¨
at, wird informiert. Einer Beratungsaktivit¨
at
k¨
onnten so beispielsweise zwei Personen in den Rollen ’ber¨
at’ und ’wird informiert’
zugeordnet sein.
➣Nicht selten wird bei einer Aktivit¨
at aus mehreren Dokumenten gelesen und geschrie-
ben.
142
8.3. Anpassung des Nutzer-Interface an Prozessmodelle
➣Aktivit¨
aten an Schnittstellen von Systemen oder Anwendungen erfordern h¨
aufig Zu-
griff auf zwei Systeme.
Das beschriebene Problem tritt also bei allen Arten der Partitionierung auf: Ausf¨
uhrungs-
einheiten, Dokumente und Systeme. Immer k¨
onnen mehrere Objekte einer Aktivit¨
at zu-
geordnet werden. Oftmals besteht bei der Visualisierung jedoch die Notwendigkeit der
eindeutigen Zuordnung von Ressourcen zu Aktivit¨
aten.
M¨
ogliche Ans¨
atze f¨
ur den Umgang mit dem Problem:
➣Hauptobjekte
Vom Prozess-Metamodell wird die Bezeichnung eines Hauptobjekts f¨
ur je-
den Ressourcentyp vorgesehen. Jedoch stellt sich die Frage, nach welchem
Kriterium ein Objekt als Hauptobjekt deklariert wird.
➣Schatten-Aktivit¨
aten
Eine Aktivit¨
at wird in der Darstellung in mehrere Schatten-Aktivit¨
aten auf-
geteilt und somit mehreren Ressourcen gleichzeitig zugeordnet – in der Swim-
lane-Darstellung also mehreren Lanes. Die Visualisierung muss zwischen nor-
malen Aktivit¨
aten und Schatten-Aktivit¨
aten unterscheiden und muss deutlich
machen, dass zu einer Schatten-Aktivit¨
at einer Partition noch weitere in an-
deren Partitionen geh¨
oren. Es bietet sich eine halbtransparente Darstellung
dieser Aktivit¨
aten an. Bei Selektion einer Aktivit¨
at werden aller zusammenge-
h¨
origen Aktivit¨
aten hervorgehoben – auch in der ¨
Ubersichtsdarstellung (siehe
Abschnitt 7.5).
➣Transformation
Einige F¨
alle wie das Vieraugenprinzip lassen sich auch auf andere Art model-
lieren. In diesem Fall durch eine Ersetzung der einzelnen Aktivit¨
at mit zwei
Bearbeitern in zwei parallele Aktivit¨
aten, gegebenenfalls durch eine Sync-
Kante verbunden, mit je einem Bearbeiter. Jedoch erzeugt diese Vorgehens-
weise schwer verst¨
andliche komplexe Modelle.
Diese Ans¨
atze lassen sich f¨
ur eine geeignete Darstellung auch alle miteinander kombinieren.
Erw¨
ahnt werden kann hier noch, dass die Matrixdarstellung von dieser Problematik nicht
betroffen ist, da hier die Ressourcen selbst im Mittelpunkt stehen und nicht Aktivit¨
aten,
die zugeordnet werden m¨
ussen.
8.3. Anpassung des Nutzer-Interface an Prozessmodelle
Eine Visualisierungskomponente f¨
ur Prozessinformationen ist ein hochkomplexes St¨
uck
Software, was dazu f¨
uhrt, dass auch die Bedienbarkeit nicht ohne weiteres einfach zu hal-
ten ist. Gerade weil die Prozessinformationen selbst niemals fest definiert sind, sondern
immer anwendungsspezifische Erweiterungen des Metamodells oder des Datenmodells ent-
halten k¨
onnen, muss sich die Benutzeroberfl¨
ache an diese ¨
Anderungen anpassen lassen,
was zwangsweise Konfigurationsaufwand nach sich zieht und die Oberfl¨
ache komplizierter
macht. Eine Reduktion der Komplexit¨
at der Oberfl¨
ache ließe sich erreichen, indem Men¨
us
und Einstellungen der Darstellungsformen dynamisch anpassbar gemacht werden. F¨
ur alle
verwendeten Prozessmodelle ließe sich einmalig eine GUI-Konfiguration erstellen. Anhand
143
8. Ausblick
dieser Konfigurationen w¨
urde dann beim Betrachten von Prozessinformationen die zum
jeweiligen Prozessmodell passende Konfiguration f¨
ur die Nutzeroberfl¨
ache geladen.
8.4. Mitbestimmung des Betriebsrates
In deutschen Unternehmen hat der Betriebsrat ein gesetzlich verankertes Mitbestimmungs-
recht was die Thematik des Datenschutzes angeht. Dieser wird bei der Protokollierung von
Benutzeraktionen tangiert. Dies ist f¨
ur die Nutzung eines PMS jedoch unumg¨
anglich. So-
bald jedoch die Prozessdaten nicht nur elektronisch verarbeitet, sondern zur Visualisierung
aufbereitet werden, sollte der Betriebsrat m¨
oglichst fr¨
uhzeitig informiert und in die Pla-
nung mit eingebunden werden.
8.5. Fazit
Die Visualisierung von Gesch¨
aftsprozessen wird f¨
ur Unternehmen immer wichtiger. Es exis-
tieren heute viele fortgeschrittene Werkzeuge f¨
ur Prozess-Monitoring und -Analyse. Diese
bieten allerdings nur recht eingeschr¨
ankte Visualisierungsm¨
oglichkeiten f¨
ur Prozessmodelle
und -Instanzen.
In dieser Arbeit wurde erstmals umfassend untersucht, welche M¨
oglichkeiten bestehen,
um Prozessdaten zu visualisieren. Dabei wurden Aspekte wie die grafische Repr¨
asentati-
on, die Strukturierung der Daten, das Erstellen geeigneter Sichten, die Verkn¨
upfung mit
Wissen aus Organisationsmodellen und die Anpassbarkeit an Benutzerbed¨
urfnisse ber¨
uck-
sichtigt. Das Ergebnis ist eine umfangreiche Kollektion von Visualisierungskonzepten und
Interaktionsm¨
oglichkeiten auf Prozessdaten. Diese wurden im Hinblick auf eine k¨
unftige
system¨
ubergreifende Visualisierungskomponente zusammengestellt und aufeinander abge-
stimmt.
Ausblick
An dieser Stelle ein kurzer Ausblick, bevor n¨
aher auf die erreichten Ergebnisse eingegangen
wird. Eine Zielsetzung der Arbeit war, m¨
oglichst viele zusammenh¨
angende Informationen
aus den verf¨
ugbaren Prozessdaten zu extrahieren. Es bestehen nun noch weitere M¨
oglich-
keiten, um Prozessinformationen anzureichern. Daf¨
ur ist es allerdings notwendig, die Da-
tenbasis der Visualisierungskomponente zu erweitern und außer Modell- und Laufzeitdaten
auch die Log-Daten von PMS auszuwerten. Durch abgeleitetes Prozesswissen aus vergan-
genen Prozessausf¨
uhrungen, k¨
onnten so beispielsweise Wahrscheinlichkeiten bei Kontroll-
flussverzweigungen angegeben werden oder statistisch auff¨
allige Werte dem Benutzer direkt
in den Darstellungen signalisiert werden. Ein Endziel k¨
onnte darin bestehen, eine wie in
dieser Arbeit beschriebene Prozessvisualisierungskomponente mit einer Process-Mining-
Komponente zu verbinden. Am Schluss k¨
onnten Visualisierung, Monitoring, Analyse und
Optimierung einheitlich unter einer Oberfl¨
ache vereint werden. Die vorgestellte Visualisie-
rungskomponente soll Prozessdaten aus einem heterogenen Prozessumfeld anzeigen. Hier
sind Erweiterungen in Richtung unternehmens¨
ubergreifender Prozessvisualisierung (engl.
cross organizational) denkbar, um Interaktionen und Datenfl¨
usse zwischen Prozessen ver-
schiedener Unternehmen darstellen zu k¨
onnen.
144
8.5. Fazit
Zusammenfassung
Die Zielsetzung war, Konzepte f¨
ur die Visualisierung von Prozessinformationen zu entwi-
ckeln, um Anwendern einer Visualisierungskomponente m¨
oglichst alle Aspekte von Pro-
zessinformationen, ¨
uber komfortable leistungsf¨
ahige Darstellungen, zug¨
anglich zu machen.
Die L¨
osung dieser Aufgabe erfolgte ¨
uber unterschiedliche Ans¨
atze.
Der erste Ansatz bestand darin zu untersuchen, welchen Anforderungen eine leistungsf¨
ahi-
ge Prozessvisualisierungskomponente gen¨
ugen muss. Außer Anforderungen an die allgemei-
ne Gebrauchstauglichkeit (Usability) sollen Anwenderbed¨
urfnisse ber¨
ucksichtigt werden.
Aus den Erfordernissen k¨
unftiger Nutzergruppen wie etwa Anwendern, Management oder
Kunden, wurden grundlegende Aufgabentypen und Detailgrad-Anforderungen abgeleitet.
Dieses Anforderungsspektrum diente als Gradmesser im Hinblick auf die zu entwickelnden
Visualisierungskonzepte.
Der zweite Ansatz war, grafische Aspekte existierender Darstellungsformen, wie etwa von
Prozessgraphen, zu verbessern. Die Optimierung erfolgte im Hinblick auf die St¨
arken und
Schw¨
achen des menschlichen Wahrnehmungssystems, um m¨
oglichst viele Informationen
in einer dennoch schnell erfassbaren Form zu visualisieren. Um vom Wiedererkennungs-
wert zu profitieren, entstand, in Anlehnung an UML und BPMN, eine grafische Notation,
die eine hohe Packungsdichte zul¨
asst, um die begrenzte Anzeigefl¨
ache m¨
oglichst effektiv
auszunutzen.
Weiterer Ansatz war, strukturelle Aspekte der Prozessvisualisierung zu untersuchen. F¨
ur
alle in Prozessdaten enthaltenen Informationsaspekte, wie etwa Datenfluss oder temporale
Aspekte, sollte eine geeignete Struktur f¨
ur die Darstellung gefunden werden. Denn Prozess-
informationen sind nicht auf ihre bei der Modellierung vorgegebene Struktur festgelegt.
Zeitinformationen lassen sich beispielsweise in Gantt-Diagrammen gut wiedergeben.
¨
Uber diese Ans¨
atze entstanden so optimierte Darstellungsformen, wie Prozessgraphdar-
stellung, Swimlane-Darstellung, Kalenderdarstellung, Tabellendarstellung, Interaktions-
diagramm, Datenflussdiagramm und eine Matrixdarstellung. Diese Formen k¨
onnen mit
verschiedenen Darstellungsarten kombiniert werden: Schema-, Instanz-, Multi-Instanz- und
Multi-Schema-Darstellungen. Dies f¨
uhrt zu einer großen Vielfalt verschiedenster Detail-
und ¨
Ubersichtsdarstellungen.
Eine Hauptschwierigkeit bei Bildschirmdarstellungen stellt die begrenzte Anzeigefl¨
ache
dar, im Vergleich zu h¨
aufig sehr großen und komplexen Prozessen. Daher wurden rund um
diese Visualisierungskonzepte umfangreiche Interaktions- und Navigationsm¨
oglichkeiten
f¨
ur eine k¨
unftige Prozessvisualisierungskomponente vorgeschlagen. Darunter beispielswei-
se die View-Bildung. Sie bildet die Grundlage, zur Erzeugung unterschiedlich komplexer
Sichten auf Prozesse.
Der Fokus dieser Arbeit liegt auf der Beschreibung verschiedener Darstellungskonzep-
te. Daher wurden f¨
ur die Visualisierungsbeispiele nur Standardkonstrukte eines Prozess-
Metamodells verwendet. Spezialkonstrukte wie Variable Parallelit¨
at, Mengenverarbeitung
(engl. expansion region [Omg 05b]) oder Zeitkanten sollten sich aber auch in die hier vor-
gestellten Darstellungskonzepte integrieren lassen.
Diese Arbeit beschreibt eine Vision f¨
ur eine m¨
achtige Prozessvisualisierungskomponente,
die umfangreiche M¨
oglichkeiten bietet, in Prozessinformationen zu recherchieren und in
145
8. Ausblick
hierarchischen Prozessen zu navigieren. Solche Visionen sind nie endg¨
ultig, die Zusam-
menstellung der Darstellungskonzepte und deren Konfigurations- und Interaktionsm¨
og-
lichkeiten kann nie im mathematischen Sinne als vollst¨
andig erachtet werden. So wichtig
und n¨
utzlich eine sorgf¨
altige und ausf¨
uhrliche Analyse auch ist, nur ein stetiger Verbesse-
rungsprozess von Version zu Version durch ausf¨
uhrliches Nutzer-Feedback wird die Vision
Wirklichkeit werden lassen, jede nur erdenkliche Auswertung von verf¨
ugbaren Prozessin-
formationen m¨
oglich zu machen. Dies gilt umso mehr, als dass im Rahmen dieser theore-
tischen Arbeit keine Nutzerumfrage m¨
oglich war. Letztlich muss die Praxis zeigen, welche
Bed¨
urfnisse die Benutzer haben und wie diese Darstellungsformen noch verfeinert werden
k¨
onnen, welche Interaktionen noch ben¨
otigt werden und welche neuen Darstellungsformen
eventuell noch notwendig werden. Wissenschaftliche Untersuchungen dazu laufen bereits,
so z. B. [LM04].
146
A
Glossar
B
Breadcrumb trail
Eine deutsche ¨
Ubersetzung existierte zur Drucklegung noch nicht. In N¨
aherung k¨
onnte
es mit ’Navigation in hierarchischen Kategorien’ oder Navigationsspur wiedergegeben
werden. Die Wendung entstand wohl in Anlehnung an die Brotkr¨
umelspur von H¨
ansel
und Gretel. Der Nutzer bekommt mehrere Links dargestellt, die ihm geordnet den Weg
zur¨
uck weisen. (siehe 7.5 und Abbildung 7.11)
BPMN
Business Process Management Notation.
BPM Werkzeuge
Business Process Management Werkzeuge dienen zum Management von Gesch¨
aftspro-
zessen. Sie umfassen die Teilbereiche Modellierung, Analyse, Monitoring & Steuerung
von Prozessen (→siehe PMS).
D
Darstellung
Prozessinformationen k¨
onnen unterschiedlich dargestellt werden, es gibt textuelle/stru-
kturelle oder graphische Auspr¨
agungen. Darstellungen sind Visualisierungskonzepte.
Data-Warehouse
Eine einheitliche Definition existiert derzeit nicht, eine treffende Beschreibung w¨
are ei-
ne zentrale Daten-Sammelstelle in der Daten aus unterschiedlichsten Quellen integriert
werden, um eine globale Sicht auf die Daten zu erm¨
oglichen, zum Zwecke einer gemein-
samen Auswertung und Weiterverwendung. Umfassende Informationen bietet ein Buch
vom ’Vater des Data Warehousing’ William Inmon [Inmo96].
147
A. Glossar
F
Form follows function
Entwurfskonzept f¨
ur die Anwendungsentwicklung. Hauptziel der Entwicklung ist, dass
die Anwendung bestimmte Funktionen anbietet. Ihr Design orientiert sich an der Be-
reitstellung von Funktionen. Dies entspricht h¨
aufig dem Denken von Entwicklern in Ka-
tegorien wie Funktionen und Features. Das gegenteilige Konzept ist →Goal-Directed-
Design.
G
Goal-Directed-Design
Entwurfskonzept f¨
ur die Anwendungsentwicklung. Hauptziel der Entwicklung ist, dass
das Design der Anwendung darauf ausgerichtet ist, m¨
oglichst effektiv die Benutzer bei
der Erreichung ihrer Ziele zu unterst¨
utzen. Das gegenteilige Konzept ist →Form follows
function
GUI
Grafische Benutzerf¨
uhrung (engl. Graphical User Interface) im Gegensatz zu Kommandozeilen-
basierten Schnittstellen. Grafikelemente und Mausbedienung erm¨
oglichen eine leicht
erlernbare, standardisierte Benutzung von Programmen und Betriebssystem
H
HCI
Human Computer Interaction (dt. Mensch-Maschine-Interaktion) ist ein interdiszipli-
n¨
arer Forschungszweig, dessen Zielsetzung es ist m¨
oglichst gute Benutzerschnittstellen
zu schaffen
Hierarchische Workflows
Unternehmensweite Gesch¨
aftsprozesse werden in hierarchischen Workflows organisiert.
Sie bilden eine Hierarchie von Haupt- und Teilprozessen (siehe Abbildung 7.7).
HSL-Farbraum
(auch HSB) Farben werden durch unterschiedliche Farbr¨
aume beschrieben. Bekannter
ist der RGB-Farbraum. HSL steht f¨
ur Hue (Farbton), Saturation (Farbs¨
attigung) und
Lightness/Brightness (Farbhelligkeit). Der Farbton w¨
ahlt eine Farbe aus einem Farb-
kreis, wobei Rot 0
°
entspricht, Gelb 60
°
, Gr¨
un 120
°
, Cyan 180
°
, Blau 240
°
und Magenta
300
°
. Die S¨
attigung gibt die Reinheit der Farbe in Prozent an, 0% bedeutet Grau. 100%
Helligkeit erzeugt die Farbe Weiß, 0% die farbe Schwarz, 50% Helligkeit entspricht dem
reinen Farbton.
M
MSC
Message Sequence Charts sind Sequenzdiagramme, die urspr¨
unglich zur Modellierung
von Telekommunikationssystemen entwickelt wurden [BH89]. Die ITU-TS hat dazu
Ende 1991 einen ersten Standard namens Z.120/92 verabschiedet [ITU-91]. Sp¨
ater ka-
men noch Erweiterungen hinzu. MSC’s sind als Sequenzdiagramme auch Teil von UML
[Omg 05b], dort unterscheiden sie sich jedoch vom ITU-TS Standard und sind objekt-
orientiert.
148
OOrthogonalität
(auch Interne Konsistenz) Es werden Ausdrucksformen ben¨
otigt, die ¨
Ahnlichkeit und
Verschiedenheit gleichzeitig transportieren k¨
onnen. Ein Symbol kann z. B. leicht mo-
difiziert werden, dabei aber Aspekte seiner Form oder die Farbe behalten. Auf diese
Weise kann der Betrachter leicht die ¨
Ahnlichkeit von zwei Informationen erkennen,
aber gleichzeitig deren Unterschiedlichkeit erfassen. Ein Beispiel w¨
are das Symbol f¨
ur
eine Aktivit¨
at, welches in zwei Farben dargestellt wird, um beispielsweise damit dar-
zustellen, dass die Aktivit¨
at zwei unterschiedlichen Bearbeitern zugeordnet ist.
PPersonas
Ein wichtiges Konzept f¨
ur das Interface-Design sind nach Alan Cooper Personas [CR03,
S.55]. Diese sind m¨
oglichst pr¨
azise Beschreibungen der sp¨
ateren Benutzergruppen, mit-
samt ihren Motivationen und Zielen (engl. goals). Die Personas mit ihren Zielen sind
die Grundlage des →Goal-Directed-Design.
PMS
Prozess-Management-Systeme sind ein Oberbegriff f¨
ur Workflow Managment Systeme
(→siehe WfMS), denn sie umfassen ¨
ublicherweise eine sehr viel weitergehendere Tech-
nologie. Alternativ wird oftmals auch von Business Process Management Systemen
(BPMS) gesprochen. PMS optimieren Arbeitsabl¨
aufe in Unternehmen. Hierf¨
ur wer-
den Gesch¨
aftsprozesse in ihre einzelnen Arbeitschritte zerlegt und f¨
ur die Hinterlegung
in einem PMS modelliert. PMS bieten u. a. folgende Funktionalit¨
at im Umgang mit
Prozessen: ausf¨
uhren, automatisieren, kontrollieren, beobachten und analysieren.
VView
Eine View ist eine Abbildung von der Menge aller Prozessinformationen auf eine be-
liebige Untermenge von Prozessinformationen. →Darstellungen zeigen Views an.
Visualisierungskonzept
siehe →Darstellung
WWfMS
Workflow Management System (Abk¨
urzung auch WFM) →siehe PMS
149
B
Literaturverzeichnis
[AbsI06] AbsInt Angewandte Informatik GmbH:aiSee - Graph Visualization (Websi-
te). Version: 2006. http://www.absint.com/aisee/. – Online Ressource, Abruf:
07.02.2006
[ades01] adesso AG:LeuSmart (Version 3.2.1), Benutzerhandbuch
[Appl87] Apple Computer Inc.:Apple Human Interface Guidelines. Version: 1987.
http://developer.apple.com/documentation/UserExperience/Conceptual/
OSXHIGuidelines/OSXHIGuidelines.pdf. – Online Ressource, Abruf: 27.07.2005
[BH89] Belina, F. ; Hogrefe, D.: The CCITT Specification and Description Language SDL.
In: Computer Networks and ISDN Systems Vol. 16 (1989), M¨
arz
[BMI 02] BMI Bundesministerium des Inneren der Bundesrepublik Deutschland:
Barrierefreie Informationstechnik-Verordnung BITV. Version: Juli 2002. http://
bundesrecht.juris.de/bitv/index.html. – Online Ressource, Abruf: 01.02.2006
[Bons96] Bonsiepe, Gui: Interface. Design neu begreifen. Mannheim : Bollmann Verlag, 1996
[Bpmi03a] Bpmi Organization:BPMN Business Process Modeling Notation (Website).
Version: 2003. http://www.bpmn.org. – Online Ressource, Abruf: 27.10.2005
[Bpmi03b] Bpmi Organization:Business Process Management Initiative (Website).
Version: 2003. http://www.bpmi.org. – Online Ressource, Abruf: 27.10.2005
[BRB05] Bobrik, Ralph ; Reichert, Manfred ; Bauer, Thomas: Requirements for the Vi-
sualization of System-Spanning Business Processes. In: 16th International Workshop
on Database and Expert Systems Applications (DEXA 2005). Copenhagen, Denmark
: IEEE Computer Society, August 2005, S. 948–954
[Bris05] Bristol Technology:TransactionVision White Paper. Version: Juni 2005. http:
//www.bristol.com/transactionvision/. – Online Ressource, Abruf: 25.01.2006
[Cava03] Cavallero, Dave: Integration technology lets business and IT collaborate to improve
business results. IBM Software Group
[Coll03] Collaxa Inc.:Collaxa BPEL4WS 101 Tutorial. Version: 2003. http://www.cems.
uwe.ac.uk/~cjwallac/UFIE8V-2004/collaxa-bpel101.pdf. – Online Ressource,
Abruf: 06.02.2006
151
B. Literaturverzeichnis
[Coop05] Cooper, Alan: Article on Goal-Directed Design (Website). Version: 2005. http:
//www.cooper.com/articles/art_goal_directed_design.htm. – Online Ressource,
Abruf: 13.02.2006
[COPA06] COPA-DATA GmbH:COPA-DATA (Website). Version: 2006. http://www.
copadata.de/. – Online Ressource, Abruf: 07.02.2006
[CR03] Cooper, Alan ; Reimann, Robert: About Face 2.0. The Essentials of Interaction
Design. John Wiley & Sons, 2003. – ISBN 0764526413
[Dece05] December, John: HTML Station (Website). Version: 2005. www.december.com/
html/spec/colorshadesuse.html. – Online Ressource, Abruf: 08.08.2005
[DGS95] Deiters, Wolfgang ; Gruhn, Volker ; Striemer, R¨
udiger: Der FUNSOFT-Ansatz
zum integrierten Geschaeftsprozessmanagement. In: Wirtschaftsinformatik (1995), Nr.
5, S. pp. 459–466. – ISSN 0302–9743
[Dodd02] Dodd, John: Perceptual factors in Information Visualisation (Website).
Version: 2002. http://www.bunnyfoot.com/freestuff/articles/general/
visualisation.html. – Online Ressource, Abruf: 28.10.2005
[DOL02] Denford, Mark ; O’Neill, Tim ; Leaney, John: Architecture-Based Visualisation
of Computer Based Systems. In: ECBS, 2002, S. 139–146
[DR03] Dadam, Peter ; Reichert, Manfred: ADEPT - Prozess-Management-Technologie
der n¨
achsten Generation. Abteilung Datenbanken und Informationssysteme, Uni-
versit¨
at Ulm. Version: 2003. http://www.informatik.uni-ulm.de/dbis/01/dbis/
downloads/DaRe04.pdf. – Online Ressource, Abruf: 06.09.2005
[e-FA00] e-FACT GmbH:ProcessReports User Manual V1.0
[Ecli06] Eclipse.org:Eclipse (Website). Version: 2006. http://www.eclipse.org/. – Online
Ressource, Abruf: 15.02.2006
[Gefa04] Gefasoft AG:Gefasoft (Website). Version: 2004. http://www.gefasoft.de/. –
Online Ressource, Abruf: 07.02.2006
[Heid02] Heidmann, Frank: Web Design - Guidlines and Standards. Fraunhofer IAO.
Version: 2002. http://ais.informatik.uni-leipzig.de/download/2002w_v_mmk/
2002w_mmk_v_12.pdf. – Online Ressource, Abruf: 18.07.2005
[Huss84] Hussy, W.: Denkpsychologie, Band 1. Ein Lehrbuch. Stuttgart : Kohlhammer, 1984
[IBM 03a] IBM Corp.:Business activity management: Your window of oppurtunity for better
business operations. IBM Business integration solutions, Executive brief
[IBM 03b] IBM Corp.:IBM WebSphere Business Integration Monitor V 4.2.4.
Version: September 2003. ftp://ftp.software.ibm.com/software/integration/
library/specsheets/wbimonitor_G325-2210-01.pdf. – Online Ressource, Abruf:
06.02.2006
[IBM,03] IBM, BEA Systems, Microsoft, SAP AG, Siebel Systems:Business Pro-
cess Execution Language for Web Services version 1.1. Version: Mai 2003. http:
//www-106.ibm.com/developerworks/webservices/library/ws-bpel/. – Online
Ressource, Abruf: 06.02.2006
[IDS 03] IDS Scheer AG:ARIS Process Performance Manager (ARIS PPM). White Paper.
Version: 2003. http://www.ids-scheer.com/international/german/products/
aris_controlling_platform/49532. – Online Ressource, Abruf: 04.02.2006
[iGra06] iGrafx:iGrafx (Website). Version: 2006. http://www.igrafx.de/. – Online Res-
source, Abruf: 04.02.2006
152
B. Literaturverzeichnis
[ILOG06] ILOG Inc.:ILOG Visualization (Website). Version: 2006. http://www.ilog.com/
products/visualization/. – Online Ressource, Abruf: 07.02.2006
[in -03] in - integrierte informationssysteme GmbH:sphinx open (Websi-
te). Version: 2003. http://www.in-gmbh.de/de/Produkte/Visualisierung/index.
html. – Online Ressource, Abruf: 07.02.2006
[Inmo96] Inmon, W. H.: Building the Data Warehouse. QED Publishing Group, 1996
[Inos03] Inosoft GmbH:VisiWinStudio - Visualisierungs-Systeme. White Paper.
Version: 2003. http://www.inosoft.com. – Online Ressource, Abruf: 07.02.2006
[Intr01] Intraware:Prozessdokumentation und Simulation mit Bonapart. Factsheet Bonapart
[ISO 98] ISO Organization:DIN EN ISO 9241/11. Ergonomische Anforderungen f¨
ur B¨
urot¨
a-
tigkeiten mit Bildschirmger¨
aten - Teil 11: Anforderungen an die Gebrauchstauglichkeit.
Version: 1998. http://www.iso.org. – Online Ressource
[ISO 06] ISO Organization:International Organization for Standardization (Website).
Version: 2006. http://www.iso.org. – Online Ressource, Abruf: 01.02.2006
[ITU-91] ITU-TS International Telecommunications Union - TeleServices:Recom-
modation Z.120/92: Message Sequence Chart
[Jabl01] Jablonski, Stefan: Prozessorientiertes Wissensmanagement. In: KnowTech 2001
(2001), November. http://www.prodato.de/presentation/knowtech2001.pdf. –
Online Ressource, Abruf: 05.02.2006
[Jaco03] Jacobsen, Jens: Usability-Normen. Version: Januar 2003. http://www.
contentmanager.de/magazin/artikel_582-199_usability_normen_din_iso.
html. – Online Ressource, Abruf: 01.02.2006
[JK01] Junginger, S. ; Karagiannis, D.: Entwicklung von Workflow-Anwendungen. In:
WISU - Das Wirtschaftsstudium (2001), M¨
arz, S. pp. 346–354
[KDV02] Koning, Henk ; Dormann, Claire ; Vliet, Hans van: Practical guidelines for the
readability of IT-architecture diagrams. In: SIGDOC 2002 - 20th Annual International
Conference on Documentation, 2002, S. pp. 90–99
[KJS96] Karagiannis, D. ; Junginger, S. ; Strobl, R.: Business Process Modeling. (1996),
S. pp. 81–106
[KK01] K¨
uhn, H. ; Karagiannis, D.: Modellierung und Simulation von Gesch¨
aftsprozessen.
In: WISU - Das Wirtschaftsstudium 30 (2001), August, S. pp. 1161–1170
[Klot04] Klotz, Achim: View-Unterst¨
utzung in Prozess-Management-Systemen, Universit¨
at,
Ulm, Diplomarbeit, Oktober 2004
[LLW+01] Luttighuis, Paul O. ; Lankhorst, Marc ; Wetering, Rob van d. ; Bal, Ren´e
;Berg, Harmen van d.: Visualising business processes. In: Computer Languages
Vol. 27 (2001), April–Oktober, Nr. 1–3, pp. 39–59. http://www.niii.ru.nl/~erikp/
Lectures.dir/MvO/2004/Testbed2.pdf. – Online Ressource, Abruf: 24.06.2005. –
ISSN 0096–0551
[LM04] Lai, Maggie B. ; Muehlen, Michael zur: Information Requirements of Process Stake-
holders: A Framework to Evaluate Process Monitoring and Controlling Applications.
In: Proceedings of the Pre-ICIS workshop on Process Management. J. Akoka and I.
Comyn-Wattiau and M. Favier
[LR99] Leymann, Frank ; Roller, Dieter: Production Workflow: Concepts and Techniques.
1. Prentice Hall PTR, 1999. – ISBN 0130217530
[Maps06] Mapsolute GmbH:Map24.de - Routenplaner und Stadtpl¨
ane (Website).
Version: 2006. http://www.map24.de/. – Online Ressource, Abruf: 30.01.2006
153
B. Literaturverzeichnis
[Miha05] Mihalca, Tiberius: Prozessdatenintegration und -transformation f¨
ur die system¨
uber-
greifende Visualisierung von Arbeitsabl¨
aufen, Universit¨
at, Ulm, Diplomarbeit, Novem-
ber 2005
[Mill56] Miller, George: The magic number seven, plus or minus two: Some limits on our
capacity for processing information. In: Psychological Review (1956)
[Mill68] Miller, Robert B.: Response time in man-computer conversational transactions. In:
Proc. AFIPS Fall Joint Computer Conference, 1968
[MR04] Mutschler, Bela ; Reichert, Manfred: Usability-Metriken als Nachweis der
Wirtschaftlichkeit von Verbesserungen der Mensch-Maschine-Schnittstelle. In:
14th International Workshop on Software Measurement, DASMA Metrik Kongress
(IWSM’04/Metrikon2004). Berlin, November 2004
[Niel01] Nielsen, Jacob: useit.com: Jakob Nielsen’s Website. Version: November 2001. http:
//www.useit.com/about/nographics.html. – Online Ressource, Abruf: 03.08.2005
[NIST93a] NIST National Institute of Standards and Technology:FIPS Federal Infor-
mation Processing Standards Publication 183, Integration Definition for Function Mo-
delling (IDEF0). Version: Dezember 1993. http://www.idef.com/pdf/idef0.pdf. –
Online Ressource, Abruf: 9.1.2006
[NIST93b] NIST National Institute of Standards and Technology:FIPS Federal In-
formation Processing Standards Publication 184, Integration Definition for Functi-
on Modelling (IDEF1x). Version: Dezember 1993. http://www.4dcompanion.com/
downloads/standards/IDEF1X.pdf. – Online Ressource, Abruf: 9.1.2006
[NM94] Nielsen, Jakob ; Mack, R.L.: Usability Inspection Methods. John Wiley & Sons
http://www.useit.com/papers/heuristic/heuristic_list.html
[Omg 05a] Omg Organization:Object Management Group (Website). Version: 2005. http:
//www.omg.org. – Online Ressource, Abruf: 27.10.2005
[Omg 05b] Omg Organization:Unified Modeling Language (UML) v2.0. Version: 2005.
http://www.omg.org/technology/documents/formal/uml.htm. – Online Ressour-
ce, Abruf: 27.10.2005
[orea04] oreas GmbH:oreas (Website). Version: 2004. http://www.oreas.com/. – Online
Ressource, Abruf: 07.02.2006
[Park05] Parkinson, Cyril N.: Zitat. Encyclopaedia Britannica Online. Version: M¨
arz 05.
http://www.britannica.com/eb/article?tocId=9058517. – Online Ressource, Ab-
ruf: 22.03.2005
[Peis05] Peisl, Roland: Delivering on demand business agility with business process ma-
nagement. White paper (G325-1999-02). IBM Software Group. Version: Januar
2005. http://www.elink.ibmlink.ibm.com/public/applications/publications/
cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=G325-1999-02#. – Online Ressource, Abruf:
03.02.2006
[PR94] Palmer, S. E. ; Rock, I.: Rethinking perceptual organization: The role of uniform
connectedness. In: Psychonomic Bulletin and Review Vol. 1 (1994), S. pp. 29–55
[RBRB06] Rinderle, Stefanie ; Bobrik, Ralph ; Reichert, Manfred ; Bauer, Thomas: Busi-
ness Process Visualization - Use Cases, Challenges, Solutions. In: 8th International
Conference on Enterprise Information Systems (ICEIS’06). Paphos, Cyprus, Mai
2006. – to appear
[RD98] Reichert, Manfred ; Dadam, Peter: ADEPTflex - Supporting Dynamic Changes of
Workflows Without Losing Control. In: Journal of Intelligent Information Systems
Vol. 10 (1998), M¨
arz-April, Nr. 2, pp. 93-129. http://www.informatik.uni-ulm.de/
dbis/01/dbis/downloads/ReDa98.pdf. – Online Ressource, Abruf: 27.01.2006
154
B. Literaturverzeichnis
[RD00] Reichert, Manfred ; Dadam, Peter: Gesch¨
aftsprozeßmodellierung und Workflow-
Management-Konzepte, Systeme und deren Anwendung. In: Industrie Management
Vol. 3 (2000), pp. 23-27. http://www.informatik.uni-ulm.de/dbis/01/dbis/
downloads/ReDa00.pdf. – Online Ressource, Abruf: 29.01.2006
[Rein93] Reinwald, Berthold: Workflow-Management in Verteilten Systemen. Stuttgart :
Teubner, 1993
[RH00] Rudolf, Hartmut ; Hallenberger, Brigitte: Tutorial: Farben im Webdesign (Web-
site). Version: 2000. www.metacolor.de/farbwaehler_AuffaecherungenOLD.htm. –
Online Ressource, Abruf: 08.08.2005
[Rind04] Rinderle, Stefanie: Schema Evolution in Process Management Systems, Universit¨
at,
Ulm, Diplomarbeit, 2004
[RR03] Reichert, Manfred ; Rinderle, Stefanie: ADEPT - Prozess-Management-
Technologie der n¨
achsten Generation. Abteilung Datenbanken und Informationssys-
teme, Universit¨
at Ulm
[RS56] Ryan, T.A. ; Schwartz, C.B.: Speed of perception as a function of mode of represen-
tation. In: American Journal of Psychology Vol. 69 (1956), S. pp. 60–69
[Sche01] Scheer, August-Wilhelm: ARIS - Modellierungsmethoden, Metamodell, Anwendun-
gen. 4. Auflage. Berlin : Springer, 2001
[Sche02] Scheer, August-Wilhelm: ARIS - Vom Gesch¨
aftsprozess zum Anwendungssystem. 4.
Auflage. Berlin : Springer, 2002. – ISBN 3–540–63835–0
[Schu05] Schuhmacher, Joachim: Usability (Website). Version: 2005. http://www.
multimedia-beratung.de/ergonomie/theorie/grundlagen/usability.htm. – On-
line Ressource, Abruf: 26.10.2005
[Schw03] Schwab, J.: Gesch¨
aftsprozessmanagement mit Visio, ViFlow und MS Project. Hanser
Fachbuch, 2003
[SH99] Scheer, August-Wilhelm ; Hoffmann, Michael: From Business Process Model to
Application System - Developing an Information System with the House of Business
Engineering (HOBE). In: Int’l Conf. on Advanced Information Systems Engineering,
Heidelberg Vol. 1626 (1999), Juni, S. pp. 2–9. – ISSN 0302–9743
[SP05] Shneiderman, Ben ; Plaisant, Catherine: Designing the User Interface: Fourth
Edition Strategies for Effective Human-Computer Interaction. Boston, MA, USA :
Addison-Wesley Longman Publishing Co., Inc., 2005. – ISBN 0–321–26978–0
[Spal05] Spall, Andreas: Einf¨
uhrung in BPEL4WS. Orientations in Objects GmbH.
Version: April 2005. http://www.oio.de/public/xml/einfuehrung-in-bpel4ws.
htm. – Online Ressource, Abruf: 06.02.2006
[This00] Thissen, Frank: Screen Design Handbuch. Berlin : Springer Verlag, 2000. – ISBN
3–540–64804–6
[Togn92] Tognazzini, Bruce: Tog on Interface. Reading, MA : Addison-Wesley, 1992. – ISBN
0–201–60842–1
[Togn04] Tognazzini, Bruce: First Principles of Interaction Design. Version: 2004. http:
//www.asktog.com/basics/firstPrinciples.html. – Online Ressource, Abruf:
28.01.2006
[Ulti02] Ultimus:Ultimus Workflow Suite 4 - Product Guide. Version: Juli 2002. http:
//www.quixa.com/library/docs/QSLIB-ULT-101.pdf. – Online Ressource, Abruf:
07.02.2006
155
B. Literaturverzeichnis
[W3C 06a] W3C World Wide Web Consortium:Scalable Vector Graphics (SVG).
Version: 2006. http://www.w3.org/Graphics/SVG/. – Online Ressource, Abruf:
01.02.2006
[W3C 06b] W3C World Wide Web Consortium:W3C Web Content Accessibility Guidelines
2.0. Version: Januar 2006. http://www.w3.org/WAI/GL/WCAG20/. – Online Ressource,
Abruf: 01.02.2006
[Ware00] Ware, Colin: Information Visualization. San Diego, CA : Academic Press, 2000. –
ISBN 1–55860–511–8
[Wert12] Wertheimer, Max: Experimentelle Studien ¨
uber das Sehen von Bewegung. In: Zeit-
schrift f¨
ur Psychologie Vol. 61 (1912), S. pp. 161–265
[WfMC99] WfMC Workflow Management Coalition:Interface 1: Process Definition
Interchange Process Model. Workflow Management Coalition. Version: Oktober
1999. http://www.wfmc.org/standards/docs/TC-1016-P_v11_IF1_Process_
definition_Interchange.pdf. – Online Ressource, Abruf: 24.10.2005
[Whit04] White, Stephen A.: Process Modeling Notations and Workflow Patterns. In: The
Workflow Handbook 2004 (2004). http://www.omg.org/bp-corner/pmn.htm. – On-
line Ressource, Abruf: 18.12.2005
[Will94] Williams, Robin: The Non-Designer’s Design Book. Peachpit Press, 1994
[Will00] Williams, Thomas R.: Guidelines for Designing and Evaluating the Display of In-
formation on the Web. In: Technical Communication Vol. 47 (2000), August, Nr.
3
[yWor06a] yWorks GmbH:yFiles API Dokumentation (Website). Version: 2006. http://www.
yworks.com/products/yfiles/doc/api/. – Online Ressource, Abruf: 07.02.2006
[yWor06b] yWorks GmbH:yFiles (Website). Version: 2006. http://www.yworks.com/en/
products_yfiles_about.htm. – Online Ressource, Abruf: 07.02.2006
156
Danksagung
An dieser Stelle m¨
ochte ich den zahlreichen Leuten meinen Dank aussprechen, die zum Gelingen
dieser Diplomarbeit beigetragen haben. Dieser Dank geb¨
uhrt besonders:
➣An erster Stelle nat¨
urlich Elmar Schoch & Oliver Hagel, auf deren Vorarbeiten diese L
A
T
EX-
Vorlage basiert
➣Meinen Reviewern und Korrektoren Elmar Schoch, Oliver Hagel, Michael Nahler, Eduard
Horber & Gabriele Dempsey
➣Meinen Betreuern Dr. Manfred Reichert & Dipl. Inf. Ralph Bobrik f¨
ur die vielen Hinweise
und anregenden Diskussionen
➣Meinen Eltern, die maßgeblichen Anteil daran haben, das ich jetzt in der Lage bin, sie an
dieser Stelle zu erw¨
ahnen
➣Jesus Christus, ihm verdanke ich Alles, was ich bin und habe
157
Erklärung
”Ich versichere, dass ich meine Diplomarbeit ohne Hilfe Dritter und ohne Benutzung
anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten
Quellen w¨
ortlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht
habe. Diese Arbeit hat in gleicher oder ¨
ahnlicher Form noch keiner Pr¨
ufungsbeh¨
orde
vorgelegen.“
Ulm, den 20. Februar 2006
.............................................................. (Max Moldmann)
159