woensdag 25 december 2013

Purpose of Kaizen Events

Kaizen Events are bursts of improvement activity, where typically employees from different departments participate in a one- or multiday workshop to solve a business problem.

In my experience, the purpose of these events is not limited to just solving a problem. By solving a problem together we also aim at building capabilities and trust.

What capabilities are we developping during Kaizen Events?
First, we develop process understanding; i.e. understand how my work relates to that of my colleagues and eventually to the customer.
Second, we train people in problem solving methods and lean practices such as A3, fishbone, process mapping, 5 why's.

Why and how do we develop trust and relationships during Kaizen Events?
Cooperation and trust between people (esp. from different departments) are at the foundation of continuous improvement. Without trust and teamwork, there can be no autonomous kaizen. In my experience, people who have solved a problem together during a Kaizen Event have build relationships. They have a betting understanding of eachother's work and concerns. Consequently, I find that whenever a new problem occurs, they'll contact eachother much easier.

Go See - understand the process at the gemba
Here are some tips that can help you work towards this purpose of Kaizen Events:
  • Plan time to train employees in problem solving tools, before applying them
  • Allow time for participants to share views and opinions. The benefit is in the dialogue, not in rushing to the solution.
Taking time to reflect with the team
It wasn't until reviewing this article, that I realised the summary of this article is the same as my slogan "Improving Performance, Growing Together": improve your process and business while developping people and fostering teamwork.

vrijdag 2 augustus 2013

Lean appeals to mind, hands and heart

I just love lean! It appeals to my mind, my hands, and my heart. Somehow, since working from the lean source, I feel a more complete and balanced person.

Clearly, lean is a holistic management system, an integrated approach on how to run a company. But for today, I would like to zoom in on how lean is holistic in the way it engages people. My deep rooted belief and daily experience is that lean management appeals to the minds, hands, and hearts of people.

First, lean's preference for the scientific and socratic method appeals to our brain. Many of the traditional lean tools help in addressing business challenges from an analytical perspective, such as Value stream maps, SMED, KPI's, level scheduling, designing the ideal state value stream based on lean prinicples. The predominant lean school of thought in the West has been very much the analytical en technical one.


Secondly, lean has a strong preference for experiments and for incremental improvement action, especially in comparison with other improvement methodologies such as TQM or LSS. Lean emphasises the gemba where the action takes place. It's at the gemba that we learn by doing. A famous quote in this context is: "Learn with you hands, and see with your feet."

Thirdly, lean addresses the heart: respect for people is a core value of lean management. Lean is about developing and engaging people, about giving them a meaningful purpose (e.g., serving the customer, serving society, personal mastery), and about belonging and contributing to a team. It is also about giving people a sense of dignity and ownership, and about creating a physically and mentally safe workplace where people can develop to their full potential and experience a mental state of flow.

I'd love to hear if you have had similar experiences with lean practices addressing mind, hands, and heart.

Understanding complex problems with causal diagrams.

Some problems are just more complex than others. In some cases multiple causes and effects are re-enforcing or smoothing eachother. Typical tools such as 5why's or fishbone don't offer sufficient support to understand and visualise these problem. In my experience, this is when a causal diagram really helps out. A causal diagram is a graphical tool that enables the visualisation of causal relationships between multiple variables in a causal model.

Here is an example of a causal diagram I once made to understand challenges in a complex SAP development and roll-out program, where milestones were systematically not met. The white circles describe causes and effects, where the arrows indicate how one topic has a causal relationship to another. For example, running many projects in parallel causes competition for scarce resources.



Let's have a closer look at how this works using the above example, starting at the bottom right: running many interrelated projects in parallel is increasing the complexity and dependencies in each of the projects. This increased complexity made it hard to make a reliable overall plan. Furthermore, all these projects were competing for scarce resources. When an issue or delay in a high priority project pulled for more scarce resources than planned, other projects where these people originally were planned to work on, were delayed. As a quick fix, it was as a rule agreed that critical resources would only be allocated shortly in advance and for a short period of time; in other words to allow them to work on where the biggest fires were. Consequently, since nobody knew whether critical resources would be available as planned, the quality and relevance of (short term) planning of projects was getting poorer. Basically, people were thinking: "Why bother investing time in making a serious planning; I never get the people I need for my project anyway." As a result, there was no real commitment for any of the timelines of the projects that were on the table. Also, challenging project managers on not meeting their deadlines, systematically resulted in the answer: "I'm not getting a response or availability (from the critical resources)". Gradually, the local roll-out management stopped challenging their local project managers. So, the incentive for good planning and execution slowly diminished. All in all, this resulted in a self enforcing mechanism of constant project replanning, with deteriorating quality of planning, poor commited project managers and nobody who was really following up on realisation of plans.

It took me a while to understand what was really going on. Mapping the interdependencies in a causal diagram helped in analysing the problems and finally defining the countermeasures.