Welcome to Arena tutorial number 10.

In this two-part set of tutorials, we will begin to apply our already vast and still growing knowledge and experience with Arena to modeling lean techniques. Please note 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.

We need to preface these tutorials with a disclaimer. Lean is not a bag of tricks to be capriciously applied in a piecemeal manner to instantly achieve world-class performance. Lean is a paradigm, that is, a world view, or way of thinking about system that can benefit from judicious and well-planned application of appropriate techniques that support the lean paradigm. That being said, these tutorial are mostly about modeling a set of lean techniques commonly applied in lean systems. In order to benefit from the material covered in these tutorials, you must apply these techniques in the true spirit of lean thinking.

We are about to spend considerable time and brainpower building models of lean techniques, so some justification for this effort is appropriate. One major benefit of applying lean techniques is that they can drastically improve measures such as work-in-process, throughput, and so forth. So, wouldnt it be nice to be able to model as-is and to-be systems employing lean techniques to predict potential improvements before any changes are made? And wouldnt it be equally beneficial to check to see that potential improvements were actually realized after the lean techniques were applied? Here is yet another reason for going through these tutorials: Its easy to talk about lean techniques in hazy generalities, but it can be something totally different to implement the techniques on actual real-world systems. Creating simulation models forces you to address many implementation details before you start eliminating stock rooms and pushing 100 ton punch presses around the shop floor.

We will construct three basic models in this tutorial, and three more in the second of this pair of tutorials. Well start by modeling batch processing, a decidedly un-lean form of production.

For batch processing at its worst, each manufacturing operation in a sequence of operations receives a production order from production control to work on a certain number of parts. The materials needed to complete the order are then pulled out of the stock room. The operation then works on all the parts in the production order, and then sends the entire batch of parts to the stock room. The parts then sit in the stockroom until the next operation receives an order from production control to continue working on the parts. This slide shows a value stream map representation for batch processing.

Here is a simple Arena model which simulates batch processing. Operation 1 works on a batch of parts designated as Type 1, and sends the batch to the appropriate shelf in the Stock Room. Production Control sends a Production Order to Operation 2 to make Type 2 parts from Type 1 parts. When Operation 2 receives the Production Order, it pulls a batch of Type 1 parts from the Stock Room, converts the entire batch of parts into Type 2 parts, and sends the batch of Type 2 parts back to the Stock Room. For the sake of simplifying our model, we have not shown the Production Order sent by Production Control to Operation 1 to make the Type 1 parts in the Stock Room.

We simulate Operation 1 with a Create module that creates a batch of 10 Type 1 part entities all at once at time zero. We then batch the parts with a Batch module, specifying a Temporary batch Type since Operation 2 will need to separate the batch to work on the parts.

From Operation 1, a batch of Type 1 parts goes to the Stock Room shelf for Type 1 parts, which we model as a Hold module. The Hold module Type is specified as Scan for Condition, which means that the batches stay on the shelf until the specified condition is met. The condition scanned for is that there must be at least one entity in Queue 1 of the Match module in Operation 2 named Receive Type 2 Production Order. Before switching over to Operation 2, lets see what goes into Queue 1 that would cause this condition in the Operation 1 Hold module to be met. Things are going to get a bit complicated now, so pay attention.

We Create one single production order entity for Type 2 parts at the start of the simulation. This Production Order 2 entity is received by the Match module in Operation 2, and is stored in Queue 1 of that module. This is the entity that we mentioned on the last slide that the Stock Room Hold module scans for before releasing the batch of Type 1 parts to be worked on by Operation 2. The effect of all of this is that when Production Control sends Production Order 2 to Operation 2, a batch of Type 1 parts is sent from the Stock Room to Operation 2.

When the Production Order 2 entity arrives at the Match module of Operation 2, the batch of parts from the Stock Room flows into Queue 2 of the Match module. The Match module functions by holding entities in its two queues until both queues have at least one entity in them, and then both entities leave the module. The Match module is configured with the Number to Match equal to 2 entities, which is why the module has two inputs flowing into it, one for the production order and one for the batch of parts to be worked on. The module is configured to match Any Entities, which means that it doesnt care what entity types enter the module, all it needs is one entity in each queue to release both entities.

10

The Match module is a bit tricky, so lets examine it in greater detail. The Production Order 2 entity flowing into the upper input of the Match module also flows out of the upper output when a match occurs, with the batch of parts entering the lower input flowing in a similar way. However, the queue symbols above the module are oriented in the opposite way, that is, the upper queue symbol shows parts accumulating in queue 2, which means that entity animations entering the lower input appear in the upper queue symbol. It is possible to move queues around on the model after you have placed the module, but this irregularity can cause you a world of hurt during debugging. In any case, having served its purpose in life, the Production Order 2 entity flowing out of the Match module is disposed of after allowing the batch of parts to be pulled from the Stock Room shelf.

11

The Separate module of Operation 2 is configured to Separate Existing Batch, which means that it breaks up the batch of Type 1 parts flowing out of the Match module into individual parts. The Process module for Operation 2 then works on the parts.

12

Since the effect of the Process module is to convert Type 1 parts to Type 2 parts, we use an Assign module to change the entity type of the part entities to reflect this change. We then Batch the parts and send the batch off to the Stock Room shelf for Type 2 parts. For this limited model of batch processing, we can use a Stock Room Hold module Type of Infinite Hold, since we will not be modeling the withdrawal of Type 2 parts from the Stock Room. The effect is that the batched parts will just accumulate in the Hold module until the end of the simulation run, rather than being disposed of by a Dispose module.

13

Heres a snapshot of our model just after we start a simulation run. You can see that Production Order 2 as arrived from Production Control, and that Operation 1 has started filling a batch of 10 Type 1 parts. At this point, Operation 2 is waiting for a batch of Type 1 parts to appear in the Stock Room so that it can start Production Order 2.

14

Here, the batch of Type 1 parts has moved on to Operation 2, where seven of the 10 parts are in queue waiting to be worked on. Operation 2 has completed two parts, and is currently working on one part.

15

Finally, Operation 2 has completed working on its batch of Type 2 parts, and the batch has been sent to its shelf in the Stock Room.

16

With this simple warm-up model for batch processing, we are now ready to dive into our set of five lean techniques, starting with the ultimate in lean production single piece continuous flow with customer pull.

17

The ideal configuration for lean systems is single piece continuous flow with customer pull, where the term customer applies to the downstream operation that received the output of its upstream operation. For this type of system, an operation is performed on a single part, and the part is immediately moved to the next operation in the process. No part leaves an operation until the next operation has completed its work, and no parts are stored between operations. Since a downstream operation must be ready to work on a part before an upstream process can give it a part, the parts are pulled through production by the last operation in the process vs. being pushed through production by the first operation.

18

Lets look a bit closer at single piece continuous flow with customer pull. For our simple model, we have just two operations: Operation 1 sends parts to Operation 2, which sends parts directly to the customer. For pull systems, a production order is typically sent to the last operation in a process, which then pulls parts out of upstream processes. So for our model, Production Control sends a Production Order to Operation 2. In this simple model we will assume that we have a long-term contract with the customer, so once we start working on a Production Order, well juts keep delivering products forever.

19

Our single piece continuous flow production system is arranged so that the operations are located right next to each other. This means that an upstream operator can easily see if the downstream operator is finished working on a part and is ready for the next part. If they are ready, the upstream operator simply pushes the part they have completed working on down to the next operator. So for the simple system we are modeling, once the production order goes to the last operation in the system, no other communication is needed to get parts to flow through the system other than having each operator visually check to see if the next operator is ready.

20

Our Arena model for this system consists of three sections. Production Control sends a production order to Operation 2. When Operation 2 is finished working on its current production order and is ready to start the next order, Operation 1 can begin working on parts for Operation 2. Operation 1 works on parts one piece at a time and moves them on to Operation 2 whenever Operation 2 is ready for its next piece. Operation 1 starts on its next piece as soon as it moves its just-completed piece on to Operation 2.

21

We use a Create module to create one single entity at time zero, which we call the Production Order. The Production Order goes to a Hold module associated with Operation 2 that holds the entity until Operation 2 is ready to start on the Production Order. We model this behavior by having the Hold module hold the incoming Production Order in its queue until its Scan for Condition is met. The condition scanned for is that there are no parts currently being worked on in Operation 2, in other words, until the work-in-process for Operation 2 is zero.

22

We use a Separate module to separate the Production Order entity into two entities. The original entity continues to represent the Production Order received from Production Control. We dispose of this entity, because in this simple model we use a production order only to initiate a production run at the last operation in the system. From there on out, parts are pulled through the system without interference from Production Control. We send the duplicate entity on to Operation 1 to create the first part for this operation to work on. Now, it is not at all necessary to separate the Production Order into these two entities. We could have just sent the Production Order on to initiate part production by Operation 1. However, here and throughout the remaining models in this tutorial, whenever we create an entity, we will attempt to follow the entity through the model just as it would flow in a real-life system. So in this model, we dont have the Production Order just disappear into thin air after it serves its purpose, nor do we magically transform one entity type into another without explicitly representing this transformation.

23

The duplicate Production Order entity that we just generated goes to Operation 1, where we use an Assign module to convert this entitys type into a Part. As we just said, we are not going to let entities just float around in our models without explicitly specifying exactly what they represent. So from here on out, it is Part entities that will be flowing through our model, not Production Order entities. This Part is now worked on by Operation 1 using the Process module shown. Note that Operation 2 is modeled by a Process module configured in exactly the same way as Operation 1, except that the resource used is quite logically named Operator 2 vs. Operator 1.

24

After Operation 1 finishes working on a Part, the Part sits in the Hold entity queue until Operation 2 is ready to work on the next part. The Part then moves to a Separate module, with the original Part moving on to Operation 2. The duplicate Part goes back to Operation 1, where it becomes the next Part that will flow through the process. This Part will continue to loop through Operation 1 until you terminate the simulation. We will use this little Arena modeling trick of re-circulating entities throughout the remaining examples in this tutorial.

25

We are now ready to run our simulation. When we configured the Operation 1 and Operation 2 Process modules we assigned one operator resource to each. Here, we see plots showing when these operators were busy over a 48 hour simulation run. Since Operation 2 is not working on any parts at the beginning of the simulation, we see that after Operation 2 receives a Production Order at time zero, Operation 1 immediately starts working on the first Part. Operation 2 waits for the first Part to arrive, and is then off and running. Recalling that we configured both Process modules to have delay times with identical triangular probability distributions, we see slight gaps for both operations as one operation finishes working on a part either before or after the other operation. Because the average delay time for both operations is the same, this model represents balanced flow through the system.

26

Lets make a minor change to our system which can have dramatic results. Instead of having an upstream operator shove parts downstream when the downstream operator is ready, lets put a one-piece buffer between the operators. This means that the upstream operator can push one part into the space between operations while the downstream operator is still working on a part.

27

In terms of our Arena model, the change is easy. We just change the scan condition on the Operation 1 Hold module to check on the Operation 2 queue, rather than Operation 2 work-in-process. Since we want our buffer to hold just one piece, we check to see when the Operation 2 queue is empty, then release a part. When we run the simulation, we should now occasionally see one part in the Operation 2 queue.

28

When we add the buffer, we see that the gaps in resource utilization disappear, that is, both operators are working continuously. This is still a balanced system in which the two operations have the same average process delay time.

29

In real life-of course, it can be a challenge getting all of the operations in a process perfectly balanced with the same delay time. Here we see the result when we double the delay time on Operation 2 with the onepiece buffer. As expected, Operator 2 is busy all the time, but Operator 1 is waiting for Operator 2 about half the time. The lean techniques that we will now examine were invented to deal with how to handle situations such as unbalanced flow that crop up to cause us to compromise on our lean goal of single piece continuous flow production. Note, however that one thing we wont compromise on in the following examples is pull production vs. push production, that is, we will always have downstream operations pull parts from upstream operations.

30

Well start by investigate one way to accommodate the realities of production systems known as the FIFO lane.

31

FIFO stands for first-in-first-out, meaning, obviously, that the first piece pushed into a FIFO buffer by an upstream process is the first pulled out by the downstream process. The opposite type of buffer is LIFO, which is last-in-first-out. A stack of plates in a cafeteria buffet line is a LIFO buffer. Lets see one way to set up a FIFO lane.

32

Heres the basic idea behind a FIFO lane: A fast operation is sending parts to a slow operation. We dont want parts to stack up in front of the slow operation, so we need some means of stopping the fast operation from producing more parts than the slow operation can handle. We put a FIFO lane with, for example, 5 slots between the operations. The fast operation keeps working on parts until the FIFO lane has all 5 slots filled. Then it stops working on additional parts until an empty slot opens up at its end of the FIFO lane. When the slow operation finishes working on a part, it pulls the next part off of its end of the lane. All the parts in the FIFO lane shift toward the slow operation, thereby freeing up a slot for the fast operation to fill. This system is also known as conWIP, which stands for conveyor WIP, since the FIFO lane acts like, and may actually be, a conveyor, and the parts in the FIFO lane are work in process. The important point to note here, of course, is that the fast operation only works on parts when there are empty FIFO lane slots for it to fill. As you may have noticed, adding the single-piece buffer between the two operations in the previous example is kind of like having a one-slot FIFO lane.

33

Heres one way to draw a FIFO lane on a lean value stream map. The important point to remember, of course, is that the fast operation only works on parts when there are empty FIFO lane slots for it to fill.

34

Here is our Arena model for lean production using a FIFO lane. Again, we have two operations, with Production Control initiating production at the last operation in the system. We see a 5-slot FIFO lane between the fast Operation 1 and the slow Operation 2.

35

At this point, well introduce the concept of the kanban card. We will use kanban cards extensively in subsequent examples in this tutorial, so we might as well start getting used to the terminology. The production order sent by Production Control is in the form of a card that contains the information needed to complete an order. But why do we need this kanban card, anyway?

36

In our previous example, operations were located right next to each other, so operators could easily determine what was going on at upstream and downstream operations. Here, we assume that operations may be widely-separated, so operators cannot easily keep track of what is happening at other operations. In this model, we use the kanban card as a way for the downstream operation to communicate with the upstream operation. When Operation 2 is ready to start on a new production order, it sends the kanban card that it received from Production Control to Operation 1, which then knows that it can start filling the FIFO buffer.

37

We use a Create module to have Production Control create the single Kanban Card needed to initiate production. We use the Entity data module to make the Kanban Card picture a green ball.

38

When the Kanban Card arrives at Operation 2, the operator checks the order and specifies on how many slots the FIFO lane between Operations 1 and 2 should have. We will allow 5 FIFO lane slots for this example. We use an Assign module to create a FIFO Quantity variable that holds this value. Because we have created a variable to hold the FIFO Quantity, any module in our model can read and change this value. The Operation 2 operator hangs on to the Kanban Card until they are not working on any other parts, and then sends the card to Operation 1. We provide this functionality using a Hold module with Type set to Scan for Condition. Now, a Kanban Card flowing in to the Hold module will sit in the modules queue until there is no work in process in Operation 2.

39

Moving on to Operation 1, we use the Separate module to create the first part worked on by this operation. Now, the entity entering the Separate module is a Kanban Card. The Kanban Card leaves the Separate module as the original entity, which is disposed of, since for this example we only use the Kanban Card to initiate production. The duplicate entity flowing out of the Separate module will represent the first part that Operation 1 will work on. The Assign module converts the duplicate entity from a Kanban Card into a Part entity, and changes the entity picture to a red ball. So, from now on, well just have Part entities moving around in our process. You should have noticed that this is essentially the same trick we used to create part entities in the preceding example.

40

Our Part entity now gets worked on by Operation 1. Note that Operation 1 runs about twice as fast as Operation 2, which is the reason that we put the FIFO lane between the operations.

41

Our Operation 1 model is similar to the one we just used to demonstrate single-piece continuous flow. After a Part leaves the Operation 1 Process module, we Separate it into two entities. The original Part entity goes on to the FIFO Lane, where the Part sits in the FIFO Lane until Operation 2 takes a Part off of the FIFO Lane. We provide this function by modeling the FIFO Lane with a Hold module, which holds Part entities in its queue until there is no work in process in Operation 2.

42

As in the previous example, we use the duplicate Part entity generated by the Separate module to keep parts flowing. We do, however, need to put a Hold module in the duplicate Part recirculation path so that a new part is worked on by Operation 1 only when there are fewer than 5 parts in the FIFO Lane. The Hold module uses the variable that we defined earlier as FIFO Quantity. When the number of parts in the FIFO Lane queue is less than the FIFO Quantity, the duplicate Part is allowed to flow back and become the next Part through the system.

43

OK, were done building this model. When you run the simulation, you should never see more than five parts in the FIFO Lane. We also see here plots for number of operators busy for Operation 1 and 2. Again, Operation 2 is working constantly, but since Operation 1 is about twice as fast, it is working only about half the time.

44

Of course, it would be pretty unusual if we were producing just a single part type in our production facility, so lets see how we would enhance our FIFO lane model to accommodate two different part types. In this model, our fast Operation 1 will be supplying parts to two slower operations. Operation 1 produces generic Part entities. Operation 2 converts the generic Part entities into Type A parts, and Operation 3 converts the generic pats into Type B parts.

45

Starting at Production Control, we now use two Create modules to generate two different kanban cards, one for part type A, and one for part type B. We copy all the modules associated with Operation 2 and paste them to create Operation 3. We send the kanban card for part type A to Operation 2, and the card for part type B to Operation 3.

46

For both Operation 2 and Operation 3, we need to modify the modules to provide unique identifiers for each, and then to change the Hold modules so that they are scanning for the appropriate conditions. Here, we see how we have made the changes for Operation 2. Changes to Operation 3 are analogous. Both operations send their kanban cards back to Operation 1 just as Operation 2 did in the previous example.

47

Recall that we need to convert the duplicate kanban card entities into part entities, just as we did with the Production Order in the previous example. But now we have two different part types to deal with, part types A and B. Note that the kanban card entities coming to Operation 1 are of two types: Type A Kanban Card and Type B Kanban Card, so in Operation 1, we need to Decide which type of kanban card is coming in, route the entity accordingly, and then convert these entities to the appropriate part entity type using Assign modules. Now we will have the correct part type entities running around in our model.

48

Now, Operation 1 supplies part type A to Operation 2 and part type B to Operation 3, so both newly-created part entities flow through the Operation 1 Process module. When Operation 1 has finished working on a part, we need to Decide which part type the part is, and then send it to the appropriate downstream operation. After that, we copy the Operation 1 Separate and Hold module sequence leading to Operation 2, and then paste it so that the new sequence links to Operation 3. Now we need to update the Hold modules so that they hook up with the proper FIFO Lane queue. We have shown this modification for part type A the modification for part type B is similar.

49

As before, when you run the simulation, you should never see more than the Kanban Quantity of parts in either of the two FIFO lanes. One thing that you should notice is that since Operation 1 is now supplying 2 operations, and that since Operation 1 is only twice as fast as the operations it feeds, Operation 1 stays busy pretty much all the time, and the FIFO buffers do not tend to fill up as they did for the previous example.

50

OK, those were some nice warm-up exercises. In part 2 of this set of tutorials well get down to modeling some hard-core lean techniques.

51