Optimierung des persönlichen Arbeitslaufes mit Hilfe constraint-basierter Prozesse

Transkript

1 Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Optimierung des persönlichen Arbeitslaufes mit Hilfe constraint-basierter Prozesse Kai Bormann Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr. Frank Leymann Dipl.-Inf. Tobias Unger begonnen am: 16. November 2009 beendet am: 18. Mai 2010 CR-Klassifikation: C.4, E.1, F.2.2, H.1.2

2

3 Inhaltsverzeichnis 1 Einleitung Gliederung Hintergrundinformationen Workflow Management Systeme Geschäftsprozesse Human Tasks Constraints Harte Constraints Weiche Constraints Scheduling Grundbegriffe Scheduling Probleme Konzept Anforderungen an das Human Task Modul Übersicht Komponenten Task Manager Work Item Handler Work List Handler Scheduler Datenhaltung Graphical User Interface (GUI) Zustände von Human Tasks Resource Mensch Implementierung Verwendete Technologien Architektur des Human Task Managers Erweiterung des vorhandenen Human Task Managers Datenstruktur Diskussion Analyse vorhandener Systeme Scheduling Modelle integriert in Workflow Managment Systemen Vergleich der Scheduling Modelle in Workflow Managment Systemen

4 6 Zusammenfassung und Ausblick Zusammenfassung Ausblick über Erweiterungsmöglichkeiten

5 Abbildungsverzeichnis 2.1 Vier Möglichkeiten um Human Tasks in BPEL4People zu integrieren [LCo10] Einfacher Workflow Prozess mit den 5 Basismodellierungselementen ER-Diagramm für eine einfache Organisationsstruktur Ansicht einer Organisationsstruktur Zustandsdiagramm Human Task [AAo07b] Basisrelationen nach Allen [RLo] Reihenfolgeänderung von zwei Tasks [Pin08] Optimaler Belegungsplan für F2 C max Optimaler Belegungsplan für J2 Cmax Komplexitätshirachie aufgeteilt in leichte und NP schwere Probleme Architektur Human Task Modul Verarbeitungsreihenfolge der Tasks Einsortierung von dringenden Tasks ER Diagramm der Datenstruktur Zustandsdiagramm Human Task abgeleitet von [AAo07b] Architektur des Human Task Managers [Wag10] Datenstruktur des Human Task Managers [Wag10] Erweiterte Architektur Gegenüberstellung von FIFO, EDD und GA Erweiterung: Mehrere Personen bearbeiten eine Taskinstanz Erweiterung: Die von mehreren Personen bearbeitete Taskinstanz kommt zur Zuteilung Tabellenverzeichnis 2.1 Notation nach Graham Bearbeitungszeiten in Abhänigkeit der Ressourcen Bearbeitungszeiten und zeitliche Constraints in Abhängigkeit der Ressourcen 25 5

6

7 1 Einleitung Workflow Management Systeme dienen der Automatisierung und Optimierung von Geschäftsprozessen. Der Mensch wurde dabei als Bestandteil eines solchen Prozesses nicht berücksichtigt. Neuste Systeme beziehen den Menschen zwar mit ein, stellen ihm jedoch keine weiteren Hilfmittel zur Optimierung seiner Arbeit zur Verfügung. In dieser Arbeit wird das Konzept eines Human Task Manager Moduls vorgestellt, welches in ein Workflow Management System integriert werden kann. Dieses Modul beschäftigt sich ausschließlich mit dem Menschen als Ressource und ist speziell auf diesen angepasst. So wird dem Benutzer eine Arbeitsliste vorgegeben, welche es ihm erlaubt, anstehende Aufgaben in der für ihn optimalen Reihenfolge zu bearbeiten. Dabei bleibt die Flexibilität des Benutzers erhalten und er kann als letzte Instanz entscheiden, ob er die vorgegebene Reihenfolge einhält oder nicht. Neue Aufgaben weist das Modul kontinuierlich und schnell den einzelnen Arbeitslisten verschiedener Benutzer zu. Diese Listen werden nach jeder abgeschlossenen Aufgabe neu berechnet. So kann das Modul auch kurzfristige Änderungen schnell umsetzen und an den Benutzer weitergeben. Dies soll den Menschen als Ressource mehr in den Geschäftsprozess miteinbeziehen ohne ihn dabei zu instrumentalisieren. Der Benutzer behält weiterhin die Kontrolle über die Arbeitsschritte, welche er letzten Endes ausführt. Das Modul trifft mit der Einteilung der anstehenden Aufträge lediglich eine Vorauswahl für den Benutzer. 1.1 Gliederung Die Arbeit ist in folgender Weise gegliedert: Kapitel 2 Hintergrundinformationen: Dieses Kapitel gliedert sich in drei Teile. Im ersten Teil werden Workflow Management Systeme vorgestellt. Der zweite Teil stellt zwei Constraintklassen vor, diese Zwangsbedinungen müssen oder sollten vom Scheduling Verfahren eingehalten werden. Die Notation von Scheduling Verfahren wird im letzten Teil behandelt. Kapitel 3 Konzept: In diesem Kapitel wird das Konzept vorgestellt, welches es ermöglicht flexibel auf die Bedürfnisse des einzelnen Benutzers einzugehen. Kapitel 4 Implementierung: Die Implementierung basiert auf einem bestehenden Task Manager. Die Anpassungen an den Task Manager werden hier beschrieben. Kapitel 5 Diskussion: Es wird die Integration von Scheduling Verfahren in Workflow Management Systemen betrachtet, die Vor- und Nachteile abgewägt. 7

8 1 Einleitung Kapitel 6 Zusammenfassung und Ausblick: Das letzte Kapitel enthält eine Zusammenfassung des Konzepts und einen Ausblick auf Erweiterungsmöglichkeiten. 8

9 2 Hintergrundinformationen Dieses Kapitel stellt die Grundlagen bereit, welche für das Verständnis der weiteren Kapitel wichtig sind. Es ist in drei Teile untergliedert. Im ersten Teil werden Workflow Management Systeme vorgestellt. Der zweite Teil befasst sich mit den unterschiedlichen Arten von Constraints. Im letzten Teil werden Scheduling Verfahren vorgestellt. 2.1 Workflow Management Systeme Workflow Management Systeme (WMS) unterstützen und überwachen die Ausführung von Geschäftsprozessen. Solche Systeme sind heutzutage ein wichtiger Bestandteil jeder Firma. Dabei greifen WMS auf Pozesslogik, Personaldaten und Firmendaten zurück, um eine optimale Durchführung der Prozesse zu gewährleisten. Geschäftprozesse werden mit Hilfe von BPEL (Business Process Execution Language) spezifiziert, einer XML-Skriptsprache, die speziell für die Bedürfnisse von Geschäftsprozessen entwickelt wurde. Allerdings ist es mit BPEL nicht möglich vom Menschen ausgeführte Arbeitsschritte, welche im Folgenden als Human Tasks bezeichnet werden, in die Prozesskette zu involvieren. Aus diesem Grund wurde BPEL4People entwickelt. Sie stellt eine Erweiterung der BPEL Sprache dar, mit dem Ziel Personen und Gruppen von Personen in die Geschäftsprozesse zu integrieren. BPEL4People Der Standard Web Service Human Task [AAo07b] gibt keine Architektur vor um Human Tasks zu verwalten. Er stellt nur einen Standard für die Spracherweiterung zu BPEL zur Verfügung. Die Human Tasks werden über das BPEL Konstrukt extensionactivity gekapselt. Die BPEL4People Spezifikation [LCo10] stellt dabei vier Möglichkeiten vor wie ein Human Task in einen Geschäftsprozess eingebunden werden kann, siehe Abbildung 2.1. Bei den ersten zwei Möglichkeiten befindet sich der Human Task innerhalb eines Prozesses. In den anderen beiden Fällen handelt es sich beim Human Task um eine Stand-Alone Lösung. Im ersten Fall wird der Human Task direkt als eingebetteter Task definiert, als Teil der BPEL Aktivität. Da der Human Task innerhalb der People Activity definiert ist kann er nur von dieser benutzt werden. Im zweiten Fall wird der Human Task als Top-Level Konstrukt definiert und kann somit als eine Scope Activity mehrfach wiederverwendet werden. Die Lösungen drei und vier sind, wie bereits erwähnt, Stand-Alone Lösungen. Das heißt, sie befinden sich außerhalb des eigentlichen BPEL4People Prozesses und werden als externer 9

10 2 Hintergrundinformationen Abbildung 2.1: Vier Möglichkeiten um Human Tasks in BPEL4People zu integrieren [LCo10] Prozess behandelt. Der Unterschied besteht im vierten Fall darin, dass dieser noch ein Web Service Interface besitzt, welches Web Service Protokolle aufrufen kann Geschäftsprozesse Komplette Firmen können mit Hilfe von Geschäftsprozessen modelliert werden. Vom Einkauf bis zum Verkauf des Produkts können alle Aufgaben in Geschäftsprozessen abgebildet werden. Hinzu kommen Geschäftsprozesse, die nicht direkt etwas mit dem verkaufenden Produkt zu tun haben. Zum Beispiel können auch das tägliche Sichern der Daten oder anfallende Wartungsarbeiten in Geschäftsprozessen abgebildet werden. Mit Hilfe dieser Geschäftslogik ist es nun möglich bestimmte Geschäftsteile zu analysieren, um sie anschließend zu optimieren. Ziel dieser Optimierung ist es, den Warendurchsatz zu erhöhen und damit Ressourcen zu sparen, um somit die Kosten zu senken [LR00]. Die Geschäftsprozesse können unter anderem mit Hilfe von BPEL [AAo07a], BPEL4People [LCo10], Petrie Netzen [Hag04] oder UML (Unified Modelling Lanaguage) [OMG07] modelliert werden. Dabei handelt es sich bei allen genannten Sprachen um imperative Modellierungssprachen. Bei diesen Sprachen wird der Prozessablauf detailliert vorgegeben. Jede zeitliche Abhängigkeit zwischen den einzelnen Tasks wird genau festgehalten. Abbildung 2.2 zeigt einen Geschäftsprozess, der die fünf Basismodellierungselemente enthält, modelliert mit Hilfe von BPMN (Business Process Modeling Notation), Version 2 [Whi04]. Die Spezifikation mit allen Modelierungsmustern ist unter [OMG09] zu finden. Die fünf Basismodellierungselemente sind: Sequenz: Die Tasks werden nacheinander ausgeführt. Im Beispiel werden T 3, T 6, T 7 und T 8 der Reihe nach ausgeführt. Parallel Split: Die Tasks werden parallel ausgeführt. Vergleichbar mit einer logischen UND-Bedingung. Im Beispiel werden T 2 und T 3 parallel ausgeführt. 10

11 2.1 Workflow Management Systeme Abbildung 2.2: Einfacher Workflow Prozess mit den 5 Basismodellierungselementen Synchronisation: Parallele Zweige werden wieder zu einem Pfad vereint. Im Beispiel wird T 1 0 aktiviert sobald T 8 und T 9 vollendet wurden. Exclusive Choice: Anhand einer definierten Bedingung wird ein Pfad ausgewählt. Im Beispiel wird T 4 oder T 5 ausgewählt, abhänig von deren Ergebnis. Simple Merge: Sobald ein Ergebnis vorliegt wird der nächste Task aktiviert. Im Beispiel wir T 9 gestartet sobald T 4 oder T 5 erfogreich beendet wurden. Leider weisen imperative Modellierungsmodelle Schwächen im Bezug auf Flexibilität auf. Die Festlegung der genauen Reihenfolge ist für Produktionsabläufe sehr gut geeignet, da dort der Ablauf fest definiert werden kann. Wenn die Reihenfolge dagegen irrelevant ist, oder beliebige Interationsfolgen möglich sein sollen, stoßen imperative Modellierungsmodelle an ihre Grenzen. Angenommen es gibt fünf Tasks und die Reihenfolge der Ausführung ist irrelevant, dann muss man mit imperativen Modellierungsmodellen ein Modell entwickeln, das 5! = 120 mögliche Reihenfolgen abbilden kann und zusätzlich einen ersten Task benennen, der eine Entscheidung trifft, welcher Task der nächste ist. Für dieses Beispiel benötigen deklarative Modellierungssprachen nur fünf Tasks [Aala]. In deklarativen Modellierungssprachen sind alle möglichen Reihenfolgen erlaubt, es sei denn sie sind ausdrücklich durch Constraints (Zwangsbedingungen) verboten [Aalb]. Dieses Vorgehen sorgt für mehr Flexibilität in der Abarbeitung der Tasks [Aala]. Daraus kann man leicht erkennen, dass imperative Modellierungsmodelle ziemlich unübersichtlich werden können, obwohl der eigentliche Vorgang recht einfach ist. Daher kann es auch passieren, dass für eine bessere Übersicht zusätzliche Constraints eingefügt werden. Im gerade beschriebenen Beispiel wäre es denkbar, dass doch eine gewisse Reihenfolge zwischen den fünf Tasks festgelegt wird Human Tasks Ein Task (Aufgabe) ist eine Arbeitseinheit, die am Stück durchgeführt werden kann. Wird diese von einem Computer automatisch durchgeführt nennt man sie nur Task. Wird sie von einem menschlichen Benutzer manuell durchgeführt, bezeichnet man sie als Human Task. Die Unterscheidung ist wichtig, da Mensch und Maschine eine unterschiedliche Arbeitsweise an den Tag legen. Die Aufgaben, die einer Maschine übertragen werden, 11

12 2 Hintergrundinformationen können genau spezifiziert werden. Ebenso ist es möglich die Antwortzeit und Verfügbarkeit genau zu bestimmen. Ein Mensch hingegen braucht für die Durchführung identischer Aufgaben unterschiedlich lange. Zum einen liegt dies an der Person, wenn die Aufgabe einem Personenkreis zugeordnet wird, zum anderen an der Tagesform dieser ausgewählten Person. Der Einfachheit halber ist im Folgenden immer ein Human Task gemeint wenn von einem Task die Rede ist. Eigenschaften von Human Tasks Hier eine kurze Liste der wichtigsten Eigenschaften einer Human Taskinstanz: Name: Der Name des Task Modells. id: Identifiziert die Task Instanz eindeutig. Status: Zeigt aktuellen Status des Tasks, zum Beispiel In Progress (siehe Zustände). Priorität: Der Wertebereich der Priorität ist frei wählbar. Werte für alle generischen humanen Rollen, welche unter Kapitel aufgeführt werden. Startzeit: Zeitpunkt zu dem der Task frühestens beginnen darf. Endzeit: Zeitpunkt zu dem der Task beendet sein muss. Sollte ein Task zu diesem Zeitpunkt nicht beendet sein, treten laut Spezifikation Eskalationsmechanismen in Kraft, die hier aber nicht näher untersucht werden. isskipable: Wird gesetzt, wenn der Task nicht mehr durchgeführt werden muss. Eingangsdaten: Werden benötigt, um den Task zu bearbeiten. Ausgangsdaten: Beinhalten das Resultat des Tasks. Man beachte, dass die Bearbeitungszeit eines Tasks in der Web Service Human Task Spezifikation keine Rolle spielt. Staff Assignment Die Zuweisung eines bestimmten Tasks zu einer bestimmten Person heißt Staff Assignment [LR00]. Dabei handelt es sich im Normalfall nicht um eine physische Person mit Name und Vorname sondern eher um eine Rolle, die diese Person in der Firma ausübt. Würde man einen Task einer Person direkt zuweisen, wäre das sehr unvorteilhaft, da bei Krankheit, Urlaub, Kündigung, etc. jedesmal der Name angepasst werden müsste. Die Rolle der Person kann sich zum Beispiel auf den Tätigkeitsbereich beziehen, den die Person ausübt, oder auf die Abteilung oder Position, die diese Person in der Firma genießt. Die Rolle dient also dazu, die Person zu verallgemeinern, damit nicht bei jeder Personaländerung alle involvierten Prozesse geändert werden müssen. Wenn es dann zur Bearbeitung des Tasks kommt, wird 12

13 2.1 Workflow Management Systeme Abbildung 2.3: ER-Diagramm für eine einfache Organisationsstruktur dieser einer Person zugewiesen, die der angegebenen Rolle zugewiesen wurde. Diesen Vorgang nennt man Staff Assignment. In Abbildung 2.3 zeigt ein vereinfachtes Diagramm eine Organisationsstruktur. Das ER-Diagramm zeigt die Beziehung zwischen einer Person, einer Rolle, die die Person übernimmt, und dem Task, den die Person zu bearbeiten hat. Jede Person übt mindestens eine Rolle aus. Zum Beispiel kann eine Person für die Personalabrechnungen zuständig sein und darüber hinaus auch für den Fuhrpark der Firma. Einer Rolle können mehrere Personen zugeordnet werden und ein Task kann von Personen, die genau einer Rolle angehören, ausgeführt werden. In diesem Beispiel kann auch einer Person direkt ein Task zugewiesen werden, was in der Praxis zu einem erheblichen organisatorischen Mehraufwand führen kann. Falls die Person einen anderen Tätigkeitsbereich übernimmt, muss nicht nur die Rolle angepasst werden, sondern auch alle Tasktypen, in denen die Person involviert ist. Organisationsstrukturen zeigen den Verantwortungsbereich einzelner Personen oder Gruppen auf. Abbildung 2.4 zeigt eine einfache Unternehmensstruktur. Die Kästchen symbolisieren hier die entsprechenden Zuständigkeitsbereiche, in oder unter den Kästchen sind die zugeteilten Personen aufgeführt. Jedes Kästchen mit den entsprechenden Personen kann somit einer Rolle zugeordnet werden. Diese Rollen werden auch in der Web Service Human Task Spezifikation als Logical People Group (LPG) definiert. Die Web Service Human Task Spezifikation [AAo07b] definiert drei Arten von Staff Assignments: 13

14 2 Hintergrundinformationen Abbildung 2.4: Ansicht einer Organisationsstruktur Logical People Group (LPG): Eine oder mehrere Personen werden einer logischen Benutzergruppe zugeordnet. Außerdem können LPGs wieder LPGs zugewiesen werden. Diese Benutzergruppen können in einer Datenbank verwaltet und während der Laufzeit dann aus der Datenbank gelesen werden. Literals: Menschen können direkt mit ihrem Namen oder indirekt über eine LPG zugewiesen werden. Expression: Menschen können über ein Attribut einer Rolle indirekt zugewiesen werden. Generic Human Roles Die Web Service Human Task Spezifikation [AAo07b] definiert Human Generic Roles. Mit Hilfe der Human Generic Roles können einzelne Personen oder Personengruppen verschiedenen Autorisierungsgraden zugeordnet werden. Somit können bestimmte Benutzergruppen nur definierte Operationen durchführen. Im Folgenden werden die wichtigsten aufgezählt. Task Initiator: Person, die den Task initialisiert (optional). Task Stakeholders: Personenkreis, der für die Taskinstanz verantwortlich ist, ihn überwacht und auch gegebenenfalls ändert. Dem Task Stakeholder muss mindestens eine Person zugewiesen sein. 14

15 2.1 Workflow Management Systeme Potential Owners: Personenkreis, der den Task bearbeiten und fertig stellen kann. Der Personenkreis kann aus einer oder mehreren Personen bestehen, die auch über eine Logical People Group gekapselt werden können. Die Potential Owners haben die Möglichkeit bestimmte Eigenschaften des Tasks zu bearbeiten, zum Beispiel die Priorität zu ändern. Actual Owner: Es gibt exakt eine Person, welche den Task letztendlich bearbeitet. Zusätzlich können bestimmte Taskeigenschaften bearbeitet werden. Zu ihnen zählen unter anderem Zurückweisung, Weiterleitung, Unterbrechung des Tasks oder auch Änderung der Priorität. Excluded Owners: Personen, die von der Bearbeitung der Tasks ausgeschlossen sind. Sie können nicht Potential oder Actual Owner werden. Business Administrator: Mindestens eine Person muss dieser Rolle zugewiesen werden. Sie besitzt dieselben Rechte wie der Task Stakeholder. Im Unterschied zum Task Stakeholder ist der Business Administrator für das ganze Task Modell zuständig, nicht nur für eine einzelne Instanz. Work Item Sobald ein Task einem Potenital Owner zugewiesen wird, spricht man von einem Work Item, das durch eine Person bearbeitet und fertiggestellt werden kann. Das Buch [LR00] stellt drei Arten vor, wie Work Items bereitgestellt werden können: Pull mode: Anwender muss Work Item explizit anfordern. Vorteil: Der Anwender behält die völlige Kontrolle über die Work Item Liste. Ohne sein Zutun bleibt die Liste unverändert. Nachteil: Er kann nicht auf hoch priorisierte Work Items reagieren, da diese erst nach seiner Anfrage in der Work Item Liste erscheinen. Push mode: Jedes erstellte Work Item wird sofort in die Work Item Liste des Anwenders eingetragen. Vorteil: Der Anwender sieht sofort neue Work Items. Nachteil: Die Work Item-Liste ändert sich ständig, dabei kann der Überblick verloren gehen. Grab mode: Dem Anwender wird ein neues Work Item bereitgestellt, wenn das aktuelle Work Item abgeschlossen wurde. Vorteil: Der Anwender bekommt automatisch das nächste Work Item zugewiesen. Nachteil: Der Anwender hat keinen Einfluss darauf, welches Work Item er als nächstes bearbeiten möchte. 15

16 2 Hintergrundinformationen Zustände von Human Tasks Abbildung 2.5 zeigt die möglichen Zustände, die ein Human Task laut [AAo07b] einnehmen kann. Create: Task wird in folgender Reihenfolge initialisiert: Eingabe Nachricht, Priorität, Generic Human Roles. Kann den Generic Human Roles keine Gruppe oder Person zugeordnet werden, wird eine leere Menge weitergegeben. Der Task bleibt solange in diesem Zustand bis er aktiviert und einem Potential Owner zugewiesen wurde. Ready: Task ist initialisiert. Der Task wurde aber noch keine Person zugewiesen. Reserved: Zuweisung einer Person ist erfolgt. Actual Owner wird gesetzt. Work Item wird noch nicht bearbeitet. In Progress: Work Item wird von der zugewiesenen Person bearbeitet. Complete: Bearbeitung des Work Items ist fehlerfrei abgeschlossen. Fehlerfälle: WS Human Task?? unterscheidet vier Fehlerfälle: Failed: Work Item wurde mit Fehler beendet. Error: Es trat ein Fehler, zum Beispiel beim Staff Assignment auf. Es wird kein Resulat zurückgegeben. Exit: Applikation beendet Work Item, bevor das Work Item beendet werden konnte. Obsolete: Actual Owner oder Business Administrator entscheidet, dass dieses Work Item nicht mehr von Bedeutung ist. Ein leeres Resulat wird zurückgegeben. Suspend: In diesem Zustand wird der Task eingefroren. 2.2 Constraints Constraints, zu deutsch Zwangsbedingungen, sind Vorgaben, die das Programm zum Lösen der anstehenden Tasks beachten muss. Sie kommen unter anderem bei Planungsproblemen zum Einsatz. Die Constraints können in zwei Klassen unterteilt werden. Zum einen gibt es harte Constraints. In diese Klasse fallen alle Constraints, die unbedingt eingehalten werden müssen. Zum Beispiel Task A muss vor Task B erledigt sein, da Task B Informationen benötigt die Task A erst bereitstellt. Die zweite Klasse sind weiche Constraints. Weiche Constraints müssen nicht zwingend eingehalten werden, sie dienen vielmehr der Optimierung. Dazu werden alle vorliegenden Tasks betrachtet, um eine optimale Reihenfolge für ihre Bearbeitung zu finden. Die beiden Constraintklassen schließen sich gegenseitig nicht aus. Vielmehr ist es sehr häufig so, dass ein Problem beide Constraintklassen beinhaltet. 16

17 2.2 Constraints Abbildung 2.5: Zustandsdiagramm Human Task [AAo07b] Harte Constraints Zu der Klasse der harten Constraints gehören die zeitbasierten Constraints. Sie müssen in Planungsproblemen zwingend eingehalten werden und dürfen sich nicht gegenseitig verletzen. Zeitbasierte Constraints werden bei der Erstellung eines Prozesses erhoben und auf ihre Richtigkeit geprüft. Die daraus resultierenden Abhängigkeiten gelten dann für alle Instanzen dieses Prozesses. Sie sind zwingend einzuhalten. Bei Nichteinhaltung liegt ein logischer Fehler in der Prozessanalyse vor. Es wird zum Beispiel ein Prozess definiert mit: A B, B C und C A, dann liegt ein logischer Fehler vor. Wird A B und B C ausgeführt hat das zur Folge, dass auch A C ausgeführt werden muss. Abbildung 2.6 zeigt einige zeitabhängige Constraints: Weitere harte Constraints sind die Einschränkungen an Ressourcen (Maschinen, Menschen, CPU, etc.). Steht die Ressource nicht zur Verfügung kann der Task nicht durchgeführt werden. Dabei muss es sich bei der Ressource nicht um eine einzelne Ressource handeln, es ist auch möglich eine Gruppe von Ressourcen zu definieren, welche den Task bearbeiten können. Hierbei muss beachtet werden, dass jede Ressource eine andere Bearbeitungszeit aufweisen kann. Nicht immer sind die Constraints so deutlich in harte und weiche Constraints zu trennen. Es ist sinnvoll Wartungsintervalle ebenso der Klasse der harten Constraints zuzuordnen. Werden Wartungsintervalle nicht oder nur unzureichend eingehalten kann es in sensiblen Bereichen wie zum Beispiel dem Flugverkehr, zu bedenklichen Sicherheitsproblemen kommen. Allerdings können Wartungsintervalle auch den weichen Constraints zugeordnet 17

18 2 Hintergrundinformationen Abbildung 2.6: Basisrelationen nach Allen [RLo] werden. Zum Beispiel kann definiert werden, dass Wartungsintervalle nur bei kleiner Auftragslage durchzuführen sind, um somit Zeit, beziehungsweise Geld, zu sparen Weiche Constraints Zu den weichen Constraints zählen alle Constraints, die nicht zwingend eingehalten werden müssen. Optimierungsbasierte Constraits werden eingesetzt um aus der Menge an gegebenen Tasks, aus unterschiedlichsten Prozessinstanzen, eine möglichst optimale Reihenfolge zu bestimmen. Welche Constraints zur Optimierung herangezogen werden entscheidet hierbei der Anwender. Je nach zu lösendem Problem kann der Schwerpunkt der Optimierung stark schwanken. Die gängigsten Schwerpunkte sind: Minimierung der Durchlaufzeit und Minimierung der Terminabweichung. Natürlich können hier auch andere Schwerpunkte, wie Minimierung der Fahrzeit, auftreten. Dies ist zum Beispiel relevant für Vertreter, welche viel Zeit im Auto verbringen. Dabei ist es sehr wichtig die Zeit im Auto zu minimieren. Weitere Optimierungskriterien sind unter Kapitel aufgeführt. Es ist zu beachten, dass sich auch weiche Constraints gegenseitig ausschließen können, zum Beispiel Minimierung der Durchlaufzeit und Maximierung der Kapazitätsauslastung. Will man die Kapazitätsauslastung maximieren, heißt das, dass genügend Aufträge zur Verfü- 18

19 2.3 Scheduling gung stehen, damit jede Ressource voll ausgelastet ist. Dies verlängert aber die Liegezeiten in der Summe der Tasks und somit die Durchlaufzeit im Gesamten. Da diese Ziele sehr schwer zu lösen sind, wird häufig auf ein Ersatzziel zurückgegriffen, in diesem Fall die Minimierung der Kosten [HG92]. Ziel ist es, die weichen Constraints so gut wie möglich zu erfüllen. Bei einfachen Problemen können optimale Lösungen gefunden werden, wie Kapitel zeigen wird. Bei komplexeren Problemen werden häufig Heuristiken herangezogen, um näherungsweise an eine optimale Lösung heranzukommen. 2.3 Scheduling Frei übersetzt heißt Scheduling Planung des zeitlichen Ablaufs. Die Aufgabe eines Scheduling Algorithmuses ist es also, die vorhandenen Ressourcen und Tasks zeitlich einzuplanen, damit alle definierten Ziele bestmöglichst erreicht werden. Die hierfür benötigten Mittel sind einerseits Ressourcen (Maschinen, Menschen, CPU, etc.) mit einer gegebenen Kapazität. Eine Maschine kann zum Beispiel immer ein Produkt auf einmal fertigen. Ein Mensch kann im Vergleich dazu zwei Aufgaben (zum Beispiel Überprüfung der Bonität und Ausführung eines Programms) in einer gegebenen Ausführungszeit gleichzeitig erledigen. Zusätzlich kann es Einschränkungen zwischen einzelnen Aufgaben geben. Das Scheduling Problem besteht darin zu entscheiden, wann welche Aufgabe von welcher Ressource ausgeführt werden soll Grundbegriffe Folgende Annahmen werden getroffen: Es gibt eine Menge von Aufträgen (Jobs) J = {J 1,.., J n }. Ein Auftrag kann in mehrere einzelne Tasks untergliedert werden J j = {T j1,.., T jo }, welche nicht mehr unterteilt werden können. Die Tasks werden auf einer Menge R = {R 1,.., R m } von Ressourcen ausgeführt. Die Bearbeitungszeit (processing time) p ij ist abhängig von der Ressource R i auf der der Task T j bearbeitet wird. Der Bereitstellungstermin (release date) r j vom Auftrag J kann genauso wie der Fälligkeitstermin (due date) d j von außen vorgegeben werden. Die Unterbrechung einer Taskinstanz, um sie zu einem späteren Zeitpunkt wieder zu aktivieren, soll nicht möglich sein. Zudem wird ein Task T j von einer Ressource R m nur einmal bearbeitet. Die Zeit, die man benötigt um mit der Arbeit am Work Item (siehe Kapitel 2.1.2) zu beginnen, wird nicht berücksichtigt. In der Literatur wird diese oft auch als Transportzeit oder Rüstzeit bezeichnet. Oft werden einzelnen Aufträgen oder Tasks noch eine Gewichtung nach Dringlichkeit mitgegeben w j, je nach Priorität der Prozessinstanz oder der Taskinstanz. Mit C j (completion time) wird der Fertigstellungszeitpunkt des Auftrags j angegeben. Die Durchlaufzeit F j (flow time) ist die Zeitdifferenz zwischen C j r j. Als Optimierungskriterium wird häufig die maximale Durchlaufzeit C max (makespan) herangezogen: C max := max{c 1,.., C j }. 19

20 2 Hintergrundinformationen Klassifizierung nach Graham In der Scheduling Theorie ist die Klassifizierung nach Graham, Lawler, Lenstra und Rinnooy Kan [PB01] [Pin08] weit verbreitet. Sie kann eine große Anzahl an Scheduling Problemen abdecken. Man unterteilt dabei das Scheduling Problem in drei Charakteristika: 1. Maschinenumgebung (α): Die Maschinenumgebung beinhaltet ein Attribut. Es wird die Anzahl an Ressourcen definiert. Diese müssen nicht zwangsläufig Maschinen sein. Es können auch Menschen sein, die Tasks erledigen. Hierbei ist wichtig, wie viele Ressourcen sich im Einatz befinden und ob es sich um eine oder mehrere parallel laufende Ressourcen handelt. Dabei spielt es auch eine Rolle, ob die Ressourcen dieselben Aufgaben in derselben Zeit erledigen können, oder ob sie unterschiedliche Aufgaben erledigen können. 2. Auftragscharakteristika (β): Es können null bis endlich viele Auftragscharakteristika aufgeführt werden. Ein Task unterliegt bestimmten Einschränkungen (Constraints). Der gängigste Constraint ist, dass ein Task nur von einer bestimmten Anzahl an Ressourcen erledigt werden kann. Eine weitere Einschränkung ist, dass bestimmte Tasks nur in einer vorgegebenen Reihenfolge durchgeführt werden können. Zum Beispiel muss eine Maschine erst ein Loch in eine Metallplatte bohren, bevor ein Gewinde gedreht werden kann. Außerdem muss ein Task zu einer bestimmten Zeit erledigt sein, oder er kann erst zu einer bestimmten Zeit gestartet werden. Tasks könnten während Ihrer Bearbeitung unterbrochen und auf andere Ressourcen verteilt werden. Dies wird hier allerdings ausgeschlossen, da es über das Thema hinausgeht. Bestimmte Tasks haben eine höhere Priorität und müssen aus diesem Grund bevorzugt behandelt werden. 3. Zielfunktion(γ): Häufig handelt es sich hierbei nur um ein Attribut, eine Zielfunktion kann aber auch mehrere beinhalten. Es muss aber darauf geachtet werden, dass diese Attribute sich nicht gegenseitig ausschließen. Die am häufigsten anzutreffenden Ziele sind, den Durchsatz zu maximieren, die Durchlaufzeit zu minimieren oder die Kosten zu minimieren. Dabei können entweder nur ein Ziel oder mehrere Ziele definiert werden, was jedoch eine Komplexitätszunahme zur Folge hat. Weitere Ziele können sein, alle anliegenden Tasks in der vorgegebenen Zeit zu erfüllen, deterministisch zu sein, das heisst ein definiertes Verhalten zu haben, die Ressourcenauslastung zu maximieren, oder auch fair zu allen Aufgaben zu sein. Das heißt jede Aufgabe wird garantiert zu einem Zeitpunkt X durchgeführt. Die wesentlichen Unterscheidungen und ihre Bedeutung sind in Tabelle 2.1 aufgeführt, weitere Merkmale sind unter [Pin08] definiert. Mit der α β γ Notation ist es möglich Probleme sehr kurz und präzise zu definieren. Ist zum Beispiel das Ziel die verspäteten Aufträge zu minimieren, werden an die zu erledigenden Aufgaben keine bestimmten Einschränkungen geknüft. Dieses Problem sieht dann wie folgt aus: 1 L max. Können nicht alle Tasks am Anfang beginnen und die Prioritäten 20