The False God of the Almighty Algorithm

There are two large lean-oriented Yahoo Group message boards, Bill Kluck's NWLean and Shahrukh Irani's JSLean.  NWLean was originally started in 1998 as a networking forum between lean professionals in the northwestern U.S., but has since evolved into a very active global discussion group with over 5,000 members.  NWLean teaches me something just about every day; in fact even in "daily digest" mode it is difficult to keep up with the large number of posts on pretty much every conceivable lean topic, with insight provided by practitioners worldwide. 

JSLean focuses on "job shop lean" and high-mix low-volume manufacturing and has around 1,000 members.  Although it was started with the noble intent of discussing a niche application of lean... it has become the forum for an epic battle of sorts between people who understand the simple power and magic (apologies to Mr. Bodek!) of "real lean" and those that don't quite get it and believe there's a software solution for every production problem.  In fact, it seems like they sometimes conjur up problems just so they can satisfy an addiction to algorithms.  Perhaps there's a 12-step program for that addiction.  But first they'd have to admit they were addicted, and that would conflict with some rather massive egos. 

Unfortunately this leads to the public thrashing of anyone who dares contradict their viewpoint that "lean and TPS are just a rehash of common sense", "there is nothing more to learn from Toyota", "lean is just a smorgasborg of tools". and "any jobshop must use computerized optimization to realize its full potential."  And that thrashing has led to the departure, sometimes in a very public manner, of many subscribers... some of whom I have developed tremendous respect for.  That fundamental lack of understanding of real lean is why many companies, especially those near Detroit, simply don't get why they aren't competitive.

Last week there was an interesting coincidental confluence of thought between JSLean and NWLean.  On JSLean Dr. Irani posted a question:

"These are two radically opposite worlds ... one is the tech-savvy and IT-powered optimization world and the other is the pencil-and-paper problem-solving world.  Which world should we live in?"

And on NWLean Mr. Kluck asked a different, but somewhat related question:

"What do we know about SAP, and how well it integrates with lean principles (or lean implementations)."

Interestingly enough, the post on JSLean resulted in zero responses.  Probably because the subscribers that actually post anything all worship at the altar of the almighty algorithm, and everyone else doesn't want to bother with the thrashing they'd take for posting an alternative opinion.

The NWLean post generated dozens of responses, most of which were IT horror stories.  Shop floor process changes to accomodate the ideosyncracies of SAP (and this doesn't just apply to SAP... several other ERP / MRP packages were also discussed), wasteful processes being proceduralized in algorithmic stone, monstrous amounts of extra inventory generated to accomodate the cascading "schedule risk" of individual operations, and of course implementation costs that can exceed $100 million buckaroos.  And interestingly enough, several people chimed in with how they have gone back to using simple visual controls and Excel spreadsheets to schedule complex operations.

Visual controls and Excel spreadsheets to run a factory?  That was just too much to take for some of the members of JSLean's Future Algorithmics Anonymous who lurk on the fringes of NWLean, so there were a couple of posts spouting their usual blather on "finite multi-variant thingamabob constructionist simulatory somethingoranother".  Maybe I'll have a venti double shot no whip non-fat mocha with that.  Or not.  I'm a simple man who enjoys a simple cup of joe.

But think about it.  About the most complex type of factory is one that makes almost a thousand cars with several hundred permutations every day.  And Toyota does it with no MRP-type shopfloor control.  MRP is used to handle financials, inventory costing, and the like... but shop floor control is pure manual pull with a small number of e-kanban type applications.  Most "real lean" companies unplug MRP on their shopfloors.  Last December our own Bill Waddell blogged on how MRP flies in the face of lean, and his book, Rebirth of American Industry, has an entire chapter devoted to "The Illusion of MRP."

"Excellence through simplicity."  To me that quote from Lao Tzu has always epitomized one of the fundamental tenets of real lean.  Don't proceduralize complexity, and don't make something more complex than it needs to be.  Manufacturing really isn't all that hard... you make something, preferably one of it, and you get it out of the operation as quick as possible.  Once you remove the loads of WIP from the floor by focusing on the velocity of the single unit, you begin to realize how so much of that perceived complexity is due to not having an unwavering desire to get a product through the flow as quickly as possible.

Almost invariably when I first go into a factory, whether it is a large assembly operation or a small machine shop with a couple CNC's, I see a huge amount of transactional waste feeding "the machine."  Tracking workorders and jobs in all sorts of stages of completion (but never quite done...), inventory, and massive amounts of paperwork.  And consequently no time to work on quality improvement, waste reduction, process flow improvement and root cause analysis.  They have been sucked into the APICS-driven illusion of MRP.  They desperately need a trip to Algorithmics Anonymous.

It's all about flow.  Simple flow.  Put a magnetic white board at the center of the shop floor, draw the process in a flowchart manner, and stick the jobs (preferably in the smallest possible units) on magnets onto the processes.  Voila!  Just by looking at the white board you can see constraints, extra WIP, make decisions on the fly as to which jobs to process next.  Shop floor operators can take control and self-manage the operation, self-leveling the individual processes.  Eventually natural process improvements will become visually evident, creating cells and other "focused factories".  I've seen some very complex jobshops that have a "FIFO pipeline" on their whiteboards feeding into the first process or group of processes on the visual tracking whiteboard. 

One example I've seen even had hash marks on the whiteboard FIFO pipeline indicating the approximate number of hours (or days or weeks if you're really slow...) to show roughly the lead time before a job hit the first process.  Jobs in the pipeline were created in a cascading pull or kanban response to actual orders.  And another even had a webcam aimed at the whiteboard, viewable over their internal network, so that their customer service folks could tell customers exactly where their jobs were at any time and how long it would take to fill a new order.  No computerized shop floor control at all... in a very complex $75 million operation making leading-edge precision technology products.  Their old MRP was relegated to ensuring raw material was available at the beginning of the process, and reconciling the financials after the product shipped.

So the next time some algorithm addict tries to sell you the ultimate in computerized shop floor control for $100,000 remind yourself that you could buy a thousand whiteboards instead.

Comments

[John C.]

THAT POST ROCKS BABY!! So very true. We get so sucked into technology that we can't see how simple the process really is. I bailed out of JSLEAN about six months ago when my email box was being filled with useless shouting between a few narrow-minded idiots.

By the way my 100 person operation does use Excel, and we are kicking our competitors' asses on leadtime. I will still improve it by using your whiteboard idea though!

You and Bill kick ass with this blog. I like the occassional well thought out and insightful posts instead of the several short fluffy posts each day that other blogs have. Keep up the great work!

JC

[CNomenthal]

You heathen! You will be assimilated by the god of the algorithm!

:)

[Dave Marson]

We use a similar white board for our operation and it works great with the biggest benefit being the ownership by the operators. Our supervisors now spend their time working on improvements while the operators visually schedule themselves and automatically move to processes where WIP is building up. Self leveling as you call it. Primary focus on part velocity. We used to use Visual JobShop with a finite capacity scheduling add-on but we couldn't see how simple our operation really was and we spent tons of time just resolving computer issues. Keep it simple stupid.

[Markus]

Hey Kevin I thought Bill was supposed to be the inspiring passionate angry old man and you were the inspiring upbeat shop floor grunt but now I'm confused! But still inspired.

Markus
- also ex-JSLean and definitely from the paper and pencil problem-solving world.

[Bill Waddell]

What a great post, Kevin. Those who see themselves living in a "tech-savvy and IT-powered optimization world" are like those whose only tool is a hammer and, as a result, can only see manufacturing problems as nails. They look at lean and, first, try to force fit MRP into it, then having failed, decry lean as an ineffective manufacturing theory.

Without knowing when to apply technology and when to use a #2 pencil, they end up being the least 'tech savvy' people of all. And the manufacturers they are obligated to support pay the price.

[Graham]

Bill i'd have to ask what are your assumptions when you dismiss the IT world almost out of hand?
Is it because you feel it is inaccessible compared to pen and paper? More inflexible?
If IBM can build a machine to beat our chess grand masters can't we build a machine to do the same for lean?
Perhaps someone has written a Standard Work Instruction for lean and is creating their tool around it...

[JT]

This sure hit the nail on head.

Hours are poured down the drain of labor collection, tweaking the material and labor standards.

Understanding the impact of velocity through the operation from concept of the product to fulfillment is lost in the minutia of MRP, Microsoft Project and complex scheduling schemes. All of these wonderful software tools lead to analysis paralyses.

Hours will be spent trying to figure out why this build had more or less margin than the last build.
Hours spent on juggling the schedule to save a day here or better still move it to next month because we have hit our dollar goal for the month.

You gotta love it baby

[Bill Waddell]

I hardly dismiss the IT world out of hand. I don't know your credentials Graham, but I am APICS certified and ran a pretty succesful software business peddling some pretty sophisticated network optimization stuff a few years back. I led projects to integrate large-scale, fully-automated manufacturing operations to real time MRP systems. I got nothin' against IT.

IT can be a very, very powerful tool. It can also be the wong tool for the job. Kevin and I have consistently criticized those who seem to believe that everything done in a factory can be better done on a computer, and those who cannot accept the reality that MRP is built upon the wrong assumptions for manufacturing optimization.

[Al Smutherson]

Wow now that made me think and made me sick to my stomach again. I've got a crew of people that do nothing except "feed the machine" as you put it. Hot lists and the hot-hot list. Expeditors to support the ultra hot. All because we put a supposed "lean-enabled shop floor solution" in place over a year ago. What a joke. I cry when I think of the lost hours for training and reconciling.

Some words of advice:

- no matter how much the software used car salesmen tries to convince you that their product will conform to your processes, don't believe him. you will end up changing your processes.
- making new process improvements becomes almost impossible as it is such a pain in the ass to change the software and routings
- you will need to hire one extra person for every $20k the software cost (I've heard this from several people) just to handle issues and exceptions
- all the modeling and algorithms in the world can't account for production realities such as lost shipments or marginal raw material quality from a sole source. but a whiteboard method can be very flexible and allow for immediate decisions.
- take the time to understand how simple your processes really are first, then you'll probably wonder why you need such a complex solution.

Never again. If someone even mentions shop floor control software, run away fast!

Al "MAPICS gave me gray hair" S.
Sipping some joe from McDonalds

[Graham]

I get where you're coming from Bill, but that's why i was asking about assumptions. You are against the "IT-Optimised" world as it's put because you see MRP as being a square peg for a round hole (apologies if i mischaracterise your ideas), i'm asking, what if you found the IT solution that's the round peg?

As for my credentials they are lowly and effectively irrelevant, consider me the man-in-the-street.

[Joe Ely]

Kevin, great post. I bailed out of JSLEAN several years ago when I saw what it was. NWLEAN on the other hand always teaches me something.

I love the idea of a webcam of the white board...that solves the apparent dilemma of "hand written" and "broadly dispersed" data.

I'll find a place to use it...thanks!

[Bill Waddell]

Hello Graham,

I would not only be open to an IT soluation for manufacturing that embraces lean, I would be eager to embrace it. The problem is that every solution out there seems to have started with MRP, then adapted from there to accommodate lean. There is no avoiding the fact that putting perfume on the MRP pig does not change the fact that it is still a pig.

The IT world is as guilty as much of the lean manufacturing community in mistakenly seeing lean as the same old business model, only with kanbans and other Toyota shop floor tricks. In fact, it is an entirely different economic model of manufacturing that MRP cannot possibly support.

Manufacturing desperately needs an IT solution that begins with a clean sheet of paper, then builds an integrated system on lean shop floor principles and lean accounting. Thus far, no IT provider has had the vision and willingness to make an investment in that system. Instead, they keep trying to get there through modifications to MRP.

Until the day comes that a truly lean manufacturing system exists, I believe manufacturing is much better served with white boards and manual methods on the shop floor.

[Joe S.]

First visit. Great post and discussions.

[Graham]

Thanks for the clarification Bill and agreed.
p.s. if anyone wants to direct me towards a gold example of manufacturing services i'd be happy (ie repair of warranty products etc)

[Mary Green]

I read this on Saturday night, and by Sunday I was still daydreaming about it during the Easter church service. I bought a large whiteboard on the way into work today. This will help solve a lot of the problems in my operation and it costs about 1/1000 of the solution I was thinking of. Thanks for saving me a ton of money and helping me take a step back to see the simple reality of my production process. I am so excited to go to work this morning!

[Ahmad]

Just this morning on JSLean Dr. Irani was offensive to Norman Bodek, asking him what was new in his new JIT Is Flow book to warrant any attention. This amazes me. It shows what an crass idiot Dr. Irani is or else how just plain ignorant he is. It also shows a lack of respect for one of the very top Lean people in the world. Norman Bodek has done incredible work, labored to translate very difficult books, and is inspiring by his humility. I have tremendous respect for him.

[Bill Waddell]

I am one of those who got fed up with the juvenile tone of JSLean, and Norm Bodek is a friend, my publisher and co-author. Yet I have to disagree with you.

We are too gentlemanly in the lean community to the point of failing to serve that community. We praise each other's books, often without even reading them. We compliment each other's articles and blogs, even though we often think they are asinine.

Challengiing each other respectfully would force us to have substance to our work. It can only make us better. Of course, Norm Bodek deserves the respect and gratitude of the lean community for his enormous contribution, but that does not mean that he is above questioning if someone in the lean community sees a lack of substance in his book. I know that I certainly do not expect to have all of my work complimented simply because some of it has been good in the past.

[Thomas]

Great Post Kevin, and excellent comments. I have some scars from JSLean, and have relegated conversation from that group to the 'if I have time...' file. I find many parallels between their stated goal of ‘finding the next step’ before they even understand the current step, and failed implementations in industry where companies have skipped over 5S because it is ‘too simple to make a difference’, then get nowhere with any other part of lean. It is fine to wish for the next breakthrough, but one is more likely to see it from the existing state of the art (TPS) than from the previous iteration (Sloan et al). Keep up the great work!

[Anil Menawat]

Bill, you said you would be open to an IT solution that starts with a blank sheet and is built on lean principle. Well, you should look at our solution at www.menawat.com. That is precisely what we have done in our profit mapping methodology. We, however, do not sell software but we use our own software to enhance lean with detailed analysis built on lean process and financial principles.

[Karen Wilhelm]

As a matter of survival, MRP sought a way to claim it had something to do with lean and job scheduling. It had to claim it could be stretched to encompass the "enterprise" in ERP. As an onlooker (yes, I even remember MAPICS), it seems almost delusional to expect to turn a push system inside out and support pull. A few newer applications seemed to have started with a clean sheet of paper to pull resources in response to orders. Maybe they are effective, maybe not. I don't think the debate is IT or not IT, but cobbled IT or appropriate IT. Toyota has IT, but designed to support its system.

[Bill Waddell]

You're right, as usual, Karen. I think you hit the nail on the head. The software people, and far too many manufacturing people, think that lean is not much more than traditional manufacturing with pull, rather than push.

An ERP system with Pull capability is not a lean manufacturing system.

[Shahrukh A. Irani]

It is one thing to outright discard computer-aided problem-solving and IT-assisted operations, and a completely different issue when one understands where "the mighty algorithm" fits. I welcome all of you who are engaging in bashing me offline to engage in open discussion on JobshopLean. If I am shown to be wrong on even one of the areas where I have promoted the use of computer-aided problem-solving, given the complexity of a "jobshop-like" environment, I will surely accept my error. The JobshopLean forum was established to concept and develop "best practices beyond the Toyota Production System". Toyota's flavor of Lean is very good, inspiring to an IE like me, but it sure comes up short in many respects when we blindly adopt its best practices in SME's engaged in high-mix low-volume variable demand manufacturing and service sectors.

[Phil Coy]

Bill, I agree that mrp logic with it's orientation to inventory is at fundamental cross-purposes to lean. There have been some interesting posts on JSLEAN about using MRP only for longer range planning with suppliers and using MRP without netting.

A completely from-scratch-designed-for-lean software solution can be found from Future State Solutions (www.futurestatesolutions.com). The demo outlines an approach to a truly lean business system without reliance on the traditional mrp engine.

The fact that we integrate with an ERP is only a recognition that customer service, financials, and HR are necessary IT applications these days. What we propose however is to replace mrp-based planning with a lean planning process.

[JSS]

While criticizing finite capacity scheduling tools, the author is strongly advocating white magnetic boards for job shop scheduling. I would like to add a few comments on this article.

Some manufacturing veterans with 30 or 40 years experience of shop floor planning may ridicule at white magnetic boards and Excel applications saying that they could easily manage the workload planning without fancy boards and Excel for decades. People who advocate white magnetic boards resent electronic white boards that are avaiable in job shop management packages. The vendors of these packages consider finite capacity scheduling tools as complicated and unnecessary. All these people want the world to use just what they know and what they are comfortable with, no more and no less.

I do not think IT solutions will be very effective in every practical situation, particularly where the system is chaotic due to a lot of uncertainty or the requitred input data is not easily available. It is not right to think that there is a software solution for every production problem. But it does not mean that they are totally useless in every situation. It is also wrong to think that software solutions have no place at all in job shop production management. Let us not go to extremes for the purpose of arguing.

Several factories had bitter experience with inefficient and inappropriate scheduling modules of MRP systems which are primarily good material planning systems. The persons responsible for procurement and implementation of an IT solution must not be simply carried away by the mesmerising talk of the sales people. They must get the solution thoroughly tested with their own data and see whether:

1) The output of the tool gives meaningful and reliable advice to the planners/schedulers.

2) The value of the output from the tool is worth the tool price and implementation effort.

3) Input data can be regularly supplied to the tool without big effort.

4) The tool can be easily used by the people on the shop floor on a regular basis with little training.

If anyone of the above criteria is not satisfied, then the tool must be rejected even if it is offered free. But, we must not shy away from an IT solution just because it is based on some advanced algorithm which we cannot comprehend by our common sense.

A positive attitude is to challenge IT solution vendors to prove the significant advantage of their solutions on the shop floor during free trial runs. If they fail to prove what they promise, reveal their bluff to the world in order to protect other shop floors from false promises of those vendors. Criticism without challenge is not right.

JSS

[Paul Akerman]

Have been helping industry in their transition from mrp to TPS since I learned TPS from my mentor Dennis Butt. Dennis is one of the pioneers in bringing TPS to the US. Back in the late 70's Dennis took over the Kawasaki plant in Lincoln NB and in a relatively short period of time his plant was found to be the most productive plant in the western world. He implemented TPS after studying with the Master himself and, obviously, had tremendous success.

The least cost method of manufacture is TPS and there is no ambiguity in that statement, and it is demonstrable. Therefore if you are doing the least cost method of manufacture, by definition, you are utilizing TPS.

There is no system of manufacture, known to mankind, that is any less costly than TPS. THE PROFF IS IN THE PUDDING.

[perspicacious]

Hi is it possible to turn this discussion from a lean v/s algorithim approach to a lean + algorithm approach.
For example replacing the white board with a digital white board
Both approaches add great value independently and there is considerable evidence for them
However rather than making the discussion 1-1=0 , can we make it 1+1 = 11