Critical Chain: A Business Novel

by Eliyahu M. Goldratt

"All the new management philosophies," Johnny is now on a roll, "implicitly recognized it. They all try to stress the importance of protecting throughput, th...

"TQM and JIT are adamant about throughput even though they haven't realized that it mandates a much sharper focusing. Reengineering puts the emphasis on reexamining basic assumptions. A cornerstone of the learning organization is to replace unsatisfactory compromises with win-win solution...

methods, all these philosophies, at last, merged into...

Finally, when they calmed down, he reminded them that the main reason for an operational measurement is to induce the departments to do what is good for the company as a whole. They had to agree.

Then he reached the conclusion that in the steel industry, we are bound to find that departments try to maximize their performance as measured by tons-per-hour, 515.

Like the fact that in almost all departments some items require less time per ton than others, 520. For example, in the rolling department, you squeeze red-hot steel into plates to produce ten tons of two-inch thick plates, which takes much less time than to produce ten tons of one-half-inch thick plates. The result must be that in order to maximize their performance of tons-per-hour in a given measurement period, departments tend to produce the fast items at the expense of the slow ones, 540. You can imagine what this

leads to. High inventory of the fast items, while missing orders on the slow items.

Don asked them how long they would run after a four-hour setup. Minimum a whole shift and usually much longer, was the consensus. And if there are not enough orders? After these questions nobody argued with the conclusion: to maximize their measurement of tons-per-hour, departments tend to process orders ahead of time and out of sequence in order to increase the batch size,

The worst situation for a department is to be idle. Non-production results in zero tons-per-hour, 525. It's no surprise that to maximize their tons-per-hour, departments tend to produce for stock, even when there is no market request on the short or medium horizon, 545. This definitely doesn't help the inventories.

What typifies the base industries, steel being one of them, is that the nature of their process is to have divergence of products at each stage of production. For example, in the rolling department, they produce many different plates from the same type of steel. Plates different in thickness. Once you produce a two-inchthick plate, and later you change your mind and want to turn it into a one-inch plate, it's too late, the steel is already cold. It's the same in the slitting department, where they slit the plates to size. If you slit a plate to be seventy inches wide, you cannot later make it eighty inches. In short, in the steel industry, items are produced through a

process having many divergent points, 560.

Now combine all this with each of the facts outlined in 540, 545 and 550, and what do you get? You get that to maximize their performance of tons-per-hour, departments tend to take actions that result in "stealing." No, nobody suspects that a worker puts ...

For example, we prepare a specific plate for only two nearterm orders; ten tons for sixty-inch-wide plates and another ten tons for seventy-inch-wide plates. The setup time in the slitting department is about three hours. To slit ten tons takes less. They try to run at least a full shift on the same setup. What happens? They slit all the twenty tons into one width and then scream hell that they were not given the material for the other order. You can imagine the resulting ...

They estimated the impact on lost sales, excess inventory, wasted cost, long delivery lead times, unreliable duedate performance, and, not less important, time w...

Don didn't dismiss anything they raised, even though some of them looked to me like pitiful excuses. With each problem they raised, Don made them quantify the negative impact. Then he guided a discussion of how much of that impact is due to what was already described on his diagram. He kept on referring to it as their current-reality-tree; the logical description of the effects stemming from the fact that they operate in the environment created by the tons-per-hour measurement.

It was amazing. For example, they complained about their vendors not always delivering on time. Don made them realize that if they did not produce so much excess inventory, they could hold much bigger stocks of raw materials. Vendors not delivering on time would then become a minor point.

Or, the problem that clients sometimes change their minds at the last moment. After inquiring, ‘last moment' turned out to be four weeks before delivery. If lead times were much shorter, this also would not be a problem, as they would ha...

Once you understand TOC you realize that there are no real-life systems with twenty constraints. Such systems will be chaotic to the extent that reality will have eliminated them a long time ago. Real-life systems have one, maximum two, constraints.

The thinking process of TOC, called the evaporating cloud, caused a revolution in my work. This method, or better still, this thinking process, is the antithesis of what I was used to doing.

Presenting a problem as a conflict between two necessary conditions makes a lot of sense. But I was almost programmed to proceed to find a compromise. In academia we don't call it compromise, we call it optimize. Three-quarters of my articles are optimization models of some kind. You can imagine how difficult it was for me to accept that a much better solution, or even solutions, emerge by refusing to attempt to find a compromise, and instead concentrating on exposing the underlying assumptions.

In any event, nobody admits to putting safety in their time estimates. When I mentioned safety of two hundred percent, they laughed in my face."

"You should have asked people for their opinion about the chance of finishing a task in the time they estimated," I answer. "That's all?"

"From my inquiries, one thing came out very clearly." And he makes the following declaration: "The time estimates are impacted, in a major way, by the last overrun the programmer had."

"I don't think that there is

much point in asking computer programmers to evaluate their chance of finishing on time. Computer programmers will never admit ninety percent chance, not even eighty, because a programmer who finished on time has not yet been born. At the same time, let me tell you, there is nobody like an experienced programmer to pad himself with safety." Not knowing much about programming, I ask, "Why?" "It's obvious. Otherwise they wouldn't have the time to add all the bells and whistles that nobody needs. If you don't sit on a programmer, he will never finish, he always has another something he must add."

"Every foreman will say that if everything is ready for him, and that's a big if, then he won't have much difficulty finishing his share on time. They don't talk in terms of probabilities, but they mean over ninety percent."

As you can see there, except for one person who is known to be paranoid, the vast majority said they think that they have better than an eighty percent chance of finishing on time." "There is a caveat to it," Ruth adds. "Almost everybody emphasized that their answer is dependent on others not delaying them, and not being loaded with too many other things at the same time."

"Whenever a step in a project is a collection of several tasks, each done by a different person," Ruth explains, "the boss of this project asks each person for their own estimates, adds them up and then adds his own safety factor on top." "So, if one estimates his task to take five days," Fred continues, "and the following task of the same team is estimated to take another five days, the person in charge will give an estimation of thirteen days."

"Sometimes," Brian interjects, "there are several management levels involved. Each level adds safety."

"In our environment, top management is frequently not happy with the final estimation of when a project is expected to be finished. They want the results sooner. So in half the cases, when all the estimates are done, they demand the lead time of the project be cut by, say, twenty percent. This global cut is usually translated into everyone, across the board, having to cut their times by twenty percent. By now everybody is used to it, so they inflate the final estimates by twenty-five percent to start with."

there are three different mechanisms by which safety is inserted into the time estimates of almost every step of a project. "The first one is that the time estimates are based on a pessimistic experience, the end of the distribution curve. "The second is that the larger the number of management levels involved, the higher the total estimation, because each level adds its own safety factor. "And the third is that the estimators also protect their estimations from a global cut.

"Because the team that finished ahead of time won't report it. You see, the way we are set up, there is no reward for finishing early, but there is, in fact, a big penalty." And he explains, "If you finish early you just invite pressure from management to cut the times. Your friends, in charge of other similar teams, will not like it, to say the least." "So what will happen?" "They will find ways to play with it. Don't worry, if they don't want you to find out that they finished, you won't." As a second thought he adds, "Besides, even in the unlikely event that they do report it, it doesn't mean that the second step will immediately start. That team is probably busy doing something else, they might even be at another site."

"Definitely," Charlie is firm. "Even though not exactly for the same reasons. A programmer is not afraid of his peer's reaction, but as I already mentioned, it will not

cross his mind to say that he finished ahead of time. He or she will always find something in the program that can still be polished a little more." "And if they report an early finish?" I encourage him to continue. "Still not much will happen. The person who is supposed to do the next step knows that there is sufficient time, so what's the rush?" "Let me see. What both of you are telling us is that it is likely that an early finish will not be reported. And even if it is, frequently the time gained will not be taken advantage of by the next step; it will just be wasted."

"A delay in one step is passed, in full, to the next step. An advance made in one...

"In sequential steps our deviations do not average out. Delays accumulate, while advances do not. This can explain how so much of our safety disappears."

I draw four boxes all leading to one. "Suppose that in

three of these steps we were early by five days. And in one step we were late by fifteen days. Statistically, if we average out all four boxes, we are on time."

"In the case of parallel steps, and in any project there are many of them, the biggest delay is passed on to the next step. All other early finishes do not count at all." "What you are telling us," Ruth is thinking hard, "is that most of the safety we put in doesn't help at all." "Correct." "If we could find a way to put the safety only where it's needed..."

The only thing that counts is the performance of the project as a whole. At the end, it doesn't matter how many steps were not completed on time, as long as the project was delivered when promised. And what do we do? We try to protect the performance of each step. Most of this protection is wasted. So even though we put in that much safety, the project as a whole is exposed."

"That's important," I say. "It means that if we don't have a mistake in our logic, it must be that we are somehow wasting the safety, not just on the project level but on the step level as well. Anybody have an idea?"

"When we got the homework assignment we all claimed that two weeks was not enough time to do it. And we succeeded in getting a postponement. Now how many of us, after we screamed that we needed more time, went back and immediately started working on the assignment? I bet that no one did."

"The students' syndrome," Brian says. "First fight for safety time. When you get it, you have enough time, so

why hurry. When do you sit down to do it? At the last minute. T...

"this digital processing department. Are they involved in many projects?"

"All projects. That's our bottleneck. We can't afford to dedicate these people to one project at a time. And in each project, there are many steps that they must be involved in." "So, if I understand you correctly," I say, "each person is multi-tasking."

Mark is the one who gives the answer. In astonishment he says, "The lead time of each step doubles. I knew that multitasking was bad, but I didn't imagine to what extent. And we didn't even consider the setup time that is wasted." "Multi-tasking is probably the biggest killer of lead