In my first post on Hoshin Kanri I explained the details of making the list for the Hoshin. This now has to be combined with a PDCA (Plan, Do, Check, Act). The rigor of PDCA gives value and life to what would otherwise be a simple action list. Let me show you:
PDCA is one of the most important tools in lean (or in any kind of process). I have written a whole series on PDCA, starting with The Key to Lean – Plan, Do, Check, Act! Just to review it briefly, the sequence is as follows:
- Plan: Define scope, define target, analyze the situation, understand the problem, develop one or ideally more solutions, select the best one for implementation.
- Do: Implement, define the new standard, train your people in the new standard, ensure the standard is followed.
- Check: Did the implementation actually work? Is the problem fixed? A nice presentation is no proof of a solution!
- Act: If it did not work (good enough), why not? What do you need to do to achieve the targets?
While the Plan and Do parts are easy and commonly done all over the world, the Check and Act are much harder. I sometimes have the feeling that management is often not interested in the actual outcome and is satisfied with a nice presentation.
If PDCA is done well, it can develop into a continuing series of PDCA loops until the problem is solved. In this case, PDCA continues with the next problem.
Overlapping PDCA with the To-Do List to Get Hoshin Kanri
In my previous post we looked at the to-do list that will go into the Hoshin Kanri. On this list are the rows in that document. PDCA represents the columns. The initial to-do list would be the column corresponding to the Plan of PDCA.
The columns do not necessarily need to be labeled Plan, Do, Check, and Act. There may be also more than four columns (or less), as long as PDCA is represented. In fact, there is not a standard Hoshin Kanri that is used everywhere, no matter what you hear otherwise. As always in lean, the document has to fit YOUR needs, the solution has to fit YOUR problem. Just copying something from someone else may not help you much.
Below is a selection of possible columns for Hoshin Kanri. These may help as suggestions to see what you may need.
- Review of last Hoshin: This would be the Check and Act of PDCA. Based on your last Hoshin document, you check if the objectives were achieved, and if not, why. A Hoshin Kanri often has a continuation, and the items from last time are found again in a similar form in the next Hoshin document.
- Hoshin Items: List of the items that you want to achieve. This is the to-do list from the last post. Feel free to group it into overarching topics (Quality, Health, Cost …) with a small number of sub-points for each. You may also include a separate column for targets, although not all Hoshins do. They are not necessarily quantitative, but may be qualitative. Together with the Hoshin items, this is the Plan from PDCA.
- Implementation Plan: What are you going to do? What is your plan? You may also include a column for Schedule and/or for Responsible. This is the Do part of PDCA.
- Evaluation: Did it work? Is the problem solved? This column may also be on your next Hoshin; see the top bullet “Review of last Hoshin.”
Some Additional Items
- Title: Give the document a title, i.e. “Final Assembly Hoshin 2019” or “Personal Hoshin 2015” or similar.
- Date: For which period (which year?) is the Hoshin?
- Owner: Who is in charge of the Hoshin?
- Department: To which department does the Hoshin belong? This should be the department of the owner.
- Supervisor: Who will review the Hoshin with the owner and give feedback?
- Signature Supervisor: A space for the supervisor to sign. This is to show that the Hoshin is completed for this term (year). Please note this does not mean that all problems are solved, however.
- Vision: What are the company (or your) overarching goals or guidelines? What is the corporate philosophy? Ideally, the items on the Hoshin should reflect this vision.
How Many Hoshins?
The power of Hoshin Kanri lies in the focus on the key points. Hence, the number of Hoshin Kanri documents that you are responsive for at the same time should be kept at an absolute minimum, ideally one. You may have a second personal Hoshin besides your corporate one to also improve yourself outside the industry context. Yet, within the industry there should be a maximum of one Hoshin document per person at a time.
Management must resist the temptation to create different Hoshins for different projects or topics. Similarly, if you are unfortunate enough to have two supervisors who both can tell you what to do, try to avoid having two separate Hoshin documents. If you put everything on your Hoshin that anybody would like to have, then you end up with 40+ different key items, all of which are top priority. Does this sound familiar? If everything is top priority, then nothing is. If nothing is priority, nothing will get done. Again: Limit the number of priority topics that make it on your Hoshin.
What Period Should a Hoshin Cover?
Most Hoshin Kanri documents that I know cover one year. This is usually a good duration, since one year allows for quite a bit of improvement activity. This duration is also long enough to see the results and review the outcome.
Again, resist the temptation to do Hoshins more frequently. You won’t get twice as much done if you have two Hoshins per year; you merely increase the organizational overhead, and hence reduce the actual improvement capacity.
Who Should Have a Hoshin?
In general, the person having a Hoshin Kanri should be able to influence an area under his control, making not only short-term decisions but also longer-term strategic decisions or changes.
Now you know how a Hoshin Kanri is structured. I also created a blank PowerPoint Hoshin Kanri Template for you to use. Hopefully it helps you. You can edit the PowerPoint to match the document to your needs.
I hope this article was helpful for you. In my next post I will explain how different Hoshin Kanri documents influence each other across the hierarchy. Until then, go out and organize your industry!
P.S.: Many thanks to Isao Yoshino for his input!