Refining a Workload Control (WLC) concept: a case study

Abstract

The paper focuses on refining a Workload Control (WLC) concept to improve the applicability of the approach to the shop characteristics found in practice. This is a two-stage process leading to significant conceptual refinements to a key WLC methodology. The first stage focuses on the development of a Decision Support System (DSS) based on a WLC concept designed for Make-To-Order (MTO) companies. Refinements made include changes to the backwards scheduling procedure and the way in which jobs are released onto the shop floor. The second stage focuses on the process of implementation. Using a case study of a MTO company, the paper describes the strategy taken to overcome a number of prerequisites to the successful implementation of a Production Planning and Control (PPC) concept. Issues addressed include grouping machines and determining capacities. This case study adds to the available literature by looking specifically at implementing WLC from the customer enquiry stage, while the case study experience also provides further refinements to the WLC concept.

Keywords:

• Production Planning and Control (PPC)
• Workload Control (WLC)
• Decision Support System (DSS)
• Make To Order (MTO)
• Job shop

1. Introduction

Workload Control (WLC) is a Production Planning and Control (PPC) concept designed for complex production environments, such as the job shop and Make-To-Order (MTO) industry, and originates from the concept of Input–Output Control (I/OC); see Wight (1970). In general terms, the input of work to the shop floor is controlled in accordance with the capacity of work centres (the output rate) through the use of a pre-shop pool and job release mechanism. WLC can lead to the reduction of shop floor throughput times and Work-In-Progress (WIP), whilst ensuring jobs do not stay in the pool too long in order to meet Delivery Date (DD) objectives (see, for example, Land and Gaalman 1996).

Contemporary research in the field of WLC is predominantly simulation based, for example Perona and Portioli (1998) and Henrich et al. (2003, 2004). Despite the WLC concept receiving much attention in the literature, only a handful of case studies have emerged (Bertrand and Wortmann 1981, Fry and Smith 1987, Bechte 1988, 1994, Hendry et al. 1993, Wiendahl 1995, Park et al. 1999). Although all of the aforementioned simulation studies explore practical issues, and are thus directly geared towards the application of WLC in practice, further empirical research is considered vital to the validation of simulation results (see Bertrand and Van Ooijen 2002, Kingsman and Hendry 2002).

One of the reasons for the lack of contemporary empirical research is the process of implementation. In order to effectively implement WLC in practice it is important to satisfy a number of prerequisites. These prerequisites are much easier to satisfy in simulation than in practice. For example, it can be necessary to group interchangeable machines and provide the rapid feedback of information from the shop floor, while accurate estimates of capacity are also required. Furthermore, it can be important for management to appropriately determine norms and parameters, such as for expected shop floor queuing times. Such requirements are not uncommon and are essential for the successful implementation of other PPC concepts. For example, Material Requirements Planning (MRP) has previously been criticized for requiring accurate estimates of capacity (see Wiendahl 1995), while Constant-Work-In-Process (CONWIP) relies on accurate feedback data in order to regulate throughput (see Stevenson et al. 2005). Hence, such implementation issues are relatively generic amongst PPC concepts. Overcoming these issues is important for increasing the amount of empirical evidence involving innovative PPC concepts, including WLC.

A WLC methodology designed for the particular needs of MTO companies has been developed at the Lancaster University Management School (LUMS). It is this methodology that is the subject of this paper, and is hereafter referred to as the LUMS approach. To facilitate further empirical research, this paper is organized around two themes: (1) developing a Decision Support System (DSS) based on the LUMS approach to WLC, and (2) addressing implementation issues. The DSS development process considers the needs of present day MTO companies, such as short lead times and the need for flexibility, and leads to a number of significant refinements to the LUMS approach. Through a partial implementation of the system, the WLC concept is further refined using case study evidence.

The remainder of the paper is organized as follows. Section 2 describes further details of the WLC concept underpinning the DSS before specific features of the system are presented in sections 3 to 7, highlighting key changes to the LUMS approach. Section 8 starts to address the second theme by examining implementation insights from previous empirical research. Section 9 includes a discussion of the proposed methods to overcome implementation complexities within the case study in two key areas: (a) grouping machines and (b) determining capacities, before a partial implementation of WLC is described. The paper provides an insight into some of the practical implications of implementing the LUMS approach and provides refinements that bridge the gap between the theory of WLC and the practice of MTO production. Finally, conclusions are drawn in section 10.

2. Hierarchical backlog control for MTO companies

Due to the degree of customization offered by MTO companies and the level of uncertainty in the industry, production often does not commence until after a customer enquiry is confirmed. As a result, lead times are longer than for Make-To-Stock (MTS) companies and take on strategic importance. Hence, planning and control at the customer enquiry stage is considered particularly significant (see Hendry and Kingsman 1989), in order to stabilize lead times and aid DD determinations. Therefore, to maintain control in a MTO environment, the job release stage can benefit from supplementary control at the preceding decision levels of customer enquiry and job entry. The LUMS approach incorporates customer enquiry and job entry control within a hierarchical structure.

The full hierarchy of backlogs incorporated in this approach is as follows, where each is a subset of the next: (1) Released Backlog: the Total Work Content (TWC) of jobs on the shop floor; (2) Planned Backlog: the TWC of jobs awaiting materials, in the pre-shop pool and on the shop floor; (3) Total Backlog: a proportion of the TWC of unconfirmed jobs, in addition to the TWC of all accepted jobs. Figure 1 summarizes the hierarchical control framework, indicating the key production stages to control (before allowing the foreman to take control of the shop floor). For a complete description of the LUMS approach prior to the refinements made in this paper, see Hendry and Kingsman (1989, 1991), Kingsman (2000) and Stevenson and Hendry (2005).

Figure 1. Hierarchical backlog control framework.

In particular, the LUMS approach supports the quotation and negotiation process in an attempt to ensure realistic DDs are quoted to prospective customers, based on the current workload (im)balance and capacity of the shop. At the lower level, the approach can be described as an aggregate approach as the workload of a job is attributed to the released backlog of each work centre at the moment of job release (see Stevenson and Hendry 2005). The backlog at a work centre hence includes load in transit (indirect load) and load on hand (direct load) without distinguishing between the two. For a complete review of PPC concepts and their applicability to MTO companies, see Stevenson et al. (2005).

2.1. Issues to explore

Aggregate load methods, such as the LUMS approach, have received criticism for relatively poor performance in simulations as routing variability increases; see, for example, Oosterman et al. (2000). However, there is no WLC method that performs better than the others under all tested conditions (Cigolini and Portioli 2002) and the additional impact of customer enquiry stage control provided by the LUMS approach can only be determined through implementation in practice. However, in order to facilitate empirical research, a number of issues need to be overcome. Firstly, the LUMS approach plans workload requirements on an aggregate weekly level (see Hendry and Kingsman 1993); however, with growth in the MTO industry and high levels of competition driving down lead times, a weekly plan may provide insufficient control for the shop floor. Secondly, accurate and up to date feedback information regarding the progress of jobs on the shop floor is required, but this can be difficult to provide under complex shop conditions. Short lead times also mean that the interval between periodic releases is likely to reduce towards a more continuous release policy, further increasing the need for up to date feedback information. Thirdly, the methodology requires more foresight in order to reflect the future load of the shop. Fourthly, WLC concepts require certain norms and parameters to be set, however these can be difficult to determine. Finally, the LUMS methodology does not exist in the form of a contemporary Windows-based DSS.

The DSS presented in this paper seeks to address these shortcomings. Through empirical research, the DSS also seeks to support the encouraging simulation results of the LUMS approach presented by Hendry and Wong (1994) and Hendry et al. (1998). Also note that a comparable empirical research project is currently being undertaken at the University of Coimbra (Portugal); see Silva and Magalhaes (2003) for initial details.

3. Decision support at the customer enquiry stage

Providing control within the DSS at the customer enquiry stage will allow the user to directly consider the current workloads and capacity of the shop when quoting DDs. The DSS uses the expected pool delay and queuing times at shop floor resources to estimate the delivery lead time as only rough cut planning is required until an order is confirmed. This maintains flexibility for the detailed scheduling level and reflects the uncertainty of the customer enquiry stage.

3.1. Total backlog management

The DSS incorporates a simple strike rate percentage at the customer enquiry stage in the determination of the total backlog of the shop in order for DD determinations to reflect the anticipated future load of the shop and avoid a company bidding for an infeasible mix of workloads and DD's (see Kingsman et al. 1993). Hence, in addition to the aggregate workload of confirmed jobs, the workload of an unconfirmed job multiplied by the strike rate of the company contributes to the total backlog.

Given the current level of competition in MTO sectors, lead times are much shorter than when the LUMS approach was first conceived, and hence production planning must consider more discrete time intervals. Therefore, the total backlog is determined for every individual day during the current planning horizon by considering the current mix of confirmed and unconfirmed jobs, and the impact these jobs will have on the total backlog of a given day (based on DDs). However, the total backlog of the shop on a given day should not include jobs that are expected to have been completed prior to the current date. As a result, the total (and planned) backlog length (and limits) should ‘step down’ towards the end of the planning period (see Hendry and Kingsman 1993). Figure 2 shows a planning horizon of ‘p’ days and a maximum backlog length of 10 days. At ‘p–10’ days, the limit begins to step down by a day at a time until the end of the planning horizon. This is provided to ensure throughput times remain competitive, so that the resources are not constantly fully loaded in future time periods, and so that the requirements of future jobs can be accommodated, thus maintaining medium-term flexibility for the shop.

Figure 2. Depreciation of the backlog length over time.

The total backlog of the shop on day d (TB _d ) can be calculated using (1) and (2):

where i is a job with a DD greater than or equal to d, TWC _i is the total work content of job i, Q _i is the quantity of job i, PT _iw is the unit processing time of job i at work centre w and ST _iw is the set-up time of job i at work centre w;

where SR is the overall strike rate of the company, TWC _i is the total work content of unconfirmed job i with a DD greater than or equal to d and TWC _j is the total work content of confirmed job j with a DD greater than or equal to d.

The DSS incorporates a time phased and instantaneous representation of the Total Backlog Length (TBL), while previous versions of the LUMS approach were simply based on an instantaneous TBL. The DSS calculates the shop TBL for each day of the current planning horizon, as determined by the distribution of the total workload and capacity, in other words the input and output rates of the shop. To clarify, the TBL on a given day is calculated by determining the number of days it will take for the shop to complete the total backlog, incrementing the TBL by a day at a time and reducing the total backlog by the capacity of the shop (across all resources) on that particular day. In its simplest form, a backlog (or total workload) of 100 h and a constant daily capacity of 10 h represent a backlog length of 10 days. At this top level planning stage, it is considered adequate to determine the TBL in total days, rather than more discrete intervals.

3.2. Determining delivery dates

The DSS provides the user with an advised DD at the customer enquiry stage for a given job based on the anticipated customer confirmation time and the expected delivery lead time for the job. Once this earliest advised DD has been found, the DSS considers the capacity of the shop. If adding the whole of the job to the total backlog of the shop does not exceed the maximum limits then the DD can be quoted, and the strike rate percentage incorporated in the TBL. If the date is considered unsuitable, the DD is incremented by a day until the TBL remains within limits and a suitable DD can be found. If the user considers the DD to be uncompetitive, the user can consult the capacity management module and change the capacity of constraint resources on the appropriate dates, thus increasing the total daily capacity and reducing the TBL of the shop. Hence, the system goes beyond rough-cut capacity planning at the customer enquiry stage by providing a flexible I/OC capacity management tool.

The anticipated Delivery Lead Time for job i (DLT _i ), with a priority of ‘p’, can be calculated using the formula in (3) below (where only the queuing time constants of work centres that the job will visit are considered). Providing the maximum TBL of the shop will not be exceeded, the advised minimum DD for job i (DD _i ) is calculated using (4) below. Equations (3) and (4) also illustrate that (by changing the quantity, priority of a job, expected material arrival date and customer confirmation time) the user can experiment with different DDs. Unlike previous versions of the LUMS approach, the formula allows queuing times to vary for each shop floor resource to increase flexibility and reflect the characteristics of real-life job shops:

where MatLT _i is the expected material lead time for job i, PD _p is the expected pool delay constant for a job of priority level ‘p’, TWC _i is the total work content of job i and QT _pw is the queuing time constant for a job of priority ‘p’ at work centre w;

where ED _i is the enquiry date for job i and CCT _i is the estimate of customer confirmation time for job i.

Figure 3 shows the customer enquiry management module of the DSS, where unconfirmed jobs are sorted according to earliest DD, as determined by the estimator. The advised DD proposed by the DSS is shown in the ‘Job Details’ part of the module. Note that, although many of the company names used in the screen shots are real, the data are fictional.

Figure 3. Customer enquiry management module. NOP, number of operations; CCT, customer confirmation time (days); MLT, anticipated material lead time (days); DLT, delivery lead time (days).

The form calculates the expected delivery lead time and the advised earliest DD for each job, and displays all jobs that are currently under consideration by prospective customers. The Total Backlog Chart provides the user with a visual aid for DD negotiations with customers. The chart shows the workload distribution over the first 24 days of the planning horizon, while the user can also zoom out to view the workload distribution over the whole planning period. Similar features are available for the planned backlog length charts and tables.

4. Decision support at the job entry stage

Customer enquiry management can help to provide a suitable mix of jobs for the job entry stage, i.e. a stable level of work for shop floor resources, with DD's staggered throughout the planning period. Job entry for some jobs may be immediately after the customer enquiry stage, while for others it may be some weeks later. Therefore, if the customer accepts the quotation, it is necessary to re-evaluate the DD to ensure that the company can still achieve this, before the TWC of the job is reintegrated into the TBL and added to the Planned Backlog Length (PBL). If the job is rejected, the DSS reduces the total backlog accordingly. However, potential customers who reject a tender may not notify the company of this decision, hence, after a period of time (the expected customer confirmation time plus a safety factor), the job can be removed from the total backlog by the DSS. This is a reasonable assumption, as if the customer later returns to place the order it is likely that the DD would have to be renegotiated.

4.1. Planned backlog management

Previous development of the LUMS approach, with weekly backlogs and workloads, used expected queuing norms to backwards schedule to a Latest Release Date (LRD) and an overly complex algebraic method of calculating Operation Completion Dates (OCD's); see Hendry (1989). In contrast, this DSS plans jobs using daily available capacity (derived from daily work centre capacities and planned workloads) by applying backwards scheduling from the DD to produce a set of OCDs, an Earliest Release Date (ERD) and a LRD to assist in ensuring DD adherence. This adaptation reduces the importance of accurately determining queuing norms as they are now only utilized at the customer enquiry stage. This procedure is only completed if capacity is available at each work centre in the appropriate daily time buckets between the DD and the current date. Hence, the planned backlog of the shop for a given day d (PB _d ) contains a subset of the total backlog of the shop, as it only considers accepted jobs with a DD equal to or beyond (and an ERD before or equal to) the current day (d), as shown in (5) below, where TWC _i is as defined in equation (1). For individual resources, the corresponding workload is added to the planned backlog between the ERD and the expected OCD. Hence, the planned backlog of work centre w on day d (PW _wd ) is given by (6):

where i is a confirmed job with a corresponding OCD equal to or beyond day d, Q _i is the quantity of confirmed job i, PT _iw is the unit processing time for confirmed job i at work centre w and ST _iw is the set-up time for confirmed job i at work centre w.

The lower the level in the planning hierarchy, the greater the importance of considering the impact of jobs on specific work centres. Using the planned backlogs, the DSS can calculate the PBLs for individual resources and the shop as a whole in the same way as the TBL is calculated. However, in the case of an individual work centre, capacity relates to that of the machine (or work centre), and not the collective total daily capacity of the shop. If the job cannot be scheduled effectively, or maximum PBLs will be exceeded, the user is advised to consider capacity management options (output control) in order to provide additional capacity and reduce the backlog length. The user can consider the option of rejecting the job or renegotiating the DD (input control). The user can also choose to change OCDs manually (while keeping dates in sequence) to provide greater flexibility, or choose to reschedule one or all jobs. At this planning level and the subsequent job release stage, the user can also assess the impact of changing the priority of a job on the LRD and OCD's. This theoretical development at the job entry stage provides an extra dimension to the approach and supplies additional functionality to support the job release stage. The job entry module of the DSS is shown in figure 4, where MAD refers to the anticipated Material Arrival Date.

Figure 4. Job entry module with job Gantt chart.

The form shows the PBL charts for each work centre in addition to a list of confirmed jobs for the current planning horizon (listed in order of earliest DD). In the upper half of the form the user can adjust job details, such as priority and MADs. The lower half of the figure shows a Gantt chart for the selected job, based on expected OCDs. The user can also view PBL tables for each resource, highlighting daily input and output levels. Similarly, the user can view the workload distribution of individual jobs across work centres in a graphical format (supported by a list of expected OCDs), and the planned queue at any work centre on a given day or in a given week based on (and sorted according to) expected OCDs. In the daily view of the planned queue, if the OCD of the previous operation of a job (or the LRD, if the work centre is the first destination) is prior to the chosen date and the OCD of the current operation is equal to or beyond the current date, the job will be displayed as part of the planned queue of a resource. In the weekly view of planned queues, if an OCD is in the chosen week, the job will be displayed in the planned queue of a resource. This helps to regulate WIP by showing the user exactly what should be queuing at a resource in a given time period and highlighting which jobs are contributing to the input of a resource in the planned backlog table.

Most jobs that a customer requests are likely to be for as soon as possible, and thus fall into the current planning period (e.g. a 100 day window). Some may be for far into the future, hence the company does not need to plan production for such jobs at present, but can choose to accept these jobs with confidence as the accepted workload beyond the current planning horizon should be small (otherwise, the size of the planning period should be reviewed). The DSS allows the user to view jobs that are beyond the planning horizon, thus improving scheduling visibility and foresight. When the DD enters the planning horizon, the job is added to the appropriate backlogs and scheduled for release, hence each job beyond the planning horizon is allocated a schedule (or horizon) entry date. The schedule entry date of job i (SED _i ), with a DD (DD _i ) beyond the planning horizon (PH), is calculated using

5. Decision support at the job release stage

When jobs have been accepted and materials made available, the DSS transfers them to the pre-shop pool, where jobs are considered for release to the shop floor. Jobs are ranked in the pool in order of shortest slack by comparing the current date with LRDs. Jobs with a negative slack are highlighted in red, to draw the users’ attention towards them. The job release stage provides additional shop floor control through the released backlog of individual shop floor resources and the shop as a whole. For a review and classification of Order Review and Release (ORR) policies see, for example, Bergamaschi et al. (1997).

5.1. Released backlog management

The Released Backlog of the shop for a given day d (RB _d ) contains a subset of the planned backlog of the shop, as it only considers the TWC of released jobs, as shown in (8) below. The Released Backlog of work centre w on day d (RB _wd ) is given in (9) below:

where TWC _i is the total work content of released job i with a DD equal to or beyond day d;

where i is a released job with a DD equal to or beyond day d, Q _i is the quantity of released job i, PT _iw is the unit processing time for released job i at work centre w and ST _iw is the set-up time for released job i at work centre w.

The DSS calculates the Released Backlog Lengths (RBLs) for individual resources and the shop as a whole. This is performed similarly to the PBL, but due to the precision required at this short term level, part day requirements are calculated for the last day on which capacity is required. Hence, when the remaining backlog is less than the capacity of a day, the contribution to the backlog length is calculated by dividing the backlog by the daily capacity. In comparison, previous development of the LUMS approach calculated part week requirements for the RBL (see Hendry 1989). In the job release module, jobs can be chosen and dragged from the pool into a ‘release enclosure’, where the impact on the RBLs of work centres can be assessed. This is achieved using RBL charts and tables, and taking into consideration the maximum RBLs to avoid excess congestion, and minimum advised RBLs to avoid unnecessary machine idleness and starvation (see figure 5). The user is advised to consider priority, the slack of jobs and the backlog limits in choosing jobs for release.

Figure 5. Job release decision support module.

The user can choose varying mixes of jobs from the pool in an attempt to balance workloads across resources, before making the final release decision. Providing an opportunity to assess the impact of multiple jobs on shop floor resources allows the user to see the cumulative effect that jobs have before making any decisions/releasing any jobs. Previous versions of the LUMS approach restricted the user to assessing and releasing each job individually without the benefit of hindsight. This is a refinement that could have major practical advantages. Although the aggregate method does not discriminate between direct and indirect load, the user is also likely to pay particular attention to the immediate impact of the job on shop floor queues, especially if processing times are high. Hence, this may be an important factor in the release decision; as a result, the DSS indicates the first work centre that a job will visit. Once the user has made their final decision, the released backlogs are updated.

The LUMS approach has previously suggested the use of an Intermediate Pull Release option between periodic releases (see Hendry 1989), although as lead times reduce, the procedure approaches a continuous review and release policy. The user can choose to pull jobs from the pool at any time, and can also force jobs onto the shop floor that will break workload restrictions at one or more work centres. This should be performed with caution; the user is presented with a warning message to remind them of the danger of overuse of the force release function. However, if force releasing was not permitted it may make the system too restrictive, particularly in the early stages of implementation, when backlog limits may be initially unrealistic. To avoid force release, the system also allows orders to be split, so that part of a job can be released immediately to improve workload balancing without exceeding workload limits, while the remainder can be released in the future when workloads have reduced or capacity has increased. This is provided as a means to make the system more realistic. Although job splitting is likely to increase set-up times and the complexity of tracking the progress of jobs, it is considered to be a common characteristic of real-life job shops.

6. Decision support on the shop floor

At the moment of job release it is important that feedback information, and therefore the RBLs of work centres, are up to date or a job may contribute to the backlog of work centres for longer than it needs to, adversely affecting the release of other jobs. The more continuous the release policy, the more continuous feedback information must be. It is acknowledged that it can be unrealistic to assume the automatic feedback of information; however, on the other hand, it would also be unrealistic in a dynamic job shop to automatically depreciate the backlogs of work centres (assuming work is completed by the scheduled OCD). This could result in the user and foreman overlooking jobs that are behind schedule, thus leading to late delivery. To combat this, the DSS provides a manual, but rapid and user-friendly, means of updating the position of jobs on the shop floor (see figure 6).

Figure 6. Job progress reporting module and shop floor WIP view.

As this still requires a disciplined approach to supplying information, jobs that are behind schedule are highlighted by the system and brought to the attention of the user in a daily ‘exception report’. This is based on the current date and the expected OCD of the current work centre of a job. If jobs have been overlooked in the supply of feedback information, the user can simply update the position of jobs before the next release decision. On the other hand, the foreman can ‘chase’ jobs that are genuinely behind schedule on the shop floor in an attempt to ensure subsequent OCDs and the final DD are met. This provides an extra measure to ensure the effectiveness of the aggregate WLC policy. The user may choose only to update jobs when they appear in the exception report and keep the planned and released backlogs synchronized. Alternatively, the user may choose only to update the position of a job when it is completed. This would mirror the WLC concept of Tatsiopoulos (1983), where downstream work is included in the aggregation of workload and would have to be reflected in the backlog length restrictions. Without an investment in shop floor technology (such as bar coding equipment or localized computer terminals), intervention is inevitable for a system to run effectively.

The module also provides the user with a number of different views in the lower half of the screen. The user can view the overall WIP for the shop as a whole, sorted by earliest DD. Alternatively, the user can view the current queue at each work centre, ordered by OCDs. From here the user can see the current position of all jobs on the shop floor (including their previous and subsequent destinations). As is the case throughout the DSS, jobs are colour coded to highlight those with priority and those behind schedule. The module also allows the user to compare and contrast the actual and expected (planned) queues of each work centre.

7. Capacity management

A change to the capacity of resources has an impact throughout the hierarchy of backlogs, influencing the total, planned and released backlog lengths. Hence, changes to the capacities of resources influence the DDs the company can quote at the customer enquiry stage, the OCDs scheduled at the job entry stage and the mix of jobs that can be released at the job release stage. The Capacity Management module of the DSS shows the planned workload and capacity distribution on any chosen day in the planning horizon and highlights resources that are under or overloaded. The DSS offers three main options to manipulate the output rate: (1) employees can be reallocated from an under-loaded to an overloaded resource; (2) overtime can be assigned to one or several resources; and (3) the user can subcontract part or the whole of a job. It is expected that reallocation is preferred to overtime as this can be performed at no extra expense. Any subcontracting should be planned as early as possible, usually at the job entry level, before materials have been ordered. By providing the decision support described in the preceding sections, it is anticipated that the number of jobs that a company subcontracts due to insufficient capacity can be reduced. The user must also consider maximum overtime constraints and the maximum and minimum allowable operators at a work centre.

The DSS also provides a user-friendly module where parameters can be set and changed after implementation, including pool delays, the strike rate and individual backlog length restrictions. For user friendliness, variable parameters, such as customer confirmation times, are changeable in the main modules of the DSS.

7.1. Summary of refinements to the methodology

As described above, this DSS development process has led to a number of changes to the LUMS approach to WLC. Key refinements are summarized in table 1. Further refinements to the concept are briefly described in section 9 in the light of case study evidence.

Table 1. Summary of key refinements from the programming of the DSS.

Planning level	Key refinements
Customer enquiry stage	Allowing norm queuing times to vary across shop floor resources to reflect the characteristics of job shops in practice; Providing a time phased representation of the TBL to illustrate the distribution of delivery dates over time; Incorporating jobs beyond the planning horizon and calculating a schedule entry date for each, in order to increase visibility.
Job entry stage	Providing discrete backwards scheduling for greater guidance and a reduced parameter setting burden; Increasing emphasis on practical aspects of interest to users, such as planned shop floor queues and Gantt charts.
Job release stage	Promoting a continuous, rather than periodic, review policy to compensate for short delivery lead times; Calculating the RBL in days and part days for increased accuracy; Providing an option to release part of a job/lot split to increase flexibility and reflect the ad-hoc decisions made in practice; Allowing the user to assess the cumulative impact of jobs on the shop floor before releasing jobs.
Shop floor control/priority dispatching	Promoting up to date feedback information from the shop floor through an exception report and user-friendly data input system to improve the effectiveness of the aggregate load methodology.
General aspects	Calculating the total, planned and released backlogs in days, rather than weeks, to reflect the competitiveness of the MTO industry; Simplifying the use of job routing data through the hierarchy of backlogs; Greater capacity management and parameter setting assistance to improve practical applicability.

8. An overview of existing WLC implementations

One of the first reported case studies of WLC was presented by Bertrand and Wortmann (1981). The authors developed an aggregated production control theory and information system and applied this to the diffusion department of a semiconductor plant producing integrated circuits. However, the planning and control requirements of the semiconductor industry are rather unique: for example, the industry is renowned for a process of re-circulation (see Fowler et al. 2002), making it difficult to generalize these results. Furthermore, given the fast moving and increasingly competitive environments for which WLC is designed, more contemporary research is required.

Fry and Smith (1987) presented a limited case study implementation of a bottleneck-oriented I/OC method for a tool manufacturing job shop, focusing on job release. The authors report reductions in WIP and backlogs, an increase in customer service and quoted lead times more than halved. The authors describe how the approach was used on one product line (pliers), representing 40% of total sales. However, other product lines may have different routings and bottlenecks. The authors offered six practical steps towards implementation: (1) change from local efficiency measures to global throughput measures; (2) identify bottlenecks to determine the maximum system throughput; (3) set maximum inventory levels between work stations; (4) reduce production lot sizes; (5) work on the correct items; and (6) set input equal to output. However, although the method was shown to work in a job shop, products appear standardized, reducing the complexity of planning and control. Park et al. (1999) present a second bottleneck-oriented case study, developing a WLC-based DSS to aid DD determinations for a large rotating machinery shop. The DSS monitors the workload of the bottleneck operation in line with the principles of the Theory of Constraints (TOC). However, it is considered that, in a job shop, controlling the workload balance across all work centres is important, and such a system may also suffer from the ‘wandering bottleneck problem’. The authors offer little explanation of how in-depth issues involved at the implementation stage were addressed. For further details of bottleneck load oriented WLC, see Enns and Prongue Costa (2002).

The complex probabilistic WLC methodology used by Bechte (1988, 1994) and by Wiendahl (1995), known as Load Oriented Manufacturing Control (LOMC), determines the indirect load of a work centre based on the probability of a job arriving at a downstream work centre in the corresponding planning period. Bechte (1988) reports, for example, the convergence of planned and actual lead times. The author touches on implementation start up effects, similar to those commonly found in simulation; when implementing a DSS, it will take time to capture the current status of the shop and for appropriate parameters to be determined. Bechte (1994) describes a number of software requirements; for the implementation of LOMC, a new calendar was installed for lead time calculations and backwards scheduling along with new work centre and transaction data files. Wiendahl (1995) emphasizes the need to provide information regarding, for example, machine availability, personnel capacity and feedback information through improving the flow of shop floor information. The author provides six useful steps towards implementation: (1) Manufacturing Analysis; (2) Manufacturing Process Improvement; (3) Feedback Accuracy Improvement; (4) Monitoring System; (5) Checking Present Manufacturing Control; and (6) Load Oriented Manufacturing Control. However, the author also explains that at least a year must be spent at each step to ensure permanent improvement can be expected, and if some steps have already been taken, the minimum time for implementation is two years. Wiendahl (1995) also explains that companies must give up the ‘traditional concepts’ of manufacturing, in other words, the successful implementation of WLC may hinge on overcoming cultural issues within the company. However, it is considered that, in practice, managers are likely to prefer simplicity, such as in the DSS described in this paper, over the more complex probabilistic approach. A method that is over-sophisticated may be misused through lack of understanding or neglected over time.

The following section explores implementation issues addressed in a case study company to add to the limited body of literature before describing the outcomes from a partial implementation of the DSS.

9. The case study: preparing for workload control

The case study company, hereafter referred to as Company X, is a small, but growing subcontract precision engineering MTO Company based in the North West of England. The company operates as a general job shop, with facilities such as CNC milling, drilling machines, centre lathes and CAD/CAM technology. Company X has steadily grown in terms of the number of employees and annual turnover, currently employing 30 people with a turnover of approximately 1.5 million Euros, and hence can be described as a small company within the framework of SMEs. Typical customers of the company are in the aerospace, automotive and defence industries. When quoting DDs, the company do not directly consider the capacity of the shop and current workloads, and simply state a lead time of approximately three weeks; as a result, the company is overloaded and under pressure to improve DD adherence. Company X has previously considered the adoption of an Enterprise Resource Planning (ERP) system; however, management rejected this idea due to the ‘one size fits all’ mentality of large and expensive computer packages. It was anticipated that, as the size of the company increases, the current ad-hoc planning measures would have to be replaced with a cost-effective planning and control system, such as WLC.

9.1. Grouping machines

The shop floor of Company X consists of 23 machines, making it difficult to ensure that the necessary level of detailed feedback information required by the LUMS approach is provided. Up to date feedback information is required in order to update the position of jobs on the shop floor and reduce the released backlogs of work centres that have processed a particular job. Henrich et al. (2003) explain that WLC concepts often assume the immediate feedback of information; this is an assumption that can be satisfied in simulation, however is unlikely to be the case in Company X. As a result it is necessary to group machines into work centres where data can be collated and reported back at regular intervals, prior to release decisions. Grouping machines can also make the system more manageable, as, for example, fewer norms, such as backlog length restrictions, have to be determined and monitored.

Henrich et al. (2004) explain that grouping interchangeable machines also means that the decision of designating jobs to a particular machine can be delayed, thus providing flexibility. In addition, alternative job routings do not have to be considered, as similar machines will already be grouped together using one backlog of work. However, in reality, a company often accumulates machines over time, hence they vary in age, specification, processing speeds and set-up times, making it rare that they are completely interchangeable, thus distorting the capacity of the work centre. As a result, to maintain control over information feedback, it can be necessary to group semi-interchangeable machines.

Employees within Company X are commonly skilled in one or two value-adding activities (covering a number of machines), while employees can also simultaneously operate more than one machine at once. Hence, employees tend to be allocated to a single machine or a pair of machines, and can be reallocated to a discrete number of alternatives. Therefore, grouping machines can provide greater flexibility for allocating work and for allocating operators to resources. A limited number of rarely used machines have no employees directly assigned to them (milling, grinding, sawing and drilling). When these operations are required, an employee from a specific area is moved across to complete the task.

To compensate for employees operating multiple machines and to account for the varying work rates, workloads, skills and experience of employees, the owner-manager of Company X gave employees an efficiency rating for the purposes of planning and control. The general rule of thumb being that if an employee operates a single machine then they can do so at an efficiency of 100%, or one machine hour per operator hour (after allowing for planned downtime) and if they are operating two or more machines they can do so at their individual efficiency rating. It is acknowledged that this assumes that experienced and inexperienced operators can both run a single machine at an efficiency of 100%; however, in reality, an experienced operator may operate the machinery at an efficiency of 120%.

Machines were subsequently grouped into 12 work centres consisting of between one and four machines, based primarily on the functional capabilities of the machines and the skills of employees. Similar machines that an employee was likely to operate at the same time were grouped, while it can also be important for grouped machines to be physically located near to each other. The four operations where no operators are permanently allocated are also accounted for. When these peripheral operations are required, the capacity of the work centre from which the employee is reallocated is depreciated to reflect this. A similar approach is used by Bechte (1988), however for such operations the author explains that ‘full capacity’ is given to avoid difficulties encountered at the job release stage. In the case of Company X, the work centres are only allocated capacity if it is available at the ‘partner resource’.

A number of machines within work centres are fully interchangeable, while some are approximately 80% interchangeable, a percentage considered sufficient by management. For example, two CNC machines were grouped into a work centre, where one machine can be used with metal up to a thickness of 25 mm and the other up to a thickness of 32 mm. Hence, jobs arriving with a thickness of 25 mm can be processed by either machine, but those with a thickness greater than 25 mm can only be processed by the one machine. The foreman can look ahead to the requirements of imminent jobs and utilize the capacity of the unrestricted machine accordingly. However, in a heavily overloaded situation, if the two machines are not totally interchangeable, this could lead to delays in the throughput of a job. Care must also be taken at the job entry and job release stages. Although the available capacity of a work centre may indicate that a job can be processed in time to meet a specific date, at the discrete scheduling level this available capacity may consist of small pockets of time on different machines, while in practice it is likely that management will want a job to run continuously on one machine in order to minimize set-up times.

9.2. Determining capacities

Due to the relationship between the output rate of machines and the number of operators and their efficiency, capacity is directly affected by employee shift patterns and attitudes towards overtime. In addition, if employees are reallocated to other work centres, the number of existing operators at the corresponding work centre will affect the impact that reallocation has on capacity. However, the efficiencies calculated by management are either subjective estimates or based on a small sample of historical data, hence accurately modelling the specific working patterns of employees would not necessarily yield an accurate representation of capacity. It is also assumed that employees who are reallocated to another work centre can operate the machinery at the same efficiency at which they are able to perform their core operations. Employees have an informal agreement with management regarding the use of overtime, where operators have overtime hours that they normally work each week, such as an hour before or after a shift. The overtime that different employees choose to work can vary widely, resulting in employees often running a work centre on their own, and hence at a reduced level of efficiency. However, overtime is largely independent of the load of the shop. In addition, working patterns and daily capacities vary depending on the shift an employee works; for example, night workers work four days a week. The situation is made more complex by a ‘Late’ shift positioned to partially overlap the Day and Night shifts.

For this initial study, a simple capacity approximation has been applied based on recent historic data regarding shift patterns. This simple approach means that the identity of operators does not have to be specified. In reality, this is also unlikely to be feasible, as it may be difficult to attribute a piece of work to one operator or to specify which operator is being reallocated. In addition, it is unlikely that specific overtime could be offered to one employee individually, hence two hours of overtime may lead to two operators working an hour each rather than one operator working for two hours.

The expected capacity of each work centre, based on the expected shift patterns of each employee (including expected overtime) and their individual efficiencies, has been calculated. From this, an average output rate per employee hour can be calculated. For example, a work centre capacity of 1.5 h per man-hour. The number of man-hours, and hence capacity, can be adjusted if operators are absent, reallocated or work overtime. The ratio can also be monitored and reviewed as the mix of operators and their experience changes. However, it is also acknowledged that, by increasing the capacity per man-hour ratio, the company can instantly increase/manipulate capacities and reduce backlog lengths, hence it is possible that this may be abused. Subject to growth and the initial post-implementation performance of the company; further research could lead to a more sophisticated representation of capacity and a change to the efficiency measurement policy of Company X. However, it is considered that the capacity approximation described will provide a useful representation of available capacity, thus providing a good starting point for WLC.

9.3. Additional contextual considerations

Customization leads to jobs going through widely different product routings, however the simplicity of product structures means that this is a sequential process. Each stage in the processing of a job is dependent on the completion of the previous step, without parallel production. Hence, sub-assemblies and complex product trees do not have to be considered. Where products consist of a number of sub-assemblies produced in-house, the assembly process is considered a separately accountable job, with the completion dates of in-house components considered in the determination of the date for final assembly. As a result, the complexity of routing information is simplified. Hence, the nature of production has a significant impact on the design of the DSS and the complexity of feedback information.

9.4. Outcomes from a partial implementation

As a means to further explore the applicability of the LUMS approach to MTO companies, the DSS has been applied to Company X for the workload of one influential repeat customer, representing an average of over 10% of the total workload of the shop. This application has led to three major refinements to the methodology, as listed and described below:

1. Changes to the way data is input at the customer enquiry stage.

2. Changes to the way accepted jobs are scheduled/rescheduled.

3. Changes to the structure of the hierarchy of backlogs.

9.4.1. Data requirements at the customer enquiry stage

Significant difficulties were encountered in obtaining detailed job data at the customer enquiry stage, although previous discussions with management had suggested that this level of information was readily available. In attempting to gain access to job data, two striking observations were made. Overcoming these cultural issues and attitudes is crucial to the future of the research with MTO companies such as Company X:

1. Management of the company perceive the overall strike rate of the company to be approximately 15%, hence the user feels that 85% of time spent entering job details at the customer enquiry stage is wasted. However, spending more time at the customer enquiry stage may gradually improve the strike rate of the company in the future. Furthermore, using the DSS in DD negotiations can help to reduce DD tightness, thus improving the options available at the job entry and release stages.

2. The attitude of the user to data entry shows a clear division between repeat and one-off customers. It seems that the company would be prepared to enter job routing information into the DSS if it is for a repeat purchase, as this information will be directly reusable in the future. However, it is argued that it is the routing information for one-off jobs that is most important as the company have not produced these jobs before and may need particular help with the planning and control of jobs that are unfamiliar to the foreman and shop floor operatives.

In the light of this experience, the concept has been refined to reduce the data input required at the customer enquiry stage, thus making the DSS simpler to implement in practice and faster to use. Rather than relying on the order quantity, processing and set-up times at each operation in order to consider the total work content of each individual job in delivery date negotiations, the concept can be simplified to control norm work centre throughput times. Norm work centre throughput times refer to the expected (or desired) amount of time it will take for a job to queue and be processed at a particular work centre. To cater for job shop production, norms can be set for each individual work centre and applied as an approximation for each job that will visit the work centre, for example a throughput time of one day. If the user supplies a list of resources a job will require, the total shop floor throughput time of a job can be estimated by summing the norm throughput times of each work centre the job will visit. This means that, given the sequential nature of production, the user need only tick a series of boxes to indicate the work centres that a job is expected to visit.

The delivery date of unconfirmed job i (DD _i ) would then be calculated as follows, where w refers to the subset of work centres that job i will visit:

where ED _i is the enquiry date of job i, CCT _i is the estimated customer confirmation time for job i, MatLT _i is the anticipated material lead time of job i, PD _p is the expected pool delay constant for a job of priority level ‘p’ and WCTT _w is the norm throughput time at work centre w.

This assumes that each job takes the same amount of time to go through each work centre; hence if the processing times of each job are very different, large jobs may be expected to queue for smaller periods of time. This means that the work centre throughput time of each job can be standardized, irrespective of the size of the job, thus providing more predictable delivery dates.

If available, it is considered that the customer enquiry data requirements outlined in section 3 would be more representative of the workload of a job. However, this leads to a trade-off between the marginal accuracy gains of increased sophistication and the speed, user friendliness and practical orientation of simplification. It is argued here that it would be more beneficial to have some information on all jobs rather than very detailed information on some and no information regarding others. As a result, it is proposed that the methodology should incorporate both types of data entry at the customer enquiry stage, to allow for the particular data availability of each company.

9.4.2. Scheduling at the job entry stage

Case study observations indicate that, given the current speed of data input, there is sometimes insufficient time (or available capacity) to backwards schedule jobs between the DD and the current date. This is due in part to the slow input of data and to the delivery date tightness of jobs. In addition, clustered DD's and an overloaded shop floor further contribute to the difficulties of backwards scheduling. On some occasions, the DD has even passed by the time that details have been entered into the system. However, although the DD has passed, such jobs can often still be found queuing or being manufactured on the shop floor. As a result, DDs are regularly renegotiated with the customer when it becomes clear that a job will not be completed on time.

This problem could be partly resolved by providing more realistic DDs, such as by using the DSS at the customer enquiry stage, but also by rejecting some jobs and providing faster data input as described above. However, in order to make the system more effective, when jobs cannot be scheduled in time, it may be necessary to provide an option to find a new and more realistic delivery date. Hence, if the job cannot be backwards scheduled, and capacity cannot be adjusted to facilitate this, the user can choose to forwards schedule the job from the ERD, or current date. This ensures that otherwise unscheduled jobs are reflected in the planned backlog of the shop and a useful production schedule can be provided for the foreman. The date to which the DSS forwards schedules can also be considered when renegotiating the DD with the customer.

9.4.3. The structure of the hierarchy of backlogs

This paper has briefly described how the LUMS approach has been modified to compensate for the current manufacturing climate. For example, with short lead times it is necessary to monitor daily workloads, rather than weekly intervals as regulated in previous versions of the methodology. However, the experience of this case study suggests that a compromise between the two time intervals can emerge. While the work centre backlogs used at the released backlog level are instantaneous, those used at the planned backlog level are time phased. At this stage, discrete time periods are required in order to sufficiently determine operation completion dates. Hence, it is considered that daily workloads must be determined and monitored for the purposes of input–output control and backwards scheduling. A time phased and instantaneous backlog is provided at the total backlog level, however at this higher planning level management are looking for a broad summary of the distribution of delivery dates, therefore it is not necessary to provide this discrete level of detail. Hence, it is sufficient to monitor the total backlog on a weekly level as delivery dates are prone to change at this uncertain stage.

10. Conclusion

This paper has considered two themes, the design and the implementation of WLC concepts, where both have contributed to the refinement of the LUMS approach. The WLC DSS design stage led to theoretical and practical progression of this WLC approach to combat the issues and assumptions outlined in section 2.1. For example:

1. The DSS aids DD quotations and incorporates the strike rate in the determination of the total backlog of the shop, and hence begins to provide control for MTO companies from the customer enquiry stage onwards.

2. The DSS uses backwards scheduling with daily capacity and workload constraints; hence, queuing norms and pool delays are only used at the customer enquiry stage. Operation completion dates are provided as a guide, while the DSS maintains flexibility by allowing the user to change these dates manually, or reschedule one or all jobs at any time.

3. The DSS promotes accurate and up to date feedback information by providing a user-friendly module through which the user can rapidly update the positions of jobs on the shop floor. In addition, the module highlights jobs that are behind the expected schedule.

4. The DSS considers the future load of work centres both within and beyond the current planning horizon. For example, the user can view planned and actual queues to differentiate between the direct and indirect load of a work centre when releasing jobs.

5. The DSS provides a single integrated Windows software package for the simultaneous control of three backlog levels, whilst also incorporating a capacity management module.

The case study and WLC implementation stage highlighted a number of key practical factors influencing the development and implementation of a PPC-based software system. For example, in practice it can be necessary to group semi-interchangeable machines into work centres, while the grouping decision is affected by the functional capabilities of machines as well as the skills of operators. In addition, the determination of capacities and, in the case of WLC, backlog lengths can be a complex process. Research has reported how input and output control can complement each other and be dynamically managed (see Kingsman and Hendry 2002). However, in practice it can be challenging to take full advantage of this. In the case of Company X, the input rate is intensified by the sudden growth of the company out of proportion with growth in resources, and a reluctance to reject business. Meanwhile, changes to the output rate (through reallocation, overtime and subcontracting) are restricted. The skills of operators limit reallocation possibilities; overtime patterns are relatively stationary and constrained, while in the future the company aims to reduce the amount of work that is subcontracted. To remain realistic, a DSS must maintain flexibility, such as by providing an option to ‘part release’ jobs. Although the DSS is considered relatively flexible, the paper has also described how the LUMS approach has been refined to meet the contextual needs of the case study company. The three changes described are considered relatively generic, and hence can be formally incorporated within the DSS and the design of the LUMS WLC methodology.

Initially, the future research of the author focuses on working towards a full implementation of the DSS in order to develop a comprehensive implementation framework and to gather further empirical evidence regarding the practical performance of the LUMS approach. While this research has maintained an empirical focus, the practical considerations highlighted in this paper could be considered in the design of more realistic simulation experiments. Future research in the field of WLC is also required in relation to the use of web technology in order to extend the advantages of WLC through the supply chain. Such functionality would allow MTO companies to benefit from some of the advantages provided by commercially available ERP packages.