Eric's Reviews > The Goal: A Process of Ongoing Improvement

The Goal by Eliyahu M. Goldratt
Rate this book
Clear rating

by
558206
's review
Aug 07, 11


I think I basically resisted this book for its smell, that is a combination of my prejudices about the patronising business parable genre (consider managers gifting their laid off employees with "Who moved my Cheese?" and also in short, the cover, the scent of "I made millions with my easy technique and if you buy my 5 CD box set, I will show you how!". This is partly reflected in overblown language, for example, the "Theory" of Constraints.

Well. I guess despite myself, I did enjoy the book. I was irritated at first when the Wise Man archetype was a physicist (I started fuming about "insta-cachet" on Twitter until one of my friends pointed out that the author was a bona fide physicist... oops!). As a novel, it's pretty terrible, but I'm not really reading it for the fiction. And really the hint of "TOC will save your marriage", no.. let's not do that. "What's the goal of marriage?" Well OK maybe that is a right question to ask and maybe if you go to a successful couple's therapist you do actually effectively get a variant of that question thrown into your face (speculating wildly here!). Finally towards the end, the "Socratic" plant-manager-thinks-with-his-trusted-underlings style got to be really wearying. You just want to say, "OK OK shut up already and just give me a stupid diagram. Nevertheless, the experience was worthwhile. I think. I may have to read it again after a few months to see if digestion helps. I have a tendency to steamroll through books without actually reading them properly.

For the techie audience, the thing to know about the Goal is that it's not managing or motivating people, as you might expect from a cheese-displacement novel. We're not trying to turn re-habit folks into being Highly Effective, not trying to crank out any more "Je suis un winner!" types. So relax. It may be still be bullshit (which is not say that Covey et al produce bullshit, how should I know?), but at least it's not that sort of bullshit. To give you an idea what this is about, I'm starting to wonder if you can make links between the thinking used in this book with the kind of thinking that some CS researchers may use in studying the efficiency of parallelised or concurrent computation. You have a system which can be characterised as a weighted dependency graph (say each arc tells you how much stuff flows out of a node); how do you optimise the weight of things going from input to output? (I may not have this right, but you get what I'm trying to depict, right? Not-that-fluffy)

The book does deliver the pleasure of the occasional counter-intuitive common-sense-in-hindsight result. One part of the book has the protagonist deliberately reducing the efficiency (or maybe just rate) of one the components in the system so that its output doesn't overwhelm or bog down the rest of the system. Makes sense now, but would you have thought to do it if you were the plant manager?

Some things I've taken away from it in my first likely superficial pass:

careful goal identification - in the case of the manufacturing plant, the goal is not to manufacture widgets, but to make money! Now this nearly tripped my initial hippie filter, but it makes sense if you think strictly in terms of the entity itself and not the wider system ie. world. It sounds wrong (because there's more to life than..., and what about the Planet?), but it's definitely way less wrong to say that the Goal of a manufacturing plant is to make money than to crank widgets, reduce costs, improve quality, etc - for all those things are subordinate to that one goal. So it's not so much about narrowing down your vision but sweeping away what area actually merely subordinate goals to some higher goal

reframing the money-making goal as increasing throughput (rate sys generates money through sales - not prod!) whilst reducing inventory (money spent on stuff you intend to sell (but have not yet sold) and reducing operational expense (money spent on converting inventory to throughput

dependency-capped statistical fluctuation - sometimes you're faster, sometimes you're slower; statistical fluctuation. Sometimes your friend is faster, sometimes he's slower. Statistical fluctuation. Now what if your friend depends on what you're doing? His capacity to be faster is capped by your speed. He can still go slower than normal, but how much faster he can go is limited by how fast you're going. Now imagine if somebody was depending on him. This is a really neat idea! Imagine a whole chain of dependencies, a whole link of nodes with their own internal statistical fluctuation. Because the fluctuation is dependency-capped, the further down the chain you get, the less able you are to benefit from the upticks in that fluctuation. It's penalties all the way down. This was the huh moment that made the book worthwhile for me

bottleneck/constraint management - sort of the upshot of dependency capped fluctuation. If your whole dependency graph is a big pile of dependency-capped statistical fluctuation, what do you do? Well you start to pay attention to where the critical points are, chain only as strong as its weakest link. The word bottleneck connotes a sort of fault/inferiority, something to be excised, as does the notion of "weakest" link, but that's really besides the point. Any complex process inherently has constraints/bottlenecks. To respond to this, you either have to somehow widen the bottleneck, or as I like to put it "honour" the bottleneck by making sure you're using it the best way possible. For example, do QA before input to bottleneck and not output because then you can fail/reject early and save precious bottleneck time on doing meaningful work.

throughput rather than cost based accounting cost efficiency not necessarily the right way to look at manufacturing. (OK I'm a bit fuzzier here), note for future reading

There's more to this, but I confess the book got to be a bit of a blur towards the end. In any case, I have a sense that even if I did understand the principles better... applying them ain't going to be easy. But I suppose just having these principles as a starting point is a good thing.
flag

Sign into Goodreads to see if any of your friends have read The Goal.
Sign In »

Comments (showing 1-2 of 2) (2 new)

dateDown arrow    newest »

message 1: by Ash (new) - rated it 5 stars

Ash Moran Some other thoughts that might help:

Goldratt went on to spend a lot of time developing the Strategy and Tactics tree to create Viable Visions for different business sectors. This involves simultaneously creating exponential growth and (ie on top of) linear stability. You could question the ecological impact of the exponential growth! Also, in none-profit-making sectors, goal units have to be defined in other terms, eg nights of homeless people housed, and money becomes "merely" a necessary condition".

A lot has been written on Throughput Accounting in its own right. In fact, if you dig into systems thinking in business, cost accounting is one of the main policy constraints. Dettmer's book The Logical Thinking Process has an example of how cost accounting sends a company on a death spiral to self-destruction. (It's only incidental in the book though.) From memory, the TOC business novels I've read, don't go too much into the details of how to set financial metrics. May be just me being hazy though.

You didn't mention the POOGI, or process of ongoing improvement, which I suspect is because it's highlighted at the end. (Someone else I know who read it recently found the periodic table example enlightening.) I think this makes more sense after reading It's Not Luck, but you can definitely see it happening in The Goal, at the points where the team realise the constraint has moved. If you re-read it in future, I think (based on your review) this is an angle worth focusing on.


message 2: by Eric (new) - added it

Eric Thanks, Ash :-)

Indeed I did take some notice of POOGI but I think it sort of fell out of my head by the time I threw my review together. I did recall seeing the periodic table example but it didn't really trigger a particular ah-ha (although I do think I appreciate that the organisational insight of the table was quite profound, I just didn't really understand how to apply the lesson of the Table)


back to top