The Need for a High-Level Unit of Capacity

Classic MRP tries to plan all dependent and independent demand in detail. To do so it needs thorough definitions regarding lead-times, available capacity, and required capacity. To determine this required capacity, an exhaustive description of all products and their processes, operations, and time elements is needed. In most cases it comes down to the fact that every bill of material (BOM) needs its own customized bill of labor (BOL), listing all necessary operations (in the right order) and all accompanying time elements (set up, run, wait, and so on). This means that a lot of data elements have to be defined (and maintained!). Not only is this an enormous effort to start with, but in the case of highly customized products it is a never-ending story when BOMs need to be added or modified. Because of the large number and the high rate of modifications, the time elements might never get calculated or measured correctly, leading to inaccurate schedules and bottlenecks on the shop floor, resulting in rescheduling, expediting, and increasing lead-times.

To make matters worse, unpredictable factors—such as tool breakages or customer changes in request dates—deteriorate the quality of the calculated schedule even further. This explains why most of the time those schedules do not meet reality on the shop floor. (Also see Chapter 3 for more discussion on this point.)

One of the root causes of this sequence of events is that the level of definition required by the traditional MRP system is simply too high to be used practically in an environment with high-mix, low-volume and customized (HMLVC) products. It is already well-recognized in the manufacturing strategy literature that to reduce lead time and improve delivery performance, such companies need to be organized into cells. Further, High-Level MRP (HL/MRP) has been recommended in the literature for companies with a cellular manufacturing structure (for example, see the book Quick Response Manufacturing by R. Suri, Productivity Press, 1998). In the HL/MRP approach, instead of planning the progress of work orders at the detailed operation level, you plan the work order at the cell level. However, a cell may include several different operations on a work order. So, this presents the question, how can one reasonably plan capacity at a cell level without accounting for all the details in each of the operations? What is needed is the ability to define capacity at a higher level and in a more universal way. That is the goal of this appendix. An analogy will help to illustrate our goal:

Our aim in this appendix is to provide a similar aggregate measure for capacity at a cell level that does not require the exhaustive details in traditional MRP systems.

Introducing a Capacity Cluster as an Approach to this High-Level Unit of Capacity

What is needed is a high-level measure that can be used easily in capacity and lead time calculations. At the same time, this measure needs to be easy to maintain, and, therefore, in contrast with the classical MRP approach, it should not be a function of the underlying operations and time elements (needed capacity), nor of the available labor or machine hours (available capacity). This goal may seem surprising or even impossible. However, we will explain that it is indeed achievable and it is possible to define a macro-level aggregate capacity measure that reasonably reflects reality in an empirical way.

Below we will explain how we can define a Capacity Cluster as a collection of multiple resources (machines/labor) in a cell that performs similar processes to manufacture similar products. We will show how Capacity Clusters are suitable for defining the available capacity of cells. Note that typically each cell will have its own Capacity Cluster defined, because of its different constellation of resources. We will go into more details on all these points in the following sections.

The best way to explain how Capacity Clusters can be used is through a detailed example. In the rest of this Appendix we will work through such an example and use it to illustrate all the concepts related to defining and using Capacity Clusters.

The MadTran Example Extended

We will use the MadTran example described in Appendix A of the book It’s About Time (by R. Suri, Productivity Press, 2010). However, we will extend the example to help explain several of the concepts of Capacity Clusters. MadTran is a company that makes transmissions. In our extension of this example we will describe two end-products made by MadTran:

• A Heavy Truck Transmission (HTT-534)

• A Light Vehicle Transmission (LVT-142)

Each product has its own multi-level BOM structure, as illustrated in Figure D.1. As shown in the figure, each product is assembled using three main parts:

Figure D.1Overview of Bill-of-Material (BOM) structure for both transmissions.

• One purchased drive shaft for transmitting the rotation to the wheels.

• One housing, which is machined in-house from a purchased casting.

• Multiple gears machined in-house from purchased blanks, and then organized into kits for the final assembly.

Note that the quantity and type of these parts can differ for each of the two transmissions. Next, for every product (end-product or semi-finished product) we can define its single-level BOM, which shows the manufacturing process needed, the type of components needed, and the quantity of each component (see Figure D.2).

Figure D.2Single-level BOM for each item specifying the process, types of components, and quantities needed.

In our example, MadTran has organized its shop floor into cells so that each of the main items at a given level in the multilevel BOM is processed in a particular cell. There are four cells, and the routing of the components through the various cells is shown in Figure D.3 and explained here:

Figure D.3Cells at MadTran and the product flow.

• All gears are machined in the Gear Manufacturing Cell, starting from purchased blanks.

• The Gear Kit Assembly Cell prepares and organizes the various gears into the two types of gear kits needed for the final assembly.

• The housings are machined in the Housing Machining Cell, starting from purchased castings.

• The transmissions are finally assembled in the Transmission Assembly Cell. As can be seen in Figures D.1 and D.2, this assembly requires a housing and a gear kit from the in-house operations, as well as a transmission shaft, which is purchased.

At the next level of detail, we need to describe the operations for all the processes, along with their relevant time elements. These are listed in Figure D.4. Note that the first three processes in the figure are the same for all the products, but the processes for the manufacturing of the Large Gear and Small Gear have different time elements.

Figure D.4List of all processes, operations, and time elements.

In classic MRP, the operations and all related time elements must be defined for all processes involved. In our MadTrans example, the BOMs and the BOLs were kept relatively simple in comparison to many real-world manufacturing scenarios. Even so, we needed to define 26 time elements in 19 operations spread over five processes. In the next section we will show that, with the use of Capacity Clusters, it is possible to define capacity directly at the level of the BOM so that only one definition for every BOM will needed.

Defining Available and Needed Capacity Through Capacity Clusters

The starting point for defining a Capacity Cluster is to think about the minimum typical set of resources that are needed to complete the processes in a cell for a given item. As two examples of this: (i) to manufacture any of the gears at MadTran, one worker is needed along with a milling machine, a gear hobbing machine, and a deburring machine—we can call this one Gear Cell Capacity Cluster; (ii) to assemble the transmission a group of two workers is required along with specialized jigs and a set of power tools—this becomes one Assembly Cell Capacity Cluster.

Next, we define the number of stock units of a given item that can be produced in a cell with one Capacity Cluster over one production period (e.g., an eight-hour shift). Building on the gear example above, let’s say one Capacity Cluster can produce 10 small gears of a given type, or only two large gears of another type. Using the inverse of these numbers, this also tells us how much of a Capacity Cluster is needed to make one unit of a given product. In the preceding example, we need 0.1 Capacity Cluster for one small gear and 0.5 for one large gear. Similarly, such numbers can be calculated for all the other items and cells.

As a result of the above approach, the capacity of a cell can be defined with only one parameter: the number of Capacity Clusters available in a production period. So, for the Assembly Cell Capacity Cluster just described, if there are three workers and additional jigs and tools, we could say that we have an aggregate of 1.5 Gear Cell Capacity Clusters available.

Observe that instead of trying to give values to the diversity of available resources in a production cell, only one aggregate parameter is needed instead of a complex and time-consuming definition of the time elements of all operations of the related process. As an aggregation, this will obviously be an approximation of the details needed in reality. On the other hand, it substantially reduces the amount of necessary data and effort required in managing and maintaining the system. Further, given the errors and inaccuracies that exist in highly detailed BOMs and BOLs, it can be argued that the more detailed descriptions do not necessarily provide a higher level of accuracy anyway.

In general, it is to be expected that various products and cells would have different characteristics. Some operations on products need a lot of labor and only a few machines, while for other operations it could be the opposite. The same is true for cells: some will contain a lot of machines and only a few people to operate them, while others will only mostly people to perform the operations. Therefore, it is likely that different Capacity Clusters will be defined for each cell.

For our MadTran example we will define four Capacity Clusters (Figure D.5). Every cell gets its own Capacity Cluster definition (Figure D.6), which probably will be the case in most situations as just explained. It is, however possible that different cells could make use of the same Capacity Cluster definition. Even if another cell had different machines and products, but a similar high-level way to define the available capacity made sense in that context, then the same definition could be extended to this other cell.

Figure D.5Four Capacity Clusters defined for MadTran.

Figure D.6Capacity Cluster type and amount available for each cell.

Also, the available capacity in a cell does not need to be fixed over time. Just as in normal MRP, you can input different capacity levels for different periods, in order to take into account staff vacation time, sickness, machine maintenance or breakdown, and so on. In this appendix, we will keep the capacity fixed over time for MadTran, so as not to complicate the example.

We now complete the details of the data for MadTran. For each of the in-house manufactured items, Figure D.7 shows the capacity needed per product, expressed in Capacity Clusters. Let us go over an example to explain the details. Both the Heavy Truck Transmission and the Light Vehicle Transmission are assembled in the same cell (Transmission Assembly) and they make use of the same Capacity Cluster (TansmissionAssemblyCluster). However, for the former product, only two transmissions can be manufactured with one TransmissionAssemblyCluster, while for the latter, five transmissions can be manufactured. As a reminder of the earlier definition, the capacity needed was defined as the number of stock units that can be produced with one Capacity Cluster, so using the data just presented, one Heavy Truck Transmission needs 0.5 of this Capacity Cluster, and similarly one Light Truck Transmission needs 0.2 of the cluster, as shown in the right-hand column of the figure.

Figure D.7Capacity needed per product, expressed in Capacity Clusters.

Later sections of this appendix will provide more examples on calculating the number of capacity clusters in a cell as well as the number of stock units that could be produced with such a cluster. If you are concerned about the number of different Capacity Cluster units that you may need to define, note that this not that large: the upper limit is the number of cells, if each has its own unit of capacity definition. If different cells can use the same definition as explained earlier, then this number could be lower.

In summary, as seen from this detailed example, Capacity Clusters define capacity at a high level. Using such a high level might introduce some approximations and errors, but trying to define the capacity on the lowest level of the operations, may not necessarily lead to more reliable planning for several reasons explained earlier. On the other hand, the gain from using the Capacity Cluster approach is that it provides the ability to more easily tune the parameters when evaluating results: because there are far fewer parameters to maintain, tuning becomes more feasible. After a few iterations, the tuned parameters will lead to far more realistic scheduling.

Using Dedicated Throughput Calculation as a Verification

We can use the data in the previous figures to calculate the total throughput of a cell during one period (e.g., a shift) if it is dedicated to one of the products. Production planners and cell teams should already have a good idea of what an achievable throughput should be if the cell is focused on getting one product out (e.g., from past efforts of trying to get rush jobs out). This calculation can then be used to check the degree of realism of the chosen parameters or to fine tune them if needed. The specific calculation to be used is:

$$\begin{array}{l}DedicatedthroughputofProduc{t}_{x}inCel{l}_y\hfill \\ ={(\text{\#}StockUnits\text{/}CapacityCluster)}_{BO{M}_{Produc{t}_x}}\hfill \\ \times {(\text{\#}CapacityClusters\text{/}ProductionPeriod)}_{Cel{l}_y}\hfill \end{array}$$

Applying this calculation to all the in-house manufactured products at MadTran gives us the numbers in the right-hand columns in Figure D.8. As an example, to help explain these numbers, let us consider the assembly of the Heavy Truck Transmission. Suppose the “Production Period” being used for these data is one shift. The data show that there are six Capacity Clusters available in the Transmission Assembly Cell in one shift. Further, two Heavy Truck Transmissions can be assembled with one Capacity Cluster. Thus, if the whole cell is dedicated to this product, it should be able to assemble 12 Heavy Truck Transmissions in a shift, and this is the number that you find towards the end of the first row of the table. This number (12) now serves as a reality check for the setting of the Capacity Cluster for this cell. Similarly, all the other numbers in this column can be used to verify or refine the definition of the Capacity Cluster for a given cell and given product type.

Figure D.8Calculation of dedicated throughput for each product in each cell.

Defining a Common Capacity Cluster for Companywide Comparisons

In the previous sections, we introduced the concept of multiple Capacity Cluster definitions, each one typically related to a given cell (or occasionally, a few cells). However, it may not be clear how to use these separate definitions to compare the needed and available capacity at a higher aggregate level, such as for areas of a factory, or even a whole factory. If there is a need to do so, we propose here an approach to defining a super-level common Capacity Cluster for a group of cells or an entire factory. This can be done by relating all other Capacity Clusters to this common one using a weighting factor to calculate the equivalent common capacity of a cell (say “a”) as follows:

$$\begin{array}{l}\#CommonCapacityClusters\hfill \\ =\#CapacityCluste{r}_a\times WeightingFacto{r}_a\hfill \end{array}$$

Adding up the common Capacity Clusters for a collection of cells provides an even more aggregated capacity number for an area of a factory or a whole factory, as will be shown below.

To determine the weighting factors, and by consequence the proportionality of all cells, common sense must be used, because these factors depend on the company priorities. For example, the relative contribution to the company profit or revenue could be used, or alternatively in a labor-constrained or machine-constrained company also the importance in terms of labor or machine power is another option. Figure D.9 illustrates the choice of these weighting factors for our MadTran example, along with an explanation in the right-hand column. Using these factors, in Figure D.10 we see that at this super-level aggregations, MadTran has a total of 19 common Capacity Clusters. Further, using these common clusters, we can calculate the share of capacity that is contributed by a given cell, simply by looking at the proportion that the cell contributes to the total common clusters (see the last column in Figure D.10). This can also be viewed as a measure of importance of a given production cell or area. For instance, the figure shows that even though the Housing Machining and Gear Kit Assembly are different types of cells, they have exactly the same weight for the company regarding available capacity. Thus, we see that using the construct of common Capacity Clusters makes it possible to compare capacity in an aggregated way across different cells or areas of the factory.

Figure D.9Weighting factors chosen by MadTran planners for common capacity calculation.

Figure D.10Total aggregated capacity for MadTran along with the capacity share for each of the cells.

Calculating High-Level Capacity for Work Orders

One of the main goals of our approach, of course, is to enable capacity planning, which requires comparing the available capacity with the needed capacity for all the promised orders. In order to do this, we need to calculate the capacity needed by each order, and then cumulate this across all the orders in the system. In this section, we show how to go from a final order to the specific work orders needed for that job, and then to the capacity needed for each work order.

Suppose that MadTran gets a customer order for five Heavy Truck Transmissions. For the purpose of this numerical example, we will assume that for this low-volume and customized business, all the parts for this job are made to order; specifically, we assume that the intermediate parts are not stocked ahead of time, nor are their work orders combined with other jobs to save on setups.

We will now determine all the necessary work orders for this customer order. Refer to Figures D.1 and D.2 for the multilevel BOM for this transmission. We will start from the end product and work our way back to the raw materials. The last work order (we’ll label it WO-001), is for the final assembly of the five transmissions mentioned in the sales. From Figure D.1 we see that each transmission requires three components: two of them (a housing and a gear kit) come from in-house operations, while the third (a shaft) has to be purchased.

The two in-house components need to be processed with two separate work orders, which are:

• WO-002 for machining of five housings, using five purchased castings.

• WO-003 for assembly of 10 Gear Kits (two kits for each transmission).

Next, we need the work order to manufacture all the gears for the Gear Kits. Each type of component will have a separate work order. Referring to the BOM and detailed data in Figures D.1 and D.2 we can calculate the number of pieces needed for each, and this results in the following work orders:

• WO-004 for 200 of the 16-teeth gears, using 200 purchased Dimension 20 blanks.

• WO-005, for 80 of the 45-teeth gears, using 80 purchased Dimension 50 blanks.

• WO-006 for 60 of the 78-teeth gears, using 60 purchased Dimension 100 blanks.

• WO-007 for 20 of the 156-teeth gears, using 20 purchased Dimension 200 blanks.

Of course, all the purchased components listed above need to be already in stock or else they need to be purchased; however, this is done in a separate module of the MRP system and here we are concerned only with capacity planning for the in-house processed items, so we will not consider the purchased components further.

Finally, we will calculate the capacity needed for each work order. This capacity is expressed in the Capacity Cluster of the cell where the appropriate step will be executed (and which must be the same as the unit of capacity used in the BOM to define how many stock units can be manufactured). The capacity needed for processing a given work order (WO) in a cell is simply the number of stock units in the work order multiplied by the number of Capacity Clusters required per stock unit, given in Figure D.7:

$$\begin{array}{l}\text{\#}Capacity Clusters Needed{ }_{WO}\hfill \\ =\text{\#}Stock Units{ }_{WO}\hfill \\ \times \text{\#}Capacity Clusters per Stock Uni{t}_{BO{M}_{Produc{t}_{WO}}}\hfill \end{array}$$

Figure D.11 shows the results of this calculation for all the work orders. The last column in the figure shows the number of Capacity Clusters needed for each work order in the appropriate cell. As a result of our approach and the corresponding BOM data, this capacity needed is expressed using the same kind of Capacity Cluster as the cell by virtue of all the definitions made above. Let’s go over the calculation for work order WO-003, which assembles 10 Heavy Truck Gear Kits in the Gear Kit Assembly cell. This work order requires 10 stock units to be assembled, and from Figure D.7 we see that each such unit requires 0.2 Capacity Clusters in this cell. Thus, we need 10 × 0.2 = 2.0 total Capacity Clusters, as can be seen in the last column of the figure.

Figure D.11Capacity needed for each work order for the final order for five Heavy Truck Transmissions.

Defining the Quantum for POLCA in Terms of Capacity Clusters

As explained in Chapter 5, in designing your POLCA system an important decision to be made is the choice of quantum: the amount of work that can be done with one POLCA card. Chapter 5 gave examples of different ways of defining the quantum, such as number of pieces, hours of work, or material-handling container size. The concept of Capacity Cluster allows for a logical choice of quantum.

Since a POLCA card returning from a downstream cell signals available capacity at this downstream cell, it makes sense for this signal be in units of capacity of that cell. The Capacity Cluster for a cell is designed to be just such a unit. So, it is a rational choice to define the quantum for a given POLCA loop in terms of number of Capacity Clusters of the downstream cell. For example, for a loop going to the Transmission Assembly Cell, the quantum could be set at two TransmissionAssemblyClusters. Then this quantum can be converted to number of stock units for a given product. This number will in general be different for each product, based on the number of units that can be made with one Capacity Cluster; this is exactly how it should be, since we want to use a certain amount of capacity downstream, rather than to send a fixed number of pieces. We will now illustrate these calculations using the MadTran example.

Suppose that MadTran has implemented POLCA on its shop floor. Based on the four cells in place and the product flows already described, it is clear that three POLCA loops will be needed (Figure D.12).

Figure D.12POLCA loops and cards at MadTran.

We will use the HM/TA loop (from Housing Machining to Transmission Assembly) to illustrate the approach. Based on the design issues laid out in Chapter 5, let’s say the MadTran team has decided that the quantum for the HM/TA loop is set to a capacity of two TransmissionAssemblyClusters. If the HM cell is machining the housing for a Heavy Truck Transmission, the product to be manufactured in the downstream cell (TA) will be the Heavy Truck Transmission End Product. Because two pieces of this end product can be manufactured with one Capacity Cluster, and because the POLCA card represents two Capacity Clusters, four pieces of the end product can be made with one POLCA card (quantum). Since each end product needs one housing, this means that HM can work on up to four housings with one POLCA card. Similarly, if HM is machining a Light Vehicle Transmission Housing, five pieces can be manufactured with the same Capacity Cluster, resulting in 10 housings that can be machined with one POLCA card. Although defining the capacity of a POLCA card using a Capacity Cluster makes the quantum variable in terms of pieces, it makes it more accurate in terms of the goal of the POLCA card, which is to send work appropriate to the capacity of the downstream cell.

In general, we can state the calculation needed using this formula:

$$\begin{array}{l}DownstreamstockunitsperPOLCAcard\hfill \\ =DownstreamCapacityClustersperquantum\hfill \\ \times DownstreamstockunitsperCapacityCluster\hfill \end{array}$$

Applying this formula to all the loops gives us the set of quanta shown in Figure D.13.

Figure D.13Quantum calculated for each POLCA loop at MadTran.

Next, we can use the previously calculated capacity needed for a work order (see Figure D.11) to calculate the number of POLCA cards needed for that work order using the formula:

$$\text{\#}PolcaCardsNeede{d}_{Wo}=\frac{\text{\#}DownstreamCapacityClustersNeede{d}_{Wo}}{\text{\#}DownstreamCapacityClustersperQuantum}$$

Note that this number will need to be rounded up to the next integer.

Using the previous example of the customer order for five Heavy Truck Transmissions, Figure D.14 calculates the number of POLCA cards needed for all work orders for this customer order. For instance, for WO-003 we need 2.5 Capacity Clusters (downstream). Dividing this by the quantum of 2.0 Capacity Clusters gives us the result of 1.25 POLCA Cards. Rounding up, this results in the number of 2.0 in the figure. Similar reasoning can be used for the other entries. The only other explanation is that for WO-001 no POLCA cards are needed because there is no downstream cell.

Figure D.14Number of POLCA cards needed for each work order for the customer order of five Heavy Truck Transmissions.

This number of POLCA cards is needed for the decision about launching each work order into the cell. Depending on the decision rules being used, the full set of POLCA cards may be needed before the work order can be launched (see Chapter 5).

This calculation is also important for another important reason. In order to calculate the number of POLCA cards in each loop, we need to estimate the flow of POLCA cards in each loop during a given planning period (Chapter 5). This number of cards, totaled across all anticipated work orders, will be required for this calculation (also explained in Chapter 5).

High-Level Capacity Definitions Enable Easier Adding of Data for Customized Products

As stated at the beginning of this appendix, for companies that make a lot of customized products it can be very time-consuming to first determine and then input into the MRP system the data for each new customized product. The whole concept of high-level Capacity Clusters is aimed at simplifying this task. Even when companies make customized products, there are a lot of similarities with previously made products.

When defining similar products to be manufactured in a similar process and similar cells, the high-level definition of capacity with Capacity Clusters helps to predict the impact of the introduction of such a similar product. In this case the derived bill of material for the new product could simply refer to an existing Capacity Cluster, but the number of stock units and lead time could be different if needed. Even when products are highly customized and different, when designing the processes, it should be possible for engineering to relate the different stages of the production process to existing Capacity Clusters.

We will illustrate this once again using the MadTran example. Let’s say that MadTran decides to expand its existing offering of products (Heavy Truck Transmission and Light Vehicle Transmission) with a new transmission for Heavy Vehicles. The engineers start with the design, but it is clear that the general process and the standard parts will not be very different from the existing products. One of the results of the engineering session will be a new BOM. It turns out that for the new product the same housing and shaft can be used as for the Light Vehicle Transmission, but a specific Gear Kit is needed. Still, this kit uses the existing Gears. The resulting BOM structure for this Heavy Vehicle Transmission is shown in Figure D.15 along with the details in Figure D.16.

Figure D.15Overview of BOM structure for the new Heavy Vehicle Transmission.

Figure D.16Detailed BOM for the new Heavy Vehicle Transmission.

From the figures, you can see that most items in the multi-level BOM were already defined earlier. Only the new end-product (Heavy Vehicle Transmission) and a new semi-finished product for the Heavy Vehicle Gear Kit need to be defined. Next, in terms of capacity, we only have to define the capacity needed and an appropriate lead time for these two new items in the BOM. For this, we can start with the already-defined Capacity Clusters and lead times, and then more appropriate numbers can be decided for the new items. For example, the engineers could reason that because the transmission for heavy vehicles can be positioned between the transmissions for light vehicles and heavy trucks, it can be assumed that the needed capacity and lead times lie between the numbers for these other two products. The result of the engineers’ estimates are shown in Figure D.17. We can also check whether these results are realistic by calculating the maximum throughput (Figure D.18) and verifying this estimate with production staff. For the new Heavy Vehicle Transmission, we get a throughput of 24 pieces a day, which can be compared with the throughput of 30 pieces a day for the existing Light Vehicle Transmission (see Figure D.8). If needed, based on feedback from production, the numbers for the new products can be fine-tuned based on these types of reality checks.

Figure D.17Lead time and capacity needed for the Heavy Vehicle Transmission items.

Figure D.18Dedicated throughput calculation for the Heavy Vehicle Transmission items.

Using Capacity Clusters for High-Level Planning

We now build on all the preceding concepts to show how Capacity Clusters can be used in the High-Level MRP (HL/MRP) planning process. Note that most of the processes described below are the standard MRP processes; the difference is only in the retention of the BOM structure and use of the higher-level capacity constructs at several places—both of these are explained below.

The HL/MRP process starts in the usual way with the release of sales orders. A sales order is released with a promised delivery date, so a factory due date can be calculated from this to be sure the ordered product can be delivered to the customer on time. The next step is the generation of the dependent demand, so for a sales order the complete underlying work order and purchase order structure is generated. One difference in relation to classic MRP where all needed work orders are generated unrelated to each other, in HL/MRP the relation between the work orders (dictated by the multilevel BOM structure) is kept in a hierarchical work order structure. Every work order in the structure is assigned to a specific cell, using the matching Capacity Cluster (the product to be manufactured by the work order with a given BOM is related to a Capacity Cluster, so the order has to be assigned to a cell related to the same Capacity Cluster).

With backward-scheduling from the due date, the start dates are calculated for the work orders. If the order flow is being managed by a POLCA control system then these start dates are termed Authorization Dates. After determining the start date (Authorization Date), the work order is put into particular time buckets based on that date. The time buckets are chosen for the specific MRP implementation (typical choices are shifts, days, weeks, and so on). Next, the number of Capacity Clusters needed per work order is determined as explained earlier in the appendix. This amount can be put in a single time bucket (e.g., the one associated with the start date), or evenly spread over the buckets containing the time needed to execute the work order based on its lead time; again, this is a choice of the MRP implementation at the company. Because all work orders assigned to the same cell have their capacity defined with the same Capacity Cluster, the capacity of all these work orders assigned to the same time bucket can be aggregated. Since the available capacity is also defined for a cell using the same Capacity Cluster, the available capacity and the needed capacity per time bucket can be compared and the relative usage of capacity can be calculated. If the capacity usage for a given bucket at a certain cell exceeds a critical threshold (e.g., 90%), the usual planning processes can be used to deal with this issue. For example, typical solutions involve authorizing overtime, adding temporary workers, outsourcing work, or in some cases changing a promised delivery date.

We will illustrate the use of the above approach for the work orders for the final order for five Heavy Truck Transmissions (see Figure D.11). The details of each of the above steps for this set of work orders, along with the associated formulas and calculations, can be found on the authors’ website (www.QRM-University.com); here we present the results of the calculations and the insights obtained.

Using only the work orders generated for the mentioned final order (in other words, without taking into account any other orders), we get the High-Level Capacity Plan shown in Figure D.19. The plan shows, for instance, that for Gear Manufacturing during the first two days, 17% of the available capacity is planned (0.83 clusters planned out of the 5.00 clusters available), for the next two days 37% of capacity is planned (1.83/5.00), and then the capacity planned rises to 82% during the next days. If the company sets its “alarm level” for capacity at 80%, then because the alarm level is exceeded, the schedule shows there is a risk that lead times will be longer than planned because of shop floor congestion. Thus, no more orders should be planned in that period.

Figure D.19High-Level Capacity Plan for the example order.

However, if other orders need to be planned, or if we wish to remove the alarm, then by drilling down into the details in the MRP system we can see which products and work orders are responsible for the needed capacity. At this point the planners can use any of the usual solutions listed above, such as authorizing overtime, moving delivery dates, or other similar solutions as might be appropriate and typically used at the company.

As you can see from the preceding discussion, apart from a few special considerations the processes involved are the usual ones with which the MRP/Planning staff at any company is already familiar. Hence the implementation of Capacity Clusters will not be difficult; in fact, it should simplify the tasks of the people involved for all the reasons explained in this appendix.

Relation Between Capacity Clusters, Lead Time (MCT), and Gray or White Space

It is also possible to connect Capacity Clusters to lead time, and more specifically to MCT (see Appendix A). As explained in Appendix A, the MCT metric for an order can be decomposed into “gray space” and “white space” components. Capacity Clusters can be used to calculate these components. Readers interested in seeing these details for the MadTrans order for five transmissions can find them on the authors’ website (www.QRM-University.com).

Determination of Capacity Clusters and Tuning the Parameters

It can be seen that the concept of the Capacity Cluster is very appealing in regard to getting control over capacity definition at a high level. This is helped in particular by the limited number of parameters that need to be defined to make the system work. A key question, however, is how to define those parameters reasonably. We discussed this briefly with the MadTran example and illustrated the answer with some instances. We now cover this point in more detail.

Analysis of historical data can lead to fine-tuning the relation between BOMs, cells, and Capacity Clusters, but such data are not always available and even when they are, this will only give a first raw setup that needs to be tuned. In many cases it will come down to using common sense when defining the parameters the first time. This makes the possibility of tuning them, based on the first results, even more important. Thus, a possible scenario to set up the parameters could be the following (refer to Figure D.20):

Figure D.20Tuning the parameters by iteration.

• Set up the parameters using common sense.

• Calculate the dedicated throughput for each product in every cell (how many units of each product can be manufactured, when only that product is made in the cell) as shown in Figure D.8 and the accompanying explanation earlier in this appendix.

• Workers and managers responsible for each cell will help you to evaluate how realistic these numbers are. Based on the feedback the model can be tuned until the numbers for dedicated throughput are viewed as being reasonable.

If, after initial use of this approach, work orders still do not proceed as planned, or when measured lead times show large discrepancies from the planned lead times, then a more major tuning of the parameters can be considered by reviewing the relation between BOMs, cells, and Capacity Clusters using one more of the following additional actions:

• Relate a different, more suited, Capacity Cluster to a BOM or a cell.

• Create a whole new Capacity Cluster because the product is not as similar to the other related products as presumed or the competence of a cell does not match the related Capacity Cluster anymore.

• Modify the number of stock units per Capacity Cluster in the BOM.

• Modify the number of available Capacity Clusters for a cell.

• Modify the number of Capacity Clusters for a POLCA card (i.e., the quantum).

• Modify the lead time of the product.

With some experience, engineers and planners will be able to use a combination of the above approaches to improve the accuracy of the high-level planning.

Concluding Remarks

This appendix has shown how the concept of the Capacity Cluster can bring the task of scheduling to a higher level, making the HL/MRP idea more concrete. A major consequence of defining capacity at such a high level is that far fewer data items need to be initiated and maintained, resulting in several benefits:

• Tuning a manageable number of parameters becomes feasible. While it may seem like a lot of work to manage the tuning steps described in the previous section, note that this will still be much less work than trying to calculate and enter hundreds or even thousands of data (time elements, descriptions of processes and operations) as would be needed in standard MRP.

• When adding variations of products, less information and effort is needed.

• For companies making custom-engineered products, configuration of all the details for new products (such as BOM and capacity requirements for all component items) becomes much easier.

• By also defining the capacity of POLCA cards in the same way, the Capacity Cluster implements more accurate capacity signals from downstream cells to their upstream supplier cells.

Capacity Clusters are the missing link between classic MRP and the newer alternative HL/MRP that has been recommended in the literature for companies with a cellular manufacturing structure. The Capacity Cluster concept enables rational and logical planning for this HL/MRP while at the same time reducing the time demands for such planning. In other words, Capacity Clusters make HL/MRP feasible and practical.

About the Author

Ignace A.C. Vermaelen is a Senior Partner and co-founder of 3rd Wave (Lede, Belgium). As an expert business consultant with a track-record of nearly 30 years in multiple areas such as discrete manufacturing, logistics, retail, food industry, and healthcare, he has been involved in several large software development projects concerning ERP/MRP, management information and business intelligence. Within 3rd Wave he is the architect of a QRMtooling set and the ongoing development of the Supply Chain Management and ERP/MRP functionality.

Antoon van Nuffel is Senior Partner, co-founder, and CEO of 3rd Wave. In the mid-1980s, as a pioneer, he brought the theoretical concepts of relational databases (a la Codd and Date) to a useable level with the introduction of a powerful code generator. As manager of a team of professionals, he implemented many ERP projects in multiple areas. Today, he is the driving force in 3rd Wave dealing with the marriage between QRM and ERP.