Danaher Kaizen & Sandwich Example (India Post #1)

I’m back! It was an amazing trip, and there’s tons to tell….there were three main themes of the trip, so I’ll separate the blog posts into those segments – #1 will focus on the Kaizen exercise; #2 will concentrate on the culture; #3 will focus on entrepreneurship and innovation, including a visit to a series of businesses in a Mumbai slum. So….on to #1!

First and foremost, a huge thank you to Danaher for hosting this trip. They generously took care of our hotel, food, and car transportation in India, and made us feel safe and welcome at all times. Thank you for that, for allowing us to work in the Portescap plant for a week on this exercise, and for teaching us the Danaher kaizen methods. I don’t want to share anything proprietary, so I’m a little limited, but I’ll explain what I can.

Our Team: Our group of 8 Darden students (and one former student, now a Danaher employee), was split into two groups, and each group was given a production “cell” to focus on, along with targeted improvements (space usage, productivity, etc.). This “kaizen” exercise used a process developed across Danaher, called DBS (Danaher Business Systems). Our job was to apply that process to our cell, work with the line workers to find areas of improvement, and implement new changes to those areas for quantifiable improvement. My team is shown below (huge thanks to Anant, Sharad, Siddarth, and Rutesh for all they taught us). The entire line of operators were women. Tiny, under 5′ women who worked on tiny, delicate motors.

How it Works: To explain it without using DBS terms, or violating confidentiality, I’ve created a Fake Sandwich Production Line example. Imagine you have a line of 5 workers who make you sandwiches. Delicious sandwiches, but it takes them too long to make them, and your wife/husband says you have to improve the cost structure of your sandwiches, since you’re eating the family out of money.

Watch It: You would start by figuring out what each worker is doing….What exactly is going on in that line? To do this, you watch it. For several hours, standing there with a timer in hand, just watching….and you figure out how it goes. One worker toasts the bread, then passes it to the mustard guy, who spreads mustard on it, then passes it to the veggie guy. The veggie guy puts on tomatoes and lettuce, then passes it to the meats guy, who adds in salami and ham, then passes it to the plating guy, who cuts it, plates it, adds a glass of milk and hands it to you. Great, now you know the process!

Calculate It: You take your notes back and look at them, and try to figure out how timing across the line works. So, for instance, the toast guy stands there waiting for the toast for 30 seconds, doing nothing. And while everyone else’s job takes under 15 seconds, the veggie guy takes 45. So he’s slowing them down. And you look at the workers, and the time, and try to figure out how a different allocation of resources makes everything faster and cheaper. You ask questions like: Does this process have to stay in this order? Do we need this many operators? What’s the slowest part of this (the bottleneck?) How can we speed this up? By asking these questions, you begin to realize opportunities to improve things just by working on operator loading (how much work they do) and order. So perhaps the toasting guy goes and cuts the tomatoes while waiting for the toast the pop. Or perhaps the mustard guy and the toasting guy become the same guy, because together those two jobs only take 35 seconds, and since the veggie guy takes 45, that still would be under the slowest part of the process.

(UPDATE – Takt Time): My teammate Benson reminded me of an important point- takt time. Takt time is basically the max time in total to make One Unit- the max time allowed per unit to meet demand. In Benson’s words, “For example, if your sandwich shop was open for 20,000 seconds per day (roughly 5.5 hours) and your avg demand was 50 sandwiches per day, your takt time would be 400 seconds (roughly 6.5 minutes). So you know you have to load your operators such that every 400 seconds you have a sandwich on a plate ready to serve.” You need to know the takt time in order to know the max time each of your operators can spend, so that as you make decisions for step ii, you’re keeping the time below the takt time.

Change It: Once you have that data, and you’ve made some decisions on what can change, you go back and make some changes. You teach the toast guy how to cut tomatoes, or you add mustard to his job, or you switch the veggie and meat guys…whatever the data told you, you change.

Improve It: While you’re doing this all, you’re also looking for ways to create efficiencies and speed the jobs. Maybe the toaster can be set to 4 instead of 5, speeding the process by 10 seconds. Perhaps the meat doesn’t come pre-sliced, but it could (from the supplier for free). Maybe the tomato guy is slicing them too thin or too thick. You make these changes to improve things.That’s not a full Kaizen process, nor does it show the depth of DBS guidance, but I wanted to avoid oversharing, and that should at least give you a general breakdown of what we did. But with motors, not sandwiches…..

Learnings: It was a truly incredible learning process. DBS provides all the templates and tools to guide you, but the process requires you to think in a specific way that takes time. For the first two days, it was difficult to really see areas of improvements to watch a process and visualize small, specific changes that would improve it by seconds or milliseconds. After that it began to come more easily, and you started to naturally notice areas of possible improvement more easily.

Learning to work with the line workers was a challenge given language barriers, but with the help of Anant and Sharad, we were able to translate back and forth, and eventually workers began trusting us enough to come straight to us with issues and communicate via hand signals. That was especially true for the “lead girls” who managed the workers directly, as they understand each step in the process and are best able to articulate small improvements that impact each activity.

Buy-in from the operators is key for ensuring adherence to the changes; if the workers are not bought in, the changes won’t last and the impact will be minimal. Also, no matter how long you watch a process, the workers are doing that process nearly 1,000x per day- THEY are the voice of experience here, and know better than anyone the changes that would help. So it’s integral that you solicit and follow their suggestions.

One of the key features of this approach (that my teammate Tim reminded me of), was a daily “report out” where we reviewed key steps, findings, and goals for the next day, and presented those to management. This feature kept us accountable, ensured we planned out the next day, and allowed us the chance to receive in-the-process feedback from those who had done this before. And knew where we could improve.

I could write a ton more, but I’ll leave it at that. Hopefully this gives you some idea of what the “kaizen” exercise was like. Tomorrow I’ll talk about the culture, and what we saw out in the city, and while working with our India friends.