In my previous post I described how POLCA (Paired-Cell Overlapping Loops of Cards) is supposed to work. Now let me look at the advantages and disadvantages of the method. Overall POLCA is a valid method of managing job shops. If it is the right one for you depends very much on your production system.
Benefits of POLCA
POLCA is good at controlling the inventory. Since all processes (cells, machines, etc.) are connected using loops with a limited number of POLCA cards, they can prevent excessive inventory between two cells. Hence, if a process is blocked in one direction due to the lack of POLCA cards, it can use the available capacity to make products for another subsequent process that has free POLCA cards available. This allows for a better and also more timely use of the utilization of the different processes. The reduction in inventory also reduces the overall throughput time.
CONWIP systems could be set up across the entire job shop. In this case, it is still possible to accumulate inventory in some parts while others run dry. A POLCA system defines the inventory along every possible step in the value stream, and hence allows for a finer tuning of the inventory (although you could similarly also set up multiple CONWIP loops).
Avoids Blocks toward Upstream
You could also limit the inventory at a process with a simple FIFO in front of the processes. However, in this case a very busy upstream process may block other less busy upstream processes by filling up the FIFO and prohibiting other processes from getting their turn. With the individual loops for each two connected processes, every upstream process gets its shot. In other words, every upstream process has a chance to deliver its goods downstream.
Minor Issues with POLCA
There are a few issues with POLCA. None of them is a deal breaker, at least not for all production systems. And many of these issues are shared with other ways to manage job shops.
A Bit of Complexity
The method with its multiple overlapping loops of POLCA cards can be complex. The POLCA loops have to cover every possible path that a product can take. If it goes from one machine to another, you need a loop. If it goes back, you need a second loop. In its extreme, it would need two loops between every possible machine combination.
However, in actual application this seems to be manageable, and real-life systems have much fewer loops than the maximum possible. There are numerous reports from the shop floor that it works.
What’s With the Overlap?
Why is that? Suri told me that this helps with positive interactions between the workers of different processes, and avoids the “throw it over the wall” effect.
This effect is believable, but I would prefer no overlap. I worry that having sometimes two cards (during processing) and sometimes one card (whenever not processing) attached to the part may be a bit more confusing. My preference would be without overlap. But I also agree that this is not a strong argument. I guess either way is possible.
Accuracy of the Order Release Time
This will be very difficult to calculate. I have worked with job shops before, and it is quite difficult to determine the order release date for the first process, much less for every process along the line. Job shops are notoriously difficult to plan, and suffer from the butterfly effect (a small difference between assumption and reality can have a big effect). On the other hand, all control systems have similar problems in job shops, so this is also not a big handicap. It depends how much effort you need to determine these times and to get them to the people that need to know them.
A POLCA system can in some rare cases cause a deadlock, where a combination of orders and POLCA cards can cause processes to block each other. Below is a simplified example, where M1 cannot continue without a M1-M2 POLCA card. All M1-M2 POLCA cards, however, are at M2, which cannot continue without a M2-M1 POLCA card. However, these cards are all at M1. A deadlock ensues, and neither process can continue.
It seems, however, that this happens very, very seldom. It can happen only if the POLCA loops form a circle (i.e., following the loops you may eventually come back to the starting process, as in the image above from M1 to M2 and back to M1). According to Suri, this has happened only in simulations, but not yet in reality. Suri also developed a solution using a “cycle card.” This is not a regular POLCA card that goes back and forth, but a card that always goes forward along the processes in the loop. Details are in the chapter 6 Preventing Gridlock When Loops Form Cycles in The Practitioner’s Guide to POLCA.
Overloading or Low Utilization
POLCA tries to balance the workload in the production system and tries to prevent overloading of a process – which is a worthy goal. However, it is easy to imagine situations where this breaks down. Take the example here. Four machines (M1-M4) feed two other machines (M5 and M6). Hence both M5 and M6 can receive work from multiple machines.
It is possible that there is a lot of work for M5 and none for M6. Hence, M5 would be overloaded, and M6 would be idle. The actual maximum inventory in each loop would be limited by the POLCA card, but multiple loops with a number of POLCA cards each can add up to a lot of material. In the example there are four loops arriving at M5, each with 5 POLCA cards, putting a whopping twenty products at M5 for production. At the same time, M6 would be starving for work.
While this is an extreme example, similar situations can happen. But then, they can also happen with other job shop control systems. Any kind of planning in a job shop is difficult and failure-prone.
POLCA requires an order release date for every process the part has to go through. This usually means that the production sequence has to be fixed beforehand. This reduces flexibility.
In my experience, many job shops do have alternative processes available. A part could be processed on machine 1 OR machine 2. I also have experienced rerouting in job shops if one machine is overloaded and another one is available. While not ideal, in a chaotic job shop it sometimes does make sense. For POLCA, however, it would require quite a bit of recalculation and rearrangement. Have a look at the overloading example from above again. Must all parts go through M5? Or did a system quirk merely schedule all parts for M5 and none for M6?
There is simply no good solution for job shops, but CONWIP and POLCA are often good enough. It depends very much on the specifics of your system to decide if POLCA or CONWIP is better, and even that is difficult to determine beforehand. Hence, POLCA is a valid option to control job shops.
Please believe me, I did not come to this conclusion lightly. In fact, I wrote this post twice. The first time I nitpicked everything apart (a bad habit of mine sometimes). Yet, Rajan Suri was very patient and provided me with lots of information and details on POLCA. It does not happen often, but he changed my mind, and I now believe that POLCA can work. If you go the POLCA route, I recommend his 2018 book The Practitioner’s Guide to POLCA. It contains more information and updates compared to his 1998 book. It also contains details on steps for designing and implementing a POLCA system.
But make up your own mind and choose the method that works best for you! In my next post I will talk about the method to calculate the number of POLCA cards. Until then, I hope this post was of interest to you. Now go out and organize your industry!
The original book by Suri is Suri, Rajan. Quick Response Manufacturing: A Companywide Approach to Reducing Lead Times. Portland, Or: Taylor & Francis Inc, 1998.
Suri just published another book: Suri, Rajan. The Practitioner’s Guide to POLCA: The Production Control System for High-Mix, Low-Volume and Custom Products. Productivity Press, 2018.
While doing my research I also found the book by Hermann Lödding helpful, although to my knowledge it is available only in German: Lödding, Hermann. Verfahren der Fertigungssteuerung: Grundlagen, Beschreibung, Konfiguration. 3. Aufl. 2016. Berlin Heidelberg: Springer Vieweg, 2016.
P.S.: This series of blog posts is based on a question by Vyacheslav Goncharenko.
P.S.: I would like to thank Rajan Suri for his input and his patience.