Flow Control with Critical Chain

In the earlier chapters of this handbook, there are solutions for different types of flow patterns: project flows, production flows, distribution, and sales. Using TOC Tools, we can tame this wild set of processes individually, yet they still need to be knitted together for an effective complex organization.

FIGURE 33-8 Flow of all products.

FIGURE 33-9 Buffered project for ideas.

The first of the four Supply Chain Flow Concepts (Goldratt, 2009) is improving the flow. If we take the flow of Ideas as shown in Fig. 33-7, we can reconstruct the flow using the CCPM approach. Changing the length of each task to represent the expected task duration with an aggressive schedule shows the critical chain and the non-critical feeding activities.

A project buffer is included and feeder buffers are inserted. Figure 33-9 shows such a plan.7 Adding similar solutions for Sales, Production, and Distribution using other TOC recommended processes (aggressive schedules with strategically placed buffers of each type) seems to offer an orderly set of templates for managing the organization. These different templates are shown in Fig. 33-10.

Having an aggressive yet carefully buffered flow pattern for each process and project is not sufficient. If the system is allowed to run without control, every process tries to do its individual best until the system turns chaotic again as in Fig. 33-11.

With so many things going on at once, even when the flows are well defined, the system is unwieldy. There must be some order. The second Supply Chain Flow Concept (Goldratt, 2009) is to insert a practical mechanism that tells the operation when not to produce in order to prevent overproduction. Ordering the flows in logical sequence driven by an overall customer demand such as in Fig. 33-12 can reduce the chaos, speed reliable flow, and more effectively use internal resources. Ordering the flows in this manner means choking the release of work in each area in such a way that work begins only when the system is ready for it. This is done by pipelining projects in multi-project critical chain and using the rope mechanism in DBR or S-DBR for day-to-day production flows. In both of these cases (projects and production), buffers are used to manage the flows.

FIGURE 33-10 Buffered processes.

FIGURE 33-11 Multi-project chaos.

FIGURE 33-12 Sequenced process management.

Sequenced process management in Figure 33-12 connects the flow patterns so that everything moves at the fastest capability of the organization but not too fast or too much. There are different flows, such as the development flow, that run parallel to the production flow. These different flows have cross-flow connectors needed for the different groups to support each other. This process flow arrangement also implements the third Supply Chain Flow Concept (Goldratt, 2009): Local efficiencies are abolished. Work is started and processed at the rate of the systemic constraint, not at the rate of local, nonconstraint resources. There will be some protective capacity in most departments, and the overall flow of the organization will be maximized.

A Breakthrough Injection

With this background, we are ready to revisit the breakthrough injection: Everyone in the organization who has a significant impact on Throughput is measured by the same simple measure (that aligns all the actions of the organization with the goals of the organization). With all the interactions of so many different departments and units, each with its own goals, objectives, and measurements, how can we imagine a single injection, let alone call it a breakthrough injection?

The Definition of the Common Simple Measure

Having buffers for production flows and CCPM schedules for ideas projects in each unit provides the basis for measurement. We want to measure the extent to which a unit is not doing what it is supposed to be doing. We could measure the "not done" things several ways. We could count the number of things not done. We could estimate the value to the organization of the things not done. Moreover, we could measure the duration of time until the error was remediated. Each one of these measures is insufficient. If we only count the number of errors, we could reduce many tiny errors and not really deliver value to the organization. Making an error with a large negative impact on the organization is bad. However, if it only lasts a day or so, it is not nearly as bad as a lesser error that lasts months. Reducing the average time to remove an error may be helpful, but that focuses improvement efforts on the minor, easy-to-fix errors and leaves the big errors unresolved. What we really need is a composite measure that considers both of these factors. Here we can benefit from one of the measures used in TOC Supply Chain Management: Throughput Dollar Days (TDD).8 TDD takes into account both the amount of Throughput that is delayed and the length of time it is delayed. TDD is the Throughput Value (the contribution to the organization represented by the final sale less any truly variable costs), which is assigned to product or process flow, times the number of days late added together for all late tasks (lateness is defined as not delivering the required quantity or quality on the mutually agreed upon date). TDD is a measure of reliability. It measures a department's or independent business unit's delivery to promise for both production flows and project activities.

Before we discuss an example, we should be clear that we are interested in providing senior management with information that is useful for managing the whole organization. Within each separately measured unit of the organization, we expect managers to use TOC solutions (primarily DBR and CCPM) to manage their resources to meet their commitments. We are proposing here that TDD only be assigned at the point that either a production flow or project moves from one separately measured unit of the organization to another, that is, at the handoffs between separately measured units. We are using TDD to measure unit performance, not individual task performance within units.

It is also important to state that we are not suggesting that a milestone be established for every activity in a project. We are trying to provide senior management with information about separately measured units in complex organizations. A major problem in organizations that have significant project work is understanding the relationship between capacity and demand. In units that have both production and project work, most resources will generally work on one or the other. Occasionally a resource will be required to work on both production flows within the unit and project activities for other parts of the organization. For example, a test engineer may have day-to-day quality control responsibilities for a unit's production and be required to regularly complete activities that are part of projects managed by other units of the organization. If the test engineering resource is a non-constraint, BM within the unit will ensure that both process flows and project activities are completed as required. If the test engineering resource is a constraint, use of DBR within the unit should prevent commitments either to an external customer or to another organizational unit that cannot be met. However, unit managers frequently have difficulty assessing whether they have resource constraints, and consequently, frequently make commitments that cannot be met. This is particularly a problem when project activities are a source of demand. In these situations, TDD will provide useful information to senior management as to where attention should be directed.

Using TDD to assign lateness to different departments and independent business units is similar to the TOC Replenishment solution for Supply Chains. It is not the same as normal CCPM. In CCPM, the project manager uses BM to take care of task variations. The project manager can allocate resources as needed to deal with buffer penetrations. However, in complex organizations, the resources are not generally available for reallocation. In complex organizations, the workflow is secured by promises that are critical to synchronization.

Most complex organizations make extensive use of milestones. Milestones are not so much a measure of performance as they are markers to indicate a project or process has progressed to a certain point. Milestones are not very good management tools because there are too few of them and they are too far apart. In addition, milestones are lagging indicators: They do not tell you what is coming in time to make corrections. They only tell you when it is too late to do anything about it. A missed milestone usually means a serious problem has occurred. Missing a milestone puts tremendous peer pressure (if not management penalty) on the errant party. To avoid this peer pressure, groups will often inflate their delivery times and create all the problems discussed in Chapters 3, 4, and 5 on CCPM.

In contrast to milestones, TDD is a forward-looking indicator of what is going on in the organization. Units will begin incurring TDD before commitments to customers are missed because production flows and project activities that result in TDD are still buffered by shipping and project buffers. In addition, TDD is reported often. The periodic TDD by unit shows which units are having the hardest time delivering for a period of time. The TDD accumulating in a project or production flow can be seen early, well before it is too late to respond. When monitored over time, TDD (like the causes of buffer penetration) highlight where the organization needs to focus its management attention and improvement efforts.

With TDD, senior management will have a method to determine which departments or units need attention. Units will incur TDD when they commit to deliver things that they cannot deliver. A unit that incurs TDD will not automatically receive additional resources. The first question senior management should ask is why the unit manager has committed to deliver things that the unit does not have the capacity to deliver. While people figure out over time how to game almost any performance measure, the fact that TDD should be decreasing over time as unit managers become more proficient at DBR and CCPM means that units will not automatically be receiving additional resources just because they are incurring TDD.

Using TDD: An Example

Let's use an approved and scheduled project as an example. Many people and units are involved in projects but for simplicity, only three groups are shown in Fig. 33-13. The Service department is responsible for the first element of the non-constraint feeding chain. The Distribution department has two contributions, one on the subchain and one on the critical chain. The Production department has one contribution on the critical chain. For this example, assume the overall project is approximately 40 days on the critical chain with 20 days of project buffer. If the Throughput value of the final project "Ideas" is $10, we can easily evaluate the subordination of the Service department, the Distribution department, and the Production department to the overall process of producing Ideas.

FIGURE 33-13 Distribution's obligation to producing ideas.

Completing a project requires participation of many independent groups who agreed to delivery at a certain time or to respond within a certain period according to the plan. A unit or department may perform one activity or several consecutive activities on a project. The overall owner of the project illustrated in Fig. 33-13 is the Development department. Because it is the project owner, the Development department has a project buffer that protects delivery of the project to the final customer from any late delivery by the individual groups.

Let us assume the Service department agreed to deliver its part of the Ideas project on day five to the Distribution department, but actually delivered on day eight, three days late on a project valued at $10 Throughput Value. The Service department is assessed three days $10 or 30 TDD. Now, the Distribution department works on its task and completes it in one day longer than they planned. The Distribution department is assessed one day $10 or 10 TDD. Both Service and Distribution departments have been assessed TDD. In thinking of TDD, we can say that each promised delivery is a commitment. When a promise is not met, that commitment is missed and the potential impact on the Throughput of the organization can be defined. For the project, the total TDD for this feeding chain is 40 TDD. TDD are additive. While TDD indicates a later delivery than promised, the normal TOC buffering process (the strategically located buffers used in DBR, CCPM, and Replenishment) protects against late delivery of the final product.

Next, we consider the Production department. Let's assume that additional actions by another department prior to the Production department have delayed the start of Production's task such that production is 10 days late to start. The department causing this delay would be charged 100 TDD ($10 10 days late). Production then takes two days longer than the response time they planned to complete their work. This additional two days taken by Production to deliver adds 20 TDD to Production and 120 TDD charged to the project.9 FIGURE 33-14 Distribution's TDD performance.

The next critical chain task is performed by the Distribution department. By good chance, the Distribution department is able to complete four days faster than their commitment. The Distribution department is assessed zero TDD. The early completion by Distribution does not affect the TDD assessment for the department or the TDD assessed to the project. What does happen in reality is the early completion by the Distribution department helps recover some of the project buffer consumption, which is reduced from 12 days to 8 days.10 The TDD measures assessed to units along the critical chain paths are additive. They reflect the capability of the system (an accumulation of many individual groups) to deliver as promised. While TDD encourages independent yet interrelated groups to deliver to promise (to be reliable), it also gives management a much-needed measure to determine the capability of the overall system. Over time, TDD levels and trends can be used as an indicator of which groups need improvement, assistance, or elevation.

A Closer Look at the Distribution Department

Let us look at an example of how this works for the Distribution department. Figure 33-14 shows the Distribution department's TDD over the most recent period of time (in this example, the period is 20 days) where the two tasks for Ideas (discussed earlier) were performed. The arrow above the task shows when the Distribution department actually worked on the project to deliver Ideas. Over this period, the first task for Ideas was one day late, incurring a 10 TDD assessment. The second task for Ideas was four days early and assessed zero TDD. The sum total for the period (just for Ideas) was 10 TDD.

There is a difference between commitment dates for separately measured units and task times for individuals. When individuals estimate their own task time, you cannot punish them for being late or reward them for being early. Either one (reward or punishment) motivates the individual to extend future estimates of task time. However, when TDD is used to measure the reliability of a unit's commitments to deliver, both internally and to customers, we expect the unit to use strategically placed buffers to ensure that the commitments can be met (see earlier chapters of this handbook, which address DBR, CCPM, and Replenishment). TDD is not a penalty but an indication to senior management that a unit is missing its commitments. TDD indicates how effectively the unit uses DBR and CCPM to manage its internal operations. If unit management has a good understanding of the unit's capacity and demand and effectively uses DBR to release work into the unit at the rate the constraint can process it, then TDD for the unit should be very low. TDD will be incurred, however, if management does not have a good understanding of capacity and demand and too much work is released into the system. The purpose of measuring TDD is not to punish or reward unit management but to tell upper management where attention is needed. In addition, we do not reward a unit for recovering TDD on a project managed by another unit. Doing so would encourage units to overstate the number of flow days required or to increase unit resources without real need. Units with the highest TDD should not be punished. They should be studied and helped to see if improvements can be made. Tracking and managing TDD over time at the system level gives the signals needed by top management about the management of capacity at the unit level and can guide the growth process while maintaining stability.

Of course, the Distribution department contributes to more than just Ideas projects. Their predominant duty is for the distribution function itself, but the Distribution department also has assignments to support Sales and Production. Figure 33-15 shows several segments of the Distribution department's workload over time. We see that the different products that they support cause some periods of heavy workload and other periods of less workload.

During the first 20-day period shown in Fig. 33-15, the Distribution department had some trouble. They were one day late on the Sales task (at the top), one day late on the Ideas task (near the middle), and one day late on the Delivery task (the bottom). In total, over that period, there was a $20 Sales task delayed for one day, a $5 Delivery task delayed one day, and a one-day delay for the $10 Ideas task; their TDD for the period was 35 TDD. During the second period, the Distribution department improved their primary performance measure. They had no late deliveries for zero TDD. We note that they were able to start some of this work early (they shifted the schedule) to take advantage of time when they were not so overloaded.

Units to Which TDD Applies: Degree of Impact on Throughput

TDD is clearly applicable to some units of complex organizations, such as production, sales, distribution, and engineering. These units have clear commitments to either outside customers or to other organizational units that directly contribute to Throughput. In addition, there is another category of units that can delay Throughput even though they do not make commitments to customers themselves. For example, the Human Resources department can affect Throughput if necessary employees are not hired and trained when needed. Purchasing can delay Throughput by contracting with unreliable or poor quality suppliers. IT can delay Throughput if it fails to deliver a critical application to Production on time. TDD should be recorded for these units as well.

FIGURE 33-15 Distribution's total workload.

There is a third category for units or departments that have a much less direct effect on Throughput. For example, Accounting is responsible for generating monthly, quarterly, and annual financial statements. This is a critical function, so a project buffer would be maintained but the impact of this function has only a very indirect impact on Throughput. It is difficult to see how TDD would be measured for this function of the Accounting department.

These three categories of units might be classified with respect to their impact on Throughput as primary (Production, Sales, Distribution, Engineering, and similar units), secondary (Human Resources, Purchasing, IT, and similar units), and tertiary (the financial reporting function of the Accounting department). For units with primary and secondary impact on Throughput, TDD makes sense. For units or departments in the third category, it is difficult to see how TDD might be measured. However, it is well established that measures motivate performance and we would like to be able to measure units whose work falls in this third category for that reason alone. If we can develop a measure that allows senior management to monitor the performance of such units in a way that allows comparison across different units, it would be helpful.

Alternatives for When TDD Does Not Seem to Fit

Some organizational units (particularly support groups) have little control over when work is assigned and some have undetermined delivery dates. Others control their own demand and do not have delivery commitments to either external customers or other organizational units. An example of the latter is a process improvement or cost reduction group. TDD cannot be measured because there are no delivery commitments to other organizational units or customers. For such groups, the focus can be on doing good things-generating Throughput in terms of completing whatever support tasks the unit is responsible for in a timely manner. Two examples might be helpful here. The first is the Product Cost Improvement Program (PCIP) at Boeing. The PCIP is a group of engineers who evaluate and implement cost reduction suggestions from various parts of the company. The group evaluates cost-saving proposals and decides which to implement. Without real delivery commitments, it is easy for the group to release many projects into the system and, due to multitasking, take a long time to complete projects. When projects are completed, however, there is a definite cost saving realized by the company. By measuring the amount of Throughput transferred through the group each day (Throughput per day or T/D), the group can see how much work is being done and track its contribution over time. Tracking the amount of Throughput delivered per day encourages the group to reduce process flow time and take actions that improve Throughput value; both increase T/D. It would be easy for the PCIP group to report T/D calculated on a monthly basis. Because the PCIP group does not have delivery commitments to other units in the organization, TDD cannot be measured for the group. However, it is still helpful to have a measure of how much the group is contributing to the organization and how well it is doing in fulfilling the purpose for which the group was created.

A second example is the hiring process of the Odessa, Texas Police Department described by Taylor et al., (2003). The department's hiring process required an average of 117 days and was not hiring sufficient officers each year to maintain the department at the desired strength. The TOC TP were used to identify what to change, what to change to, and how to cause the change, but the impetus for starting the process was awareness of the shortfall in the hiring department's production relative to its goal of hiring an adequate number of officers each year. Although the department did not use such a measure, it is easy to see how the department could have used a measure similar to T/D to monitor its progress. In this case, "officers hired per month" would have been useful to make senior management aware of the progress of the hiring department in meeting its goal of hiring sufficient officers to maintain the required strength of the police department.

The definition of Throughput suggested in the TOCICO Dictionary (Sullivan et al., 2007, 47) in these two examples is "the rate at which the system generates 'goal units. '" ( TOCICO 2007, used by permission, all rights reserved.) Even departments that do not have a direct impact on Throughput can define goal units to monitor their progress. Typically, T/D is calculated as the number of goal units delivered over the reporting period divided by the number of days in the period. T/D encourages groups to move quickly to complete larger Throughput value work sooner. In addition, it encourages shortening the flow time of all work, especially the lower Throughput value tasks.

Any organizational unit should be able to determine its goal units and calculate a T/D. This measure helps unit management stay focused on the unit's goal, but some units could also benefit from another measure, described next.

Inventory Dollar Days

We can borrow another supply chain measure, Inventory Dollar Days (IDD), to help the PCIP group and the Odessa Police Department monitor their progress by focusing attention on the number of projects released into the system before there are sufficient resources to process them. The traditional definition of IDD applies to physical inventory. Inventory Dollar Days (IDD) is defined in the TOCICO Dictionary (Sullivan et al., 2007) as IDD is computed as the sum of all current inventory on hand valued at the original purchase price times the number of days since the inventory was received by the unit being measured.

(a) measure of the effectiveness of a supply chain that measures whether the supply chain did things that it shouldn't have done, the result of which is that the supply chain is holding inventory of products customers don't want. The system should strive for the minimum IDDs necessary to reliably maintain zero throughput dollar days. ( TOCICO 2007, used by permission, all rights reserved.) Effective use of DBR and eliminating efficiency as a performance measure at non-constraints obviate the need for measuring IDD for physical inventory within the organization. However, we can redefine IDD to help with "conceptual inventory." For some groups that have no physical inventory but have a flow of small projects, assignments, papers, or mental tasks, it would be helpful to just count the number of such items in progress and measure how long they take to complete. For example, an Internal Audit department might just count the number of audits in progress and the length of time they are in progress. If five audits were in progress at the beginning of the month, and none was completed, and no new audits started, the department would report 150 "audit days" (5 audits 30 days) incurred during the month.

Sometimes it is straightforward to assign a dollar value to the inventory of these conceptual items. In the internal audit example, the department might assign an average value of $100 to audit hours incurred and use this to determine the inventory value of audits in progress. For example, an audit that is budgeted for 120 hours would have a total value of $12,000. Because on average only half the hours have been incurred at any point in time, a useful simplification would be to assign an inventory value of 50 percent of the total value, or $6,000, as soon as the audit is initiated and use this figure to accumulate IDD throughout the duration of the audit. This approach has the benefit of valuing larger audits at a proportionately higher value than small audits, with the result that IDD would be a more accurate reflection of the work that is in progress than the simple "audit-days" measure described previously.

Applying this concept to the Odessa Police Department, a value of one-half of the salary of the position being hired could be used as an inventory value. For example, if the department were starting the hiring process for a new administrative assistant at a salary of $20,000, one-half of that amount or $10,000 would be added to "inventory" and kept there until the person was actually hired. At the end of each reporting period, the total number of IDD would be reported. In this case, if the search for the administrative assistant had been started on the 21st day of the month, $100,000 IDD (10 days 50 percent of $20,000) would be reported at the end of the month. If the search were not completed the following month, another $300,000 IDD (30 days $10,000) would accumulate. This measure would be extremely valuable when the department is hiring a class of 10 recruits. If the average pay for a new recruit were $30,000, IDD of 4,500,000 (50 percent of $30,000 10 recruits 30 days) would be incurred for each month the hiring process continues. Assigning dollar values to these types of projects, assignments, papers, or mental tasks is helpful where it is possible, because managers naturally focus on dollar amounts more easily than on simple item counts.

It should be noted that the use of IDD described here is not the same as its use for physical inventory in the supply chain. When used for physical inventory, the primary purpose of IDD is to discourage supply chain partners from doing things they should not be doing, that is, building inventory before it is necessary or building inventory that may never be necessary. Our primary concern here, however, is not with organizational units doing things that should not be done (e.g., hiring the administrative assistant) but with providing visibility to unit management of WIP and encouraging units to strive to complete tasks quickly. The longer the projects, assignments, papers, or mental tasks are held in the system, the larger the value of IDD. There is an incentive to complete assignments and tasks quickly to stop the accumulation of IDD.

To see how IDD might apply to the PCIP group at Boeing, assume that the decision is made to release project 123A, which requires repositioning a support bracket on the 747 to save $1,000 installation labor per plane. If an engineer starts the project today and pushes all of the necessary reviews, approvals, and other interactions with other units, the project will require 10 hours of PCIP engineer time and can be completed in one month. Without diligent follow-up and focus on this project, however, significant multitasking with its attendant switching costs and lead-time effects can occur. As mentioned previously, the PCIP group has not committed to deadlines for other units so it is up to the unit to make sure projects get done quickly. In this case, the project can easily take six months or longer to complete and may take 15 hours of engineer time if the engineer does not aggressively pursue it. During the additional five months, 25 airplanes have been completed without the improvement, costing the company $25,000 more than they might have. Assume the present value of the cost savings over the remaining life of the 747 program is $250,000 if the project is completed in one month. As previously, assume that half the Throughput value ($125,000) is assigned as the inventory value from the inception of the project and that the project is started on the 26th of the month and completed on the 20th of the following month. For the first month, IDD of $625,000 would be recorded (5 days $125,000) and for the second month $2,500,000 would be recorded (20 days $125,000) related to the project. Tracking IDD will motivate the engineer to stay on top of this project and push it through the system to minimize IDD in the future.

The actual results for Boeing's implementation of T/D and IDD for the 747 and 777 PCIPs are impressive. The engineers associated with the PCIPs for each aircraft began focusing on the measures and asking the right questions. Analysis of the impact of implementing these measures from June 2001 to February 2002 and from October 2002 to March 2003 showed Throughput (net cost savings) for completed PCIP projects exceeding $62 million, a 500 percent increase over similar periods before T/D and IDD were implemented. In addition, flow time decreased by 50 percent, costs were reduced 40 percent, and the quality of the product increased. After the new measures were implemented, the group manager stated that all of the group's prior measures could be eliminated because T/D and IDD were all they really needed to know to manage their process (Mortenson 2002; Chambers 2003).

Summary of Measures

Table 33-4 summarizes the previous discussion of the use of TDD, T/D, and IDD for different types of units in a complex organization.

TABLE 33-4 Summary of Measures

Focusing for Balance (and Changing the Culture of the Company)

With TDD, the fourth Supply Chain Flow Concept is also in place for the parts of the organization that most directly affect Throughput. TDD provides the focusing process to balance flow (Goldratt, 2009). While Ford used direct observation and Ohno used the gradual reduction in the number of containers and then gradual reduction of parts per container, TDD can be used to focus on balancing flow based on time.

When using TDD on the critical process flow, it is easy to see where the system is unbalanced.11 Senior management can use TDD because it has a consistent meaning across units, that is, that an organizational unit has been late on a commitment to deliver to either another unit or a customer. The magnitude of TDD is easy to interpret.

In addition, since everyone is measured in the same way, this means the top levels of the company want exactly the same thing as the bottom levels of the organization: fast, reliable flow. With this in mind, the top priority of the top of the organization is to ensure that the lowest levels of the organization are fast and reliable. These measures link local actions to global results. Those at the bottom of the organization also want senior management to succeed at being fast and reliable because that means the bottom of the organization will be achieving its goals as well.