Steve Spear: Managing work to see problems when and where they occur By Steven Spear, Author of 'The High-Velocity Edge' and 'Chasing the Rabbit' - Last updated: Wednesday, June 23, 2010 - Save & Share - Leave a comment

Managing work to see problems when and where they occur is a

necessary precondition–one too often overlooked–if an organization

is going to achieve bona fide continuous improvement in pursuit of

operational excellence.

Here’s why.

Absent an ability to design perfect systems for design, production,

and delivery on the first try, operational excellence depends on

continuous improvement and relentless innovation.  As important as it

is to have rigor in solving problems, the necessary pre condition is

managing work so problems—flaws in the current design of systems and

the current approaches to doing work–are seen when and where they

occur.

Deming, for example, was a passionate advocate of the ‘Shewhart

Cycle’ of Plan, Do, Check, Act–in effect bringing the scientific

method from the laboratory into the workplace.

However, for all the discipline he encouraged in solving problems,

Deming was exceptionally committed to clarifying when a problem was

actually occurring.

Doing nothing was preferable to ‘tweaking,’ –an irrigorous

application of change in response to normal variation, not bona fide

departures.  At least doing nothing left the process mean and

variance unchanged.  Tweaking makes both worse.  Hence, while most

famous for statistical process control, Deming had many other

examples to show how tweaking made things worse, not better.

Toyota too built a management system on the criticality of seeing

problems as precursors to solving them.  Pillars of the Toyota temple

are Just In Time, on the one side, and Jidoka, on the other.  As I

point out in The High Velocity Edge, Just In Time, widely credited to

Ohno, encompasses a number of approaches to integrating disparate

process-component pieces into a well-balanced, synchronized whole.

Mostly overlooked, in practice outside of Toyota, is jidoka, a

concept with roots back to Toyota founder, Sakichi Toyoda.  While

jidoka has acquired a whole host of screw ball interpretations–

automation with a human touch, for instance–the key concept is that

work stop the moment a problem develops both so the effects can be

contained and also so the problem can be investigated immediately.

Toyoda was inspired to develop this approach from seeing women

fruitlessly weave defective fabric, in his hometown, because they did

not know a thread had broken on the loom. The first jidoka was in

looms that would stop, indicating which strand needed to be

rethreaded.  The concept was generalized so that all types of work

call at problems.

As I mentioned above, jidoka is an unfortunately overlooked element

of effective process design.

When first researching Toyota and lean in the ’95-’96 time frame, I

found some 28 hundred articles when searching on the key words of

lean, pull, JIT, kaizen, etc.  When searching on jidoka,

autonomation, and the like?  Less than a handful.

In practice, there seems to be an equally unbalanced approach to

process design and the inclusion of ‘built in tests’ to indicate

where the process design is flawed.