Bridging the Gap Between Theory and Practice

The scientific literature includes more than fifty years of formal publications on scheduling theory and scheduling algorithms, and hundreds—if not thousands—of algorithms can be found in the collection of leading international journals. And yet, one finds few applications of most of these algorithms in practice. There are many reasons for this practicality gap. Scheduling algorithms presented by scientists are mostly complex, and practitioners prefer solutions that are simple, even if inferior, over-complex and (supposedly) superior solutions from algorithms that they do not understand. It is often costly to implement the complex algorithms. Also, a lot of data is needed by these algorithms, which is not easily available. Furthermore, it is doubtful to what extent the scheduling algorithms actually do come up with good solutions. When proving the optimality of the algorithms, scientists assume that the available data is correct. They also assume that their model does grasp the most important elements of the real system. This is seldom true. Lack of accurate data on processing times, further exacerbated by the variability in processing times needed by different workers, variability in the number of available workers on a given day, and the presence of sequence-based setup times are, amongst other things, issues that are rarely incorporated in scheduling algorithms. Also, most scheduling algorithms schedule around a single class of constrained resource (e.g., only machines), while reality has to cope simultaneously with multiple constrained resources (machines, workers, fixtures, and so on). On top of all this is the real-world fact that the whole environment is itself dynamic, with customer order changes, unexpected “drop-in” orders, and real-time system changes (machine failures, absent workers, rework or scrap, missing parts), which raises doubts about whether a schedule that was calculated earlier can still be considered “optimum” in any reasonable sense.

This appendix helps to explain a significant aspect of how POLCA bridges the gap between theory and practice. POLCA is a transparent and robust planning and control system and has proven its value in practice. The system supports the realization of short lead times in a high-mix, low-volume and custom (HMLVC) environment. POLCA has clear logic and has the robustness to cope with many types of variabilities. The technical abilities of POLCA are one aspect of the practical success of the system. However, we will see here that human issues, furthermore, play a major role in the acceptance of the system by the people in a company.

Need for a Sociotechnical Approach

In practice, there is an overemphasis on the technical aspects of planning and control systems. It is essential to consider human and organizational aspects when specifying and implementing a new planning and control system. The relative failure of many shop floor planning and control systems can be explained, at least partially, in terms of the lack of a true sociotechnical approach to the design and implementation of these systems.

A well-known list of ten sociotechnical factors to be used in the design and implementation of sociotechnical systems is given by Cherns in two articles published in 1976 and 1987 (see “For Further Reading” at the end of this appendix). This set of factors has been used in several studies and provides a handy checklist for the assessment of technical systems to be used in an organizational context. Here we will divide Cherns’ factors into two categories: process-oriented factors and design-oriented factors. Process-oriented factors relate to the process that should be followed in order to gain acceptance of the system by those who will work with the system. Design-oriented factors are important to link the social and the technical needs while working with the system.

In this appendix, we will explain how these factors relate to the activities that occur during the adapting and implementing of POLCA to a specific situation. To illustrate these points in practice, we use the case study of Variass Electronics BV, the Netherlands, where POLCA has been successfully implemented. Variass is a system supplier and EMS (Electronics Manufacturing Services) specialist in electronic and mechatronic high-tech products and systems. The company manufactures a huge variety of customer-specific products. About six years ago, Variass implemented POLCA in its manufacturing department. An ERP system is used to generate manufacturing orders, and then the POLCA card system manages the flow of jobs on the work floor. More details on this case study will follow as we discuss the success factors below.

Process-Oriented Factors for Adapting, Implementing, and Improving a System

Our category of process-oriented factors consists of three out of Cherns’ list of sociotechnical factors that we believe are important in the process of adapting, implementing and improving the application of a system such as POLCA. As indicated in Figure E.1, these factors are (i) compatibility, (ii) transitional organization, and (iii) incompletion.

Figure E.1Three process-oriented sociotechnical success factors and a key characteristic of POLCA for these success factors.

The first factor, compatibility, states that the way in which design is done should be compatible with the design’s objective. It is the objective of POLCA to balance the workload on the shop floor while realizing productivity and due date targets. The system explicitly asks for cooperation from the workers. They have to accept the rules of the system with respect to the flow of jobs between cells. Furthermore, they have to self-organize the work within the cells. Therefore, the self-organization of the workers and the production manager in the POLCA system should be reflected in the process of adapting and implementing POLCA. The sociotechnical success factor of compatibility demands appropriate participation of the workers and the production managers in the adaptation and implementation of POLCA. In the case of Variass, the improvement manager developed a simulation game for the workers and the production manager. Playing this game led to some adaptations of POLCA. (Appendix F describes similar experiences with other organizations using games to help teach and train people about POLCA.)

Since the shop floor area was not too large and cells were quite close to each other, the teams at Variass decided to replace the POLCA Boards at each cell with one board centrally located and accessible to all the cells. They also made a minor modification in the way that cards connect cells, which will be explained in a later section. Figure E.2 shows the central board. There are two main points to note about this board. First, if a row (which represents a cell) has a lot of cards, it means the cell needs work from supplying cells. If there are no cards on a particular row, then the cell has no capacity and supplying cells have to perform operations for other cells. This information on the board helps to make sequencing and dispatching decisions in the cells. Second, the board provides staffing information for each cell, as also shown in Figure E.2. The combination of these pieces of information helps the production manager decide whether to move workers from one cell to another, if needed. The cell teams also helped management to develop rules for the re-assignment of workers to cells in order to cope with such temporal imbalances.

Figure E.2Bulletin board with staffing information along with POLCA cards indicating the need for jobs. The manager is pointing to the number of workers in a particular cell.

By doing the above activities, the adaptation and implementation process of POLCA at Variass has been compatible with the self-organizing element within POLCA. POLCA is a relative simple, but smart, system which can be simulated easily: it does not need computer support. These elements of POLCA further enabled the sociotechnical factor of compatibility.

The success factor of transitional organization requires that those who are responsible for adapting POLCA to the specific situation should also be responsible for the implementation of the system. As explained with many examples in Chapter 5, the design of a POLCA system needs to accommodate many company-specific situations and requires detailed knowledge of the production system. This knowledge exists among people on the shop floor. In the case of Variass, the workers made important design decisions under guidance of the improvement manager. They also implemented the operational details of the system in their areas. This was helped by the fact that implementation activities needed on the shop floor are not complex in the case of POLCA. The improvement manager also communicated with the planning department to create an appropriate connection of POLCA with the planning system of the company. As noted in Chapter 4 and Appendix C, a High-Level MRP (HL/MRP) approach is desirable to support the operation of POLCA. In the case of Variass, this was not problematic: the planning system only had to control the total required capacity. Using the central board as an indicator and the worker reallocation mechanisms as a solution, it was easy to create flexibility on the shop floor to cope with fluctuations in demand.

The sociotechnical factor of incompletion recognizes the fact that systems need to change in the course of time, because of a changing context and/or improvement ideas. There should be room for improvement. POLCA is not a complex system and does not need much computer support. This creates the possibility to change the system easily, if needed. It is, for instance, not complex to add or remove cells. Similarly, it is easy to add or remove cards. Furthermore, the cards themselves provide clear improvement signals, as explained in Chapters 3, 7, and 9.

Design-Oriented Factors to Link the Social and Technical Needs

As mentioned, POLCA is a system that can be easily adapted to a specific situation. Adaptation of POLCA should also obey sociotechnical design factors. Cherns (1976, 1987) present seven design-oriented factors: (i) minimal critical specification, (ii) variance control, (iii) boundary control, (iv) information flow, (v) power and authority, (vi) multi-functionality, and (vii) support congruence. Table E.1 gives a short explanation of these factors, and then we discuss how POLCA relates to each factor.

The success factor of minimal critical specification demands a careful specification of the essential elements of decision support needed by the workers. Only these elements should be dealt with by the system. No more, no less. A planning and control system should not unnecessarily limit the freedom of the workers to take planning and control decisions. In the adaptation of POLCA toward a particular situation, the factor of minimal critical specification needs to play a role. POLCA gives some minimal rules to be obeyed: a limited number of semi-autonomous cells are needed along with load-oriented rules for linking these cells. The production manager at Variass did have experience with another card-based control system called CONWIP (see “For Further Reading,” and Appendix C and H). In his opinion CONWIP as a control mechanism running globally across the entire shop floor gave workers too much freedom (this is explained further in Appendix H). The production manager’s experience with this system was that workers collected and stored jobs in order to keep busy at their preferred machines. There was no collective responsibility. In contrast, he was enthusiastic about POLCA because it served the setting of both local and global accountability. Hence, in this situation POLCA served the sociotechnical factor of minimal critical specification.

In the case of Variass, cells were defined such that the number of different routings was limited, while keeping the within-cell flows controllable by the autonomous teams. The design team experimented in a game situation with POLCA and decided to link the POLCA cards to cells instead of loops. This is an option in case of simple routings and a transparent load situation, and works as follows. Each cell team looks at the rows for all its customer (downstream) cells. If a card is available on a row, it means that particular customer has capacity to receive more work. Then, if the upstream cell decides to work on a job for this customer, it takes the customer cell’s card back to its own cell, completes a job for this customer cell, and when it delivers the job it puts the card back on the row belonging to the customer. The workers adopted the FIFO (First-In-First-Out) dispatching rule, combined with the requirement of an available customer POLCA card. If a customer card is not available, then the next job in the FIFO row is chosen. Imbalance between cells is solved by moving workers. This was an easy way to avoid queues on the work floor. The central board and the row of jobs provide the necessary information for this dispatching rule. This example shows that POLCA can easily be adapted to a particular situation and how the design team searched for minimal critical specification.

The success factor of variance control states that variances should not be exported across unit, departmental, or other organizational boundaries. This means that each organizational level in a production control system should be able to cope with the variances that may arise at that level. In other words, decision-making tasks at each level should reflect the variances that may arise at that level. The concept of POLCA serves the success factor of variance control to a certain extent. POLCA defines clear decision-making tasks connected with the organizational levels. Control at the unit level is the cell control, guided by the availability of cards and Authorization Dates (which typically come from High-Level MRP control). Within the cells, there is room to cope with variances in processing time and some fluctuation in demand. Important for this is the setting of cell lead times. The coordination between cells is accomplished through the part of POLCA that creates pairs of cells with overlapping loops of cards. This is a self-organizing mechanism, able to cope with the varying output of the connected cells. High-level MRP control takes care of loading the production cells. This level is able to cope with variation in the importance of the various jobs. Authorization Dates and lead times are set by the High-Level MRP. The division of responsibilities are clear and offer flexibility to cope with variances at each level without frustrating other levels. In the case of Variass, workers are assigned daily to the various cells based upon the predicted workload. Temporary imbalances are solved by the production manager, who may move workers to other cells.

The success factor of boundary control demands that boundaries should not be drawn so as to impede the sharing of information, knowledge, and learning. In a functional layout of a factory, each specific group of machines has its own characteristics and may make suboptimal decisions with respect to sequencing and dispatching. In a cellular layout, each cell may focus on its own interests and may not be willing to share information and resources. POLCA links the various resources in a company such that all value streams can be processed on one system consisting of connected cells. According to the Quick Response Manufacturing (QRM) philosophy, the focus of POLCA is on reducing lead time. This sole focus on the lead time needed to finish manufacturing jobs reduces suboptimal decisions. As a conclusion: the design of POLCA-connected cells and the sole focus supports the boundary control success factor.

With respect to boundary control, it is interesting to compare the old manufacturing situation of Variass with the current POLCA system. Originally, the company had a functional layout. Each functional group optimized its own performance based on local efficiency metrics. However, there was substantial sub-optimization of the factory as a whole, visible in the buffers between the various processes. Then the company decided to implement Lean. Based on the advice of a consultant, the company implemented a flow line for the high-volume, fast-moving products. Other products, partly needing the same machines, were seen as exceptions. As a result, the lead times of the fast-moving products decreased, but the lead times of the large number of remaining products increased substantially. Boundaries were not correctly drawn. This led the company to investigate other methods and they eventually arrived at POLCA. The company replaced the flow line by a number of cells. Although these cells have mainly a functional character (i.e., not multidisciplinary) the new boundaries, together with the accompanying POLCA coordination system, work well for both fast-moving as well as slow-moving products.

The principle of information flow stresses the need that information for action should be directed first to those whose task it is to act. POLCA keeps all information gathering and processing on the work floor. At Variass, workers and the production manager use the information on the central board for decision-making. There is no intermediate planning manager needed to make assignment decisions and to inform workers.

The success factor of power and authority stresses the importance that workers, who have the responsibility for realizing lead times and shortening throughput times, should be able to deal with supporting means. In the cells used as building blocks of the POLCA system, the workers have complete ownership of their resources and decisions. They get the means and support to improve cell functioning. The workers of various cells are together the owners of the coordination system. They work with the system and are able to make appropriate decisions. This aspect of POLCA is important in comparison to an automated scheduling system, which can only be dealt with by a planner.

The success factor of multi-functionality is important for realizing system robustness. In the cells used with POLCA, workers are cross-trained. This multi-functionality of workers supports mix flexibility and gives the system robustness. Robustness is also realized by POLCA’s card-based coordination system. Decision support tools that can only be used by one employee are not usable if the employee is absent. There are many small companies where the planner literally cannot go on holiday, being the only person able to make appropriate release and dispatching decisions! POLCA simplifies the actions to be performed by the planner. The planner just has to release orders based on the Authorization Date at the Planning Cell. Dispatching is organized on the shop floor, through the cards and POLCA rules. There is no additional software needed. The division of responsibilities and the transparency of the cards support the multi-functionality rule. The system is not dependent on a planning specialist. Hence, POLCA is a robust system.

The success factor of support congruence is related to the context of the system. If workers become responsible for the scheduling and control of their tasks using POLCA, then it is a natural progression that they should also become responsible for other decision-making tasks such as hiring temporary personnel, organizing preventive maintenance, prioritizing improvement projects, and so on. (Chapter 5 gives a practical example of a cell team being authorized to hire temporary workers.) Without support congruence, other systems in the company may frustrate the proper functioning of POLCA. Hence companies implementing POLCA should keep in mind this principle, and, in turn, POLCA helps to reinforce its application.

Conclusion: POLCA Obeys Sociotechnical Success Factors

This appendix has linked POLCA to the accepted sociotechnical success factors of system design and implementation. POLCA has characteristics that support these success factors. POLCA is a transparent system, it doesn’t need advanced tools, it provides a clear division of planning and control responsibilities, and it can easily be adapted to a particular situation. All these factors, together with the system rules and coordination logic of POLCA, explain its success in practice, as can be seen by the numerous case studies in this book.