Required Programs:

GPSS World student version to run the .gps model and the .gpr OptimalReport.

AToM3 with GPSS formalism loaded to load the graphs.

Problem Description:

This project simulates the Point Zero clothing warehouse during a busy season for approximately 2000 orders. Most of the datas were provided by a supervisor of that warehouse and from personal work experience there. The work time is more or less 50 hours per week and in our simulation, a time unit will be looked as one minute. My goal is to decide how many workers to hire for picking, checking and packing to such that the average delay(including 0) is < 15 minutes and the utilization of all the workers is > 75%. Following is a description of the routines involved in our modelling of an order:

When an order is received, it goes through the picking department which simply goes through the warehouse's stocks and picks what the client orders.

Once the picking is done, the order goes to the checking department which checks every pieces picked for any defects in the clothes or any mistakes the picker may have made.

If a mistake is found, the order is returned to the picker for him to start over. Otherwise, it goes to the packing department which packs all the pieces inside boxes with proper weights.

Modelling Description:

Now, I will explain some of the choices I made during the modelling of this warehouse.

The Functions:

The GenFun function is the function that provides the modifier for the time it takes to generate an order. Basically it is every 1 to 5 minutes, with more emphasis put on 1 minute to 2 minutes.

SIZEF is a function that lets us determine the size of an order. From this, we can see that 20% of the time, the order will consists of 6 pieces, 20% 12 pieces, 10% 24 pieces, 10% 30 pieces, 10% 36 pieces, 10% 42 pieces. Finally there will be 5% chance to receive a very small order of only 1 piece or a very big order of about 300 pieces. Note that the sizes is mostly a multiple of 6, because every pack of clothes consists of 6 pieces (1S, 2M, 2L, 2XL) and clients generally orders packs of clothes instead of pieces.

StockType function tells us which type of stock the order wants. It can be either pants, shirts or other types of stocks. Note that one might think that a client might order different types of stock inside one order. This is possible, however, the order delivered to the warehouse will consist only of 1 type of stock per order. For example, an order for both shirts and pants will be separated in 2 where one will be for shirts and another one for pants. This is to simplify the work done at the warehouse. Then, in the shipping area , they reassemble orders together and ships it to the client. I did not include the shipping procedures in the simulation, because I did not have enough data or information on them. To return to our function, StockType simply has 50% chance to return 2 which means shirts, 30% chance to return 1 which stands for pants and 20% chance to return 3 which is other stocks.

The last function Worker is a function that simulates a worker's behaviour. As we all know some workers are better at their tasks than others. For simplicity, I only have 3 values for the worker efficiency. 0.5 stands for a lazy worker and has 30% chance, 1.0 is for normal average workers and has 40% chance and finally, 1.5 is for fast, efficient workers which has 30% chance.

Tables:

There are 5 tables available: PickTime, CheckTime, PackTime, STtable and Size. The first three gives us an idea of approximately how long it takes to pick, check or pack an order. STtable is a table that draw the function StockType, we basically verify that this function does do what we expect. Size is a table which draws the function SIZEF, again, it is to verify that SIZEF is working properly. The following pictures of the tables were generated using our optimal result data.

As we can see from the following 3 tables, the pick time, check time and pack time mostly lies within an hour. However, there are some rare occurences of orders which took a very long time to pick, check and pack. These orders are the rare, but huge 300 orders.

The following picture shows that the stock type of orders is mostly ~50% for 2 which is shirts, ~30% for 1 which is pants and ~20% for 3 which is other stocks.

The following table shows that the size of our orders does mostly lie within 6-42 pieces and that we do have rare orders of 1 or 300 pieces.

Storages:

Picker: This storage indicates the amount of workers that pick orders

Checker: Amount of worker that check orders

Packer: Amount of worker that pack orders

Pants: The maximum amount of pants the warehouse can hold ~6000 (supervisor's data)

Shirts: The maximum amount of shirts the warehouse can hold ~10000 (supervisor's data)

Others: The maximum amount of other stocks the warehouse can hold, ~4000 (supervisor's data)

Variables:

Ptime: This is approximately the time required to pick an order, it depends on the size of the order and the worker's efficiency.

Ctime: This is approximately the time required to check an order, it is generally longer to check an order than to pick it. It also depends on the size of the order and the worker's efficiency

Patime: This is approximately the time required to pack an order, generally shorter than check time, but longer than pick itme. Again, it depends on the size of the order and the worker's efficiency.

errorfac: This is the error factor, it is the percent chance that a picker makes a mistake when picking an order. This mainly depends on the size of order, but also depends a little bit on the worker's efficiency.

Simulation Description:

Stock Initialization:

Our first GENERATE-TERMINATE blocks is used to initialize the amount of stock in our inventory. That is why we run it at time 0 and only once. In this initialization, we use ENTER blocks to reserve a certain amount of pants, shirts and other stocks. This makes our starting inventory to be 600 for pants, 1000 for shirts and 400 for other stocks. These data were provided by the supervisor.

Restocking:

The last GENERATE-TERMINATE blocks is used to restock our inventory. This occurs every 60 minutes +- 5 minutes. The amount restocked is 360 for pants, 600 for shirts and 300 for others. Again, these data were provided from the supervisor and before we add to the stock, we test if we will not go beyond our limit after the restocking, if we do, then we simply do not add this particular stock and go to the next one. LEAVE blocks are used to simulate the restocking.

Order Simulation:

This is the main part of our simulation. First, we create an order every 1-5 minutes with more emphasis given on 1 minute. This was not provided by the supervisor, but since we are simulating for approximately 50 hours = 3000 minutes and we are told that we have approximately 2000 orders during that period of time, I decided to use this approach.

Then, we assign a size parameter and a stock type parameter to our order. This is done using the SIZEF and the StockType functions explained above. Next, we test which type of stock the client is asking for, in other words, what did StockType function return and depending on the type required, we will check whether we have enough pants, shirts or other stocks available in our inventory. If there is not enough stock available, the order is queued and the next order will be processed. Finally, if we do have enough stock, we subtract this amount from our storage using the ENTER block and use an unconditional TRANSFER block to send it to order processing denoted by the label PROC

Now that we know we have enough order available, we simply pick the order, checks it and packs it. These are done using the ADVANCE blocks which also refers to the variables PickTime, CheckTime and PackTime described above. If an error is detected during checking, the order size is added back to the corresponding storage and the order is returned to the beginning of PROC and started over. The error detection is modelled using a TRANSFER block which goes to Error_DET(Error Detected) with a probability of errorfac which is described in the VARIABLE section.

Test run results:

Using the test runs in this file, we can see that the optimal case is 11 pickers, 21 checkers and 13 packers. We can also notice that the average waiting time for pants, shirts and stock are all less than 20 minutes which is reasonable. You can also find a complete .gpr Report of the optimal case. In the test runs, I only showed the relevant data, because otherwise, the formating will not be nice and we don't really care about other datas. I also added remarks after each test run to show the steps I took to reach my optimal solution. Note that this is not the only optimal solution.

Problems and Possible Improvements:

Several facts makes our system not 100% adequate for the Point Zero warehouse. First of all, our picking time, checking time and packing time is not exactly the same than the real amount of time required to pick, check and pack. As an example, a client who order 6 pieces will have a small pick time in both our system and the real environment. However, a client who orders 36 pieces will possibly have a longer pick time in our system than in the real work place. This is because sometimes, all the 36 pieces are of one style and the picker can simply pick up a box and bring the box to the checker. This takes about the same amount of time as with the order of 6 pieces. Also, in the real environment, there are style numbers and colors and sizes which we did not really implement. As an example, an order who asks for dark blue and blue can confuse the picker and can result in a higher error risk. Also, the utilization of pants, shirts and other stocks is faulty, because of the initialization process. I could not find any other ways to implement a maximum limit of these storages and at the same time an initial availability quantity.

Conclusion:

I would like to say that this project has been very educational. We learned and practiced several aspects of modelling and simulation to model a somewhat simple environment which showed us the strengths and weaknesses of GPSS