I won't always be reviewing books this frequently but this one has been sitting around the house  for awhile and I thought this would be a good chance to get it read.

This isn't a new book.  It was published in 2006. But it's one of the widely read books and author Jamie Flinchbaugh has been making a name for himself.  He posts regularly at Evolving Excellence and I've always liked what he says there.  (Full Disclosure:  I don't know Jamie Flinchbaugh but he recently joined a LinkedIn discussion group I started.)

The book is very nicely structured.  Each chapter focuses on a topic and the authors explore five components or ideas related to that topic.  For example, Chapter One...Think First: Five Principles of Lean; Chapter Two...People Need Leadership, Not Management: Five Leadership Moves for Lean....and so on,  The other chapters explore lean pitfalls, lean transformation roadmap, lean operating systems, lean accounting, lean material management, lean service, and personal lean.  The "five points" format helps in understanding and retaining the authors' main ideas.

One doesn't need to read the chapters in order.  In fact, I'd recommend that you read Chapter Four (Transformation Roadmap) and Chapter Five (Operating Systems) first.  The material in the first two chapters will be familiar to anyone for whom this is not the first thing they've read on lean.  (If this is your first book on lean, I'd still recommend reading Chapters Four and Five then read Chapters One and Two.) The other chapters can be read in any order one likes.

The reader won't get a manual of instructions for implementing lean.  Nor will the reader get detailed (or any, for that matter) descriptions of lean tools.  If you don't know what 5S or quick change is all about before you start the book, you won't learn it here.  But that's not what the authors are going for.  The reader will get a solid grounding in relevant concepts and thinking, within which later reading on tools and methods will make more sense.  As to the concepts and ideas presented by the authors, they're on the mark, well presented, fairly well explained (although, see paragraph below).  As with most lean texts, there's a bit more emphasis on waste removal as an end in itself...but just a bit.  They duly emphasize the importance of flow, to my lights, the most important concept within lean. 

One might think a book carrying a subtitle "Lessons from the Road" would contain lots of....lessons from the road, i.e., stories about real organizations to illustrate the authors' points.  Well...not so much.  The authors do a lot of "talking about" their points but, quite often, I felt the need for an illustration or an example.  A few are forthcoming, but just a few. 

Is the book worth reading?  Yes, definitely.  You won't come away feeling that you know how to get a lean initiative started next week within your own organization, but you should come away feeling as though you have a good grasp on more than a few important lean concepts and principles.

      

Velocity is written by a trio of folks who work for the AGI-Goldratt Institute, which brought us The Theory of Constraints with that now-famous book, The Goal.  These folks have made the business novel a genre unto it's own.  Heck, I'm writing one myself.  Something about that novel format that makes for easy writing and (we authors hope) easy reading.

And this book is easy to read.  You could probably get it done on a long air trip, certainly over a weekend.  You can read it even more quickly if you take my advice to start at about page 150.  Here's what you will have missed:
Amy has been promoted to President of a firm that just got bought by a conglomerate.  Her boss is a jackass.  Her jackass boss inflicted an Lean Six Sigma guy on her. She also has an MRP system, again, inflicted on her from the start, that (somehow) senses when a work center is underutilized, then schedules product for that work center...on its own...with no human intervention....and it can't be turned off.  The two factories that Amy oversees have tons of problems that nobody seems to be able to fix, least of all the Lean Six Sigma guy.  There's also a separate R and D office that has to approve designs or formulations or something for the plants but doesn't do it in a timely way.

Oh, yes...there's also Amy's budding love interest and a formerly married couple of managers at the R and D office that get it on in the lab every so often.  If I recall correctly, there was a similar schtick in The Goal.  Somehow, business novel writers got it in their heads that, because it was a novel, it had to include some sex and drugs and rock and roll.  Here's a suggestion:  leave that to Danielle Steele because you're no good at it.

So, there you go...skip to page 150, where everything of interest regarding Theory of Constraints starts.

What starts to happen at page 150?  Well, things have gotten so damn bad that...Amy finally decides to get all the requisite parties together to do some...PLANNING!   Now there's an idea!  One kind of wonders why Amy (or anybody) didn't think of it when everything was just "every day" bad.  No kidding, at no point before halfway through the book does Amy get everybody together and say, "Let's figure this out and develop a plan that we can all agree to." 

And that's my primary problem with the book.  The descriptions of operational issues and problems are good (for the most part).  But I was continually nonplussed by the actions...and non-actions of the various protagonists.  In that regard, the story line didn't seem very realistic much of the time. 

First...Amy's promotion.  Amy has been a middle level marketing type, recently promoted to an upper level marketing type.  Suddenly, she's President of the subsidiary, a subsidiary that, everyone recognizes, has serious operating problems.  Yes, it could  happen, I guess. 

Then there's the Six Sigma Lean guy.  As I mentioned, he is sent to Amy by the top dog conglomerate jackass.  He's a gung ho kind of guy, all focused on getting rid of variation and waste.  So far so good.  He jumps right in with...line balancing?  And it's a line that the authors have made sure has a big, immutable constraint right in the middle of it, a heating/curing process step that takes anywhere between two and 23 hours, depending on the product specs.   Oh, the Lean Six Sigma guy also spends several months training everybody in the company in lean.  So, the lean six sigma implementation, as far as the reader can tell, consists of:

1. Sending everybody to class, and
2. Efforts on the part of the Lean Six Sigma guy, alone, to balance a line with a 23 hour process step in the middle of it.

I'm sure this is all of you lean practitioners would go about it, right? 

Then there's the IT.  It's a ERP/MRP sort of thing called WINGS that, as mentioned, has the ability to tell when an operation isn't fully utilized, then schedules product to that operation, ordering material if need be.  How does WINGS know when a work center is underutilized?  That's not explained.  What's also not explained is...why the hell would anyone ever, in their most hallucinatory states, EVER set up such a system?   And it got me thinking, "Maybe I'm the one who's naive.  Maybe such a monster really exists."  If someone knows of such a system, I'd love to hear about it. 

Finally, there's an important piece of the story that doesn't ring true, at least for this lean practitioner.  While there is a lot of superficial attendance to various measures throughout the book, it's apparent that there is no "dashboard  of metrics" used by anybody close to the project.  Amy gets blindsided by different folks coming to her with disparate metrics and we're to believe that she doesn't have a firm set of her own.  We're also to believe that this gung ho Lean Six Sigma guy is, for all practical purposes, averse to performance metrics other than those of the "micro" sort.  Like the ratio of kaizen blitzes to total head count.  (I know that's one that's near and dear to all you readers....right?)  We're also to believe that the jackass CEO of Everything, who is continually flying his lieutenants all over the world for golf and drinks at the finest resorts (no, I'm not kidding) is digging into machine utilization at Amy's plants.  The whole approach to measuring performance just didn't ring true for me.  Again, maybe I'm just naive and folks really do go about things this way.  But....kaizen blitzes as a percentage of total headcount?  C'mon.

On the other hand, the descriptions of other operational conditions and problems ring true.  The descriptions of what does and doesn't go on at R and D with respect to processes and culture are especially on the mark.  I get the impression one or more of the authors have a good bit of experience in this arena.  Bottom line is that, apart from the trysting in the labs, the R and D part of the story is well presented, as is (most of) what does and doesn't go on in the plants themselves.

The book's subtitle is: "Combining Lean, Six Sigma, and The Theory of Constraints to Achieve Breakthrough Performance".  A more honest subtitle would be: "Subordinating Lean and Six Sigma to The Theory of Constraints to Achieve Breakthrough Performance".  And I don't even have in mind that subordinating lean and six sigma to TOC is necessarily a bad thing.  It's just that you're not actually going to learn much about "combining" the three approaches.  You will however read a lot about how lean and six sigma is inferior to TOC.  Again, not that that would necessarily be a bad thing.  But don't lead us to believe you're going to tell us how to combine the methods, then tell us that "combining" means "Do TOC as your primary approach and then do a little lean and six sigma around the edges....just so long as they don't get in the way of the real work."

Is the book worth reading?  Yes...but just barely.  You'll learn something about TOC, if you didn't already know it.  You'll won't learn anything at all about lean or six sigma; it's presented in an inaccurate and mostly disparaging light.  (I'm sure the authors would disagree with this.  But it's a matter of damning by faint praise.  The Lean Six Sigma guy is presented as having all the right knowledge, training, and experience.  But he implements it in a way that a recent college grad would recognize as bogus. ) And you won't learn much about how to combine them.

But, if you do read it,  start at page 150.

      

Simply speaking, I haven't been very active on this blog so far this year.  Part of it is that I've developed other outlets that I get more response to...one of my problems here has always been that there are no comments.  Another problem is that readership apparently tanked after I inadvertently let my "blog rental" slip about this time last year and they canceled the blog.  I think lots of folks must have had it on RSS feed or something because I had readership up to 5000+ a month (somehow) and it went back to about 500 a month.  Try as I might, I couldn't get the readership back up much.  (Lately, in spite of very few posts, readership is above 1000 for July and August.  Go figure.)  Finally...I just kind of ran out of ideas.  I never wanted this blog to be one of those that simply link to other articles and opine on things.  That's useful but other blogs do that.

So, here's my new idea.  Don't know if it will increase readership or not but I think it will at least provide something of a public service:  book reviews.  Not just any book reviews, mind you, but reviews of books of interest to lean, Six Sigma and continuous improvement practitioners.  It'll get me reading some books that I haven't gotten around to reading and provide you with some info that might steer you to the good ones and away from the not so good ones.

I've never done book reviews so who know if I'll be any good at it.  I tend to like to talk about movies but sum books up with a quick, "Yeah, it's worth reading," or "Don't waste your time."    But I figure any info at all will help you make some decisions as to what to read and what to ignore, right?

      

"Pull" is a simple concept but it can be hard to get one's head around if you start by looking at your own complex operations.  So let's look at a simple example.  I can't put an illustration directly on this post, so I'm going to ask to you download a PPT file.   Simple Pull Illustration Diagram  So, download that, maybe print it out, and we'll go from there.  (I would have put it right onto this post but I don't think I can do it with this blogging software.)

You see you have a very simple process in which only one product is made that has two steps and four components.  A and B are assembled together in Step One.  That assembly moves along and components D and E are added.  Now it's a finished product.

Let's set up various scenarios with our illustration.  Suppose any or all of the following is true:

1. Any combination of Components A, B, C, and D are purchased in large quantities because of price discounts.
2. Steps 1 and 2 are far apart.
3. Large numbers of the A/B assembly (Step 1) are put together without regard to whether Step 2 needs them or not.
4. Scheduling of Step 2 is separate from the scheduling of Step 1.  In other words, Step 1 makes as much stuff as it can.  Then Step 2 makes as much stuff as it can.
5. The distances between where A, B, C, and D are stored and where Steps 1 and 2 are long.
6. A, B, C, and D are replenished in large quantities without regard to production levels. 

Traditional manufacturing allows any of these scenarios to take place.  In fact, traditional manufacturing and cost accounting actually support some of these tactics.  In pull systems, none of these scenarios are allowed to exist.  Instead, we work to set up the following conditions:

1. Steps 1 and 2 are moved close together in a cell.
2. Components A, B, C, and D are purchased and replenished in small amounts.
3. Step 1 makes only what Step 2 needs. 
4. Step 1 moves small batches to Step 2.
5. Step 2 is making only what the customer needs. 

You can see that this links Steps 1 and 2 very closely.  Perhaps too closely, especially if the two steps have very different cycle times or the components have very different lead times.  So, we might think of putting some inventory between the two steps.  We'll call this our "supermarket".  It will serve as a buffer between the two steps.

Let's say the company gets an order for 100 of whatever product that our simple line makes.  Step 2 takes, say, 10 sub-assemblies from the supermarket and starts to work on them.  Then, keeps taking ten at a time until the order is filled.  Step 1, seeing that there's a "hole" on the supermarket starts working to fill it.  Seeing the second "hole" of 10, then schedules to fill it and so on until the "hole" quits appearing. 

So, Step 2 "pulls" from the supermarket and Step 2 "pushes" to the supermarket.

You probably have a number of questions at this point:

• How much product should go into the supermarket?
• How did Step 2 decide to take ten sub-assemblies?  Why not 20? Or 2?
• What if an order for 300 of the product comes in?  Does it all work the same way?

There's no way of answering these questions without have a lot more information.  This is why developing pull systems is challenging.  More on all this in our next post.

      

When I...ahem...paused (if that's the word for a four-month gap) my blogging activities, we were talking about establishing pull systems.  I ended that post back in...January, was it?....by saying that you shouldn't even think of implementing pull systems until you have 5S, preventive maintenance, work standards, and quick change well in hand.

So, let's say you've done this.  What next?

You're value stream map should tell you what to do next.  Essentially, you're looking for the following opportunities:

1. Putting related operations together in cells...or, at least, closer together;
2. Moving quantities in smaller batches between steps in the process,
3. Keeping inventories of parts and components at the point of use,
4. Establishing formal "supermarkets" of parts and components between steps in the process to control flow and work in process
5. Replenishing parts, components, and raw materials more often rather than less
6. Reducing lead times, process times, and delays.

In our next post, we'll go into a bit more detail, using some simple illustrations.

      

I'm going to be writing a regular column in a trade magazine, Fabricating and Metalworking.  My first installment came out in the May issue.  It'll be similar to my blog, emphasizing "how to" rather than theory.  Check it out!

      

As I mentioned early last month, I spoke at the Industry Week Best Plants Conference here in Cleveland.  It was a nicely done conference overall.  IW does a bang-up job putting on a conference, IMHO.

My co-speaker, Pete Accorti, President of Talan Products, and I got free registration to the entire conference proceedings.  That' unusual in the world of "speaking for free at conferences" and I very much appreciated the consideration.  (I once spoke at a one-day conference put on by IEEE down in Atlanta that wouldn't even feed me lunch!) 

I didn't go on any of the plant tours on Monday but did attend a variety of session on Tuesday and after our own presentation on Wednesday.

As you might imagine, reports on lean implementations were the order of the day.  I'll tell you the truth, I don't remember many particulars from the sessions I attended (although a presentation on 5S by my old friend Fletcher Birmingham and a client of his was especially informative) but I do have some general impressions.

Powerpoint has been around since the late '80's, according to Wiki.  I remember a boss of mine using it in the early '90's.  So, the software is 20 years old...and almost nobody knows how to use it.  I saw presentations by folks from big companies that, I'm sure, were put together by folks who ought to know better (as contrasted to, say, some poor lean champion putting a few slides together late at night) that were, in a word, terrible.  Rather, it wasn't the presentation that was terrible so much as it was poor Powerpoint development and use.

You can probably brainstorm the litany of Powerpoint abuses yourself:

• Too many slides,
• Slides that don't really say anything or move the "plot" along (Hint to presenters:  You only need ONE slide to tell about your company unless what you make or do is so esoteric that you need ONE MORE to explain it.)
• Slides that just plain can't be read, even by folks in the front row,
• Reading from slides (as if I couldn't read the darn thing myself),
• Slides with information that the speaker doesn't address,

And, of course, the big enchilada of all PowerPoint boo-boos:

TOO MUCH STUFF ON ONE SLIDE!!!!

Lest I be accused of bashing others without making myself available for similar bashing, I've attached the slide for our presentation to this post.  (You'll see that a couple of them get close to being guilty of the same things I complain about above...but just a couple.)  Anyway, maybe you'd just like to see our presentation.  Here it is:

IW Conference Presentation on Talan Products

OK, I got a bit off topic with that PowerPoint rant.  (But, lest you think I'm alone in my ire, check this article out.  Even the military is starting to recognize the shortcomings of  "death by PowerPoint".)

There was another theme I got from the conference:  Lean implementation in big companies is very different from implementations in small companies.  I'm going to address that in my next post.  And, I promise, it won't appear two months from now!

      

Well...maybe. 

I'm going to be a speaker at next month's Industry Week Best Plants Conference here in Cleveland.m  (Scroll down until you see Developing Effective Measures for the Lean Enterprise....that's me!)

If you're going to be there, I sure hope you'll come here Pete and me lay the good word down.

      

If you're a LinkedIn "member" join my group, Strategy, Strategic Thinking, Strategic Planning.  Get on your LinkedIn home page, look for the search window.  Do the drop down arrow and click "groups".  Do a search using the whole name of the group or you'll end up with pages and pages of hits and who knows where mine will be.  I'll be looking for you!

      

I would have sworn it was no more than three or four weeks since my last post.  Time goes fast.

As to why the long gap, I wrote a couple of articles for trade magazines about my client, Talan Products.  (Here's the article in MetalForming, and here's the other in Fabricating and Metalworking.  By the way, I'll be writing a regular column on lean manufacturing for F and M that starts in May so keep going to the site to check those out.)  I've also been preparing a presentation for Industry Week's Best Plants Conference here in Cleveland, again about Talan Products and the manner by which it chose and uses lean metrics.  I'll also be making a presentation down in Columbus at the ASQ regional meeting there next month.  In the midst of all that, I made a presentation to the Case Western Operations Management Club and have been active on the AME group over on LinkedIn.

So, even though I haven't been posting here enough, I've been working to get the word out.