# Achieving Balanced Workload Distribution Amongst Cross-Trained Teams

Oladipupo Olaitan, Erlend Alfnes, Jørn Vatn, Jan Ola Strandhagen

► To cite this version:

Oladipupo Olaitan, Erlend Alfnes, Jørn Vatn, Jan Ola Strandhagen. Achieving Balanced Workload Distribution Amongst Cross-Trained Teams. IFIP International Conference on Advances in Production Management Systems (APMS), Aug 2018, Seoul, South Korea. pp.355-363, 10.1007/978-3-319-99704-9_44. hal-02164860

HAL Id: hal-02164860

https://inria.hal.science/hal-02164860

Submitted on 25 Jun 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Achieving Balanced Workload Distribution Amongst Cross-Trained Teams

Oladipupo Olaitan[0000-0002-4604-2543], Erlend Alfnes[0000-0002-9892-3916], Jørn Vatn[0000-0002-7562-0672] and Jan Ola Strandhagen[0000-0003-3741-9000]

Norwegian University of Science and Technology (NTNU), Trondheim, Norway
oladipupo.a.olaitan@ntnu.no

**Abstract.** This research is focused on improving the flow of items through the cross-trained teams of a leather furniture manufacturing company, which manufactures a high mix of products. Presently, a Push control strategy is applied to control production, but this causes uneven build-up of items for processing (i.e. workload) at the cross-trained teams. Hence, this research investigates the application of the CONstant Work In Process (CONWIP) strategy to control Work in Progress (WIP) and at the same time ensure balanced workload distribution amongst the teams. It uses the release signal from downstream to monitor the work rate of individual teams and regulate the release of new items for them to process. Results of simulation experiments conducted on the system show that the application of CONWIP, particularly with consideration of the cross-trained teams in its item release decisions, ensures a balanced distribution of workload amongst the teams. This eradicates the constant need for human intervention to redistribute items between the cross-trained teams, which is a current challenge for the case study company.

**Keywords:** CONWIP, Cross-trained Workforce, Workload Control.

## 1 Introduction

The research presented in this paper is part of a project titled SØM 4.0, which is aimed at streamlining and improving the process flow at a furniture manufacturing company. The manufacturing line consists of four upstream lines that produce and supply components for subsequent assembly at a downstream stage. Chair covers are manufactured through the cutting and the sewing sections, before being assembled with foam from another line, to make the upholstery. The upholstery sub-assembly then undergoes assembly with wood and steel components, which also come from two other production lines. Each of the high variety of product models manufactured in the system requires unique components from the upstream component production lines. The cover production line is the main manufacturing stream into which raw materials are released and operations are planned according to specific customer orders. The other manufacturing lines must then supply components to meet the planned arrival dates of the covers for assembly. As a result, this paper focuses on streamlining the flow of items through the cover production line.
The rest of the paper is organised as follows: Section 2 provides a background on related literature, followed by an overview of the cover production line. In Section 3, the company's existing Push control strategy and the implemented CONWIP control strategy are described. Section 4 will describe the setup of the simulation experiments conducted to compare both strategies. The results of the experiments are analysed and discussed in Section 5, followed by conclusions and practical insights for practitioners.

## 2 Background

Pull production control strategy involves the use of cards, called Kanbans, to control production and regulate system inventory [1]. The Kanbans limit the number of parts in the system, because parts require Kanbans to authorise their processing in the system, and parts that are unable to obtain Kanbans are kept in a queue that serves as a backlog list. There have been strategies developed to suit manufacturing environments that differ from that for which the traditional Kanban control strategy (TKCS) was originally developed. An example is the CONWIP strategy [2], which provides a means of applying pull control in multiproduct environments, and in environments with relatively higher levels of variability, because of its more open assignment of Kanbans amongst products — i.e. its Kanbans can be product-anonymous [3]. Other strategies that have been developed subsequently, such as Generic Kanbans [4] and Extended Kanbans Control Strategy (EKCS) [5], also offer the possibility to have an open assignment of cards when different types of products or components are involved [6].

### 2.1 Item Release Rules

For a single product system, items in the backlog list are released based on their order of arrival into the queue. However, in multiproduct systems, in which many attributes would differentiate product types from one another, there is usually a need to define rules based on which items are selected for release from the backlog list. As such, the application of pull control strategies in multiproduct environments comes with a new challenge of deciding on the item to select for release into the system upon the availability of a new Kanban. Research works have found that defining rules for the sorting and release of items into a system can be used to improve its performance [7, 8]. For example, a study found that implementing a backlog sequencing rule has significant impact on the performance of CONWIP, specifically the capacity slack-based rules which they implemented [7]. Item release rules operate by selecting for release the item type whose attribute most fits the attribute favoured by the rule. Some of the attributes that are considered are the items' due dates, lengths of processing times, numbers of processing steps, planned release dates or the amount of slack from their due dates etc., and the item that ranks top based on the attribute is released.

Alternatively, there are rules that do not only consider the current items in the backlog list, but also those that are currently in the system [9, 10]. For instance, the rule applied in a study aims to always maintain a balanced mix of item types in the system. Thus, it selects the next item type for release in order to ensure that a desired balance is maintained in the mix of item types [10]. Similarly, the capacity slack-based rule of
another study seeks to achieve balance in the system, but of the overall system workload
[7]. It considers the current workload situation on the shop floor when taking item re-
lease decisions, and selects for release the item that will not violate the workload bal-
ance. Such studies set limits on the system workload and quantify every item release in
terms of its workload implication on the system.

This study will apply a similar two-layered item release rule in which the planned finished dates are first applied in sorting items in the backlog list, followed by selecting them for release based on the availability of a suitable operator team to process them downstream. Releasing items according to their planned finish dates should ensure that they arrive close to their planned dates for downstream processes, while the consideration of available capacity at the teams ensures that process-based constraints are considered when releasing items.

## 2.2 Overview of Cover Production Line

The cover production line of the case study system is a typical example of high mix production. The product line consists of 36 different models, most of which are offered in two or three different sizes (small, medium and large). Additionally, each model size is offered in fabric or leather material, which can also come in different variety of colours and material textures. The product differentiation starts right from the first production step in the cutting section, where the model design and materials are configured specifically for a product.

The materials for the covers are cut in Step 1 (S1) followed by them undergoing variety of sewing operations between Steps 2 and 10 (i.e. S2 to S10). S1 is the cutting section, while S2-S10 constitute the sewing section.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Process Flow Chart from Cutting to Sewing</figcaption></figure>

The outputs from the sewing section are chair covers that undergo assembly with foam, and subsequent assembly with wood and steel components to derive the finished furniture. This work focuses on the sewing section, which has the most labour intensive and value-adding processes of the whole production. The routing possibilities through these processing steps differ from one product model to another, as shown in **Fig. 1**. Also, at S8 there are four cross-trained operator teams that are skilled in the processing of specific product models only, and the teams have different levels of proficiency for product models.

The company currently applies Push control strategy to release items that arrive from cutting into sewing. However, the direct release of semi-finished items from the cutting section (S1) into the downstream sewing section creates a constant need for human intervention in the automated transport system to redistribute workload between the four teams and ensure smooth flow of items through the system.
## 3 Production Control in the Cover Production Line

In this section, the logic of the current Push control strategy of the company is described, followed by a description of the logic of the implemented CONWIP control strategy. The two control strategies are subsequently compared using simulation experiments, which are set up based on 4 months of historical data from the case study company.

The approaches to controlling WIP, taking item (trolley) release decisions and assigning trolleys to the cross-trained teams are the main targets for improvement in this work; therefore, the current and the new approaches will be described in the following subsections using similar set of notations as follows:

- $MC_{g[i-j]}$ = the set maximum WIP limit for team g between stages i and j.

- $MC_{[i-j]}$ = the set maximum WIP limit in the system between stages i and j.

- $CC_{gt[i-j]}$ = the current WIP level of team g between stages i and j at time t.

- $CC_{t[i-j]}$ = the current WIP level in the system between stages i and j at time t.

- $A_{gt}$ = the availability of team, g, at time, t, i.e. it checks whether the team has reached its set maximum at that time.

$$A_{gt} = \begin{cases} 1, & \text{if } CC_{gt[i-j]} < MC_{g[i-j]}, \\ 0, & \text{otherwise.} \end{cases}$$

- $S_{gm}$ = preference level of model, m, for team, g. $S_{gm}$ can have a value of 90, 80 or 0, which respectively identify that team, g, is a primary, secondary or incompatible team for model, m. Those values are mainly to differentiate the levels of proficiency of teams for the different product models. The higher the value of $S_{gm}$ the stronger the preference of a product model for a team.

It should be noted that under both control strategies, the respective teams process the trolleys that have been released to them according to the trolleys' due dates.

### 3.1 Push Control Strategy

As shown in Fig. 2, there is currently no limit on the system WIP; therefore, the only WIP restriction that applies is that which is used to determine the availability of the primary team for a trolley's model. The current level of $CC_{gt[8-8]}$ with respect to $MC_{g[8-8]}$ at the time of arrival, t, of the trolley determines the team it selects for its processing.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Process flow with Push Control</figcaption></figure>

When a trolley arrives at S8 for processing, it is released to the team with the highest value of ($A_{gt} \times S_{gm}$) + $S_{gm}$. This expression checks for the availability of the primary
team for the model conveyed by the trolley and releases it to the team (i.e. the team with $S_{gm} = 90$), if the team is available. If the primary team is not available, it checks for the availability of an alternative (secondary) team (i.e. from other teams with $S_{gm} > 0$). If no alternative team is available, then the $S_{gm}$ added in the expression implies that the trolley is nevertheless released to its primary team, even if it would violate the team's maximum WIP level restriction. It should be noted that the routing of a trolley between S4 and S7 and between S9 and S10 varies depending on the product model the trolley contains, as previously illustrated in **Fig. 1**.

## 3.2 CONWIP Control Strategy

CONWIP control strategy involves setting a maximum limit on the number of units of items that are allowed in a section of the system. It keeps track of the current number of items in this section and ensures it does not exceed a predefined limit.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Process flow and Release Decision Points for Trolleys – CONWIP</figcaption></figure>

As shown in **Fig. 3**, CONWIP has been implemented to control the WIP level between S7 to S8, such that the number of trolleys within this section does not exceed a set maximum WIP limit, $MC_{g[7-8]}$. The first five stages are left out of the CONWIP control loop, because they are relatively short operations. As such, there is relatively low competition for the resources used for these five operations, and it is not necessary to stop the trolleys from undergoing these five operations before determining if they should access the more resource-intensive operations or not. The same justification applies for the omission of the last two stages from the CONWIP loop, which makes the signal for the release of a new trolley into the CONWIP loop to be sent as soon a trolley is completed at S8.

When a trolley arrives at S7, there are two conditions under which it can be immediately released downstream:

1. If the trolley is urgent, i.e. it arrived one day or less from its planned finish date, it is sent immediately to the next stage of its processing. Because of its urgency, it is also assigned to the team with the lowest $CC_{gt[7-8]}$ and not necessarily its primary team.

2. At least one of the teams skilled to process its contents must be available (i.e. one of the teams with $S_{gm} > 0$ must have $A_{gt} = 1$), and the trolley is released to the team with the $Max[A_{gt} \times S_{gm}]$ amongst the available teams. This ensures that if the best skilled team is not available, an alternative team is selected to process the trolley.
Both conditions are aimed at improving the delivery precision to the subsequent upholstery stage and ensuring a balanced distribution of workload amongst the teams.

If none of the conditions for the immediate release of a trolley downstream is fulfilled, it is held in an intermediate queue until existing trolleys have been completed and released from S8. Once an existing trolley has been completed and released from S8, and $CC_{gt[i-j]} < MC_{g[7-8]}$, a signal is sent upstream to the intermediate queue to release a new trolley into S7. The decision on the new trolley to release considers the team that completed the last trolley whose release from S8 triggered the signal. It searches from the queue head and releases the first trolley containing a product model with $S_{gm} = 90$, where *g* is the team that processed the last trolley released from S8. If there is no trolley containing a model with $S_{gm} = 90$ in the queue, the search is repeated for trolleys containing models with lower values of $S_{gm}$.

Essentially, the release decision is combined with the selection of the team that will process the trolley upon its arrival at S8. Because of the cross-training situation, it is important to ensure to fill the exact capacity that is signalled to have become available downstream by ensuring that the team from which a trolley was completed is that for which a new one is released. The trolley released into the CONWIP loop does not have to contain an exact same model as that which was released from it, but it must contain a model that can be processed by the same team.

# 4 Simulation Experiments to Compare Strategies

To compare the current strategy's performance with the implemented CONWIP control, simulation experiments were conducted in FlexSim™ Modelling software using historical data from the case study company. The data covered a three-month period, during which 12,208 trolleys of cover pieces were produced. The data, which is available online [11], was used directly in running the simulation model, with a direct replication of the actual release dates and times of trolleys, their required processing steps and times, as well as the company working days, shift durations and the numbers of available operators per workstation/team during the period. The model was run as a terminating simulation, with the terminating condition being the exit of the last of the 12,208 trolleys from the system. The control strategy under operation determined the actual release times of the trolleys into the sewing section (or their CONWIP loops), as explained in Section 3. With this, it would be possible to attribute any differences observed in the two strategies' performances to the differences in their logics for releasing trolleys into the system and for assigning trolleys to teams.

## 4.1 Parameters and Settings of Compared Strategies

In addition to the general system settings, system parameters that are specific to each control strategy were set as shown in **Table 1**. As shown in Table 1, the maximum WIP limits for the teams were set such that each operator in the team would be working on a trolley and have an additional two that are waiting in the queue.
<table><caption>**Table 1.** Team WIP Limits</caption><thead><tr><th>Approach</th><th>Team A<br>MC<sub>A</sub>[i-j]</th><th>Team B<br>MC<sub>B</sub>[i-j]</th><th>Team C<br>MC<sub>C</sub>[i-j]</th><th>Team D<br>MC<sub>D</sub>[i-j]</th></tr></thead><tbody><tr><td>Push i = 8, j = 8</td><td>54</td><td>48</td><td>42</td><td>33</td></tr><tr><td>CONWIP i = 7, j = 8</td><td>72</td><td>64</td><td>56</td><td>44</td></tr></tbody></table>

The aim of having the additional two trolleys is to protect the operators against starvation, and the value of two was derived from the highest ratio between any two stages' throughput rates. Because the teams' WIP limits under CONWIP include trolleys that are still undergoing processing at S7, an additional trolley per operator was added in the teams' WIP limits. The overall CONWIP limit between S7 and S8 thus becomes the total of the team's WIP limits, i.e. 236 trolleys.

## 5 Discussion of Results and Conclusions

The performance measure of interest is the balanced distribution of workload amongst the cross-trained teams, which is measured based on the numbers of trolleys that are either queued for or undergoing processing at each of the teams. Under the Push and the CONWIP control, the workload is recorded for each of the teams across the entire simulation period. As shown in **Fig. 4**, CONWIP achieved a more balanced workload distribution between the teams than the existing Push control.

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Teams' Workloads as measured by Number of Trolleys</figcaption></figure>

The instances with large deviations between the plots in the graph are those in which the shift leader would have needed to manual redistribute the workload between the teams. Therefore, CONWIP, in combination with the item release rule implemented, eradicates the constant need for human intervention, as currently experienced under Push.
**5.1 Conclusions and Practical Insights**

In this work, CONWIP has been applied in a high mix manufacturing system to stream-
line the flow of the high mix of products through the system. Because of the cross-
trained workforce that is involved in the system, an item release rule that synchronises
CONWIP's item release with the outputs of specific teams. This rule ensured that the
teams receive items to process according to their individual work rates, and the constant
need for human intervention to redistribute items between the teams can be eradicated.
Results of the simulation experiments show that taking the item release decision with
this consideration ensures a balanced distribution of workload amongst the teams.

The increased affordability of technologies for tracking items through manufactur-
ing processes should facilitate the implementation of CONWIP as described in this
work. Less sophisticated technologies can also be used; for example, physical cards or
electronic display boards can be colour-coded for the teams, such that cards sent up-
stream for the release of a new item can be attributed to a specific team.

**Acknowledgement.** This research has been carried out as part of SØM 4.0 project, as funded by the Norwegian Research Council's BIA programme. The authors wish to thank the project partners for facilitating this work.

**References**

1. Ohno, T.: The origin of Toyota production system and kanban system. in Proceedings of the International Conference on Productivity and Quality Improvement, 3-8 (1982).

2. Spearman, M.L., Woodruff, D.L., Hopp, W.J.: CONWIP: a pull alternative to kanban. International Journal of Production Research 28, 879-894 (1990).

3. Duenyas, I.: A simple release policy for networks of queues with controllable inputs. Operations Research 42, 1162-1171 (1994).

4. Chang, T.M., Yih, Y.: Generic kanban systems for dynamic environments. International Journal of Production Research 32, 889-902 (1994).

5. Dallery, Y., Liberopoulos, G.: Extended kanban control system: combining kanban and base stock. IIE transactions 32(4), 369-386 (2000).

6. Baynat, B., Buzacott, J.A., Dallery, Y.: Multiproduct Kanban-like Control Systems. International Journal of Production Research 40, 4225-4255 (2002).

7. Thürer, M., Fernandes, N.O., Stevenson, M., Qu, T.: On the backlog-sequencing decision for extending the applicability of ConWIP to high-variety contexts: an assessment by simulation. International Journal of Production Research 55, 4695-4711 (2017).

8. Framinan, J.M., Gonzalez, P.L., Ruiz-Usano, R.: The CONWIP production control system: review and research issues. Production Planning & Control: The Management of Operations 14, 255-265 (2003).

9. Hopp, W.J., Roof, M.: Setting WIP levels with statistical throughput control (STC) in CONWIP production lines. International Journal of Production Research 36, 867-882 (1998).

10. Ryan, S.M., Fred Choobineh, F.: Total WIP and WIP mix for a CONWIP controlled job shop. IIE Transactions 35, 405-418 (2003).

11. Olaitan, O.A.: Data from Historical Production Records (dataset). Mendeley Data Repository. Accessed June 07, 2018. 10.17632/kszngyhpmt.1.