Constant Work in Process Control System (CONWIP)

CONWIP (Constant Work In Process) [11, 15, 70-72] establishes a limit on the WIP in the line and simply does not allow releases into the line whenever the WIP is at or above limit. A new job is introduced to the line each time a job departs (Figure 2.7) and results in a WIP level that is very nearly constant. To be effective, a reasonable maximum level of WIP for the flow must be established. If this level is too low (i.e., near the critical WIP), throughput will suffer. If too high, then cycle time will be excessive [11].

Opi is Operation i (i: A to E) Ii is the parts Input buffer of Opi AA is the queue for production‘s authorisations of the whole line

Oi is the parts Output buffer of Opi Dcustomer is the queue for customers‘ demands

Figure 2.7: CONWIP release strategy [64]

CONWIP implicitly assumes two things:

IA OpA Raw Parts OA IB OpB OB IC OpC OC ID OpD OD IE OpE OE DCustomer Customer DA DB DC DD DE Demands AA IA OpA Raw Parts OA IB OpB OB IC OpC OC ID OpD OD IE OpE OE DCustomer Customer

52

(1) The production line consists of a single routing, along which all parts flow. (2) Jobs are identical, so that WIP can be reasonably measured in units (i.e., the

number of jobs or parts in line).

In such situations, the basic CONWIP protocol (i.e., start a new job whenever one in proves finishes) can be easily and effectively used for shop floor control.

Nevertheless, very long line should not be run as a single CONWIP loop. For instance, one should not create a single CONWIP loop spanning an entire semiconductor fab ─

there are simply too many steps. A long CONWIP line begins to behave like a push system. That is, when the WIP cap is large (because the line is long) WIP can accumulate in sections of the line and be unavailable in others. This creates ―WIP bubbles,‖ which disrupt flow and thereby defeat the flow smoothing role of a pull

system. Fortunately, a long line can be broken into several tandem lines. One way to do this is to control the line as several tandem CONWIP loops (Figure 2.8) separated by WIP buffers [73]. The WIP levels in the various loops are held constant at specified levels. The inter-loop buffers hold enough WIP to allow the loops to temporarily run at different speeds without affecting (blocking or starving) one another. This makes it easier for different managers to be in charge of the different loops. However, the extra WIP and cycle time introduced by the buffers degrade efficiency. This is trade-off one must evaluate in light of the particular needs of the manufacturing system. The more CONWIP loops the line is broken into, the closer its behaviour will be to Kanban.

CHAPTER - 2 LITERATURE REVIEW

53

Opi is Operation i (i: A to E) Ii is the parts Input buffer of Opi Ai is the queue for production‘s authorisations of the loop starting at Opi

Oi is the parts Output buffer of Opi Dcustomer is the queue for customers‘ demands

Figure 2.8: Tandem CONWIP loops [64]

If one loop is a clearly defined bottleneck, however, it may be decoupled from the rest of the line. This will let the loop run as fast as it can (i.e., to work ahead), subject to availability of WIP in the upstream buffer and subject to a WIP cap on the total amount of inventory than can be in the line at any point in time. Of course, this means that the WIP in the downstream buffer can float without bound, but as long as the rest of the line is consistently faster than the bottleneck loop, the faster portion will catch up and therefore WIP will not grow too large. Of course, in the long run, all the CONWIP loops will run at the same speed ─ the speed of the bottleneck loop [11].

While it is certainly simplest from a logistics standpoint if machines are dedicated to routings, other considerations sometimes make this impossible. Shared resources complicate both control and prediction of CONWIP lines. If the facility contains multiple routings that share workstations, CONWIP levels can be established along different routings.

If different jobs (product mix) require substantially different amounts of processing on the machines, then things are not so simple. The reason is that the total workload in the line may vary greatly because of the difference in processing times across products. To

AA IA OpA Raw Parts OA IB OpB OB IC OpC OC ID OpD OD IE OpE OE DCustomer Customer AD

54

use CONWIP in these settings the policy must be expanded. CONWIP levels can be stated in units of ―standardized jobs‖, which are adjusted according to the amount of

processing they require on critical resources [11]. For example, the WIPLOAD policy measures the overall workload on the shop floor as the sum of the remaining processing times of all the items on the shop floor [74]. Each time an item go through one of the operation, the WIPLOAD is reduced by this operation processing time. New items are then released into the line to maintain the WIPLOAD constant at a prescribed level.

Therefore, CONWIP can be applied to a very broad range of production environments. Of course, greater system complexity generally implies greater variability and hence lower efficiency. Nevertheless, the WIP cap provided by CONWIP will prevent inventory from growing without bound, which will make the system more stable and manageable. The following conditions are needed for CONWIP to work well:

(1) The loop should not be too long. The line can be broken into several tandem lines.

(2) Part routing can be grouped into a small number of product flows. Each flow will make up a CONWIP loop.

(3) There must be a measure of WIP. In some systems, this can simply be a count of the units in the system. But in systems where different part types require vastly different process times, it makes sense to measure the WIP in terms of processing time required.

Two problems that can arise with CONWIP (or Kanban) in certain environments are the following:

CHAPTER - 2 LITERATURE REVIEW

55

(1) Premature releases due to the requirement that the WIP level be held constant. (2) Bottleneck starvation due to downstream machine failures.

While the issue of premature releases is not a common problem in lines operating close to capacity, it is a major concern in low utilization routings. Even if a part will not be needed for months, a CONWIP system may trigger its release because CONWIP in the loop has fallen below its target level. In plants with many routing (e.g., a plant tending toward a ―job shop‖ configuration), some routings may not be used for substantial

periods of time. Clearly, under these conditions a constant WIP level should not be maintained along the routing, since this would result in releasing jobs that are not needed until far in the future. A simple way to prevent this is to establish an ―earliest start date‖ for jobs in release list [11].

The problem of bottleneck starvation is at the center of the theory of constraint. Indeed, any starvation of the bottleneck results systematically into lost capacity and reduced throughput for the whole line. Therefore there should be enough inventories in the line to preclude the bottleneck starvation. Simultaneously, long queues in front of the bottleneck have to be avoided to keep low inventory. In other words, items should arrive as late as possible to the bottleneck machine, just in time to prevent the bottleneck starvation [44]. A proper scheduling of the arrivals at the bottleneck is important. It is the object of dedicated release strategies (see Theory of Constraint section, p58).