


Standardized Work for Kaizen: Define, Achieve, Maintain, Improve
by Tracey RichardsonJanuary 7, 2014
Standardized Work for Kaizen: Define, Achieve, Maintain, Improve
by Tracey RichardsonWe hear a lot about kaizen, but what are the actual process steps for kaizen?
I like to say, DAMI (Define, Achieve, Maintain, Improve), not to be confused with DMAIC. This was a thinking process we were all trained in when I worked at Toyota.
We never got to “settle in” or get used to a standard very long before it changed on us (through a specific improvement process of course). At first this was annoying, but then as the purpose of this was explained to us, it became our norm. In order to truly implement kaizen we knew we needed to practice the DAMI process to define a new standard from the current one.
Our leaders were there as mentors from the beginning, coaching us on the proper use of the process and making sure we engaged in dialogue at the gemba with the people who would be affected by the change. Then eventually it was expected of us as leaders (and to some extent team members), to define, achieve, maintain, and improve key processes without being told. Why? Because this was our job. Imagine this idea!
When working to strengthen business processes, so many people change things over and over (believing this is continuous improvement), but I ask them, do you have a standard for that process before you change something? Before we change anything, the current process needs to be written down and documented so it’s a benchmark for improvement. Taichii Ohno said, “There can be no kaizen without a standard.”
So let’s take a look at this DAMI process, which can be used in any type of organization and industry. What is it and how does it work?
Define:
The first step is to Define a standard, ideal state, the expectations, or possibly the scope of work for an individual. It’s an act of respect for people to give them clear expectations of what the standards are so they can then meet an internal or external customer need. Sometimes we don’t know what will meet expectations, but we need to start somewhere. Like the ole’ saying goes, how do you know where you are going if you don’t know where you are? This is also true for continuous improvement.
Achieve:
Once we have defined what we feel at the time is the best known method to perform our process, we need to ask the question: Can we Achieve it? Oftentimes organizations “over-promise” and find themselves not able to achieve standards based on meeting a sales need, not understanding total capability internally. So achievability is important.
In our early days of production at Toyota (TMMK plant), we knew we needed to make a car every 60 seconds. This is what we defined as the standard based on the customer need at that time (takt time). We went through several iterations of the process in order to achieve the 60 second standard. But we did it and the standard was achievable to our disbelief from where we were just two months before that.
Maintain:
If you reach the achievable stage then we must Maintain it for a period of time. My Japanese trainers would often say “lucky is not sustainable,” meaning if you get lucky and achieve your results with a non-repeatable or unsustainable process then you are just lucky. Who wants to base their business model on luck?
After we define and achieve, we must be able to prove we can sustain/maintain the new process/improvement every day for each output we create. For us this may be a 2–3 month period. Remember, this happens through measuring the process daily against the standard. If a standard is in place you should be able to differentiate the “plan versus actual” easily. All standards should allow us to see abnormality at a glance. So if it’s not maintainable then we need to revisit the achievability of the standard (define).
I think it’s funny when organizations reach the “maintain” phase because they feel they are “winning” as Charlie Sheen would say! Winning! But in the continuous improvement mindset “maintaining” is not the stopping point. There is still one more step.
Improve:
The most overlooked step in true continuous improvement is the actual “measurability” of the Improve step (creating a new standard if you are meeting the current one). So many continuous improvement leaders say, “We are improving.” I ask, “How do you know? They might say, “We are making change.” Again though, how do they know? This is where I see so many discrepancies and unexpected errors happen, most of which tend to root back to fact that the standard or ideal state was never truly defined or documented so it could be achieved and measured.
Continuous improvement in its true fashion is not easy, especially when we are asked to measure it and prove it. I can change something every day to make it appear like I am improving, but improvement without measures is waste. Kaizen without value isn’t kaizen. You must measure value. Without clear standards this is impossible.
At Toyota, we were never to be complacent or happy with just maintaining something. If you couldn’t see a problem in a process, you were expected to purposely create a gap. Think about that! What type of organization creates a problem to solve when there is none? Why might we do such a thing?
A lesson I learned from my trainer was “Never be comfortable. If you are comfortable then you are not learning.” So change it up folks! You must define, achieve, maintain, and improve if you really want to practice kaizen.
Think of it this way: if it isn’t broke… “purposely” break it!
David Verble
Mike Kobashi, Pascal Dennis, Sammy Obara, Tom Shuker & Tracey Richardson
Was this post... Click all that apply | |||
![]() |
![]() |
![]() |
![]() |
104
people say
YES
|
110
people say
YES
|
87
people say
YES
|
80
people say
YES
|
4 | People AGREE with this reply |
Hi Steve,
So to give you an example I will share with you in a "quick version" a story/example I share in my training sessions how my Japanese trainer taught me DAMI.
So when I was promoted into a salary management position I was responsible for an entire team in the Plastics department at Toyota (TMMK plant). As the Japanese would state, "50% of your role as a leader is to develop people". I wasnt meeting their need apparently :).
So one day my trainer came down on the floor (gemba) and "walked" my area. I was confused as to why since I felted I was meeting my all my goals set. Actually my KPI (key performance indicators) boards looked really good. I was, at the time, making an assumptions if "results" are good then everything is ok. A common mistake I see today in others.
My trainers continued to observe, I truly felt I was going to get a pat on the back for "good work". I was asked to come into our breakroom after 45 min of his observation time and he said "thank you Tracey san for KPI's being met", "but I have challenge for you". I considered it a compliment to get a thank you, but what came next was a surprise. After his observations (which I thought he couldnt find anything because he was taking so long since I was meeting all my goals), he said one of my teams had 10 people, could I please do with 9 people.
I have to say I didnt know what to say, it wasnt what I was expecting, but after deeper conversations and studying my processes I realized I wasnt doing what a leader should do and that is constantly be looking for waste even when your standards are met. Basically I was looking at the visual boards feeling all was well, but in reality my processes were not. This was a deep lesson in process versus results. If you focus solely on results you miss everything at the process level. Plus its historical data you cant change. A process you can change/improve to effect results (leading indicators versus lagging).
I tell this story in much greater detail, but I hope you see the DAMI example in it. My current standard was 10 people for that team, but the trainer saw waste in all their processes and had a vision of it being done with 9 with some "kaizen thinking" applied. We involved all our team and did this "rebalance" in 4 mos. It ran very well with 9 people and no one worked harder, just smarter. The extra person went to another team. No one was ever laid off or fired at Toyota as a result of kaizen. It was production efficiency, kaizen and people development.
I hope this story helps a bit. Tracey
Reply »
Tracey,
Thank you for sharing. I have always found that real life examples are excellent ways to learn.
Kind Regards,
Steve
Reply »
Thank you,
Charlie
Reply »
Reply »
Reply »
3 | People AGREE with this comment |
Your articles are articulate, informative, and easy as well as fun to read. You seem to have a natural knack with your wiriting skills.
Well done,
Kent
Reply »
Hi Kent,
I appreciate your kind words, thank you. I really try to bring across the stories and lessons as I learned them. I teach the same as I write, very practical and down to earth. I hope I can continue to share with everyone in the same way. Thanks again, Tracey
Reply »
Reply »
Hi John,
Thank you for your comment. I would have liked to share all the details but perhaps it can be a story the the form of a column one day. :). I spend a lot of time talking about process and results you are correct- process focus is essential. I hope to continue to share experiences that help others learn. There are a few up and coming so stay tuned! :) Thanks Tracey
Reply »
Reply »
Hi Jesse,
This is a practical post everyone can read through and hopefully translate to their own work. Without standards its very difficult to measure improvement, so if we spend some time up front developing them (to meet customer need) it gives us more time in the future to be proactive versus reactive. I like to think of it as swinging the pendulum towards process versus all results. :). Thanks for your feedback and willingness to share. Tracey
Reply »
Thank you,
Amy H. Rossetti
Reply »
Tracey,
Nice article. Did you ever use Kaizen events at Toyota?
If so were they successful?
Thanks
David
Reply »
David Verble
Mike Kobashi, Pascal Dennis, Sammy Obara, Tom Shuker & Tracey Richardson
The article was very interesting. Would it be possible to share examples?
Regards,
Steve
Reply »