POLCA yes, or POLCA no? Review of The Practitioner’s Guide to POLCA (2/2)

This is part 2 of an article about Rajan Suri’s work in the area of QRM, and about his new book The Practitioner's Guide to POLCA. First, it is described in what way standard POLCA deviates from it’s simplified and more well-known form. This is release-and-flow POLCA, which was already introduced in part 1. Next, an in-depth review of Rajan Suri’s book follows, and the comments of Suri on this review. Finally, conclusions about the applicability of POLCA are drawn.

[ Sequel to part 1 ] As explained in Rajan Suri's book The Practitioner’s Guide to POLCA, standard POLCA has one big advantage over the simplified release-and-flow form of this workload regulating system.

Cover of The Practitioner’s Guide to POLCA

Adaptive
It makes the planning adaptive, even after the jobs have been released for production. The decision time is the moment at which people in a QRC decide on what job they will start to work next. With standard POLCA there are three decision rules. One extra rule preceeds the rules for simplified POLCA:

If there are no jobs on the list that can be started, then the QRC-team can utilize their time for cross-training or improvement projects. They could also help in QRC’s with high workloads. It is one of strengths of the POLCA-system that it shows where those QRC’s are. It identifies upstream cells that don’t send their jobs in time, and downstream cells to which the route is blocked.

Overtaking
The most important aspect of the first decision rule is, that orders arriving in the buffer in front of a QRC, can overtake others. So, orders which were delayed during their route along their chain of preceding QRC’s, will be handled first, if possible.
That way, the chance that these are still finished on time, is maximized. In addition, this makes it possible to speed up or slow down specific orders a little bit, when a certain customer would want an adjusted delivery date.

One remark here: Suri says that you should not start with a job for which there is no POLCA-card present for the next cell, even if this job is late. I did not understand this. Although the absence of a card signals that the destination cell has a high work load, it seems good to send the delayed job to this cell anyway, since it can pass other jobs waiting there. Maybe it might be good to have a POLCA wild card available for this situation? Special cards are common in POLCA. These can solve a lot of POLCA-problems, theoretically maybe every problem with this system. I will come back to that later!

436 pages
Above, in combination with part 1 of this article, the complete POLCA-system was described, be it in a nutshell. In the book, a company is mentioned that started to use it within three days, to balance the workload in their existing network of QRC’s.

So, why would you need a book of 436 pages (!) to describe when POLCA is useful and how it can be implemented? The reason is the large number of prerequisites and adaptations needed to make this system work in a certain environment. In addition, half of the book consists of extensive case studies and technical details explained in appendices.

Prerequisites
One of the most important prerequisites for POLCA is the formation of Quick Response Cells and possibly restructuring the (modular) way products are made. The less complex the routing network, the less complex the POLCA-system has to be.

Other prerequisites are designing ways to generate the authorization lists, and calculating the number of POLCA-cards per loop to start with. The latter can be done with an astonishingly simple formula! The minimum number of POLCA-cards that you need in for example a loop between cell A and B is simply equal to:

#cardsAB = (the cycle time for POLCA-card AB without waiting times) * (number of AB card-cycles needed to complete all orders in a planning period) / this planning period.

This is the minimum. Therefore #cardsAB should be multiplied with a safety factor (1+S). This is all explained in more detail in the book.

Adaptations
Adaptations of the POLCA-system to a certain environment typically concern adding special POLCA-cards, to deal with exceptions. One example is the bullet card, which can be connected to a rush order. This production order will then complete its route along the QRC’s as fast as possible, without needing any other POLCA-cards.

Another example is the safety card, to be ‘played’ when for example work on a job is already in progress in a QRC, but it is discovered that some materials are missing. In that case, the job is set aside and a safety card is connected to it, instead of the two POLCA-cards. Next, the destination card is placed back on the POLCA-board within the cell, and the origin card of the job is send back to the corresponding QRC. This ensures that the work in the QRC where the problem surfaced, and the work in the QRC’s up- and downstream of it, can continue, while the job with missing components is waiting.

The number of safety cards is limited and it is advised to use a tracker to log what caused the problem. Still, in my opinion Lean specialists would say that it is better that the work stream in this POLCA-loop comes to a halt immediately, to prevent that new jobs encounter the same problem. Why this is not done is not discussed in the book. The reason behind it might be that the next product, since the production is customer-specific, could need other materials. However, I think that at least this should be judged by the QRC-team. If the risk is big that other jobs get the same problem, it is not a good idea to play the safety card.

Examples
The examples of possible adaptations of the POLCA-system as described above, and there are many more of these in the book (!), show that the companies that have applied POLCA during the last 20 years, found solutions and work-arounds for nearly every problem you might think of. It might be a good idea to make a database available with all known problems and corresponding solutions.

When POLCA was introduced, theoretical situations in which the system would fail were used to criticize it. Twenty years later, as shown in the book, the system has proven to be much more flexible and adaptable than originally thought. If you are considering implementing POLCA, reading Suri’s new book with many examples, implementation guidelines and possible adaptations, therefore is a good idea. Everything is explained in plain language.

Simplicity
In my opinion, the strongest point of POLCA is the simplicity of it and the way it makes work streams and bottlenecks visible. It is relatively easy to explain how POLCA works, and why it solves problems like late deliveries, long throughput times and work-in-progress which is piling up. This can for example be demonstrated by playing a POLCA-game, or by simulating work streams on the shop floor. This results in a rapid buy-in and enthusiasm of many of the people involved.

Not mentioned in the book is that in some cases an even simpler solution is possible than POLCA: a limited buffer space in front of each QRC. These buffers are also a visual management signal to each QRC, that would like to send jobs in their direction: if the buffer is full, don’t do it!

Increasingly complex
When you need a lot of POLCA cards, a lot of special cards, when frequently new authorization lists have to be generated and manually brought to cells, or when the capacity needed per job varies so that a varying number of POLCA-cards is needed to start a job, the POLCA-system becomes increasingly complex. Then, theoretically it might still work, but in practice problems might arise like employees not returning POLCA-cards in time.

Suri states that POLCA works better than scheduling software, because production plans generated by such software become immediately outdated due to changes on the actual situation on the shop floor. However, this is not true when an adaptive scheduling system with real-time feedback on the actual position and status of the production orders is used. Of course, such a digital solution brings along a rather large investment, and it is likely that using it requires more training and discipline.

Digital POLCA
However, three of the companies described in Suri’s book actually use a software system, although an important part of it is a digital form of POLCA. Why did these companies opt for a digital solution? Because applying ‘paper POLCA’ became too complex.

This makes me draw the following conclusion. If POLCA can be implemented in a way that the number of cards, card types and authorization lists are still manageable and above all understandable, then ‘POLCA on paper’ probably is a good solution.

However, when you need increasingly more rules and cards, the advantage of ‘POLCA on paper’ – an easy to understand visual job shop management system – in my opinion disappears. In that case, a digital POLCA system might be better. Then the employees in QRC’s don’t need to be bothered with complex sets of planning rules. The system simply tells them what will be the next job to work on. Besides this, you can add any planning logic that you want, so you could for example take into account the workload at all cells downstream.

If you continue this line of thoughts, then applying a digital POLCA system is not the only option. Other real-time scheduling solutions, for example based on the Theory of Constraints solution for project management, might fit as well.

COBACABANA
Suri added a description of an alternative card-based system, COBACABANA. He deserves a compliment for that, since you hardly see this in management books.

With COBACABANA there is one central planner. He or she schedules the jobs by adding release cards to a planning board, sized equal to their workload. This board has one row for each QRC. When it is possible to add all the cards for one production order without exceeding the maximum allowed workload in any QRC, this order is released. Otherwise the cards are removed again.

Released production orders travel with a copy of the release cards, called operation cards. When a task is finished, the corresponding operation card is returned to the planner, who then removes the related release card from the planning board.

Suri is right when he says that COBACABANA has three disadvantages compared to POLCA. First, since planning is done centrally, the system is not understandable at the level of the work cells. Second, it is more difficult to handle the cards. For example, cards representing the capacity per task need to be present for each job. Third, jobs are released based on the planned workload instead of the actual workload of the cells.

The inventors of COBACABANA suggest corrections for this. It is outside the scope of this article to discuss if these corrections would work. Suri says that the adaptations will make the system too complex. This triggered me to add one final remark. As discussed before, any card-system that needs much corrections, including POLCA, becomes incomprehensible and unmanageable at a certain point. Then it might be better replaced by a digital version of it, since this eliminates the fuss with handling the cards.

Conclusion
My conclusion regarding the book: The Practitioner’s Guide to POLCA is a very good and comprehensive book about POLCA and its possibilities and prerequisites, be it with some positive bias on the applicability of it.

Comments Rajan Suri on the review of The Practitioner's Guide to POLCA
Rajan Suri: ‘I would like to thank Dr Jaap van Ede for his very thorough and insightful review. He has done an excellent job of summarizing the essence of POLCA, as well as the key messages of my new book. I have a few comments in response to some of his remarks in the review. These comments are a bit long because there are technical points to be addressed properly. I hope that it will help readers to get more insight into POLCA and why and when it works well in practice.’

Reviewer: “Suri says that you should not start with a job for which there is no POLCA-card present for the next cell, even if this job is late. I did not understand this. Although the absence of a card signals that the destination cell has a high work load, it seems good to send the delayed job to this cell anyway, since it can pass other jobs waiting there.”

Response: It is very interesting that you say this, because we battled with managers and shop floor supervisors about exactly this point during our early POLCA implementations! There are many reasons why it is not a good idea to start this job. Let’s say there are 5 POLCA cards in this loop. If none are available, this means there are 5 jobs already in process inside the downstream cell. Even if you send another job, it will be “Hurry up and wait”, because the downstream cell is already busy with many other jobs. But it gets worse than this. Suppose 4 upstream cells feed this downstream cell and each of these upstream cells has 3 late jobs but no POLCA cards. If you break the POLCA rule, now you can have up to 12 additional jobs going to the downstream cell, which is already backed up – leading to more congestion on the shop floor.
On the other hand, keeping the POLCA rules, note that once this job gets started, since it is late, it will most likely jump to the front at the downstream cells and start to catch up (see the heading “Overtaking” in the review). The Authorization Dates have a little padding in them, so the job might “appear” to be late, but in fact has a chance to make up time. In addition, the number of POLCA cards needed for a job has a small safety margin. Both help this job to catch up. And finally, the most important point: Breaking the POLCA-rule starts you on a slippery slope: companies can have late jobs from multiple customers competing for capacity. Who will decide to allocate a wild card to a late job, and how many such wild cards will we allow? This takes us right back to the pre-POLCA situation of multiple “hot jobs” and supervisors arguing about which one to do next. The better approach is to design the system with the right safety margins in the Authorization Dates and the number of POLCA cards, and then to have full discipline – everyone has to “play by the rules”. As described in many of the case studies in my book, companies found that after they got the POLCA system working properly, most of the problems (hot jobs or late jobs) simply disappeared.

Reviewer: “Another example is the safety card, to be ‘played’ when for example work on a job is already in progress in a QRC, but it is discovered that some materials are missing (…) In my opinion Lean specialists would say that it is better that the work stream in this POLCA-loop comes to a halt immediately, to prevent that new jobs encounter the same problem. Why this is not done is not discussed in the book. The reason behind it might be that the next product, since the production is customer-specific, could need other materials. However, I think that at least this should be judged by the QRC-team.”

Response: You are exactly right on both points. Firstly, in a (high-volume) automotive assembly line, typical of Lean manufacturing, if a worker tries to install a switch in a driver’s display panel and finds that the connectors for the switch are incorrect, it is likely that all the switches have wrong connectors and the next car on the line, and the next car as well, will get this same problem! So it makes sense to stop this line immediately. But in companies using POLCA, we have seen that most of the time the next job needs a different switch, from a possibly different supplier, or maybe no switch at all! Secondly, you make a good suggestion to judge the "repeat-risk" of this problem, and this could be done very well by a joint review between the QRC-team and the “Safety Card Owner” (explained in the book). So this could be an improvement to this process which readers can implement – thank you!

Reviewer: “Not mentioned in the book is that in some cases an even simpler solution is possible than POLCA: a limited buffer space in front of each QRC. These buffers are also a visual management signal to each QRC, that would like to send jobs in their direction: if the buffer is full, don’t do it!”

Response: Yes, this is much simpler, but actually, this simpler solution would only work for rather linear flows and within small factories, as I now explain. On the first point, suppose Cell F has 5 upstream cells that could be feeding it with jobs, and suppose that the buffer space that you describe in front of Cell F is now full. Then 5 cells will be watching this space to see when it opens up, and who gets to use it? You can imagine a (comical) situation where, as the space opens up, 5 forklift trucks all race towards the open space to see who gets to it first! In contrast, in POLCA, when the next job is completed at Cell F, only one of the upstream cells will get a POLCA card. Hence the green light to send a job is clearly communicated to one cell only. The second point is that if the upstream cells are spread out over a large factory, then there is no clear visibility about whether the buffer is full or not, and someone from each upstream cell will need to keep traveling a long distance to check each time if they can send another job. In POLCA this signal is clearly displayed locally on each upstream cell’s POLCA Board.

Reviewer: “A little bias towards the advantages of POLCA.”

Response: I completely acknowledge this bias. But every parent will understand my position… When you have a child that grows to be 20 years old and is now mature with some major accomplishments, you feel very proud of this child, and tend to see all of his/her good points and not anything else.