Management and Improvement of In-Use Token-Based
Systems: A Comparative Case Study
Master Thesis
Carlijn Bontjer (S2813858/ B5064564)
MSc. DD TOM/SCM
University of Groningen Newcastle University
Faculty of Economics and Business Business School
Supervisor University of Groningen: Nick Ziengs MSc. Supervisor Newcastle University: Dr. Graeme Heron
Abstract
Purpose – Card-based production planning and control systems, also called token-based
systems, are widely used in Lean initiatives to control work-in-process. The current business environment is characterized as dynamic and challenging for small and medium-sized enterprises. Due to the dynamics, the variety continuously pressures the token-based system. To maintain or improve its performance it is important to manage the token-based system. This research aims to identify what factors drive a change and how to handle these.
Methodology – By conducting a multiple cases study, this research seeks to answer the
research question by giving practical insights and enlarging the theoretical body of knowledge concerning token-based systems. The case study included nine companies which provided ten cases. Semi-structured interviews were conducted in order to collect a wide range of rich data to answer the research question.
Findings – All the companies perceive different types of variability. Only minor changes are
made to the token-based system. The variability is not captured by adapting the token-based system but by using other techniques. These techniques are the flexible capacity on a day-to-day base and load redistribution at the order release and dispatching. As a result, the final maturity of token-based is not desired by practitioners.
Research limitations/implications – Only small and medium-sized enterprises were included
in this study, which limits the generalizability to other firms. This research provides a maturity model which can be used to assess the token-based system and to suggest modifications to the token-based system to better serve the company’s performance.
Keywords – Production planning and control, pull production, token-based production
Preface
This study is performed to finish my Dual Master Degree program in Operations Management at the University of Groningen and the Newcastle University Business School. The journey has been challenging but also rewarding.
I would like to express my gratitude to my supervisors N. Ziengs and G. Heron for their feedback which significantly improved the quality of this study but also to keep confidence in myself. Furthermore, I would like to thank Martijn Biesheuvel for his contribution regarding the data collection required to perform this study.
Of course, this study would not have been possible without the input from the industry. Therefore, I would like to thank the companies who participate in this research. Without these companies, this research could not have been performed.
Finally, I will express my profound gratitude to my family and friends for providing me with support and continuous encouragement throughout my years of study. This accomplishment would not have been possible without them. Thank you.
I hope that you will enjoy reading this dissertation and that it will give insight into the management and improvement of token-based systems.
Groningen, December 2016
Table of Contents
1 Introduction ... 1
2 Theoretical Background ... 4
2.1 Production planning and control ...4
2.2 Decisions within Production planning and control ...5
2.3 Token-based systems...8
2.4 Design of token-based systems ...11
2.4.1 Structure ...11
2.4.2 Configuration ...13
2.5 Management of the token-based system ...17
2.6 Maturity model ...19 3 Method ... 22 3.1 Research design ...22 3.2 Case selection ...22 3.3 Data collection...23 3.4 Data analysis ...25 3.5 Quality criteria...25 3.6 Overview of cases ...26 4 Findings... 28 4.1 Within-case analysis ...28 4.1.1 Company A ...28 4.1.2 Company B ...29 4.1.3 Company C ...31 4.1.4 Company D ...32 4.1.5 Company E...33 4.1.6 Company F ...34 4.1.7 Company G ...35 4.1.8 Company H ...36 4.1.9 Company I ...36 4.2 Cross-case analysis ...38
4.2.1 Adaptions to the token-based system ...39
4.2.2 Flexible capacity ...40
4.2.3 Load redistribution ...41
4.2.4 Usage of Kanban on the shop floor...41
4.2.5 Discipline ...43
5 Discussion ... 45
5.1 The factors influencing decisions regarding of in-use token-based system ...45
5.2 The management of variability using an in-use token-based system ...48
5.3 Managerial implications ...49
5.4 Research implications ...49
5.5 Limitations and future research ...50
6 Conclusion ... 52
7 References ... 54
List of Figures
Figure 2.1 Decision moments within the production planning and control ... 6
Figure 2.2 Overview Token-based systems ... 10
Figure 2.3 Overview Production Planning & Control ... 11
Figure 2.4 General overview design considerations structure of a token-based system... 16
Figure 2.5 General overview considerations configuration of a token-based system ... 16
Figure 2.6 Variability aspects within a company... 18
Figure 2.7 Maturity model ... 20
Figure 3.1 Process/Product matrix with the position of the case companies ... 27
Figure 4.1 Consideration to capture variability ... 43
Figure 4.2 Generic Framework for dealing with variabilities... 44
List of Tables
Table 2.1 A classification of priority rules with order dispatching (adopted of Land (2004)) .. 8Table 2.2 Decision in the PPC strategy discussed in token-based systems ... 10
Table 2.3 Design considerations of structure ... 12
Table 3.1 Overview of the case company characteristics ... 27
Table 4.1 A summary of the case studies ... 38
List of Abbreviations
ATO Assemble to order
CR Critical ratio
COBACABANA Control of balance through card-based navigation
CONWIP Constant work in progress
COPD Customer order decoupling point
EDD Earliest due date
ERP Enterprise resource planning
ETO Engineer to order
FCFS First come first serve
JIT Just in time
LOR Least operations remaining
MRP Material requirement planning
MTO Make to order
MTS Make to stock
OA Order acceptance
OD Order dispatching
ODD Operations due dates
OR Order release
POLCA Paired-cell overlapping loop of cards with authorization
PPC Production Planning and Control
SME Small and medium-sized enterprises
S/OPN Slack per remaining operations
SPT Shortest processing time
TBS Token-based system
WIP Work in progress
WINQ Work in next queue
WLB Workload balancing
1 Introduction
Lean manufacturing is one of the proven methods in the field of operations management which can increase productivity and decrease lead time of a firm (Powell et al. 2013; Azian et al. 2013; Hopp & Spearman 2004). Large companies seem to have embraced manufacturing best practices such as Lean, while this is not the case for small and medium-sized enterprises (SMEs) (Powell et al. 2013). Card-based production planning and control systems, also called token-based systems, are widely used in lean initiatives (Hopp & Spearman 2004) and provide a mechanism to control work in progress (WIP) (González-R et al. 2012). The underlying principle is; new work can only enter the shop floor if other work leaves the shop floor, e.g. maintaining a so-called WIP-Cap (Thürer, Stevenson & Protzman 2016). This principle can be controlled through cards or tokens. In general, an available card signals free capacity of the work cell downstream. When a card is available, it will be attached to an order, which authorizes the order to be processed to the next workstation downstream (Ziengs et al. 2012). When this workstation finishes that order, the attached card will be sent back to allow additional work to enter.
Since the inception of these systems, a large variety of card-based systems has been proposed that are appropriate for a variety of business environments (González-R et al. 2012). Examples of these token-based production systems are Kanban (Sugimori et al. 1977), CONWIP (Spearman et al. 1990), POLCA (Suri 1998), and COBACABANA (Land 2009). Although a large body of work addresses the implementation and design of these card-based systems, relatively few of these papers empirically investigates how to manage or improve these systems in the light of changing circumstances (Soepenberg et al. 2012). Even though Tardif and Maaseidvaag (2001) experienced that many companies periodically redesign their token-based system to match current operating conditions. The goal of this paper is twofold; first goal is the identification of how these token-based systems are managed and second goal focusses on how improvements or adaptions of these systems are handled.
practitioners (Thürer et al. 2014; González-R & Framinan 2009) because they require special expertise which can be too expensive for SMEs (Gaury 2000; Alfieri & Matta 2012). Furthermore, practitioners prefer simpler ways of organizing production planning and control (PPC) (Muda & Hendry 2002).
Nevertheless, the insight of these studies is of particular relevant to SMEs because they face a continuously and fast changing environment on which they have to anticipate. Examples of changing circumstances in the environment are the drive for faster deliveries, customized products, and better quality at lower costs. This leads to less volume and more diverse demand. This is vital for companies because pull systems, especially older ones, are built for high volume and low diversity (Sugimori et al. 1977). For example, Kanban was created to fulfil specific needs of Toyota, i.e. to work effectively under specific production and market conditions (Lage Junior & Godinho Filho 2010). More specifically, most SMEs must deal with a greater degree of uncertainty and variability compared to large companies and multinationals (Bell 2005). This high degree of variability indeed influences the performance of in-use token-based systems because the conditions does not hold anymore where the token-token-based systems were proposed (Chang & Yih 1994; Lage Junior & Godinho Filho 2010). Practitioners stress the important of increasing the robustness of token-based systems (Kleijnen & Gaury 2003). It is assumed that the in-use token-based system needs to be carefully managed (Gaury et al. 2000). When required, the token-based system should be improved to keep the fit between environment and production systems. Also, other modifications or mechanisms are possible in the field of PPC to maintain the initial conditions of the initially implemented token-based system. Furthermore the literature on the management of token-based systems, on when, which and to which magnitude to change the systems are underexposed (Soepenberg et al. 2012; Kotani 2007). Therefore, the following research question is defined:
Which factors influence the decisions to adjust the in-use token-based production system and how are these adjustments handled?
planning and control strategies and to evaluate them on the performance of such systems. Therefore, classification of systems based on literature will facilitate the identification of factors. First, the design considerations are studied and second, the management and improvement aspects are considered. Besides an extensive literature review, a multiple case study will be held in order to identify factors influencing the token-based system which are not found in literature. Based on these factors, the aim is to develop insights which assist practitioners with management and improvement of their token-based systems through the development of a maturity model. Moreover, the maturity model can be used to assess the extent to which a token-based system is flexible to capture variability perceived from its environment and to suggests adaptions in order to obtain better performance.
2 Theoretical Background
2.1 Production planning and control
PPC systems are crucial tools for firms in this continually changing business environment (Stevenson et al. 2005). PPC systems encompass functions such as planning material requirements, demand management, capacity planning and the scheduling and sequencing of jobs (Stevenson et al. 2005). PPC systems differ per company. Within the field of PPC, we can distinguish between three different types of control policies, namely token-based, time-based and surplus-base (Gershwin 2000). Token-based systems are defined as follows: “the movement of tokens in the manufacturing system to trigger events” (Gershwin 2000, p.892). Examples are Kanban (Sugimori et al. 1977) or CONWIP (Spearman et al. 1990) as both fit the definition. Time-based control systems process orders in a workstation on a time-basis consideration with a fixed interval, e.g. priority rules. An example of a time-based control system is the Material Requirements Planning (MRP) (Hopp & Spearman 2008). A surplus-based system is defined as: ”a system wherein decisions are made on the basis of how far cumulative production is ahead of, or behind, cumulative demand” (Gershwin 2000, p.891). An example of a surplus-based system is to have a hedging point or base stock policy on surplus and backlog (Gershwin 2000).
Within PPC strategies two major streams can be identified; pull and push production systems. Pull production is defined as: “A system that explicitly limits the amount of WIP that can be in the system” (Hopp & Spearman, 2004, p.142). This definition implies that a push production system does not explicitly limit the amount of WIP within the system (Hopp & Spearman 2004). An example of a push system is the MRP since releases are made according to the master production schedule without consultation of the system’s status (Hopp & Spearman 2004). Implementation of pull control might be achieved by using cards or tokens (Deleersnyder et al. 1989).
transport and products, with their processing requirements and demand patterns must be considered (Deleersnyder et al. 1989). Secondly, the flow line loading problem involves the allocation of a possible amount of work to each flow line in a period of time to prevent the occurrence of bottlenecks. Lastly, the operational control problem is related towards an implementation of the Kanban system where the optimal number of Kanban cards should be determined, and this depends on stochastic machine reliability and stochastic demand (Deleersnyder et al. 1989).
After successful implementation of a token-based system the next challenge is to manage and when necessary, adapt or improve the in-use token-based system. The literature on the management of token-based systems, on when, which and to which magnitude to change the systems are underexposed (Soepenberg et al. 2012). Besides SMEs face a continuously and fast changing environment on which they have to anticipate. Therefore, it is self-evident that the PPC also have to anticipate on the changing conditions. This also holds for the in-use token-based system. Besides, several studies confirmed that the environment influences the performance of a token-based system which increases the importance of an adequate management of these token-based systems (Prakash & Chin 2014; Gupta et al. 1999).
2.2 Decisions within Production planning and control
Figure 2.1 Decision moments within the production planning and control Order acceptance
Order acceptance is defined as the order is accepted and the corresponding due date is specified (Breithaupt et al. 2002), this is the case for make-to-order companies. Another possibility is that an order is discarded. The policies regarding order acceptance are essentially linked to due dates when an order is accepted. These policies can be divided into exogenous and endogenous acceptance (Land 2004). Endogenous acceptance can be either job or shop floor related. For instance, job related acceptance can be based on the processing times of the routing (Land 2004). Shop floor is related to the number of jobs on the shop floor, number of jobs in queues on routing and the processing times on routing (Land 2004). Examples of exogenous policies are based on the uniform processing time which is set by management. An example of an endogenous policy is the acceptance of an order which is based on the routing of the job in the shop, which estimates the throughput time. With this information, the due date can be determined and it is known when the order can be released. These due date policies show a strong interaction with other PPC policies (Kingsman & Hendry 2002; Stevenson et al. 2005).
the shop floor. Therefore the planner might consider changing the size of the release card and or acceptance card (Thürer, Land, et al. 2016).
Order release
The order release is the mechanism that allows a job to enter the shop floor. Therefore it is an instrument used to control the input of orders to the shop floor (Land 2004; Thürer et al. 2014). Orders do not enter the shop floor immediately when they are received from the customer, they are retained in the pre-shop pool and are released in accordance with certain performance targets (Thürer et al. 2014). The elementary mechanisms for the order release are: setting an external production pace by controlling the raw part arrival process, authorizing releases based on WIP in all parts of the system, and releasing new parts in response to actual demand or forecasts of demand (MacGregor Smith & Tan 2013). Release methods can be based on infinite loading methods and finite loading methods (Sabuncuoglu & Karapinar 2000; Land 2004; Wisner 1995). Infinite loading methods do not have a restriction regarding the quantity released into the system, i.e. push systems. On the other hand, when there is a limitation it means that a finite loading method is used, i.e. pull systems. For the infinite loading methods, the control of the order is transferred to the order dispatching decision. In order to apply a finite loading method, a token-based solution is often adopted in practice to coordinate the routing of orders between work cells (Thürer et al. 2014). Finite loading methods can be divided into two main subclasses: load-limiting methods and methods that balance the loads across stations over time (Land 2004; Yan et al. 2016). Load-limiting methods restrict the number of orders on the shop floor to a maximum and load balancing methods will sequence the orders for release with the focus on the stations with lower utilization (Land 2004).
Order dispatching
Order dispatching is the decision when an order should be processed to the next workstation after the operation of another order has been finished (Land 2004). An extensive amount of literature discusses the priority rules which can be applied (Panwalker et al. 1977; Blackstone et al. 1982). Different order dispatching rules have different aims; these are mainly to conserve flow, improving throughput or reduce lateness dispersion (Land 2004). Land (2004) gives a classification of dispatching rules based on these different strategies which are provided in the table below.
Table 2.1 A classification of priority rules with order dispatching (adopted of Land (2004))
Conserving flow Improving throughput Reducing lateness dispersion - Arrival sequence
FCFS ( First-Come-First-Served)
- Processing characteristics SPT (Shortest Processing Time), LOR (Least Operations Remaining). - Workload balance WINQ
(Work-in-Next-Queue)
- Due date and slack EDD (Earliest Due Date), ODD (Operations due dates), S/OPN (Slack Per Remaining Operation), CR (Critical ratio)
2.3 Token-based systems
Token-based systems are an important class of real-time manufacturing scheduling systems (Gershwin 2000) and they are widely applied in the production environment. Token-based systems are used to control order release and order dispatching. Many articles have been published addressing new types of token-based systems over the last 35 years (González-R et al. 2012). Kanban is one of the most well-known token-based systems developed. Kanban is a simple form of communication on the shop floor that indicates when products are needed (Ohno 1988). Kanban can fulfil different purposes depending on the type of cards used. One type is production Kanban, which is used to authorize the production of a certain work cell. Another type is supplier Kanban, which communicates with the supplier that there is a requirement of components (Powell et al. 2013). A different kind is a transportation or move Kanban card. This card authorizes the movement of the components attached to card, e.g. from the central warehouse to the shop floor (Gupta et al. 1999).
Matta 2012). Examples are Generalized Kanban (Buzacott & Shanthikumar 1993) and extended Kanban (Dallery & Liberopoulos 2000). After the development of Kanban, CONWIP is initiated which should overcome the drawback that Kanban is only suitable in a repetitive environment (Spearman et al. 1990). Another example is POLCA which is appropriate in an environment with high variety and low volume, where the application of CONWIP is limited (Suri 1998).
Still, problems are explored within the literature of token-based systems. However, they have received different answers (González-R et al. 2012). Framinan et al. (2003) concluded that no token-based system outperforms the other under all possible environments. Therefore, it is even more difficult for practitioners to choose the right system for their environment and its characteristics. Examples of difficulties are the role of tokens, their locations, how they are managed and their configuration (González-R et al. 2012) which is closely related to the problem areas defined by Deleersnyder et al. (1989).
Figure 2.2 Overview Token-based systems
Note that dispatching can also be done by the structure and configuration of the token-based system which resembles the first mechanism. The second mechanism can be the dispatching rules or priority rules. Table 2.2 indicates several decisions and if these decisions are taken into consideration for the different types of token-based systems.
Table 2.2 Decision in the PPC strategy discussed in token-based systems
Order acceptance Order release Order dispatching
Kanban X X
POLCA X X
CONWIP X
COBACABANA X X
2.4 Design of token-based systems
Different types of token-based systems and their characteristics are described in Section 2.3. A variety of different token-based systems can be designed to suit certain characteristics of a production environment (Thürer, Land, et al. 2016). This section will describe the most logical choices made for a token-based system based on literature. Figure 2.3 gives an overview of the various decision.
Figure 2.3 Overview Production Planning & Control 2.4.1 Structure
WIP. Gaury (2000) identified empirically that only less than half of the initial loops is usually necessary to implement. The control loops result in whether the token-based system is characterized as a traditional, segmented or joint system (Gaury 2000). Joint systems are considered when a manufacturing environmental problem cannot be solved by CONWIP alone, and therefore Kanban can be used additionality for example (Prakash & Chin 2014).
When designing and implementing the control loops, the first two problems of identifying the flow lines and the flow line loading problem previously described should be overcome (Deleersnyder et al. 1989). When designing the control loop(s), there are several options to choose. The table below gives the options related to route and product control.
Table 2.3 Design considerations of structure
Product specific Product anonymous
Route-specific Kanban POLCA
M-CONWIP
Non-route-specific CONWIP
Generic Kanban
irrespective of the type of order. Product anonymous signals are found in CONWIP (Spearman et al. 1990) and generic Kanban (Chang & Yih 1994). These token-based systems are non-route-specific.
Based on the vast amount of literature described above, it is possible to provide argumentation for choosing certain options. The decision related to route-specific or non-route-specific control is related to variability. When the majority of the products have the same routing through the shop floor, and product variety is low, it is suggested to opt for product specific and non-route-specific control loops. When product variety is high but the routing variability is low, it is logic to choose for a product anonymous and route-specific control loop. However, this barely occurs due to low product variety and it is assumed that routing variability is as well low. Furthermore, having a high variety in routing and a high variety of products, it is recommended to opt for a route-specific and product anonymous control.
Secondly, the loops are either overlapping or non-overlapping. When the routing variability is relatively high, it is advised to opt for route-specific control as mentioned previously. However, it can be the case that route-specific control cannot fully capture the variability, therefore it might be an option to use overlapping loops to capture that additional variability (Thürer, Stevenson & Protzman 2016). Overlapping control loops result in improved signalling capability of the capacity in the subsequent parts of the routing (Suri 1998; Riezebos 2010). However, note that this is not possible when having undirected routing (Thürer, Stevenson & Protzman 2016). Thirdly, a choice has to be made whether to use centralized or decentralized control of the control loop(s) or a combination of both. Central control is favourable when there are unstable changes in demand (Lage Junior & Godinho Filho 2010). Decentral control is preferred to limit the built-up of WIP between the stations. However, when the routing variability is high, centralized control loops are preferred since decentralized control loops might result in a blocking mechanism (Lödding et al. 2003).
2.4.2 Configuration
of the system in which literature indicates that there is a lack of knowledge, e.g. Soepenberg et al. ( 2012). There are four choices which have to be made to complete the configuration of the system. These are discussed below.
First, what kind of authorization they hold, namely production or withdraw cards. The authorization can be related to the start of production or related to a new order to be placed at the supplier, namely a withdraw. This is related to the placement of the control loop, e.g. structure (González-R et al. 2012). The type of authorization a card has depends on where the control loop is placed. When the control loop is placed between two stations, the card will authorize production. When the loop is placed from the workstation to the central warehouse, to control the supply of components, the authorization is related to moving or transportation. Finally, when the loop is used to control the orders placed at the supplier, a card represents an ordering card.
Second, the cards are either product specific or product anonymous. This was previously mentioned in the structure section. This choice of product specific or product anonymous cards is related to the product variety of the firm. When there is a high product variety, it is advised to use product anonymous cards and vice versa (Ziengs et al. 2012; Prakash & Chin 2014). When there is a high product variety, and cards are product specific, the WIP can rise to uncontrollable levels. This situation is not desirable and does not suit the original objectives of a token-based system. Product anonymous cards attain a higher service level when there is high product variety (Prakash & Chin 2014).
Third, to choose if the card either represents a unit or the load which makes the cards either unit-based or load-based. Load-based cards do take the processing time requirements of orders into consideration (Ziengs et al. 2012), where this is not the case for unit-based cards. Load-based systems are more accurate regarding processing time. These load-Load-based cards are favourable when there is a high processing time variability (Vandaele et al. 2008). Processing time variability is often perceived in MTO companies due to the variety of products. However, these companies use unit-based cards due to the increase complexity using load-based cards (Ziengs et al. 2012).
complexity increases (Akturk & Erhun 1999). Another advantage of a single-card is that shorter information lead times are achieved compared to dual-card. However, when there is a significant physical distance that card has to be transported, a dual-card can be advised (Akturk & Erhun 1999).
Finally, the decision is related to the method of management which can be either card setting or card controlling. Here a choice has to be made to have a time interval to recheck the cards or do this real-time continuously. There is an option to adapt the number of cards based on environmental changes which can be either internal or external. Several papers indicated that with card controlling higher performance is attained (Hopp & Roof 1998; Tardif & Maaseidvaag 2001). Hopp and Roof (1998) propose a procedure for increasing or decreasing the number of cards in a MTO CONWIP system based on the discrepancy of the mean and standard deviation of inter-output times and a target throughput. In contracts, Tardif and Maaseidvaag (2001) proposed a procedure for a MTS CONWIP system which uses extra cards when the inventory level falls under a release threshold. Card setting means that the cards in the system are fixed during the decision interval (Framinan et al. 2006). When there is low inter-arrival time variability and/or due date allowance, it is more straightforward to use card setting. When the external variability increases and the system is out of control, card controlling is preferable. To conclude, an overview of these different choices related to structure and configuration is given in Figure 2.3
possible to change the entire token-based system to maintain the fit with the operating and environmental conditions.
Figure 2.4 General overview design considerations structure of a token-based system
Figure 2.5 General overview considerations configuration of a token-based system
2.5 Management of the token-based system
Kanban is one of the methodologies of a pull strategy to implement JIT manufacturing (Spearman & Zazanis 1992). JIT is designed for stable and predictable environments such as constant processing times and smooth and stable demand (Gupta et al. 1999). Gupta et al. (1999, p.1066) state: “once implemented, JIT is fraught with numerous types of uncertainties such as processing time and demand variations, breakdowns and other type of planned or unplanned interruptions”. Therefore, it is important to manage the in-use token-based system to maintain the benefits in which they were initially implemented for (Riezebos 2013).
González et al. (2006) mentioned that there should be a fit between the environment and the token-based system. To meet current demand trends, companies redesign the configuration of their token-based system periodically, e.g. by increasing or reducing the number of cards in a control loops (Tardif & Maaseidvaag 2001). Some of the environmental and production setting factors that pressure the token-based system are identified by Gupta et al. (1999). An example of variability is demand variability, the number of Kanbans should be adapted which resulted in no backlog and lower order completion time, and a slight increase in WIP and time system compared to the original implemented Kanban system (Gupta et al. 1999). When the number of cards is not adapted towards a change in demand, the system might fail, e.g. resulting in a surplus or shortage of material. Both result in additional costs which could be avoided with accurately management of the quantity of Kanbans.
2007). This widely held view contrasts with the opinion held by Vandaele ( 2008) who developed load-based POLCA. Load-based POLCA determines the release authorization according to a real-time system and enable high optimization level of the manufacturing lot sizes. Since the introduction of electronic authorization signals, it becomes easier to change the structure and configuration of an in-use token-based system.
Thürer et al. (2016) claim that environmental variability has a huge effect on which type of token-based system a company should opt for. Variability faced by a company can be separated into two main categories, namely process and demand variability (Lu et al. 2011). Process variability comes from inside the factory, namely the production process. Demand variability is the variability perceived by customers. Henrich et al. ( 2004) refer to the variabilities evolving from a single order. An order contains technical and non-technical characteristics. Technical characteristics relate to routing and process variability, i.e. internal variabilities. Non-technical characteristics contain arrival and due date, i.e. external variabilities. The variabilities are visualized in Figure 2.6.
Figure 2.6 Variability aspects within a company
After identifying a drive for change in either the structure of the configuration of the based production system the following questions may arise; When to change the in-use token-based system? Which part of the token-token-based system to change? And to which magnitude to change the token-based system, only configuration or also structure? These questions are not addressed in the literature yet (Li 2013). To illustrate, observing inventory level as a means of an indication when to adjust the number of Kanbans might not give an immediate indication of when the system is undergoing instabilities or to respond to it (Li 2013). However, this background section presents a framework (Figure 2.4 & Figure 2.5) which can serve as a guide to the management of an in-use token-based system.
2.6 Maturity model
In order to assess the implementation of a token-based system for pull production, a maturity model is conceptualized. The aim of a maturity model is to benchmark the maturity of a company’s operations to best practice (Netland & Alfnes 2011). The proposed maturity model is based on the refinements proposed in the literature for token-based systems which are described in the previous sections. These refinements focus on the level of variability which is captured through the token-based system. The five levels of this maturity model define an ordinal scale for assessing the level of customized token-based system to support pull production even with variability. Each maturity level represents an evolutionary plateau on the path towards a fully customized based system with a periodical review of the token-based system and captures the perceived variability. This maturity model is presented in Figure 2.7.
Characteristics of the five identified levels of maturity are described below:
Level 1 –All the maturity models’ level 1 uses “initial”, which is maintained. As a result, level 1 suggests that a company does not use token-based production system, but there might be some considerations implementing a token-based system.
(Akturk & Erhun 1999). This implementation of this token-based system is not heavily subjected to variety and does not influence the order release and dispatching decision.
Figure 2.7 Maturity model
Level 3 – labelled as “decentral control” refers to the implementation of a token-based system in the main production line. At this level, several control loops might be implemented with the focus on the routing through the shop floor. This routing variability is captured through either choosing route-specific or non-route-specific control depending on the flow variety (Ziengs et al. 2012). But also using overlapping control loops might capture the routing variability (Riezebos 2010). At this level, the token-based system controls the order dispatching. Other variabilities might be perceived by neglected by the implemented token-based system.
Level 5 – the top level of this maturity model is called “full control”. The token-based system truly captures variabilities. As a result, there is a focus on card controlling and on processing time variability. The processing time variability can be captured through the use of load-based cards instead of unit-based cards (Hopp et al. 2012; Vandaele et al. 2008). The order release and dispatching decisions are both controlled through the token-based system.
The proposed maturity model shows various types of token-based system implementation and managing different parts to control production even though it is subjected to variability. The most mature level indicates that the implemented token-based system can capture variability. This is not the case for the lower levels of maturity. The lower levels of mature of a token-based system do not mean that these are not subject to many variability, but the variability might be captured through other mechanisms such as workload control (WLC) (Stevenson 2006) or using the priority rule of shortest processing time (SPT) at the order release (Land 2004). This will lead to micromanagement on the shop floor. The final maturity level means that the variability is captured through the token-based system which is implemented according the suggestions proposed in the literature.
3 Method
3.1 Research design
This research constitutes a qualitative approach providing knowledge regarding the management and improvement of in-use token-based systems. A case study is the most relevant type of research when ‘how’, ‘what’ or ‘why’ questions are addressed (Yin 2009). The research question in this thesis is a ‘how’ and ‘why’-type of question because of the interested in the management of in-use token-based systems. Yin (1981, p.59) defines a case study as: “An empirical inquiry that investigates in a contemporary phenomenon in-depth and within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident.” This makes the research explorative since the aim is to generate new theory regarding the in-use token-based systems (Bengtsson 1999).
The multiple case study method is considered to be the most suitable for exploratory research (Yin 1981). This research is explorative because of the aim to increase the knowledge concerning in-use token-based system, e.g. building theory. A case study has the preference since the focus is on discovering factors that influence the usage of the token-based systems which includes multiple variables, e.g. MTO, MTS, job shop or flow shop. These factors are important for practitioners to maintain the performance of the in-use token-based systems even though the conditions of the environment might change. Furthermore, the focus is also on the different factors driving an adaption of the token-based system which might be discovered and are not found in literature before. This makes standard experimental and survey design less suitable (Yin 1981). The multiple case studies’ conclusions are more robust compared to a single case study because it allows for comparison that clarifies whether an evolving result is purely idiosyncratic to a single case or steadily replicated by some cases (Yin 2009; Eisenhardt 1989). Secondly, a multiple case study makes the research findings more generalizable (Eisenhardt & Graebner 2007). Thirdly, multiple case study enables broader exploration of research questions and theoretical elaboration (Eisenhardt & Graebner 2007). As a result, when certain important factors evolve concerning in-use token-based systems, these can be included in the research.
3.2 Case selection
analysis is the in-use token-based system with the emphasis on the factors that influence the management and the improvement of these systems within the SMEs. SMEs are identified, following the European Union definition (2000), as companies who are legally independent with no more than 500 employees. The cases are selected based upon the usage of token-based systems. In other words, when the production is pulled and the firm uses tokens as triggering mechanisms, it is identified as a token-based system (Hopp et al. 2012).
The cases are selected based on replication logic since the aim is to build a theory (Voss 2009). Replication logic is used to find differences in the variabilities, methods, and how these variabilities are handled depending on the maturity of the token-based system implemented. Eisenhardt (1989, p.15) suggested that in in the field of multiple case study research, the range of four to ten cases “usually works well". A study about case research design indicates that more than 40% of the researched papers are in line with the ideal number suggested by Eisenhardt (Barratt et al. 2011). Articles that used over ten cases had the overall aim to derive to a framework/proposition rather than purely providing descriptive insights (Barratt et al. 2011). Since the objective of this research is also to propose a framework, ten cases are chosen. Saturation is also considered, meaning that if a new case does not add new information, that case should be the last case. The multiple case studies are identified together with another researcher with the same focus of research. This increases the external validity of the study because the cases help guard against observational bias (Voss 2009).
3.3 Data collection
Interviews
The primary data collection consists of semi-structured interviews. Interviews were conducted with key personnel in a role of relevance to the implementation or managing of the token-based system. Where possible, the opinions of the interviewees were validated with quantitative evidence. This quantitative evidence can be provided by documents concerning performance parameters of the production, including the token-based system or other relevant quantitative information. The companies are active in a wide range of industrial sectors, the most typical are; electronics, machine tools, aerospace and defence, and industrial equipment.
meaning that they had to be aware of every aspect of the company to give a complete overview. Also, they had to be aware of how the token-based system is used. Whenever possible, also interviews held with employees on the shop floor. This is to ensure triangulation of the obtained information through the interviews.
The interviews are semi-structured to allow new insights to be brought up by either the interviewee or the interviewer. The interviews were all conducted face-to-face. The length of the interviews varies from 35 minutes to 90 minutes per interviewee which was depended on the expertise and the availability of the interviewee. The interview protocol with a consent form was given to each interviewee and a list of pre-determined questions before the interview took place and can be found in Appendix A.
An interview protocol was used to guide the interviews. This interview protocol also ensures data reliability (Yin 2009). The interview consists of questions which are derived from the theoretical framework provided in section 2. Questions were structured according to the funnel model (Voss 2009), i.e. starting with the environment of the organization followed by the structure and configuration of the token-based system. The interviews were recorded to ensure no relevant information is missing which might be identified during a later stage of the study. The interviews were transcribed and sent to the interviewee for review, and if necessary, revision. This ensures the construct validity of the data (Voss 2009). Furthermore, a list of interviewed people and their job description can be found in Appendix B. Due to confidentiality, the company names and names of interviewees are left out. The interviewees are offered immunity since the ethical guidelines of University of Groningen and Newcastle University are followed.
Direct observations
3.4 Data analysis
The method of Miles and Huberman (1994) is used to analyse the qualitative data. This approach is composed of three main steps: data reduction, data display, and conclusion drawing. The first step, data reduction was performed by analysing the retrieved data and highlighting the valuable data which is done per quote. The aim of highlighting the information is to organize the data of the diverse responses to get a decent outline of all available valuable data. The second step, data display, a conventional content analysis was used as the primary approach. A conventional content analysis is suitable when existing theory or research literature on the phenomenon is limited (Hsieh & Shannon 2005). With conventional content analysis, the categories and names for categories flow from the data. As a result, it is allowed that new insights emerge (Kondracki et al. 2002). After all the data is coded, the codes are sorted into categories based on how different codes are related and linked (Hsieh & Shannon 2005). Subsequently, the codes were organized into a smaller number of categories (Appendix C). These categories are patterns or themes that are derived through the analysis, making it possible to identify relationships among the categories (Hsieh & Shannon 2005).
First categories were assigned to each case, e.g. within-case analysis. The aim is to cope with the amounts of information and become familiar with each case and to identify the unique patterns (Eisenhardt 1989). This strengthens the internal validity of findings (Voss 2009). The focus is on exposing the relations between variabilities and the actions used to cope with these. Since the usage of conventional content analysis, during the within-case analysis, the researcher can come up with new categories whenever necessary. Secondly, as suggested by Voss (2009), a cross-case analysis is performed which aimed to identify patterns among the different cases which made it possible to review the evidence from multiple cases through various lenses (Eisenhardt 1989). The cross-case analysis is based on the variabilities perceived by the cases and their way of handling with the variabilities. Here, particular focus was on the similarities and difference of managing the variabilities.
3.5 Quality criteria
concerning the same case, whenever this was possible. Furthermore, a chain of evidence was created by interviewing, document analysis and observations to verify and validate given responses or gathered data. Secondly, interval validity was supported by performing a cross-case analysis which allows the research to elaborate discovered patterns of certain factors. This is organized by using categories which gave an adequate overview and summary of the observed phenomenon per case. Thirdly, external validity was ensured through the replication logic of the multiple case study. From the with-in cases analysis, the categories assigned to certain data are then compared per category for all the cases. As a result, an overview per category was made to make a complete comparison. Finally, reliability was secured by using an interview protocol and by establishing a case study database in Microsoft Excel. The case study database consists of the quotes highlighted from the transcriptions which are stated in the first column. In the second column, the subcategories are assigned, followed by the main categories (see Appendix C for the coding scheme). Besides the consideration of the different quality criteria, the ethical guidelines of the University of Groningen and the Newcastle University were followed.
3.6 Overview of cases
For this research, the cases were chosen based on replication logic. From the 11 interviewed organizations, 9 of them were identified as suitable for this research. Two organizations did not have a system which suited our definition of a token-based system. From the nine appropriate organizations, ten cases were presented. An overview of these companies is given in Table 3.1. The companies are named A to I to be discrete and ensure confidentiality.
Table 3.1 Overview of the case company characteristics
Company Main business #
employees1 Annual turnover Primary CODP Token-based system Implemented since A Producing customized hinges 16 €4 million MTO POLCA 2007 B Assembling electronics 70 €22 million ATO POLCA 2011 C Producing machines for potato growers
65 €25 million MTO Kanban 2008 D Producing high-speed rotating systems for aerospace industry 50 €40 million MTO/ETO CONWIP + Kanban 2004 E Producing conveyor belts 67 €30 million MTO Two-bin Kanban 2011 F Producing electricity cabinets 6 €6 million ATO/MTO CONWIP 2000 G Producing refuse collection vehicles 160 €100 million MTO Two-bin Kanban 2014 H Producing folder inserters and parcel packaging 60 €55 million MTO/ATO Kanban 2014 I Producing baths 20 €500 million MTO Two-bin Kanban 2009
Figure 3.1 Process/Product matrix with the position of the case companies The cases are described in more detail in Appendix D.
4 Findings
4.1 Within-case analysis
This section gives an overview of the token-based systems used at the case companies with respect to the literature addressed in Section 2. The companies and their cases are described in more detail in Appendix D. The individual cases encountered difficulties with the implementation and the management of the token-based system with regards to the variabilities.
4.1.1 Company A
The first of the case studies is a manufacturer of custom-made hinges with 22 employees and an annual turnover of €4m. The company implemented POLCA in 2007 to create flow on the shop floor.
Adaption from literature - POLCA is used for the entire production but does not control the order release. This order release differs from the original POLCA system proposed by Suri (1998) where the order release is based on the availability of POLCA cards downstream, e.g. indicating spare capacity. In the original system, order release is influenced by the priority of an order and the current shop floor situations (Henrich et al. 2004). It is essential for the first work cell on the shop floor to maintain a high utilization rate to decrease the waste of metal, e.g. nesting. Characteristics of the first work cell are opposed to the work cell characteristics described by Suri (1998). Contrary to the literature, company A has unit-based cards while the processing time variability is relatively high, where load-based cards are more common in this situation (Vandaele et al. 2008). The interviewee indicated that this is due to the complexity associated with using load-based cards.
cells. The capacity adjustments are made by (re)placing the employees. This flexible capacity is possible since the employees are cross-trained.
Maturity of the system - the maturity of this system implemented is characterized as level 4/5 because the entire production is controlled through the implemented token-based system. However, a level 5 is not achieved since the processing time variability is not captured through the token-based system. This processing time variability is captured through two other mechanisms; decreasing batches and flexible capacity. The advantage of achieving level 5 is that the reliance on those two mechanisms can be minimized since the processing time variability is captured through the token-based system by using load-based cards for example. Furthermore, it can be beneficial to monitor the performance of the token-based system in order to review the number of cards in the system continuously. To work properly, this should be done in relation to the first production cell. However, this would increase the complexity and requires more knowledge on Load-based POLCA systems.
Contribution to the research question - there are no factors that pursue a change to the token-based system. However, company A recognizes and acts to the variabilities through the following mechanisms:
- Processing time is partially captured by dividing an order into several batches when a certain workload is achieved. This result in cards partially being load-based and unit-based. - Another mechanism that captures the processing time is through load redistribution at the
order release.
- Furthermore, processing time variability is also captured through the flexible capacity of the work cells.
Company A does not want to make changes to the POLCA system, since the interviewee indicates that the system is flexible itself and no adjustments are required. It can be assumed that the POLCA is more used as visualization tool to guide employees instead of a real control tool.
4.1.2 Company B
flow of the conventional assembly department and eliminate micromanagement on the shop floor.
Adaption from literature - the POLCA system implemented deviates from the original POLCA system as described by Suri (1998). This adaption is due to the presence of non-overlapping loops where the original POLCA system proposed overlapping loops. This change is made to capture the high number of control loops, e.g. more than 90. Overlapping loops increase the complexity of the token-based system which was also perceived by Company B. Company B prefers having simple tools to control the production. This was previously also highlighted by having too many loops can be cumbersome to monitor (Thürer, Stevenson, Protzman, et al. 2016). The order release is also not controlled through the POLCA system as suggested by the literature since the first work cell is recognized as a bottleneck. The order release is therefore based on the available capacity of the entire system at the moment of release. Company B finds it challenging to maintain the right quantity of cards in the system. The formulas proposed by literature for the calculation of cards were initially used, but does not meet the expectations. This is logical since the POLCA formulas are not applicable anymore due to the change made in the structure. Within the company there is the discussion whether to use an electronic system instead of physical cards. The interviewee preferred physical cards due to their simplicity.
Management of variability – The routing variability is captured through the route-specific control loops; however, these are non-overlapping. Furthermore, the company is not heavily subjected to demand variability. However, high processing time variability presented, resulting in deviating workload of work cells. As well as company A, this is captured by capacity adjustments throughout the shop floor. The number of cards is not adjusted; however, this is not necessary since a card indicates an amount of capacity. By changing the capacity, the meaning of a POLCA card changes, even though the same number of cards is maintained. Processing time variability is captured by reducing the workload per order. An order is represented by a card. When a certain threshold is reached, the order is divided into several cards. This can be perceived as partially unit- and load-based cards. This is the same method used by company A.
token-based system. Other mechanisms are used to capture the variability, such as decreasing the batches when a certain threshold is achieved and using a flexible capacity. Aiming for a high maturity level should result in less reliance on the other mechanisms used to capture the variabilities apart from the token-based system. As a result, this increases the complexity when using load-based cards to capture processing time variability.
Contribution to the research question - The main lesson concerning the research question is that also at this company, there are no factors which drive a change to the token-based system. The main factors influence the systems are a high routing sequence variability and high processing time variability. Company B uses other mechanisms to capture the variability.
4.1.3 Company C
Case study three is a producer of agricultural machinery for potato growers. The company has 110 employees and an annual turnover of €25m. The company implemented a two-bin Kanban system in 2007 to control the components supply from the central warehouse to the production.
Deviation from literature - The components are not all located at the shop floor since the components are physically too large to be located at the production line. Therefore, an extension made to the formula presented in literature is by including the physical size of the component besides the demand
Management of variability - Company C has high inter-arrival time variability due to two demand peaks throughout the year. This high inter-arrival variability does not suit the assumptions made by Toyota, where Kanban was first used. Company C deals with this variability by having an average stock level which is too high compared to propositions of Ohno (1988).
Contribution to research question - The major factors influencing the in-use token-based system are limited. The only remarkable point is the inventory level of components which is relatively high on average. This inventory level sounds logical due to the high inter-arrival time variability when aiming to maintain simplicity. Also, the physical size is used to determine the quantity of the Kanban.
4.1.4 Company D
The fourth company is a producer of high-speed rotating systems for the aerospace industry. Company D has 110 employees and reports an annual turnover of €40m. The company has been using a two-bin Kanban and CONWIP since 2004. CONWIP was implemented to reduce the throughput time, and the two-bin Kanban was implemented to have a cheap and straightforward system to control components resulting in a reduction of stock outs and discrepancies in the inventory level.
Adaption from literature - Company D has not made any significant changes to the implementation of the systems. The number of cards is reviewed on a weekly basis during a production-planning meeting. As a result, the CONWIP system is more used as a visualization tool for the employees on the shop floor. This deviates from literature because the token-based system should be utilized as a tool to control the production (González-R et al. 2012). Regarding the two-bin Kanban system, for the calculation of the quantity of Kanban, the risks involved with a certain supplier and the price of the product is also taken into account.
Management of variability – Company D is not heavily subjected to routing variability since most of the products follow the same flow through the process. Due to long-term contracts, there is no high demand variability. However, the company perceives some processing time variability which is captured by the flexible capacity of the work cells, which is also used at companies A and B.
times can be determined more accurately, which should result in higher service level (Olaitan 2016). The preference of the cards is a load-based variant due to the processing time variability. CONWIP and Kanban are preferable to maintain the simplicity of the system but still be able to cope with the processing time variability.
Contribution to the research question - Company D captures the variability with maintaining flexible capacity among the work cells through the use of moving the cross-trained employees. Furthermore, for the calculation of Kanban quantity, the price of the products is also considered. The company sees the implementation of a token-based system as an increase in complexity and therefore did not highly customized the system. A problem experienced by the company is the discipline required for the two-bin Kanban system.
4.1.5 Company E
Company E produces conveyor belts which are used in various industrial applications. Company E employs 98 people and report an annual turnover of €30m. A two-bin Kanban system was implemented in 2011 because of the commitment towards Lean. The two-bin Kanban system is used to supply components from the warehouse to the shop floor of the assembly department.
Adaption from literature – There is no deviation perceived from the literature regarding the implemented token-based system.
Management of variability – Company E does not actively manage the variabilities. This is the same attitude as company C. Also, any variabilities are captured by maintaining an inventory which is on average too high. The quantity of Kanban is not managed through the years. Therefore, the variability is captured by increasing the velocity of the bins, e.g. more often are the bins refilled in a certain timeframe.
Contribution to the research question - Company E does not give new insights regarding the research question. This lack of insights is probably due to the low maturity level. Company E does not know how to optimise the use of the Kanban system. A consequence of the inter-arrival time variability is the variation in the velocity of the bins throughout the year.
4.1.6 Company F
Company F produces electricity cabinets and employs six people in the CONWIP system. The CONWIP line reports an annual turnover of €6m. The CONWIP system is implemented since 2000 in order to use the principles of Lean to produce more efficiently.
Adaption from literature - This is related to the order dispatching. The original order dispatching rule established by Spearman et al. (1990) was FCFS. Company F uses EDD as dispatching rule in order to minimize conflicts of the due date.
Management of variability – The routing variability is relatively low. Therefore, a CONWIP system is suitable. Also, the demand variability is moderate which is captured through increasing the velocity times of the bins. This method has the preference over an increase in the quantity of the tokens. Increasing the number of the tokens, for example, leads to an increase in WIP, which the company wishes to decrease as much as possible. However, the adaption to the quantity of cards is also perceived as a method. The company is subjected to processing time variability which is captured through the flexible capacity of the work cells.
Maturity of the system - The achieved maturity level is 4, the CONWIP system is minimally exposed to variabilities and therefore customization is less important. The variability is partially captured through the token-based system. Also, other mechanisms are used also to capture this variability. Company F, as with Company E, has the preference for a variable velocity time than adapting the number of cards to changing conditions. Most of the time, these other mechanisms have the preference due to their simplicity and management.
number of cards is useless. Literature assumes that the capacity of work cells is fixed when it is recommended to adjust the number of cards in the system. The company does not feel the urgency to increase the maturity level of the CONWIP system since is already functions according to their expectations.
4.1.7 Company G
Company G produces refuse collection vehicles and employs 450 people. Their annual turnover is €100m. Kanban is implemented throughout the shop floor in 2011 to ensure the availability of required components for the production.
Adaption from literature - the only deviation of the in-use Kanban systems according to the literature is related to the calculation of the quantity of the Kanban cards. Since some components are physically relatively large, the size is also taken into consideration for the calculation. This consideration also holds for company C.
Management of variability – in general, the token-based system is not subjected to high variabilities. However, to capture some variability, especially the demand variability, some additional safety stock is maintained. Also, a fluctuating velocity time is used, which is similar to company F. Furthermore, load redistribution is done to capture the processing time variability.
Maturity level of the system - The maturity level perceived is 2 since the Kanban system controls a minor problem. However, the performance of the implemented system could be increased when a flexible Kanban system is maintained which should result in an on average lower inventory. The company indicated that this is not their primary objective and prefer having some safety stock.
4.1.8 Company H
Company H produces folder inserters and packaging machines. Company H employs 300 people and reports an annual turnover of €55m. The Kanban system was implemented in 2014 in order to control the production of subassemblies to the major production line.
Adaption from the literature – The Kanban system implemented has no customizations. The explanation for this is probably that the Kanban cards only authorize the subassembly production, which is relatively a small part of the production.
Management of the variability – Routing variability is minimal, and the demand variability is high. The demand variability is captured through flexible capacity and the processing time variability is perceived moderate. Flexible capacity is maintained to cope with demand and processing time variabilities. When there is an increase in demand or processing times, it is possible to add an extra work cell for the production of sub-assemblies. Also, some workload balancing is done to cope with processing time variabilities.
Maturity of the system - The maturity of the system is perceived to be level 2 since the token-based system captures only a minor control problem. Also, other mechanisms are used to capture the variability concerning demand and processing time. This variability is most of the time captured through flexible capacity and some load redistribution.
Contribution to the research question - Capacity flexibility is an important aspect of dealing with variability. Furthermore, company H also uses the principles of load redistribution to cope with processing time variability. The number of cards is rarely adjusted.
4.1.9 Company I
Company I produces baths and employs 100 people. An annual turnover is reported at €500m. Since 2009 they implemented a Kanban system with the aim to increase delivery reliability.
also considered in this computation. The literature assumes that the suppliers can deliver each requested quantity, due to a lack of buying power.
Management of variability – Routing variability is perceived as low since the customization is only done to the additional components of a bath. The demand variability is high due to project orders, i.e. high number of baths for an order. This is captured by having a higher safety stock to ensure that all the time components are available. Processing time variabilities are captured by using workload balancing principles at the order release. Furthermore, to cope with the variabilities, the company maintains flexible capacity by using cross-trained employees.
Maturity of the system - the Kanban system is level 2 since the implemented token-based system captures only a minor control problem. Due to project orders an additional safety stock is maintained which could be eliminated when using a flexible Kanban system (Gupta et al. 1999).
Contribution to the research question - The main lessons from this company to the research question is that no major adjustments are made to the original suggested Kanban approach. The variabilities are captured by using workload control principles at the order release and the flexible capacity of the work cells.
Table 4.1 A summary of the case studies
Company Token-based system
Perceived variability Capture mechanisms outside token-based literature Maturity level A POLCA V1. Routing V2. Processing time S1. Decreasing batches S2. Flexible capacity S3. load redistribution 4/5 B POLCA V1. Routing V2. Processing time S1. Decreasing batches S2. Flexible capacity 4/5
C Kanban V1. Demand S1. Additional safety stock S2. Physical size of products
2
D.1 Kanban S1. The price of the products 2/3 D.2 CONWIP V1. Processing time S1. Flexible capacity 3 E Two-bin
Kanban
V1. Demand S1. Additional safety stock S2. High velocity time of bins
2
F CONWIP V1. Demand V2. Processing time
S1. Order dispatching with EDD S2. High velocity time of bins S3. Adaption of number of cards S4. Flexible capacity
4
G Two-bin Kanban
V1. Demand S1. Additional safety stock S2. High velocity time of bins S3. Load redistribution S4. Physical size of products
2 H Kanban V1. Demand V2. Processing time S1. Flexible capacity S2. Load redistribution 2 I Two-bin Kanban V1. Demand V2. Processing time S1. Flexible capacity S2. Load redistribution S3. Additional safety stock
2
