Analyse häufiger Fehlersituationen in
Verbindung mit Zeitbedingungen in
Prozessen
Carolin Antonie Steurer
Bachelorarbeit
Institut für Datenbanken und Informationssysteme
Universität Ulm
Prüfer: Prof. Dr. Manfred Reichert
Betreuer: Andreas Lanz
Januar 2012
Inhaltsverzeichnis
1 Einleitung 1
2 Zeitliche Vorgaben 5
2.1 Grundlagen .................................... 5
2.2 Ein Beispielprozess - OP mit Chemotherapie . . . . . . . . . . . . . . . . . 6
2.3 Zeitvorgaben ................................... 12
3 Nicht Einhalten der zeitlichen Vorgaben: Konsequenzen 17
3.1 Der Begriff der Eskalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Eskalationsbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Wer ist für die Fehlerbehandlung zuständig? . . . . . . . . . . . . . 18
3.2.2 Wie wird mit einer Eskalation umgegangen? . . . . . . . . . . . . . . 19
3.2.3 Wann wird die Fehlerbehandlung eingeleitet? . . . . . . . . . . . . . 19
4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze 21
4.1 Aktivität startet zu spät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Vorbedingung nicht erfüllt . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Ressourcen sind nicht verfügbar . . . . . . . . . . . . . . . . . . . . . 27
4.1.3 Geschäftsobjekt ist nicht bereit . . . . . . . . . . . . . . . . . . . . . 30
4.1.4 Zusammenfassung ............................ 32
4.2 Aktivität dauert zu lange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Problemursprung liegt außerhalb der betroffenen Aktivität . . . . . 33
4.2.2 Indirekte Abhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Erhöhter Arbeitsumfang . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4 Zusammenfassung ............................ 43
4.3 Aktivität endet zu spät/endet nicht . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Prozess (Instanz) ist nicht ausführbar . . . . . . . . . . . . . . . . . . . . . 43
4.4.1 Fehler im Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Prozessinstanz nicht ausführbar . . . . . . . . . . . . . . . . . . . . . 45
4.5 Fazit........................................ 47
5 Ausblick: Unterstützung bei Zeitproblemen 49
5.1 Process Aware Information Systems (PAIS) . . . . . . . . . . . . . . . . . . 49
5.2 Systemunterstützung zur Korrektheit von Prozessen . . . . . . . . . . . . . 50
5.2.1 Der Stand von Heute . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III
Kapitel 1
Einleitung
"Remember that time is money"
Benjamin Franklin (*17.01.1706-†17.04.1790)
„Zeit ist Geld“ ist ein wohlbekanntes Zitat von Benjamin Franklin, der diesen Ratschlag
im 18. Jahrhundert einem jungen Geschäftsmann mit auf den Weg gegeben hat.
Selbst dreihundert Jahre später scheint dieses Sprichwort noch von hoher Geltung zu
sein. Gerade im Geschäftsbereich lassen sich dafür zahlreiche Beispiele finden: Mitarbeiter
und Leihgeräte werden nach Zeit bezahlt, folglich steigen die Kosten mit der Dauer der
Ausführung. Jeder Auftrag benötigt eine gewisse Zeit an Bearbeitung. Kann diese Zeit
verringert werden, so kann die Zahl der ausgeführten Aufträge und damit der Gewinn
erhöht werden. Des Weiteren werden Aufträge häufig nur erteilt, wenn versichert werden
kann, dass deren Bearbeitung zu einer vorgegeben Deadline fertiggestellt ist.
Speziell im Klinikbereich hat ineffizientes Arbeiten häufig einen hohen finanziellen Ver-
lust zur Folge. Man betrachte hierzu folgende Beispielsituation: In einem kleineren Kran-
kenhaus ohne eigenes Labor werden die Blutproben der Patienten in ein externes Labor
zur Untersuchung geschickt. Das Ergebnis wird entweder zur Sicherstellung der gefahr-
losen Entlassung oder für die OP des Patienten benötigt. Diese beiden Aktionen können
somit erst dann stattfinden, wenn das Ergebnis der Blutuntersuchung bekannt ist.
Ist das besagte Krankenhaus entsprechend ländlich gelegen, so kann es sein, dass die
Blutproben für bestimmte Labore nur dreimal pro Woche abgeholt werden, zum Beispiel
montags, mittwochs und freitags um 9:00 Uhr. Die Blutabnahme findet während der Visite
zwischen 7:00 und 10:00 Uhr statt.
Man stelle sich vor, an einem Dienstag Abend wird ein Patient eingeliefert, für dessen
Befund der Arzt ein Blutergebnis benötigt. Anhand dessen wird er entscheiden, ob der
Patient entlassen werden kann oder ob er operiert werden muss.
Werden am darauffolgenden Morgen die Patienten der aufsteigenden Zimmernummer nach
untersucht und befindet sich der entsprechende Patient in dem Zimmer mit der höchsten
Nummer, so wird ihm die Blutprobe erst um 10:00 Uhr entnommen und er muss zwei
1
21 Einleitung
zusätzliche Tage im Krankenhaus versorgt werden, bis sein Blut (am Freitag) untersucht
werden kann. Das Ausmaß der hierbei unnötig entstehenden Kosten liegt auf der Hand.
Der beschriebene Fall könnte durch den Einsatz eines guten Prozessmanagementsystems
verhindert werden. Ein Prozessmanagementsystem (PMS) ist ein Softwaresystem, mit des-
sen Hilfe Geschäftsprozesse, in denen Daten, Informationen und Aufgaben nach feststehen-
den Regeln von einem Bearbeiter zum anderen gereicht werden, vollständig oder teilweise
automatisiert werden [SMO99]. Dafür werden die einzelnen Arbeitsschritte des Prozesses
verschiedenen Aktivitäten zugewiesen. Die jeweiligen Aktivitäten können aus nur einem
einzigen Arbeitsschritt (atomare Aktivitäten) oder aus mehreren zusammengefassten Ar-
beitsschritten bestehen. Gibt es eine Deadline für den Gesamtprozess, so lassen sich anhand
dieser, der Dauer der einzelnen Aktivitäten und weiterer zeitlicher Einschränkungen die
Reihenfolge der Aktivitäten bestimmen und Deadlines für jede einzelne Aktivität berech-
nen. Mittels all den genannten Informationen kann ein Prozessmodell aufgestellt werden,
das den Ablauf des Prozesses schematisch wiedergibt.
Im beschriebenen Beispiel muss die Blutprobe um 9:00 Uhr zur Abholung bereitliegen,
damit sie noch am selben Tag ins Labor gebracht wird. Es werden zehn Minuten benötigt,
um das Blut ordnungsgemäß zu verpacken und zu beschriften. Aus diesen Zeitbeschrän-
kungen lässt sich die Deadline für die Aktivität „Blutabnahme“ ableiten und wird somit
auf 8:50 Uhr gesetzt. Entsprechend müssen die restlichen Aktivitäten angepasst werden
(im oben beschriebenen Fall würde dies eine andere Reihenfolge der zu untersuchenden
Patienten bedeuten). Wird die Deadline überschritten, so sollte das Prozessmanagement-
system entsprechend reagieren.
Aus dem beschriebenen Beispiel geht die Bedeutung des Einsatzes von Prozessmana-
gementsystemen hervor, wobei die Auseinandersetzung mit Zeit und Zeitbeschränkun-
gen ein wesentlicher Bestandteil beim Entwurf und Management von Geschäftsprozessen
ist [EPR99].
Der Einsatz von Prozessmanagementsystemen bringt gerade im Hinblick auf die vorgege-
benen Zeitbedingungen und -beschränkungen auch Probleme mit sich, die eine große Her-
ausforderung darstellen. Speziell durch zeitliche Aspekte erhält ein Prozessmodell einen
dynamischen Anteil, welcher das Modell selbst realistisch und damit attraktiv macht, je-
doch sehr schwierig zu automatisieren ist. Somit stellt sich die Frage, in wie weit die
Automatisierung von Prozessen eine Hilfe und in wie fern sie eher eine Einschränkung
darstellt. Eine Gefahr der Einschränkung besteht, weil Prozesse zum Teil ihrer Flexibili-
tät beraubt werden. In Folge dessen muss der Vorüberlegung und Analyse zum Umgang
mit Zeitaspekten eine außerordentlich hohe Bedeutung zugeordnet werden, damit diese
sinnvoll vom System behandelt werden können und das System auch tatsächlich zur Leis-
tungssteigerung beiträgt.
Ziel dieser Arbeit ist es, möglichst flächendeckende Lösungsansätze für die Verletzung
sämtlicher Zeitprobleme, wie sie in Kapitel 2 anhand eines klinischen Beispielprozesses
erläutert werden, zu finden. Kapitel 3 gibt eine Übersicht, was genau bei der Verletzung
einer Zeitvorgabe geschieht, zudem wird der zugehörige Begriff „Eskalation“ eingeführt. In
wie fern diese verletzten Zeitvorgaben entstehen können und wie man mit diesen Verlet-
3
zungen umgehen oder sie sogar verhindern kann, wird in Kapitel 4 erläutert. Dazu werden
die auftretenden Fehler nach ausgewählten Kriterien gruppiert.
Sind die theoretischen Lösungen gefunden, so stellt sich die Frage nach der praktischen
Umsetzung. In Kapitel 5 werden zunächst Möglichkeiten zur Unterstützung bei zeitbeding-
ten Problemen vorgestellt und daraufhin die heutigen Möglichkeiten den Wunschvorstel-
lungen gegenübergestellt und dadurch die Bedeutung des Titels „Klinikbezogene Prozess-
systeme sind „Killer-Anwendungen“ für Prozessmanagementsysteme nach dem heutigen
Standard“ [DRK97] einer im Jahre 1997 erschienen Veröffentlichung erörtert.
Kapitel 2
Zeitliche Vorgaben
Prozessmanagementsysteme sind regelbasierte Systeme. Das bedeutet, es sind klar defi-
nierte Regeln vorgegeben (wie zum Beispiel die Ausführungsreihenfolge der Aktivitäten,
Abstände zwischen den einzelnen Aktivitäten, Zeiten, zu denen ein bestimmter Abschnitt
des Prozesses beendet sein muss, etc.), die beim Entwurf und bei der Ausführung des Pro-
zesses eingehalten werden müssen [SW95]. In diesem Kapitel werden als spezielle Regeln
verschiedene Arten von zeitlichen Vorgaben vorgestellt, von denen eine große Artenvielfalt
existiert [LWR10].
Im Folgenden werden die wichtigsten Zeitbedingungen vorgestellt, welche für die Gruppie-
rung der in Kapitel 4 betrachteten Problemsituationen verwendet werden. Diese werden
zunächst anhand eines Beispielprozesses vorgestellt und anschließend genauer beschrieben.
2.1 Grundlagen
Wie schon in Kapitel 1 beschriebenen, werden bei der Prozessmodellierung die einzel-
nen Arbeitsschritte in verschiedene Aktivitäten aufgeteilt. Eine Aktivität kann aus nur
einem einzigen Arbeitsschritt (in diesem Fall wird sie als atomare Aktivität bezeichnet)
oder aus mehreren Arbeitsschritten bestehen. Zudem kann eine einzelne Aktivität auch
einen Subprozess darstellen, der wiederum mehrere Aktivitäten beinhaltet. Anhand des in
Abbildung 2.1 beschriebenen Prozessmodells von Prozess P werden im Folgenden einige
Grundlagen der Notation BPMN 1.2 [ORS03] erläutert.
Mit Hilfe des Start-Ereignisses wird der Start des Prozesses identifiziert. In Folge dessen
ist Aktivität A die erste Aktivität, die in P zur Ausführung kommt. Anschließend folgt ein
exklusives Gateway. Abhängig vom Verlauf von Aktivität A wird nach deren Beendigung
entweder Aktivität B oder Aktivität C gestartet. Nach Abschluss dieser Aktivität folgt ein
paralleles Gateway: Aktivität D und Aktivität E werden gleichzeitig gestartet. Während
der Ausführung von Aktivität E werden Daten erstellt, die in Aktivität F benötigt wer-
den. Aktivität F kann dann starten, wenn die benötigten Daten aus Aktivität E vorhanden
5
62 Zeitliche Vorgaben
sind. Prozess P kann genau dann enden, wenn sowohl Aktivität F, als auch Aktivität D
abgeschlossen worden sind. Ein eintretendes Nachrichtenereignis, wie es in Aktivität F
vorkommt kann auch bei einem exklusiven Gateway als entscheidendes Element benutzt
werden (je nach Dateninhalt wird der eine oder der andere Pfad eingeschlagen).
Anhand von Prozess P wurden nun diejenigen Bestandteile eines Prozessmodells disku-
tiert, die im Folgenden benutzt und von Bedeutung sein werden.
Grundlagen kurz
Start- Ereigns
Aktivität A Exklusives Gateway
Aktivität C
Aktivität B
Paralleles Gateway
Aktivität D
Aktivität E
End- Ereignis
Eintre-
tendes Nach-
richten
Ereignis
Aktivität F
Carolin Steurer 1 von 1 20.01.2012
Abbildung 2.1: Beispielprozess P
2.2 Ein Beispielprozess - OP mit Chemotherapie
Man führe sich folgendes Szenario aus dem Gesundheitswesen vor Augen [Mey96], welches
in die beiden Prozesse „Prozess Tumorektomie“ und „Prozess Chemotherapie“ unterteilt
ist:
Prozess Tumorektomie
Bei einem routinemäßigen Arztbesuch einer Frau wird ein Verdacht auf Brustkrebs festge-
stellt, woraufhin die Patientin in eine Klinik überwiesen wird (siehe Abbildung 2.2). Nach
der Vereinbarung eines Aufnahmetermins wird die Patientin in der Klinik aufgenommen
(hierbei werden einige Formalien geklärt und der bisherige Krankheitsverlauf der Patientin
besprochen). Aufgrund der Richtlinien des Krankenhauses muss diese Patientenaufnahme
maximal drei Wochen nach der Überweisung stattfinden.
Ist die Patientin in die Klinikkartei aufgenommen, so wird eine diagnostische Untersuchung
vorbereitet, die an einem Termin, der bei der Aufnahme vereinbart wurde, stattfindet. In
dieser diagnostischen Untersuchung wird die Patientin von einem zuständigen Arzt unter-
sucht. Dabei wird unter anderem eine Blutprobe entnommen, eine MRT durchgeführt und
wenn nötig Impfungen aufgefrischt. Die Blutprobe wird ein das Labor geschickt, wobei
das Ergebnis bis zur OP-Vorbereitung vorliegen muss.
Die OP-Vorbereitung ist zweigeteilt in die Patientenvorbereitung und die Vorbereitung
des OP-Saals (in Abbildung 2.4 als Subprozess dargestellt). Letzterer muss bis um 14 Uhr
am Tag vor der OP bei der zuständigen Schwester reserviert werden und bis zum Start
der OP gereinigt und mit den notwendigen Mitteln ausgestattet sein. Vor der OP werden
2.2 Ein Beispielprozess - OP mit Chemotherapie 7
der Patientin evtl. notwendige Medikamente zugeführt (je nach Ergebnis der Blutunter-
suchung) und sie wird narkotisiert. Dies findet im OP-Saal statt, das heißt der OP-Saal
muss bis zur Patientenvorbereitung zur Verfügung stehen. Da die Patientin nicht beliebig
lang in der Narkose liegen darf, muss die OP maximal 30 Minuten nach Ende der Pati-
entenvorbereitung beginnen. Um die Wirkung der Narkose sicherzustellen, müssen jedoch
mindestens 10 Minuten Abstand zum Start der OP bleiben.
Auf die OP selbst folgt die OP-Nachbereitung, welche in drei Teile gegliedert ist (in Ab-
bildung 2.5 als Subprozess dargestellt): Die Zuführung geeigneter Schmerzmittel, die post-
operative Versorgung auf der Intensivstation und die anschließende stationäre Pflege. Die
stationäre Pflege ist beendet, wenn die Schmerzen der Patientin soweit abgesunken sind,
dass die Schmerzmittel abgesetzt werden können.
Der Prozess dieser OP ist somit abgeschlossen. Aus finanziellen Gründen sollte dieser Ab-
schluss spätestens 3 Monate nach der Patientenaufnahme stattfinden. Trifft dieser Zeit-
punkt nicht zufällig das Ende eines Quartals, so kann die Zeit bis zum Ende des Quartals
zusätzlich für den Prozess genutzt werden.
Prozess Chemotherapie
Nach dieser OP folgt bei der Patientin der Prozess der Chemotherapie (siehe Abbildung
2.3). Die erste Chemotherapie darf frühstens vier Wochen nach einer OP stattfinden (das
hat einen Minimalabstand von vier Wochen zwischen den beiden Prozessen zur Folge).
Die gesamte Therapie hat eine Dauer von acht Wochen. Anschließend findet eine Unter-
suchung statt. Der Hausarzt der Patientin muss innerhalb von zehn Tagen nach dieser
Untersuchung einen Brief mit den aktuellen Daten der Patientin erhalten.
Auf die Untersuchung folgt eine weitere (kleinere) OP, bei der der Patientin Gewebepro-
ben entnommen werden. Vor der OP gibt es wieder eine OP-Vorbereitung und danach eine
OP-Nachbereitung. Diese beiden Aktivitäten enthalten die gleichen Schritte wie zuvor be-
schrieben. Nach der OP wird das Gewebe zur Untersuchung an das Labor geschickt. Ist
der Befund von der Untersuchung des Gewebes negativ, so endet der Prozess. Andernfalls
wird eine weitere Chemotherapie durchgeführt. Dieser Zyklus darf maximal drei Mal wie-
derholt werden.
Betrachtet man die Darstellung der Prozesse in den gegebenen Abbildungen, so ha-
ben diese (gegenüber der textuellen Beschreibung) den Vorteil, dass nichts „überlesen“
werden kann. Die Abhängigkeiten werden übersichtlich dargestellt. Der Nachteil dieser
Darstellung ist, dass Informationen verloren gehen, wie zum Beispiel die Begründungen
für die Abhängigkeiten. Man betrachte zum Beispiel die Vorgabe, dass die OP maximal
30 Minuten nach der OP-Vorbereitung begonnen werden darf. Die Begründung für diese
Bedingung ist die Wirkung der Narkose. Ist dies bekannt und tritt der Fall ein, dass die
OP erst nach 40 Minuten starten kann, so kann dafür gesorgt werden, dass die Narkose der
Patientin später verabreicht wird (was natürlich die Dauer der OP-Vorbereitung erhöht
aber das Problem lösen kann).
Weder in der textuellen Beschreibung der Prozesse, noch in deren Abbildung wird die
82 Zeitliche Vorgaben
Dauer jeder einzelnen Aktivitäten explizit dargestellt. Diese ergeben sich entweder durch
die fixen Deadlines oder Termine oder sie sind zusätzlich festgelegt. Zum Beispiel ist die
Dauer einer diagnostischen Untersuchung aus finanziellen Gründen auf eine Stunde be-
schränkt. Da der OP-Saal ständig benötigt wird, ist auch die Dauer der OP durch die
nachfolgende Reservierung beschränkt.
Insgesamt lassen sich aus diesem Beispielprozess schon einige zeitliche Vorgaben herausle-
sen, die im Folgenden zusammengetragen werden.
2.2 Ein Beispielprozess - OP mit Chemotherapie 9
OP
Patient in
Klinik über-
weisen
Aufnahme-
termin
vereinbaren
Patienten-
aufnahme
Planung der
diagnos-
tischen Unter-
suchung
Diagn. Unter-
suchung:
MRT, Blutab-
nahme
Blut-
unter-
suchung
OP-
Vorbereitung
OP
OP-
Nach-
bereitung
min 10Min,
max 30Min
max{3 Monate nach
Patientenaufnahme,
Quartalende}
max. 3 Wochen
Carolin Steurer 1 von 1 20.01.2012
Abbildung 2.2: Prozess Tumorektomie
10 2 Zeitliche Vorgaben
Chemo
Durchführung
Chemo
Untersuchung
Brief an
Hausarzt
OP-
Vorbereitung
OP
(Gewebe-
entnahme)
OP- Nach-
bereitung Gewebeprobe
untersuchen
maximal
10Tage
Befund positiv
min 10Min
max 30MIn
Befund negativ
Mindesabstand
zur letzten OP:
4 Wochen
Carolin Steurer 1 von 1 22.01.2012
Abbildung 2.3: Prozess Chemotherapie
2.2 Ein Beispielprozess - OP mit Chemotherapie 11
OP-Vorbereitung
OP- Vorbereitung
Vorbereitung
OP- Saal
Vorbereitung
des
Patienten
Saal bis 14 Uhr
am Tag vor der
OP buchen
Carolin Steurer 1 von 1 16.01.2012
Abbildung 2.4: Subprozess OP-Vorbereitung
OP-Nachbereitung
OP- Nachbereitung
Patienten mit
Schmerz-
mitteln
versorgen
Postoperative
Versorgung
auf Intensiv-
station
Solange
Schmerzmittel
nötig, muss
stationäre
Pflege anhalten
Stationäre
Pflege
Carolin Steurer 1 von 1 16.01.2012
Abbildung 2.5: Subprozess OP-Nachbereitung
12 2 Zeitliche Vorgaben
2.3 Zeitvorgaben
Um Probleme bzgl. zeitlicher Vorgaben beheben oder verhindern zu können, müssen zu-
nächst die zeitlichen Vorgaben bekannt sein. Diese werden in den folgenden Abschnitten
diskutiert.
Zunächst wird zwischen absoluten und relativen Vorgaben unterschieden. Absolute Vor-
gaben sind zum Beispiel Vorgaben für die Dauer einer Aktivität oder explizit gegebene
Termin, die eingehalten werden müssen, wie zum Beispiel die Deadline einer Aktivität
oder eines Prozesses [CGJ+07].
In Prozessmodellen treten darüber hinaus relative Zeitbedingungen auf, die in den einzel-
nen Instanzen indirekt zu fixen Terminen führen. Ein Beispiel hierfür ist folgendes: Die
OP-Vorbereitung muss zwischen 10 und 30 Minuten vor der OP enden. Für die OP selbst
ist ein fester Termin angesetzt. Sei dieser am 15.04.2012 um 9:00 Uhr. Mit dieser Angabe
wird aus der relativen Vorgabe, dass die OP-Vorbereitung 10 bis 30 Minuten vor der OP
enden muss, eine absolute Vorgabe: Die OP-Vorbereitung muss am 14.04.2012 zwischen
8:30 und 8:50 Uhr enden.
Bei der Ausführung einzelner Prozessinstanzen gilt es also, feste Termine einzuhalten, die
entweder im Voraus schon fest angesetzt waren, sich durch relative Abhängigkeiten erge-
ben haben oder während des Prozesses festgesetzt wurden.
Eine detaillierte Darstellung zeitlicher Bedingungen mit einer Vielzahl an Beispielen lässt
sich in [LWR10] finden. An dieser Stelle soll nur ein kurzer Überblick über die für diese
Arbeit relevanten Zeitvorgaben gegeben werden.
Absolute Zeitvorgaben
Bei absoluten Zeitangaben kann der exakte Zeitpunkt beim Start des Prozesses gesetzt
werden. Dazu sei folgendes Beispiel gegeben: Möchte man eine Anzeige in eine Wochenzei-
tung stellen, so muss diese am vorangehenden Dienstag um 8:00 Uhr eingereicht worden
sein. Beim Start des Prozesses ist klar, an welchem Datum die Anzeige erscheinen soll und
somit auch das Datum für den Dienstag, an dem die Anzeige eingereicht sein muss. In
Tabelle 2.1 sind verschiedene Arten von absoluten Zeitangaben aufgelistet. Man beachte,
dass die Dauer zwar eine absolute Angabe ist, jedoch stellt sie eine relative Angabe für
den Endzeitpunkt dar.
2.3 Zeitvorgaben 13
Tabelle 2.1: Absolute Zeitvorgaben
Zeitvorgabe Erläuterung / Beispiel
Deadline für Gesamtprozess Prozess muss bis Ende des Jahres abgeschlossen
sein, damit ergibt sich die Deadline: 31. Dezem-
ber
Deadline für einzelne Aktivität Aktivität muss innerhalb eines Tages / bis zu ei-
nem vorgegebenen Zeitpunkt (Datum und Uhr-
zeit) beendet sein
Starttermin für Prozess Prozess muss zu einem bestimmten Datum star-
ten
Starttermin für einzelne Aktivität Aktivität muss zu einem bestimmten Datum
starten
Dauer des Prozesses die Dauer des Prozesses ist entweder exakt
vorgegeben (Masterarbeit: 6 Monate. Mit dem
Start der Arbeit lässt sich eine absolute Deadli-
ne errechnen), nach oben beschränkt oder es ist
eine Zeitspanne angegeben
Dauer einer Aktivität die Dauer der Aktivität ist entweder exakt vor-
gegeben, nach oben beschränkt oder es ist eine
Zeitspanne angegeben
Relative Zeitvorgaben
Wie oben genannt, geben relative Zeitvorgaben keinen konkreten Zeitpunkt vor sondern
viel mehr eine Abhängigkeit. In Tabelle 2.2 werden vier verschiedene Arten von relativen
Zeitvorgaben mit zugehörigen Beispielen in Abbildung 2.6 eingeführt.
Tabelle 2.2: Relative Zeitvorgaben
Zeitvorgabe Erläuterung / Beispiel
Start-Start-Beziehung Aktivität darf frühstens dann starten, wenn ab-
hängige Aktivität gestartet ist
Start-Ende-Beziehung Aktivität darf frühestens dann enden, wenn ab-
hängige Aktivität gestartet ist
Ende-Start-Beziehung Aktivität darf frühestens dann starten, wenn ab-
hängige Aktivität beendet ist
Ende-Ende-Beziehung Aktivität darf frühestens dann enden, wenn ab-
hängige Aktivität beendet ist
14 2 Zeitliche Vorgaben
Beziehungen
AB
C D
E F
G H
Ende- Start- Beziehung
Ende- Ende- Beziehung
Start- Start- Beziehung
Start- Ende- Beziehung
Carolin Steurer 1 von 1 20.01.2012
Abbildung 2.6: Skizzierung von Abhängigkeiten zwischen zwei Aktivitäten
Man beachte, dass zu jeder der in Tabelle 4.1 und Abbildung 2.6 aufgeführten Zeit-
bedingung zusätzlich ein Mindestabstand und/oder ein Maximalabstand angegeben sein
kann, der eingehalten werden muss: Bei der Start-Start-Beziehung bedeutet ein Mindestab-
stand von einer Stunde, dass Aktivität B erst eine Stunde nachdem Aktivität A gestartet
ist, gestartet werden darf. Ist kein solcher Mindestabstand gegeben, so darf Aktivität B
starten, sobald Aktivität A gestartet wurde. Eine Ende-Start-Beziehung mit einem Min-
destabstand von einer Stunde und einem Maximalabstand von zwei Stunden hätte hier
zur Folge, dass Aktivität F frühestens eine Stunde nachdem Aktivität E beendet worden
ist, gestartet werden darf und spätestens zwei Stunden nach dem Beenden von Aktivität E
gestartet werden muss. Gleichermaßen lässt sich das auf jede der genannten Beziehungen
übertragen.
Man verdeutliche sich, dass die Ende-Ende-Beziehung und die Start-Start-Beziehung beid-
seitig existieren können: Die Aktivitäten müssen dann gleichzeitig starten oder gleichzeitig
enden.
Weitere Zeitangaben
Vergleicht man die bisher aufgeführten Zeitangaben mit den vorkommenden in Kapitel
2.2, so fällt auf, dass noch nicht alle Zeitangaben aus dem beschriebenen Klinikprozess
erläutert worden sind. Bisher wurden diejenigen genannt, die in den graphischen Ab-
bildungen des Prozessmodells abgebildet sind, wie die Reihenfolge der Aktivitäten und
maximale/minimale Abstände zwischen den einzelnen Aktivitäten.
Die folgenden Zeitangaben ergeben sich größtenteils aus den örtlichen Begebenheiten.
An dieser Stelle sei besonders die Aktivität „diagnostische Untersuchung“aus Kapitel 2.2
beachtet. In einer Klinik sind nur begrenzt viele Röntgengeräten vorhanden, in diesem
Beispiel sei dies auf ein einziges beschränkt, was zur Folge hat, dass zu einem Zeitpunkt
nur eine Patientin geröntgt werden kann.
Des Weiteren dürfen einer Patientin an einem Tag nicht beliebig viele Impfungen zugeführt
2.3 Zeitvorgaben 15
werden. Das bedeutet, die Zeitpunkte der Impfungen müssen protokolliert und abgeglichen
werden.
Zusätzlich wird der Patientin eine Blutprobe entnommen, welche ins Labor geschickt wird
und bis zur OP-Vorbereitung ausgewertet sein muss. Die Öffnungszeiten des Labors sind
jedoch beschränkt. Das heißt, diese müssen bei der Planung mitberechnet werden. Werden
für die Blutauswertung selbst drei Stunden benötigt und hat das Labor nur von 8:00 - 17:00
Uhr geöffnet, so muss berüchtigt werden, dass die Blutprobe evtl. am Tag vor der OP-
Vorbereitung im Labor vorliegen muss (möglicherweise kommt noch eine Transportzeit
des Blutes von hinzu).
Am Wochenende ist das Labor mit weniger Personal besetzt als unter der Woche. Es soll
hauptsächlich für Notfälle bereitstehen, welche in gegebenen Fällen auch Vorrang haben.
Ist die OP-Vorbereitung auf einen Montag um 8.00 Uhr angesetzt, so sollte die Blutprobe
spätestens am Freitag im Labor eingetroffen sein. Ist das Labor dennoch überlastet, so
haben dringendere Fälle Vorrang. Dies zeigt, dass bei begrenzter Zeit (bzw. begrenzten
Ressourcen) Aufgaben nach Prioritäten geordnet werden können. Im klinischen Bereich
sind solche Prioritäten zum Beispiel durch Notfälle gegeben.
Kapitel 3
Nicht Einhalten der zeitlichen Vorgaben:
Konsequenzen
In Kapitel 2 wurden bestimmte Zeitvorgaben anhand einiger Beispielprozesses erläutert.
Sei nun angenommen, dass aus verschiedenen Gründen eine dieser zeitlichen Vorgaben
nicht eingehalten werden kann. Dabei stellt sich die Frage, wie die Folgen einer solchen
Verletzung einer Zeiteinschränkung aussehen. Muss der gesamte Prozesse abgebrochen
werden oder gibt es Möglichkeiten, den Fehler zu behandeln? In diesem Kapitel wird
die direkte Reaktion auf eine verletzte Zeitbedingung im Prozess diskutiert: Was löst ein
solcher Fehler im Prozess aus? Wie wird dieser Fehler entdeckt? Wie kann mit solch einem
Fehler umgegangen werden? Wer ist für diese Fehlerbehandlung zuständig?
3.1 Der Begriff der Eskalation
Wird eine Fehlerbehandlung für die Verletzung von (zeitlichen) Vorgaben eines Prozesses
aufgerufen, so spricht man von Eskalation: Der eingetretene Fall ist nicht im ursprüngli-
chen Prozessmodell vorgesehen und somit muss eine Ausnahmebehandlung durch Aufru-
fen einer höheren Instanz ausgeführt werden. Das ursprüngliche Prozessmodell muss dabei
„verlassen“ werden und es wird zum Beispiel ein spezieller Subprozess oder der Prozess-
manager eingeschaltet. Eskalation ist somit ein Event, für das keine anwendbare Regel im
zu Grunde liegenden Prozessmodell existiert [vRD07].
Ausgelöst werden kann eine Eskalation beispielsweise durch die Verletzung zeitlicher Vor-
gaben: Zeitangaben im Prozessmodell werden bei der Ausführung nicht eingehalten (Bei-
spiel: Deadline oder vorgegebener Maximalabstand wird überschritten), sie kann aber
auch einen ganz anderen Ursprung haben (Beispiel: Ressourcen sind überlastet oder nicht
ausgenutzt).
Der Umgang mit Eskalationen stellt eine große Herausforderung dar, da diese heute noch
nicht von Prozessmanagementsystemen unterstützt werden, jedoch einen zentralen Aspekt
17
18 3 Nicht Einhalten der zeitlichen Vorgaben: Konsequenzen
im Zeitmanagement darstellen. Daher ist es wichtig, die Arten von den verschiedenen
Eskalationsursprüngen und die Möglichkeiten von Eskalationsbehandlungen zu kennen.
3.2 Eskalationsbehandlung
In diesem Teil wird beschriebenen, wie mit einer Eskalation umgegangen wird. Es wird
diskutiert, wann eine Fehlerbehandlung eingeleitet wird und wer für deren Ausführung
zuständig ist.
3.2.1 Wer ist für die Fehlerbehandlung zuständig?
Im Betracht der Vielzahl der Fehler, die im Bezug auf zeitliche Vorgaben bei einem Pro-
zessablauf entstehen können, stellt es sich als eine sehr komplexe Aufgabe heraus, ein Sys-
tem zu entwickeln, das im Falle einer Eskalation immer korrekt reagiert. In der heutigen
Zeit sind die technischen Systeme leider noch nicht flexibel genug, um den dynamischen
zeitlichen Bedingungen, Anforderungen und Einschränkungen in Prozessmodellen gerecht
zu werden [SMO99]. Im Normalfall werden Prozesse sowohl von manueller, als auch von
technischer Seite geregelt.
Der Vorteil eines automatischen Systems ist, dass es so gut wie immer zur Verfügung
steht, ein Mensch dagegen ist des Öfteren nicht erreichbar. Dafür kann der Mensch die Si-
tuation besser einschätzen und individuelle Umstände erfassen, was einer Maschine nicht
möglich ist. Sie kann nur vorgegebene Regeln verfolgen. Dies geht dann allerdings sehr
schnell, was man wiederum als Vorteil nennen kann. Eine Kompromisslösung ist ein semi-
automatisches System: Entweder wird zuerst der Mitarbeiter alarmiert und wenn er das
Problem nicht schnell genug in den Griff bekommt wird das System eingeschaltet oder es
wird erst das System aktiviert und bei keiner geeigneten Lösung der Mitarbeiter hinzuge-
zogen [vRD07].
Derzeitiges Ziel ist es, das technische System dem menschlichen Verhalten möglichst weit
anzupassen, was allerdings Schwierigkeiten birgt: Betrachtet man den Fall, dass die Dead-
line sehr zeitnah ist oder sogar schon feststeht, dass sie verletzt wird, so werden Menschen
ihr Verhalten ändern. Sie arbeiten schneller, treffen schnelle Entscheidungen (eventuell
auf Grund bisher unvollständiger Informationen), überspringen wenn möglich weniger re-
levante Aktivitäten oder überlassen diese geringer qualifizierten Mitarbeitern (siehe Lö-
sungsansätze in Kapitel 4). Ein technisches System wird nicht nervös oder panisch, es wird
immer weiter nach seinen vorgegebenen Regeln arbeiten. Diese Regeln können für einen
Ausnahmefall in einem Subprozess verankert sein. Das heißt, im Falle einer Eskalation
wird derjenige Subprozess aufgerufen, der für genau diese Art von Fehler geschaffen wor-
den ist. Will man jedoch für jeden möglichen Fehler einen eigenen Subprozess parat haben,
so würde das Prozessmodell eine unvorstellbar große Dimension annehmen und dadurch
sehr komplex und unübersichtlich werden [Hal10]. Darüber hinaus könnten selbst dann
noch keine individuellen Entscheidungen von automatisierten System getroffen werden.
3.2 Eskalationsbehandlung 19
3.2.2 Wie wird mit einer Eskalation umgegangen?
Wie bereits erwähnt, fehlt es noch an Systemen, die einen (korrekten) Umgang mit Eska-
lation bereitstellen. An dieser Stelle sollen daher zwei bekannte Methoden zum Umgang
mit Eskalation erläutert werden.
Zum einen gibt es die sogenannte 3D Methode: Detect, Decide, Do. Wie der Name schon
sagt, wird das Problem erst festgestellt, daraufhin wird entschieden was getan werden soll
und schließlich wird die Entscheidung ausgeführt. Das könnte zum Beispiel bedeuten, dass
ein Subprozess aufgerufen wird, der geeignete Maßnahmen ergreifen soll, um eine korrek-
te Fortsetzung des Prozesses zu erreichen. Ergebnis eines solchen Subprozesses könnten
die Änderung der Deadlines sein, die Ressourcen können neu verteilt werden, Aktivitä-
ten können gebündelt oder gesplittet werden. Bündeln heißt hierbei, dass Aktivitäten, die
von der gleichen Ressource ausgeführt werden können, zusammengefasst werden. Somit
sind sie zeitnah und können in einem Schritt bearbeitet werden. Im Gegensatz dazu be-
deutet splitten, dass eine Aktivität in mehrere Teile aufgeteilt wird, damit sie unter den
vorhandenen Ressourcen aufgeteilt werden kann. Wird der Prozess durch fehlende Daten
aufgehalten, so können Arbeitsschritte vorgezogen werden, in denen die fehlenden Daten
nicht benötigt werden. Eine weitere Möglichkeit bestünde darin, die Daten zu „schätzen“
und die Aktivität ohne vollständigen Datensatz auszuführen. Während der Laufzeit des
Subprozesses wird der eigentliche Prozess unterbrochen.
Andere Methoden hält ECA (Event-Condition-Action) bereit. Eine ECA-Methode wird
im Folgenden beschrieben: Es werden verschiedene Eskalationslevel unterschieden, zum
Beispiel Level 0 bis Level 3. Level 0 bedeutet hier, dass alles nach Plan verläuft, Level
1 tritt ein, wenn eine Aktivität ihre Deadline überschreitet. Wenn diese Aktivität nach
einem bestimmten Zeitraum immer noch nicht beendet ist, so kommt Level 2. Hier werden
verschiedene Maßnahmen (vor allem hinsichtlich der bearbeitenden Ressourcen) ergriffen.
Löst auch dies das Problem nicht, dann kommt es zu Level 3: Die problematische Aktivität
wird ausgelassen [vRD07].
3.2.3 Wann wird die Fehlerbehandlung eingeleitet?
Tritt der Fall der Eskalation ein, so muss unverzüglich eine Fehlerbehandlung eingeleitet
werden, da der Prozess nicht in der Lage ist, fortzufahren und die Zeit, in der der Prozess
stillsteht sonst verloren geht.
Jedoch ist es nicht immer sinnvoll, eine aufwändige Fehlerbehandlung einzuleiten, es kann
günstiger sein, den gesamten Prozess neu zu starten. Es gilt an dieser Stelle, eine Kosten-
abschätzung durchzuführen, die die Kosten für eine Fehlerbehandlung gegen die Kosten
eines Prozessabbruchs (und -neustarts) abwägt. Zudem kann es von großem (finanziellen)
Vorteil sein, die Eskalation vorherzusehen und sie früher einzuleiten, als es eigentlich nö-
tig wäre. Die in 3.2.2 vorgestellten Methoden können dabei hilfreich sein. Diese Art von
Vorhersage einer Eskalation kann nur von menschlicher Seite aus gemacht werden, da von
Systemen noch keine Vorhersage über die Zukunft zu erwarten ist. Dennoch ist es größte
Mühe Wert, eintretende Eskalation im Voraus zu entdecken, da Ausnahmebehandlungen
20 3 Nicht Einhalten der zeitlichen Vorgaben: Konsequenzen
die Hälfte der Gesamtzeit eines Prozesses einnehmen können und dadurch einen hohen
Kostenfaktor ausmachen [SW95].
Ziel hierbei ist es, möglichst viele Ausnahmefälle im Prozessmodell konkret definiert und
jeweilige Behandlungsmöglichkeiten parat zu haben. Wie solche Fehler zustande kommen,
inwiefern diese sich klassifizieren lassen und was mögliche Lösungen sein können wird in
Kapitel 4 analysiert.
Kapitel 4
Zeitvorgaben: Probleme und zugehörige
Lösungsansätze
In Kapitel 2 wurden Arten von zeitlichen Vorgaben mit zugehörigen Beispielen vorgestellt
und in Kapitel 3 wurde die Konsequenz der Verletzung dieser Vorgaben aufgezeigt. Im
Folgenden wird speziell auf die Verletzung zeitlicher Einschränkungen und den Umgang
damit eingegangen: Welche Art von zeitlicher Vorgabe wird verletzt? Auf Grund welcher
Art von zeitlicher Vorgabe kann das Problem entstehen? Welche Möglichkeiten gibt es, das
Problem zu lösen? Worin bestehen mögliche Konsequenzen? Was kann im Vorfeld getan
werden, um die Verletzung der zeitlichen Vorgabe zu verhindern?
Die einzelnen Probleme werden zunächst am Beispiel einer Aktivität analysiert und darauf-
hin wird die Auswirkung auf den gesamten Prozess nachvollzogen. In dieser Arbeit werden
die einzelnen Ursachen nach ihren Eigenschaften gruppiert, mit dem Ziel, möglichst über-
greifende Lösungen und prophylaktische Maßnahmen zu finden, die auf eine ganze Reihe
von Problemen gleichermaßen angewendet werden können. Eine grobe Unterteilung ergibt
zunächst folgende Gruppen: Aktivität startet zu spät, Aktivität dauert zu lang, Aktivität
endet zu spät, Prozess ist nicht ausführbar. Diese werden jeweils in einem eigenen Unterka-
pitel vorgestellt. Die genannten vier Unterkapitel sind wiederum in verschiedene Sektionen
gegliedert, denen schließlich mögliche Ursachen zugeordnet werden. Für jede aufgeführte
Ursache werden problemführende zeitliche Vorgaben, mögliche Zusammenhänge, Lösun-
gen und prophylaktische Maßnahmen aufgeführt. Unter den problemführenden zeitlichen
Vorgaben werden an dieser Stelle jene zeitlichen Vorgaben verstanden, durch die die je-
weilige Ursache und somit die Verletzung einer zeitlichen Vorgabe entsteht. Ein Beispiel
hierfür ist, dass eine Aktivität nicht zum vorgesehenen Zeitpunkt starten kann, weil sie
einen maximalen Abstand zur vorherigen Aktivität einhalten muss. Mittels der angegebe-
nen Lösungen werden mögliche Fehlerbehandlungen diskutiert, die den Prozess wieder in
einen ausführbaren Zustand überführen. Anhand der prophylaktischen Maßnahmen wird
beschrieben, wie sich das vorhandene Problem verhindern lässt. Aspekte, die für alle Ur-
21
22 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
sachen eines Abschnitts oder gar eine ganze Sektion gelten, werden hierbei extrahiert und
zusammengefasst.
4.1 Aktivität startet zu spät
In diesem Abschnitt wird der Fall analysiert, dass eine bestimmte Aktivität nicht starten
kann, das heißt, nach Plan müsste die Aktivität zum Zeitpunkt tstarten, sie tut es aber
nicht. Der Zeitpunkt tist entweder ein fixer Termin, wie die diagnostische Untersuchung
in Prozess Tumorektomie (siehe Kapitel 2.2), oder ein relativ zum Prozessbeginn oder zu
einer vorangegangenen Aktivität festgelegter Zeitpunkt bzw. festgelegte Zeitspanne. Zum
Beispiel beträgt in Prozess Tumorektomie der Minimalabstand zwischen OP-Vorbereitung
und OP-Durchführung 10 Minuten, der Maximalabstand ist 30 Minuten (siehe Abbildung
4.3). Startet die Aktivität zu spät, so wird möglicherweise der maximale Abstand zur vor-
angegangenen Aktivität nicht mehr eingehalten. Außerdem ist es möglich, dass der Start
der Aktivität einen maximalen Abstand zu einer weiteren Aktivität einhalten muss, der
somit auch nicht eingehalten werden kann (siehe Abbildung 4.3). Die Konsequenzen einer
zu spät gestarteten Aktivität zeichnen sich meist durch ein verspätetes Ende (bei gleicher
Dauer) der Aktivität aus, was einen Dominoeffekt auf sämtliche nachfolgenden Aktivi-
täten mit sich bringen kann bis schließlich die Gesamtdeadline des Prozesses nicht mehr
eingehalten werden kann oder der Prozess ganz abgebrochen werden muss.
Folglich gibt es in diesem Abschnitt folgende Arten der verletzten zeitlichen Vorgabe:
Fester Starttermin, Deadline für Aktivität, maximaler Abstand zur vorherigen Aktivität,
maximaler Abstand zwischen Start der betroffenen Aktivität und dem Start/Ende der
nachfolgenden Aktivität.
Um den Prozess nicht abbrechen zu müssen, ist es häufig nötig, den Startzeitpunkt der
Aktivität entsprechend zu verschieben und mit dieser neuen Information den restlichen
Prozess entsprechend anzupassen bzw. neu zu planen. Wenn es möglich ist, kann man
auch eine andere Aktivität vorziehen und die „Problemaktivität“ nach hinten verschieben,
mit dem Vorteil, einen Großteil des Prozesses in seinem ursprünglichen Zustand belassen
zu können. Um verhindern zu können, dass Aktivitäten zu spät starten, muss zunächst
den Ursachen für den verspäteten Start auf den Grund gegangen werden. Die einzelnen
Ursachen können hierbei in drei Kategorien eingeteilt werden: Vorbedingung nicht erfüllt
(siehe Abschnitt 4.1.1), Ressourcen nicht verfügbar (siehe Abschnitt 4.1.2) und Geschäfts-
objekt nicht vorhanden (siehe Abschnitt 4.1.3)).
An dieser Stelle seien dazu folgende Begriffe erläutert:
Ressource: „Begriff für die (materiellen, finanziellen und personellen) Mittel,
die eingesetzt werden können (oder müssen), um gesetzte Ziele (...) zu errei-
chen“ [SK06]. Sie haben bestimmte Eigenschaften und sind durch andere ihrer
Art ersetzbar. In Prozess Tumorektomie und in Prozess Chemotherapie sind
dies zum Beispiel Röntgengeräte, MRT-Geräte, Krankenschwestern, OP-Säle,
OP-Schwestern etc.
4.1 Aktivität startet zu spät 23
Bearbeiter: Spezielle Ressourcen mit der Eigenschaft, dass sie für die Bearbei-
tung der Aktivität verantwortlich sind. In Prozess Tumorektomie ist das zum
Beispiel der Arzt, der die OP durchführt, da dieser selbst den Patienten un-
tersucht und die OP geplant haben muss und somit die Verantwortung für die
OP trägt.
Geschäftsobjekt: Das Geschäftsobjekt ist der Bestandteil eines Prozesses bzw.
einer Aktivität, der bearbeitet wird. Beispiele für Geschäftsobjekte können
Kunden, Produkte und Bestellungen eines Auftragssystems sein [Ges]. In kli-
nischen Prozessen sind dies unter anderem die Patienten.
Im Folgenden werden die einzelnen Ursachen innerhalb der zugehörigen Kategorien ana-
lysiert.
4.1.1 Vorbedingung nicht erfüllt
In diesem Abschnitt wird eine nicht erfüllte Vorbedingung als Grund für den unmöglichen
Start einer Aktivität analysiert. Es werden dabei drei verschiedene Arten von Vorbedin-
gungen diskutiert.
U1: Daten nicht verfügbar
Manche Aktivitäten benötigen einen bestimmten Datensatz bevor sie starten können. Bei-
spielsweise kann die Patientenvorbereitung nicht beginnen, wenn das Ergebnis der Blut-
untersuchung des Patienten noch nicht vorhanden ist (siehe Abbildung 4.1). Dies ist ein
sehr interessanter Aspekt, da somit theoretisch auch die vorhergehende Aktivität „OP-
Vorbereitung“ noch nicht starten kann, welche die „Patientenvorbereitung“ als Subprozess
enthält. Da es einen festen Termin für die OP gibt, gibt es auch einen spätesten Startzeit-
punkt für die OP-Vorbereitung, welcher somit überschritten wird, wenn die Blutergebnisse
nicht rechtzeitig vorhanden sind.
Daten nachreichen
OP-
Vorbereitung
Blut-
untersuchung
OP- Vorberietung
OP- Saal-
Vorbereitung
Patienten-
vorbereitung
Blut-
untersuchung
Carolin Steurer 1 von 1 17.01.2012
Abbildung 4.1: Beispiel zur Datenabhängigkeit: Blutergebnis zum Start von
OP-Vorbereitung nötig
Wie in Tabelle 4.1 beschrieben, handelt es sich bei der problemführenden zeitlichen Vor-
gabe im Allgemeinen um eine Ende-Start-Beziehung: Die Daten sind nicht verfügbar, weil
eine vorangegangene Aktivität nicht beendet ist (siehe auch U3: Andere Aktivität nicht im
gewünschten Status). Entweder handelt es sich dabei um die Aktivität, in der die Daten
erstellt werden oder die Aktivität, die die Daten übermittelt.
An dieser Stelle hat man zwei Möglichkeiten zu handeln: Man startet die Aktivität nicht,
24 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.1
Ursachen Daten nicht verfügbar
Art der problemführen-
den zeitlichen Vorgabe
Ende-Start-Beziehung
Beispiele OP-Vorbereitung: Blutergebnis fehlt
Zusammenhänge Aktivität endet zu spät, Aktivität dauert zu
lang, Daten müssen nachgereicht werden
Lösungen Ohne Daten fortfahren, Daten nachreichen
mögliche Konsequenzen: Daten anders als ange-
nommen
Folgen: Aktivität neu starten, doppelte Teil-
schritte
Prophylaktische Maß-
nahmen
Vor Start der Aktivität regelmäßig prüfen, ob
Daten in Bearbeitung
was entweder eine Umstellung des ganzen Prozesses oder eines Teilprozesses zur Folge hat,
oder man startet die Aktivität trotz der nicht vorhandenen Daten. Dies bedeutet, man
nimmt für die Daten Erfahrungswerte bzw. Schätzwerte an und sobald die Daten nach-
gereicht werden, wird der angenommene Wert aktualisiert. Dieses Verfahren ist natürlich
nur dann möglich, wenn es sich um keine zu riskanten Schätzungen handelt, wie zum Bei-
spiel die Blutgruppe eines Menschen bei einer Bluttransfusion. Vorstellbar wäre dies zum
Beispiel bei einer Schreinerei: Der bestellte Schrank ist fertig und laut Prozessplan werden
nun die Griffe montiert, allerdings ist die Entscheidung, welcher Griff es sein soll noch
nicht vom Kunden eingetroffen. Man weiß allerdings aus Erfahrung, dass 90 Prozent aller
Kunden Griff A wählen. Somit könnte man Griff A montieren, mit einem geringen Risi-
ko, die Aktivität wiederholen zu müssen. In Prozess Tumorektomie sollte man zwar nicht
von einem bestimmten Blutergebnis ausgehen, kann jedoch die Aktivität OP-Vorbereitung
dennoch starten, in der Hoffnung, dass das Blutergebnis im Subprozess bis zum Start von
„Patientenvorbereitung“ eintrifft, da es vorher noch nicht benötigt wird (siehe Abbildung
4.2).
Wie kann man diese Art von Fehler verhindern? Eine Möglichkeit besteht darin, vor Start
der Aktivität, den Stand der Daten zu überprüfen und falls diese nicht im gewünschten
Status sind, die Ursache hierfür herausfinden und wenn möglich frühzeitig einen Lösungs-
weg finden. Weitere Details hierzu werden in Abschnitt 4.2 beschrieben.
U2: Bearbeiter nicht verfügbar
In diesem Abschnitt wird der Fall betrachtet, dass die Aktivität nicht starten kann, weil
der Bearbeiter nicht verfügbar ist (siehe Tabelle 4.2). Es sei an dieser Stelle nochmals
verdeutlicht, was unter einem Bearbeiter verstanden wird: Der Bearbeiter trägt die Ver-
antwortung für die Aktivität und kann nicht ohne weiteres durch einen anderen seiner Art
4.1 Aktivität startet zu spät 25
Daten nachreichen
OP-
Vorbereitung
Blut-
untersuchung
OP- Vorberietung
OP- Saal-
Vorbereitung
Patienten-
vorbereitung
Blut-
untersuchung
Carolin Steurer 1 von 1 17.01.2012
Abbildung 4.2: Beispiel zur Datenabhängigkeit: Blutergebnis zum Start von
Patientenvorbereitung nötig
ersetzt werden. Dies unterscheidet ihn von einer üblichen Ressource. Wir gehen folglich
davon aus, dass es unmöglich ist, die Aktivität trotz der Abwesenheit des Bearbeiters zu
starten. In Prozess Tumorektomie könnte dies zum Beispiel der operierende Arzt sein, da
er der einzige Arzt ist, der die Vorgeschichte des Patienten kennt, sämtliche Voruntersu-
chungen durchgeführt und die OP geplant hat. Ist dieser nicht anwesend, so kann die OP
nicht starten.
Da es keine Möglichkeit gibt, die Aktivität ohne Bearbeiter zu starten, muss der Start-
zeitpunkt verschoben werden. Geht man der Ursache für die Abwesenheit auf den Grund,
so kann herausgefunden werden, ob eine minimale Verschiebung des Startzeitpunkts der
Aktivität ausreicht bis der Bearbeiter verfügbar ist oder ob die Zeitspanne bis zum Start
zu groß ist. Dann muss der Restprozess und die nötigen vorangegangenen Aktivitäten neu
geplant werden. In Prozess Tumorektomie ist die maximale Verschiebungstoleranz der Ak-
tivität „OP“ 30 Minuten. Ansonsten muss die Patientenvorbereitung wiederholt werden.
Da es nicht möglich ist, die Aktivität ohne Bearbeiter zu starten, ist es von besonderer
Wichtigkeit, diesen Fall zu verhindern. Man sollte auch hier schon vor dem Start der Ak-
tivität den Bearbeiter „im Auge haben“ und diesen ggf. an die Aktivität erinnern. Bei
menschlichen Bearbeitern können hierbei persönliche Terminpläne (siehe Kapitel 5.3) eine
große Hilfe sein.
26 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.2
Ursachen Bearbeiter nicht verfügbar
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele OP: Arzt fehlt
Zusammenhänge Ressource nicht verfügbar, Bearbeiter nicht im
gewünschten Zeitraum verfügbar
Lösungen Grund für Abwesenheit des Bearbeiters heraus-
finden, Startzeitpunkt anpassen, Aktivität neu
planen, Restprozess anpassen, Mögliche Konse-
quenzen: Aktivität wird später starten als ge-
plant
Prophylaktische Maß-
nahmen
Bearbeiter rechtzeitig an Aktivität erinnern und
Bestätigung einfordern
U3: Andere Aktivität nicht im gewünschten Status
An dieser Stelle wird der Fall analysiert, dass eine Aktivität nicht starten kann, weil eine
andere Aktivität nicht im gewünschten Status ist (siehe Tabelle 4.3). Folglich existiert zwi-
schen den beiden Aktivitäten eine Start-Start-Beziehung oder eine Ende-Start-Beziehung.
Das bedeutet, eine andere Aktivität dauert zu lang (siehe Abschnitt 4.2) bzw. endet zu
spät oder startet zu spät. In Prozess Tumorektomie kann die OP zum Beispiel nicht star-
ten, bevor die OP-Vorbereitung abgeschlossen ist (siehe Abbildung 4.3). Demnach herrscht
an dieser Stelle eine Ende-Start-Beziehung.
Die Lösungsansätze hierfür sind vergleichbar mit denen für U1 (Daten nicht vorhanden).
Ende-Start-Beziehung mit Zeit
OP-
Vorbereitung OP
min. 10 Min,
max. 30 Min
Carolin Steurer 1 von 1 14.01.2012
Abbildung 4.3: Ende-Start-Beziehung
Unter Umständen (und mit einem gewissen Risiko) kann die Abhängigkeit ignoriert und
die Aktivität dennoch gestartet werden. Evtl. muss ein bestimmtes Ergebnis aus der vor-
angehenden Aktivität aus Erfahrungen geschätzt werden, mit dem Risiko, die betroffene
Aktivität wiederholen zu müssen. Im Gegensatz zu dem Fall, dass Daten nicht vorhanden
sind, kann es hier auch sein, dass gar nichts mehr von der vorangehenden Aktivität nach-
gereicht werden muss, dass sie also schon soweit bearbeitet wurde, dass alle gewünschten
4.1 Aktivität startet zu spät 27
Tabelle 4.3
Ursachen Andere Aktivität nicht im gewünschten Status
Art der problemführen-
den zeitlichen Vorgabe
Start-Start-Beziehung, Ende-Start-Beziehung,
minimaler Abstand
Beispiele OP kann nicht starten, da OP-Vorbereitung
nicht abgeschlossen ist
Lösungen Evtl. Startbedingung ignorieren, Mögliche Kon-
sequenzen: Abhängige Aktivität endet anders
als erwartet, Folgen: doppelte Teilschritte
Prophylaktische Maß-
nahmen
Abhängige Aktivität beobachten
Informationen erstellt sind. Daher lohnt es sich in jedem Fall, den Stand der problemati-
schen Aktivität einzufordern. In Prozess Tumorektomie ist es natürlich nicht möglich, die
OP zu starten, ohne dass die OP-Vorbereitung abgeschlossen ist. Diese kann erst abge-
schlossen werden, wenn das Blutergebnis eingetroffen ist. Jedoch ist es möglich, dass das
Ergebnis feststeht, aber noch nicht vollständig in das Datennetzwerk eingetragen ist. So-
mit gilt die Aktivität noch nicht als abgeschlossen. Dennoch kann man das Ergebnis schon
telefonisch erfragen und die OP-Vorbereitung kann beendet und somit die OP gestartet
werden. Um die Startentscheidung möglichst unverzüglich treffen zu können, sollte die
abhängige Aktivität schon im Voraus beobachtet werden, und feststellen zu können, wie
weit diese in ihrer Bearbeitung fortgeschritten ist, um mit diesen Informationen wiederum
die Folgen für die nachfolgende Aktivität abschätzen zu können.
Für die beschriebenen Problemsituation lässt sich zusammenfassen, dass es lohnenswert
ist, die Aktivitäten, von denen eine Vorbedingung ausgeht, frühzeitig zu beobachten, um
bei aufkommenden Verzögerungen die Entscheidung, die Abhängigkeit zu ignorieren oder
andere Maßnahmen auszuüben (zum Beispiel den Prozess umstrukturieren) mit einem fun-
dierten Wissen treffen zu können. Somit kann als prophylaktische Maßnahme festgehalten
werden, die Verzögerung so früh wie möglich zu erkennen, um dann nach Möglichkeiten
zu suchen, die Aktivität dennoch zu starten oder den Prozess umzustrukturieren .
4.1.2 Ressourcen sind nicht verfügbar
Ein weiterer Grund für das Nicht-Starten einer Aktivität liegt in verfügbaren Ressourcen.
An dieser Stelle sei nochmals betont, dass die zu einer Aktivitäten gehörenden Ressourcen
zwar zur Ausführung nötig, aber durch anderer ihrer Art ersetzbar sind. Zum Beispiel sei
für eine Aktivität „Röntgen“ ein Röntgengerät erforderlich. Dafür sei Röntgengerät A vor-
gesehen. Ist dies nicht verfügbar, so kann die Aktivität auch problemlos mit Röntgengerät
B durchgeführt werden. Ganz ohne Röntgengerät ist sie allerdings nicht durchführbar.
Im Folgenden wird der Grund für die Nicht-Verfügbarkeit der Ressourcen differenziert
betrachtet und analysiert.
28 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
U4: Ressourcen sind nicht reserviert
Der trivialste Grund für das Fehlen einer Ressource ist, dass diese nicht reserviert ist (siehe
Tabelle 4.4). Das heißt, sie „weiß“ nicht von ihrer anstehenden Aufgabe oder ist bereits
anderweitig belegt. Bei einer menschlichen Ressource bedeutet dies, dass sie einfach nicht
erscheint (entweder sie hat frei oder ist in einen anderen Prozess eingebunden). Eine ma-
schinelle oder räumliche Ressource ist entweder in einen anderen Prozess eingebunden,
also belegt, oder sie wäre zwar verfügbar, aber nicht ohne Reservierung (evtl. kann ein
Raum nur von bestimmten Personen aufgeschlossen oder muss vor der Benutzung gereinigt
werden). Im besten Fall ist die Ressource verfügbar und kann ad-hoc reserviert werden.
Sind Ressourcen nicht reserviert, so ist es in den meisten Fällen einen Versuch wert, ei-
ne ad-hoc-Reservierung durchzuführen. Bei einer nicht-menschlichen Ressource wird diese
erfolgreich sein, wenn die Ressource nicht in einen anderen Prozess eingebunden ist und kei-
ne vorbereitenden Schritte notwendig sind. Bei einer menschlichen ist es dann erfolgreich,
wenn sie nicht in einen anderen Prozess eingebunden ist und sich zum entsprechenden
Zeitpunkt in räumlicher Nähe befindet. Ressourcen können also in der Regel bis zu dem
Zeitpunkt reserviert werden, an dem eine vorgegebene Deadline für die Reservierung er-
reicht oder ein anderer Prozess mit der Reservierung zuvorgekommen ist. Demnach ist es
sinnvoll, die Reservierung so früh wie möglich zu tätigen und die erfolgreiche Durchführung
frühzeitig überprüfen zu lassen.
Tabelle 4.4
Ursachen Ressourcen nicht reserviert
Art der problemführen-
den zeitlichen Vorgabe
Deadline für Reservierung
Beispiele OP-Saal nicht reserviert, OP-Schwester nicht
eingeteilt
Zusammenhänge
Lösungen Ad-hoc-Reservierung
Prophylaktische Maß-
nahmen
Vor Start der Aktivität rechtzeitig prüfen, ob
Ressourcen reserviert sind
U5: Ressourcen sind in anderen Prozess eingebunden
In diesem Abschnitt wird der Fall betrachtet, dass die benötigten Ressourcen reserviert
sind, aber dennoch zur gewünschten Zeit in einen anderen Prozess eingebunden sind (siehe
Tabelle 4.5). Dies könnte entweder durch einen Fehler im System, das eine Doppelreservie-
rung zugelassen hat, entstanden sein oder dadurch, dass die andere Aktivität später endet
als geplant. Schließlich kann es auch sein, dass es sich bei dem anderen Prozess um einen
Prozess mit höherer Priorität handelt (zum Beispiel wird der OP-Saal durch einen Notfall
belegt). Auch in diesem Fall kann versucht werden, eine Ressource der gleichen Art (in
4.1 Aktivität startet zu spät 29
diesem Beispiel: OP-Saal) ad-hoc zu reservieren, um die Aktivität somit erfolgreich star-
ten zu können. Um eine Doppelreservierung zu vermeiden, können auch Bestätigungen für
die erfolgreiche Reservierung der Ressource eingefordert werden. Ist die Ressource in eine
Aktivität eingebunden, die später endet als geplant, so sollte diese Information rechtzeitig
übermittelt werden um entsprechend reagieren zu können. Im Optimalfall geschieht dies
durch die problembehaftete Aktivität selbst, aber auch die startende Aktivität kann vor
dem Start ihre benötigten Ressourcen beobachten.
Tabelle 4.5
Ursachen Ressourcen in anderem Prozess
Art der problemführen-
den zeitlichen Vorgabe
Prozessübergreifend
Beispiele OP-Saal für andere OP benötigt (doppelt reser-
viert, endet zu spät oder Notfall)
Zusammenhänge Aktivität endet zu spät
Lösungen Alternativressourcen ad-hoc reservieren
Prophylaktische Maß-
nahmen
Ressourcen in gewissen Abständen an Aktivität
„erinnern“, evtl. Bestätigung einfordern, Status
überprüfen
U6: Ressourcen versagen
Der letzte Grund für das Nichtvorhandensein der Ressourcen besteht darin, dass die
„Schuld“ bei den Ressourcen selbst liegt, sie „versagen“ (siehe Tabelle 4.6). Handelt es
sich um menschliche Ressourcen, so kann unter dem „Versagen“ zum Beispiel verstan-
den werden, dass die Ressource verschläft, die Aktivität vergisst, im Stau steckt, wegen
Krankheit spontan ausfällt, etc.. Bei maschinellen Ressourcen kann es sich beispielsweise
um einen Defekt handeln (Beispiel: Röntgengerät ist kaputt). Somit können die reser-
vierten Ressourcen nicht benutzt werden und ein Start der Aktivität ist nur durch eine
Ad-hoc-Reservierung anderer Ressourcen (der gleichen Art) möglich. Der Defekt eines
Gerätes kann zwar nicht unbedingt verhindert werden, jedoch sollte man ihn frühzeitig
entdecken, um eine andere Ressource so früh wie möglich zu reservieren. Eine menschliche
Ressource sollte einen Überblick über die anstehenden Aktivitäten behalten und evtl. auch
daran erinnert werden, dafür bieten sich die in Kapitel 5 erläuterten Personal Schedules
an.
Bei den vorangegangen Ursachen hat es sich als sinnvoll herausgestellt, vor der Aktivität
schon die Verfügbarkeit der benötigten Ressourcen zu überprüfen, um ggf. auf Ersatzres-
sourcen auszuweichen, um die Aktivität problemlos starten zu können. Gibt es keine Er-
satzressourcen, so kann die Aktivität nicht wie geplant gestartet werden. In diesem Fall
kann der Ablauf innerhalb der Aktivität (evtl. Subprozess) so umgestaltet werden, dass
30 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.6
Ursachen Ressourcen versagen
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmten
Beispiele Benötigtes Gerät defekt, OP-Schwester ver-
schläft
Zusammenhänge
Lösungen Alternativressourcen ad-hoc reservieren
Prophylaktische Maß-
nahmen
Ressourcen in gewissen Abständen an Aktivität
„erinnern“, evtl. Bestätigung einfordern
die Ressourcen erst dann benötigt werden, wenn sie verfügbar sind. Zum Beispiel kann bei
der diagnostischen Untersuchung in Prozess Tumorektomie erst am Ende die MRT durch-
führen, wenn das MRT-Gerät zu Beginn noch nicht verfügbar ist. Eine weitere Möglichkeit
besteht darin, den gesamten Prozess umzustrukturieren, also die Reihenfolge der Aktivi-
täten zu vertauschen. Zusammenfassen lassen sich die prophylaktischen Maßnahmen wie
folgt: Frühzeitige Erkennung der Verzögerung und sofort nach einer Möglichkeit suchen,
Ressourcen zu bekommen oder die Aktivität/den Prozess umzustrukturieren.
4.1.3 Geschäftsobjekt ist nicht bereit
Ein weiterer Teil, der bei der Ausführung jeder Aktivität unabkömmlich ist, ist das Ge-
schäftsobjekt. Das Geschäftsobjekt ist das „zu bearbeitende“ Objekt, wie zum Beispiel
Produkte oder Kunden. In klinischen Prozessen wird unter dem Geschäftsobjekt meist der
Patient verstanden.
Fehlt das Geschäftsobjekt, so fehlt der Aktivität der entscheidende Bestandteil und eine
Ausführung ist nicht möglich. Im Folgenden werden zwei Gründe für den Ausfall des Ge-
schäftsobjekts aufgeführt und ihre Konsequenzen diskutiert. Die erste Ursache ist, dass das
Geschäftsobjekt auf Grund diverser Umstände nicht am gewünschten Ort sein kann, im
zweiten Fall ist es zwar am gewünschte Ort, kann aber dennoch nicht bearbeitet werden.
U7: Geschäftsobjekt befindet sich nicht am gewünschten Ort
Es gibt viele denkbare Gründe, warum das Geschäftsobjekt nicht am gewünschten Ort ist,
die darauf zurückzuführen sind, dass es noch in einen anderen Prozess oder in eine andere
Aktivität eingebunden ist. Zum Beispiel kann der Patient noch nicht in der Klinik sein, weil
er im Stau steckt, weil er sich auf dem Klinikgelände verirrt hat oder weil er den Termin
vergessen hat. Dies lässt sich als eine Ende-Start-Beziehung beschreiben (siehe Tabelle 4.7):
Der Ortswechsel vor der startenden Aktivität wird als eigene Aktivität/eigener Prozess
betrachtet. Erst nach dessen Vollendung (wenn das Geschäftsobjekt das Ziel erreicht hat)
kann die Aktivität starten.
4.1 Aktivität startet zu spät 31
Es muss also geprüft werden, ob das Geschäftsobjekt zum Startzeitpunkt der Aktivität
am Zielort sein wird und wenn nicht, entweder ad-hoc ein Transport organisiert oder die
Aktivität an eine spätere Stelle im Prozess verschoben werden. Wie beim Ausbleiben des
Bearbeiters ist auch hier das Ignorieren der Abwesenheit unmöglich.
Tabelle 4.7
Ursachen Organisation: Geschäftsobjekt nicht am ge-
wünschten Ort
Art der problemführen-
den zeitlichen Vorgabe
Ende-Start-Beziehung
Beispiele Patiententransport zu spät
Zusammenhänge Aktivität endet zu spät, Bearbeiter nicht verfüg-
bar
Lösungen Wenn möglich Aktivitäten bzw. Aufgaben ver-
tauschen
Prophylaktische Maß-
nahmen
Vor Start der Aktivität rechtzeitig prüfen, ob
Objekt an gewünschten Ort transportiert wird,
wenn dies nicht der Fall: ad-hoc-Transport or-
ganisieren oder Prozess umstrukturieren
U8: Geschäftsobjekt ist nicht im gewünschten Zustand
Selbst wenn das Geschäftsobjekt am gewünschten Ort ist, kann es passieren, dass die Ak-
tivität auf Grund des Zustands des Geschäftsobjekts dennoch nicht starten kann (siehe
Tabelle 4.8). Beispiele dafür sind folgende: Der Patient verhält sich anders als geplant. Er
möchte die OP nicht mehr durchführen, oder er ist zu schwach. Bei einem nicht menschli-
chen Geschäftsobjekt kann es sich hier um einen Defekt oder ähnliches handeln. Es ergibt
also keinen Sinn, nach einer Möglichkeit zu suchen, die Aktivität auszuführen, da der
Zweck der Aktivität in der Bearbeitung des Geschäftsobjekts liegt. In diesem Fall gilt,
Schadensbegrenzung einzuleiten: Den Prozess abbrechen und die Ressourcen und Bear-
beiter schnellst möglich für andere Prozess freigeben.
Da hierbei große Verluste entstehen, ist es äußerst wichtig, solch einen Fall zu verhindern:
Mit menschlichen Geschäftsobjekten sollten im Vorfeld viel kommuniziert und alle Fragen
und mögliche Probleme geklärt werden. Bei maschinellen Geschäftsobjekten sollte deren
Zustand sorgfältig überprüft werden.
32 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.8
Ursachen Geschäftsobjekt ist nicht im gewünschten Zu-
stand
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele OP: Patient lehnt OP ab, Patient stirbt, Patient
zu schwach für OP
Zusammenhänge
Lösungen Prozess verwerfen, evtl. abhängige Prozesse op-
timieren
Prophylaktische Maß-
nahmen
Sämtliche Sachverhalte frühzeitig klären
4.1.4 Zusammenfassung
Es wurden nun sämtliche Ursachen für den ausbleibenden Start einer Aktivität mit zuge-
hörigen (individuellen) Lösungen aufgeführt. An dieser Stelle seien noch einmal Lösungen
zusammengefasst, die für alle Ursachen, die den Start einer Aktivität verhindern, gelten:
Startzeitpunkt verschieben, Prozess neu planen, Ausführungsreihenfolge verändern.
Die Konsequenzen für diese Art von Fehler zeichnen sich zum einen durch die Verletzun-
gen der oben genannten zeitlichen Vorgaben aus und zum anderen durch einen gewissen
Dominoeffekt: Startet eine Aktivität zu spät, so wird sie möglicherweise (bei gleichbleiben-
der Dauer) auch später enden als vorgesehen. Ist das Zeitfenster zur nächsten Aktivität
nicht groß genug, so wird auch diese zu spät starten usw. bis die Deadline des Gesamt-
prozesses nicht mehr eingehalten werden kann. Ist es unmöglich, eine Aktivität zu starten
oder zu verschieben, so kann es zum Prozessabbruch kommen.
Hier sind nochmals die möglichen Konsequenzen zusammengefasst: Aktivität endet
zu spät, Maximaler Abstand zwischen dem Ende der betroffenen Aktivität und dem
Start/Ende der vorhergehenden Aktivität wird nicht eingehalten, Mindestabstand zur
nachfolgenden Aktivität wird nicht eingehalten , Termine der Aktivität werden nicht ein-
gehalten, Dominoeffekt, maximale Prozessdauer wird überschritten, Deadline für Prozess
wird nicht eingehalten, Prozessabbruch.
4.2 Aktivität dauert zu lange
Dieser Abschnitt beschäftigt sich damit, dass eine Aktivität länger dauert als geplant. Der
Start läuft nach Plan ab, das Ende der Aktivität wird jedoch auf Grund der erhöhten
Dauer später sein als vorgesehen. Man kann sich viele Ursachen vorstellen, die dazu füh-
ren, dass eine Aktivität länger dauert als geplant. Um diese strukturiert zu analysieren
wird zunächst differenziert, ob der Problemursprung innerhalb der Aktivität selbst (siehe
4.2 Aktivität dauert zu lange 33
Abschnitt 4.2.1) oder durch äußere Einflüsse entsteht. Unter äußeren Einflüssen kann man
sich an dieser Stelle zum Beispiel eine Unterbrechung durch einen anderen Prozess vor-
stellen. Dies könnte in einem Klinikprozess beispielsweise durch einen Notfall entstehen,
der den OP-Saal oder den Arzt benötigt.
Liegt der Problemursprung in der Aktivität selbst, so kann man zwischen indirekten Ab-
hängigkeiten (siehe Abschnitt 4.2.2), wobei die erhöhte Dauer zum Beispiel durch Res-
sourcen verursacht wird, und erhöhtem Arbeitsumfang (siehe Abschnitt 4.2.3), d.h. die
Aufgabe ist in der vorgegebenen Zeit nicht zu schaffen, unterscheiden.
Als vierte Ursache kommt der Punkt hinzu, dass die Aktivität selbst nach Plan abläuft
und alle zugehörigen Aufgaben eigentlich erledigt sind, sie aber dennoch nicht „offiziell“
beendet werden kann, da das Ende von einer anderen Aktivität abhängt.
Es lassen sich damit die folgenden Arten an verletzten zeitlichen Vorgaben ablei-
ten: vorgegebene Dauer, festgelegtes Ende der Aktivität, minimaler Abstand zur nächsten
Aktivität, maximaler Abstand zwischen dem Ende der betroffenen Aktivität und dem der
vorhergehenden Aktivität.
4.2.1 Problemursprung liegt außerhalb der betroffenen Aktivität
In diesem Abschnitt werden Arten von Ursachen betrachtet, deren Ursprung außerhalb
der Aktivität liegt, die jedoch die Dauer der Aktivität erhöhen.
U9: Daten müssen nachgereicht werden
Man erinnere sich an die Ursachen U1 (Daten nicht vorhanden) in Abschnitt 4.1 (Vorbe-
dingung für Start der Aktivität ist nicht erfüllt). Als mögliche Lösung wurde aufgeführt,
die Aktivität dennoch zu starten und die Daten im Laufe der Aktivität nachzureichen.
Wird dieser Lösungsweg eingeschlagen, so kann es dennoch geschehen, dass die Daten
zum benötigten Zeitpunkt während der Aktivität noch immer nicht vorhanden sind und
die Aktivität somit nicht fortgesetzt werden kann, was einen Leerlauf und folglich eine
längere Dauer zur Folge hat (siehe Tabelle 4.9). Ein Beispiel zu Prozess Tumorektomie
kann wie folgt gegeben werden: Das Blutergebnis ist zum Start der OP-Vorbereitung noch
nicht vorhanden. Die Aktivität bzw. der Subprozess wird dennoch gestartet, in der Hoff-
nung, dass das Ergebnis bis zum Start der Patientenvorbereitung eingetroffen ist (siehe
Abbildung 4.2). Trifft dies nicht zu, so kann die Patientenvorbereitung evtl. trotzdem
starten (Formale Dinge können erledigt werden, Patient kann gebettet werden, etc.), aber
keinesfalls vollständig durchgeführt werden (Narkose und mögliche Medikamente können
nicht eingestellt werden). Damit muss also so lange gewartet werden, bis das Blutergebnis
vorhanden ist, erst dann kann die Aktivität fortgesetzt werden. An dieser Stelle kann die
Abhängigkeit als eine Ende-Ende-Beziehung zwischen den beiden Aktivitäten beschrieben
werden: Die Aktivität, die die Daten liefert (Blutuntersuchung), muss beendet sein, bevor
die Aktivität enden kann, die die Daten benötigt (Patientenvorbereitung).
Wie oben beschrieben, kann versucht werden, ohne Daten fortzufahren (möglicherweise
durch umsortieren der Teilaufgaben innerhalb der Aktivität), ist das Eintreffen der Daten
34 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.9
Ursachen Daten müssen nachgereicht werden
Art der problemführen-
den zeitlichen Vorgabe
Ende-Ende-Beziehung
Beispiele OP-Vorbereitung: Blutergebnis fehlt
Zusammenhänge Aktivität endet zu spät, Daten nicht verfügbar
Lösungen Ohne Daten fortfahren, andere Aktivität vor-
schieben, mögliche Konsequenzen: Daten anders
als angenommen, Aktivität nochmals neu star-
ten, Folgen: erhebliche Verzögerung
Prophylaktische Maß-
nahmen
Rechtzeitig prüfen, ob Daten nach Plan ver-
fügbar sind, andernfalls evtl. Teildatensatz oder
Schätzung anfordern
allerdings nicht absehbar, so kann es sinnvoller sein, die Aktivität zu stoppen und eine
andere vorzuziehen. Eine weitere Möglichkeit ist dadurch gegeben, dass die Daten aus
Erfahrungswerten verwendet oder geschätzt werden und ein dadurch bestimmtes Ergeb-
nis angenommen wird. Stellt sich dabei später heraus, dass die Annahme falsch war, so
muss die gesamte Aktivität wiederholt werden, was eine erhebliche Verzögerung zur Folge
hat. Dieser Weg sollte demnach nur eingeschlagen werden, wenn das Risiko einer falschen
Annahme sehr gering ist.
U10: Ressourcen sind nicht zum geplanten Zeitpunkt verfügbar
Möglicherweise sind die Ressourcen nicht für den gesamten Zeitraum der Aktivität nötig
und sind entweder nur für einen Teilabschnitt gebucht oder waren anfangs nicht verfügbar
und die Aktivität wurde dennoch gestartet. Die zugehörige Tabelle (siehe Tabelle 4.10)
hat große Ähnlichkeit mit denjenigen aus Abschnitt 4.1.2 (Ressourcen nicht verfügbar).
Sei nun eine spezielle Ressource betrachtet, dann kann die Zeit bis zur Verfügbarkeit der
Ressource als eine Aktivität betrachtet werden, die enden muss bevor die betrachtete
Aktivität (die auf die Ressource „wartet“) enden kann. Folglich handelt es sich um eine
Ende-Ende-Beziehung. Als Beispiel sei an dieser Stelle wieder die diagnostische Untersu-
chung in Prozess Tumorektomie aufgeführt: Innerhalb dieser Aktivität muss eine MRT-
Untersuchung durchgeführt werden. Dazu muss das MRT-Gerät innerhalb des Zeitraums
der Aktivität irgendwann zur Verfügung stehen. Solange die MRT nicht durchgeführt wur-
de, ist die diagnostische Untersuchung nicht zu Ende. Steht die Ressource zum geplanten
Zeitpunkt nicht zu Verfügung (Ursachen hierfür wurden in Abschnitt 4.1.2 aufgeführt), so
kann wenn möglich auf eine andere Ressource der selben Art zurückgegriffen werden (mit-
tels ad-hoc-Reservierung). Steht keine derartige Ressource zur Verfügung, kann versucht
werden, die Reihenfolge der Teilschritte innerhalb der Aktivität zu vertauschen, um die
4.2 Aktivität dauert zu lange 35
Tabelle 4.10
Ursachen Ressourcen nicht zum geplanten Zeitpunkt ver-
fügbar
Art der problemführen-
den zeitlichen Vorgabe
Ende-Ende-Beziehung, prozessübergreifend
Beispiele Diagnostische Untersuchung: MRT nicht reser-
viert / in anderen Prozess eingebunden
Zusammenhänge Ressourcen nicht verfügbar
Lösungen Ad-hoc-Reservierung/Umbuchung, Reihenfolge
der Teilschritte innerhalb der Aktivität vertau-
schen
Prophylaktische Maß-
nahmen
Rechtzeitig vor dem Start der Aktivität prüfen,
ob Ressourcen reserviert und verfügbar sind,
ggf. benötigte Ressourcen (erneut) reservieren
Nutzung der Ressource auf einen späteren Zeitpunkt zu verlegen. Ist kein Lösungsansatz
durchführbar, so muss die Aktivität abgebrochen werden. Um dies zu vermeiden, sollte
frühzeitig abgesichert werden, dass die benötigten Ressourcen zur Verfügung stehen, um
notfalls Ersatzressourcen reservieren zu können.
U11: Andere Aktivität ist nicht im gewünschten Status
Auch dieser Fall (siehe Tabelle 4.11) ist vergleichbar mit dem, dass die Aktivität auf Grund
einer Abhängigkeit von einer weiteren Aktivität nicht starten kann. Die Aktivität dauert
länger als geplant, weil sie entweder auf Informationen oder Bearbeitungsschritte einer
anderen Aktivität wartet und in ihrer Tätigkeit nicht fortfahren kann oder weil sie aus
formalen Vorgaben nicht enden darf, bevor eine andere Aktivität nicht gestartet oder be-
endet ist. Ein Beispiel hierfür findet sich in Abbildung 4.4: Solange die Schmerzmittel nicht
abgesetzt sind, darf die stationäre Versorgung nicht enden. Hier besteht eine Ende-Ende-
Beziehung zwischen den Aktivitäten. Eine weitere Vorgabe könnte durch den maximalen
Abstand zur nachfolgenden Aktivität gegeben sein: Die nachfolgende Aktivität kann noch
nicht starten, es darf aber nur ein begrenzter zeitlicher Abstand zwischen den beiden
Aktivitäten liegen. Beispiel: Die OP-Vorbereitung darf maximal 30 Minuten vor der OP
enden (siehe Abbildung 4.3). Steht der OP-Saal erst in 35 Minuten zu Verfügung, so kann
die OP-Vorbereitung noch nicht beendet werden. An dieser Stelle sei verdeutlicht, dass
die Dauer der Aktivität im einen Fall verlängert wird, weil die Aktivität tatsächlich noch
nicht früher fertiggestellt ist und im anderen Fall ist innerhalb der Aktivität alles fertig
bearbeitet, jedoch gilt sie erst als beendet, wenn eine andere Aktivität den vorgegebenen
Status erfüllt. Man beachte an dieser Stelle den Zusammenhang zu einem Subprozess in
der Aktivität: Ist die Aktivität, die den Subprozess enthält gestartet, so kann es pas-
sieren, dass eine Aktivität innerhalb des Subprozesses aus verschiedenen Gründen nicht
36 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
starten kann. Was für diese Aktivität eine Verzögerung beim Start bedeutet, hat für die
„Aktivität“ (also den Subprozess) eine erhöhte Dauer zur Folge.
Ähnlich wie bei U3 (Andere Aktivität nicht im gewünschten Status) gemäß Abschnitt
4.1 (Aktivität startet zu spät) besteht auch an dieser Stelle die Möglichkeit, die Abhän-
gigkeit zu ignorieren, wobei das Risiko einer falschen Annahme abgeschätzt werden muss,
da bei falscher Annahme die gesamte Aktivität wiederholt werden muss. Um dabei mög-
lichst wenig Zeit zu verlieren, sollten schon im Voraus Informationen über den Status der
Aktivität, an die die Abhängigkeit gerichtet ist, eingeholt werden.
OP-Nachbereitung
OP- Nachbereitung
Patienten mit
Schmerz-
mitteln
versorgen
Postoperative
Versorgung
auf Intensiv-
station
Solange
Schmerzmittel
nötig, muss
stationäre
Pflege anhalten
Stationäre
Pflege
Carolin Steurer 1 von 1 16.01.2012
Abbildung 4.4: OP-Nachbereitung: Ende-Ende-Beziehung
4.2 Aktivität dauert zu lange 37
Tabelle 4.11
Ursachen Andere Aktivität nicht im gewünschten Status
Art der problemführen-
den zeitlichen Vorgabe
Start-Ende-Beziehung, Ende-Ende-Beziehung,
max. Abstand
Beispiele OP: Patient nicht vorbereitet
Zusammenhänge Aktivität endet zu spät, Aktivität startet zu
spät (Subprozess)
Lösungen Evtl. Abhängigkeit ignorieren, Mögliche Konse-
quenzen: Informationen von abhängiger Aktivi-
tät sind anders als erwartet, Folgen: Aktivität
evtl. neu starten
Prophylaktische Maß-
nahmen
Informationen über aktuellen Status der abhän-
gigen Aktivität anfordern
U12: Unterbrechung der Aktivität durch ein externes Ereignis
Im vorherigen Abschnitt wurden Situationen beschriebenen, in denen die Dauer einer Ak-
tivität nicht eingehalten wird, obwohl die Aufgaben innerhalb dieser Aktivität wie geplant
ablaufen. Tabelle 4.12 beschreibt einen weiteren ähnlichen Fall: Die Aktivität wird durch
ein externes Ereignis mit höherer Priorität unterbrochen und kann vorerst nicht fortgesetzt
werden. In Prozess Tumorektomie könnte dies beispielsweise durch einen Notfall gesche-
hen: Während der diagnostischen Untersuchung wird der Arzt (d. h. der Bearbeiter der
entsprechenden Aktivität) zu einem Notfall gerufen, der höhere Priorität als die Untersu-
chung hat. Daraufhin wird die Untersuchung entweder abgebrochen oder es muss gewartet
werden, bis der Arzt wieder verfügbar ist und die Untersuchung fortsetzen kann, was die
Zeitspanne zwischen Start und Ende der Untersuchung, also ihre Dauer, erhöht.
Tabelle 4.12
Ursachen Unterbrechung der Aktivität durch externes Er-
eignis
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele Arzt muss wegen Notfall Untersuchung abbre-
chen
Zusammenhänge Bearbeiter nicht verfügbar, Aktivität kann nicht
enden
Lösungen Nach alternativer Ausführung suchen
Prophylaktische Maß-
nahmen
Berücksichtigen aller anderen parallel laufenden
Prozesse
38 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Wird davon ausgegangen, dass es während der Unterbrechung keine Möglichkeit gibt, die
Aktivität fortzusetzen, so kann versucht werden, eine andere Aktivität vorzuziehen bzw.
den Restprozess anzupassen. Um einen solchen Vorfall nach Möglichkeit zu verhindern,
sollten in der Planung und während der Ausführung sämtliche parallel laufende Prozesse
berücksichtigt werden, um auf eventuelle Unterbrechungen vorbereitet zu sein.
4.2.2 Indirekte Abhängigkeit
Im Folgenden werden Ursachen betrachtet, deren Ursprung sich innerhalb der Aktivität
befindet. Dieser Teil handelt speziell von indirekten Abhängigkeiten: Der Ursprung liegt in
der Aktivität, ist aber im weiteren Sinne unabhängig vom eigentlichen Inhalt der Aktivität
und damit von den Aufgaben, die in der Aktivität bearbeitet werden. Somit liegt die
Ursache entweder beim Bearbeiter, beim den Ressourcen oder beim Geschäftsobjekt.
U13: Bearbeiter ist zu langsam
Wie wird die vorgegebene Dauer einer Aktivität festgelegt? Im Normalfall wird diese aus
Erfahrungswerten ermittelt. Wurde die Dauer einer diagnostischen Untersuchung bzgl.
einer bestimmten Krebsart über Jahre hinweg protokolliert, so lässt sich mittels dieser
Erfahrungswerten ein Schätzwert berechnen, der als vorgegebene Dauer verwendet wer-
den kann. Man stelle sich nun vor, dass ein unerfahrener Arzt diese Untersuchung zum
ersten Mal durchführt, so liegt die Annahme nicht fern, dass er die vorgesehene Dauer
überschreitet. Ist der Bearbeiter dabei, die vorgegebene Dauer zu überschreiten, sollte er
sofort darüber informiert werden, damit er durch schnelleres Arbeiten oder, wenn möglich,
durch Auslassen einiger nicht ganz so relevanten Arbeitsschritten, den Rückstand bis zum
Aktivitätsende ausgleichen kann (siehe Tabelle 4.13).
Tabelle 4.13
Ursachen Bearbeiter zu langsam
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele Arzt braucht zu lange für Untersuchung
Zusammenhänge
Lösungen Schritte auslassen
Prophylaktische Maß-
nahmen
Bearbeiter bei Zeitverzug sofort informieren
U14: Ressourcen bereiten Probleme
Als zweite indirekte Abhängigkeit sind die Ressourcen gegeben (siehe Tabelle 4.14). Auch
sie können durch ungeplantes Arbeiten die Bearbeitung der Aktivität verzögern. Zum
4.2 Aktivität dauert zu lange 39
Beispiel könnte eine OP-Schwester aus menschlichen Gründen langsamer arbeiten, als
dies von ihr erwartet wird. Genauso könnte ein benötigtes MRT-Gerät ausfallen, und es
muss erst repariert werden, bevor es wieder eingesetzt und in Prozess Tumorektomie die
diagnostische Untersuchung fortgesetzt werden kann.
Tabelle 4.14
Ursachen Ressourcenprobleme
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele Untersuchung: MRT kaputt, OP: OP-Schwester
zu langsam
Zusammenhänge Ressourcen nicht verfügbar
Lösungen Schritte auslassen, Aktivität/Prozess umstruk-
turieren, Ressourcen austauschen
Prophylaktische Maß-
nahmen
Ressourcenzustand frühzeitig prüfen, Ad-hoc-
Ressourcen- Umbuchung
Ist im Voraus bekannt, dass eine Ressource in einem schlechten Zustand ist, so kann
man diese möglicherweise durch eine andere ihrer Art austauschen. Auch während der
Aktivität kann dies noch möglich sein. Andernfalls kann die verlorene Zeit mit ausgelasse-
nen Teilschritten oder schnellerem Arbeiten der Ressourcen wieder ausgeglichen werden.
Ansonsten muss die Aktivität bzw. der Prozess umstrukturiert werden. Handelt es sich
um menschliche Ressourcen, so gelten die gleichen Lösungen und prophylaktischen Maß-
nahmen wie in U13 (Bearbeiter ist zu langsam).
U15: Geschäftsobjekt ist in anderem Zustand als erwartet
Das Geschäftsobjekt kann genau wie beim Start der Aktivität (siehe U8, Abschnitt 4.1.3)
auch hier in einem anderen Zustand sein als geplant (siehe Tabelle 4.15): Ein menschliches
Geschäftsobjekt kann sich gegen die Ausführung der Aktivität entscheiden. Dies hätte
in den meisten Fällen einen Abbruch des Prozesses zur Folge. Andere Verhaltensarten
verzögern nur die Bearbeitung der Aktivität. Ein Beispiel dafür ist: Der Patient ist zu
nervös für die OP und benötigt Beruhigungsmittel, auf deren Wirkung gewartet werden
muss. Im nicht menschlichen Fall kann es sein, dass das zu bearbeitende Gerät Mängel
aufweist, die zunächst behoben werden müssen.
Um diese Art von Verzögerung zu vermeiden, sollten vorhersehbare Probleme abgeklärt
und im Vorfeld behoben werden (evtl. dem Patienten schon vorher ein Beruhigungsmit-
tel geben, das Geschäftsobjekt im Voraus auf Mängel testen). Andernfalls kann versucht
werden, die Aktivität umzustrukturieren. Tauchen dennoch derartige Probleme in der Ak-
tivität auf, so können diese evtl. durch ausgelassene Arbeitsschritte oder eine schnellere
40 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
Tabelle 4.15
Ursachen Geschäftsobjekt in anderem Zustand als erwar-
tet
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele OP-Vorbereitung: Patient ist nervös, benötigt
Beruhigungsmittel
Zusammenhänge
Lösungen Schritte auslassen, schnelleres bearbeiten, um-
strukturieren der Aktivität/des Prozesses
Prophylaktische Maß-
nahmen
Vorhersehbare Probleme frühzeitig beheben
bzw. einplanen
Bearbeitung ausgeglichen werden. Ist dies nicht möglich, so muss die Aktivität oder sogar
der ganze Prozess umstrukturiert werden.
4.2.3 Erhöhter Arbeitsumfang
In diesem Abschnitt wird folgende Situation betrachtet: Die Bearbeitung der Aktivität ist
im Gange. Es gibt keine Störungen von außen und Bearbeiter, Ressourcen und Geschäfts-
objekt verhalten sich wie erwartet. Dennoch kann die Aktivität ihre vorgegebene Dauer
nicht einhalten. Das bedeutet, dass die anstehenden Aufgaben nicht in der vorgesehenen
Zeit zu bearbeiten sind. Mögliche Ursachen dafür sind im Folgenden aufgeführt.
U16: Teilschritte müssen wiederholt werden
Eine (nicht atomare) Aktivität lässt sich in verschiedene Teilschritte einteilen. Besteht
die Aktivität aus einem Subprozess, so kann man diesen wiederum in verschiedene Ak-
tivitäten unterteilen. In den bisher genannten Problemen wurde des Öfteren aufgeführt,
dass eine Aktivität wiederholt werden muss (zum Beispiel auf Grund falscher Annahme
von nicht vorhandenen Datenergebnissen). Befindet sich eine solche Aktivität innerhalb
eines Subprozesses, so erhöht sich damit die Dauer des gesamten Subprozesses und somit
die Dauer der Aktivität, die diesen Subprozess beschreibt. Aber auch bei Aktivitäten, die
keinen Subprozess beinhalten, kann dieses Problem aufkommen: Man nehme die Aktivität
„Laboruntersuchung“ aus Prozess Tumorektomie als Beispiel. Diese Aktivität besteht aus
verschiedenen Arbeitsschritten. Zuerst wird das Blut in ein Reagenzglas gefüllt und darin
werden verschiedene Untersuchungen durchgeführt. Zerbricht dieses Reagenzglas im Laufe
der Aktivität, so müssen einige Untersuchungen nochmals durchgeführt werden (falls diese
noch nicht abgeschlossen waren). Diese Umstände waren nicht eingeplant, als die Dauer
für die Aktivität festgelegt wurde und somit ist diese nicht mehr einzuhalten (siehe Tabelle
4.16).
4.2 Aktivität dauert zu lange 41
Tabelle 4.16
Ursachen Teilschritte müssen wiederholt werden
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele Laboruntersuchung: Reagenzglas zerbricht
Zusammenhänge
Lösungen Schritte auslassen, Prozess umstrukturieren
Prophylaktische Maß-
nahmen
Vorhersehbare Probleme frühzeitig beheben
bzw. einplanen
Sind in einer Aktivität kritische Teilschritte enthalten, so können häufiger notwendige
Wiederholungen in die Dauer eingeplant werden. Tritt das Problem auf, so können die wie-
derholten Teilschritte evtl. durch das Auslassen anderer Teilschritte kompensiert werden.
Andernfalls ist eine Umstrukturierung/Anpassung des restlichen Prozesses nötig.
U17: Aktivität ist komplexer als erwartet
Eine weitere Ursache für einen erhöhten Arbeitsumfang entsteht, wenn die Aktivität kom-
plexer ist als erwartet (siehe Tabelle 4.17). Das heißt, ihr Inhalt wurde falsch eingeschätzt.
Zum Beispiel können bei einer Standard-OP Komplikationen auftreten, durch die sich die
benötigte Dauer erhöht.
Tabelle 4.17
Ursachen Aktivität komplexer als erwartet
Art der problemführen-
den zeitlichen Vorgabe
Keine bestimmte
Beispiele Komplikationen während einer OP
Zusammenhänge Bearbeiter zu langsam
Lösungen Ressourcen hinzunehmen, Schritte überspringen
Prophylaktische Maß-
nahmen
Sämtliche Komponenten und Erfahrungsberich-
te in Planung miteinbeziehen
Tritt der oben beschriebene Falle ein, so kann eine Ad-hoc-Reservierung von zusätzlichen
Ressourcen eine Hilfe sein. Wenn möglich, können auch hier Teilschritte übersprungen
werden, um Zeit zu gewinnen. Um das Ganze zu vermeiden, sollten vor der Festlegung der
Dauer sämtliche Erfahrungsberichte in die Planung miteinbezogen und alle Komponenten
bzw. kritische Situationen berücksichtigt und im Voraus Lösungen für alle möglichen Fälle
gefunden werden.
42 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
U18: Vereinbarte Dauer wird nicht eingehalten
In den obigen Abschnitten wurde immer davon ausgegangen, dass eine im Voraus festge-
legte Dauer für die Aktivität existiert. Jedoch ist es nicht immer möglich, die Dauer vor
Beginn der Aktivität festzulegen. In manchen Fällen kann dies erst innerhalb der Akti-
vität selbst geschehen. Die stationäre Pflege im Subprozess „OP-Nachbereitung“ dauert
mindestens so lange an, wie Schmerzmittel verabreicht werden müssen (siehe Abbildung
2.3). Die Aktivität „Schmerzmittel“ gilt aber erst dann als beendet, wenn der Patient
keine Schmerzen mehr hat [Mey96]. Das Problem in diesem Fall besteht nun darin, dass
keine vorgegebene Dauer existiert. Um den Prozess zu planen, muss eine Dauer geschätzt
werden, was sich als äußerst schwierig erweisen kann. Im Laufe der Aktivität kann diese
geschätzte Dauer dann zwar aktualisiert werden, aber es bleiben dennoch Schätzwerte.
Eine etwas andere Situation ist die Folgende: Es ist gibt keine Angabe über eine maxi-
male Dauer einer Aktivität, aber die Bedingung lautet, dass die Aktivität innerhalb eines
Geschäftstages abgeschlossen sein muss. Wird die Aktivität erst zehn Minuten vor Ende
des Geschäftstages begonnen, so beträgt die maximal erlaubte Dauer für die Ausführung
der Aktivität zehn Minuten. Da die Aktivität selbst eine Mindestdauer besitzt, ist sie nur
noch dann an dem beschriebenen Tag ausführbar, wenn ihre Mindestdauer nicht mehr als
zehn Minuten beträgt. Wird diese Aktivität zu Beginn eines Tages gestartet, so ergeben
sich zehn Stunden für die maximal zugelassene Dauer. In diesem Fall wird die maximale
Dauer beim Start der Aktivität festgelegt und zu diesem Zeitpunkt muss geprüft werden,
ob die Aktivität noch gestartet werden kann.
Tabelle 4.18
Ursachen Vereinbarte Dauer nicht eingehalten
Art der problemführen-
den zeitlichen Vorgabe
Keine geplante Dauer
Beispiele Stationäre Pflege: Schmerzmittel werden abge-
setzt wenn Patient schmerzfrei ist,
Aktivität muss innerhalb eines Geschäftstages
abgeschlossen werden
Zusammenhänge
Lösungen Regelmäßig aktualisierte Einschätzungen anfor-
dern, Prozess neu planen
Prophylaktische Maß-
nahmen
Dauer möglichst genau aus sämtlichen relevan-
ten Erfahrungswerten erschließen, ständiges Up-
date anfordern
Um die Abschätzung der Dauer möglichst korrekt zu halten, ist es notwendig, ständig
Updates aus der laufenden Aktivität zu erhalten. Mit diesen Angaben sollte dann, falls
nötig, möglichst schnell der Restprozess aktualisiert werden.
4.3 Aktivität endet zu spät/endet nicht 43
4.2.4 Zusammenfassung
Die in diesem Unterkapitel aufgeführten Lösungsmöglichkeiten und prophylaktischen Maß-
nahmen sind zum Teil ähnlich, wenn nicht sogar identisch. An dieser Stelle soll nochmals
zusammengefasst werden, welche Maßnahmen ergriffen werden können, wenn eine Aktivi-
tät zu lange dauert.
Ist die vorgegebene Dauer innerhalb einer Aktivität nicht einzuhalten, so kann entweder
versucht werden, diesen Verzug innerhalb der Aktivität auszugleichen oder die folgenden
Aktivitäten werden an die Konsequenzen der zu lange dauernden angepasst. Werden Teil-
schritte übersprungen, so müssen diese evtl. in späteren Aktivitäten nachgeholt werden
und das Problem wurde somit nicht gelöst sondern nur verschoben.
Als Lösungen für einen Fehler, der eine zu lange Dauer der Aktivität verursacht gelten
Folgende: Aktivität/Prozess umstrukturieren, Teilschritte überspringen, mögliche Konse-
quenzen: Probleme in späteren Aktivitäten/Prozessergebnis auf Grund der ausgelassenen
Schritte.
Eine logische Konsequenz auf eine zu lange Dauer ist ein zu spätes Ende, was einen
Dominoeffekt auslösen kann, damit ergeben sich die folgenden möglichen Konsequen-
zen: Aktivität endet zu spät/gar nicht, minimaler Abstand zur nachfolgenden Aktivität
wird nicht eingehalten, Maximaler Abstand zwischen dem Ende der betroffenen Aktivität
und dem Start/Ende der vorhergehenden Aktivität wird nicht eingehalten, Dominoeffekt,
maximale Prozessdauer wird nicht eingehalten, Prozessdeadline wird nicht eingehalten,
Aktivität muss abgebrochen werden.
Prophylaktische Maßnahmen können die Folgenden sein: Festgelegte Dauer mit
Hilfe sämtlicher Erfahrungswerte und nach Rücksprache des für die Aktivität zuständigen
Bearbeiters realistisch ansetzen.
4.3 Aktivität endet zu spät/endet nicht
Ein häufiger Fehler bzgl. der zeitlichen Vorgaben besteht darin, dass eine Aktivität zu spät
oder gar nicht endet. Endet eine Aktivität zu spät, so ist dies entweder die Konsequenz
eines zu späten Starts oder einer zu langen Dauer der Aktivität. An dieser Stelle wer-
den somit keine speziellen Ursachen mehr für das spätere bzw. ausbleibende Enden einer
Aktivität aufgeführt, da diese schon in den Abschnitten 4.1 und 4.2 diskutiert worden
sind.
4.4 Prozess (Instanz) ist nicht ausführbar
Als letzter Punkt wird die Situation betrachtet, dass es nicht für alle Instanzen möglich
ist, den vorgegebenen Prozess in der Praxis auszuführen. Die Ursachen hierzu sind in zwei
Kategorien gegliedert: „Fehler im Prozessmodell“ und „Prozessinstanz nicht ausführbar“.
Fehler im Prozessmodell haben zur Folge, dass der modellierte Prozess unter bestimmten
Umständen nicht realisierbar ist. Im zweiten Abschnitt (Prozessinstanz nicht ausführbar)
44 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
werden diejenigen Ursachen diskutiert, die zum Abbruch einer Prozessinstanz führen, das
heißt sie sind nicht im Prozessmodell verankert, sondern erst während der Ausführung
„entstanden“.
4.4.1 Fehler im Prozessmodell
Die folgenden beiden Ursachen beschreiben einen Fehler im Prozessmodell und führen
dazu, dass der Prozess nicht (fehlerfrei) ausgeführt werden kann.
U19: Inkonsistenz im Prozessmodell
Enthält das Prozessmodell einen Widerspruch bzgl. der zeitlichen Angaben, so kann der
Prozess nicht ausgeführt werden (siehe Tabelle 4.19). Ein Beispiel hierfür ist der Fall,
dass zwischen zwei Aktivitäten ein maximaler Abstand von drei Stunden festgelegt wurde,
jedoch eine Aktivität zwischengeschaltet ist, die selbst eine Mindestdauer von vier Stunden
besitzt (siehe Abbildung 4.5). Durch diesen Widerspruch ist eine korrekte Ausführung des
Prozesses unmöglich.
Widerspruchgut
Aktivität A:
2h
Aktivität B:
4h
Aktivität C:
1h
max. 3h
Carolin Steurer 1 von 1 14.01.2012
Abbildung 4.5: Inkonsistenz im Prozessmodell
Tabelle 4.19
Ursachen Inkonsistenz im Prozessmodell
Art der problemführen-
den zeitlichen Vorgabe
Sämtliche
Beispiele Minimaler Abstand 4h, maximaler Abstand 3h
Zusammenhänge Modellierung
Lösungen Ad-hoc-Änderung des Prozesses vor weiterer
Ausführung
Prophylaktische Maß-
nahmen
Peer-Review, „Durchspielen“ des Prozesses,
4.4 Prozess (Instanz) ist nicht ausführbar 45
Um diese Art von Fehler zu verhindern sollte vor der Einführung des Modells zumin-
dest ein Art Probeprozess „durchgespielt“ werden, bei dem solche Fehler erkannt werden.
Außerdem ist es empfehlenswert ein Peer-Reviewing durchzuführen, bei dem das Prozess-
modell von Mitarbeitern kontrolliert wird, die beim Entwurf nicht selbst beteiligt waren.
Schließlich gibt es verschiedene Möglichkeiten zur Überprüfung des Prozesses auf Inkonsis-
tenzen, die in Kapitel 5.2 vorgestellt werden. Tritt ein solcher Fehler in der Prozessausfüh-
rung dennoch auf, so muss der Prozess entweder abgebrochen oder eine Ad-hoc-Änderung
des Modells durchgeführt werden
U20: Fehlinformation bzgl. Realität
Wurden gewisse Gegebenheiten des Umfelds, in dem der Prozess ausgeführt werden soll, bei
der Modellierung nicht berücksichtigt oder fehlerhafte Informationen, die mit der Realität
nicht übereinstimmen, verwendet, so hat dies eine fehlerhafte Ausführung des Prozesses
zur Folge (obwohl das Prozessmodell in sich korrekt bzw. konsistent ist). Beispiele für
eine solche Situation sind die Folgenden: Das Labor für die Blutuntersuchung hat am Wo-
chenende geschlossen, im Prozessmodell werden die Wochentage aber nicht berücksichtigt.
Somit treten dann Fehler bei der Prozessausführung auf, wenn die Blutuntersuchung laut
Plan am Wochenende stattfinden soll. Ein weiteres Beispiel ist, dass die diagnostische Un-
tersuchung im Prozessmodell auf 20 Minuten festgelegt ist und deren Dauer in der Realität
einer Stunde entspricht.
Tabelle 4.20
Ursachen Fehlinformation bzgl. Realität
Art der problemführen-
den zeitlichen Vorgabe
Sämtliche
Beispiele Labor am Wochenende geschlossen
Zusammenhänge Modellierung
Lösungen Ad-hoc-Änderung des Prozesses vor weiterer
Ausführung
Prophylaktische Maß-
nahmen
Absprechen mit/Überprüfung durch Fachkraft
des Einsatzgebietes des Prozessmodells
Damit diese Art von Fehler nicht eintritt, sollte die inhaltliche Fachkraft stark in die
Prozessmodellierung miteinbezogen und ständig Rücksprachen gehalten werden. Tritt der
Fall dennoch ein, so wird der Prozess entweder sofort abgebrochen oder mittels Ad-hoc-
Änderungen korrigiert.
4.4.2 Prozessinstanz nicht ausführbar
Im Gegensatz zum vorherigen Abschnitt wird nun davon ausgegangen, dass das Prozess-
modell zu Beginn an realisierbar war, aber während der Ausführung ein Problem entsteht,
46 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
dass dazu führt, dass der Prozess nicht mehr weiter ausführbar ist. Dazu werden zwei
verschiedene Ursachen betrachtet.
U21: Aktivität ungültig
Der in Tabelle 4.21 beschriebene Problemfall bezieht sich auf eine bestimmte Aktivität, die
nicht mehr gültig ist, zum Beispiel weil eine neue Version existiert. In Prozess Tumorekto-
mie werden während der diagnostischen Untersuchung eine MRT und eine Blutabnahme
durchgeführt. Ab nun soll innerhalb dieser Aktivität zusätzlich eine CT durchgeführt wer-
den. Hat beim Start einer Prozessinstanz noch die alte Version der Aktivität gegolten und
gilt beim Start der Aktivität „diagnostische Untersuchung“ schon die neue Version, so ist
für diese Aktivität zum einen nicht genug Zeit eingeplant und zum anderen wurden nötige
Vorbereitungen wie die Reservierung des CT-Geräts nicht getroffen. In Folge dessen tritt
in Prozessinstanz ein Fehler auf.
Eventuell lässt sich der Prozess durch eine Ad-hoc-Änderung der Aktivität vor einem
Tabelle 4.21
Ursachen Aktivität ungültig
Art der problemführen-
den zeitlichen Vorgabe
Sämtliche
Beispiele Neue Version existiert
Zusammenhänge
Lösungen Ad-hoc-Änderung des Prozesses vor weiterer
Ausführung
Prophylaktische Maß-
nahmen
Vor Start und während des Prozesses Gültigkei-
ten überprüfen
Abbruch bewahren. Schon im Voraus und während des Prozesses sollten die Aktivitäten
auf ihre Gültigkeit überprüft werden, um dieses Problem zu verhindern.
U22: Während Ausführung festgelegte Termine sind nicht einhaltbar
Nicht alle Termine bzw. Aktivitäten stehen bei Beginn der Prozessausführung schon fest.
Es kann vorkommen, dass eine Aktivität einen Termin vereinbart, also eine neue Aktivi-
tät im späteren Teil des Prozesses einfügt bzw. deren Beginn festsetzt (Beispiel: Bei der
Patientenaufnahme in Prozess Tumorektomie wird der Termin für die diagnostische Un-
tersuchung festgelegt). Wird dabei nicht genug Zeit für die Aktivitäten vor diesem Termin
berücksichtigt (in diesem Beispiel: Vorbereitung der diagnostischen Untersuchung), so ist
es nicht möglich, diesen Termin einzuhalten (siehe Tabelle 4.22).
Kann ein Termin nicht eingehalten werden, so muss dieser, wenn möglich, verschoben
werden. Da dies so früh wie möglich geschehen sollte, empfiehlt es sich, während der Aus-
führung regelmäßig zu überprüfen, ob der Termin eingehalten werden kann und vor allem
4.5 Fazit 47
Tabelle 4.22
Ursachen Während Ausführung festgelegte Termine nicht
einhaltbar
Art der problemführen-
den zeitlichen Vorgabe
Sämtliche
Beispiele Termin für diagn. Untersuchung bei Aufnahme
vereinbart: zu wenig Zeit für Vorbereitung der
diagn. Untersuchung
Zusammenhänge
Lösungen Termin ad-hoc ändern
Prophylaktische Maß-
nahmen
beim Festlegen des Termins die abhängigen Ak-
tivitäten berücksichtigen, während der Ausfüh-
rung öfter überprüfen, ob Termine einhaltbar
beim Festlegen des Termins die „Zwischenaktivitäten“ (diejenigen nach der Aktivität, in
der der Termin festgelegt wird und vor dem Termin selbst) zu berücksichtigen.
4.5 Fazit
Es wurden 22 Ursachen für zeitbedingte Fehlersituationen in Prozessen diskutiert, die sich
jeweils einer der drei Kategorien „Aktivität startet zu spät“, „Aktivität dauert zu lange“
und „Prozess (Instanz) ist nicht ausführbar“ zuordnen lassen. Für jede dieser Ursachen
wurde zunächst einzeln betrachtet, in welchen Arten von Zeitangaben der Ursprung der
vorhandenen Fehlersituation liegt. Zu diesen problemführenden zeitlichen Vorgaben zählen
unter anderem sämtliche Abhängigkeiten (Start-Start-Beziehung, Ende-Start-Beziehung,
Start-Ende-Beziehung, Ende-Ende-Beziehung) sowie vorgegebene maximale/minimale Ab-
stände zwischen den einzelnen Aktivitäten. Allerdings liegt der Ursprung der Ursachen für
zeitbedingte Fehlersituationen nicht immer in zeitlichen Vorgaben. Ebenfalls kann er im
Mangel der benötigten Ressourcen, dem Zustand des Geschäftsobjekts oder des fehlenden
Bearbeiters der Aktivität liegen.
Die Möglichkeiten zu reagieren wenn eine (lokale) Eskalation auf Grund einer nicht ein-
gehaltenen Zeitvorgabe eintritt lassen sich in drei Kategorien einteilen: Man kann die
auslösende Aktivität überspringen, einen alternativen Ausführungspfad einschlagen oder
die Zeitangabe neu anpassen. Die spezifisch vorgeschlagenen Lösungen bestehen häufig aus
nötigen Ad-hoc-Handlungen (wie zum Beispiel Ressourcen reservieren oder den Prozess
umstrukturieren), dem Ignorieren der vorhandenen Abhängigkeiten oder aus dem Aus-
lassen von einzelnen Arbeitsschritten. Da jedoch jede dieser Lösungen einen zusätzlichen
Aufwand erfordert und darüber hinaus weitere Probleme auftreten können (werden Ar-
beitsschritte ausgelassen, so müssen diese evtl. in späteren Aktivitäten nachgeholt werden),
ist es oftmals günstiger, eine Eskalationsbehandlung einzuleiten, bevor die eigentliche Es-
48 4 Zeitvorgaben: Probleme und zugehörige Lösungsansätze
kalation eintritt (siehe Kapitel 3.2.3) [EPR99]. Dadurch kann unter anderem eine doppelte
Ausführung von Arbeitsschritten vermieden werden. Vor allem gilt es aber, dies Situatio-
nen einer aufkommenden Eskalation ganz zu vermeiden.
Vermeiden lassen sich die aufgeführten Ursachen durch ständige Analyse und Kontrolle des
Gesamtprozesses, durch „Kommunikation“ zwischen den Aktivitäten und durch voraus-
schauendes Arbeiten. Läuft eine Aktivität nicht nach Plan ab, so muss der Prozessmanager
und die davon abhängigen Aktivitäten unverzüglich vom aktuellen Status der Aktivität
erfahren, um entsprechend reagieren zu können. Darüber hinaus ist es hilfreich, weit im
Voraus aufkommende Problemsituationen zu erkennen. Zum Beispiel kann viel Schaden
vermieden werden, wenn früh festgestellt wird, falls ein Mitarbeiter mit seinen auszufüh-
renden Aktivitäten überfordert sein wird, um dem noch entgegenwirken zu können.
Kapitel 5
Ausblick: Unterstützung bei Zeitproblemen
In diesem Kapitel werden Hilfen für den Umgang mit Zeitproblemen und deren Vorbeu-
gung vorgestellt. Zunächst wird der Hintergrund von Process Aware Information Systems
erläutert. Im nächsten Abschnitt werden Unterstützungen aus technischer Seite für den
Entwurf und die Ausführung eines Prozesses mit Zeitbedingungen aufgeführt. Dabei wird
insbesondere auf den Unterschied zwischen dem Anspruch an ein solches System und des-
sen heutigen Stand eingegangen. Des Weiteren werden Methoden zur Sicherstellung der
Korrektheit der Zeitbedingungen eines Prozesses vorgestellt. Im dritten Teil dieses Kapitels
wird die Idee und der Zweck der bereits zuvor erwähnten Personal Schedules erläutert.
5.1 Process Aware Information Systems (PAIS)
Im Fazit von Kapitel 4 wird unter anderem aufgeführt, wie wichtig und bedeutend es ist,
dass während der Prozessausführung alle am Prozess Beteiligten den Überblick über den
Gesamtprozess behalten. Um diesen Überblick gewährleisten zu können, sollte man sich
die Struktur von PAIS (deutsch: Prozessorientierte Informationssysteme) bewusst machen.
PAIS bietet Softwareunterstützung bei der Ausführung von Prozessen, deren Ansatz sich
durch eine explizite Beschreibung von Prozessen kennzeichnet. Dies geschieht durch die
strikte Trennung von Prozesslogik und Anwendungscode [WRRM08]. Das Ziel hierbei ist
eine höhere Anpassungsfähigkeit der Prozesse [WWRD07].
Der Prozess wird dazu aus verschiedenen Perspektiven betrachtet und modelliert [vRD07]:
•Prozessperspektive: beschreibt den Kontrollfluss, wie zum Beispiel die Reihenfolge
der Ausführung der Aktivitäten
•Datenperspektive: bezieht sich auf die verwendeten Daten und deren Verarbeitung
im Prozess
49
50 5 Ausblick: Unterstützung bei Zeitproblemen
•Ressourcenperspektive: gibt den strukturellen Zusammenhang der einzelnen Ressour-
cen – menschliche Mitarbeiter oder technisches wie Software oder Hardware – wieder
•Tätigkeitsperspektive: beschreibt den Inhalt der einzelnen Arbeitsschritte: Was muss
gemacht werden? Wann muss es gemacht werden? Wer ist dafür zuständig?
•Kontextperspektive: beschreibt das Umfeld, in dem der Prozess durchgeführt werden
soll
•Durchführungsperspektive: beinhaltet relevante Abschätzungen für eine sichere Durch-
führung
Läuft eine Prozessinstanz ohne Fehler ab, so entspricht die Ausführung der Aktivitäten
dem gegebenen Kontrollfluss, die Daten werden nach Plan (der Datenperspektive) erstellt
und übergeben und alle Aktivitäten werden von den ihnen in der Ressourcen- bzw. Tätig-
keitsperspektive zugeordneten Ressourcen ausgeführt.
Da dies nicht immer der Fall ist und es wichtig ist, aufkommende Fehlersituationen so
früh wie möglich zu entdecken, sollte ein ständiger Überblick über den Gesamtprozess
gewährleistet sein. Dazu müssen alle genannten Perspektiven regelmäßig auf Korrektheit
überprüft werden. Somit kann der Zustand des laufenden Prozesses strukturiert mit dem
aufgestellten Plan der Ausführung verglichen und auf Übereinstimmung geprüft werden.
Vergleicht man die Eigenschaften, nach denen die Fehlerursachen in Kapitel 4 gruppiert
sind, mit den genannten Perspektiven von PAIS, so lassen sich einige Zusammenhänge
finden. Zum Beispiel werden in 4.1.2 die Ursachen analysiert, die aus der Ressourcenper-
spektive heraus zu einer Verzögerung des Starts einer Aktivität führen.
Um auftretende Fehlersituationen schnell und zielführend lösen zu können, ist es nötig,
die Fehlerursachen im Kontext des Gesamtprozesses zu analysieren. Dazu ist es hilfreich,
die Ursachen zunächst den entsprechenden beschriebenen Perspektiven zuzuordnen (wie
in Kapitel 4). Tritt der Fehler zum Beispiel auf Grund fehlender Daten auf, so ist es zweck-
mäßig, den Prozess „aus der Datenperspektive“ betrachten und diese als Grundlage einer
Eskalationsbehandlung nehmen. Jedoch muss man sich im Klaren darüber sein, dass ein
PAIS dazu beiträgt eine Eskalation zu verhindern aber im Falle einer Eskalation kaum
Unterstützung leisten kann.
5.2 Systemunterstützung zur Überprüfung von Korrektheit
von Prozessmodellen und -abläufen
Wie in Kapitel 4.4 aufgeführt, ist ein möglicher Grund für zeitbedingte Fehlsituationen
ein inkorrektes Prozessmodell. Als Ursachen dafür wurden vier Punkte genannt: Inkon-
sistenz im Prozessmodell, Prozessmodell entspricht nicht der Realität, Aktivität ungültig
und während der Ausführung festgelegte Termine sind nicht einhaltbar.
Vor der Prozessausführung sollte daher gewährleistet werden, dass der Prozess in sich
korrekt ist. Gerade die ersten beiden genannten Ursachen können dadurch im Voraus ver-
hindert werden und sollten daher keinesfalls bei der Prozessausführung auftreten. Welche
5.2 Systemunterstützung zur Korrektheit von Prozessen 51
Mittel es gibt, die Korrektheit eines Prozesses sicherzustellen und in wie weit es noch
bestehenden Bedarf an technischen Hilfsmitteln gibt, wird im Folgenden beschrieben.
5.2.1 Der Stand von Heute
Die angebotene Unterstützung bzgl. zeitlicher Aspekte in realen Prozessmanagementsys-
temen ist heute auf die Simulation von Prozessen beschränkt: Es können Engpässe iden-
tifiziert und die Ausführungsdauer der Aktivitäten analysiert werden [EPR99]. Jedoch
gibt es weder Unterstützung bei der Definition, Entdeckung oder dem Management von
zeitlichen Vorgaben, noch für die Sicherstellung der Konsistenz im Prozess, noch bei der
Entdeckung von Seiteneffekten von Fehlersituationen [CP09]. Man kann von Systemseite
aus keinerlei Urteilsvermögen über die Korrektheit des Prozesses erwarten [EL95]. Es ist
lediglich möglich, den kürzesten, den längsten und den kritischen Pfad berechnen zu las-
sen [Mar99], wobei der kritische Pfad durch denjenigen Pfad beschrieben wird, bei dessen
Ausführung keinerlei Zeitpuffer bestehen bleibt und somit keine Verzögerungen auftreten
dürfen.
Folglich ist es möglich, einen Prozess schematisch zu entwerfen, wie es zum Beispiel in
Abbildung 2.2 dargestellt ist, jedoch müssen sämtliche Zeitangaben „von Hand“ festgelegt
werden. Das System ist beispielsweise nicht in der Lage, die Deadline einer Aktivität zu
erschließen, selbst wenn diese aus dem Kontext eindeutig hervorgeht. Es kann lediglich die
Dauer der einzelnen Pfade abgeleitet werden. Des Weiteren wird von Systemseite aus nicht
auf Korrektheit bzw. auf Konsistenz des Prozessmodells geprüft, das heißt, diese Fehler
können nur durch menschliche Kontrolle gefunden und behoben werden.
5.2.2 Zukunftsvorstellung
In diesem Abschnitt wird beschrieben, durch welche Merkmale zukünftige Ziele gekenn-
zeichnet sind, was für deren Realisierung benötigt wird und durch welche Mittel dies
ermöglicht werden kann.
Ziel
Ein Ziel kennzeichnet sich dadurch, dass die Deadline von Aktivitäten berechnet wer-
den kann, sodass die Gesamtdeadline des Prozesses und sämtliche andere zeitliche Vor-
gaben eingehalten werden. Wird die Deadline für eine Aktivität nicht eingehalten, so ist
es wünschenswert, dass eine prozessspezifische Ausnahmebehandlung (Eskalation) durch-
geführt wird. Zudem sollte sichergestellt sein, dass der Prozess keinerlei Widersprüche
enthält [EPR99].
Abgesehen davon sollten die Dauer und Abstände zwischen den Aktivitäten (wenn nicht
explizit vorgegeben) auf Grund der vorgegebenen Bedingungen (soweit möglich) auto-
matisch erschlossen werden. Diese Informationen muss an alle Beteiligten weitergereicht
werden, soweit dies für sie von Nutzen ist. Zudem müssen Spezialfälle und Prioritäten be-
rücksichtigen werden. Als Beispiel dafür betrachte man eine Organtransplantation: Zwei
52 5 Ausblick: Unterstützung bei Zeitproblemen
verschiedene Aktivitäten müssen exakt gleichzeitig enden (Organentnahme und Vorberei-
tung des Patienten für die Transplantation) und diese Aktivitäten haben Priorität vor
nicht lebensbedrohlichen Standard-OPs (zum Beispiel kann eine OP für ein neues Hüft-
gelenk deshalb verschoben werden).
Das Prozessmanagementsystem sollte die Dauer von Aktivitäten und die gegebene Anord-
nungsreihenfolge aufführen und begründen können. Risikosituationen sollten früh entdeckt
und verhindert werden. Eventuell ist es sinnvoll, schon eine frühzeitige Eskalation einzu-
leiten [EPR99].
Die Möglichkeit einer Ausführung muss immer gegeben sein [BWJ02]. Ist ein Prozess nicht
in dem Zustand, dass er korrekt ausgeführt werde kann, so muss ein sog. Re-Engineering
eingeleitet werden [EPR99], bei dem der Prozess korrigiert und optimiert wird. In Folge
dessen müssen sämtliche Ausführungspfade kontrolliert werden, da durch die Änderungen
evtl. neue Fehler entstanden sind [CP09].
Was ist für die Realisierung der genannten Ziele nötig?
Nötig sind spezielle Techniken, die die Korrektheit der Zeitvorgaben während des Ent-
wurfs und der Ausführung überprüfen und das Einhalten dieser Bedingungen (die inneren
Deadlines und vorgegebenen Abstände) überwachen können. Es sind Mechanismen nötig,
die dem Prozessmanager melden, sobald eine Zeitverletzung droht. Mitarbeiter müssen
automatisch Information über die Dringlichkeit bzw. die Wichtigkeit der anstehenden Ak-
tivität erhalten, um eigenständig Prioritäten setzen und ihr Arbeitsverhalten entsprechend
anpassen zu können. Wird eine zeitliche Vorgabe verletzt, so muss es eine entsprechende
Komponente im System geben, die eine Ausnahmebehandlung einleitet und die Instanz
wieder in einen stabilen Zustand überführt. Um den vielen entstehenden Ausnahmen ge-
recht zu werden, ist hierfür ein Framework mit klarer Semantik von Nöten [DRK97].
Mittel zur Realisierung
Während der Entwurfsphase eines Prozesses ist es nötig, einen Ausführungsplan (Pro-
zessmodell) zu erstellen, der keine Zeitvorgaben verletzt. Ist dies nicht widerspruchsfrei
möglich, so enthält der Prozess Inkonsistenzen. Befindet sich der Prozess schon in der Aus-
führung, so kann das besagte Prozessmodell auf absolute Zeitangaben transferiert werden,
um sicherzustellen, dass äußere Vorgaben eingehalten werden. Im Laufe der Prozessausfüh-
rung muss dieses Modell immer wieder dynamisch aktualisiert werden, da möglicherweise
die vorherigen Schritte nicht alle nach Plan abgelaufen sind. Eine zusätzliche Unterstüt-
zung beim Entdecken aufkommender Fehler kann durch eine sogenannte guarding time
gegeben werden [BWJ02]. Diese beschreibt immer den nächsten Zeitpunkt im laufenden
Prozess, an dem ein Ereignis auftreten soll, zum Beispiel den Start einer Aktivität. Wird
dieser Zeitpunkt ohne Eintritt des gewünschten Ereignisses überschritten, so wird eine
Eskalation eingeleitet.
Wird vor oder während der Prozessausführung klar, in welchem Zeitraum eine Aktivität
ausführbar ist, so kann mit dem Planen begonnen werden, d.h. die nötigen Ressourcen
5.3 Personal Schedules 53
werden reserviert und die Bearbeiter informiert. Dabei wird die Aktivität unter anderem
in den Zeitplan des betroffenen Bearbeiters eingefügt. Hierbei wird die exakte Ausfüh-
rungszeit der Aktivität festgelegt (siehe Kapitel 5.3).
Müssen auf Grund einer Eskalation während der Laufzeit Änderungen am Prozessmodell
vorgenommen werden, so sollten die neuen Instanzen unmittelbar mittels der Aufstellung
des oben genannte Modells überprüft werden, um sicherzustellen, dass bei der Eskalati-
onsbehandlung keine (neuen) Fehler entstanden sind [CCPP98].
5.3 Personal Schedules
Wie schon zuvor erwähnt, ist es für einen erfolgreichen Prozessablauf äußerst wichtig, dass
alle Beteiligten möglichst genau wissen, was und wie viel an zu erledigenden Aufgaben in
(naher) Zukunft auf sie zukommen wird. Beim Ansatz der Personal Schedules [EPR99]
wird hierfür für jeden Mitarbeiter ein Zeitplan angefertigt, in dem seine Aufgaben für
die nahe Zukunft stehen (möglichst weit in die Zukunft blickend). Dadurch werden die
Mitarbeiter nicht jedes Mal von einer neuen Aufgabe „überrascht “, sondern können ihre
Auslastung im Voraus abschätzen und sich dadurch zum einen ihre Zeit sinnvoll einteilen
und zum anderen auch Prioritäten zwischen den einzelnen Aktivitäten setzen.
Da das größte Problem beim Abschätzen eines Prozesses, darin besteht, dass man nicht
genau weiß, wie dieser ablaufen wird, müssen die Personal Schedules in der Lage sein, sich
dynamisch anzupassen. Der Grund hierfür ist einerseits, dass es in einem Prozess häu-
fig mehrere mögliche Ausführungspfade gibt und andererseits, dass die realen Zeiten auf
Grund sämtlicher örtlicher Gegebenheiten oft ein wenig von den geschätzten Zeiten ab-
weichen. Abgesehen davon muss der Prozess evtl. während der Ausführung bedingt durch
Eskalationen geändert werden. Um den Ausführungsweg eines Prozesses besser abschätzen
zu können, werden Parameter eingeführt, die die Wahrscheinlichkeit für die Ausführung
einzelner Pfade probabilistisch beschreiben. Es müssen somit regelmäßig die neuesten In-
formationen eingebracht und dadurch auch die Ausführungszeiten angepasst werden. Um
die Personal Schedules zu erstellen, ist es erforderlich, zuerst einen Zeitplan des Prozesses
aufzustellen. Er beinhaltet alle Aktivitäten mit den zugehörigen Informationen: Dauer,
Voraussetzungen, Wahrscheinlichkeit ihres Eintretens.
Mit Hilfe der gegebenen Prozessperspektive und der Ressourcen- bzw. Tätigkeitsperspekti-
ve können die einzelnen Tätigkeiten anschließend den Ressourcen zugeordnet werden. Für
jede einzelne Aktivität kann auf Grund der zu Beginn feststehenden möglichen Ausfüh-
rungspfade eines Prozesses ein sicherer Zeitbereich definiert werden. In diesem Zeitraum
steht die Aktivität zu 100% zur Ausführung bereit. Dieser Bereich ist in allen möglichen
Ausführungswegen des Prozesses eingeschlossen. Abbildung 5.1 zeigt die Aktivitäten, die
in naher Zukunft auf einen Mitarbeiter M zukommen werden. Die Aktivitäten sind mit
ihrer zugehörigen Dauer und der Wahrscheinlichkeit ihres Eintretens zum Zeitpunkt t auf-
geführt. Zudem existiert ein Wert X, der angibt, wie hoch die Wahrscheinlichkeit ist, dass
die Aktivität gar nicht zur Ausführung kommt.
In dem Beispiel aus Abbildung 5.1 werden die Aktivitäten A,B,C sicher ausgeführt (X=0)
54 5 Ausblick: Unterstützung bei Zeitproblemen
A 6
0,00
0,80
1,00
XX
010
310
B 8
0,00
0,90
1,00
XX
820
1220
C12
0,00
0,10
1,00
XX
1837
1830
D 6
0,90
0,50
1,00
XX
2548
2535
InstanzAInstanzBInstanzCInstanzD
A 6
0,00
0,80
1,00
XX
010
310
AktivitätADauerd=6
X=0
Awirdzu0% nichtausgeführt
Awirdzu100%ausgeführt
Astehtzu80% imZeitabschnitt0‐10 zurAusführungbereit
Akannzu100% imZeitabschnitt3‐10 ausgeführtwerden
Abbildung 5.1: Beispiel von zukünftigen Aufgaben für Mitarbeiter M
und D nur zu 10% (X=0,9). Aus diesen Angaben wird nun der in Abbildung 5.2 darge-
stellte Personal Schedule erstellt. Ziel ist es dabei, dass dieser so sicher wie möglich (d.h.
ein möglichst hoher Anteil der Aktivitäten befindet sich zur eingeplanten Ausführungs-
zeit in ihrem sicheren Bereich) ist und sich keine Aktivitäten überschneiden. Ein Personal
Schedule wird dann als sicher bezeichnet, wenn alle Aktivitäten in ihrem sicheren Bereich
ausgeführt werden. Im Beispiel aus Abbildung 5.1 ist es unmöglich, einen sicheren Personal
Schedule zu erstellen, da sich die sicheren Bereiche der Aktivitäten überschneiden. Abbil-
dung 5.2 zeigt den sicherst möglichen Personal Schedule für Mitarbeiter M. Anhand dieses
Diagramms kann Mitarbeiter M nun seine Zeit sinnvoll einteilen, da er in der Lage ist,
die Aufgaben, die auf ihn zukommen abzuschätzen und sinnvoll einzuteilen. Darüber hin-
aus können in solch einem Personal Schedule Prioritäten für die Aktivitäten eingetragen
werden, damit Mitarbeiter M bei einem Sonderfall schnelle und sinnvolle Entscheidungen
treffen kann. Ein weiterer Vorteil von Personal Schedules zeichnet sich dadurch aus, dass
man auf Terminwünsche der Mitarbeiter Rücksicht nehmen kann. Möchte beispielsweise
Mitarbeiter M zum Zeitpunkt t=20 einen Tag Urlaub nehmen, so kann versucht werden,
diesen Termin freizuhalten.
Damit ein Personal Schedule realistisch ausführbar ist, ist es äußerst wichtig, beim Er-
stellen die örtlichen Gegebenheiten zu berücksichtigt. Ist zum Beispiel ein Arzt in einer
OP eingeteilt, die von 8:00 - 9:00 Uhr geplant ist und beginnt um 09:00 Uhr eine Untersu-
chung, die dieser Arzt durchführen soll, so ist das nur dann realisierbar, wenn der OP-Saal
direkt neben dem Raum ist, in dem die Untersuchung stattfinden soll. Handelt es sich um
einen großen Klinikkomplex, so müssen sämtliche Wege, die zwischen den Aktivitäten zu-
rückzulegen sind, miteinberechnet werden [Man11]. Weitere Details zu Personal Schedules
finden sich in [EPGN03].
5.3 Personal Schedules 55
ZEIT IN PROZESSMANAGEMENTSYSTEMEN
bei 12 beginnt. In Abbildung 4 ist dies durch die rote Farbe markiert. Die
Wahrscheinlichkeit für einen Erfolg liegt dennoch bei 0,9. Aktivität D startet nun bei
30 (direkt nach Beendigung von C) und dauert bis 36. Auch hier liegt die
Wahrscheinlichkeit für eine gelungene Ausführung nur bei 0,5 (die Balkenfarbe in
Abbildung 4 für den letzten Zeitschritt ist rot, D ist im Bereich 35-36 nur zu 50%
ausführbar), wobei man an dieser Stelle auch beachten sollte, dass D nur zu 10% zur
Ausführung kommt. Aktivität A kann nun bei 4 starten, liegt also ganz in ihrem
sicheren Bereich (dieser ist zwischen 3 und 10). Alles in allem liegt die Zulässigkeit
dieses Prozesses bei 0,9*0,5=0,45, was bedeutet, dass der Prozess zu 45% erfolgreich
ablaufen wird. Die Zulässigkeit berechnet sich durch die Multiplikation der
Erfolgswahrscheinlichkeiten der geplanten unsicheren Bereiche (hier: B wird mit
einer Wahrscheinlichkeit von 0,9 erfolgreich sein und D mit einer Wahrscheinlichkeit
von 0,5). Kommt D nicht zur Ausführung, so liegt die Zulässigkeit bei 0,9, es besteht
also eine Erfolgsaussicht von 90%. Würde man B ganz im sicheren Bereich ablaufen
lassen, so müsste C ausweichen und die Zulässigkeit läge nur noch bei 0,1. Wäre es
möglich, alle Aktivitäten in ihrem sicheren Bereich zu behandeln, so gäbe es in
Abbildung 4 keine roten Balkenabschnitte und die Zulässigkeit entspräche 100%.
Ein weiterer Vorteil von Personal Schedules zeichnet sich dadurch aus, dass man
auf Terminwünsche der Mitarbeiter Rücksicht nehmen kann. Möchte beispielsweise
Mitarbeiter M zum Zeitpunkt t=20 einen Tag Urlaub nehmen, so kann man
versuchen, diesen Termin freizuhalten. Natürlich wieder unter Berücksichtigung der
zeitlichen Möglichkeiten der Aktivitäten. Weitere Einzelheiten zu Personal Schedules
finden sich in [3].
Abbildung 4 Personal Schedule von Mitarbeiter M
Sicheres Intervall
Unsicheres Intervall
Geplant + sicher
Geplant+ unsicher
Abbildung 5.2: Personal Schedule für Mitarbeiter M
Kapitel 6
Zusammenfassung
In dieser Arbeit wurden mögliche Verletzungen von Zeitbedingungen im Kontext von Ge-
schäftsprozessen und ihre unmittelbaren Konsequenzen differenziert und analysiert. Die
einzelnen Ursachen lassen sich in verschiedene Kategorien einteilen. Hierzu wird zunächst
unterschieden, zu welcher Art zeitlicher Vorgabenverletzung die einzelnen Ursachen füh-
ren (zum Beispiel zum Verpassen eines vorgegebenen Startzeitpunktes einer Aktivität).
Anschließend werden Ursachen in solch einer Kategorie nach bestimmten Kriterien grup-
piert (zum Beispiel Bearbeiter nicht vorhanden). Es wurden spezifische und übergreifende
Lösungen für die aus der Verletzung einer Zeitbedingung entstehenden Probleme vorge-
stellt, die im Rahmen einer entsprechenden Eskalation angewendet werden können um den
Prozess wieder in einen sinnvollen Ablauf zu überführen. Diese lassen sich folgenderma-
ßen zusammenfassen: Abhängigkeiten ignorieren, die Aktivität oder den gesamten Prozess
umstrukturieren, die vorgegebene Deadline verschieben, Ad-hoc-Maßnahmen ergreifen wie
zum Beispiel zusätzliche Ressourcen hinzuziehen.
Neben den Lösungen wurden auch prophylaktische Maßnahmen diskutiert. Dabei fällt auf,
dass sich viele Fehler vermeiden lassen, wenn ein Management existiert, dessen ständiger
Überblick über sämtliche in Zusammenhang miteinander stehenden Prozesse sichergestellt
ist. Außerdem muss eine Kommunikation zwischen den verschiedenen Aktivitäten und Pro-
zessen möglich sein. Des Weiteren hat es sich in verschiedenen Situationen als besonders
wichtig herausgestellt, eine aufkommende Verletzung einer Zeitbedingung so früh wie mög-
lich zu entdecken. Zum einen, weil sie dann noch verhindert oder frühzeitig eine Eskalation
eingeleitet werden kann. Zum anderen sollte eine notwendige Umstrukturierung des Pro-
zesses (Aktivitäten vertauschen oder Deadlines verschieben), möglichst früh geschehen um
weitere Komplikationen zu verhindern. Um Fehler im Prozessablauf entdecken zu können,
sind genaue Anordnungen bzgl. des Prozessablaufs, wie zum Beispiel Abhängigkeiten zwi-
schen den Aktivitäten, festgesetzte Termine und benötigte Ressourcen, sowie möglichst
ausführliche Angaben über sämtliche örtliche Gegebenheiten für den Entwurf des Prozes-
ses nötig. Zudem muss die Korrektheit des Prozesses soweit möglich vor der Ausführung
57
58 6 Zusammenfassung
des Prozesses sichergestellt sein.
Tritt eine Eskalation auf, so kommt die Frage auf, wer für die Behandlung der Eska-
lation zuständig ist. Wünschenswert wäre ein Prozessmanagementsystem, das für jeden
möglichen aufkommenden Fall eine passende Lösung liefern kann. Um gegen sämtliche
Ausnahmen und Änderungen gerüstet zu sein, müsste jede einzelne davon vom Prozess-
designer im Voraus berücksichtigt werden, was ein sehr komplexes und unübersichtliches
Modell zur Folge hätte und zusätzlich Einschränkungen mit sich bringen würde, da Ad-
hoc-Änderungen erschwert wären, was im Widerspruch dazu steht, dass in einem Modell
die Dynamik des Prozesses abgebildet aber nicht eingeschränkt werden soll. Zudem ist
auch das umfangreichste Modell nie zu hundert Prozent gegen Ausnahmesituationen ab-
gesichert. Daraus folgt die These, dass der Mensch an dieser Stelle niemals komplett ersetzt
werden kann. Dennoch ist es größte Mühe Wert, ein Prozessmanagementsystem zu entwi-
ckeln, das entstehende Fehlersituationen sofort bemerkt und dies signalisiert. Denn gerade
bei komplexen und umfangreichen Prozessen, wie zum Beispiel einem Klinikprozess, ist
es für einen Menschen ohne Hilfe von Systemseite unmöglich, jede zeitliche Verzögerung
sofort zu realisieren und einzuordnen. Ist zum Beispiel um 10 Uhr eine OP geplant, zu
der Krankenschwester X als Ressource eingeteilt ist, so muss diese mindestens eine halbe
Stunde früher in der Klinik ankommen, um sich für die OP vorzubereiten. Sind die genann-
ten Informationen einem System gegeben, so wird es registrieren, falls Krankenschwester
X um 9.30 Uhr noch nicht zum Dienst angetreten ist, da alle Mitarbeiter beim Eintritt
in die Klinik elektronisch „stempeln“. Daraufhin wird dem Prozessmanager eine Meldung
erteilt. Dieser kann die Ursache der Abwesenheit von Krankenschwester X herausfinden
und danach individuell entscheiden, ob die OP dennoch zum geplanten Zeitpunkt gestartet
wird.
Gerade in Klinikprozessen ist es schwierig, ein System zu entwickeln, das von selbst Eska-
lationsbehandlungen einleitet, da es sich bei den Geschäftsobjekten um Menschen handelt.
Das heißt, alle Entscheidungen müssen individuell getroffen werden, Prioritäten können
in kein System eingetragen werden. Aber gerade im medizinischen Bereich ist es außeror-
dentlich wichtig, Ausnahmesituationen früh und schnell zu bemerken, denn in diesem Fall
gilt nicht nur „Zeit ist Geld“ sonder auch „Zeit ist Leben“ und dafür wird ein zuverlässiges
Softwaresystem benötigt. Ein Prozessmanagementsystem sollte somit als Unterstützung
des Menschen bei der Prozessausführung verstanden werden. Es ist durchaus wichtig, das
System möglichst intelligent zu entwerfen und mit vielen Informationen zu füllen, damit es
nicht nur aufkommende Problemsituationen frühzeitig feststellt, sondern auch dem Pro-
zessmanager im Falle einer Eskalation sinnvolle Lösungsvorschläge unterbreiten kann, aus
denen dieser dann nur noch einen angemessenen auswählen muss.
Damit der Prozessmanager die richtigen Entscheidungen treffen kann, muss dieser stets
den Überblick über den Prozess bewahren. Um das zu ermöglichen, gibt PAIS eine struktu-
rierte Einteilung des Prozesses vor. Für einen gerechten Umgang mit Eskalationen wurden
mit der 3D-Methode und dem ECA-System hierfür passende Ansätze vorgestellt. Nicht
nur der Prozessmanager muss gut über den Ablauf des Prozesses informiert sein, son-
59
dern auch alle übrigen Beteiligten. Die jeweiligen Bearbeiter der Aktivitäten müssen im
Bilde ihrer zukünftigen Aufgaben und deren Prioritäten sein, um ihr Arbeitsverhalten
dementsprechend anpassen zu können. Um dies zu realisieren, eignen sich die vorgestell-
ten Personal Schedules. Die Mitarbeiter können aufkommende Problemsituationen somit
frühzeitig erkennen und ihre Zeit einteilen sowie ihr Arbeitsverhalten anpassen.
Literaturverzeichnis
[BWJ02] Bettini, Claudio ; Wang, X. S. ; Jajodia, Sushil: Temporal Reasoning
in Workflow Systems. In: Distributed and Parallel Databases 11 (2002), S.
269–306
[CCPP98] Casati, F. ; Ceri, S. ; Pernici, B. ; Pozzi, G.: Workflow evolution. In:
Data & Knowledge Engineering 24 (1998), Nr. 3, S. 211 – 238
[CGJ+07] Combi, C. ; Gozzi, M. ; Juarez, J.M. ; Oliboni, B. ; Pozzi, G.: Conceptual
Modeling of Temporal Clinical Workflows. In: Temporal Representation and
Reasoning, 14th International Symposium on, 2007, S. 70–81
[CP09] Combi, Carlo ; Posenato, Roberto: Controllability in Temporal Concep-
tual Workflow Schemata. In: Dayal, Umeshwar (Hrsg.) ; Eder, Johann
(Hrsg.) ; Koehler, Jana (Hrsg.) ; Reijers, Hajo (Hrsg.): Business Process
Management Bd. 5701, Springer Berlin / Heidelberg, 2009 (Lecture Notes in
Computer Science), S. 64–79
[DRK97] Dadam, Peter ; Reichert, Manfred ; Kuhn, Klaus: Clinical Workflows -
The Killer Application for Process-oriented Information Systems? / Univer-
sität Ulm, Institut DBIS. Universität Ulm, 1997 (UIB-1007-16). – Technical
Report
[EL95] Eder, Johann ; Liebhart, Walter: The Workflow Activity Model WAMO.
In: Proceedings of the 3rd International Conference on Cooperative Infomati-
ons Systems, 1995, S. 87–98
[EPGN03] Eder, Johann ; Pichler, Horst ; Gruber, Wolfgang ; Ninaus, Michael: Per-
sonal Schedules for Workflow Systems. In: van der Aalst, Wil M. P. (Hrsg.)
;Hofstede, Arthur H. M. (Hrsg.) ; Weske, Mathias (Hrsg.): Proceedings
1st International Conference on Business Process Management (BPM’03)
Bd. 2678. Eindhoven, The Netherlands : Springer Berlin / Heidelberg, June
2003 (Lecture Notes in Computer Science), S. 216–231
[EPR99] Eder, Johann ; Panagos, Euthimios ; Rabinovich, Michael: Time Cons-
traints in Workflow Systems. In: Jarke, Matthias (Hrsg.) ; Oberweis, An-
V
VI Literaturverzeichnis
dreas (Hrsg.): Advanced Information Systems Engineering Bd. 1626, Springer
Berlin / Heidelberg, 1999 (Lecture Notes in Computer Science), S. 286–300
[Ges] Wikipedia - Definition von Geschäftsobjekt.
http://de.wikipedia.org/w/index.php?title=Geschäftsobjekt&oldid=92828585,
. – zuletzt besucht: 13/01/2012
[Hal10] Hallerbach, Alena: Management von Prozessvarianten, Universität Ulm,
Dissertation, 2010
[LWR10] Lanz, Andreas ; Weber, Barbara ; Reichert, Manfred: Workflow Time
Patterns for Process-Aware Information Systems. In: Bider, Ilia (Hrsg.) ;
Halpin, Terry (Hrsg.) ; Krogstie, John (Hrsg.) ; Nurcan, Selmin (Hrsg.)
;Proper, Erik (Hrsg.) ; Schmidt, Rainer (Hrsg.) ; Ukor, Roland (Hrsg.)
;Aalst, Wil (Hrsg.) ; Mylopoulos, John (Hrsg.) ; Rosemann, Micha-
el (Hrsg.) ; Shaw, Michael J. (Hrsg.) ; Szyperski, Clemens (Hrsg.) ;
Aalst, Wil (Hrsg.) ; Mylopoulos, John (Hrsg.) ; Rosemann, Michael
(Hrsg.) ; Shaw, Michael J. (Hrsg.) ; Szyperski, Clemens (Hrsg.): Enter-
prise, Business-Process and Information Systems Modeling Bd. 50, Springer
Berlin Heidelberg, 2010 (Lecture Notes in Business Information Processing),
S. 94–107
[Man11] Mans, Ronny: Workflow Support for the Healthcare Domain, Universität
Eindhoven, Dissertation, Beta, 2011
[Mar99] Marjanovic, Olivera: On modeling and verification of temporal constraints
in production workflows. In: Knowledge and Information Systems 1 (1999),
Nr. 2, S. 157–191
[Mey96] Meyer, Joachim: Anforderungen an zukünftige Workflow-Management-
Systeme: Flexibilisierung, Ausnahmebehandlung und Dynamisierung - Erör-
terung am Beispiel medizinisch-organisatorischer Abläufe, Universität Ulm,
Diplomarbeit, 1996
[ORS03] Owen, Martin ; Raj, Jog ; Software, Popkin ; Brocke, Jan V. (Hrsg.) ;
Rosemann, MichaelEditors (Hrsg.): BPMN and Business Process Manage-
ment Introduction to the New Business Process Modeling Standard / Popkin
Software. 2003 (May 2008). – Forschungsbericht. – 27 S.
[SK06] Schubert, Klaus ; Klein, Martina: Das Politiklexikon. 4. aktual. Aufl.
Dietz, 2006
[SMO99] Sadiq, Shazia W. ; Marjanovic, Olivera ; Orlowska, Maria E.: Managing
Change And Time In Dynamic Workflow Processes. In: International Journal
of Cooperative Information System 9 (1999), S. 93–116
VII
[SW95] Saastamoinen, Heikki ; White, George M.: On handling exceptions. In:
Proceedings of conference on Organizational computing systems. New York,
NY, USA : ACM, 1995 (COCS ’95), S. 302–310
[vRD07] van der Aalst, Wil M.P. ; Rosemann, Michael ; Dumas, Marion: Deadline-
based escalation in process-aware information systems. In: Decision Support
Systems 43 (2007), Nr. 2, S. 492–511
[WRRM08] Weber, Barbara ; Reichert, Manfred ; Rinderle-Ma, Stefanie: Change
patterns and change support features – Enhancing flexibility in process-aware
information systems. In: Data and Knowledge Engineering 66 (2008), Nr. 3,
S. 438–466
[WWRD07] Weber, B. ; Wild, W. ; Reichert, M. ; Dadam, P.: ProCycle - Integrierte
Unterstützung des Prozesslebenszyklus. In: Künstliche Intelligenz 12 (2007),
November, Nr. 4 / 20, S. 9–15
