This study has been carried out in a company which produces paper and board packages. The study focuses on scheduling in the shop-floor. In this study, the current performance of a package manufacturing plant on predicting future completion dates of the orders was evaluated. At first, some observations were made for the input data. Then some assumptions were made to establish a model. Then a software which represents for the model is developed by using Visual Basic 5.0. At last some certain number of scenarios were generated to have better predicts on the completion dates of the ordersÖNSÖZ
Bu çalışma kağıt ve karton ambalaj üretimi yapan bir işletmede gerçekleştirilmiştir. Bu çalışma atelyedeki iş çizelgelemesi üzerinde durmaktadır. Bu çalışmada, işletmenin siparişlerin tamamlanma günlerini tahmin etmedeki performansı değerlendirilmiştir. Bunun için öncelikle modelde kullanılacak değişkenlerin tipini belirlemek için bazı gözlemler yapılmıştır. Daha sonra model için bazı varsayımlar yapılmıştır. Daha sonra modeli sanal ortamda temsil edecek simülasyon yazılımı Visual Basic prodramlama dili kullanılarak geliştirilmiştir. Son olarak siparişlerin tamamlanma günlerini daha iyi tespit edebilecek bir kaç senaryo üzerinde çalışılmıştır.
This study has been carried out in a company which produces paper and board packages. The study focuses on scheduling in the shop-floor. The study includes observations on the system and a software developed in Visual Basic 5.0 to simulate the current system and some certain alternatives to the system to get answers to what-if questions.
2. PROBLEM DEFINITION AND OBJECTIVES
The problem that takes place in this plant is that engineers have some difficulties to predict the due dates of orders with a high accuracy. So sometimes the due dates of orders are delayed, and the customers are informed about this situation. But this happens before a couple of weeks that the customers expects to get what he has ordered. Of course this is an unwilling situation for both the customer and the producer.
The target that was aimed in this study is to predict the due dates of the orders with more reliable methods. And perform some certain preventive actions, if any delays seems to takes place. In order to do that, some certain performance criteria must be determined.
The delay for each order,
The total delays that take place in a period of time.
3. SYSTEM DEFINITION
The system is a non-terminating system.
Jobs are processed on first come first go basis.
The machines used are not identical.
The orders cannot be divided into parts to be processed in two of the machines.
The orders cannot be divided into parts to be processed at different times.
3.2. Definition of the System
In the system there are two non-identical machines called Lemanic and ATN. The number of products of this firm is twenty. And these products can be grouped into two categories. Any of these products can be processed in any of the machines in different standard times. It is enough for a product to be processed in a machine to be ready to be delivered to the customer.
In the manufacturing department, it accepted that 1 unit of DC is equal to 5 units of HLB. Because the standard time to process one unit of DC is six times greater than the standard time to process one unit of HLB. After this part of the study, one unit of HLB will be called a piece.
3.3. Working Principles of The System
Customers inform the plant about their orders via phone or fax. And these orders are arranged in an order usually in FİFO basis. And when one of the two machines becomes available, the first order is loaded to this machine. After being processed in a machine, the orders becomes ready to be delivered to the customer.
The machine ATN runs 24 hours a day, 7 days in a week. The processing capacity of the machine ATN is 100.000 pieces per hour.
Also the machine Lemanic runs 12 hours a day, 5 days a week. The processing capacity of the machine Lemanic is 62.500 pieces per hour.
3.4. The Software Developed in This Study.
As it was said before, the aim of this study is to make more reliable predicts for the due dates of the orders. To achieve this, a new approach to this system is designed and this approach is transferred to codes in Visual Basic 5.0 to build up a software.
In this approach, the actual production flow is simulated. If we start from the arriving of an order to the plant, the on-going events are as follows.
The plant has a different type of ordering system. In this system customers inform the plant about their actual orders. The actual orders are the orders that the customer want to be completed in one or one and a half month. Also the customers inform the plant about prospective orders for the following five or six months. Of course these orders loose their accuracy, if the completion date gets far from now. (Figure 3.1.)
The arriving order joins a virtual FIFO queue to be processed in any of the machines. When it is time for an order to be processed in a machine, the staff working in the shop-floor is informed about this event. Every order needs a setup time for the machine that it will be processed. The setup time for an order depends on the category of the order which was processed before it on the same machine. For example if the next order that will be processed is in Category I (HLB) and the previous order that was processed is in Category II (DC), then this situation may be called changing from HLB to DC. There are two categories that means four different setup times for a machine. All these are also the same for the second machine. So there are eight different setup type. While processing these orders, some downtimes occurs. These downtimes are caused by the machine or by the nature of the order. Also these two downtimes have different values for two machines.
According to these data it is obvious that, the production time of a certain order depends on these factors:
The type of the machine in which the order will be processed.
The setup time of the order in the machine.
The production capacity of the machine.
The downtimes that will occur during the processing.
And also the time that an order arrives to shop-floor depends the production time of the orders that have been processed before it.
The logic of the software developed in this study is to simulate this production activities in a virtual environment and to see what can happen in the future.
The first module of the software is about the orders. In this module, there are three processes for the orders:
Entering an order
Deleting an order
Updating an order
All orders have seven attributes:
The second module of the software is about the parameters of the system. In this module, it is possible to see and update the setup times, down times and working days for each machine. (As we said the machine Lemanic runs 5 days a week. But if we want to make overtime in this machine on some certain days, it is possible to reflect this situation to the model in this module)
The most important module of the software is the simulation module. This module simulates the production process and computes the values related to the production. At the end of a replication we get these data related to the system.
This simulation is run more than one times. By this way it possible to get different scenarios of the production process. For example we can see if there are any delays for the due dates in the system or not. Also it is possible to see the when the plant has idle time to accept new orders in certain period of time.
If there are any delays for any of the orders there are two ways for the plant. To inform the customer abut this situation, or try to make some changes in the production process and try to predict what can happen. This means to search answers to the what-if questions. The software lets the user to make some changes on the conditions and helps the user to find answers to this type of questions. For example the user can modify the workdays for machine. As we said the machine Lemanic works 5 days a week. The user can make the machine work on the days that he chooses. By this way some delays can be reduced by overtime.
Also some general and fundamental changes may be made on the parameters of the model. Setup times may be reduced by using cross-training stuff in the plant or by using extra staff responsible for setup. Also some improvements may be achieved on downtimes. The downtimes related to machine may be reduced by preventive maintenance, and the downtimes related to the nature of the job may be reduced by using more qualified and experienced stuff. Or the things go bad and the setup times and the downtimes may increase. No matter what happens to these parameters, the changes can be reflected to model by the updating module of the software. By this way the user can find answers to his problems about what happens if these parameters change.
Also it is possible schedule the days-off for the staff using the software. When the orders are less then the capacity for a period of time, some consecutive days can be made off-days. The software is run and the outputs are get under these conditions.
Another useful part of the software can be explained as follows. When we run the software we have the chance to see the future for five or six months. We can try to schedule the orders in different types and by this way we can find an optimum strategy to complete the orders in minimum period of time. And we can suggest this strategy to the customer. For example we can say "if you accept to get your orders in this sequence, there will be no delay or at least minimum delay".
4. INPUT DATA
The tables below gives the whole information about the input data that are used in the model.
The input data about the setup times are experimental. Because the plant has not enough data to analyze. There are eight different type of setups. If we accept that a setup occurs one times in four days, and also if we accept to make analyzes minimum with thirty data, then the number of the days we need to inspect become 8 x 4 x 30 = 960. And the plant has not records related to three years ago. The triangular distribution is used to represents the distributions. By this way the random setup times stays in the limits defined by the engineers. And the probability of having meaningless setup times is reduced.
The input data for the downtimes are observational. In this data ARENA input data analyzer is used to analyze the data. Also the downtimes are represented by the triangular distribution to prevent the meaningless downtimes. The downtimes for each downtime type have accepted to be the same. The details of these data are in Table 4.6 and Table 4.7.
The capacity of the machines are theoretical values.
5. DEVELOPMENT OF THE MODEL AND THE SOFTWARE
The model is developed according to definitions given for the system. And the software is developed based on this model.
6. VERIFICATION AND THE VALIDATION
6.1. Verification of the Model
In order to verify the model, some techniques were used. These are;
As a result, there is not any interruption or unknown situation which prevents us from running the model.
6.2. Validation of the Model
An idealistic goal in validation is to ensure that the simulation model is good enough so that it can be used to make decisions about the system. This can be done comparing the real system and the output data. In this I had no chance to compare the outputs with the real system. The model represent for approximately six months. And also completion of an order changes from one day to ten days. And if we want to have an idea about an order, we must observe a certain times. In such a dynamic system it is hard to this at least takes a lot of time. So we can only compare the outputs with the experiences of the people familiar with the system. And this process shows us that the simulation model is good enough to represent the system.
7. EXPERIMENTAL DESIGN
The simulation is run after verifying and validating the model. As indicated before the system is a non-terminating one. And the simulation stops after all the orders are completed.
The simulation is run for eleven times. The delays for each order is calculated and the expected delay time for an order is the average of these eleven delays.
If we run the software in these conditions, we get the following results.
In the output, OrderID represents for the order number of the order, Material represents for the name of the product, Order Type represents for the type of the order, InDate represents for the arriving date of an order to the plant, ProDueDate represents for the proposed due date, Lateness represents for the excepted delay for an order, Machine represents for the machine that the order has the biggest probability to be processed in, No. Delays represents for the number of delays for an order in 11 replications.
We see that there are 15 delays in 85 orders. The total of these delays is 127 days. The total delays for the months.
In current strategy the first delay in the machine Lemanic is in the order with the OrderID 6. The due date for this order is 25.06.2000 and it has approximately two days delay. Now let's see what happens if we make overtime in two Saturdays before 25.06.2000.
We see that with two days of overtime in the machine Lemanic, we eliminate the delay in the order with the OrderID 6. By this way we have 14 delays in 85 orders. And the total delays degreases from 127 days to 116 days.
Let's think that the engineers of the plant wants to change the working policy of the machine Lemanic. They want the machine to work 6 days a week. Before implying this let's try to see what happens to the delays.
In the second strategy we degreased total delays from 14 orders to 10 orders by taking the first strategy as the reference point. And the total delays degrease from 116 days to 104.09 days
In this strategy, it is assumed that some improvements have been developed and the downtimes are degreased by one minute. So there must be some changes in the system.
We see that the number of the delayed orders is only 5. And the total delays degreases from 104.9 days to 67.72 days. and there is no delay in December.
In the previous situation we saw that there is no delay in December. As the last strategy let's make two days-off on the New Year Event, 31.12.2000 and 01.01.2001.
In this strategy having two days-off at the end of the December made the order with the OrderID 87 delay for 1.36 days. also total delays increased from 67.72 days to 69.08 days.
8. ANALYSIS OF THE RESULTS
As a result of the experimental design, we have seen that
In this study, the current performance of a package manufacturing plant on predicting future completion dates of the orders was evaluated. At first, some observations were made for the input data. Then some assumptions were made to establish a model. Then a software which represents for the model is developed by using Visual Basic 5.0. At last some certain number of scenarios were generated to have better predicts on the completion dates of the orders.