Documente Academic
Documente Profesional
Documente Cultură
This is the second of a two-part set of tutorials where we apply our ever-growing knowledge and experience with Arena to modeling lean techniques. Please recall that the primary goal of these tutorials is not to compare the performance of different process configurations. Rather, the tutorials simply show some ways to model different common lean techniques. Note also that the models provided in these lectures are not necessarily the only or even best ways to model lean systems, the intent is merely to provide some examples that students can use to develop their own lean system simulations.
Here are the six models that we are building in this pair of tutorials. The previous tutorial concluded with a model in which one operation supplied parts to two downstream operations via FIFO lanes. That was super-fun, so lets move right on to modeling a very common lean technique called a supermarket pull system.
Conditions where supermarket pull systems can be beneficial to maintaining flow include: A large imbalance in cycle times of the steps in the process, or Some steps in the process serve many other steps or customers, or Some steps are physically far apart, or Some steps are unreliable, making it impractical to directly link steps with a continuous flow system. As we go through the following supermarket pull example, well see that this approach is in some ways analogous to a FIFO lane, except that you really wouldnt want to have mile-long FIFO lanes connecting to each of your customers.
The supermarket pull system mimics the way supermarkets re-stock shelves with goods. Once a shelf is filled with an item, no more items are brought to the shelf until a customer pulls an item off the shelf, thereby making room for another item on the shelf. In some implementations, the shelf is not replenished every single time an item is removed, but only at set times, like at night when the supermarket is closed. Another way to do this is to replenish the shelf only when the number of items on the shelf has fallen below the re-order level. Supposedly, the application of supermarket pull to manufacturing occurred on the 1950s when some folks from Toyota happened to stop in at a Piggly Wiggly store. The rest is history.
Let walk through a detailed example of one way that a supermarket pull system could work. When you go in to Office Depot to buy an electronic gizmo, you dont actually go up to a shelf and grab the gizmo that you want. Rather, you pull a card off of a shelf where the gizmos are displayed. This card is, in essence, a special-purpose kanban card which is called a withdrawal kanban card. You give the card to an Office Depot associate, who then goes to the stock room, grabs the gizmo that you want, and then brings it to you up at the check-out counter. In lean-speak, the withdrawal kanban card causes an item to be removed from a supermarket shelf.
Now, back in the Office Depot stock room, another associate sees that the shelf has one less gizmo. The associate then sends a so-called production kanban card to the gizmo supplier, which sends over a gizmo to replace the one that was just sold. As we mentioned, sometimes the stock room is checked only at certain times, and sometimes the production kanban cards are only sent when the number of parts on a shelf falls below a certain level.
Heres how we diagram this supermarket pull system on a value stream map. A customers request for an item causes a withdrawal kanban card to flow back to the supermarket shelf where items are kept. An item is then pulled from the shelf and delivered to the customer. Then
Removing an item from a shelf causes a production kanban to be sent to the supplier, which then causes the supplier to send an item to the shelf.
In summary, a withdrawal kanban triggers the movement of items, while the production kanban triggers the production of items. So, like the FIFO lane, the supplier does not produce any parts until notified to do so. Also, a supermarket shelf is similar to a FIFO lane in that both provide temporary storage of items waiting to be picked up at some time in the future. The difference is that for a FIFO lane, production is triggered by an empty slot at the end of the FIFO lane. For a supermarket system, it is the production kanban card that triggers this action.
Heres an Arena model that simulates a supermarket pull system. We have four major sections to this model: Production Control, Operation 1, the Supermarket, and a Customer. Production Control issues a production kanban card that alerts Operation 1 to fill up a supermarket shelf with parts before customers start arriving. Operation 1 fills the shelf, and then keeps it full as customers remove parts. The Supermarket receives parts from Operation 1, and withdrawal kanban cards from Customers. Upon receiving a withdrawal kanban card, the Supermarket sends a part to the Customer, and sends a production kanban card to Operation 1. Customers submit withdrawal kanban cards to the Supermarket, and then receive the parts that they request.
10
Here we see the entities that flow between the for major sections of the model.
11
For this example, our supermarket shelf has room for 10 parts, so we use a Create module to generate 10 copies of a Production Kanban Card entity in order to fill up the shelf. Note that all 10 cards are sent at time zero, that is, at the very start of a simulation run. This will be important later, since it is how we get the shelf full before customers start arriving. We Separate the Production Kanban Card entity and Assign the duplicate entity to be a Part. This is the same technique we have been using to generate Part entities from Production Control kanban cards.
12
Operation 1 works on a Part for about an hour. Because we are filling the shelf with 10 parts, this means that the shelf will be filled in about 10 hours. Again, this will be important later when we model customers arriving to pick up parts.
13
What we need to do now is attach the Production Kanban Card entity to the Part entity that it produced. This will be the card that gets sent back to Operation 1 when a Part is taken off of a shelf. In the Match module, cards wait patiently until a part is available, and then both are sent off to a Batch module, which joins the two together. The Match module is set up so that the Number to Match is 2, which means that the module has two input points and two output points. The module is configured so that Any Entities that come in will go out together. In other words, the module doesnt care what entity types the incoming entities are, it just matches any 2 that come in from the two input points. The Batch module now forms a batch of Batch Size equals 2 of Any Entity that arrives. Since we tied the two outputs of the Match together, the two entities that arrive at the Batch module will be a pair consisting of a Part and a Production Kanban Card. The batch Type is Temporary, since we will need to separate the part and the card when a Part is pulled off the shelf.
14
Moving on to the Supermarket Shelf, we model the shelf with a Match module. In this module, Part entities and Withdrawal Kanban Card entities coming from customers wait around in the Match module queues until there is at least one of each entity, at which time they both move out of the module. Having served its purpose, the Withdrawal Kanban Card coming out of the Match module is unceremoniously disposed of. But do recall that the Part entities entering the supermarket are already batched with Production Kanban Card entities, so when this pair pops out of the Match module, we need to do another Separate so that we can send the Production Kanban Card back to Operation 1, and send the Part on to the Customer.
15
Over in the Customer section of our model, we use a Create module to simulate arrival of customers to the supermarket. We create Customer entities at about half the rate that Operation 1 produces parts, which means that the operation will be idle about half of the time waiting for parts to be pulled off the shelf. Note that the first Customer entity is created at 15 hours. Since it takes about 10 hours to fill up the shelf and Operation 1 starts working on parts at time zero, the shelf will be filled when customers start arriving. Actually, this is not really necessary, but will make it easier to see how the completed model works. After creating Customer entities, we Separate the entities and then use an Assign module to generate one Withdrawal Kanban Card entity for each Customer arriving at the supermarket.
16
Recall that the Withdrawal Kanban Card generated by the Customer goes to the Supermarket Shelf to cause a Part to be delivered to the Customer. When the Part arrives, the Customer is united with the Part in a Match module. The two are then joined in a Batch module as a Permanent batch of 2 entities. We batch customers and parts as Permanent batches because we will not be separating them again in this model.
17
Before running the simulation, you might want to get all four entities running around in your model identified with a different picture. When you run the simulation, you should see no more than 10 parts on the supermarket shelf. In terms of Operation 1 utilization, we see that the process is running constantly during the time it is filling up the shelf, but then only runs as needed to keep the shelf full. This is because Operation 1 works on parts about twice as fast as customers request them.
18
We said that while keeping shelves full at all times is one way to run a supermarket pull system, one other way to run the system is to refill a shelf only when the number of parts on the shelf falls below some pre-defined order point. Lets see how we might modify our supermarket pull system model to simulate this approach.
19
All we need to do to have our model re-stock the shelf on a re-order level is to add a Hold module that collects the Production Kanban Card entities until the number of parts on the shelf falls below the re-order level. Here, the re-order level is set at 5 parts.
20
When we run the model now, we should never see more than 10 Part entities on the shelf, and never more than 5 Production Kanban Card entities waiting to be sent back to Operation 1. When we look at utilization of Operation 1, we see an initial fill period followed by periods when the operation is re-filling the shelf. The advantage of this approach is obvious: Operation 1 now has large blocks of free time to work on other types of parts.
21
Of course, were probably going to have more than one part type in our system and more than one shelf in our supermarket, so we could expand our supermarket pull system model to include multiple shelves. But well leave this exercise to the student, noting that the general approach is similar to that which we applied when modeling multiple FIFO lanes. We will, however, address a separate issue that does come up when our system needs to replenish several part types. The question is this: When an operation needs to work on several different part types, in what order should it work on the part types?
22
23
In lean systems, this issue of the order in which different parts should be worked on comes under the topic of load leveling. Here we see an example where we need to work on four pieces of two part types. As in our previous model, we use one kanban card for each piece that we need. The question is: which of the four part types should we work on first, then second, then third, and fourth?
24
One way to build the four pieces is to first build two Type 1 parts, and then build two Type 2 parts. If you think about it, this is in essence a batch processing approach like the one we modeled in our first Arena example. But in lean, we typically do not work on parts in batches. Rather, we level the production load by alternating part types as they pass through the system.
25
One way that load leveling can be implemented is through the use of a load leveling box. Each part type that we will be working on has a row of slots in the box. Kanban cards for different part types are put into their own row in the box.
26
The columns of the box represent time slots equal to the time needed by an operation to work on a particular part type. So here we see that it takes an operation twenty minutes to work on Part 1, and 30 minutes to work on Part 2. Now, the kanban cards are put into the slots of the box in the order that the parts should be worked on. So here the operation will work on a Part 1 part type, then a Part 2 part type, then back to Part 1, and so on.
27
This slide shows one way to diagram a load leveling box on a value stream map.
28
In anticipation of building our Arena model for load leveling, we are going to need to create a few Arena variables to keep track of which card is going into which slot in the load leveling box. The variable Type 1 Total is the total number of type 1 parts that the customer is requesting, which is the same as the total number of kanban cards for part type 1 that the Customer sends the Supplier. Type 2 Total is the same quantity for part type 2.
29
Type 1 Needed is the number of part type 1 cards we will put in the load leveling box slots before we switch to putting type 2 cards in the slots. So if we want to put two type 1 cards followed by one type 2 card into the box, then Type 1 Needed is equal to 2 and Type 2 Needed is 1. Well show how to calculate these numbers on the next slide.
30
Given the total number of cards that we receive from the Customer, we need to figure out how many of each type of card to place in a row before switching from one type to another. The top two equations perform this calculation, where the function called minimum selects the smaller of the two quantities referenced. In order to maximize the mix between two part types, we will always place just one card of the type with fewer total cards, and then follow that card with the number of cards of the other type needed to level the production load. It is the minimum function that insures this condition. Note that this expression always yields 1 for the type with fewer total cards, which is what we want, but performing this same calculation for both types doesnt require us to figure out which type has fewer cards.
31
Now imagine that the box is empty and we are just starting to put part type 1 cards into the box. As we put part type 1 cards into the box, we increment the value of the variable Type 1 Found. This makes Type 1 Found equal to the current number of part type 1 cards that we have placed in the box. The bottom line is that when Type 1 Found equals Type 1 Needed, we know that we should switch to putting part type 2 cards into the box. Of course, the same line of reasoning holds for Type 2 Found.
32
Here is an Arena model that will do load leveling for two part types. For this model, we generate separate kanban cards for each part type that we will work on, with one card per piece. The kanban cards for the two part types are sent from Production Control to a Production Scheduler, who sorts through the cards and places them in the box in the appropriate order.
33
Shown here are the part type variables we just discussed. We have added an additional variable called Card Type to Select, which we will use to keep track of what type of card the Production Scheduler is putting in a slot.
34
In Production Control, we use Create modules to generate kanban cards for each part that we need to work on. Here, we show generation of 3 cards for part type 1 at time zero. The associated Assign module assigns each of these cards a Card Type attribute value of 1, indicating that the cards coming from this Create module are for type 1 parts. The Assign module also counts the number of cards passing through it and updates the Type 1 Total variable accordingly. The part type 2 Create and Assign modules are configured similarly, except that the Entities per Arrival in the Create module is 6, and the Card Type attribute value in the Assign module is 2, since we want to build 6 pieces of type 2 parts. All of the cards are then dumped into a Hold module, where they wait to be pulled out by the Production Scheduler. As we will see shortly, there is actually no need to have an output flow from the Hold module. Choosing a Type for the Hold module as Infinite Hold models this situation.
35
Over in Production Scheduling, we Create an entity called Card Sorter, which we can think of as the person who will sort through the stack of cards coming from Production Control and put the cards in the load leveling box in the appropriate order. Note that we need to create the Card Sorter at a First Creation time later than when the cards are created. Otherwise, the Card Sorter wont have any cards to sort. The first thing the Card Sorter does is calculate the number of cards needed, as modeled in the Assign module. The expressions shown in the Assignments window are Arena-speak versions of the equations that we saw a few slides ago for calculating the Type 1 Needed and Type 2 Needed variable values.
36
In order to fill the load leveling box, the Card Sorter needs to sort through the Stack of Mixed Cards sitting in the Hold module in Production Control to pull out the needed number of type 1 cards, and then the needed number of type 2 cards. We see that the two Assign modules change the value of the Card Sorter entitys Card Type to Select attribute to reflect which type of card the Card Sorter needs to look for when sorting through the stack. So, for example, when the Card Type to Select attribute value is set to 1, the Card Sorter will pull out the needed number of type 1 kanban cards from the Stack of Mixed Cards. The two Assign modules also reset the value of the Type 1 Found and Type 2 Found values to zero. Recall that we will be incrementing these values each time we pull the associated card type. Note that since the Calculate Cards Needed module is attached to Get Cards for Part Type 1, the Card Sorter starts by looking for type 1 cards, but this is arbitrary the Card Sorter could very well have started looking for type 2 cards.
37
OK, now things get interesting. The Card Sorter entity goes to a Search module, which searches the Stack of Mixed Cards module queue. The Search module looks for Card entities in the queue with a Card Type attribute that matches the Card Type to Select attribute attached to the Card Sorter. Recall from the previous slide that the Card Type to Select is initially set to 1, meaning that the Card Sorter will start by pulling cards for part type 1. What happens when it finds a Card Type that matches the Card Type to Select? Well, lets see.
38
When a kanban card of the right type is found by the Search module, then the Remove module pulls the Card entity out of the Stack of Mixed Cards queue and sends it to the Load Leveling Box, which is another Hold module. We arent modeling the operation that will be taking the cards out of the load leveling box, so we can model the Hold module with Type of Infinite Hold. The result is that at the end of the simulation, this Hold module will contain the complete stack of sorted cards.
39
Regardless of whether or not the needed Card type is found, the Card Sorter entity moves on to a Decide module that determines if there are additional cards in the Stack of Mixed cards queue that need to be sorted. If the Card Sorter has sorted all the cards in the Stack of Mixed Cards, it is unceremoniously disposed of, having performed its assigned duty.
40
On the other hand, if there are more cards to sort through, the Card Sorter goes to a Decide module that determines which card type is currently being sorted for, and then the card type found variable for that card type is incremented by the Assign module. Here, we are following the path for just a type 2 card, since type 1 cards follow the same type of path.
41
The final step in this sequence is to Decide if the Card Sorter needs to find another Card of the same type in the Stack of Mixed Cards queue, or if it needs to switch to finding the other card type. It does this by checking to see if the type found variable matches the type needed variable. If it does not match, the Card Sorter goes back to the Search for Card module to find another Card of the same type. If it does match, the Card Sorter goes to the Assign module to change its Card Type to Select attribute to the other card type.
42
Here we see the results of our efforts. As desired, running the model fills the Load Leveling Box with cards that alternate between type 1 and type 2 cards, with 1 card of the type with fewer cards mixed with 2 cards of the type with more cards.
43
Our final topic is kanban production, which forms the backbone of many lean systems.
44
Up to now, all of the lean techniques that we have modeled have involved singlepiece production, that is, the upstream operations have sent parts to downstream operations one piece at a time. As discussed earlier, the antithesis of single piece flow is batch production, where batches of parts are typically stored in a stockroom between operations. While single-piece flow is the ideal approach for lean, in reality it is often not practical to adhere strictly to single-piece flow. For the lean technique known as kanban production, parts are moved between operations in batches rather than one piece at a time. We should note that while kanban production moves parts in batches, this is not at all the same as batch production. For example, the batches of parts in kanban production typically move directly from one operation to the next, with no stop in the stock room between operations. Also, the batches of parts are still pulled through production by downstream operations, not pushed into the system by upstream operations.
45
In our last example of this lecture, we will see one way of modeling a kanban production system. For kanban production, batches of part are often moved between operations in kanban bins. For our model, each bin has a kanban card attached to it which contains information about the parts in the bin, and specifies how many parts should be in the bin, which we will call the kanban quantity. The goal of each operation in the kanban system is to fill a kanban bin with the kanban quantity of parts, and then move the bin of parts to the next operation. The rule is that as soon as the kanban bin is full, the upstream operation sends it to the downstream operation. So how does an operation know that it is time to fill a bin?
46
As in some of our previous lean techniques, it is kanban cards sent from downstream operations that signal the upstream operations to send parts. The kanban cards are the same cards that are attached to the kanban bins. In some cases, just the cards are sent, and in some cases the cards and bins are sent together. So the main difference between kanban production and single piece flow is that the upstream operation will deliver not a single piece of the required part, but a bin of parts containing the kanban quantity of parts specified on the kanban card.
47
One way to implement kanban production is for the downstream operation to send the card upstream only after it has emptied the bin that it is currently working on. For this approach, there is at most only 1 bin-full of work-in-process parts. The problem is that the upstream operation needs to wait for the downstream operation to finish the bin full of parts before it can work on anything, and vice versa. Fortunately, we have already seen a more effective way to do this.
48
As we did with single-piece continuous flow with pull, all we need to do is to create a one-bin buffer between the operations. But note again that this buffer bin does not get sent to stock between operations, it stays in the process flow.
49
Here is our Arena model for kanban production. Our model consists of three areas: Production Control, Operation 1, and Operation 2, with parts being shipped from Operation 2 to the customer. We will implement a kanban system between Operation 1 and Operation 2. For our model, a production run of parts is initiated by having Production Control prepare one single kanban card. As in our previous lean examples, Production Control sends the kanban card to Operation 2. As soon as Operation 2 is ready to work on a bin of parts, the operator sends the card to Operation 1. Operation 1 then builds just enough parts to fill a kanban bin with the kanban quantity specified on the kanban card. When the bin is filled, Operation 1 stops working on parts and the bin and attached card are sent to Operation 2. In our model, we will be tracking the flow of parts and cards, but will not create a separate entity for bins. You could, of course, do this, and it would add realism to your model, but well skip it here for the sake of simplicity.
50
For this kanban model, Operation 2 is configured with a one-bin buffer, which is similar in concept to the one-piece buffer that we used in our model of single-piece continuous flow. This means that while Operation 2 is working on the parts in one bin, another full bin of parts is stored in the operation waiting to be worked on. When Operation 2 is ready to work on the bin in the buffer, the kanban card is removed from the bin and returned to Operation 1. Operation 1 then fills a bin, and sends the bin and card back to the one-bin buffer. The kanban card keeps shuttling between Operation 1 and Operation 2 until the total order is complete. The kanban card is then disposed of. So for the lean system we will be modeling, Production Control needs to send only one kanban card to Operation 2, and from then on, Operation 2 is responsible for pulling bins full of parts through the system. As with the other lean techniques modeled here, no other interaction with Production Control is necessary.
51
Here is our model for Production Control. The Create module creates one Kanban Card entity at the start of the simulation. The Assign module then creates two variables. Recall that since these are variables, they are not attached to the Kanban Card entity, but can be read by all other modules in the model. The Order Quantity is the total number of parts that must be built, the Kanban Quantity is the number of parts that will be put in a kanban bin when moving parts between operations We see that Production Control has decided to fill the full order of 100 pieces by filling kanban bins with 10 pieces each. The Kanban Card is then sent from Production Control to Operation 2.
52
The Kanban Card from Production Control flows into Operation 2. A Hold module is used to check if Operation 2 is ready to start the order. Since we have a one kanban bin buffer in front of Operation 2, the Hold module scans the Operation 2 queue to see if it is empty before sending on the card.
53
As we mentioned, there are two separate entities that we want to move through our system: kanban cards and parts. We already have a Kanban Card entity, so now we need to create Part entities. We do this using Separate and Assign modules. The Separate module creates a duplicate of the Kanban Card entity, and the Assign module turns the duplicate entity into a Part. This is the same approach that we used in some previous examples in this tutorial. The Assign module also creates a variable called Operation 1 Quantity. We will use this variable to count the number of pieces that Operation 1 has worked on while filling a kanban bin. Note that this counter is reset to zero each time Operation 2 returns a kanban card to Operation 1. Now lets follow the Part entities through Operation 1.
54
As we work on each Part in Operation 1, the variable Operation 1 Quantity is incremented in the Assign module. Operation 1s Process module performs the work on the Part flowing in to it. Note the time delay on Operation 1, which will be one tenth the value of the delay for Operation 2. Here we are modeling the situation where Operation 1 is faster than Operation 2.
55
Next, as we did in some previous models in this tutorial, we split the Part entity into two entities using a Separate module. We send the original entity to a Batch module which fills up the kanban bin, with the batch size being equal to the Kanban Quantity. The Type of batch created is Temporary, since the batch will need to be separated before Operation 2 can work on it.
56
As in some previous models, the duplicate Part entity re-circulates back through Operation 1, but only after the Decide module checks to see if any more parts are needed to fill the kanban bin. If we have filled a kanban bin, we dispose of the circulating Part entity, and Operation 1 then waits until Operation 2 sends back a kanban card requesting another bin of parts.
57
So much for working on parts. Let us now follow the Kanban Card through Operation 1. We said that we want to attach the Kanban Card to a bin full of parts, which we do in the Match module. In this module, a Kanban Card dutifully waits in its Match queue until a kanban bin full of parts arrives. Then the two entities move off together to a Batch module, where the card is temporarily attached to the bin, and the pair moves on to Operation 2. One thing to note here is that we now have a batch within a batch, that is, we first batched a bunch of parts together in a bin, and then we batched a bin with a card. This is perfectly fine, as long as we un-batch the entities in the same order as they were batched.
58
Now over to Operation 2. Recall that we want to have a one-bin buffer in front of Operation 2. What this means is that even though Operation 2 may be working on a batch of parts, we will allow Operation 1 to send over the next bin of parts to be worked on. We model this buffer with a Hold module, which holds the bin and its attached card until the Operation 2 queue is empty. Once this occurs, we Separate the card from the bin, and send the two types of entities off on their separate ways using a Decide module.
59
We now un-batch the bin-full of Part entities using a Separate module, so that the parts can be worked on by Operation 2. Again, Operation 2 runs ten times slower than Operation 1.
60
As for the Kanban Card, we use this entity to decrement the Order Quantity variable using the Assign module. Since Operation 1 just delivered a number of parts equal to the Kanban Quantity, we reduce the Order Quantity by this amount. In the Decide module, we check to see if the Order Quantity is greater than zero. If so, this means we need more parts, so we send the card back to Operation 1.
61
Here we see our simulation in action. We have one Kanban Card waiting for Operation 1 to fill the next kanban bin, and five parts already in the bin. There is no bin in the Operation 2 one-bin buffer yet, and Operation 2 is working on the first of ten parts from the first bin sent to it.
62
Here we see the situation some time later. Operation 2 is still working on the first part in the first bin, but now has one bin in its buffer. Operation 1 is waiting for Operation 2 to send the Kanban Card attached to the bin in the buffer, at which time it will begin filling the next bin.
63
Here we see resource utilization for the two operations with Operation 1 ten times faster than Operation 2.
64