Geschäftsprozesssimulation mit der Software "Arena": Die Essensausgabe in der Mensa der Universität Karlsruhe

Inhaltsverzeichnis

Teil I Einleitung
1. Motivation

Teil II Die Software Arena
1. Kurzbeschreibung der Software Arena
1.1 „Create-Flowchart“-Modul mit Schedule
1.2 „Match-Flowchart”-Modul

Teil III Simulation des Ist-Zustand „Essensausgabe“
1. Beschreibung des alten Mensa-Prozesses
2. Vor-Ort-Erhebung
3. Hochrechnung vom Klausurzeitraum auf Hochsession
4. Simulation des Ist-Zustand „Gut & Günstig“
4.1 Der Aufbau des Gut & Günstig Simulationsmodells
5. Simulation des Ist-Zustand „Komponentenessen“
5.1. Der Aufbau des Simulationsmodells vom Komponentenessen

Teil IV Simulation des Soll-Zustand „Komponentenzusammen-
Stellung“ in der neuen Mensa der HS Karlsruhe
1. Beschreibung des neuen Mensa-Prozesses
2. Simulation des Soll-Zustand in der neuen Mensa
2.1 Verteilungsrechnung der Essensvorlieben von Mensagästen
2.1.1 Verteilungsrechnung
2.2 Der Aufbau des Simulationsmodells der neuen Mensa
3. Schwachstellen im neuen Mensaprozess
4. Optimierung im neuen Mensaprozess durch Front Cooking

Teil V Auffälligkeiten während des Simulationsdurchlauf
1. Einschränkungen der Demoversion von Arena 9.0
2. Concurrent-Process in Arena 9.0

Teil VI Reportanalysen
1. Gut & Günstig
2. Komponentenessen
3. Neue Mensa
4. Fazit

Teil VII Inhalt der ScreenCam-Videos

Teil VIII Der Fragenkatalog

Teil IX Glossar

Teil X Abbildungsverzeichnis

Teil XI Bibliografie

Teil XII Appendix
1. Vor-Ort-Erhebung vom 06.07.2006 – 12.07.2006
2. Mengengerüst (Komponenten) im Zeitraum vom 07.11. bis 11.11.2005
3. Mengengerüst (Gut & Günstig) im Zeitraum vom 07.11. bis 11.11.2005
4. Simulationsmodell der neuen Mensa

Teil I Einleitung

Im Rahmen des WUSKAR-Projekts (Werkstatt Unternehmenssoftware Karlsruhe), wird eine Studienarbeit erstellt, deren Inhalt der Ist-Zustand des Mensa-Prozesses „Essensausgabe“ ist. Die Simulation erfolgt hierbei unter Zuhilfenahme des Softwarewerkzeugs „Arena 9.0“.

1 Motivation

Jeden Tag bilden sich in den Mensas der Hochschulen lange Wartenschlagen aus, da die Studierenden auf ihr Essen warten müssen. Über diese Tatsache wurde im Spiegel Online ein Bericht mit dem Titel „Intelligenter Schlange stehen“ veröffentlicht. In diesem Artikel wurden die „ewigen“ Warteschlangen in der Mensa in Bremen beschrieben. Diese Mensa wurde ursprünglich für 6000 Besucher angelegt, muss aber täglich mittlerweile um die 8000 hungriger Mäuler stopfen […]. Das bedeutet nicht nur Stress für alle Beteiligten, sonder auch enorme finanzielle Einbusen für den Mensabetreiber, weil mehr als ein Drittel der Studenten im Warteschlangenchaos auf Beilagen und Getränke verzichtet. [UniSPIEGEL 2005]

Das Problem der langen Warteschlangen und der Stress herrscht aber auch in der alten Mensa der HS Karlsruhe. Es soll im Rahmen dieser Arbeit zunächst der Ist-Zustand der alten Mensa analysiert werden, um Schwachstellen aufzudecken und diese in den neuen Mensa-Prozessen zu vermeiden. Die neune Mensa der HS Karlsruhe wird voraussichtlich im Jahr 2007 eröffnet.

Die Neugestaltung der Prozesse soll auch einen Teil dieser Arbeit beinhalten. Hierbei werden mögliche Lösungsansätze für die Prozessgestaltung in der neuen Mensa von der HS-Karlsruhe ermittelt. Da es in der Realwelt noch gar nicht möglich wäre, die ermittelten Lösungsansätze zu testen, werden diese ebenfalls im Simulator „Arena 9.0“ abgebildet und auf Effektivität und Effizienz hin untersucht um im Jahre 2007 eventuell zum Einsatz zu kommen.

Teil II Die Software Arena

1 Kurzbeschreibung der Software Arena

Bei der Software Arena handelt es sich um eine Simulationssoftware die aus dem Hause Rockwell stammt. Arena ist bereits in der Version 9.0 verfügbar, die auch in dieser Fallstudie als Softwarewerkzeug eingesetzt wird. Die Software „Arena 9.0“ ist ein mächtiges Simulationsprogramm und bietet im Vergleich zu anderer Simulationssoftware eine animierte Allround-Simulation. Mit der Software Arena lassen sich originale Realwelt Vorgänge auf ein Simulationsmodell im Rechner abbilden. Mit diesem Modell können dann anders als in der realen Welt Experimente durchgeführt werden, ohne dass es zu irgendwelchen Kostenschäden bzw. Produktionsausfällen kommt.

Arena geht bei der Simulationsdurchführung nach dem prozessorientierten Ansatz vor, d.h. Komponenten führen Aktionen durch, wodurch sich das System verändert. Andere Programme simulieren ereignisorientiert, d.h. Ereignisse verändern das System.

Anwendungsgebiete für Arena sind z.B. Entwurf und Analyse von Herstellungssystemen, Ermitteln der Hard- und Softwareanforderungen für ein Computersystem, Analyse von Finanz- und Wirtschaftssystemen oder die Ermittlung des optimalen Aufbaus von Servicesystemen, wie z.B. der Mensa-Prozess.

Zum Aufbau des Mensa-Simulationsmodells sind bei Arena 5 grundsätzliche Schritte notwendig gewesen:

- Aufbau eines Grundmodells, das aus Arena Modulen besteht, per „drag&drop“ (z.B. eine Warteschlange mit einem Bediener).
- Einstellen und hinzufügen von Parametern und Daten (z.B. Bedienzeiten) durch doppelklicken auf die Module.
- Simulieren des Modells und Überprüfung, wie gut das Modell das reale System (z.B. alten Mensa Prozess) modelliert.
- Analyse der Simulationsergebnisse
- Änderung des Modells bzw. der Parameter, um mehr über das mögliche Verhalten des realen Systems herauszufinden und um die Effizienz und Effektivität des Systems zu ermitteln.

1.1 Das „Create-Flowchart“-Modul mit Schedule

Jede Prozesskette in Arena beginnt mit einem Create-Modul. Dieses Modul, stellt die Schnittstelle zu den weiteren Modulen dar, wie z.B. dem Prozess-Modul. Im Create-Modul werden die Starteinstellungen definiert (z.B. feste Anzahl und der Intervall, der ankommenden Studenten in die Warteschlange).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Create-Modul

Aufgrund von den Erhebungsbögen, die für diese Arbeit angefertigt wurden, kann von einer fest definierten Anzahl von ankommenden Studenten nicht ausgegangen werden. Durch die unterschiedlichen Zeitintervalle, in denen die Messungen durchgeführt wurden, variierte diese Anzahl. Die Simulation soll geplant nach dem aufgenommenen Realzeitschema erfolgen, indem der Prozess in Echtzeit abgebildet wird. Für diesen Fall stellt die Simulationssoftware „Arena 9.0“ einen speziellen Eingangstyp zur Verfügung. Dieser Typ nennt sich Schedule (1) und beinhaltet einen Zeitplan (2) der später noch definiert werden muss.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Einstellungsparameter für Create-Modul

Um den Eingangstyp Schedule überhaupt verwenden zu können, müssen die „Time Patterns“ definiert werden. Time Patterns sind die Ablaufpläne (Ablaufmuster) mit den Eingangsgrößen (1), die zu einer bestimmten Zeit erfolgen sollen. Diese können in der Benutzerleiste unter Edit [Abbildung in dieser Leseprobe nicht enthalten] Calendar Schedules eingestellt werden.

Unter (2) findet sich der Namen des erstellten Plans wieder nach dem der Ablauf generiert werden soll. Man kann in diesem Konfigurationsmenü noch die Ablaufdauer (3), sowie die Art der Eingangsgrößen (4) und welche Art von Wert (5) diese besitzen sollen definierten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Einstellungsparameter für Time Patterns

Für den Simulationsaufbau der Gut & Günstig Essensausgabe und der dazugehörigen Warteschlange wurden zwei Ablaufpläne benötigt, um die beiden Prozesse real abzubilden.

1.2 Das „Match-Flowchart“-Modul

Damit eine Zusammenführung zwischen zwei unterschiedlichen Prozessen erfolgen kann, wird ein Match-Modul benötigt. Dieses Modul hat die Aufgabe bei der Simulation den Gut & Günstig Essensausgabe Prozess mit dem Warteschlangenprozess zu koppeln. Die beiden Prozesse werden gematcht (miteinander verbunden) sobald die Essensausgabe erfolgt und der bereitstehende Studierende aus der Warteschlange das Essen abnimmt.

Damit die Aufnahme eines Match-Moduls in die Prozesskette möglich ist, muss das zusätzliche Standard-Attachment „AdvancedProcess.tpo“ zu den Funktionen miteingebunden werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Match-Modul

Das Match-Modul wartet jeweils auf die Ergebnisse, aus den einlaufenden Prozessen und stellt hierfür Warteschlangen bereit. Je nach Einstellung können das 2 bis max. 5 eingehenden Prozesse mit der entsprechenden Anzahl an Warteschlangen sein (1).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Konfigurationsmöglichkeiten im Match-Modul

Das in dieser Arbeit verwendete Match-Modul beinhaltet 2 Warteschlagen, d.h. es wird auf ein Ergebnis aus der Essensausgabe gewartet, sowie auf einen ankommenden Studierenden. Sobald die Ergebnisse in den Warteschlangen des Match-Moduls vorhanden sind, gibt das Match-Modul beide Ergebnisse frei und wertet den Prozess Essensabgabe an den Studierenden als einen abgeschlossenen Prozess.

Teil III Simulation des Ist-Zustand „Essensausgabe“

1 Beschreibung des alten Mensa-Prozesses

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Warteschlangensituation in alter Mensa

Um in die alte Mensa der HS Karlsruhe zu gelangen, kommen die Studierenden eine Treppe hinauf. Nachdem die Studierenden das Ende der Treppe erreicht haben, müssen sich die Studierenden für das Essen entscheiden. Je nach Essenswahl können sich die Studierenden an der Gut & Günstig Essensausgabe aufreihen oder am Komponentenessen. Zu bestimmten Uhrzeiten (siehe Datenerhebungsbogen) kann es auch vorkommen, dass sich Warteschlangen bis zur Treppe hinunter entwickeln und noch länger. Dabei sind zu Stoßzeiten Warteminuten von bis zu maximal 45 Minuten möglich.

Nachdem dem Erreichen der Gut & Günstig Essenausgabe hat der Studierende keine weiteren Wahlmöglichkeiten mehr. Er erhält ein zusammen gestelltes Essen, das von zwei Küchenkräften zusammen gerichtet wird. Dieses Essen besteht aus einer Hauptkomponente, sowie einem Salat und in Abwechslung kann eine Suppe bzw. ein Dessert dazu gereicht werden. Nach dem Erhalt des Essens geht der Studierende an die Kasse und bezahlt.

Eine weitere Essenswahlmöglichkeit die sich dem Gast zur Auswahl stellt, ist das Komponentenessen. Nach dem Erreichen der Komponentenessenstheke hat der Studierende die Auswahl zwischen zwei Hauptkomponenten. Diese können z.B. Hähnchenkeule oder Tortellini sein. Nach dem Erhalt kann der Gast zur nächsten Theke gehen und erneut eine Auswahl treffen. Dort angekommen wählt er die Beilage aus und erhält z.B. Nudeln oder Reis. Im weiteren Vorgehen kann sich der Studierende an einer weiteren Theke für einen Salat und an einer nochmals darauf folgenden Theke für ein Dessert entscheiden. Nachdem der Studierende alle seine Komponenten zusammengestellt hat, geht er zur Kasse und bezahlt sein Essen.

Durch den Geschäftsprozess Kasse schließt der Studierende seine Essenswahl ab und beendet damit den Mensa-Prozess „Essensausgabe“. Der Gast kann zum Bezahlen seines Essens zwischen zwei Kassen eine Auswahl treffen, wo er bezahlen möchte. Der Bezahlvorgang an der Kasse stellt einen Prozess da, der für den Studierenden bzw. den zahlenden Kunden erneut eine gewisse Zeit in Anspruch nimmt. Je nach Uhrzeit und dem Studierenden-Aufkommen können sich an der Kasse erneut lange Warteschlangen ausbilden. Damit diese vom Kassenpersonal abgebaut werden können wird wieder eine gewisse Zeit in Anspruch genommen.

2 Vor-Ort-Erhebung

Ein wichtiger Bestandteil für die genaue, sowie originalgetreue Nachmodellierung des Ist-Zustand Mensa-Prozesses „Essensausgabe“ stellt die Vor-Ort-Erhebung, sowie das Mengengerüst dar. Anhand der Erhebungsbögen und des Mengengerüsts kann eine Hochrechnung erfolgen. Diese ist notwendig, da die Vor-Ort-Erhebung während des Klausurzeitraumes stattgefunden hat und daher nicht der Realität wie während des Semesters entspricht. Nach der Hochrechnung kann der Mensa-Prozess in der Simulationssoftware Arena 9.0 abgebildet werden.

Über einen Zeitraum von einer Woche vom 06.07.2006 bis 12.07.2006 wurden die genauen Prozessabläufe analysiert (s. Appendix Erhebungsbögen). Dabei wurden jeden Tag in der Zeit zwischen 12.00 Uhr und 14.00 Uhr alle 10 Minuten folgende Abläufe untersucht:

1. Wie viele Studierende zu welchem Zeitpunkt in welcher Schlange stehen
2. Wie lange die Dauer zum Wegnehmen eines Menüs dauert
3. Wie viele Essen pro Minute bei Gut & Günstig ausgegeben werden können
4. Durchschnittliche Wartezeiten pro Studierendem in der entsprechenden Warteschlange
5. Wie viel Zeit pro Mitarbeiterin für die Zusammenstellung des Gut & Günstig Essens benötigt wird
6. Wie viel Zeit verbringt der Studierende an einer Theke bis er die von ihm gewünschte Komponente erhält

Durch die Auswertung der Erhebungsbögen, lassen sich folgende Schlussfolgerungen ableiten.

- Die täglich entstehenden Warteschlangen an der Gut & Günstig Theke bzw. am Komponentenessen hängen stark davon ab, welches Essen es wo gibt, und was die Studierenden bevorzugen. Man kann innerhalb dieser Woche sehr gut sehen, dass der Geschmack der Studierenden von den Allgäuer Käsespätzle bzw. den Chicken Crossis mit Cocktailsoße angesprochen wurde. Im Gegensatz dazu kommen die Rinderrouladen bzw. der Bauernschmaus nicht so sehr bei den Studierenden an.
- Eine weitere Beobachtung, die aus der Vor-Ort-Erhebung ersichtlich ist, ist dass die Warteschlangen immer nur zu bestimmten Zeiten extrem anwachsen. Dabei konnte festgestellt werden, dass die Stoßzeiten in der Mensa zwischen 12.00 Uhr bis 12.30 Uhr und nochmals zwischen 13.00 Uhr bis 13.30 Uhr liegen.
- Da die Vor-Ort-Erhebung während der Klausurzeit stattfand und in dieser Zeit die Mensa nicht voll ausgelastet ist, waren auch die Wartezeiten in den Schlangen noch im Rahmen des Üblichen. Bei der Gut & Günstig Warteschlange, musste kein Studierender länger als 1 Minute 17 Sekunden bzw. in der Warteschlange für das Komponentenessen länger als 5 Minuten 19 Sekunden anstehen und auf das Essen warten.
- Ebenfalls ein wichtiger Aspekt, den man aus der Erhebung erkennen kann, ist die Dauer, die das Küchenpersonal für die Zusammenstellung des Gut & Günstig Essens benötigt. Je nach dem welche Komponenten zusammengestellt werden müssen, kann es bei Bauernschmaus 2-3 Sekunden pro Mitarbeiterin andauern und bei Spaghetti Napoli 8-12 Sekunden. Von diesen Werten wiederum ist die Wartezeit in der Schlange abhängig und wie lange es für den Abbau dieser Warteschlange in Anspruch nimmt.
- Ein weiterer Faktor der zum Abbau der Warteschlange beiträgt ist die Wegnahmedauer eines Studierenden von seinem Tablett. Vor der Erhebung ist der Mensabetreiber von einer durchschnittlichen Wegnahmedauer von ca. 1 Minute ausgegangen. Dieser Wert wurde bei der Vor-Ort-Erhebung deutlich widerlegt, denn die Dauer beschränkt sich auf 3-6 Sekunden, damit der nächste Studierende nachrücken kann.
- Durch die Analyse der Erhebungsbögen lassen sich auch Rückschlüsse auf die Vollauslastung des Küchenpersonals an der Gut & Günstig Theke ziehen. Dabei kann festgestellt werden, dass es dem Personal nicht möglich ist, innerhalb von einer Minute mehr als 12 Essen zusammenzustellen. Vorraussetzung muss jedoch dabei sein, dass es keines großen Aufwands bedarf. Der Regelfall für das Personal liegt bei 9 Essen pro Minute.
- Während der Erhebung stellte sich auch heraus, dass die Studierenden nicht in Form eines konstanten Streams bzw. immer nur alleine ankommen, sondern eher in unregelmäßigen Pulks. Diese Pulks bewegen sich oft in einer Größe zwischen 3 bis max. 7 Studierende. Für die Simulation in Arena wäre die Wahl des Mittelweges der Menge ideal geeignet. Dafür könnte man einen Pulk der aus 5 Studierende besteht als ankommende Personengruppe annehmen.

3 Hochrechnung vom Klausurzeitraum auf Hochsession

Wie im vorherigen Abschnitt erwähnt wurde, fand die Vor-Ort-Erhebung während der Klausurzeit satt. In diesen Tagen ist die Mensa ziemlich schwach durch Studierende besucht und daher bieten die Erhebungsergebnisse keinen realen Bezug zur Hochsession. Aus diesem Grund muss anhand des Mengengerüsts (s. Appendix Mengengerüst) eine Hochrechnung für die Simulation des Ist-Zustandes erfolgen, in der die Mensagäste während des Klausurzeitraums auf die Hochsession hochgerechnet werden.

Um einen Bezug von der Erhebung auf das Mengengerüst herstellen zu können wird ein Studierendenfaktor ermittelt.

Dieser Faktor ergibt sich aus:

Abbildung in dieser Leseprobe nicht enthalten

Der Studierendenfaktor wird mit den ermittelten Mensabesuchern im Erhebungsbogen multipliziert (hochgerechnet). Durch diese Hochrechnung erhält man einen annähernden Wert von Studierenden, die die Mensa während der Hochsession besucht haben. Diese Hochrechnung wird für das Gut & Günstig Essen, sowie für das Komponentenessen durchgeführt. Des Weiteren muss beim Komponentenessen noch die Anzahl an Studierenden ermittelt werden, die sich für einen Salat bzw. Dessert oder beides entscheiden.

Um diese Werte ermitteln zu können, muss auf die Erfahrungswerte des Mensabetreibers zurückgegriffen werden.

Die Informationen des Mensabetreibers ergaben:

- Während der Hochsession wird für das Gut & Günstig Essen immer mit 600 Komponenten geplant. Diese sind z.B. 600 Desserts, 600 Salatteller und 600 Portionen an Sättigungsbeilage und Hauptkomponente. Zu den beliebtesten Essen gehören Schnitzel mit Pommes Frites und Salat, Currywurst, Lasagne und Maultaschen
- Für das Komponentenessen wird während der Hochsession folgendermaßen geplant:
- Von insgesamt 500 Desserts werden ca. 200 - 250 Stück von den Studierenden verzehrt.
- Von insgesamt 1000 Salaten werden ca. 400 Stück von den Studierenden verzehrt.

Für die Hochrechnungen an Studierenden in der Mensa wurde anhand des Mengengerüsts der 08.11.2005 für das Komponentenessen, sowie für das Gut & Günstig Essen ausgewählt. An diesem Tag kann man feststellen im Vergleich zu den anderen Tagen, dass hier die Mensa am stärksten besucht wurde. Für die Studierendenzahlen lt. Erhebungsbogen, wurde der 11.07.2006 ausgewählt. Der Grund für die Auswahl beruht darauf, dass beide Tage auf den Wochentag Dienstag fallen.

Hochrechnung für das Komponentenessen:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7: Hochrechnung der Mensagäste beim Komponentenessen vom 08.11.2005

[...]