Sep 2 2016
Why I don’t like Lean houses, except one | Christian Hohmann | LinkedIn Pulse
“I never liked the (Toyota inspired) Lean houses and their many variants. First all these models are generally understood as prescriptive rather than descriptive, thus those new to Lean tend to adopt and copy one model without necessarily understanding its real meaning. The building blocks of Lean houses are principles, methods and tools, reinforcing the feeling that it’s all about “techniques”.
The house building metaphor also suggests a beginning with sound foundations, robust pillars and when the roof is atop, the organization is done. We’ll see later it is not in this way. To add to the confusion, with the broad choice of variants, which is the right one to look at?”
Sourced through LinkedIn Pulse
Michel Baudin‘s comments:
I share your reservations about the many “Houses of Lean” floating around, but my main concern with them is vagueness. The descriptive versus prescriptive confusion that you bring up is one concern. In one diagram I am looking at right now, “Heijunka” sits on top of “Stability” and underneath “Pull System,” “Takt Time” and “Continuous Flow.” Whatever it is intended to mean, it can’t be that you should implement Heijunka as soon as your processes are stable. Given that there are very few companies outside of the Toyota supply chain that have even implemented Heijunka, it is clearly an advanced topic, not to be tackled until you have done many other things, including items listed above it.
The basic operation when drawing a house of Lean is stacking. It has a well-defined meaning in computer networks, where you talk about “protocol stacks.” For example, the worldwide web sits on top of the internet, and it means that, behind the web face it shows you, your browser uses the internet protocol to communicate with the world, in ways that would be unintelligible to you. The meaning is obviously different in a “House of Lean,” but what is it? And what does it mean to draw a manager inside?
I think of graphics as a language, to be used to communicate specifics that you can’t in other ways. Whether you use bubbles and arrows or stack boxes, the meaning of the objects and relationships should be clear, unambiguous, and explained. It means that, to be informative, the graphic must be drawn according to some explicit, formal rules, like “rounded boxes represent production operations and arrows flows of materials, which must be labeled.” Unless such rules are adhered to, the meaning of the graphic is ambiguous.
Sometimes, the authors want ambiguity. They want readers to see whatever they want to see. Ambiguity works in Marketing and Sales, but not in technical work. Most graphics about manufacturing are technical communication, not art. Art is communication too, but not of the same kind, and it’s not used to help design production lines, specify software requirements, or manage projects.
Having formal rules, like the Unified Modeling Language (UML) in software engineering is, of course, no guarantee that graphics will be informative or useful in any way. You may master grammar perfectly but have nothing to say. Too often, organizations that adopt a graphic standard only review graphics for compliance with the rules, as has happened in Lean with Value Stream Mapping (VSM), with teams pressured to produce similar looking and formally perfect VSMs to post on walls for visitors to see.
The only time I personally used a House of Lean is on p.2 of Working with Machines, to dramatize what happens when one of the two columns supporting a roof is missing, the two columns being JIT and Jidoka.
#HouseOfLean, #TPSHouse, #VSM, #UML
September 2, 2016 @ 1:38 pm
The worst is a variant of a “Lean House” that is about 400 bricks (tools) all jammed together in a way that doesn’t really make sense. I like the idea of the basic Toyota TPS house – the pillars of flow and jidoka, the foundation of fundamentals, supporting people. It gets off track when people overcomplicate it and turn TPS into a basket of tools, something it’s not.