Continue to Use the POLCA Implementation Team and the POLCA Champion

In Chapter 5 we explained that the POLCA system design and implementation needs to be carried out by a cross-functional team whose composition was described in that chapter, and also that, at the outset, management should designate one of the POLCA Implementation Team members as the POLCA Champion. The role of this person was also explained in Chapter 5. It is important that you continue to use the POLCA Implementation Team and POLCA Champion to support the launch of POLCA.

The first task of this team should be to create a timeline for all the activities needed for the launch, based on the items described in this chapter. The second task should be to establish baseline values for key metrics prior to the POLCA launch. For this, the team should review the goals that were established for the POLCA system (see Chapter 4) and decide how the progress toward these goals could best be measured using both hard data (numbers) and soft data (opinions, possibly based on surveys). Then the team should collect current values for these metrics, so that there is an established baseline against which to compare the progress after POLCA is in place. We will return to the issue of metrics at the end of this chapter with some additional pointers.

As a brief reminder about the responsibilities of the POLCA Champion, a key role is to serve as a central point of contact to whom questions regarding the operation of the POLCA system can be directed. Since the POLCA Implementation Team will consist of many people, it is helpful for everyone in the rest of the organization to know that if they have a question it can be addressed to a specific person, rather than to the team in general. Another important role of the POLCA Champion is to serve as the liaison between the POLCA Implementation Team and upper management. During the steps preceding the launch, as well as during the launch and initial operation of the system, questions may arise that require reevaluating or even rethinking existing policies. Examples are: changes that simplify the POLCA decision-making, such as reassigning a material-handling task to a different person; changing who is authorized to make a particular decision; redesigning how a particular exception is handled; and questions related to workload and staffing policies. When such issues arise, it is helpful to have one person who can be the advocate for the change and bring the issue to upper management for a decision.

If your system design includes some type of Safety Cards (Chapter 6) then the POLCA Implementation Team should also decide who will be in charge of these cards. This could be one person, such as a senior operations manager, or multiple people. For instance, if there are Safety Cards for different product lines or customers, each of the product line managers (or customer managers) could be in charge of their quota of cards.

Conduct Training for Everyone Impacted by the System

While companies understand the need for training prior to implementing a new system, they usually underestimate the extent of training and also don’t involve enough people in the training. It is critical that you train not only the people directly involved in applying POLCA in their jobs, but also many other people who will be or might be affected by the new system. Below, we discuss the people that should be trained, and the various types of training to be conducted.

Training for the Core Group

First, we suggest the types of people that should be involved in the most extensive training and what should be included in the training. You can use this list to stimulate the thinking for your particular situation, and add to it as you see fit. We assume here that the POLCA Implementation Team members went through sufficient POLCA training prior to engaging in the system design. The most obvious next group of people to be trained includes all the operators that are in cells that will be part of POLCA loops. If you are initially implementing POLCA only in a portion of your shop floor, then you also need to train operators that will be in cells that are not on POLCA but will interface with cells that are on POLCA (see Chapter 5). If you have material handlers that are separate from the cell operators, then any such people who would move jobs that are on POLCA, or who would be involved in returning POLCA cards, need to be included as well. Next, you should review all the support personnel. Clearly, the relevant planners, schedulers, supervisors and managers should be included. In particular, if you will start your POLCA Chains with the Planning Cell as recommended in Chapter 5, then all the members of this cell need to be trained. Depending on your operation, you may feel that some customer service representatives need to be included too. Similarly, you should review if people in other parts of the organization might be impacted and should also be included. Finally, it is important to have key senior managers attend the training, so they can understand the need for some of the prerequisites and/or policy changes required for the success of POLCA.

As mentioned, some of these people would have been trained much earlier as part of the POLCA Implementation Team working on designing the POLCA system. However, that team only included a small subset of the people impacted by POLCA, and now you need to be sure to cover a wider swath consisting of the full set of people that will be affected.

For the core group of people mentioned above, you should anticipate a total of two to four days of training over a period of time. The first part of the training should involve both the general concepts of POLCA, and the motivation for implementing it—specifically, why it is needed for your company’s manufacturing environment. The concepts of POLCA should include how it works (similar to Chapter 2) as well as its benefits (Chapter 3) so people can understand why it will be effective for your situation. You may find that it is useful to do some simple physical simulations for people to see how jobs and cards would move through the system. Appendix F has an example of one such game, and Appendix I on “Additional Resources” lists other POLCA games available around the world. You can use some of the simulation games already available, or you can make your own simulation if you feel you want to use your own terminology and manufacturing environment. Chapter 11 describes how the pharmaceutical company Patheon created its own simulation game and how it was used for both senior management and shop floor employees.

While the first part of the training above covers the general concepts of POLCA and how it works, for the next part of the training this core group of people needs to be educated on the procedures that have been designed for your implementation. Essentially this involves covering the specific details that you have decided on, based on the roadmap in Chapter 5, as well as the exception-handling procedures that you have constructed based on Chapter 6. As recommended in Chapter 5, you will find it helpful to create a flowchart that documents the rules and decision points, both for the flow of jobs as well as for cards. The teams might also find it helpful to have all the Decision Time triggers documented in a list for reference on each POLCA Board. Both these items—the flowchart and the list of triggers—are not only useful for the training, but serve as an ongoing reference for everyone throughout the launch and subsequent implementation. They are also valuable for training new employees and temporary workers. Figure 7.1 shows an example of a flowchart. This figure is intended to illustrate the types of details that should be in the chart, so some of the details are there as examples, not as concrete items that you need to copy for your flowchart. For instance, in the diamond box with the question “Do we have Authorized jobs delayed more than two days…” the chosen value of “two days” is just for illustration and you should decide what represents a significant delay in your case. Similarly, you should design the entire flowchart and corresponding details to fit your situation. However, Figure 7.1 can serve as a model for your team in designing your flowchart.

Figure 7.1Example of flowchart to be used for training a cell team (this example assumes the Authorization List is in printed form and is printed once a day).

Finally, prior to the actual launch, companies have found it extremely valuable to have a detailed physical simulation or “walk-through” with some make-believe jobs being carried through the shop floor. For this, you should pick one or more representative routings that will cover the key issues and decision points involved. Create a sample job packet for each such routing. Then the training group should walk through the complete decision logic and physical movements involved with each job packet. You will need to have sample POLCA cards made for these routings. Start with how the Planning Cell will release the job packet along with a POLCA card, and how the material arrives at the first step. Next, go over how the cell team uses the Authorization List and the Decision Time rules. It’s not necessary to perform the manufacturing operations, but talk through what operations will be done at this cell and then walk the packet and material (or make-believe material), along with the appropriate POLCA card to the next cell. Then repeat the process at this next cell. As POLCA cards need to be returned to upstream cells at any of these steps, walk through the procedure for this (based on your decisions as explained in Chapter 5). Repeat this process until the end of the routing, being sure to explain any special procedures required in the last part of the POLCA chain.

It is possible that doing this physical walk-through for one routing will cover all the main points that people need to learn, or else you may feel that you must go over a few different routings to capture other situations. The POLCA Implementation Team should decide this based on the particulars of your system operation.

You will find that this physical simulation will not only help people to see how POLCA will work in your company and be more at ease about using the system, but it will also raise a number of issues that may not have been considered. In fact, it is a good idea for the Implementation Team to do a trial walk-through first, to uncover as many such issues ahead of time, and be more prepared for the walk-through with the larger group. (Tasks such as this should be considered when the Implementation Team is preparing the timeline for the launch.)

Create a Standard Process for Secondary Activities Initiated by Decision Time Rules

When a cell team cannot launch a job based on the Decision Time rules, Step 4 of the rules requires that the team engage in secondary activities instead. As discussed in Chapter 3, this step provides a formal framework for improvement activities such as cross-training, setup reduction, and preventive maintenance, as well as for teams to offer assistance to other cells that are temporarily overloaded. It is best to assist your teams in creating a systematic process that will kick in when it’s time for such secondary activities. Having such a process in place will preempt any bickering among the team members as to how to use this time.

The first step is for a cell team to develop a list of improvement activities that need to be addressed, along with an estimate of time that each activity would take; this list should be updated periodically. The second step is to prioritize this list and, again, these priorities should be revisited periodically. The result of these first two steps is that the team always has an up-to-date list ready to go. The third step is, when the team finds that no jobs can be launched and it has some time on its hands, it should first investigate roughly when it might be able to work on the next job. This can be done by (for instance) checking with a downstream team when a POLCA card might be returned and/or with an upstream team when a job might be completed. This step then gives the team an estimate of how much time is available. One option here is for the team to decide if upstream and downstream will be backed up for a while and if some team members should offer to help out in those cells (and thus help to alleviate the stoppage in their own cell). If the team (or part of the team) decides to engage in improvement activities, the final step is for the team to review its prioritized list along with the preceding time estimate and decide which improvement activity to begin. The result of this approach is that when production is stopped the team immediately has a direction to pursue, and such opportunities are not lost.

If management is concerned about the cell stoppages caused by POLCA and the resulting lower labor utilization metrics, one solution used by companies has been to have the employees record the time that they are working on secondary activities, such as improvement projects or helping in another cell. In the same way that a worker would log time to a specific job, he or she can log their time to another activity. In this way, there is no “idle” time of the employees: either someone is working on a production job, or they are working on a secondary activity. These logs will also give management an idea of the time and efforts spent in improvement activities. In this way management can perceive such times as an investment, rather than a loss of labor productivity.

Schedule Frequent Review Sessions and Management Updates

During the initial phases of the launch, it is beneficial to schedule frequent review sessions by the POLCA Implementation Team. This ensures that team members have already cleared their schedules for these sessions, rather than the POLCA Champion trying to put together an urgent meeting as issues arise. These reviews can be kept short, and are meant to address issues that may have gone unnoticed during the design of the system. For example, during the first few days of the launch, the team could schedule a half-hour meeting at the beginning or end of every day, or both. After a week or so, this could be scaled back to a 15-minute “stand-up meeting” at the beginning of each day, and one longer review meeting towards the end of the week. As the confidence in the implementation increases, a periodic review meeting might be all that is needed for example, once every couple of weeks.

To complement these POLCA Implementation Team meetings, you should also plan for and schedule frequent report-outs to upper management. The purpose is partly to keep management abreast of the progress, but also to pre-empt any surprises for upper management, such as possible short-term degrading of some performance metrics as the bugs are worked out of the implementation. In addition, these sessions can be used to address policy changes that might be needed, as discussed previously. Again, these report-outs can be short but frequent initially, and then scaled back to once a week or once every couple of weeks as the implementation gains traction.

Have a Plan for Rolling Out Adjustments and Corrections

As a follow-up to the points in the previous section, if you decide that some significant changes need to be implemented in your POLCA system, you also need a plan as to how these will be rolled out. For example, suppose you decide to change the way that cards are being returned, or to implement some new loops. How will you communicate the new method to everyone involved?

One way to institutionalize this process is to have a periodic (e.g., once a month) POLCA review meeting involving all the relevant shop floor employees and support functions. While companies may already have monthly meetings for employees, this should not be confused with those; you must earmark a meeting specifically to deal with POLCA matters, and the audience for this meeting might be selected differently in any case. You can use this periodic meeting to communicate and roll out system changes. It is also a good forum to solicit feedback on the system. After the POLCA system has been in place for a while and has matured sufficiently, you can reduce the frequency of this meeting or hold it only as needed when specific situations arise.

Design the Checks That Will Ensure POLCA Discipline Is Followed

Simply describing the POLCA rules to all involved is not enough—you need to ensure that the rules are followed! In case you are wondering why employees might not follow the rules, there are many reasons, and, most of all, remember that we are dealing with people in the system. In factories, a common reason for machine operators to change the recommended sequence of jobs is cherry-picking: choosing an easier job over a more difficult one. Another is ease of changeover. An employee might pick a job that requires minimal or no setup after the job just completed. Other reasons could involve personal schedules. For example, if a job has arrived at a cell but the Decision Time rules don’t allow the cell team to start that job at this moment, employees might decide to work on it anyway because they want to be able to leave early or take some time off on the next day. And so on.

So, the Implementation Team needs to accept that these possibilities exist and think through two important points ahead of the launch. The first is, how will we check if the POLCA rules are being followed? Some companies are small enough that they feel the production manager or supervisors clearly know what is going on. Larger companies have instituted spontaneous audits where some members of the POLCA Implementation Team arrive at a cell and check if all the jobs in process are indeed Authorized and have the right POLCA cards attached to them. (Two types of POLCA audits will be described further in Chapter 9.)

The second point to decide is, if a POLCA rule has been broken, what are the consequences for the employee or the cell team? Again, companies have differed in their handling of this. Smaller companies have taken the softer approach that the errors could be simply due to misunderstanding and have used the occasion to explain and re-train the employee(s). Some larger companies with more wide-ranging employees have taken a harder line, even writing up a complaint about an employee if this is a repeated occurrence.

Regardless of which way you decide to go with these two points, it is important to think them through ahead of time and come up with your answers. This represents yet another reason why it is critical to include some representation from Human Resources (HR) in the POLCA Implementation Team as recommended in Chapter 5, and possibly include the whole HR group in the short overview training session described earlier.

Start Tracking and Debugging Key Metrics

As part of your POLCA launch you must determine the way that you will track key POLCA-related metrics, specifically, metrics that determine your progress toward the goals that were established for your POLCA implementation (Chapter 4). The core set of metrics that you should measure include WIP inventories, finished-goods inventories (if relevant to your type of manufacturing), lead times (you could use the MCT metric described in Appendix A, if your management has bought into this metric), total system throughput, and on-time delivery performance. Additional metrics should be designed to meet other goals that were set at the start. For example, if you felt that the tighter WIP control and communication between the cells would help to improve quality, then quality-related measures could be added into the basket of metrics.

There is an important issue to consider when implementing a lead time metric while using the POLCA system: lead time needs to be computed differently for individual cell teams versus for the POLCA system as a whole. The reason is, you need to correctly attribute the components of lead time for which a cell team or the POLCA system should be held responsible.

Let’s start by considering this issue for a cell team. You want to make sure that the lead time (or MCT) metric for this cell only contains portions of time that the cell team is truly responsible for, and is able to impact with its actions. To understand the issue here, remember that when a job arrives at a cell the Decision Time rules could prevent the job from being launched. Therefore, the cell should not be penalized for the segment of time that the job is waiting due to POLCA rules.

However, in measuring the performance of the POLCA system as a whole, our metric would be designed differently. If a job has to wait at a cell because it is not yet Authorized or the right POLCA card is not available, then this is due to the operation of the POLCA system, and this waiting time should be included in the lead time metric. Once again, though, we need to be careful not to penalize the POLCA system for items that are outside the scope of the POLCA implementation.

Let’s take lead time (or MCT) for a particular POLCA Chain as an example. We pick a given POLCA Chain because it makes sense to separate out the lead times for different routings—if you want to carefully track performance patterns then you don’t want to mix the data for short and simple jobs with long, complex ones. So, for a given POLCA Chain the lead time clock for a job should only start ticking when both these conditions are satisfied: the job is Authorized at the first cell in the chain, and the material for this job is available. Clearly, if the material is not available at the first cell, this is an issue that is outside the POLCA system, and the lead time clock for this POLCA Chain should not start. However, the clock can start ticking regardless of the availability of a POLCA card! If the right POLCA card is not available and the job has to wait, this waiting time is definitely part of the POLCA system’s design and operation, so it should be included in the lead time metric.

Another example is when there is a component part shortage and a Safety Card needs to be deployed. The job is delayed, but this delay should not be attributed to the cell nor to the POLCA system; the delay should be recorded in a separate category. If you have other such situations, you should use the preceding discussions as examples to help you decide whether to include, or not include, segments of lead time for a cell team or for a POLCA Chain.

Similarly, on-time delivery performance for the POLCA system should be measured at the end of the POLCA Chain, not at the shipping point. In order to fairly judge the POLCA system based on this data, you will need to compensate for whether material arrived at the first cell on time. You don’t want POLCA to take the blame if the first cell didn’t receive its material until much later than planned!

The preceding discussions highlight the point that you should think through some of your traditional metrics before applying them to measure the performance of POLCA. You want to make sure that you are fairly measuring the POLCA system, not coloring the data with problems that are outside the scope of POLCA. As you start implementing the metrics, shop floor employees may point out other situations that require adjusting the metrics; this is part of the debugging mentioned in the title to this section.

This chapter concludes the sections on designing and launching your POLCA system. If this and the preceding chapters appear somewhat daunting, in actual fact some of these steps and decisions can occur very quickly. The next chapter describes an inspiring case study where a company designed and launched POLCA in three days!