Die Herausforderung
von Aineth Torres-Ruiz (EGADE BS) und Ariel Shtul (Die Archivare)
Vorgestellt auf der Winter Simulation Conference 2016
Wir haben ein Simulationsmodell in SIMIO entwickelt, das die Systemelemente des Vorarchivierungsprozesses bei dem größten israelischen Archivdienstleistungsunternehmen darstellt. Der Vorarchivierungsprozess umfasst in der Regel die manuelle Erfassung der Abrufinformationen von Kisten und Akten, die auf einem Rollenförderer ankommen, bevor ihnen ein Platz in der Lagereinrichtung zugewiesen wird. Die Bediener sitzen um das Förderband herum und wählen einen Karton mit Barcode aus. Mithilfe des Simulationsmodells haben wir das Verhalten des ursprünglichen Systems untersucht und Möglichkeiten zur Effizienzsteigerung ermittelt. Die ersten Änderungen am System haben eine Verbesserung der Systemkapazität um bis zu 15 % über mehrere Monate hinweg gezeigt. In den folgenden Abschnitten werden die Systembeschreibungen und die Merkmale der Modellierungskomponenten erläutert.
Einführung
"Ha'Archivarim" ist das größte Unternehmen in Israel, das Archivdienstleistungen anbietet. Es ist eine Tochtergesellschaft der Archivgruppe von Villar Int'l, einem Tel-Aviv 75 Index-Unternehmen. Zur Archivgruppe gehören zwei weitere Unternehmen: Archive House ("Beit Ha'Archiv") und Archivit, mit Sitz in Rumänien. Das Unternehmen verwaltet mehr als 40.000 m2 Lagerfläche und über 3,5 Millionen Kartons. Eine normale Schachtelgröße ist 40x30x30 cm, aber das Unternehmen bearbeitet auch Schachteln mit anderen Abmessungen.
Jedes Jahr erhält das Unternehmen Hunderttausende von neuen Kartons von seinen Kunden. In der Vorarchivierungsabteilung wird der Inhalt der Kartons in eine Datenbank eingegeben, damit die Kunden die benötigten Dateien in Zukunft wiederfinden können. Während einige Kunden den Inhalt über eine Website eingeben, müssen die meisten Informationen von den Mitarbeitern des Unternehmens, den Dateneingabe-Operatoren, manuell eingegeben werden. Diese Mitarbeiter sitzen um ein kreisförmiges Förderband herum und wählen eine Box mit einem Strichcode aus. Sie scannen den Barcode ein, und auf ihrem PC öffnet sich ein Bildschirm mit den entsprechenden Feldern, je nach Kundenwunsch. Bei mehr als 6 Akten markieren die Mitarbeiter die Akten mit einer Nummer und geben dann den Inhalt ein. Zum Beispiel können sie für eine Krankenakte Name, ID, Datum und Abteilung eingeben. Zum Schluss schieben sie die Schachtel zurück auf das Förderband und nehmen eine neue Schachtel und so weiter. Die Kisten bleiben auf dem Förderband, bis sie von einem Bediener entnommen wurden. Es kann sein, dass ein Bediener aus Eigeninteresse keine Kiste entnimmt. Schließlich zieht ein automatisches System die getippten Kisten vom Förderband ab. Dieses System war bei der Entwicklung des Modells noch nicht funktionsfähig, was dazu führte, dass etwa 10 % der Kartons das Förderband nicht zum richtigen Zeitpunkt verließen. Die Abteilung umfasst mehr als 10 vollzeitbeschäftigte Datenerfasser, einen direkten Manager, zwei Förderbandbe- und -entlader, Personal für die Annahme und die Kundenkoordinierung sowie einen Abteilungsleiter. Der saisonale Rhythmus, in dem die Kartons von den Kunden ankommen, diktiert die Saisonalität der Beschäftigung. In der Hochsaison besetzt das Unternehmen alle Fördererpositionen und hat zusätzliche Schichten.
Zielsetzung der Simulation
Ziel war es, ein Simulationsmodell zu entwickeln, das es den Benutzern ermöglicht, verschiedene Szenarien zu testen, indem sie die folgenden Systemattribute ändern: Anzahl der Bediener für die Dateneingabe, Qualifikationsniveau der Bediener für die Dateneingabe, Bearbeitungszeit für Kartons und Akten und Rate der Kartons, die das Förderband nicht verlassen (wenn sie es sollten).
Die Lösung
Grundlegende Modellierungslogik
BOX stellt die Standardentität dar, die sich innerhalb des Systems durch ein Netzwerk von Bedienerobjekten (Abbildung 1) bewegt und der bei der Eingabe eine Anzahl von Dateien zugewiesen wird. Das Bedienerobjekt für die Dateneingabe besteht aus einer Kombination von drei Förderbändern und einer Arbeitsstation. Es modelliert die Ankunft der Kisten, die Auswahl, die Entnahme, das Scannen des Barcodes und die Rückgabe an das Förderband. Mehrere Instanzen des Dateneingabe-Operator-Objekts werden innerhalb des Hauptmodells platziert und miteinander verbunden. Darüber hinaus werden der Zugang und der Ausgang zum Hauptförderbereich durch zwei weitere Förderbänder dargestellt (Abbildung 2).
Im Folgenden werden weitere Logikbausteine und der verwendete Modellierungsansatz beschrieben:
- Logik1: Die Kisten werden von den Bedienern gescannt, wenn sie über freie Kapazitäten verfügen und die Kiste noch nicht gescannt wurde.
Herangehensweise: Wenn sich Boxen dem ersten Knoten des Betreibermodells nähern, wird das Attribut ModelEntity.Picture überprüft. Ein Wert von 0 bedeutet, dass die Kiste gescannt und an den Eingabeknoten am Erfassungsarbeitsplatz gesendet werden muss, andernfalls wird sie an den Ausgabeknoten gesendet. Ein Kasten wird als gescannt markiert(modelEntity ==1), wenn die Kästen am Erfassungsarbeitsplatz eingerichtet werden. - Logik2. Es besteht eine Wahrscheinlichkeit, dass die Kisten nicht gescannt werden, selbst wenn die in Logik1 angegebenen Bedingungen erfüllt sind (aufgrund des Eigeninteresses des Erfassers).
Lösungsansatz: Im Operatormodell wird nach der Überprüfung von ModelEntity.Picture jedem Kästchen eine zufällige, gleichmäßige Wahrscheinlichkeit zwischen 0 und 1 zugewiesen, die unterhalb eines bestimmten Wahrscheinlichkeitswertes an den Eingabeknoten des Dateneingabeoperators gesendet wird. - Logik3. Kisten verlassen das Förderband nicht, wenn sie es sollten (aufgrund eines Systemfehlers).
Lösungsansatz: Beim Verlassen der letzten Bedienerinstanz wird auf der Grundlage einer Auszugswahrscheinlichkeit entschieden, ob eine eingegebene Kiste erneut in eine Schleife gelangt. - Logik4: Einige Bediener sind leistungsfähiger als andere und brauchen länger, um die gleiche Kiste zu tippen.
Ansatz: Im Operatormodell wird die Gesamttippzeit durch einen Effizienzkoeffizienten geteilt.
Die geschäftlichen Auswirkungen
Output-Metriken
Das Modell sammelt eine Reihe von Output-Metriken, darunter: Kumulative Besetzt-, Leerlauf- und Wartezeiten der Datenerfasser, Gesamtzahl der verarbeiteten Dateien und Boxen, Anzahl der von jedem Datenerfasser verarbeiteten Dateien und Boxen und Anzahl der Boxen, die das System nicht verlassen haben.
Ergebnisse
Anhand des Modells konnten mehrere Änderungen vorgenommen werden. Ein zusätzlicher Motor mit höherer Geschwindigkeit und eine Arduino-SPS wurden installiert, um das Auszugssystem zu reparieren, das nun mit einer Effizienz von nahezu 100 % arbeitet. Außerdem wurde ein Bonussystem aktualisiert, um die verschiedenen Boxen auszugleichen und den Drang der Datenerfasser, auf eine "bessere" Box zu warten, zu beseitigen. Der Verlust an marginaler Effizienz mit jedem zusätzlichen Datenerfasser wird untersucht, um die Entscheidung zu unterstützen, ein zweites Förderband während der Hochsaison zu öffnen.