Simulation with Arena part.2

kelton5

SIMULATION WITH ARENA

 

Simulation with Arena W. David Kelton, Randall P. Sadowski, David T. Sturrock

Strony: 231-272

5.5 MODEL 5-2: Udoskonalony system call center

str. 231                 Przy opracowywaniu modeli dla rzeczywistych systemów będziesz chciał, aby twój model był tak prosty jak to tylko możliwe, a jednak będziesz chciał, żeby ten model wychwycił precyzyjnie działanie systemu. Naszym końcowym celem jest użycie naszego modelu, żaby znaleźć najbardziej opłacalne wyjście zwiększenia poziomu obsługi czy satysfakcji klientów. Chcielibyśmy przyjrzeć się wpływowi takich zmian jak zwiększenie liczby linii czy zmiana poziomu zatrudnienia. Nasz obecny model pozwoliłby nam wychwycić takie zmiany, choć brakuje mu szczegółów. Więc spójrzmy ponownie na opis problemu i określmy gdzie potrzebujemy dodać więcej detali.

5.5.1 Opis nowego problemu

Zacznijmy bardziej szczegółowym zbadaniem połączeń przybywających. Tempo połączeń przybywających do tego systemu faktycznie różni się w ciągu dnia zgodnie z niestacjonarnym procesem Poissona (POISSON PROCESS), [zobacz sekcja 12.3], który jest typowy dla takiego rodzaju systemów. Więc możemy gromadzić dane wyrażone w połączeniach na godzinę dla każdego 30-minutowego okresu, podczas którego system jest otwarty. To tempo połączeń przybywających jest pokazane na Table 5-2.

str. 232                 Następnie spójrzmy na zatrudnienie. Mimo, że nasz początkowy model zakładał stały poziom zatrudnienia dla działów sprzedaży i pomocy technicznej, obsada etatów w rzeczywistości różni się podczas dnia. Okazało się, że jest 6 sprzedawców ze zróżnicowanym harmonogramem pracy podsumowanym jako (liczba ludzi @ czas w minutach): 1@60, 3@60, 4@90, 5@60, 6@60, 5@90, 6@90, 5@30, 3@60 i 2@60.

Pracownicy pomocy technicznej pracują 8 godzin dziennie z 30 minutową przerwą na lunch (lunch nie jest wliczony w 8 godzin pracy). Jest 11 pracowników pomocy technicznej, których harmonogram pracy jest pokazany na Table 5-3. Charity i Noah są uprawnieni tylko do zajmowania się produktem Type 1; Tierney, Aidan i Emma są uprawnieni tylko do zajmowania się produktem Type 2; Mya, Ian i Christie są uprawnieni tylko do zajmowania się produktem Type 3. Molly jest uprawniona tylko do zajmowania się produktem Type 1 i 3, a Anna i Sammy są uprawnieni do zajmowania się wszystkimi trzema produktami.

Ostatni kawałek szczegółów, które ominęliśmy w naszym początkowym modelu było te 4% połączeń z pomocą techniczną wymagające dalszego badania po skończeniu połączenia. Pytania podniesione przez tych dzwoniących są przesyłane do innej grupy pomocy technicznej, poza granicami naszego modelu, która przygotowuje odpowiedź.

str. 233. Czas na przygotowanie odpowiedzi jest określany jako EXPO (60) minut. Wynik odpowiedzi jest wysyłany do tej samej osoby z pomocy technicznej, która odebrała początkowe połączenie. Ta osoba potem dzwoni do klienta, co zajmuje TRIA (2,4,9) minut. Te połączenia oddzwaniające wymagają jednej z 26 linii i otrzymują priorytet nad połączeniami przychodzącymi. Jeśli połączenie oddzwaniające nie zostanie wykonane w ten sam dzień, kiedy zostało otrzymane, to jest ono wtedy przenoszone na następny dzień.

Jeśli zamierzamy rozważyć zmiany w poziomie zatrudnienia, aby zwiększyć satysfakcję konsumentów możemy chcieć mieć więcej detali w systemie, kiedy jest on zatłoczony. Więc dodajmy liczniki do naszego modelu, których używaliśmy, żeby policzyć liczbę połączeń odrzuconych podczas godzin obsługi.

 

5.2.2 Nowe pojęcia

Nasz udoskonalony model wymaga dwóch nowych pojęć. Pierwszym jest proces przybywania, którego tempo zmienia się przez cały czas. Drugie pojęcie pokazuje, że kiedy połączenie próbuje schwycić jednostkę zasobu z pomocy technicznej, to tak na prawdę próbuje schwycić zasób z obszaru wspólnego albo zbioru zasobów uprawnionych do zajmowania się połączeniem. Zanim zbudujemy nasz model przedyskutujmy każde z tych pojęć.

Zaczniemy od procesu przybywania, którego tempo zmienia się w czasie. Ten typ procesu przybywania jest dość typowy dla systemów usługowych i wymaga innego podejścia. Przybywanie w wielu systemach jest modelowane jako stacjonarny proces Poissona, w którym przybycia występują raz w czasie, są  niezależne od innych, a ich średnie tempo jest stałe przez cały czas. Dla tych z was, którzy nie są wielkimi fanami prawdopodobieństwa, oznacza to, że mamy wykładniczy czas interarrival (czas pomiędzy kolejnymi połączeniami) z ustaloną średnią. Nie koniecznie musisz sobie zdawać sprawę, z tego, że jest to proces, którego użyliśmy dla modelowania naszych wcześniejszych modeli przybycia (z wyjątkiem Modelu 4-5, który był wymyślony żeby zilustrować szczególny punkt). Była lekka zmiana w tym dla Części B przybyć Modeli od 4-1 do 4-1, gdzie założyliśmy, że przybycie było grupą czterech, dlatego przybycia wciąż występują jako jedna grupa w czasie, zgodnie ze stacjonarnym procesem Poissona.

Dla tego modelu, przeciętne tempo przybywania jest funkcją czasu. Te typy przybyć są zazwyczaj modelowane jako niestacjonarne procesy Poissona. Oczywistym, ale błędnym, podejściem do modelowania tego będzie wpisanie do TIME BETWEEN ARRIVALS, w CREATE MODULE, dystrybucji wykładniczej ze zdefiniowaną przez użytkownika zmienną jako średnia Value, potem zmienienie tej Value na bazie tempa dla aktualnego okresu czasu. Dla naszego przykładu, zmieniliśmy tę Value, co każde 30 minut. To by zapewniło przybliżone rozwiązanie, jeśli tempo zmieniające się pomiędzy okresami było raczej małe. Ale jeśli tempo zmian jest duże, ta metoda może dać bardzo mylące (i złe) wyniki. Najprostszym sposobem zilustrowania potencjalnego problemu będzie rozważenie skrajnego przykładu. Powiedzmy, że mamy tylko dwa okresy, każdy 30-minutowej długości. Tempo dla pierwszego okresu jest 3 (średnia wartość przybyć na godzinę), albo interarrival-time ze średnią 20 minut, a stopień dla drugiego okresu jest 60, albo interarrival-time ze średnią 1minuta. Przypuśćmy, że ostatnie przybycie w pierwszym okresie występuje w czasie 29 minut.

str.234. Wytworzyliśmy następne przybycie używając średniej Value interarrival-time 20 minut. Używanie wykładniczej dystrybucji ze średnią 20 można łatwo (odnośnik 1) zwrócić wartość większą niż 31 do czasu następnego przybycia. To skutkowałoby brakiem przybyć podczas drugiego okresu, gdzie w zasadzie powinna być oczekiwana wartość 30 przybyć(odnośnik 2). Na ogół, używanie tej nazbyt uproszczonej metody powoduje nieprawidłowe zmniejszanie się liczby przybyć podczas przechodzenia od jednego do następnego okresu ze wzrostem w tempie, albo zmniejszenie się w interarrival-time. Przechodzenie z jednego do następnego okresu ze zmniejszeniem tempa spowoduje nieprawidłowy wzrost w liczbie przybyć w drugim okresie.

Jednakże, jest ważne, aby być w stanie modelować i wytwarzać takie procesy przybycia poprawnie, ponieważ wydaje się, że pojawiają się one cały czas, a ignorowanie niestacjonarności może stwarzać poważne błędy słuszności modelu, ponieważ wartości szczytowe i minimalne mogą mieć ważny wpływ na osiągi systemu. Na szczęście, Arena ma wbudowaną umiejętność generowania niestacjonarnego procesu przybyć Poissona w CREATE MODULE. Podstawowa metoda jest opisana w Sekcji 12.3.

                Drugie nowe pojęcie, jest to potrzeba modelowania jednostki przybywającej do lokalizacji albo stacji i wybieranie jednego z kilku podobnych, (ale nie całkiem identycznych) obiektów. Najczęstszą sytuacją jest wybieranie z dostępnego zasobu z obszaru wspólnego zasobów. Załóżmy, że 3 jest telefonistów: Sean, Lynn i Michael. Jakikolwiek z tych telefonistów może wykonać żądane zadanie, i chcesz wybrać któregokolwiek z tych trzech, tak długo jak jeden jest obecnie dostępny. SETS DATA MODULE w BASIC PROCESS PANEL zapewnia podstawę dla tej funkcyjności. Zbiory Areny są grupami obiektów tego samego typu, do których można się odnieść używając nazw zbiorów i indeksów zbioru. Obiekty, które składają się na zbiór oznaczają elementy zbioru. Elementy poszczególnego zbioru muszą być tym samym typem obiektu, takim jak zasoby, kolejki, obrazy, itd. Możesz zebrać jakiekolwiek typy obiektów Areny w zbiór, zależny od twoich wymagań modelowania. Jeden obiekt może znajdować się w więcej jak jednym zbiorze. Załóżmy w naszym OPERATORS SET, że Lynn może też być wykwalifikowana jako osoba zajmująca się układem regulacji systemu. Zatem, możemy zdefiniować drugi zbiór zasobu o nazwie SETUP jako Lynn i Doug (Doug nie jest telefonistą). Teraz, jeśli telefonista jest potrzebny, wybierzemy ze zbioru OPERATORS; jeśli osoba zajmująca się układem regulacji systemu jest potrzebny to wybierzemy go ze zbioru SETUP. Lynn może być wybrana w obu przypadkach, ponieważ jest częścią obu zbiorów. Możesz mieć tak wiele zbiorów, jak chces,z z tak wieloma albo z niewieloma częściami zachodzącymi na siebie jak jest to potrzebne.

odnośnik 1. Z prawdopodobieństwem e-31/20=0.21, żeby być (prawie) dokładnym. Właściwie ta figura jest warunkowym prawdopodobieństwem braku przybyć w drugim okresie, przyjmując, że były przybycia w pierwszym okresie i że ostatni z nich był w czasie 29. To nie jest zupełnie to, co byśmy chcieli, jednak, chcemy bezwarunkowego prawdopodobieństwa nie zobaczenia przybyć w drugim okresie. Jest możliwe opracowanie tego, ale będzie to skomplikowane. Jednak, łatwo jest zobaczyć, że niższa granica tego prawdopodobieństwa jest dana przez prawdopodobieństwo, że pierwsze przybycie będzie po czasie 0, wygenerowana jako wykładnicza ze średnią 20 minut, pojawia się po czasie 60 – to jest jeden sposób (a nie jedyny) żeby nie mieć przybyć w drugim okresie, i mieć prawdopodobieństwo e-60/20=e-3=0.0498. Zatem, nieprawidłowa metoda dałaby nam, co najmniej 5% szansy na brak przybyć w 2. okresie. Teraz, wróć do tekstu, i zobacz drugi przypis.

odnośnik 2. Prawdopodobieństwo braku przybyć w 2. okresie powinna wynosić e-60(1/2)=0.000000000000093576.

Dla naszego call center, musimy użyć zbiorów żeby poprawnie wymodelować personel pomocy technicznej. Musimy też rozważyć jak wymodelować zwrotne połączenia z pomocą techniczną. Są one wyjątkowe, bo muszą być odpowiedziane przez tę samą osobę z pomocy technicznej, która odebrała początkowe połączenie, więc musimy mieć sposób, żeby wyśledzić, kto pierwotnie odebrał początkowe połączenie. Zrobimy to magazynując indeks zbioru określonego zasobu przydzielonego z wybranego pracownika pomocy technicznej, więc będziemy wiedzieć która osoba potrzebuje oddzwonić, jeśli jest to konieczne.

 

5.5.3 Definiowanie danych

str. 235. W naszym pierwszym modelu, mieliśmy w sumie 5 zasobów( jeden dla 26 linii tel, jeden dla działu sprzedaży, i trzy dla działu pomocy technicznej). W naszym nowym modelu, będziemy mieli w sumie 13 zasobów ( jeden dla 26 linii tel, jeden dla działu sprzedaży, i 11 dla indywidualnych potrzeb działu sprzedaży). Z wyjątkiem kilku, linie kierują się harmonogramem (omówiliśmy harmonogramy w sekcji 4.2.2). Zdefiniowaliśmy osobny harmonogram dla każdego zasobu; jednak, jeśli kilka osób z obsługi technicznej kieruje się tym samym harmonogramem (np. Charity, Tierney, i Mya), możesz po prostu użyć ponownie pojedynczego harmonogramu, (ale spowoduje to, że twój model będzie mniej elastyczny pod względem możliwych przyszłych zmian). Opracowując harmonogram dla personelu pomocy technicznej użyliśmy GRAPHIAL SCHEDULE EDITOR, ustaliliśmy liczbę szczelin/gniazd czasowych na 22, i maksymalną pojemność na osi rzędnych (y-axis) diagramu na 2 (mogliśmy zrobić 1) w oknie dialogowym OPTIONS. Harmonogram Charity jest pokazany na Figure 5-11.

Jeśli budujesz ten model razem z nami, upewnij się, że każdy harmonogram pokrywa całe 660 minut każdego dnia, od 8.00 do 19.00 (22 półgodzinne okresy czasu), nawet jeśli musisz wypełnić wiele zer na początku albo na końcu (tak jak my zrobiliśmy na końcu dla Charity). Mimo, że harmonogram, na Figure 5-11 wygląda jakby pokrywał wszystkie 660 minut, to tak na prawdę pokrywa tylko pierwsze 17 okresów czasu [od/przez 8:30 jak pokazane na Figure 5-11]. GRAPHIAL SCHEDULE EDITOR nie zakłada, że każdy harmonogram pokrywa jeden dzień (mogą być jakiejkolwiek długości).

str. 236 W tym przypadku, harmonogram zacznie się od okresu czasu 18, który pokrywa tylko 8,5 godziny w 11-godzinnym dniu. Moglibyśmy sprawdzić ramkę pod klawiszem OPTIONS żeby „Pozostań w pojemności pod koniec harmonogramu”, i ustawić tę pojemność na 0. W wyniku dałoby to poprawny harmonogram pierwszego dnia. Problemem przy używaniu tej opcji jest to, że jeśli zdecydujemy mieć wielokrotne powielanie i wybraliśmy nie inicjalizowanie systemu na początku każdego dnia (w oknie dialogowym Run Setup), to zawsze dałoby w rezultacie pojemność 0 po pierwszym powieleniu. Zatem, chcielibyśmy się upewnić, że ostatnie 5 półgodzinnych okresów czasu wyraźnie ma pojemność 0. Możesz to zrobić klikając prawym przyciskiem myszy na komórkę DURATION harmonogramu i wybierając EDIT VIA DIALOG albo EDIT VIA SPREADSHEET. Wybranie EDIT VIA SPREADSHEET otwiera okno DURATIONS (Figure 5-12), co pozwala ci na podwójne kliknięcie żeby dodać nowy wiersz a potem wpisać Value, Czas trwania łączenia (Duration combination) na 0,5. To reprezentuje 5 30-minutowych okresów z pojemnością 0, zatem wyraźnie wypełnia 11 godzin dnia.

Wybranie EDIT VIA DIALOG otworzy okno dialogowe DURATIONS, które pozwoli ci na wpisanie tych samych wartości (Display 5-32). Jeśli otworzysz ponownie GRAPHIAL SCHEDULE EDITOR po dodaniu tych danych, ilustracja pozostanie taka sama jak przedtem. Jedna przestroga – upewnij się, że wyszedłeś z edytora bez zapisywania danych w przeciwnym razie dodane dane (0,5) zostaną skasowane.

Również zbudujemy harmonogram dla pracowników sprzedaży i procesu przybycia. Proces przybycia buduje się tak samo jak budowałeś zasób harmonogramów, z takim wyjątkiem, że wybierasz ARRIVAL w komórce TYPE, a nie CAPACITY.

Następnym krokiem jest zdefiniowanie 13 zasobów w RESOURCE DATA MODULE. Wybraliśmy opcję IGNORE dla Schedule Type pomocy technicznej, nawet, jeśli okaże się, że opcja WAIT jest najbardziej prawdopodobną opcją dla tego typu operacji. Kiedy osoba z pomocy technicznej akurat rozmawia kiedy przewidziana harmonogramem przerwa nastąpi, ta osoba typowo zakończy połączenie a potem weźmie całą przerwę (opcja WAIT). To działałby dobrze, jeśli wykonywalibyśmy tylko jedno powielanie albo wykonywalibyśmy powielanie wielokrotne i inicjowalibyśmy system na początku każdej replikacji. Niestety, nie zawsze tak się dzieje. Jeśli wybraliśmy opcję WAIT i zasób był opóźniony na 10-minutowy lunch, reszta dziennego harmonogramu będzie wypchnięta o 10 minut. Mimo, że to nie jest problem, to 10-minutowe opóźnienie ukaże się w harmonogramie następnego dnia. Wszystkie opóźnienia będą się kumulowały przez cały czas. To już mógłby być problem.

Także zawarliśmy trochę danych kalkulacyjnych [Busy/Hour – Zajęty/Godzina, Idle/Hour – bez pracy/Godzina] dla pomocy tech i działu sprzedaży, jednakże nie używamy obecnie tych wpisów w modelu operacji. Finalna wersja arkusza kalkulacyjnego pokazana jest na Figure 5-13.

str. 237. Zdefiniowawszy nasze zasoby, możemy teraz zdefiniować nasze zbiory używając SET DATA MODULE, znajdujące się w BASIC PROCESS PANEL. Najpierw zdefiniujemy 3 zbiory zasobów.

Zawartość tych zbiorów odpowiada osobom z pomocy tech uprawnionych do zajmowania się wszystkimi rodzajami produktów. Zauważ, że Molly, Anna i Sammy włączeni są w więcej niż jeden zbiór. Także, zauważ, że konsekwentnie wpisujemy te 3  wszechstronne osoby na końcu każdego zbioru rozmyślnie. Np. weź zbiór Produktu 1, który składa się z Charity, Noah, Anna and Sammy, w tej kolejności. Jeśli to możliwe, chcieliśmy przydzielić Charity i Noah dla połączeń przychodzących jako pierwszych, ponieważ mogą tylko zajmować się produktem Type 1. Użyliśmy reguły PREFERRED ORDER SELECTION, która przydziela zasoby na podstawie ich kolejności w zbiorze, zaczynając od pierwszego (Charity). W naszym modelu, będzie próbowało na utrzymanie Molly, Anna i Sammy dostępnych, ponieważ mogą zajmować się też innymi produktami.

SET MODULE pozwala nam na tworzenie zbiorów zasobów, liczników, obliczeń, rodzajów jednostek i obrazów jednostek. Możesz też stworzyć zbiór z jakichkolwiek obiektów Areny używając ADVANCED SET DATA MODULE z ADVANCED PROCESS PANEL. Stwórz zbiór klikając na SET MODULE, potem kliknij dwa razy na widok arkusza żeby dodać nowy wpis. Poprowadzimy cię przez szczegóły tworzenia pierwszego zbioru zasobów. Wpisz PRODUCT 1 w komórce NAME, i wybierz RESOURCE z komórki Type rozwijanej w dół. Żeby zdefiniować elementy zbioru, kliknij na „0 Rows” w kolumnie MEMBERS żeby otworzyć arkusz kalkulacyjny, aby móc wpisać elementy (members), a potem kliknij dwa razy żeby otworzyć nowy czysty wiersz. Ponieważ zdefiniowaliśmy już zasoby, możesz użyć opcji rozwijanej w dół żeby wybrać RESORCE NAME dla każdego elementu. Żeby dodać dodatkowe elementy do zbioru, po prostu 2 razy kliknij gdzie jest wskazane żeby dodać nowe wiersze. Ukończony arkusz kalkulacyjny elementów zbioru dla Produktu 1jest pokazany na Figure 5-14. Musisz to powtórzyć dla zbiorów Produktu 2 i 3.

Także zdefiniowaliśmy COUNTER SET (zbiór liczników) [nazwany REJECTED CALLS] z 10 elementów, które także będą uaktualniać na bieżąco liczbę odrzuconych połączeń (sygnał zajętości) dla każdego okresu godzinowego. Dla tego zbioru, najpierw zdefiniowaliśmy 10 liczników używając STATISTIC DATA MODULE  (z ADVANCED PROCESS PANEL). Przypisaliśmy nazwę statystyki od PERIOD 01 do PERIOD 10 i odpowiadające sobie Counter Names od PERIOD 01 REJECTED CALLS do PERIOD 10 REJECTED CALLS (zera poprzedzające cyfry od 1 do 9 są użyte po to, aby było wszystko poukładane w raportach wyjściowych). Wybraliśmy również REPLICATE dla komórki INITIALIZE OPTION, co spowoduje, że liczniki będą czyszczone za każdym razem gdy inne statystyki będą czyszczone, jak zostało to określone w oknie dialogowym RUN > SETUP. Mogliśmy też wybrać opcję YES; jeśli opcja NO jest określona i wielokrotne powielanie jest wykonane, wtedy wartość licznika na końcu powielania zostanie zapamiętana jako początkowa wartość dla początku następnego powielania w taki sposób, że wartości raportowane będą kumulowane podczas działania powielania. Pierwsze 5 wpisów licznika jest pokazane na Figure 5-15.

Ukończony SET DATA MODULE jest pokazany na Figure 5-16, który zawiera 3 zbiory Zasobów i 1 zbiór Licznika.

 

5.5.4 Modyfikowanie modelu

str. 239 Zmodyfikujemy Model 5-1, który stworzyliśmy wcześniej, aby utworzyć nowy Model 5-2. Już omówiliśmy prawie wszystkie wymagane pojęcia zawarte w tych modułach, więc nie będziemy cię zanudzać detalami każdego z nich. Zamiast tego, skupimy się na nowych modułach i pojęciach.

Zacznijmy od sekcji połączeń przybywających. Zrobiliśmy pierwszą zmianę dla CREATE MODULES, który tworzy nasze połączenia przychodzące. W sekcji TIME BETWEEN ARRIVALS, wybraliśmy SCHEDULE z listy Type rozwijanej w dół. Harmonogram przybyć, ARRIVAL SCHEDULE, który stworzyliśmy powyżej został wpisany w pole SCHEDULE NAME. Ponieważ CREATE MODULE będzie prowadził harmonogram według wzoru i automatycznie zatrzyma tworzenie nowych przybyć po 11 godzinach symulacji, możemy wykasować trzy moduły, które mieliśmy w sekcji przerwanie przybycia w Modelu 5-1. Również wykasowaliśmy ASSIGN MODULE, INCREMENT ACTIVE CALL COUNTER, użyty do inkrementowania zmiennej WIP. Użyliśmy tej zmiennej w wyrażeniu, które wpisaliśmy w części TERMINATING CONDITION w oknie dialogowym RUN > SETUP dla Modelu 5-1. Zastąpiliśmy tą zmienną inną zmienną o nazwie NR (TrunkLine). Zrobiliśmy to z dwóch powodów. Po pierwsze, nie potrzebowaliśmy pierwszej zmiennej, więc uprościliśmy nasz model przez usunięcie jej. Po drugie, używanie zmiennej Total WIP w nowym układzie wymagałoby poradzenia sobie z oddzwanianiem w obszarze pomocy technicznej, co powodowałoby problemy z modelowaniem. Moglibyśmy dekrementować zmienną, kiedy połączenie zwrotne było wysłane na zaplecze organizacyjne, a potem inkrementować ją, kiedy zasób został zwrócony do pomocy tech. Więc poszliśmy na łatwiznę, ponieważ zmienna naprawdę nie była potrzebna i wyrzuciliśmy ją z modelu. Ostatnia zmiana wymagana dla pierwszej sekcji modelu było użycie RECORD MODULE, żeby zapisać liczbę połączeń odrzuconych. Jak było wspomniane wcześniej, zdecydowaliśmy się uaktualniać na bieżąco połączenia odrzucone w każdym 1-godzinnym okresie czasu.

str. 240 Żeby tego dokonać, zdefiniowaliśmy 10 liczników w STATISTIC DATA MODULE i utworzyliśmy zbiór o nazwie REJECTED CALLS zawierający te połączenia. Zmodyfikowaliśmy RECORD MODEULE 1, sprawdzaniem RECORD do SET BOX  i wpisaliśmy te samą nazwę. Potem rozbudowaliśmy wyrażenie AINT [(TNOW/60)+1], które zwracałoby całkowitą wartość, która reprezentuje bieżący okres na podstawie czasu trwania symulacji (Display 5-33); żeby zrozumieć jak to wyrażenie działa, zauważ, że TNOW jest wewnętrzną wartością symulacji- zegara Areny, (w minutach, nasze BASE TIME UNITS) AINT jest wbudowaną funkcją Areny, która ścina argument liczby rzeczywistej w kierunku zera, a potem uruchamia komputer/symulację przez wartości minutowe TNOW.

Przejdźmy teraz do zmian, których dokonaliśmy dla sekcji TECH SUPPORT CALLS. Pierwsze 5 modułów (do i włączając DETERMINE PRODUCT TYPE modułu DECIDE)pozostaje takie samo jak w Modelu 5-1. Poprowadziliśmy cię przez zmiany wymagane dla produktu Type 1 pomocy technicznej i odesłaliśmy cię do pliku Model 05-02.doe dla różnic dla pozostałych dwóch typów połączeń z pomocą techniczną.

Bezpośrednio, następnie po DETERMINE PRODUCT TYPE DECIDE MODULE, wstawiliśmy ASSIGN MODULE,  gdzie zrobiliśmy 3 przypisania. Najpierw przypisaliśmy nowy typ jednostki i obrazek jednostki, więc możemy pokazać różnicę między połączeniami dla różnych typów produktu zarówno w animacji jak i w raportach. Zdefiniowaliśmy także nowy atrybut o nazwie TECH CALL TYPE , który jest przypisany do całkowitej wartości z 1,2, i 3, zależnie od typu produktu. Wkrótce zobaczysz, dlaczego potrzebujemy nowego atrybutu.

Następujący PROCESS MODULE jest taki sam z wyjątkiem informacji w sekcji RESOURCE. Ponieważ zastąpiliśmy pojedynczy zasób, Tech1, w Modelu 5-1 zbiorem zasobu PRODUCT 1, musieliśmy zmodyfikować tę sekcję. Zmieniliśmy TYPE na SET i wpisaliśmy PRODUCT 1 dla SET NAME. Wybraliśmy PREFERRED ORDER dla SELECTION ROUTE i zdefiniowaliśmy nowy atrybut, TECH AGENT INDEX, dla POLA SAVE ATTRIBUTE. Kiedy zdefiniowaliśmy zbiory zasobu, konsekwentnie umieściliśmy w spisie najbardziej wszechstronnych członków personelu na końcu każdego zbioru. Zatem, jeśli jest to możliwe, chcielibyśmy przydzielić Charity albo Noah do połączenia przychodzącego najpierw, ponieważ mogą tylko zajmować się produktem Type 1 call. Reguła PREFERRED ORDER SELECTION przydziela zasoby na podstawie ich kolejności w zbiorze, jeśli jest wybór pomiędzy wielokrotnymi bezczynnymi zasobami, zaczynając od pierwszego (Charity). W naszym modelu, to spróbuje trzymać Molly, Anna i Sammy dostępnych; pamiętaj, że mogą zajmować się również innymi typami połączeń. Również zmagazynowaliśmy indeks zasobu przydzielony do SAVE ATTRIBUT TECH AGENT INDEX ponieważ musimy wiedzieć która osoba odebrała połączenie jeśli wymagane jest dalsze postępowanie i połączenie zwrotne.

str. 241. To dopełnia zmian w tej sekcji naszego modelu, ale tak długo jak zajmujemy się połączeniami z pomocą techniczna, rozbudujemy nową sekcję dla naszego modelu żeby poradzić sobie z połączeniami zwrotnymi pomocy tech.

Logika dla tej sekcji jest pokazana poniżej (If costumer….. system exit – pominięte)a moduły schematu blokowego na Figure 5-17.

Kompletna jednostka połączenia z pomocą tech jest wysyłana do DECIDE MODULE o nazwie „Backoffice Research and Return Call?” gdzie 96% połączeń jest uważanych za zakończone (założyliśmy że jest to Fałszywy skok – „False branch”) i są kierowane do tego samego wyjścia z systemu jakiego użyliśmy w Modelu 5-1. Pozostałe 4% (Prawdziwy skok – „True branch”) jest wysyłane do RELEASE MODULE gdzie Trunk Line jest zwalniana, ponieważ połączenie jest teraz rozłączane. Następnie DELAY MODULE opóźnia jednostkę na EXPO 60 minut, ponieważ jest to czas wymagany na dalsze postępowanie, prowadzony przez niezdefiniowany zasób poza granicami naszego modelu [jakakolwiek kolejka jest przetaczana na czas EXPO (60)]. Jeśli połączenie wchodzi w to opóźnienie pod koniec dnia i nie może być ukończone tego dnia, może, w rzeczywistości, być przeniesione na następny dzień. Ponieważ nasz model trwa przez jeden dzień, takie połączenia po prostu są nieukończone podczas działania. Także zdefiniowaliśmy i wpisaliśmy STORAGE ID „Backoffice Research Storage”, więc możemy pokazać te jednostki na animacji. Po opóźnieniu, jednostka jest wysyłana do ASSIGN MODULE gdzie inkrementujemy jednowymiarową tablicę zmiennej Tech Return WIP używając wartości atrybutu Tech Call Type jako indeksu.

str. 242. Możesz zdefiniować tę zmienną w ASSIGN MODULE, ale najpierw musisz otworzyć VARIABLE DATA MODULE i wpisać wartość 3 w komórce ROW, która definiuje rozmiar tablicy. Następnie odczytujemy elektronicznie (sense) typ produktu z N-WAY przez CONDITION TEST w „Product Type?”. DECIDE MODULE kieruje połączenie zwrotne do odpowiedniej gałęzi.

Jednostka połączenia zwrotnego musi schwycić zasób i linii (połączenia wychodzące potrzebują linii tak samo jak przychodzące), i właściwą osobę z pomocy tech, która pierwotnie odebrała połączenie przychodzące. Opisaliśmy rzeczy dla produktu Type 1; pozostałe dwie są podobne. W następnym SEIZE MODULE połączenie zwrotne pomocy tech produktu Type 1 łapie z odpowiedniego Zbioru Zasobu personelu pomocy tech. Kolejka jest możliwa, i użyjemy oddzielnej kolejki (i animacji), i określimy priorytet chwytania jako wysoki [seize Prioryty as High (1)], ponieważ połączenie wychodzące zwrotne będzie miało większy priorytet niż połączenie przychodzące. Tutaj schwyciliśmy tylko osobę z pomocy tech, ale nie linię (zrobimy to w kolejnym module). To połączenie zwrotne musi iść do tej samej osoby, która odebrała pierwotne połączenie od klienta, więc użyjemy Specific Member SELECTION RULE i określimy ATTRIBUTE Tech Agent Index w polu SET INDEM żeby się upewnić o tym.

Jak schwycimy już odpowiednią osobę z Tech 1, połączenie zwrotne Tech 1 może teraz schwycić linię (Trunk LIne) w kolejnym PROCESS MODULE, z High Priority nad Medium priority połączeń przychodzących. Przetwarzanie opóźnienia bazuje na wyrażeniu Return Tech Time i kiedy jest zakończone, linia jest zwalniana. Kolejka może wystąpić w tym module, jeśli żadna linia nie jest natychmiast dostępna. Podczas tego czasu, animacja jest nadal dokładna, ponieważ obrazek jednostki pokazuje się w animacji Zasobu SEIZE AREA, więc nie ma oddzielnej kolejki dla tego. Kiedy połączenie jest ukończone, określona osoba z pomocy tech jest uwalniana w następnym RELEASE MODULE.

W naszej pierwszej próbie rozwijania tej sekcji, użyliśmy pojedynczego PROCESS MODULE z wysokim priorytetem, aby w tym samym czasie schwycić i osobę z pomocy tech i linię. Kiedy uruchomiliśmy naszą symulację i obserwowaliśmy animację, zdaliśmy sobie sprawę, że te połączenia zwrotne czekały już na długo przed tym jak zostały przetworzone. Okazało się, że kiedy podchodzisz do modelowania w ten sposób, oba zasoby muszą być dostępne w tym samym czasie dla jednostki, aby postępować/zachodzić. Jeśli tylko jeden z określonych zasobów jest dostępny a system jest zajęty, najprawdopodobniej zostanie przydzielony do innej czekającej jednostki. Ponieważ te połączenia zwrotne mają wysoki priorytet, zdecydowaliśmy się schwytać zasoby oddzielnie. Zdaliśmy sobie sprawę, że w prawdziwym systemie najprawdopodobniej połączenie będzie przydzielone do określonej osoby pomocy tech, która będzie próbowała oddzwonić tak szybko jak on albo ona będzie dostępny/a. Oczywiście oddzwaniając, on albo ona będzie musiał/a najpierw schwycić dostępną linię. Więc zmodyfikowaliśmy nasz model logiczny przez rozdzielenie dwóch operacji chwytania tak jak zostało to poprzednio opisane.

Po ukończeniu połączenia zwrotnego, jednostka wchodzi w ASSIGN MODULE gdzie ustalona zmienna Tech return WIP jest dekrementowana. Ukończone połączenie jest teraz gotowe do wysłania do wyjścia z systemu. W każdym innym przypadku, kiedy zakończone połączenie zostało wysłane do wyjścia z systemu, cały czas ma ono zasób linii (Trunk Line), więc pierwszym modułem był RELEASE MODULE, żeby uwolnić ten zasób. Te jednostki już zwolniły zasób linii, więc musimy wysłać jednostki do RECORD MODULE, a następnie do RELEASE MODULE.

Jeśli spojrzysz na STATISTIC DATA MODULE, zobaczysz, 10 wejść typów Liczników opisanych wcześniej. Utworzyliśmy także 4 statystyki typu TIME-PERSISTENT, aby żądać wyników (średni czas, minimum i maximum) całkowitej liczby połączeń badania zaplecza organizacyjnego dla połączenia zwrotnego(śledząc zmienną NSTO (Backoffice Research Storage)) i dla całkowitej liczby każdego typu produktu w systemie (śledząc  wyrażenia Tech 1 Total Online WIP, Tech 2 Total Online WIP, Tech 3 Total Online WIP).

str. 243. Nasz nowy model nie wymaga żadnych zmian dla połączeń sprzedażowych i o status zamówienia Modelu 5-1.

Zróbmy przegląd modyfikacji naszej animacji. Takie same pozostają: 3 zanimowane pamięci dla zapisu opóźnienia, wykres zajętych linii (Trunk Line Busy plot), zmienna dla Sales WIP i kolejka dla połączeń czekających na pomoc tech i sprzedaż. Najpierw usunęliśmy zasoby Tech 1, Tech 2 i Tech 3 z animacji. Potem zmieniliśmy nazwy zmiennych dla 3 obrazów WIP, żeby pasowały do naszego nowego modelu. Np, zmieniliśmy zmienną WIP dla produktu Type 1 z Process Product Type 1 Tech Call.WIP na Tech 1 Total Online WIP, która jest wyrażeniem zdefiniowanym w EXPRESSION DATA MODULE żeby była Process Product Type 1 Tech Call.WIP + Tech Return WIP (1), więc jest to za każdym razem całkowita liczba połączeń pomocy tech dla produktu Type 1, który są „otwarte” albo jako połączenia przychodzące albo jako zaplecze organizacyjne dla połączeń zwrotnych. Zreorganizowaliśmy też naszą nową animację żeby uwzględniała obszar Back Office Research i dodaliśmy zmienną WIP, NSTO (Backoffice Research Storage); NSTO jest wbudowaną funkcją Areny, która zwraca liczbę jednostek w STORAGE określonej w swoim argumencie.

Dodaliśmy też 3 nowe kolejki dla obszary pomocy tech żeby pokazać połączenia zwrotne czekające na obsługę. Ta kolejka dla obszaru Tech 1 jest Seize Tech Agent Type 1.Queue. Potem dodaliśmy animację pamięci, żeby pokazać połączenia zwrotne, które mieliśmy do dalszego badania dla nowego obszaru badania zaplecza organizacyjnego, Backoffice Research Storage.

Ostatnią zmianą było dodanie zasobów dla naszego nowego personelu pomocy tech. Wybraliśmy Charity z listy zasobu i otworzyliśmy bibliotekę z obrazami Areny, Office.plb. Tam znaleźliśmy obrazek osoby siedzącej przy biurku z nieczynnym telefonem i drugi obrazek z osobą rozmawiającą przez telefon. Skopiowaliśmy pierwszy obrazek żeby przedstawiał nasz Idle picture (bezczynny obrazek) i drugi żeby był Busy picture (zajętym obrazkiem). Dla naszego Inactive state, zmodyfikowaliśmy pierwszy obrazek, żeby przedstawiał biurko bez operatora. Potem zamknęliśmy okno i umieściliśmy zasób. Po sortowaniu wg wymiarów naszych zasobów, użyliśmy opcji TEXT żeby go oznaczyć. Potem zrobiliśmy kopię tych dwóch obiektów i zmieniliśmy identyfikator, żeby reprezentował Noah. Powtórzyliśmy to dla Tierney, ale zmieniliśmy kolor koszuli w obrazkach Idle i Busy. Naszym planem było użycie innych kolorów koszul żeby zaprezentować różne uprawnienia personelu pomocy.

Finalna wersja zanimowanej symulacji jest podobna do Figure 5-18, którą otrzymaliśmy w przybliżonym czasie 341.1. W CATEGORY OVERVIEW REPORT, widzimy w USER SPECIFIED section’s COUNTER, że najwięcej połączeń odrzuconych pojawia się w godzinach 5-8 (odpowiadającym od południa do 16.00), więc to może być okres czasu, w którym należałoby dodać personel (jednak, zrobiliśmy tylko jedno powielanie więc taka konkluzja jest statystycznym przypuszczeniem); podjedliśmy to w sposób bardziej zorganizowany i statystycznie wiarygodny w Rozdziale 6.

str.244. Mówiąc o statystycznej wiarygodności, jest jeszcze jedna lekcja poglądowa (dla nas, w rzeczywistości) z Modelu 5-2. Podczas rozbudowywania a potem aktualizowania tego modelu, dodaliśmy ostateczny szlif robiąc kilka małych zmian, które myśleliśmy, że nie zmienią wcale modelu (zmiana nazw dwóch osób pomocy tech, żeby być dokładnym). Myśleliśmy że nie zmienią one wyniku, ale zmieniły go, ku naszemu (początkowemu) zaskoczeniu. Przyczyną jest to, że każda zmiana w modelu, nie ważne jak (pozornie) nieistotna, potencjalnie zmienia wykonywalny kod (executable code) pod względem kolejności operacji; np. w przypadku związków czasu, które są rozwiązywane w zasadniczo dowolny sposób. Zmiana nazwy najwyraźniej to zrobiła, powodując, że różne zdarzenia miały dostęp do ustalonych podstawowych sekwencji liczb losowych (zobacz sekcja 12.1) w różnej kolejności, i w ten sposób prowadząc do różnych liczbowych rezultatów. Na początku byliśmy wytrąceni z równowagi i straciliśmy wiele dni starając się znaleźć nasze błędy, ale to właściwie tylko podkreśliło kwestię tego, że wyniki liczbowe symulacji stochastycznych (tych używających losowych liczb w jakikolwiek sposób) są same w sobie losowe, więc podlegają losowym wahaniom/wariacjom. Zatem, dokładne wyniki liczbowe z jednego powielania nie mogą być pewne, i naprawdę konieczne jest zrobienie pewnego rodzaju statystycznej analizy wyników symulacji, jak opisaliśmy w Rozdziale 6.

 

5.6 Model 5-3: Udoskonalone call center z większą ilością wyjściowych pomiarów osiągnięć

Chociaż Model 5-2 wytwarza mnóstwo wyjściowych pomiarów osiągnięcia, nie wytwarza całkowitych ekonomiczny figur wartości, na których łatwo moglibyśmy porównać różne konfiguracje. Wiele badań modelowania skupia się na zredukowaniu kosztów (albo idealnie, zminimalizowania kosztów), więc stworzyliśmy całkowity pomiar kosztów jako główny wynik. W tym samym czasie, dodamy kilka opcji do modelu żeby przygotować pole do porównania innych możliwości i do szukania najlepszego rozwiązania w Rozdziale 6. Żeby uzyskać lepszą dokładność statystyczną również, zrobimy pięć powieleń, reprezentujących tydzień roboczy i skupimy się na kosztach tygodniowych.

Są dwa podstawowe obszary, w których pojawiają się koszty: (1) obsada etatów i koszty i koszty zasobów, które są dość konkretne i łatwe do zmierzenia, i (2) koszty z powodu kiepskiej obsługi, które są mniej konkretne i mogą być ciężkie do określenia ilościowego. Rozważymy te dwa rodzaje kosztów oddzielnie.

str. 245                                Najpierw spójrzmy na obsadę etatów i koszty zasobów, niektóre z nich zdefiniowaliśmy w Modelu 5-2, ale ich nie używaliśmy. W RESOURCE MODULE Modelu 5-2, zdefiniowaliśmy koszt $20 na godzinę dla personelu prowadzącego sprzedaż i $18-22 na godzinę dla personelu pomocy technicznej, zależny od poziomu wyszkolenia pracowników i ich elastyczności; te koszty były poniesione ilekroć personel był obecny zgodnie ze swoim harmonogramem, niezależnie od tego czy byli zajęci czy wolni. Używając informacji o personelu opisanym w Sekcji 5.5 (i zdefiniowanej w SCHEDULE DATA MODULE Modelu 5-2), tygodniowy koszt dla personelu, który pracował jest:

Personel prowadzący sprzedaż w sumie:…….

Personel prowadzący pomoc techniczną:……..

Sumując, dostaliśmy tygodniową bieżącą listę płac o wysokości $12,820.

Żeby poprawić obsługę, teraz uogólnimy model, żeby pozwalał na dodatkowy personel. Patrząc na liczenie na godzinę sygnałów zajętości (busy-signal balks) z Modelu 5-2, wygląda na to, że najbardziej poważny niedobór personelu jest pomiędzy południem a 16.00, więc stworzyliśmy w modelu zdolność dodawania i sprzedawców i obsługi technicznej podczas tego 4-godzinnego okresu, który odpowiada 4-godzinnemu okresowi od 5 do 8.

Żeby dodać łatwą w kontroli zmienną ilość personelu sprzedaży, zdefiniowaliśmy zmienną New Sales, żeby była liczbą dodatkowego personelu sprzedażowego, który zatrudnimy na 4-godzinny okres każdego dnia, za cenę $17 na godzinę. Zatem każda dodatkowa osoba personelu sprzedażowego będzie pracowała 20 godzina na tydzień, więc koszt dodatkowy to $17/godzinę X 20 godzin/tydzień = $340 na tydzień dla każdej nowej osoby ze sprzedaży. Żeby umieścić nowy personel sprzedażowy w modelu, skorygowaliśmy wiersz Sales Schedule w SCHEDULE DATA MODULE. Ponieważ użyliśmy Zmiennej (New Sales) jako część harmonogramu, nie możemy użyć GRAPHICAL SCHEDULE EDITOR i musimy wchodzić w ten harmonogram używając jego okna dialogowego (albo arkusza kalkulacyjnego); kliknij prawym przyciskiem myszy na wiersz Sales Schedule, a potem wybierz EDIT VIA DIALOG. Display 5-34 pokazuje gdzie zmiany były wprowadzone. Oczywiście, jeśli ustawiliśmy New Sales na 0, to mamy ten sam układ personelu sprzedaży jak w modelu podstawowym.

Podobnie zrobiliśmy żeby dodać personel pomocy technicznej podczas tego okresu od 12.00 do 16.00. Zdefiniowaliśmy nowe Zmienne New Tech 1, New Tech 2, New Tech 3, aby były liczbą dodatkowego personelu pomocy tech, wykwalifikowanego dla produktów Type 1,2 i 3, w kolejności, i New Tech All, aby były liczbą dodatkowego personelu pomocy tech, wykwalifikowanego dla Wszystkich typów produktów. Oczywiście, nowe osoby pomocy tech dla Type 1 wszystkie są nazwane Larry, nowe osoby pomocy tech dla Type 2 wszystkie są nazwane Moe, nowe osoby pomocy tech dla Type 3 wszystkie są nazwane Curly, a nowe osoby pomocy tech dla All-type są nazwane Hermann. 4 nowe wpisy w RESOURCE DATA MODULE są dodane, aby stworzyć te zasoby i zdefiniować stawkę godzinową (hourly rate) dla nich ($16 dla każdego Larry, Moe i Curly, i $18 dla każdego Hermann). Żeby wyrazić ich kwalifikacje, dodaliśmy Larry do zbioru Product 1 w SET MODULE, Moe do zbioru Product 2, Curly do zbioru Product 3, a Hermann do wszystkich trzech zbiorów. Stworzyliśmy wpisy w harmonogramie dla wszystkich czterech nowych zasobów. Harmonogram Larry jest na Display 5-35, a pozostałe trzy są podobne; tak jak harmonogram sprzedażowy, ten może być edytowany tylko za pomocą okna dialogowego (albo arkusza kalkulacyjnego), a nie przez GRAPHICAL SCHEDULE EDITOR, ponieważ zawierają zmienne. Ponieśliśmy koszty 16 X 4 X 5 + $320 na tydzień dla każdego Larry, Moe i Curly, i 17 X 4 X 5 = $360 na tydzień dla każdego Hermann.

str. 246.               Końcowym sposobem zmodyfikowania mieszaniny zasobów jest zmiana liczby linii, które były wcześniej ustalone na 26. Zasób Trunk Line jest zdefiniowany w RESOURCE MODULE jako prosty zasób Fixed Capacity (ustalona pojemność), więc tylko zmodyfikujemy tam wpis, jeśli chcemy zmienić liczbę linii. Żeby w tym zbudować koszty, poniesiemy koszt jednolity $98 na tydzień za każdą linię, umowa, która obejmuje wszystkie lokalne i międzymiastowe użycie tej linii.

str. 247.               Aby ocenić wszystkie powyższe koszty zasobów, zdefiniowaliśmy Wyrażenie o nazwie New Res Cost. Display 5-36 pokazuje wpisy dla nich w EXPRESSION DATA MODULE. Wszystko dotyczące tego Wyrażenia było opisane powyżej, oprócz MR (TrunkLine), które używa wbudowanej funkcji Areny MR, która podaje liczbę elementów Zasobu w argumencie, w tym przypadku, Trunk Line. Zauważ, że to Wyrażenie nie zależy od tego, co się stanie podczas symulacji i jest użyte tylko pod koniec w STATISTIC MODULE, żeby pomóc wyprodukować końcowe wyjściowe pomiary osiągnięcia.

Teraz wróćmy do innej kategorii kosztów systemu, te ponoszone, kiedy klient nie odkłada słuchawki. Niewątpliwie, to wymiana zasobów i kosztów obsady etatów; Możemy użyć naszego modelu, żeby zbadać te wymiany, i może nawet spróbować je zoptymalizować. W praktyce takie rodzaje kosztów niezadowolenia klienta są trudne do określenia, więc musimy polegać na ankietach i technikach takich jak analiza metodą regresji, aby znaleźć/dojść liczby.

str. 248                                Założyliśmy, że większość ludzi do tej pory jest zahartowana wystarczająco, żeby oczekiwać czasu oczekiwania podczas zawieszenia rozmowy, kiedy mamy do czynienia z call center, ale w pewnej chwili, ludzie zaczynają się wściekać, a system zaczyna naliczać koszty. Dla połączeń technicznych to 3 minuty; dla połączeń sprzedażowych tp 1 minuta; dla połączeń o status zamówienia to 2 minuty. Ponad ten punkt tolerancji dla każdego typu połączenia, system będzie naliczał koszt 36.8 centów za minutę dla wszystkich połączeń z pomocą techniczną, które są zawieszone, 81.8 centów za minutę dla połączeń sprzedażowych i 34.6 centów za minutę dla połączeń o status zamówienia. Dla każdego typu połączenia, gromadzimy w zmienną „excess” („nadwyżka”) czasu oczekiwania w kolejce (np., czas oczekiwania w kolejce ponad odcięciem tolerancji) wszystkich ukończonych połączeń poprzez nowy ASSIGN MODULE, przez który jednostki przechodzą po tym jak ich połączenia są załatwione/zakończone.

Display 5-37 pokazuje ten nowy ASSIGN MODULE dla połączeń pomocy tech, i dwa inne są podobne (umieściliśmy jasno pomarańczowe kratki/pudełka za nowymi ASSIGN MODULE, więc możesz je łatwo zlokalizować w modelu). Zauważ, że ENTITY.WAITTIME jest wbudowanym atrybutem Areny, który automatycznie gromadzi całkowitą liczbę razy jednostki w kolejce jak idzie, tak samo jak inne czasy opóźnienia przydzielone do „Wait”. W naszym modelu, nie ma takich przydzielonych opóźnień, i nie ma opóźnień kolejek pod góre innych niż te, które czekają wstrzymane na odebranie, więc ta wartość rzeczywiście/faktycznie zawiera to, co chcemy w tym przypadku. (Obliczanie ENTITY.WAITTIME zdarza się tylko wtedy, gdy COSTING BOX jest sprawdzony zaznaczony w oknie dialogowym RUN > SETUP >PROJECT PARAMETERS, więc musimy sprawdzić czy jest zaznaczone). Pod koniec symulacji, zmienna Excess Tech Wait Time będzie liczbą całkowitą minut poza 3-minutową tolerancją co kończy połączenia techniczne przetrzymane podczas całego dnia pracy programu, i po 5 powieleniach, będzie to podzielona produkcja, w końcowym wyniku, średnia dzienna nadwyżka czasu oczekiwania tech. Jeśli to pomnożymy przez koszt za minutę 36.8 centów, dostaniemy koszt nadwyżki czasu oczekiwania tech na dzień, a my kalkulujemy koszty na podstawie tygodnia, więc musimy zamiast tego pomnożyć przez 36.8 centów X 5 = $1.84, żeby dostać tygodniowy koszt. Koszty dla dwóch innych typów połączeń są obliczane podobnie (współczynnik, przez który musimy podzielić nadwyżkę czasu oczekiwania, aby dostać tygodniowy koszt to 81.8 centów X 5 = $4.09 dla połączeń sprzedażowych, i 34.6 centów X 5 = $1.73 dla połączeń o status zamówienia). Podczas robienia 5 powieleń jednego dnia, może być to pomyślane jako tydzień pracujący, model w ten sposób zbudowany będzie produkował szacunkowy tygodniowy koszt bez względu na liczbę powieleń (użyjemy tego modelu w Rozdziale 6 z więcej niż 5 powieleniami, żeby udoskonalić dokładność wyników wyjściowych).

Umieszczając wszystkie te różne koszty razem w jeden całkowity pomiar kosztów jest całkiem proste. Podane wyżej dyskusja i układ, całkowity Total cost wyjściowych pomiarów osiągnięcia jest „New Res Cost ……. 12820”, (str. 249) która wpisujemy w STATISTIC DATA MODULE (w ADVANCED PROCESS PANEL); Typ tej Statystyki jest wybrany jako Output (pomiar wyjściowy), co oznacza, że jest to ilość, która oblicza tylko na końcu symulacji i tylko jej wartość chcemy widzieć w końcowych raportach. Ponieważ zdefiniowaliśmy tę Output sami, a nie użyliśmy wewnętrznego obliczania Areny, pojawi się ono pod User Specified -> Output w raporcie Category Overview.

W tym momencie, prawdopodobnie zastanawiasz się, co się stało z tymi biednymi nieszczęśliwymi duszami, które zadzwoniły tylko po to, aby być natychmiast zignorowane przez sygnał zajętości. Nie miały one nawet szansy się zdenerwować po tym jak ich czas tolerancji wstrzymania i zacząć obciążać kosztami system [nawet, jeśli naprawdę są wkurzeni]. Mogliśmy oszacować (duży) koszt za każdy sygnał zajętości i wbudować to w strukturę kosztów naszego systemu, ale zamiast tego zdecydowaliśmy się obliczyć procent połączeń przychodzących, które otrzymują sygnał zajętości i wyprodukować to jako osobne dane wyjściowe (output). Zamiast patrzenia na to jako na część celu  miernika osiągnięć modelu, widzimy to raczej jako zapotrzebowanie (requirement) [jako rodzaj ograniczenia (constraint), z wyjątkiem, że jest to o danych wyjściowych a nie o danych wejściowych], że nie więcej jak 5% połączeń przychodzących otrzymuje sygnał zajętości; jakikolwiek model nie spełniający tych wymagań będzie postrzegany jako nie do przyjęcia, bez względu na to jak niskie będą dane wyjściowe Total Cost.

Aby obliczyć procent połączeń przychodzących, które otrzymują sygnał zajętości, musimy znać całkowitą liczbę usiłowania połączeń i połączeń odrzuconych. Mamy już RECORD MODULE, który liczy liczbę usiłowania połączeń (licznik Attempted Calls). Również, policzyliśmy liczbę połączeń odrzuconych, ale obecnie liczymy te połączenia odrzucone na bazie na godzinę. Moglibyśmy zsumować wartości z 10 liczników, ale poszliśmy na łatwiznę i dodaliśmy kolejny RECORD MODULE w sekcji połączeń przybywających modelu logicznego (z jasno pomarańczowym wierszem/kratką za nim), która da nam te liczbę całkowitą (licznik Total Rejected Calls). Żeby obliczyć wartość danych wyjściowych Percent Rejected, dodaliśmy wiersz do STATISTIC MODULE z tą nazwą i wyrażeniem 100*NC(TOTAL REJECTED CALLS)/NC(ATTEMPTED CALLS); NC jest wbudowaną funkcją Areny, która zwraca wartość licznika nazwanego w swoim argumencie.

Ponieważ zażądaliśmy wielokrotnego (5) powielania, musimy powiedzieć Arenie co ma robić między powieleniami. Jest 4 możliwe opcje.

OPCJA 1: Initialize System (yes), Initialize Statistics (yes)

Da to w rezultacie 5 statystycznie niezależnych i identycznych powieleń i raportów, każdy zaczynający się pustym systemem w czasie 0 i każdy trwający 660 minut. Generator liczb losowych (random-number generator) [zobacz Sekcja 12.1] nie przestaje pracować pomiędzy replikacjami, robiąc je niezależne i identycznie rozdzielane (IID). Możliwe połączenia zwrotne pomocy technicznej przeniesione na następny dzień zostają utracone.

OPCJA 2: Initialize System (yes), Initialize Statistics (no)

Da to w rezultacie niezależne powielenia, każde zaczynające się się pustym systemem w czasie 0 i każde trwające 660 minut, z raportami, które narastają/kumulują/ są zbiorcze.                 str. 250. Zatem, Raport 2 będzie zawierał statystyki dla pierwszych dwóch powieleń, Raport 3 będzie zawierał statystyki dla pierwszych trzech powieleń, itd. Generator liczb losowych zachowuje się jak w Opcji 1.

OPCJA 3: Initialize System (no), Initialize Statistics (yes)

Da to rezultacie 5 wykonań biegu programu, pierwszy zaczynający się o czasie 0, drugi po tym jak pierwsze się zakończy (pamiętaj, że używamy reguły zatrzymania żeby zakończyć powielenie), trzeci po tym jak drugi się zakończy, itd. Ponieważ system się nie inicjalizuje pomiędzy powieleniami, czas kontynuuje postęp i żadne połączenia pomocy tech które nie zostały oddzwonione będą przeniesione na następny dzień. Raporty będą zawierały tylko statystyki dla pojedynczego powielenia albo dnia, niż będą się kumulowały.

OPCJA 4: Initialize System (no), Initialize Statistics (no)

Da to rezultacie 5 wykonań biegu programu, pierwszy zaczynający się o czasie 0, drugi po tym jak pierwsze się zakończy, trzeci po tym jak drugi się zakończy, itd. Ponieważ system się nie inicjalizuje pomiędzy powieleniami, czas kontynuuje postęp i żadne połączenia pomocy tech które nie zostały oddzwonione będą przeniesione na następny dzień. Raporty są zbiorcze.

 

Idealnie byłoby użyć albo Opcji 3 albo 4, ponieważ chcielibyśmy przenieść wszystkie nieoddzwonione połączenia pomocy tech na następny dzień. Jednak, to by wymagało od nas zmiany reguły zatrzymania i pozwolenia trwać każdemu powielenie 660 minut. Więc pozwól, że przyjmiemy wartość domyślną – Opcję 1.

Jak przeszedłeś przez dyskusję w tej sekcji, prawdopodobnie myślałeś, że jest wiele innych sposobów, jakich mogliśmy użyć, aby ukończyć wiele rzeczy, jakie zrobiliśmy. Mogłoby to być możliwe, na przykład, pełniej wykorzystać wbudowane zdolności kalkulacji kosztów Areny niż robić wiele rzeczy samemu i sparametryzować model inaczej, używając tylko „prymitywnych” wartości wejściowych takich jak płaca i liczba pracowników. Albo mogliśmy pozwolić Arenie policzyć pewne rzeczy wewnętrznie, które my liczyliśmy zewnętrznie, używając naszych małych kalkulatorów. To wszystko prawda, ale zajęłoby to więcej czasu i wysiłku. To jest typowy werdykt, jaki musisz podjąć budując model – zamieniając czas budowania modelu na ogólność modelu (i może elegancję), zazwyczaj jest się prowadzonym przez tego, kto będzie używał modelu, i do czego. Układ tego modelu będzie przydatny w następnym rozdziale, gdzie pokażemy Ci kilka zdolności Areny dotyczące ważnej czynności analizy statystycznej symulacji danych wyjściowych.

Uruchomiliśmy model, można tak nazwać „podstawowy przypadek” (base case), bez dodatkowych pracowników czy linii telefonicznych (np., New Sales, New Tech 1, New Tech 2, New Tech 3 i New Tech All były określone na 0, a liczba linii tel była określona na 26). Total Cost okazał się być $22,242.55 na tydzień, i 11.96% połączeń przychodzących otrzymywało sygnał zajętości. Ponieważ procent połączeń odrzuconych jest powyżej naszego docelowego poziomu 5%, kolejny raz uruchomiliśmy model, gdzie zwiększyliśmy wszystkie 6 wejściowych zasobu „kontrolujących” zmienne na 3 (np., New Sales, New Tech 1, New Tech 2, New Tech 3 i New Tech All były określone na 3, a liczba linii tel była określona na 29); to wytworzyło Total Cost $23,683.35, i tylko 1.61%  połączeń przychodzących otrzymywało sygnał zajętości; najwyraźniej, koszt zatrudnienia dodatkowego personelu i dodanie 3 linii tel nie jest mądrą inwestycją patrząc wyłącznie na Total Cost. str. 251. Ale zredukowało to procent połączeń odmownych do dopuszczalnego poziomu. Jednak, powinieneś mieć niejasne przeczucie dotyczące tej „analizy” (my mieliśmy), ponieważ każdy rezultat pochodził tylko z 5 powieleń. Nie wiemy czy wyniki są tylko postrzegane jako losowy odskok, (random bounce), albo czy moglibyśmy śmiało powiedzieć, że drugi układ jest lepszy, albo jak śmiało wybraliśmy jeden spośród kilku różnych scenariuszy, albo który scenariusz byłby najlepszy. To są te zagadnienia, jakie podejmiemy w Rozdziale 6, i użyjemy Modelu 5-3 aby się im przyjrzeć.

5.7 Model 5-4: An (s, S) Symulacja Inventarza

Zamkniemy ten rozdział rozparzeniem systemu całkowicie innego rodzaju, inwentarzowego, wskażemy jak takie operacje mogą być modelowane i zilustrujemy szerokość symulacji ogólnie i Areny w szczególności (nie jest to tylko do modeli kolejkowych). Użyjemy modułów tylko z paneli BLOCKS i ELEMENTS, głównie po to, by zademonstrować ich użycie i żebyś był świadomy, że one tam są jeśli ich potrzebujesz (więc, w efekcie, używamy języka symulacji SIMAN); w Ćwiczeniach 5-17 poprosimy Cię o ponowne stworzenie tego modelu przy użyciu wyżej poziomowych konstrukcji modelowania z paneli BASIC PROCESS i ADVANCE PROCESS. Ten model jest zasadniczo taki sam jak ten w Sekcji 1.5 Law i Kelton (2000).

5.7.1 Opis systemu

Widget by Bucky, międzynarodowe przedsiębiorstwo holdingowe, prowadzi inwentarz jednego rodzaju artykułów (oczywiście nazywają się one wigdets – elementy interfejsu graficznego). Widgety są niepodzielne, więc poziom inwentaryzacji musi być zawsze liczbą całkowitą, którą będziemy określać jako I(t) gdzie t jest czasem (w dniach) minionym od rozpoczęcia symulacji. Początkowo, 60 widgetów jest w zasięgu ręki: I(t) = 60.

Klienci przybywają w czasie interarrival rozdzielonym jako wykładniczy z wartością 0.1 dnia (jest to całodobowa operacja), z pierwszym pojawiającym się przybyciem nie w czasie 0 ale po tym jednym z czasów interarrival po czasie zero (past time zero). Klienci żądają 1,2,3 albo 4 widgety z prawdopodobieństwem kolejno 0.167, 0.333, 0.333 i 0.167. Jeśli żądanie klienta może być spełnione natychmiast w inwentarzu podręcznym, to klient dostaje pełne żądanie i szczęśliwy odchodzi. Ale jeśli inwentarz podręczny jest mniejszy niż wymaga klient, to klient dostaje cokolwiek jest pod ręką (co może się okazać niczym), a reszta żądań jest niezaspokojona (backlogged) i klient dostaje to później kiedy inwentarz będzie dostatecznie uzupełniony; to jest śledzenie/uaktualnianie przez pozwolenie poziomowi inwentarzowemu I(t) żeby był ujemny, co fizycznie nie ma sensu, ale jest wygodny sztuczka rachunkowa. Klienci z zaległymi artykułami są nieskończenie cierpliwi i nigdy nie anulują swoich zamówień. Jeśli poziom inwentarzowy jest już ujemny (np, już mamy zaległości) i więcej klientów przybywa z żądaniami, to poziom jest po prostu bardziej ujemny. Nie śledzimy/uaktualniamy (keep track), które widgety w szczególności przybywające w przyszłości zaspokoją, którego zaległego klienta (są też nieskończenie mili, więc to nie ma znaczenia).

Na początku każdego dnia (włączając czas zero, początek dnia 1), Bucky sprawdza inwentarz żeby zdecydować czy zrobić zamówienie od dostawcy widgetów w tym czasie. Jeśli poziom inwentarzowy (może być dodatni albo ujemny) jest (dokładnie/ściśle) mniejszy niż stała wielkość s (używamy s=20), Bucky zamawia inną stałą wielkość S (używamy S=40). str.252. To znaczy, że zamawia ilość widgetów, tak jakby przybywały natychmiast, poziom inwentarzowy pojawia się dokładnie S. Więc jeśli t jest liczbą całkowitą i zatem I(t) jest poziomem inwentarzowym na początku dnia (może być dodatni, ujemny albo zerowy) i I(t) < s, Bucky zamawia S – I(t) artykułów; jeśli I(t) ≥ s, Bucky nie ma nic, pozwoli żeby dzień upłynął, i sprawdza ponownie na początku następnego dnia, to jest, w czasie t + 1. Z powodu formy/kształtu tego przeglądu/polityki uzupełniania, systemy takie jak ten są często nazywane (s, S) modelami inwentarzowymi.

Jednak, zamówienie złożone na początku dnia nie przybywa natychmiast, ale raczej koło ostatniej połowy tego dnia, po opóźnieniu dostawy (również znane jako czas realizacji) rozdzielane jednakowo pomiędzy 0.5 i 1 dnia. Więc kiedy zamówienie przybywa, poziom inwentarzowy pojawi się z ilością/sumą równą początkowej ilości zamówienia, ale jeśli były jakieś żądania przed tym jak zamówienie było złożone, to pojawi się coś mniej niż S, kiedy zamówienie jest w końcu dostarczone. Zauważ, że względne taktowanie (relative timings) wartościowania inwentarzu i dostarczania opóźnień (lags) są takie, że nigdy nie mogą być większe niż jedno zamówienie, które jest w drodze, ponieważ zamówienie złożone na początku dnia przybędzie, najpóźniej, zaraz przed zakończeniem dnia, który jest początkiem następnego dnia, pierwsza możliwość żeby złożyć inne zamówienie; zobacz ćwiczenie 5-18 modelowania implikacji (wynikania) tej konkretnej sytuacji liczbowej.

Bucky jest zainteresowany średnią wartością wszystkich kosztów na dzień tego systemu przez 120 dni, co będzie sumą 3 komponentów:

  • Średni koszt zamówienia na dzień. Za każdym razem kiedy złożone jest zamówienie, to ponoszony koszt wynosi $32 bez względu na zamówioną ilość, plus $3 za zamówiony artykuł; jęsli nie ma złożonego zamówienia nie ma kosztów zamówienia, nawet kosztu stałego $32. $3 nie jest ceną (całkowitą) widgetu, raczej koszt administracyjny operacyjny dla Bucky za zmówienie widgetu (nie rozpatrujemy cen w tym modelu). Na końcu 120-dniowej symulacji całkowity koszt zamawiania narosły jest dzielony przez 120 żeby uzyskać średni koszt zamówienia na dzień.
  • Średni poziom utrzymania na dzień. Jeśli są fizycznie artykuły w inwentarzu to (np. I(t) >0) koszt utrzymania wynosi $1 za widget za dzień. Te (równanie – rys) (pomyśl o tym) i całkowity koszt utrzymania jest dzielony na długość symulacji, 120 dni.
  • Średni koszt niedoboru na dzień. Kiedykolwiek mamy zaległości (np. I(t)<0), średni koszt wynosi $5 za widget na dzień, surowa kara za utrzymania dodatniego inwentarzu. Całkowity koszt utrzymania jest (równanie – rys) (pomyśl o tym trochę mocniej), i średni koszt utrzymania na dzień jest dzielony na długość symulacji.

 

str.253. Zauważ, że okresy kiedy mamy ani opóźnienia ani żadnych artykułów fizycznie w inwentarzu (to jest, I(t) = 0) nie ma ani kosztów niedoboru ani utrzymania – kalkulacyjna nirwana. Również, możesz zauważyć, że nigdzie nie liczymy kosztów sprzedaży całkowitej ani ceny detalicznej widgetów; w tym modelu, zakładamy, że ceny są ustalone i indukowanie tego żądania, co się stanie bez względu na to, więc dochód pieniężny i zyski są ustalone i są tylko koszty manipulacyjne, na które będziemy próbowali wpływać.

Jedna subtelna uwaga zanim zbudujemy naszą (raczej prostą) symulację. Wartościowanie inwentarzowe pojawia się na początku każdego dnia – to jest, kiedy zegar jest liczbą całkowitą, i jakikolwiek koszt jest wtedy ponoszony. Wydarza się to, kiedy system wydaje się kończyć w czasie liczby całkowitej (120), więc prawidłowo powinno tam być wartościowanie inwentarzowe, i możliwe, że zamówienie złożone wtedy nie dotrze do końca świata, więc nigdy go nie dostaniemy, ale będziemy musieli zapłacić koszty zamówienia. Więc musimy uchronić wartościowanie inwentarzu od dziania się w czasie 120, co zrobimy przez zatrzymanie trwania symulacji w czasie 119.9999 9(leniwe fałszerstwo w naszej części, ale poprosimy cię o posprzątanie po nas w ćw. 5-19).

5.7.2. Model Symulacji

Jak już wspomnieliśmy wcześniej, zbudujemy ten model używając tylko modułów z paneli BLOCKS i ELEMENTS. Byłoby łatwiej budując go przy użyciu wyżej poziomowych (i mnie starożytnych) modułów z paneli BASIC PROCESS i ADVANCED PROCESS, ale pozostawimy Ci tę przyjemność w Ćw. 5-17.

Figure 5-19 pokazuje model ukończony, włączając animację w prawym górnym rogu. Moduły z BLOCKS i ELEMENTS PANELS na dole są podzielone na 3 sekcje, jak jest wskazane przez obrysowane ramki za modułami.

str. 254. Zacznijmy od struktury danych dla modelu. Moduły na dole sekcji Figure 5-19 są z ELEMENTS PANEL, więc są same w sobie nazywane elementami. Zauważ, że nie są one dołączone  do niczego, ponieważ definiują różne obiekty dla całego modelu. W miarę jak się im przyglądamy, już się zaznajomiłeś z niektórymi terminami/składnikami, ponieważ wiele podobnych konstrukcji i funkcji w wyższych poziomach Areny są dostępne również tutaj.

VERIABLE ELEMENT, pokazany w swojej ukończonej postaci z wpisem dla Inventory Level jest widoczny na Figure 5-20, definiuje opcjonalną inicjalizację zmiennych Areny (podobnie jak VARIABLE MODULE z panelu BASIC PROCESS). Jeśli nie ma inicjalizacji dla zmiennej, jej wartość domyślna wynosi 0. Pozwolimy Ci wybrać na wpisy w tym modelu samemu, które są zdefiniowane jak następuje:

Inventory Level: W jakimkolwiek czasie symulacji, jest to poziom inwentarzowy (dodatni, zerowy bądź ujemny) i jest zainicjalizowany tutaj na 60.Ta zmienna jest funkcją I(t).

Little s: Jest to s, zainicjalizowane na 20.

Big S: Jest to S, zainicjalizowane na 40.

Total Ordering Cost: Jest to statystyczny akumulator zmiennej, do której wszystkie koszty zamówienia są dodawane; nie jest zainicjalizowany, (więc jest bezwarunkowo zainicjalizowany na 0).

Setup cost: Stały koszt zamówienia, zainicjalizowany na 32.

Incremental Cost: Zmienna (na widget) kosztu zamówienia, zainicjalizowana na 3.

Unit Holding Cost: Koszt utrzymania jednego widgetu w inwentarzu dla jednego dnia, zainicjalizowany na 1.

str. 255.               Unit Storage Cost: Koszt posiadania jednego widgetu w zadłużeniu/zaległości dla jednego dnia, zainicjalizowany na 5.

Days to Run: Długość symulacji (w dniach), zainicjalizowana na 119.9999 na nasze przyznane lenistwo, jak opisane powyżej.

Zdefiniowaliśmy 4 Wyrażenia poprzez EXPRESSION ELEMENT, pokazane na Figure 5-21 z wpisem dla zmiennej Demand Size. Te Wyrażenia definiują prawdopodobieństwo dystrybucji dla ilości wskazanej przez swoje nazwy i powinny być jasne/nie powinny wymagać wyjaśniania. Zdecydowaliśmy zdefiniować Evaluation Interval raczej jako Wyrażenie a nie Zmienną, nawet jeśli jest ona wielkością stałą (1), powód, dla którego powinniśmy spróbować uogólnić model jest to, że chcemy jakiegoś rodzaju losowego wartościowania przedziału w przyszłości (ale, jak jest widoczne w Ćw. 6-12, jest również zaleta zdefiniowania go jako Zmiennej).

ATTRIBUTES ELEMENT ma tylko jeden wpis, użyty w celu opisania/zdeklarowania, że Order Quantity jest atrybutem dołączonym do jednostek. ENTITIES ELEMENT opisuje/deklaruje dwa typy jedostek, których użyjemy, Customer i Inventory Evaluator. PROJECT ELEMENT pozwala na określenie Title, Analyst Name i innej dokumentacji, tak samo jak kontrolowanie raportowania, podobnie do opcji Run>Setup>Project Parameters, której używaliśmy wcześniej. Nie ma zbyt wiele w tych modułach, więc je ominiemy i pozwolimy Ci je samemu zbadać/przejrzeć.

str. 256. REPLICATION ELEMENT, pokazany na Figure 5-22, zasadniczo powiela, co jest dostępne przez Run>Setup>Replication Parameters. Mamy tylko dwa niedomyślne wpisy. Najpierw, zmieniliśmy Base Time Units na Days, ponieważ wszystkie nasze wejściowe pomiary czasu są w dniach i bloki z BLOCKS PANEL nie mają warunku określającego wejściowe zespoły/jednostki czasu, zakładając, że są one wszystkie w Base Time Units. Po drugie, określiliśmy Replication Length aby było Days to Run, Zmienna była zainicjalizowana na 119.9999, nasze podłe fałszerstwo, aby uniknąć niepotrzebnego wartościowania inwentarzu w czasie 120.

DSTATS ELEMENT, Figure 5-23 wraz z widocznym wpisem Holding Cost, robi to, co STATISTIC MODULE wpisy typu Time-Persistent, w tym przypadku, mówimy, że chcemy zgromadzić wartości time-persistent i niedobór kosztów. Częściowo ukryte Wyrażenie SIMAN w Figure 5-23 jest Unit Holding Cost * MX (Inventory Level, 0 ) i jest chwilowym kosztem utrzymania, który musi być obciążony za każdym razem gdy Inventory level jest dodatni (przypomnij sobie, że MX jest wbudowaną funkcją Areny, która zwraca maximum swojego argumentu). Podobnie, inny wpis w DSTATS ELEMENT, o Nazwie Shortage Cost, gromadzi Wyrażenie SIMAN Unit Shortage Cost * MX (-Inventory Level, 0 ) dla kosztu niedoboru. To, co chcemy jest średnią czasu tych wartości, które dostaniemy następnie.

str. 257. OUTPUTS ELEMENTFigure 5-24 robi to co jednostki STATISTIC MODULE typów Output, i potrzebujemy zrobić tu dwie rzeczy. Po pierwsze, (i widoczne, na Figure 5-24), dostaniemy średnią kosztów zamówienia na dzień dzieląc Total Ordering Cost przez Days to Run, długość trwania programu, i zmagazynowanie ich w nazwie wyjściowej Avg Ordering Cost. Po drugie, zsumujemy wszystkie 3 komponenty w  średniej wartości osiągnięć wyjściowych w to, co nazwaliśmy Avg Total Cost przez wyrażenie OVALUE (Avg Ordering Cost) + DAVG (Holding Cost) + DAVG (Shortage Cost). Funkcja Areny OVALUE zwraca ostatnią (najnowszą) wartość swojego argumentu, który w tym przypadku jest tym, co zdefiniowaliśmy w poprzednim wierszu tego modułu (mogliśmy tego uniknąć przez wpisanie Total Ordering Cost/Days to Run tutaj w zamian, ale robiąc to tak jak my to zrobiliśmy, wykonując osobny wynik wyjściowy dla komponentu średniego kosztu zamówienia ze średniego kosztu całkowitego, co może się samo w sobie spotkać z dużym zainteresowaniem). Funkcja Areny DAVG zwraca średnią stałą czasu swojego argumentu, więc jest użyta tutaj dwa razy, aby uzyskać średnią dzienną utrzymania i kosztów niedoboru (także wytworzone osobno w raportach).

Wróćmy teraz do modułów logicznych z BLOCKS PANEL, które są nazywane blokami. Najwyższa grupa (top group) bloków w Figure 5-19 reprezentuje przybywanie klientów, tworzenie żądań od inwentarza i odchodzenie.

str. 258. CREATE BLOCK, pokazany na Figure 5-25, wymaga trzech niedomyślnych wpisów. Dla obu First Creation i Interval, wpisaliśmy Interdemand Time, zdefiniowany w EXPRESSION ELEMENTS jako EXPO (0.1). Entity Type zdefiniowaliśmy jako Customer.

str. 259. Następny/następnie ASSIGN BLOCK, na Figure5-26, dekrementuje żądanie klienta z Inventory Level. Wyrażenie Demand Size było zdefiniowane w EXPRESSION MODULE jako nieciągła zmienna losowa żeby zwracała żądania 1,2,3 i 4 z odpowiednimi prawdopodobieństwami.

Jednostka Customer potem odchodzi przez DISPOSE BLOCK, gdzie jedyna rzecz, jaką zrobiliśmy było wyczyszczenie kratki Record Entity Statistics (nie dbamy o nie w tym modelu).

Środkowa grupa bloków na Figure 5-19 reprezentuje okresowe wartościowanie inwentarzu i decyzje dotyczące zamówień. Jeśli zostało złożone zamówienie, czekamy aż przybędzie i wtedy inkrementujemy poziom inwentarzowy; jeśli nie ma złożonych zamówień to nie ma nic do zrobienia.

Ta logika zaczyna się z CREATE BLOCK, na Figure 5-27, żeby wstawić w model to, co możesz myśleć, że jest licznikiem widgetu (nie promienia), który policzy widgety, zdecyduje czy złożyć zamówienie, a potem, jeśli zamówienie jest złożone, będzie czekał na jego dostarczenie, a potem położy widget na półce. Chcemy, aby First Creation była o czasie 0 ponieważ nasz system wymaga wartościowania inwentarzu na początku działania. Entity Type jest Inventory Evaluator, a Interval czasu pomiędzy kolejnym tworzeniem jest Wyrażeniem Evaluation Interval, które było określone jako stała 1 w EXPRESSIONS ELEMENT.

Raz stworzona, jednostka Inventory Evaluator przechodzi do BRANCH BLOCK, na Figure 5-28, która robi niektóre takie same rzeczy jak DECIDE MODULE z BSIC PROCESS PANEL, z którym się już zapoznałeś. W tym przypadku, chcemy zdecydować czy złożyć zamówienie w tym czasie.

Najpierw Add (dodamy) gałąź typu IF z warunkiem Inventory Level < Littles, który jeśli jest prawdą, wskazuje, że chcemy teraz złożyć zamówienie (kratka okna dialogowego dla tej gałęzi jest widoczna na Figure 5-28). str. 260. Inną gałęzią jest typ Else i jest jedyną inną możliwością, wskazującą, że nie składamy teraz żadnego zamówienia. Punkty wyjściowe z BRANCH BLOCK odpowiadają prawdzie odpowiadających sobie gałęzi; w tym przypadku pierwszy punkt wyjściowy jest prowadzony, jeśli złożymy zamówienie ( i prowadzi do ASSIGN BLOCK po prawej stronie i powyżej BRANCH BLOCK), a drugi punkt wyjściowy odpowiada gałęzi Else i znaczy, że nie ma nic do zrobienia (więc jednostka natychmiast idzie do DISPOSE BLOCK po prawej i pod BRANCH BLOCK). str. 261. Ważną częścią BRANCH BLOCK jest Max Number of Branches field (max liczba pola gałęzi), która jest domyślnie ustawiona na nieskończoność (i gdzie zamiast tego wpisaliśmy 1); ogólnie BRANCH BLOCK wyznacza wartość każdej gałęzi w liście w kolejności i wysyła przychodzącą jednostkę (albo jej duplikat) do każdej gałęzi, która oznacza wartość True, dopóki Max Number of Branches jest zużyta. Jest to potężna możliwość, ale może prowadzić do błędów, jeśli wpisy w blokach nie są uważnie dobrane.

Jeśli potrzebujemy złożyć zamówienie jednostka Inventory Evaluator nastepnie pójdzie do kolejnego ASSIGN BLOCK, na Figure 5-29, który najpierw oblicza Order Quantity (atrybut włączony do jednostki)  jako Big S – Inventory Level. Następne przyporządkowanie w tym bloku pociąga za sobą koszt zamówienia za to zamówienie przez zastąpienie Zmiennej Total Ordering Cost przez wyrażenie Total Ordering Cost + Setup Cost + Increment Cost + Order Quantity. Zauważ, że ważne było, aby zrobić to przyporządkowanie w tej kolejności, ponieważ wynik pierwszego jest użyty w drugim.

Teraz jest czas, aby zaczekać na przybycie zamówienia, które jest osiągnięte przez wysłanie jednostki Inventory Evaluator do DELAY BLOCK, Figure 5-30, gdzie po prostu siedzi i czeka na jednostki czasu Delivery Lag (pamiętaj, że tylko Base Time Units s dostepne w blokach). Przypomnij sobie, że Deliver Lag było zdefiniowane w EXPRESSIONS ELEMENT że będzie UNIF (0.5, 1.0).

str. 262. Po opóźnieniu dostawy, Inventory Evaluator idzie do następnego ASSIGN BLOCK, Figure 5-31, gdzie inkrementuje Inventory Level przez swój atrybut Order Quantity.

str. 263.               Po dostarczeniu zamówienia, praca Inventory Evaluator jest zakończona, więc idzie do ostatniego DISPOSE BLOCK (ale nie smuć się, ponieważ niedługo stworzymy kolejną z tych jednostek).

Dodajmy (tylko) trochę animacji. Okno dialogowe wykresu ramki jest pokazane na Figure 5-32 (z zakładką DATA SERIES pokazującą Ujemną Krzywą Inwentarza – Non-positive Inventory curve), która pokazuje Inventory Level w czasie. Chcemy mieć różne kolory w zależności od tego czy Inventory Level jest dodatni (na czarno), czy ujemny (na czerwono), czego dokonamy sporządzając wykres dwóch oddzielnych krzywych (Data Series). Żeby pokazać dodatni poziom inwentarza, sporządzimy wykres wyrażenia MX (Inventory Level, 0) na czarno, a dla negatywnego sporządzimy wykres MN (Inventory Level, 0), który będzie ujemną wartością, na czerwono (MN jest wbudowaną funkcją Areny, która zwraca minimum swoich argumentów). Zauważ, że kiedy 0 „wygrywa” w którymś z tych wykresów, to otrzymujemy płaską linię 0 (flat line at zero), co może nie jest takie najgorsze, ponieważ wizualnie będzie przedstawiać wykreślenie gdzie zero się znajduje (w wesoły, kolorowy sposób).

str. 264. Może być zabawne zobaczyć też inwentarz w jakiś sposób (nie, nie zamierzamy animować pojemników z małymi widgetami albo ich zjaw). Dlatego, zainstalowaliśmy pary Level animations (czasami zwane animacjami termometru), zaraz po lewo od wykresu. Główna animacja [czarna, na Figure 5-33] sporządza wykres liczbę widgetów fizycznie znajdujących się w inwentarzu, co jest wyrażone przez MX (Inventory Level, 0), i sporządzimy wykres w taki sposób, że będzie szło w górę jak inwentarz będzie się stawał bardziej dodatni. Ostatnia animacja (czerwona, dla której nie chciało się nam robić ilustracji tutaj) sporządza wykres liczby widgetów w zadłużeniu (backlog), co jest MX (-Inventory Level, 0); kiedy jesteśmy w zadłużeniu, jest to liczba dodatnia, ale chcemy sporządzić dla niej wykres nurkujący poniżej poziomu zerowego jak będziemy szli głębiej w zadłużenie, więc wybraliśmy Fill Direction aby było Down.

Po dodaniu kilku etykiet i takich tam innych, jesteśmy wreszcie gotowi. Obserwuj wykres i termometr, żeby zobaczyć spadek poziomu inwentarzu jak żądanie się pojawia, potem wpadają znowu w góre, kiedy zamówienie przybywa. Średni koszt dzienny (zaokrąglony do najmniejszego pensa) gdzie 9.37 za utrzymanie, 17.03 za niedobór, i 100.39 za zamówienie, całkowita liczba 126.79. Czy (s, S) = (20,40) jest najlepszą taktyką to dobre pytanie i zadamy Ci je (w statystycznie dobry sposób) w ćw. 6-10 i 6-11 na końcu Rozdziału 6.

5.8 Podsumowanie i prognozowanie

Ten rozdział zajmował się głębią szczegółowych niżej poziomowych możliwości modelowania, tak samo jak szczegółowymi zagadnieniami takimi jak precyzyjnie dostrojone animacje. Wspominaliśmy jak możesz wejść i mieszać w języku symulacji SIMAN, na pewno to zrobiliśmy; zobacz Pedgeb, Shannon i Sadowski (1955) aby uzupełnić wiedzę o tym jak obchodzić się z SIMAN. W tym momencie, powinieneś być wyposażony w ogromny arsenał narzędzi modelowania, aby móc zabrać się za różne systemy, wybierając konstrukcje z różnorodnych poziomów wedle potrzeby. W kilku następnych rozdziałach będziemy kontynuowali rozwijanie możliwości modelowania Areny.

5.9. Exercises – ćwiczenia

5-2         Elementy przybywają do dwu-maszynowego/komputerowego systemu zgodnie z wykładniczym rozkładem interarrival ze średnią 20 minut. Po przybyciu, części są wysyłane do Machine 1 i przetwarzane. Czas przetwarzania rozkładu jest TRIA (4.5, 9.3, 11) minut. Potem części są przetwarzane w Machine 2 z czasem przetwarzania rozkładu TRIA (16.4, 19.1, 20.8) minut. Części z Machine 2 są kierowane z powrotem do Machine 1, aby je przetworzyć drugi raz (ten sam czas przetwarzania rozkładu ale niezależny rysunek z niego). Potem ukończone części wychodzą z systemu. Uruchom symulację na pojedynczą replikację 20,000 minut, aby zaobserwować średnią liczbę w kolejkach maszyny/komputera i średni czas cyklu/okresu części.

5-13       Urząd wydawania prawa jazdy ma dwa typy przybyć. Osoby indywidualne zainteresowane kupnem nowych tablic rejestracyjnych charakteryzują się rozkładem czasów interarrival jako EXPO (6.8) i czasem serwisu TRIA (8.8, 13.7, 15.2); wszystkie czasy są w minutach. Osoby indywidualne, które chcą odnowić albo złożyć wniosek o nowe prawo jazdy mają rozkład czasu interarrival jako EXPO (8.7) i czas serwisu TRIA (16.7, 20.5, 29.2). Biuro ma dwie linie, po jednej dla obu typów klientów. Urząd ma 5 urzędników biurowych: dwóch przypisanych do tablic rejestracyjnych (Mary i Kathy), dwóch przypisanych do licencji/praw jazdy (Sue i Jean), i lidera zespołu (Neil), który może obsługiwać oba typy klientów. Neil będzie obsługiwał klientów, którzy czekają najdłużej. Zakładamy, że wszyscy urzędnicy będą dostępni przez cały czas 8 godzin pracy. Zauważ, że jeśli jednostki z początku wielokrotnych kolejek FIFO (odpowiadające wielokrotnym PROCESS MODULES) próbują schwycić ten sam Zasób, logika wybrania, tego, która jednostka „wygra” jest taka, że wszystkie kolejki były scalone razem w jedną kolejkę FIFO. Zaobserwuj system i czas cyklu dla obu typów klientów.

5-14       Biuro opisane w ćw. 5-13 rozpatruje sprawę douczenia Kathy, aby mogła obsłużyć oba typy klientów. Zmodyfikuj model, aby to zaprezentować i zobacz, jaki ma to efekt na czas systemu przez klienta.

5-26       Zmodyfikuj Model 5-1 , aby używał niestacjonarnego procesu Poisson’a (jak użyto w Modelu 5-2 i 5-3), aby odmiennie wdrożyć regułę zatrzymania dla tego modelu. Pozbądź się drugich dwóch Zmiennych i niedomyślnych wpisów w polu ENTITIES PER ARRIVAL i polu MAX ARRIVALS w module tworzenia „Create Call Arrivals”. Także pozbądź się trzech modułów z obszaru „Arrival Cutoff Logical Entity”. Umieść Text Box w swoim modelu, aby krótko wyjaśnić co zrobiłeś, aby to wdrożyć. Wyjaśnij, w drugim Text Box, w swoim modelu, dlaczego wyniki są trochę inne od tych z Model 5-1, i wyjaśnij, dlaczego są dobre.

 

Tłumazcenie i korekta: Monika Wosztyl

One response to “Simulation with Arena part.2

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s