Daily Kaizen

This is the second of a two part blog. Part one was published 5/23

Loop 1 – Plan vs. Actual:

As we know from A3 thinking, a problem is defined as a gap between a target (plan) and an actual. We can not move on to understanding root cause, identifying countermeasures or taking action, until we make this gap clearly visible. Given this, the first loop that must be fully connected is plan vs. actual, and should look something like:

• Thursday – Production Planning -  “Actuals” from the previous week are collected and synthesized with all other identified data that allows the team to improve the thinking of their forecast for the next x time frame (often between 1 – 3 months out).
• Friday – The forecast for the month is translated into a forecast for the next week on the team’s Kaizen board.
• Following week – the daily forecast becomes the basis for the plan that is loaded to the team Heijunka board (daily actuals may create an adjustment to the following days plan)
• As team members complete their work, actuals received and actuals completed are tallied, collected, and made visible on the Kaizen board.
• Actuals completed are recorded for longer term analysis (usually electronically).
• Thursday – Actuals for the week add to the thinking of the next production planning session.

* If the actuals from the past don’t consistently improve the plan for the future, then there is not a closed loop.

Loop 2 – Root Cause, countermeasure, and status checks –Just because a team has begun to consistently collect plan vs. actual and use standard work, doesn’t mean they consistently take action on the problems that become visible. Further, a daily management system will begin to make more problems visible then ever before. Given this, if an effective system for dealing with them isn’t in place, the team will feel overwhelmed and that things are getting worse, rather then better, leading to sure abandonment. Therefore a loop to understand root cause of problems, take action, and learn from that action must be in place, and should look something like:

• Any problem that is identified (target vs. actual from previous day or team measures, an andon pull by a team member while using standard work, standard work itself, etc) is collected, added to a growing knowledge base of team problems, and made visible on the Kaizen board.
• For less complex problems – the team uses A3 thinking to understand root cause of the problem, and then propose a countermeasure (either in the moment of the andon pull or in the next day’s huddle).
  • Each countermeasure is assigned an owner, and given a date for a status update to be reported back to the team
• For more complex problems – a threshold is set, and when reached (issue arises x times, issue becomes apparent through analysis of knowledge base, etc), an A3 owner is assigned, as well as dates to report thinking back to the team
• Root cause and proposed countermeasures are added to the growing knowledge base of team problems (usually an electronic copy to ensure learning can be accumulated over time).
• On assigned dates, assigned owners (A3 or countermeasures) report back on their thinking or status of the countermeasure, respectively.
• Results of countermeasures are monitored for a set period of time to assess effectiveness at addressing root cause.
• Results of countermeasures (both effective and not) are captured in knowledge base
• If proven effective – Standard work and any other DMS component impacted by the countermeasure are updated to ensure the system reflects the improved thinking of the team (there may be a set cadence for updates (i.e. – once a month) to ensure change isn’t overwhelming or unorganized).
• A3’s are kept in a single place – owned by the team. Along with the knowledge base, these prior experiments and their results become the teams “book of knowledge” to refer to and learn from as future problems arise.

* If we don’t have a process in place to consistently learn from our problems, then we do not have a closed loop, failing to capitalize on our best source of learning.

For those of you implementing Daily Management Systems with your teams, I hope the thinking shared here aids in a stable and continuously improving system taking root.

Popularity: 9% [?]

This is the first of a two part blog

Recently, I’ve been consulting with a team focused on implementing a daily management system (DMS)* (see below) to allow them to stabilize their work and then continuously improve toward the customer. The team and their leader have shown great engagement. As a consultant, this is an ideal situation. However, as we know, it certainly doesn’t guarantee success. The area’s leader has made great strides in his lean thinking, and has moved from understanding the concepts theoretically but experiencing it as extra work, to now seeing how a daily management system “is the work”. This new understanding is predicated on seeing the DMS components as critical pieces of a living system.

This leader sees the vision, and is eager to make it a reality. As I’ve prepared to leave the area the leader has asked how he can be sure that the components they’ve begun to put in place can become that system he now sees. What I shared with him is the following

DMS system pic 1

Currently, his team is in Phase 1 of the drawing above. In fact, all teams that begin to put in a daily management system will be in this phase for some period of time. Essentially they have the major components, but as a team, they don’t have the understanding, roles, and culture to connect these components into a system. As he and I have discussed, this is a critical and potentially deadly phase, as his team, who are open and willing, will at some point revert back to old habits if a tangible value doesn’t become apparent. Tangible value will only begin to be seen and felt in Phase 3, when there is a system that allows the team to continuously identify problems and improve their processes toward the customer (continuous improvement) and when the frustrations / problems that they make visible result in the team identifying root cause, then a countermeasure, and finally implementing that countermeasure and monitoring results (showing Respect for People). Through this respect, engagement is fostered, as team members come to see the huddle and other problem raising opportunities as the avenues to improve their work, and not just a daily skit to appease management.

Once the major components of a DMS are understood by the team, and begin to be implemented, there are two major loops that need to be closed individually, and linked together (see picture below), to ensure there is a daily management system, and not just parts (assumes standard work is in place).

Loop 1 – Plan vs. Actual: If the actuals from the past don’t consistently improve the plan for the future, then there is not a closed loop.

Loop 2 – Root cause, countermeasure, and status checks: If we don’t have a process in place to consistently learn from our problems, then we do not have a closed loop, failing to capitalize on our best source of learning.

 DMS system pic 2

For length reasons, Loop 1 and Loop 2 will be discussed in more detail in my following blog.

* Interested in more information on what a Daily Management System is at Group Health?

If you are a GHC employee please see the link below

http://incontext.ghc.org/ghms/daily_management.html

If you are external to Group Health, we’ve defined the foundational elements as:

• Establishing process standards and targets based on customer requirements
• Standardizing, stabilizing, and continuously improving key processes
• Linked visual systems that drive actions
• Checking / rounding processes at all levels
• Using A3 thinking to solve problems
• Coaching staff to create problem solvers at all levels of the organization

• Using a daily plan that makes work visible – core work, strategic and team improvement
• Implementing counter-measures and rings of defense
• Incorporating demand and capacity information to help prioritize work
• Leveling the work load to create greater predictability and flow  

Popularity: 19% [?]

Over the last couple of months I have been working on an organizational pilot to develop a system that will allow frontline teams to improve their processes daily.  Our goal is to make this system as simple as possible and as I have discussed in past posts eventually we would like to get to the point where the improvement system in integrated into the daily work.  The approach we have taken is pretty straight forward and it is really exciting to see how engaged the teams are in improving their own processes.  I thought it might be useful to share our process and seek feedback:

• First, we allow the teams to select the process they would like to improve through a simple vote.  We have a set of guidelines that help with the selection which include that teams must use their minds not their money, the work needs to be completed within 9 business days, etc. 
• Second, we build a simple process map that calls out the high level steps in the process
• Third, we walk the process and identify waste.
• Fourth, as a group we have the team develop proposals for two experiments that they would like to run over the next two weeks.   We have simple forms that allow us to quickly develop the hypotheses and the action plans.
• Fifth, over the next two weeks we run the experiments.  The team is pulled together for quick check-ins to determine how things are going throughout the week and to make adjustments.  Team huddles are used to share the experiments with everyone on the staff since not everyone is able to participate in the improvement team. 
• Finally, at the end of two weeks the team comes together to complete the final adjustments to the experiment and to produce the job aides and job breakdowns. 

As I mentioned earlier the goal is to make this process as simple as possible.   The team meets for approximately 5 hours over the two week time period.  Most of the work is completed through small experiments during the work day.  We decided from the beginning to do no classroom work.  All of the group work is done in the middle of the gemba so that it is completely transparent to everyone what the team is doing and the only training we have done is a five minute lesson on waste.  Making all the work visible is a simple visual system that tracks new ideas, current experiments in progress and the results/documentation for work that is completed. 

For my next posting I will share our lessons learned thus far for this process.  I hope this is helpful!

Popularity: 4% [?]

A couple years back I had a chance to spend time at a fairly advanced Lean manufacturing organization that was really impressive.  This company ran hundreds of kaizen events a year and every single day they shut the factory down for 30 minutes and associates spent time doing daily improvement.  During the visit I told one of the leaders how impressed I was with what I was seeing and said it was the first time I had seen continuous improvement in action.   He gave me a funny look and told me they were just getting started and they were not even close to having a management system that promoted continuous improvement.  He then said that until they were able to “integrate improvement into their everyday processes” they would still be running improvement projects and always be reacting to problems that came up during the day.   He said continuous improvement only can be reached when “improving the process is no different than completing the process task.” 

To be honest at the time I really had no idea what he talking about and now its three years later I am only starting to understand.  I once heard someone say that a process is either being improved or it is in decline.  This is because customer and stakeholder requirements are constantly changing so that a standard and standard process that meets requirements one day will no longer meet the requirements the following unless we have ways to continuously understand and adapt to changes in those requirements.  When you consider that most work teams have dozens of processes that they manage on any given day if you take a project/event based approach then it is only realistic that most of your processes will be in decline at any given time.  Thus, there is no way an organization can claim to be promoting continuous improvement through events or projects.  It will only occur when “improving the work is the work.”

At Group Health we are a long way from getting to a place of continuous improvement, but this is why people talk about Lean as being a journey.  We started with the event based approach and we are now working in pockets to learn how to do daily improvement.  Most excitingly there are a couple of areas that are beginning to figure out how improvement is integrated into their work with frequent check and adjust cycles.  I spent time last week with a group of nurses that are adapting their processes with almost every case to meet changing customer requirements.  Our call centers are responding within seconds to changing customer demands.  As we learn more we will get better.

Popularity: 5% [?]