Tom Jackson
Portland, Oregon
26 October 2009
What is hoshin kanri?
It is, essentially, a way to create a new organizational structure.
What is organizational structure?
According to economists like the new Nobel Laureate, Oliver Williamson (see my previous post), organizational structure is a structure for processing information. This makes complete sense if we stop but a moment to consider that organizational structure is about who makes the decisions. And decisions, as we know, require information and a set of priorities. Voila! Information processing.
So what kind of organizational structure does hoshin kanri create?
Simple. It's a poka yoke for strategy.
Come again?
A poka yoke. A mistake proofing device.
To quote Shigeo Shingo, a poka yoke or mistake proofing device "builds the function of a checklist into the process." Shingo illustrated his concept as a system of nested Deming cycles. (Actually, Shingo used the more economical Plan Do Check cycle, but never mind.)
Here we see how it works. We start a Deming cycle or cycle of organizational learning. To ensure flawless execution, in the very act of DO-ing, we embed another learning cycle. We do this for two reasons:
1. To be certain that we are doing it the right way, i.e., according to standard work; and
2. Just in case the "right way" isn't good enough, because you never know....
We can add checklists to checklists ad nauseum, depending only upon how much risk we want to wring out of any given system. The structure is sometimes called a nested Deming cycle. It's a checklist within a checklist within a checklit....
In military craft we refer to this design strategy as redundancy.
Back to checklists. Think of checklists as a form of memory. This is very much like computer memory.
In the case of operations, the checklist is about not forgetting how to do a job right the first time. The checklist can be literal (as in an airline pilot's checklist) or physical (as in a rumble strip or the alarm that is triggered when you leave your keys in your car).
In the case of strategy, the checklist can be literal, but it is essentially a metaphor for a system of constant reminding and recalibrating. Through the process of catchball, we agree to return to the "checklists" or action plans that we built into our A3 team charters, when we first built our annual hoshin, our strategy, our policy for improvement. Moreover, we remind each other. And when things don't work out quite as we had originally strategized, we regroup, refocus, and on we go.
Once a month, once a quarter, once a week (and by extension, once or more every day in our standup meetings), we revisit our "checklist."
Are we in control or out of control.
It is easy enough to see how this might apply to daily work, but to strategy? Well, why not? And that is precisely what hoshin kanri does.
The example of pilot and co-pilot double-checkling the aircraft before pushback comes very close to capturing the spirit of hoshin. The pilot checks the plane and checks the co-pilot's checking of the plane. Likewise the co-pilot checks the plane and checks the pilot's checking. Top down; bottom up. This is the essential structure of every hoshin review meeting.
And the checklist?
The organizational "checklist" is the list of priorities, as expressed in the organization's mission and vision and in every A3 team charter drafted during the catchball process. (As every game theorist knows, strategy is one very big checklist.)
Hoshin kanri is about remembering what we all agreed was important and what to do together to promote the interests of the organization. And if we should forget, or if circumstances should invalidate our agreements, hoshin is about starting over (and over) again, remembering what went wrong, what went well. Hoshin is about honoring the very human endeavor of nothing ventured, nothing gained.
Trial by fire, the fire of intelligence.
2 comments:
Great Article Tom. Hoshin Kanri brings reflection and alignment to an organization's strategy and in that way it is the method to ensure we are going the right way and doing the right things.
I think this can be error proofing to a point (as you know, I avoid the phrase poka yoke). If you treat strategy as PDCA then at least theoretically you shouldn't get too far off course. This is the reason I always recommend your book, because of how seamlessly PDCA is integrated.
When I say theoretically, the problem comes is when the check on a strategy takes a long time to develop. You might choose a strategy that is a bet on conditions to change in the future. Just because they didn't change yet doesn't mean your strategy was wrong.
When that happens, people build in checks just to see if we did what we said we would do. This is OK. At least it checks if we're dropping the ball or not. But it isn't a check on whether our actions are having the intended effect. That's the important part of check. When people lose the check of outcomes, they lose the learning that PDCA really provides.
Jamie Flinchbaugh
www.jamieflinchbaugh.com
Post a Comment