VOLUME 1, NUMBER 3 | FALL 1998

Eli Goldratt:
The Future of Manufacturing


by Tom Inglesby



I stop and look at him. "What are we asking for? For the ability to answer three simple questions: 'what to change?', 'what to change to?' and 'how to cause the change?' Basically what we are asking for is the most fundamental abilities one would expect from a manager. Think about it. If a manager doesn't know how to answer those three questions, is he or she entitled to be called manager?"

"At the same time," I continue, "can you imagine what the meaning is to being able to hone in on the core problem even in a very complex environment? To be able to construct and check solutions that really solve all negative effects without creating new ones? And above all to cause such a major change smoothly, without creating resistance but the opposite, enthusiasm? Can you imagine having such abilities?"
— Alex Rogo, The Goal


I first met Eli Goldratt in 1985, shortly after his seminal book,
The Goal was released. He was standing before a restless crowd of APICS members at their annual conference, playing the role of "barker" as if he were in an old-fashioned carnival. Or at least that's what it seemed like to me, a know-it-all editor. To me, it was simply a case of an author, and software developer, making a pitch for something that no one knew they needed.

That was then, now is a bit different. Goldratt's Theory of Constraints approach hasn't become the world beater that some expected but it certainly has proven the know-it-all editor wrong. So much so that I took to rereading his books to see what I might have missed all those years ago. I found that, with age, they make a lot more sense to me now. I'm just not sure if it is my age or that of the theory that makes this happen.

While there are many who dispute Goldratt's guru status, more than a few have come over to seeing some very basic, and very usable approaches — sometimes deeply buried within the novel metaphor — in what he has to say and what he has written. Like many modern management theories, Goldratt's depends a great deal on basic logic, things that, given the time and effort, we'd all see as obvious. The problem is, we often fail to take — or have — the time to see beyond the immediate issues, clouded as they are by the smoke from the many fires we are constantly faced with putting out. Maybe it's time to take some time and see what we've been missing.

Goldratt currently resides in Israel and, as the following interview shows, there may be a few more years and a few more books to make Goldratt's legend grow among executives and managers.



Tom Inglesby: When you were developing the Theory of Constraints (TOC) and its practical applications within manufacturing, what process did you used? Were you using the concepts that developed into TOC?

Eli Goldratt: That would give me too much credit. I didn't develop it; it's a standard concept in physics and so naturally, being a physicist, I used it. However, it's very different from the process of thinking that is used outside the health sciences. If you want to know the evolution of the Theory of Constraints as applied to manufacturing, the first thing I decided was to use a computer. But this was not to solve the problem of scheduling the shop floor, which is an immense problem. I was trying not to approach it like MRP (material requirements planning) or today's ERP (enterprise resource planning) which are information technologies. I thought, "Let's make sure the computer will help us move the data from one source to another; spread it out correctly, so the data can move very efficiently throughout the organization." This is important and the larger the company the higher the value. Seldom now do you find a paper contract, the relevant pieces of information are in the form of data moving to purchasing, finance, and so on. The computer makes sure nothing falls between the cracks. This has great value for large companies. The smaller the company is, the smaller the value.

Aren't there problems associated with dependence on computers?

Data usually comes with mistakes. If you don't clean the data, what you get as a result of optimization is pure garbage. But if you try to clean all the data you find that the time, not to mention the effort, to clean the data takes more time than the lifetime of the data itself. Which means it's almost a deadlock. What you need to do is to find out which part of the data it's essential to clean and which parts are not relevant at all.

I also found that the real problem is not the ability to optimize, but the measurements, procedures and policies — many of which are totally against any common sense. So the problem is not so much the computer, but how to fight the devastating policies, more than half of which stem from cost accounting. Remember, in the early 1980s cost accounting was regarded as a total sacred cow. I think that's what caused me to write the book The Goal. In The Goal I don't mention the computer or optimization. People read it and fell in love with it. I would say at least 2,000 to 3,000 companies have implemented it [Theory of Constraints] and replicated exactly what was written in The Goal, including the result.

But then came the next problem: You implement it in production, the constraint moves to another department. If you don't move after that constraint, you stagnate because the constraint is now blocking the results. How do you chase the constraint and break it no matter where it lands in the company? We found the constraints were in production and distribution and engineering product development and marketing. That was a huge problem. In marketing there was not one generic answer. There was only a generic process to find the specific answer. Out of 2,000 companies, we haven't seen two companies with the same answer. That's when I developed the thinking processes which are used to develop your own answers and published them in It's Not Luck.

Once companies are really moving fast, it turns out the constraints that now dictate the rate of growth and the rate of improvement are in relationship. The thinking process was already developed so it was a problem of how to teach people how to use them. It takes about a day to teach the process, but then using it takes only a minute. For these problems, you don't have a whole week to do a full analysis and construct the solution like you have when you are dealing with huge marketing problem. Once I became convinced that the practical solutions were implemented and checked for any area of the organization, regardless of the constraint, then I decided the time had come to retire.

So it started from a computer software organization, then it moved into a method of how to run the shop floor, continued to methods of how to run other parts of the organization, and then it was developed into the thinking processes. That is how you develop such things. Now it has developed into a holistic method of how to run any organization.

How do you deal with people's fear of changing their way of thinking for fear their metric, that by which they are measured by their management, is not going to allow them to proceed? How do you overcome the corporate politics problem?

For that there is the "buy-in process." In other words, how you sell your ideas. You mentioned bosses, but many times the problem is your peers more than your bosses. Likewise, if you are a top manager, convincing people below you is not so easy, and if you try to dictate, it doesn't work. There is a problem of how you convince people to do the right things. I've developed five steps of the buy-in process. I can tell you, it's working to my full satisfaction.

The first thing is, how do you convince people so you get a consensus on the problem? This must always be the first step. Of course, at this stage you are not allowed to talk about your ideas of how to correct the problem. You can't persuade a person that's the problem by the mere fact that you have the solution for it. That is not exactly a decisive argument. What most people call problems are what I call bad symptoms. If you try to get a consensus on which bad symptom we have to deal with, you never reach a consensus. People are looking at things from different angles, from different positions in the company and you can not get a consensus on what is the biggest undesirable effect. But instead you take the time and use what Newton showed to be so effective in physics — that there is an Archimedes point, one point that causes all undesirable effects. If you present it as cause and effect connections, then you won't have any problem getting a consensus.

Once you reach a consensus on the problem, then you should be careful not to show your solution, but to reach a consensus on the direction of the solution. Only then can you reach the next point, which is getting a consensus on the solution. You haven't finished, because then is the time you start to run into the "yes, but" arguments. "Yes, I agree with you, but there is an obstacle standing in the way to implement it." Once again, the idea is not to answer it directly, but to show the person the full logic of why he rightfully claims that from the solution, "this and this" will be the problem. Amazingly enough, if you show the person the logic of why he will be right, at that time he will be able to come with whatever additional change needs to be done in order to overcome the problem. And that becomes part of the solution.

I gather you are not sold on the concept of team-based management as being effective.

You have to make a team out of the team. It's not so difficult, but if you approach it in the conventional way, we will not get a team. Unless of course they've grown together through so much experience that they've learned how to accommodate each other. Otherwise, they simply don't get it. In most companies, when I see a team, they're coming together with their experience, their baggage and with their legitimate interests. Then what you get is not a solution but typically a lousy compromise. You get the situation where the failure is an orphan. Everybody will blame everyone else. That's not the correct way to go. If you are a team, where each person is viewing the same thing from different angles, then you'll find if there is one thing that leads to all of their problems. Unfortunately, in most cases I've seen, it's not done.

If you carefully read The Goal, especially the new version, in the last 90 pages you'll find that is exactly what Alex Rogo is doing. He's building his own team. Nevertheless, he doesn't take it for granted; he's spending all his time finding exactly what is the core problem.

He goes from specific to universal very rapidly. From the beginning of the book to the end, he grows tremendously.

You'd be amazed, but that's what we see in reality. These people who are going through that, that's exactly the curve that they're having — an exponential growth.

You're finding that when people are on a learning curve, the curve becomes much steeper as they get more into it?

Exactly. Much, much steeper. It's wonderful to watch.

Is there a wall they run into?

I haven't found it yet.

The presentation in your various books is based on Socratic principles, the method of leading people to find answers for themselves.

Correct. It seems strange to me that people don't realize it, because it's standard in physics and chemistry. That's the way it's done. Cause and effects, finding the core problem, whenever you raise a reservation you have to show exactly the causalities, not just give your opinion. Unfortunately, there is a legend that all of these hard science methods are applicable to the material world but not applicable to human—based systems because people are unpredictable.

If people are really unpredictable, we couldn't manage at all. Of course, people are predictable. If you go out into the street and find a person arbitrarily, and you spit in his ear, I think that there is a very high probability that this person would not kiss and hug you back. In this sense, people are predictable.

In the middle 1980s there was CIM (computer integrated manufacturing). Because it was all too often applied as a point solution, it created problems before and after the "solution." Do you find that TOC also creates before-and-after constraints in many cases?

Let me give an example. You have a chain. In the chain you have the weakest link. That's the one that dictates the strength of the whole chain. If you strengthen that link, the whole chain becomes stronger, but not to infinity. Now the strength will be dependent on another weak link. So the constraint has moved, but the performance has jumped. It's not that by strengthening the link, you've created a problem somewhere else, but by strengthening the weakest link, you've strengthened the whole chain up to the point where another link is now limiting further growth.

You identify other weaker links in the chain by finding and correcting the weakest, and then finding the subsequent weaker.

Correct. Then success will be limited by the subsequent constraint which, by the way, is not very close to the first one. You get a significant jump in performance, but not to infinity. CIM tried to balance the plant by automation. I was so much against it in 1985, it's unbelievable. So much money went down the drain because of it. Try to imagine that we build a system where everybody is on the same level. Everybody is happy to the same extent. Everything would crack on the spot, and that's exactly what they've tried to do there.

How do today's efforts at demand flow fit in with theory of constraints?

That's exactly what the TOC is trying to do. Work flow concepts were invented by Henry Ford. He's the one who should take the full credit for it. The assembly line is a work flow. He didn't try to balance the line, he created buffers in the right places, he created correct imbalancing capacity to enable everything to work. He knew exactly what he was doing. Unfortunately, he didn't succeed in translating it for others.

If you are trying to do work flow by technology, you must make sure that the bottleneck is built in and everybody else has appropriate excess capacity — in other words protective capacity — and that the balance of inventory is built in correctly. If you are ignoring all of that, ignoring the basic principle of dependent events coupled with statistical fluctuations, of course it's going to collapse. At the same time, we have to understand that so many functions are not machine-oriented. When we are talking about flow through the entire company, we have to bear in mind that many of the things cannot be mechanized. For example, programming work, which is part of development, or the sale process. However, it doesn't mean that the concepts cannot be applied correctly.

If you want it in a nutshell, you can say that the Theory of Constraints is how to make sure that the bottom line will be improved. And in organizations, the way to do it is how do you make sure that the flow of sellable goods will be maximized without adding protective capacity.

Do you mean excess over the required excess?

I don't call it excess. I call it "protective." Excess is something that will not give me any benefit. Something that if I trim, I do not jeopardize the result. If it is something that the minute I trim it, I'm killing the result, it was not excess to start with. That's the real judgment of whether it's excess, not if from time to time it's standing idle.

The theory flies in the face of MRP and the JIT approach.

It is just-in-time. My problem with JIT is that it does not understand where to concentrate the protection, so it spreads the protection everywhere. Because of that, you need to have a much higher inventory and capacity. There are many published cases where companies that have been on JIT and moved to "drum, rope and buffer" management — which is the same idea but on a higher level — and got an understanding of where the protection should be concentrated, the results have more than doubled relative to JIT.

The concept of JIT is a major step forward.

When JIT was moving into U.S. manufacturing, there was no understanding of how it should be done. The problem I saw in the early days of JIT was pushing the buffer onto your supplier.

It was so idiotic. By the way, this was not done in Japan. In Japan, they understood very well that if you want to implement JIT, you have to chase out the measurements related to cost accounting from the shop floor on the spot, otherwise it doesn't work. Not even a word was said about it in the United States. How can you measure a worker by efficiency when the kanban system itself is telling him, "You don't have a kanban out, stay idle." How can you live with both at the same time? So, please do what I'm telling you, but if you do what I'm telling you, I'll punish you for that. No wonder it didn't work so well in the United States (except for very few places where they did chase out the measurements and change them).

Which brings us to the problem of the metrics, the cost accounting being one of the greatest. But isn't the GAAP (Generally Accepted Accounting Practices) required by government?

Up to a point. All that is mandated by the government is to use it as a value in the inventory in your balance sheet. Everything else is self-imposed by the companies. If the government is imposing 1 percent and we are imposing 99 percent, we shouldn't blame the government for that.

Almost coincidental with the release of The Goal in 1984 was a change in accounting structure called activity based costing (ABC). Do you find ABC fits in with the Theory of Constraints?

It doesn't. Activity-based costing is taking the concept of local optima to another level. In my eyes, it's devastating. Moreover, the people who really understand ABC are not admitting that product costs cannot possibly be calculated by ABC. There is no way to do it. Moreover, in ABC there is no way to allocate all costs on the item level. Some costs can be allocated at the item level, some only at the batch level, some only at the product level, some only at the product group level, and some not even there. So there is no way to calculate product cost from it. Nevertheless, in the market, ABC is sold as if it is a more accurate way to calculate product costing.

We seem to be in a state of merger mania, worldwide. How does TOC propagate across multiple business cultures?

Most of the difference in cultures come out in how you present things. For example, the French negotiate much differently than the Germans. Both are very different than the English. But, if you peer below this thin layer, there is an international communication language, which is called common sense. The Goal is "common sense." It's entirely cross-national. Why? Because common sense is the same thing everywhere. If you want to bridge between cultures, you have to reach the level where things become so clear and the causalities are so evident in your argument, that everybody agrees. When you are talking about mergers between international companies, the common experience is not there. And definitely, not common comradeship. You must rely on what makes sense — common sense.

When you are teaming across multi-national companies, this is much more difficult.

If you are doing it conventionally, without a doubt. If you are approaching it in the same way that I showed in The Goal — first of all, let's agree on the problem, not by vote but by finding out what the cause of everything is through cause and effect relationships. If you approach it this way, then you find out that there is no difference if a person is from one culture or from a different culture. Otherwise, you are absolutely right. The problem of cultures makes things almost impossible.

There have been many changes in technology and concepts in manufacturing over the last 10 to 15 years. Are you making changes to TOC concepts to accommodate these changes? How are you adapting TOC to the 1990s and 2000s?

I don't think that I have to adapt it. Instead, I see the industry is adapting to the common sense that's written in The Goal. For example, in the last 10 years, look what happened to cost accounting. Today nobody defends it. They are looking for a better way to do it, but nobody defends it anymore. The measurement, the efficiency measurements today in most companies are condemned as stupid. They still do it, of course, but at least it's condemned. Reducing transfer batches in order to speed up the lead time is now accepted almost everywhere. Rapid response to the market is crucial. Not so much on cost per part, but the total cost of the operation where the emphasis should be on reducing drastically the response time to the market. This is now universal. It wasn't like that 10 years ago.

Companies are moving to what I was preaching in 1984. If you are talking about basic concepts, if you are talking about cause and effect, causalities are not changing. Sometimes one of the entries change, but I don't think that anything has changed except for one thing: Things have become even more traumatic in terms of competition. It's much more fierce. Fifteen years ago, who could imagine that the lifetime of a product in the market can be, in major industries, one-third of the development time. Look at electronics; the time to develop the product is three times more than the lifetime of the product. They have to have three generations in the pipeline, one after the other, which is creating havoc.

Have you thought about combining the TOC with chaos theory?

They have combined. At the time I didn't understand it. I was wondering how, when I was working on problems that had two bottlenecks, I got unstable situations regardless of the solutions. Even when I got the optimum solution, mathematically, it was totally unstable. I didn't understand why it existed. Now because of chaos theory, I understand perfectly.

When you have two bottlenecks in the line, you've created a chaos situation. If you look at the equations, you'll see it immediately. At that time I didn't have a theoretical background or the technology to talk about it in this way. How can you change the parameters of the equation so you move out of a chaos situation into a stable situation? When you are unstable in a chaos situation, every small disruption causes big, unpredictable effects. The only way out is to get out of the chaos, rather than trying to control it or stabilize the unstable. If you have two bottlenecks in a line, don't try to stabilize it, it's impossible. That's what chaos theory shows so vividly. You have to break one of the bottles. You have to add capacity; you have to get out of the unstable situation. You have to change the parameters.

As a student of the philosophy of Zen, there seems to be a lot of similarity to the TOC approach.

I felt the same way. The power is even stronger with Socrates. But I don't think that there is much difference. The Socratic approach is not just to ask questions. If you simply ask questions, especially a few that people don't know how to answer, what you get is a punch in the nose. The idea is how do you establish the background and then ask the question, that people's intuition is strong enough to leapfrog the gap. That's the Socratic approach. It's taking small bites. But that means you have to put in all your own work beforehand. You have to do a lot of homework.

We've seen the Theory of Constraints taking off anew. What about Eli Goldratt? What are you up to now that you have "retired" at the ripe old age of 51?

The problem that I see today is that so many managers in companies do not see the company as a whole. This is their department, their project, their silo, and they seem to draw a blank on how what they are doing impacts everything else. Due to that, not only is the communication between departments not the best in the world, much local optima is done which jeopardizes the performance of the whole organization. It turns out that it's not because people are stupid, but because the approach that we have taken in running the company, is in fostering local optima. In order to really change it, I decided that the way to do TOC is to expose enough people in the company, from all functions, at the same time, so that a common language will be generated, so that they can really understand it, look at it all from a different angle, and start to get much better and efficient at communication. To accomplish this, I'm going to launch a satellite-based program. A series of eight sessions, each one three hours long, given once a week. At the beginning I'm explaining the basics, then covering all of production, bringing it to the tactical level. Then to do the same for finance, for product development or engineering, distribution, marketing, and then sales. At then the last session, I'm putting everything together again. The idea is that these will be downlinked to the companies themselves. People are reading about it at different times, some departments don't read it at all, so only partial things are done. People have to be exposed to exactly the same type of logic, the same approach, because what you do in your department impacts on everyone else.

For example, to lower the setup time, if it's not on a bottleneck, has a huge bad impact on the inventories in distribution. But people are unaware of it all. I hope that if many managers in the company hear the process at the same time, and they have enough time to discuss it, this can change the culture of the company. We have to have a vehicle by which everyone will hear it at the same time from the company. I have done it already for small companies and it worked. I'm now trying to do it on a major scale.

To purchase any of Eli Goldratt's books visit the Lionheart Publishing Bookstore.




Web Site © Copyright 2020 by Lionheart Publishing, Inc.
All rights reserved.


Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: +44 23 8110 3411 |
E-mail:
Web: www.lionheartpub.com


Web Design by Premier Web Designs
E-mail: webmaster@lionhrtpub.com