Design considerations of token-based systems: A multiple case study in small and medium-sized enterprises

(1)

Design considerations of token-based systems: A multiple case

study in small and medium-sized enterprises

Author: Martijn Biesheuvel DD-MSc. Operations Management

13.739 Words (excluding appendices and references)

December 12, 2016

Groningen, the Netherlands

Supervisor & Assessor: N. Ziengs MSc. Co-Assessor: Dr. G. Heron

University of Groningen, Faculty of Economics and Business Nettelbosje 2, 9747 AE Groningen

The Netherlands

Newcastle University Business School

(2)

Abstract

Purpose: The customization of pull production systems has received great interest. Academics customized pull production systems in order to overcome shortcomings of generic systems and to improve the fit with the environment in which they operate. However, these customised pull production systems are mostly tested in simplistic (theoretical) environments and are often inoperable in real-life environments as they can become too complex to operate. Organisations therefore tend to implement systems that are more straightforward and do not adapt the systems to the degree that is suggested by modelling and simulation literature. This study tries to empirical asses the design considerations made by organisations and aims to find out if the improvement aspects, suggested by literature, are used in practice.

Method: A multiple case-study is chosen in order to empirically validate the design considerations of organisations and assess whether the theoretical performance benefits of customized token-based systems are used in practice.

Findings: A decision tree is made which serves as a guidance for practitioners for choosing a generic token-based system, based on a number of pull system characteristics. Next to this, multiple sub-systems are identified that may help practitioners in controlling specific environmental and organisational characteristics.

Contribution: The study identified a gap that is determined as the bridge between academics and practitioners. Academics developed simulation and optimisation models of token-based systems in order to improve the performance in respect to generic systems. However, the suggestions and advice derived from these models are not used in practice. Academics should focus on developing literature that is related to reducing and controlling variation, as practitioners struggle with these aspects.

(3)

List of figures

Figure 2-1: Central and decentral control ... 13

Figure 2-2: Connected and unconnected workstations ... 14

Figure 2-3: Traditional vs. segmented vs. joint structures ... 15

Figure 2-4: JIT-manufacturing (Lee & Ebrahimour, 1984) ... 19

Figure 2-5: Conceptual framework ... 20

Figure 4-1: Kanban comparison ... 30

Figure 4-2: Conwip comparison ... 34

Figure 4-3: Polca comparison ... 36

Figure 4-4: Overview of design considerations ... 40

Figure 4-5: Segmented or traditional structure ... 41

List of tables

Table 3-1: Organisational characteristics ... 27

Table 4-1: Design considerations token-based systems ... 29

Table 4-2: Cross case analysis ... 38

(5)

List of abbreviations

ATO Assemble to order

MTS Make to stock

BTO Buy to order

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

GFS General flow shop

GJS General job shop

JIT Just in time

MRP Material requirement planning

MTO Make to order

PFS Pure flow shop

PJS Pure job shop

Polca Paired-cell overlapping loop of cards with authorization

QRM Quick response manufacturing

SME Small and medium sized enterprises

SPT Shortest processing time

STS Ship to stock

TPM Total productive maintenance

TQM Total quality management

WINQ Work next in que

WIP Work in progress

(6)

Preface

This thesis represents the final piece in finalizing the dual degree master in Operations Management. Since the start of the pre-master in Technology and Operations Management, most of my time and effort was dedicated to working to this point. Despite my dedication I could not have done it myself, if it was not with the people close to me. Therefore I would like to take this opportunity to express my graduate to everyone who supported me and gave me initial confidence to finish this journey.

First of all, I would like to thank my supervisor Nick Ziengs. The enthusiastic guidance, support and feedback throughout the project was very helpful and significantly improved the quality of this study. Next to this, I also would like to thank Dr. Graeme Heron for his role as co-assessor and the feedback he was willing to provide.

I would also like to thank all the people that were involved during the interviews. This input is the foundation of this thesis. Next to this, I would like to thank Carlijn Bontjer for helping me collecting this data.

(7)

1 Introduction

One of the aspects central in production control is the management of the total flow of goods through a system (Liberopoulos & Dallery, 2000). This flow is controlled through production planning and control policies, which are used to pursue the minimization of throughput times, work-in-progress (WIP), stockholding costs and improve the delivery reliability and responsiveness to change (Stevenson, Hendry, & Kingsman, 2005). Production control systems are often classified as either “push” or “pull”. Pull production systems explicitly limit the amount of work in process that can be in the system or part thereof (Hopp & Spearman, 2004), whereas push systems do not have an explicit limit on WIP. The main advantages of pull systems come from the reduced amount of WIP, smoother production flow, improved quality and reduced costs (Hopp & Spearman, 2004).

Token-based systems use cards, or more general: ‘tokens’, as triggering mechanism to authorize the processing of jobs or the movement of materials and are implemented in pull production systems (Gershwin, 2000; González & Framinan, 2009). The most well-known token-based system is Kanban (Sugimori, Kusunoki, Cho, & Uchikawa, 1977). The system operates in a relative simple way: the production or movement of materials starts when a consecutive workstation indicates, by using cards, that there is capacity. In Kanban systems, the cards are related to products, which makes these systems less suitable for the 21st century market, as these are characterised by much product and volume variety (Suri, 2003).

(8)

The aim of this research is to empirically explore the different design considerations of token-based systems and investigate which factors affect these considerations. This research aims to find out if the suggested policies of modelling and simulation literature are wanted by practitioners, in order to make the suggested performance improvements.

A holistic explorative multiple-case study is conducted among nine organisations which control the production, or part thereof, with a token-based system. The input for the case analyses is primarily based on semi-structured interviews, which are supported by observations and document analyses. The organisations in the case study are characterised as small to medium-sized organisations, as these organisations tend to have the characteristics that make pull production control suitable (Stevenson et al., 2005). During the case study, six organisations were interviewed that controlled (a part of) the production with a Kanban system, two organisations with Conwip and two organisations using a Polca system.

This research makes a number of contributions. First, literature lacks explanation on how token-based systems are designed by practitioners and what factors are influencing the design considerations of these organisations. Second, the findings can be used as classification for literature, which can be either useful for academics or practitioners. Third, the findings can be used as evaluation of classification, in order to identify areas where simulation studies should focus on. Next to this, the literature can be used as guidance for practitioners as it sets forth all the design considerations and what factors influence these considerations. By using this literature, organisations can design token-based systems that better fit their particular circumstances and prevent design mistakes.

(9)

2 Theoretical background

2.1 Production planning and control

The objective of production planning and control policies is to minimize the shop floor throughput time and lead time, lower the amount of WIP, lower stockholding costs, improve delivery date adherence and improve the responsiveness to changes in demand (Stevenson et al., 2005). The design of such control policies can become complex as the number of design considerations and factors influencing these considerations are comprehensive (Liberopoulos & Dallery, 2000; Stevenson et al., 2005).

Within production planning and control, one can distinguish between order acceptance, order release and order dispatching (Gershwin, 2000; González & Framinan, 2009; Land, 2004; Wein, 1988). Order acceptance is the process where an order is accepted (or rejected), a due date is assigned and is the first opportunity to control the input of work (Land, 2004). The order acceptance can support the release decision, which refers to the mechanism that controls the input of jobs to the shop floor (Land, 2004). The order dispatching rules specifies which job should be processed next at a workstation.

(10)

The order dispatching rules specifies which job should be processed next after a workstation finished a specific job. Literature defined different priority rules for the sequencing of jobs. Examples are: first come first serve (FCFS), shortest processing time (SPT), earliest due date (EDD) and work next in queue (WINQ). These examples can be put in different categories: conserving flow, improving throughput and reducing lateness dispersion (Land, 2004). Conserving flow implies that the outgoing job sequence is the same as the incoming job sequence (e.g. FCFS). In this case, the dispatching rule only act as a blocking mechanism for jobs between workstations, but does not change the sequence. Improving throughput can be done in two ways: making use of the processing characteristics (e.g. SPT) or balancing the workload (e.g. WINQ) (Land, 2004). Reducing lateness dispersion rules try to limit the amount of slack and due date violations (e.g. EDD).

To conclude: the order release, acceptance and dispatching rules offer the possibility for delaying a specific amount of work and allows the organisation to prioritize work. It is a decision moment for the flow of a job.

2.2 Production control systems

(11)

Production control can be seen as an optimization problem, which can be solved in two ways: exact and approximate. Exact methods formulates the problem as an optimal control problem for which an optimal control policy is to be found (Liberopoulos & Dallery, 2000). Gaury (2000) published an overview of these exact methods in pull production systems. The approximate approach tries to identify a (finite) set of control policies and select the best of these in order to control the system in the best way, subjected to the given parameters. The difference between these methods is that the exact methods focus on specific parameters, under simple conditions and often cannot be extended to real-life situations.

2.3 Pull production

Hopp and Spearman (2004, p. 142) defined pull and push systems as: “A pull production

system is one that explicitly limits the amount of work in process that can be in the system. By default, this implies that a push production system is one that has no explicit limit on the amount of work in process that can be in the system”. As described, token-based systems are

often implemented in pull systems as these can be helpful in controlling the amount of work in a system. Well known generic pull systems that are controlled using tokens are Kanban, Conwip and Polca.

(12)

2.4 System design

The design of token-based systems revolves around two issues: setting structure and configuration (Gaury, 2000). The structure of token-based systems refers to the control loops between different workstations and the configuration defines the type and the amount of tokens that circulate within a loop (Gaury, 2000; Ziengs et al., 2012). The number of tokens in a system regulates the amount of WIP as they are related to an amount of work.

2.4.1 Structure

Determining the structure and configuration is hard, since the design problem is complex and multiple parameters are interlinked with each other. To determine the structure the following design considerations need to be made:

1) Centralised control vs. decentralised control 2) Connected loops vs. unconnected loops 3) Traditional vs. segmented vs. joint structures

Lödding (2003, p. 43), describes a centralized production control system as: “a system

that controls WIP levels and thereby the lead times and work centre utilization on a centralized control level”. Decentralized production control systems will set these parameters

by creating control loops between workstations (Lödding et al., 2003). Kanban is an example of decentralized control, whereas Conwip is an example of centralized control.

(13)

over the buffers as station one and two could not authorize the production or movement of materials as there is no capacity in downstream buffers.

Figure 2-1: Central and decentral control

The second factor influencing the decision for placing control loops is bottleneck utilization. Conwip (one control loop) is often praised for its high throughput (push) and low WIP (pull) (Hopp & Spearman, 2008). With this fact, we also refer to Figure 2-1, as WIP naturally accumulates before a bottleneck, bottleneck utilization will be greater (Spearman, Woodruff, & Hopp, 1990). Next to this, if WIP accumulates before the bottleneck, it may be easier to spot this and put focus on improving specific parts of the production system. Moreover, a distinct bottleneck is easier to model, control and preventing starvation or blocking of the bottleneck will be easier to control (Hopp & Spearman, 2008).

A third factor is related to flexibility and robustness (Framinan, González, & Ruiz-Usano, 2003; Hopp & Spearman, 2008). Organisations facing uncertain and dynamic environments tend to operate better with fewer control loops (Framinan et al., 2003). Robustness is related to dealing with processing time variability and the manufacturing environment (inter-arrival time variety, volume variety and product variety). However, literature is not unambiguously on the results of comparing different systems with each other and it is not clear if the benefits of certain systems are related to the robustness, specific designs principles of systems or the scenarios wherein the systems are tested. Further research is therefore needed, see Framinan et al. (2003).

The last factor influencing the placement of control loops is related to employees. First, control loops bring a certain amount of stress into the system (Hopp & Spearman, 2008). Often, operators have the materials to start producing, but are not authorized to start. When they finally are authorized, they have to replenish the void in the system as quickly as

Central control

Decentral control

1 2 3

(14)

possible, to prevent starvation downstream (Klein, 1989). Klein (1989) makes the statement that there is some of this stress in Conwip systems, yet there seems to be more of this stress in Kanban systems where there are control loops between each consecutive workstation. The second argument is that control loops may foster closer relationships between operators of adjacent workstations (Hopp & Spearman, 2008; Powell, Riezebos, & Strandhagen, 2013). The placement of control loops will ensure that operators communicate with each other, which provides the opportunity for quality control and identification of problems adhering to the production rate.

The next distinction in setting structure is that workstations can be connected or unconnected (Ziengs et al., 2012). If a card signals information about the availability of capacity to one or more workstations, they are classified as ‘connected’. If a card does not signal the availability of capacity to a workstation, but to an inventory point or collection point, the control loop is ‘unconnected’. This is represented in Figure 2-2. The figure represents a production process in which the triangle denotes an inventory point and the squares denote a workstation.

Figure 2-2: Connected and unconnected workstations

The last structural classification is related to the specific pattern of control loops. This pattern can be classified as traditional, segmented or joint (Gaury, 2000). Traditional structures are widely described in literature, are often used in practice and use a specific pattern of control loops. Examples of these traditional structures are Kanban, Conwip and

Segmented

(15)

segment. An example could be that the first part of the production produces to stock, where the last part of the production produces to customer order. An example is the process of ordering a burger in a fast-food restaurant. All the individual ingredients are cut and placed in inventory bins (push). As soon as a customer orders the burger, the meat is cooked and the burger is assembled to customer preferences (pull). Joint structures make use of multiple control mechanisms to control a specific part of the production. An example could be a combination between Conwip and Kanban. Figure 2-3 visualizes these design considerations.

Figure 2-3: Traditional vs. segmented vs. joint structures 2.4.2 Configuration

The configuration of a token-based system refers to the amount and type of cards that circulate within a control loop (Gaury, 2000; Ziengs et al., 2012). The cards limit the amount of WIP and are used to authorize actions (e.g. movement of materials or production). To determine the configuration, the following design considerations need to be made:

1) Singe card vs. dual card 2) Load-based vs. unit-based

3) Product-specific vs. product-anonymous vs. route-specific control

A system uses a maximum of two types of cards: production and/or transportation cards (also called conveyance and withdrawal cards). A transportation card authorizes the quantity that the succeeding stage should withdraw (Akturk & Erhun, 1999), whereas production card defines the quantity that the producing stage should manufacture in order to replace those which have been removed (Groenevelt, 1993). The reasons for choosing a dual-card system over a single-dual-card system are not unambiguously and can be divided into four main categories: complexity, control, physical distances and information processing time.

Traditional

Segmented

Joint

(16)

First, one-card systems are often implemented because of their simplicity (Akturk & Erhun, 1999; Spearman et al., 1990). A dual-card system is often harder to implement, as there are more prerequisites and strict assumptions, but offer tighter control (Akturk & Erhun, 1999). Next to this, dual-card card systems are often used when the physical distances between workstations or cells are big or parts become too heavy. The costs of initiating a material-handling operation each time a station requires material therefore becomes prohibitive (Berkley, 1992). Also, the information lead times are longer compared to single-card systems.

The second distinction between cards is that they can be either load-based or unit-based. Unit-based cards represent a single order, whereas a load-based card represents a predetermined amount of work (Ziengs et al., 2012). A unit-based card does not take processing time requirements into account and an available card is therefore a rough approximation of the available capacity. Load-based cards represent a specific amount of work. Choosing one over the other is related to complexity and the needed amount of control. Unit-based cards are more straight forward and therefore more frequently used (Ziengs et al., 2012). However, they do not indicate the processing time requirements in account, which may be disadvantageous for levelling production and anticipating on peaks in workload. As load-based systems are complex to implement and operate, organisations often limit the maximum amount of workload per job, through input control (Land, 2004).

(17)

Product-specific control is seen in a Kanban system, route-specific control is seen in Polca and product-anonymous control is seen in Conwip. Product-anonymous control or route-specific control is often seen in organisations that produce in a make-to-order (MTO) environment, as the product variety is high and the volume is low (Riezebos, 2010).

The number of cards (e.g. WIP) that are used in a system have a major influence on the performance and are means for balancing inventory and service performance (Gaury, 2000). Pull systems only perform well when the number of cards is chosen optimally (Gupta & Gupta, 1989; Huang, Rees, & Taylor, 1983). The cards act as a blocking mechanism to limit further production of materials. If an infinite amount of cards would circulate within a control loop, the operator is always allowed to produce and blocking would only occur by machine stoppages, material starvation or issues with employees. Gaury (2000) shows that the service level above a certain amount of WIP does not further increase. However, the total costs increase after this threshold. Literature presents multiple techniques for calculating the number of cards: empirical formulas, optimization based on analytical models and optimisation based on simulation models. Most of these formulas and techniques are related to Little’s law (1961). This law states that the average throughput rate of a system equals the quotient of the average number of elements in the system and the average time an element is in the system (Riezebos, 2010). For an example of empirical formulas see Sugimori et al. (1977), analytical models see Di Mascolo et al. (1996) and simulation models see (Bonvik, Couch, & Gershwin, 1997).

Within system design, the focus is on determining the correct amount of cards; e.g. card setting. As organisations are submissive to change, it may be needed to change the amount of cards overtime: e.g. card controlling. More information on card controlling will be found in papers of Hopp & Roof (1998) and Tardif & Maaseidvaag (2001).

2.5 Organisational and environmental characteristics

(18)

The first characteristic is related to variety. Variety is defined by Hopp & Spearman (2008, p. 249) as: “the quality of non-uniformity of a class of entities”. They categorise variety in two possible ways, which are the building blocks for characterizing variety in production: process time variety and flow variety. Next to this, there is variety that is created from an outside perspective and is often cited in (modelling) literature: volume and product variety. Process time variety is the variability in process time that is created through natural variability (e.g. different products), pre-emptive outages (e.g. breakdowns), non-pre-emptive outages (e.g. planned maintenance) and recycling (e.g. rework). Flow variety or routing variety refers to the variability in the transfer of jobs or parts from one station to the next (Chang, 2007; Hopp & Spearman, 2008). Product variety (or product mix) refers to the amount of different products produced. Volume variety is divided into two segments: the amount of products per order (volume variety) and the time between needed volumes (inter-arrival time variety).

The trade-off between product and volume variety often goes hand in hand with flow variety and process time variety and can be related to the operations strategy as shown by Stevenson (2005). Operations strategies can be classified according to six typologies: engineer-to-order (ETO), buy-to-order (BTO), make-to-order (MTO), assemble-to-order (ATO), make-to-stock (MTS) and ship-to-stock (STS) (Hoekstra & Romme, 1992; Lampel & Mintzberg, 1996; Naylor, Naim, & Berry, 1999; Olhager, 2003; Yang & Burns, 2003). The different concepts have been organised around the concept of the Customer Order Decoupling Point (COPD). This is the stockholding point where parts are linked to a specific customer and forecasting stops (Christopher, 2000; Hoekstra & Romme, 1992; Mason-Jones, Naylor, & Towill, 2000; Naylor et al., 1999; Olhager, 2003).

(19)

2.6 Support systems

Token-based systems are often part of a greater philosophy or strategy. Originally, Kanban was part of the just-in-time (JIT) manufacturing technique (Jing & Xuejun, 2009; Lee & Ebrahimour, 1984; Monden, 1983; Ohno, 1988; Stone, 2012; Sugimori et al., 1977). JIT manufacturing consists of four components: production smoothing, standardisation, multifunction workers and Kanban, which are

essential for establishing a proper system, see Figure 2-4 (Lee & Ebrahimour, 1984). Kumar (2007) argues that the pillar Kanban can be replaced with other token-based systems. However, as debated in the introduction, the 21st century markets often require a large variety of highly customized products with variable demand (Suri, 1998). Kanban and JIT manufacturing is therefore not optimal in these environments, as the strategy breaks down all together as the foundations do not make any sense in these type of environments (Suri, 1998).

It is argued that token-based systems operating in these environments are part of another strategy: quick response manufacturing (QRM). QRM is a company-wide strategy that pursues the reduction of lead time in all aspects of the organisations’ operations (Sugimori et al., 1977). For a thorough literature review see Kumar & Panneerselvam (2007) and Suri (2003, 1998). Other practices that often go hand in hand with token-based systems are TQM (Total Quality Management) (Ahuja & Khamba, 2008), TPM (Total Productive Maintenance) (Ahuja & Khamba, 2008) and Lean (Six Sigma) (Stone, 2012).

(20)

2.7 Conceptual framework

The theoretical background emphasises that organisational and environmental characteristics influence the design considerations of token-based systems. The conceptual framework that evolves from this is shown in Figure 2-5 and helps to understand the simplified theoretical context of designing token-based systems. The design considerations eventually lead to the final design of a token-based system, where after implementation leads to the performance of a token-based system.

Figure 2-5: Conceptual framework

Neither the conceptual framework nor theoretical background specifically describes what organisational and environmental characteristics influence specific design considerations and how they influence these. Neither is it known what specific design considerations practitioners make and why they make these. This is related to the fact that little to no empirical studies about these subjects are conducted (Riezebos, 2010). Next to this, it is not known if the suggested design considerations by literature are needed (Gershwin, 2000; González & Framinan, 2009). Therefore, empirical evidence is needed that describes how organisations design token-based systems, what factors influence the design considerations and how they have influence on these considerations.

Organisation

● Operations strategy ● Support systems ● Process time variety ● Flow variety

Configuration

● Single card vs. dual card ● Load based vs. unit based

● Product specific vs. product anonymous vs. route-specific control

Performance Environment

● Product variety ● Volume variety ● Inter-arrival time variety

Structure

(21)

3 Methodology

The methodology of this study describes how the research is designed, cases are selected, the data from these cases is collected and how the data will be analysed, in order to answer the research statement. Next to this, the methodology describes how the ethics guidelines are followed during the case study. This chapter finalises with an overview of the cases selected and their characteristics.

3.1 Research design

In order to explore what design considerations practitioners make and why they make these considerations, a multiple case study was conducted. Since a profound understanding on how token-based systems are designed from a theoretical perspective is obtained, case studies are especially valuable as they provide the opportunity to explore and describe key insights in real life phenomena. A multiple case study is chosen as it is considered the most suitable for exploratory research (Yin, 1981) and since it provides the best opportunity to obtain key insights in the design of token-based systems of practitioners.

A case study is described by Yin (1981, p. 23) 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”.

The study aims to provide new knowledge in the field of system design of token-based systems. Because of the complexity e.g. multiple systems and variables, other research methods like experiments and surveys, are less suitable (Yin, 1981). To make the findings more robust and generalizable, multiple cases are selected as it allows comparing findings between cases and remove data that is only seen in one single case (Eisenhardt, 1989; Eisenhardt & Graebner, 2007; Yin, 1981). Lastly, a multiple case study was chosen as it enables a broader exploration of the research statement (Eisenhardt & Graebner, 2007).

3.2 Case selection

(22)

token-based system in place, which is one of the prerequisites of the study. The other organisation did not provide enough information for a thorough Kanban case analysis. Unfortunately, the organisation did not have time for a second interview. Next to this, acquiring extra data was found not to be essential for the case analyses, as the optimum amount of cases is based on satiation (Eisenhardt, 1989) and input from six valuable cases was already obtained.

The unit of analysis of each case analysis is the production system, which may be fully or partial controlled by a token-based system. This unit of analysis is chosen as token-based systems are often used to support production (Monden, 2012). In these cases, the characteristics of the production system may have an influence on the design of token-based system and are less subjective to the environmental characteristics.

The focus of the research is on small and medium-sized Enterprises (SMEs) as these organisations often implemented these type of systems (Stevenson et al., 2005). SMEs are characterised by the European Union (2005) as organisations with no more than 500 employees. Cases from these types of organisations provide especially valuable input as the scale of the organisations do not limit a thorough analysis. Case studies often become difficult in large organisations since they become time-consuming and often result in the accumulation of large amounts of data (Yin, 1981)

3.3 Data collection and ethics

In order to enhance data triangulation, multiple forms of data from different sources, were obtained per case in order to ensure the internal validity (Bowe, Voss, & Thomas Aretz, 2009). Internal validity is defined by Merriam (2002, p. 25) as: “the congruency of the

researcher’s findings with reality, where reality is the researcher’s interpretation of the participant’s perceptions or understanding of the topic of interest”. Triangulation, through

(23)

The main ethical consideration in this study is to protect the confidentiality and anonymity of the participants. Therefore, all the data that was obtained has been anonymised in order to reduce the risk of exposure of the organisations that participated. Primary data for the case analyses is retrieved from semi-structured interviews with a variety of individuals who are employed in the organisation. These employees are working in higher hierarchical functions in the organisation and were involved during the design and implementation of the system. This implies that most of these individuals are able to oversee the entire system, the design considerations and are aware of aspects involved during the design. Semi-structured interviews were chosen because they offer the flexibility to approach the interviewees differently, while getting the required data from different perspectives (Noor, 2008).

The interviews took approximately 40 to 90 minutes per interview and were all conducted face-to-face, in Dutch. This language was chosen in order to prevent miscommunication and generate complete in-depth answers. The length of the interviews differs, as they are semi-structured allowing to get more insights from certain perspectives. The interview protocol and a consent form can be found in Appendix A. These documents were given to each interviewee a week before the interview in order to give the interviewee the time to prepare and look up facts and figures about the organisation and system. All the interviews were recorded using digital voice recording software where after a literal transcript was made accordingly. After reviewed by the interviewee, the interviews were used as input for the analyses.

(24)

3.4 Data analysis

In order to compare the different cases with each other, the characteristics explained in the conceptual framework must be measureable. This section describes how a unified framework is developed for measuring these characteristics. Next to this, this section describes how generic token-based systems (Kanban, Conwip, Polca) handle these characteristics. This base case serves as a benchmark for the between case analyses.

Process time variety

The process time variety is measured through the assessment of interviewee and gives a fair understanding on the amount of process time variety in the production system. The scales will be based on the qualitative input from the interviews and will be ranked from low (1) to high (6). It is expected that Conwip systems tend to handle processing time variety better than Kanban, as Kanban is intrinsically a system for repetitive manufacturing (Hall & Society, 1983). Moreover, Framinan (2003) describes that several authors show through simulation that Conwip outperforms Kanban when processing time variability increases. Riezebos (2010) describes that Polca systems tend to handle the processing time variety better than Conwip. The base case is therefore defined as follows: Kanban is expected to operate in environments with little process time variety (2), Conwip with medium (4) and Polca in environments with much process time variety (6).

Flow variety

(25)

Product variety

The amount of product variety has been characterised as low, medium or high. If the organisation produces a single item, the variety is categorised as low (1), whereas medium (3) refers to a couple dozen different products and high (6) refers to the fact that not a single product is the same. It is expected that Kanban is widely implemented in repetitive manufacturing environments (Kumar & Panneerselvam, 2007), as the Kanban cards are related to specific products. Therefore, it is not suitable in environments where there is much product variety. Conwip and Polca do not have these characteristics and therefore tend to operate better under environments where there is more product variety. Riezebos (2010) describes that Polca performs better than Conwip in complex job shop types, due to its ability to control large varieties. Hence, Kanban is expected to operate best in environments with little product variety (2), Conwip medium (4) and Polca in organisations with much product variety (6).

Volume variety

Volume variety is described as the experienced difference in volume per order. The scale that is used to measure volume variety ranges from 1 to 6, where 1 represents no volume variety and 6 is related to extreme volume variety. Low volume variety (1) can be related to a stable amount of volume per order, e.g. every customer orders one product. Medium variety (3) is that a customer can order between one and a dozen products and high volume variety (6) is related to a diverse variation in the amount of products per order. Kanban is widely implemented in repetitive manufacturing environments (Kumar & Panneerselvam, 2007) and cards are related to specific amounts and specific products. Therefore, dealing with an increase or decrease in volume is more difficult to deal with than Conwip or Polca. The difference between Polca and Conwip is however limited as both systems handle these types of variety equally (Dogger, Land, & Foreest, 2010). However, it may be difficult to increase or decrease capacity, as the amount of cards need to be recalculated. Kanban is expected to operate in environment with little volume variety (2), and both Conwip and Polca in environments with a medium amount of volume variety (4).

Inter-arrival time variety

(26)

the amount of vacations booked during school holidays. High demand variety (6) is related to a very steep peak in demand, e.g. a supplier of Christmas decoration. Kanban is widely implemented in repetitive manufacturing environments (Kumar & Panneerselvam, 2007) and cards are related to a specific amount of products. Therefore, dealing with an increase or decrease in volume is more difficult to deal with in a Kanban system than in Conwip or Polca. However, also in these systems it may be difficult to increase or decrease capacity, as the amount of cards needs to be recalculated. Kanban is expected to operate in environment with little inter-arrival time variety (2) and both Conwip and Polca in environments with a medium amount of volume variety (4).

Operations strategy

The operations strategy is divided into six typologies: ETO, BTO, MTO, ATO, MTS and STS. The decoupling point for STS strategies is located the most far downstream and the closest to the customer, which is indicated with a low score (1). The ETO decoupling point is located the most upstream which is indicated by a high score (6). In between there, are BTO (5), MTO (4), ATO (3) and MTS (2). The (ordinal) score rates the place of the customer order decoupling. Kanban systems are mostly used in MTS (2) environments (Gaury, 2000), whereas Conwip and Polca are often used in MTO (4) environments (Stevenson et al., 2005).

Support systems

The only factor that cannot be classified is the presence of support systems, as these are pure categorical factors and each system influences the design differently. Next to this, most of the cases have multiple support systems in place, which makes ranking complex and hard to read. These factors will therefore be described separately in the analyses.

3.5 Organisations

(27)

Case System Production strategy Production volume (p/y) Batch size Different products (p/y) Routing variety

Support systems Number of interviews Information obtained Inter-arrival time variety Organisation A Conwip and Kanban

MTO / ETO 1000 – 2000 1 8 -9 GJS 5s, TPM, Conwip &

Process control

3 Interviews

Data Observations

Low

Organisation B Kanban MTO 12.500 1 – 30 8000 - 10000 GFS Lean, 6S 2 Interviews

Observations

Medium

Organisation C Kanban MTO 1200 1 1000 GFS 5S, lean 1 Interview

Observations Data

Medium

Organisation D Kanban MTO 700 – 720 1 – 10 17 GFS Projects related to

productivity, safety, delivery and Kai Zen

1 Interview

Observations

Low

Organisation E Kanban MTS / MTO 5000 1 – 50 5000 PFS Lean 1 (2 persons) Interview

Observations

Medium

Organisation F Kanban MTO / MTS 4000 1 100 GFS Lean, 5S 1 Interview

Observations Data

Medium

Organisation G Polca ATO 2500+ 0 – 16

hours

250 GJS QRM 1 Interview

Observations Data

Low

Organisation H Conwip MTO / ATO 60.000 50 -500 800 GFS Lean, 1 Interview

Observations

Low

Organisation I Polca MTO 1500 – 2000

orders

2 - 2500 500 GJS QRM 1 Interview

Observations

(28)

4 Analyses

This chapter describes the between case analyses of the Kanban, Conwip and Polca systems from the case study in order to make the findings more robust, generalizable and remove data that is only seen in one single case. Next to this, the between case analyses describes how the cases relate to the defined base cases in chapter 3.4.

After this, the cross-case analysis compares the findings from the different systems with each other in order to find out if the same characteristics influence the same design considerations of different systems and if practitioners make the same design considerations. Next to this, it aims to find out when specific design considerations are not suitable. The chapter concludes with an overview of the results. This section describes what the main influencing factors are and how they influence the design of token-based systems.

The individual case analyses have been described in Appendix B to Appendix J and can be used as reference if specific information related to design considerations, environmental or organisational characteristics are needed. The appendices describe how the environmental and organisational factors, described in the conceptual framework, influence the structure and the configuration of the system. Next to this, if other factors influenced the design of the system, they have been described separately. Moreover, if other design considerations are made, they have been described in the appendices.

(29)

Table 4-1: Design considerations token-based systems

Kanban systems Organisation A Organisation B Organisation C Organisation D Organisation D Organisation D Organisation E Organisation E Organisation F Organisation F Organisation A Organisation H Organisation I Organisation G

Kanban in assembly department Kanban buffer system with central warehouse Kanban buffer system with central warehouse Kanban in assembly department Supplier filling Kanban Kanban buffer system with central warehouse Kanban buffer in assembly department Kanban in Warehouse Kanban buffer system with central warehouse Kanban to control production of sub-assemblies Conwip to control production Conwip to control part of production Polca to control production Polca to control assembly department Configuration

Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card Single card

Dual card Type of card

Load based

Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based Unit based

Unit based (with limitations)

Material flow

Product specific Product specific Product specific Product specific Product specific Product specific Product specific Product specific Product specific Product specific Product specific

Product anonymous

Product anonymous

Route specific Route specific Route specific

Control

Central Central Central

Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral Decentral

Structure

Traditional Traditional Traditional Traditional Traditional Traditional

Segmented Segmented Segemented

Joint Loops

Connected Connected Connected Connected Connected Connected Connected Connected Connected Connected Connected Connected Connected Connected

Unconnected Unconnected Number of cards Card setting Based on 6 months or 9 months usage Based on usage and feeling Based on usage and size Based on usage

and size Based on usage Based on size Based on feeling

Based on usage

and delivery times Based on demand Based on demand

Based on capacity Based on caclulation Based calculation Based on calculations / capacity Card controlling

Once a year Once a year Each quarter Yearly Yearly Yearly Multiple times a month

Multiple times a year

Multiple times a

year Weekly Not adjusted

Adjusted if shortages occur Based on expirience Based on expirience Order release

Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting Load limiting

Load balancing Load balancing Load balancing

Order dispatching

Conserving flow

Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow Conserving flow

Conserving flow (some exceptions) Conserving flow (some exceptions) Conserving flow Conserving flow (some exceptions) Improving througput Reducing lateness

Other No use of physical _card Electronic support _through PDA Electronic support _through ERP Electronic _support

(30)

4.1 Between case analyses 4.1.1 Kanban

As described in Table 3-1 and Appendix B to Appendix J, multiple Kanban systems have been seen. The organisational and environmental characteristics of the cases, as described in the methodology (operations strategy, process time variety, shop-floor configuration, volume variety, inter-arrival time variety and product variety), have been ranked and are set forth in Figure 4-1. Moreover, the expected Kanban base case, defined in chapter 3, has been included.

Figure 4-1: Kanban comparison

As shown in Figure 4-1 , the organisational and environmental characteristics of all the Kanban cases vary and the cases do not match the expected base case. This is expected as all the Kanban systems from the case study are used to support the (main) production process and are adapted to that process. The characteristics of these support systems would match the base case as the systems are designed to match this typology. The next section describes how these systems have been adapted to match the Kanban typology.

(31)

The operations strategy of all cases has been defined as MTO. However, all the systems are used to support the main production process by controlling a specific part of the production process or by supplying parts. Therefore, all the Kanban systems operate on a MTS strategy and the characteristics of these support systems would therefore match the base case.

Four out of six cases described that they designed the Kanban system because they implemented Lean. One of the organisations acknowledged that Kanban was implemented because a consultant advised this and the last organisation works with Kanban as it was copied after demerger and consultants advised the continuum of this system. Support systems therefore initiate in most cases the development of token-based systems. Next to this, multiple organisations use electronic support systems (ERP/MRP systems or PDA-scanners) to simplify the operation of the system and get real-time insight in specific indicators.

The second factor that was defined in the conceptual framework is process time variety. This type of variety does however not influence the design considerations of the Kanban systems in the case study.

The shop floor configuration directly influences the Kanban design. Most cases are defined as general job shops or general flow shops and specific parts, controlled through the Kanban, are needed in each workstation. The location of these parts is however fixed and there is no flow variety. The location of the products is therefore one of the first steps in determining the structure of the system. However, this does not hold for all cases. This is shown in the case of organisation A. This organisation is planning to switch to order picking as too much indirect time is spent on acquiring parts and the Kanban way of working is often ignored. The limited amount of products needed per order, make order picking feasible.

(32)

Volume variety in combination with inter-arrival time variety are important aspects that influence the design of a Kanban system. This type of variety is also noticeable in the parts that are needed to build the products. These types of variety increase the need of large buffers in order to cope with peaks in demand. Often there is not enough available floor space, causing the need for a segmented structure and a central inventory. Another option may be to temporarily enlarge the buffers during peaks in demand or to improve the supplier delivery times. However, none of the organisations is willing to enlarge the buffers, since changing the configuration is time-consuming, peaks in demand are often unknown and there is in most cases a limited amount of available floor space. Next to this, the supplier delivery times can in most cases not be improved.

Next to the characteristics that were defined in the conceptual framework other factors have been found that influenced the design of Kanban system. Most of these factors are related to specific organisational and environmental characteristics. Next to this, specific product characteristics are found that influence the design of the system.

Product characteristics influencing the design are related to the physical dimensions and the price of products. Four out of six organisation indicate that the physical dimensions increase the need for a central warehouse and a segmented structure as there is a limited availability of floor space. Next to this, the price of products is seen in two cases as a factor that determines the applicability of Kanban. Organisations prefer to control cheaper parts with Kanban, for maintaining minimum amounts of inventory. Expensive products are controlled with MRP-system, as these products have more influence on the total value of the inventory and are of greater importance for the continuum of the production. Next to this, these electronic systems can reserve stock and anticipate on future demand, which cannot be controlled through Kanban.

(33)

Some parts that are controlled through Kanban are used in multiple workstations throughout the organisation. Examples are nuts and bolts. Scales of economy would be limited through traditional structures, as it would lead to multiple, small purchasing orders. By using a segmented structure, inventory levels can be controlled centrally, scales of economy can be obtained and processing times are limited.

Two of the case organisations specifically designed the Kanban system in order to create a uniform way of working and reduce the mistakes made (fool-proofing). The bin-sizes at organisation F are adapted on the amount of sub-assemblies that need to be made. These Kanban bins contain the exact amount of parts that are needed to build a specific sub-assembly. This fool-proofing method limits rework in later stages.

Next to this, multiple environmental factors are found that influenced the design of the system. Multiple cases provide evidence that the organisations are often bounded to minimum order quantities when buying products. Next to this, delivery times are sometimes long. These factors relate to the design consideration of a segmented or traditional structure. Next to this, two out of six organisations are bounded to consumer trends in the market. Parts can become obsolete (old-fashioned) and therefore inventory levels are controlled centrally using MRP-software, to anticipate on future demand.

(34)

4.1.2 Conwip

As described in Table 3-1, Appendix B and Appendix I, two Conwip systems have been seen during the case analyses. The organisational and environmental characteristics of the cases, as described in the methodology, have been ranked and are set forth in Figure 4-2. Also, the Conwip base case has been included, which serves as a benchmark from literature.

Figure 4-2: Conwip comparison

The characteristics of both organisations are relatively similar and fall in line with the characteristics under which Conwip systems are expected to operate. Conwip systems offer advantages over Kanban systems as the system makes use of a release list, which is used in both organisations to improve bottleneck utilization and distribute the workload over the different workstations. This is of great importance, since the machines of organisation A must be fully utilised and often have large set-up times. Next to this, the stock levels at the main production line of organisation H may not become the bottleneck.

(35)

related to specific internal costumers. Central control is therefore preferred, as the organisation does not want to hold stock between workstations for each customer.

Both of the organisations actively try to optimize the production using the principles of Lean. However, the most important support system is the use of the release list, which is a specific design consideration to control and distribute workload. In the case of organisation H, it is used to determine the production sequence and is automatically generated if the inventory levels drop below a certain threshold at the main production line. In the case of organisation A, the release list is of great importance, since it is the only option to determine the production sequence, distribute the workload over different machines and anticipate on due dates. Next to this, the machines of organisation A often have large set-up times. The employees preferred clustering orders, previous to the Conwip system, in order to reduce the set-up times and improve the efficiency, which was disadvantageous for other orders as these were delayed. The release list therefore controls the production sequence.

The flow variety is limited in both organisations. All the orders start in the same cell and end in the same cell. Next to this, there are only a couple different cells. The central control of Conwip is therefore expected, as the organisation is able to oversee the entire system and the organisation can rely on input control. Both organisation do not experience volume, product or inter-arrival time variety and these factors do not influence the design of the system.

(36)

4.1.3 Polca

As described in Table 3-1, Appendix H and Appendix J, two Polca systems have been seen during the case analyses. The organisational and environmental characteristics of the cases, as described in the methodology, have been ranked and are set forth in Figure 4-3. Also, the Polca base case has been included, which serves as a benchmark from literature.

Figure 4-3: Polca comparison

This figure shows that the characteristics of both organisations are similar and are in line with the expected base case that was defined from Polca literature. Both organisations are committed to QRM, which in both cases initiated the design of the Polca system. Both organisations designed specific support systems that help to control the production. In the case of Company I, an (in-house developed) software package controls the release and dispatching of orders. in the case of organisation G an electronic tool supports the release decision. The importance of the release list is in both cases severe as it limits and distributes the workload. Both organisations are characterised as general job shops and all work is released in a single cell. The release list anticipates on future workload and tries to distribute the workload over different cells evenly. In both cases, this control is needed as the variety in products, flow, processing times and volumes are high.

(37)

the division of capacity. Card controlling is not described in the conceptual framework. However, important lessons can be learned from both organisations. Both organisations stated that they have too much cards in their systems, as the organisations do not want to let the production run dry downstream. The experienced process time and volume variances are in both cases large and increasing the number of cards seems to make the system more stable. Input control is used to control this variety. However, even with these limitations, there are often imbalances in workload across different workstations. A result of this is that in both cases the cards do not act as a blocking mechanism, but are only used to control the transfer of jobs between workstations.

Next to this, the production system is dynamic in shifting capacity from one cell to another. This capacity is shifted if cells experience an increase in demand and other cells run dry. Organisation G uses a board that controls the division of capacity over work cells. This board indicates how many employees are working in a specific cell and how much there should be working, in order to anticipate on workload peaks in specific cells (which is indicated through the electronic release list). Prerequisite for this, is the cross-training of employees. In order to further improve the production and get exact insight in the workloads per cell, both organisations want to make the shift to load-based Polca.

The production volume, as described in Table 3-1, is in both cases based on the number of orders per year, as the number of products per year does provide much information. The experienced variances in products and volumes limit these insights. Both organisations do not experience any inter-arrival time variety and this factor does not influence the design. The last design change that has been made is that both organisations tend to reduce the complexity of the system. Organisation G made the cards cell-specific instead of route-specific as the number of cards made the system too complex to operate. In the case of Company I, this factor is of less importance since an electronic system controls the order release and dispatching. As the initial amount of cards was raised in both cases, the cards do not function as a blocking mechanism and making the cards cell-specific instead of route-specific is of less influence.

(38)

seen. The first system controls the division of capacity on the production floor and the other system controls the workload to the production floor.

4.2 Cross case analysis

Table 4-2 summarizes all the characteristics that influenced the design of the token-based systems, derived from the case study. If the characteristic had no influence on the design considerations of the token-based system in any cases, it is indicated by a minus sign (-). If a characteristic influenced the design of the token-based system in less than half of the cases, it is indicated by a ‘X’ and if the characteristics had influence on the design considerations in more than half of the cases it is indicated by ‘XX’.

The table shows two distinctive clusters in the characteristics that influenced the design of token-based systems. The first cluster, in the upper right corner, are the factors that

Characteristic Kanban Conwip Polca

Or ga ni sa ti on al ch ar act er is ti cs Operations strategy - X XX Support systems X XX XX

Process time variety - X XX

Shop floor configuration - X XX

En vi ro nm en ta l ch ar act er is ti cs Product variety _X _X _XX Volume variety _- _XX _XX

Inter-arrival time variety _XX _- _-

Ch ar ac te ri st ic s de ri ve d ca se s tu dy Number of products XX Physical dimensions XX - - Price X X - Organisational pressure X - -

Usage on multiple locations X - -

Fool proofing X - -

Minimum order quantities XX - -

Supplier delivery times XX - -

Consumer trends X - -

Customer buying power - X -

(39)

also set forth in the theoretical background. The second cluster, in the bottom left corner, shows that other factors influence the design of the Kanban cases. This comparison implies that the systems are designed in different ways, as different characteristics influence the design considerations.

Next to the characteristics that influence the design, multiple design considerations have been seen during the case analyses which are not set forth in the conceptual framework. In all Conwip and Polca cases, the level of electronic system integration in the production system is high. These tools are used to control specific aspects in the production system. All organisations in the Polca and Conwip cases use electronic tools to apply the principles of WLC. Next to this, organisation G designed a board that controls the capacity in different workstations. These sub-systems are used to control complexity and make the token-based system stationary. Making the systems stationary implies that the organisations do not change the structure nor the configuration, but rather use sub-systems to control specific aspects, such as input control and capacity division. The organisations do not want to change the number of cards in the systems, as they perceive this as being complex. As the organisations dynamically shift capacity between workstations and the number of cards is raised explicitly, the blocking mechanism becomes obsolete and has little influence. If the capacity in a cell is changed, the number of cards should be changed accordingly. However, organisations try to avoid this complexity.

In both Polca cases, the organisations tried to simplify the systems as the amount of cards become unmanageable by hand. In the case of Organisation I, this is managed by using an electronic system that controls the order release and dispatching. In the case of organisation G, this factor is managed by cutting the cards into two and relate capacity to cells. By doing this, the number of different cards is decreased significant (from roughly 72 to 9).

(40)

4.3 Overview of results

This section provides an overview of the design considerations made by practitioners and the most important factors influencing these. Next to this, it provides an overview of the sub-systems practitioners tend to use to control variation aspects in the production system. The first and most distinctive difference in the design of token-based systems is related to the production strategy of the token-based system. Practitioners tend to use Kanban systems if the token-based system operates on a MTS strategy and either Conwip or Polca if the token-based system has a MTO strategy. The design considerations for these types of systems are visually represented in Figure 4-4. This figure serves as a guidance for making considerations during the design of token-based systems. However, the decision tree does not rule out any specific design considerations and decisions should be taken with care.

Figure 4-4: Overview of design considerations

Practitioners tend to use two types of token-based systems in MTO environments: Conwip and Polca. The most distinctive factors influencing the decision for these token-based

Token-based systems Product variety Conwip Polca Complexity reducing mechanisms ● Input control ● Electronic systems Complexity reducing mechanisms ● Input control ● Capacity division ● Electronic systems

Flow variety Process time variety Kanban

Complexity reducing mechanisms ● Electronic systems

Segmented structure

Traditional structure

Single card Single card Connected

loops Connected loops Decentral

control

Decentral control

Traditional structure Traditional structure

Single card

Central control Decentral control Connected loops

Unit based

Unit based Unit based Unit based

Product specific Product specific Product anonymous control Route specific control

Connected loops Single card

MTS MTO

(41)

Conwip, whereas practitioners tend to use Polca if these types of variety are in the higher segment. After this distinction, the design follows the suggested considerations provided by literature.

Practitioners tend to use Kanban in MTS environments. The most distinctive consideration in the design of these systems is related to choosing a traditional or segmented structure (joint structures have not been considered, as these have not been seen during the case analyses). After this decision, the design follows the suggested considerations provided by literature. Choosing the correct type of structure is related to specific organisational, environmental and product characteristics which are derived from the case study. The decision tree for choosing a structure is defined in Figure 4-5.

Figure 4-5: Segmented or traditional structure

The default choice is always a segmented structure and if all conditions are satisfied a traditional structure is suitable. The numbers in the boxes relate to the decision that needs to be made.

1) The first distinction is related to the number of different products. Four out of six cases show that central (MRP/ERP) control is preferred if the number of products becomes unmanageable by hand.

2) The next factor is a combination between volume and product size. High volumes relate to larger buffers (assuming that processing times are stable). Decentral control for small products, in high volume, may be possible. However, if products become larger, the needed amount of floor space can increase rapidly. Three cases provide evidence that segmented structures are needed in these cases.

3) Bin-sizes are determined based on a specific demand in a specific time unit. If this demand varies greatly during the year, bin-sizes need to be adjusted or the

Design considerations of token-based systems: A multiple case study in small and medium-sized enterprises