Projekt: Simulation eines Kassierprozesses im Lebensmitteleinzelhandel
- Ersteller MAXG
- Erstellt am
Wurzelsepp29
Lt. Junior Grade
- Registriert
- Nov. 2009
- Beiträge
- 268
ahja... oder man nimmt einfach einen Online-Anbieter, der das ganze cloudbasiert für studentische Zwecke meistens kostenlos bereitstellt?
Was genau soll bitte in Python oder Javascript programmiert werden, was die Durchlaufzeit von zwei verschiedenen Prozessen berechnet?
Da kann ichs ja gleich auf einen Zettel schreiben und runterrechnen.
Der Charme an BPMN ist nunmal, dass verschiedene Verzweigungen mit Wahrscheinlichkeiten und entsprechenden Zeiten belegt werden können, um den Geschäftsprozess vollumfänglich analysieren zu können.
Was genau soll bitte in Python oder Javascript programmiert werden, was die Durchlaufzeit von zwei verschiedenen Prozessen berechnet?
Da kann ichs ja gleich auf einen Zettel schreiben und runterrechnen.
Der Charme an BPMN ist nunmal, dass verschiedene Verzweigungen mit Wahrscheinlichkeiten und entsprechenden Zeiten belegt werden können, um den Geschäftsprozess vollumfänglich analysieren zu können.
Der Knackpunkt ist, jeder der häufiger einkaufen geht, dürfte es sich angewöhnt haben zuerst die Sachen abzuräumen, dann zu bezahlen und nicht umgekehrt. Diese "Doppelschachtsysteme" gibt es deshalb nur an den wenigsten Kassen und sie sind nur dann nützlich wenn wirklich jemand so langsam mit dem Einpacken ist, dass ein zweiter Kunde in dieser Zeit bedient werden kann.MAXG schrieb:
Statistisch müsstest du erst einmal herauszufinden, wie oft überhaupt eine solche Situation entstehen kann. Wenn ich mir die heutigen Kassen so anschaue, dann scheinbar nicht so oft. Der Bezahlvorgang an der Kasse ist zudem selten ein Problem, meist sind es Nachfragen weil auf der Quittung was nicht stimmt, eine Ware mehrfach verbucht wurde, ein Preis unklar ist oder wenn jemand anfängt seine "Groschen" zusammenzurechnen.
Incanus
Fleet Admiral
- Registriert
- Jan. 2022
- Beiträge
- 10.681
Und genau das ist das Problem, es hält alle Nachfolgenden an der Kasse unnötig auf. Sobald fertig gescannt wurde sollte der Kunde bezahlen und dann erst weiter einpacken, falls er noch nicht fertig ist.xexex schrieb:
Nicht erst danach überrascht feststellen, dass ja auch noch bezahlt werden musst, die Tasche suchen, öffnen, die Brieftasche entnehmen, öffnen, nach der Karte suchen, schauen wo das Terminal ist, wie man die Karte einstecken oder davor halten muss etc.
Jeder der in der Mittagspause in den Supermarkt geht, um sich zu verpflegen weiß, was ich meine
.Hallo,xexex schrieb:
danke für den wichtigen Input. Korrigier mich gerne, aber ich denke, dass die Zeitersparnis immer im Wegfall von Einpack-Zeit und Bezahl-Zeit liegt, unabhängig davon, ob der Kunde erst einpackt oder erst bezahlt - denn:
Sobald der Kassierer den letzten Artikel über die Scannerkasse gezogen hat und den Kunden nach der gewünschten Bezahlart gefragt hat, kann er die Kartenzahlung anweisen.
Der Kunde erledigt den Rest ja dann - sprich Bezahlung am Terminal, einpacken und Bon mitnehmen.
Währenddessen kann der Kassierer mit dem nächsten Kunden fortfahren, ob der erste Kunde nun gerade einpackt oder bezahlt, ist dann nicht mehr wichtig - er sollte nur darauf achten, dass der Kunde am Ende auch bezahlt hat. (akustisches Signal)
Um die Ersparnis bei einem "optimalen" Prozess mit der Doppelkasse herauszufinden müsste ich also wissen:
- Wahrscheinlichkeit, dass ein Kunde mit Karte zahlt
- Die Höhe der durchschnittlichen Einpackzeit bei durchschnittlicher Artikelanzahl
- Die Höhe der durchschnittlichen Dauer für eine Geldkartentransaktion
Diese Informationen zu gewinnen ist wahrscheinlich nicht ganz leicht, könnte ich aber theoretisch durch die Zusammenarbeit mit dem Unternehmen direkt aus der Praxis erhalten.
Genau dann kommen aber die Rückfragen, oder der Kunde will noch Geld abgehen, oder überlegt sich doch Bar zu bezahlen. Abgesehen davon ist das nicht korrekt, der Prozess läuft nur etwas verändert ab.Incanus schrieb:
Waren aufs Band -> kassieren -> Kunde packt währenddessen ein -> Nachfrage/Reklamation -> bezahlen -> waren vom nächsten Kunden werden kassiert...
Wenn du zwei Schächte hast, was gewinnst du damit? Wenn der Kunde schnell genug ist, wird der zweite Fach schlichtweg nicht genutzt, er dient also im besten Fall als "Überlauf" wenn der Kunde zu langsam ist. Bezahlen, kann der Kunde meist sowieso nicht selbst, denn es kommt zumindest in Deutschland noch immer die Frage ob er überhaupt mit Karte oder Bar bezahlen möchte.
Deshalb haben sich heute schlichtweg immer mehr Kassen von diesen zwei Ablagen komplett getrennt. Bei deinem "System" hast du das Problem, der Kassierer ist schon beim nächsten Kunden, während der erste noch was möchte oder was reklamieren will. Aus potentieller Zeitersparnis, wird eine Zeit- und Reklamationsfalle.
Das hängt nun mal stark von verkauften Waren und wie die verkauft werden. Gibt es lose Waren die vom Kassierer verwogen werden? Gibt es Waren die vom Kassierer erst auf Preis überprüft werden müssen? Möchten die Kunden noch zusätzliche Dienstleistungen? Barabhebung? Zigaretten? Muss Ausweis geprüft werden? Kleingeld gezählt?MAXG schrieb:
Ich habe jetzt keine statistisch relevanten Zahlen, aber muss ehrlich zugeben, dass ich in den letzten 10 Jahren keine Kasse mehr gesehen habe, die noch ein zweites Ablagefach hätte. Es wird schon seine Gründe haben. Will man die Taktfrequenz der Kartenzahler erhöhen, baut man schlichtweg mehrere Selbstbedienungsterminals hin, "Problem" gelöst und man ist nicht auf zwei Kunden beschränkt.
Zuletzt bearbeitet:
Hallo,xexex schrieb:
ich kann deine Bedenken nachvollziehen und das motiviert mich auch, das System bis ins Detail zu hinterfragen.
Ich möchte dir kurz einen Fall vorstellen, den ich so schon in der Praxis beobachten konnte:
Kunde 1 hatte eine Handvoll Artikel und bezahlte mit Karte. Im herkömmlichen Prozess wartet der Kassierer nun, bis der Kunde die Karte findet, das Terminal bedient, muss ihm noch den Bon reichen und dann warten, bis er den Einkauf eingepackt hat.
Mit dem neuen Prozess kann der Kassierer sofort mit dem nächsten Kunden fortfahren, da der Kunde dies in seinem abgetrennten Bereich selbstständig erledigt, und hat somit einen Zeitvorsprung von bestimmt 10-15 Sekunden.
Das hört sich vielleicht nicht viel an, kann sich aber bei der Häufigkeit des Prozesses aufsummieren und muss auch aus ganzheitlicher Sicht betrachtet werden (Es muss ggf. keine zweite Kasse für die gleiche Anzahl an Kunden eröffnet werden - Filiale ist durch weniger Wege effizienter)
Auch sehe ich deinen Punkt, dass durch die vielen verschiedenen Artikel und sonstige Angebote (wie du sagst, Zigaretten, Barabhebung etc.) eine realistische Modellierung sehr schwierig wird. Leider sehe ich aber aktuell keine andere Möglichkeit, den Prozess so genau wie möglich zu simulieren, um überhaupt eine Aussage über den Zeitvorteil treffen zu können.
Soweit habe ich das ja verstanden, aber so läuft der Vorgang doch nicht ab.MAXG schrieb:
Ich stehe an der Kasse, lade meine Waren auf Band, dann fängt der Kassierer die Waren zu scannen. In der Zeit hüpfe ich dann auf der Stelle und warte bis der fertig ist und mich alles nötige abfragt, damit ich danach bezahlen und einpacken kann? Ich sag jetzt einfach mal aus persönlicher Erfahrung als Kunde, zu 80-90% ist der Kunde schneller als der Kassierer.
Was erledigt er? Das Bezahlen? Kartengerät geht nicht, Kunde hat sich vertippt, er möchte doch noch Bargeld abheben, er hat zulange gewartet. Was machst du dann? Der Prozess der Kartenzahlung ist im Normalfall der schnellste Prozess, einmal die Karte/Handy/Uhr ans Gerät halten und fertig, ich weiß nicht was du daran beschleunigen willst.MAXG schrieb:
Du vergisst dabei dass bis zur eigentlichen Bezahlung die Ware noch immer im Besitz des Verkäufers verbleibt. Für diesen Prozess bräuchtest du schon mal eine "Dual Kasse" mit der du einen Kunden kassierst, während der gesamte Bezahlvorgang von anderen Kunden noch weiter offen bleibt. Wenn du das System so dermaßen verkomplizierst, hast du ständig Vorarbeiter im Laden die irgendwelche Stornos bearbeiten müssen und an den Kassen wird alles nur nicht wirklich kassiert.
Wie gesagt, eine zweite Ablage ist gut wenn ein Kunde länger zum Einpacken benötigt nachdem er bezahlt hat. Der Fall kommt aber scheinbar selten genug vor, dass diese Trenner vor Jahren aus sämtlichen Läden verschwunden sind die ich besuche.
Ich finde die Aufgabenstellung durchaus Interessant, nur statt dich mit der Programmierung zu befassen, würde ich mich mal für eine Stunde an eine Kasse stellen und die statistische Relevanz einer solcher Lösung prüfen. Beziehungsweise als erstes einfach mal den Prozess und mögliche Komplikationen erfassen.
Zuletzt bearbeitet:
Zum ersten Punkt:xexex schrieb:
Ich sollte hier eventuell erwähnen, dass im Unternehmen sehr schnell kassiert wird und gerade bei größeren Einkäufen >20 Artikel, oft schneller kassiert wird, als eingepackt. (v.a. wenn Kunden in Tüten oder Rucksäcke packen)
Auch Großeinkäufe sind alltäglich, hier bietet es sich schon an, die große Ablage als "Überlauf" zu nutzen.
Wenn es wenige Artikel gibt oder der Einkauf nur in den Einkaufswagen gepackt wird, hast du recht, hier sind Kassierer und Kunde meist gleich schnell.
Soweit nur meine Erfahrung.
Zum zweiten Punkt:
In solchen Fällen kann der Kassierer immer noch eingreifen, auch wenn er bereits mit dem nächsten Kunden fortgefahren ist. (z.B. Kartenzahlung neu aufsetzen, Bargeldauszahlung anweisen etc.) Solche Fälle hat man aber auch im herkömmlichen Prozess - ganz reibungslos geht es eben nie.
Die Kartenzahlung geht auch in der Regel rasch, oftmals muss aber noch der PIN getippt werden oder erst einmal die Karte aus der Geldbörse genommen werden. Und diese Zeit würde man sich eben (sofern es keine oben genannten Zwischenfälle gibt) sparen.
Dafür müsste, der erste Vorgang noch solange offen sein und während sich der Kassierer dann wieder mit dem ersten Kunden beschäftigt, ist der zweite Vorgang unterbrochen. Mag sein, dass es für manche Kassierer kein Problem darstellt, praktisch ständig zwei Kassiervorgänge im Kopf zu halten, in der Praxis sehe ich solche Lösungen nicht (mehr) und das wird schon seine Gründe haben.MAXG schrieb:
Die Aufhänger an der Kasse sind in meinen Augen so gut wie nie die Kartenzahler. Es sind Barzahler, Leute die doch noch eine Tüte kaufen wollen, Altersprüfung, Preisprüfung, Rückgabe weil etwas offen ist usw.
ErsterSelbstbau
Cadet 3rd Year
- Registriert
- Feb. 2022
- Beiträge
- 39
Ich kann jegliche Kritik an dem Doppelkassensystem gut nachvollziehen, vieles der hier geschriebenen Kritik hatte ich beim ersten Durchlesen auch.
Aber: Wenn ich den Threadersteller richtig verstanden habe, geht es in seiner Bachelorarbeit (immerhin eine wissenschaftliche Arbeit!) eben genau darum die Vor- und Nachteile eines Doppelkassensystem systematisch zu erfassen (aus der Praxis) und einen ersten theoretischen Ansatz für eine Transformation auf andere Filialen zu entwickeln. Was geht und was nicht würde im laufe der Arbeit erkannt - es geht eben genau darum das festzustellen.
@MAXG: Falls ich falsch liege, korrigiere mich bitte, sonst führt das hier wohl zu sehr in eine falsche Richtung.
Aber: Wenn ich den Threadersteller richtig verstanden habe, geht es in seiner Bachelorarbeit (immerhin eine wissenschaftliche Arbeit!) eben genau darum die Vor- und Nachteile eines Doppelkassensystem systematisch zu erfassen (aus der Praxis) und einen ersten theoretischen Ansatz für eine Transformation auf andere Filialen zu entwickeln. Was geht und was nicht würde im laufe der Arbeit erkannt - es geht eben genau darum das festzustellen.
@MAXG: Falls ich falsch liege, korrigiere mich bitte, sonst führt das hier wohl zu sehr in eine falsche Richtung.
Hallo,ErsterSelbstbau schrieb:
danke für deinen Kommentar, das ist richtig. Ich möchte das System nicht auf Biegen und Brechen verteidigen, sondern dem Unternehmen eine valide Aussage über die Auswirkung einer Implementierung liefern. Dies kann auch heißen, dass das System zwar in der Theorie Zeitvorteile generiert, es aber in der Praxis nicht umsetzbar ist.
ErsterSelbstbau
Cadet 3rd Year
- Registriert
- Feb. 2022
- Beiträge
- 39
Und die Simulation des Kassierprozesses soll die Theorie bereitstellen und muss noch entwickelt werden?MAXG schrieb:
Mit der Simulation des Prozesses hatte ich das Ziel, den neuen Prozess dem alten direkt gegenüberzustellen und dadurch den Zeitvorteil deutlich zu machen.
In der Simulation würde ich davon ausgehen, dass sowohl Mitarbeiter und Kunden den Prozess optimal ausführen - deswegen Theorie.
Anschließend könnte ich den Vorgang in der Praxis prüfen und eruieren, ob der Zeitvorteil umgesetzt werden kann und falls nicht, welche Gründe dies hat.
Durch die Anregungen bin ich jedoch zugegebenermaßen skeptisch, ob ich den Prozess wirklich ausreichend realistisch simulieren kann, sodass das Ergebnis Aussagekraft besitzt.
In der Simulation würde ich davon ausgehen, dass sowohl Mitarbeiter und Kunden den Prozess optimal ausführen - deswegen Theorie.
Anschließend könnte ich den Vorgang in der Praxis prüfen und eruieren, ob der Zeitvorteil umgesetzt werden kann und falls nicht, welche Gründe dies hat.
Durch die Anregungen bin ich jedoch zugegebenermaßen skeptisch, ob ich den Prozess wirklich ausreichend realistisch simulieren kann, sodass das Ergebnis Aussagekraft besitzt.
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 17.944
Gerade wenn man dann liest, dass Aldi sowas scheinbar demnächst einführen will, stelle ich mir die Frage - ausgehend von meinem Aldi um die Ecke - wo man da noch Personalkosten einsparen will, wenn von 4 Kassen sowieso immer nur eine offen ist. Es sei denn man baut die Kassen buchstäblich mobil und die Kunden können noch in den Gängen bezahlen, während das Kassenpersonal zwischen den Bezahlvorgängen direkt weiter Regale einräumen kannMAXG schrieb:
Aber zur Sache: Wie soll die "Simulation" denn aussehen? Soll das in die Richtung gehen wie man es zB in Dokus im TV sieht, als Film im weitesten Sinne? Ist die Simulation das eigentliche Ziel des Projekts oder nur Mittel zum Zweck, um den Sachverhalt darstellen zu können? Mir kämen dabei nämlich sonst so Werkzeuge wie UML-Diagramme (zB Sequenz-Diagramm) in den Sinn, mit denen sich sowas ebenfalls darstellen ließe. Dabei kann man zB jeweils eine Spalte für Kunde 1, Kunde 2, Kassenpersonal, Kassenband, Warenauslauf, Kartenterminal, etc. erstellen und die einzelnen Vorgänge - zB Artikel scannen - zeitlich einordnen. Sieht dann ungefähr so aus wie hier oder auch hier beispielhaft dargestellt bzw. erklärt.
Wenn man es etwas animiert mag, kann man das fertige Diagramm später auch ganz banal mit PowerPoint, o.ä. nachzeichnen und als Folien abspielen. Besondere Kenntnisse sind dafür nicht erforderlich, weil man in keinster Weise programmieren muss und letztendlich nur ein übersichtliches Sequenzdiagramm zu erstellen ist.
Ich denke, die Einführung in einer bestimmten Filiale hängt stark vom Umsatz bzw. Kundendurchlauf ab. Wenn ohnehin nur eine Kasse geöffnet ist, wird die Einführung einer Doppelkasse nicht von höchster Priorität sein.Raijin schrieb:
Ich würde sagen, beides. Dazu muss ich erwähnen, dass ich die Arbeit folgendermaßen aufgebaut hätte: Feststellung Potenzial der Doppelkassen - Prüfen, ob Potenzial bereits in der Praxis, also in Filialen, die diese bereits haben, umgesetzt werden kann - Formulierung von Handlungsempfehlungen zur Ausschöpfung des Potenzials. (oder den Stopp der EinführungRaijin schrieb:
)Zum einen wäre es also schon ein Ziel, mithilfe der Simulation überhaupt festzustellen, auf welchen Zeitvorteil man grundsätzlich hoffen könnte. Andererseits muss ich im Rahmen der Arbeit den Sachverhalt auch erläutern, hier könnte ich die Simulation natürlich auch als Mittel zum Zweck nutzen, sofern diese grafisch anschaulich wäre.
Natürlich könnte ich aber auch Berechnung des Zeitvorteils und grafische Darstellung voneinander trennen, ich denke so in etwas meinst du das mit den UML-Diagrammen.
Ich werde mich auf jeden Fall mal damit auseinandersetzen. Vielen Dank
ErsterSelbstbau
Cadet 3rd Year
- Registriert
- Feb. 2022
- Beiträge
- 39
Das wäre wohl die Modellvalidierung. Ohne Modell keine Validierung, also müsste das Modell zuerst her.MAXG schrieb:
Ansatzpunkte für Python sehe ich da erstmal nicht, das käme ev. dann falls man das Modell mit wirklich vielen Laufvariablen "durchrechnen", also simulieren wollte. Allerdings denke ich auch da sind die schon genannten Ansätze (Excel, BPMN) passender.
Ich zweifle gerade daran ob eine Bachelorarbeit so weit gehen sollte - Ist das wirklich so gedacht?
Oder anders gefragt: Gibt es schon eine offizielle, konkrete, verbindliche Aufgabenstellung für diese Bachelorarbeit?
Die Bachelorarbeit ist noch nicht offiziell angemeldet. Das Thema ist lediglich mit dem Unternehmen und dem Dozenten vereinbart. Eine klare Aufgabenstellung von deren Seite gibt es nicht, da die Idee von mir kam - ich mir also erst einmal selbst überlegen muss, wie ich zu einem Ergebnis komme.ErsterSelbstbau schrieb:
Einfach gesagt, wird erwartet, dass ich herausfinde, ob und in welchem Ausmaß die Doppelkassen vorteilhaft sind.
Nun könnte ich natürlich einfach die Kennzahlen der Filialen mit Doppelkassen auswerten und prüfen, ob sich die Kasseneffizienz verbessert hat. (was höchstwahrscheinlich der Fall ist)
Dies wäre aber meiner Meinung nach inhaltlich zu wenig für eine zufriedenstellende Note.
Dementsprechend kam mir die Idee, das Potenzial festzustellen, dies mit den Daten und Beobachtungen aus der Praxis zu vergleichen und anhand dessen Optimierungsmaßnahmen zu entwickeln.
Wie hier aber auch deutlich wurde, ist der Kassierprozess einfach kein maschineller Prozess, der sich nicht so einfach modellieren lässt.
Ich werde mich trotzdem mal mit der vorgeschlagene Software (BPMN, Excel) beschäftigen.
Vielen Dank.
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 17.944
Jein. Ein Sequenzdiagramm kann durchaus den Zeitvorteil auch grafisch darstellen, das ist ja das Prinzip des Sequenzdiagramms, der zeitliche Verlauf eines komplexes Prozesses mit mehreren Beteiligten. Der Zeitvorteil ergibt sich schlussendlich aus dem Vergleich beider Abläufe, mit einem oder zwei EC-Terminals.MAXG schrieb:
Code:
Kunde Kassenband Personal EC-Terminal
| | | |
| | | |
| | | |
| --auspacken---> | ---scannen----> | |
x x x |
x x x |
x x x |
x x x ----Betrag----> x
| | | x
| | | x
x <-------------------SummeAnzeigen------------------ x
x x
x -------------------PinEingeben--------------------> x
x x
x <-----------------ZahlungBestätigen---------------- xDas ist natürlich nur rudimentär mit asciiflow gezeichnet und erhebt selbstverständlich keinerlei Anspruch auf Vollständigkeit (zB Warenauslauf, zweiter Kunde, etc), aber ich denke damit wird einigermaßen deutlich was ich meine. Unterfüttert man nun die einzelnen Vorgänge noch mit entsprechenden Zeitwerten, ergibt sich eine Timeline von der Ankunft des Kunden bis zu seinem Abgang. Jede "Zeile" könnte hier beispielsweise für 5 Sekunden stehen oder so - dementsprechend lang werden dann die Blöcke für die Vorgänge.
Egal wie man es macht, das ganze steht und fällt natürlich mit einigermaßen belastbaren Daten. Im Zweifelsfalle bedeutet das also sogar einige Stunden mit Klemmbrett und Stoppuhr auf einem Hocker neben der Kasse, um Daten zu sammeln und zB durchschnittliche Zeitfenster für "Das macht 17,90€" <> TippTipp <> Kassenzettel <> Ab zum Auto.