The following content is
provided under a Creative Commons license. Your support will help
MIT OpenCourseWare continue to offer high quality
educational resources for free. To make a donation or
view additional materials from hundreds of MIT courses,
visit MIT OpenCourseWare at ocw.mit.edu. EARLL MURMAN: At
one time, I know MIT did a study, how
many signatures it took to appoint a student as
a graduate research assistant, and it was 18. So lean thinking
very much applies not just to defense aircraft,
which a lot of it you've heard about, but to a
lot of other situations, including education. And that's an opportunity. If you think it's hard to
change aerospace companies, and now we're doing
health care, it's going to be even harder
to change education, because faculty members
are not very flexible in these kinds of things. But maybe in time, we will. OK, so what we're going
to do in this module is to look into some of
the fundamental principles of lean thinking. So you've had a couple
introductory modules. Now we're actually going to
get down to a little bit more, what are the fundamentals. So we're going to look at-- at the end of this module, you
should be able to describe, what are the basic
elements of a process. You will be able to
draw a process map. You're going to draw a
process map is an exercise. You should be able to explain
what constitutes value. George already talked
a lot about that, but we'll be a little
bit more specific. Then there are five fundamental
principles of lean thinking. They're very fairly
simple, common sense, but very powerful
to internalize. And then we're going to
talk about some tools for implementing lean thinking. George already mentioned
value stream maps. We're going to-- we won't
do that till this afternoon, but that's a very powerful tool. But we'll look at
some simpler tools. OK, process, pretty simple,
a series of actions, changes, or functions which
brings about a result. And so you got-- every process has some inputs. There's a process which
changes those inputs into some useful outputs. So let me give you a simple
example you can all relate to, doing homework problem. What are your inputs
for a homework problem? Greg? AUDIENCE: If it's out of
the book, they already-- EARLL MURMAN: OK. AUDIENCE: --give you-- EARLL MURMAN: OK. Yeah. Maggie. AUDIENCE: Lecture notes. EARLL MURMAN: Yeah. AUDIENCE: Other
classes [INAUDIBLE].. EARLL MURMAN: Yeah. And maybe you got
some requirements from somebody who wants you
to do that homework problem. Here's the assumptions,
or here's what you-- OK. And then what do you do? Well, you have some kind of
way of taking those inputs and generating-- now what's the output
of a homework problem? Christopher? AUDIENCE: The solution. EARLL MURMAN: Solution, OK. And what do you do with that? AUDIENCE: Turn it in. EARLL MURMAN: Turn it in. Right. [CHUCKLES] OK, OK. And so you got-- if you think about how
you do a homework problem, you probably have developed some
kind of process for doing that. Nobody-- you might have
even been taught that. But maybe you read it
carefully, what's required. Maybe you do it
with somebody else. Maybe check the answers. You got some kind of
process to do that. That's a process. Now what we're
going to talk about, processes that involve
a lot of people. George, in one of your
radars, how many people might be involved in, say-- these are engineers. How many people might be
involved in the engineering of a radar system? AUDIENCE: The developmental
up front work? EARLL MURMAN: Yeah. AUDIENCE: 50 to 60 overall. EARLL MURMAN: 50 or 60 people. OK, that's fairly
small, actually. Al, at F-18, how many
F-18 do you have? How many people
might be involved? AUDIENCE: 1,500. EARLL MURMAN: 1,500. So we're talking
about processes where you got a lot of
people involved, not just one person
working a homework problem. But it's the same
concept, so you have to go about it the right way. OK, so we already
talked about this. What happens to the
output of the process? We call the person that
that goes to the customer. So in your homework
problem, Chris, your customer is your
faculty member, or TA, or whoever you're giving it to. And what do you want
to do to that customer? You want to-- AUDIENCE: Please them? EARLL MURMAN: Please them. Right. You want to delight them, right. You want them to
come back and say, Christopher, this is not
an A. It's an A plus. OK, that's your customer. Now George talked about
customers for the radar. Lockheed was the customer
for the radar system. That kind of customer we
call an external customer. That's the person who
typically is giving you money for something. That's pretty important. If they don't give you money
for it, whoever your company is isn't going to be
around too long. George mentioned
Westinghouse was making tons of money
from their customer until they got
into some trouble. Now there's actually a
difference between the end user and the customer. So if we're making
commercial airplanes, the customer might
be the airlines, but the end user is who? AUDIENCE: Passenger. EARLL MURMAN: The passenger,
the mechanic, the pilot. So they don't pay
for the airplane, but they're the
ones that use it. So now in that
case, they actually don't pay for the airplane. In some other
cases, the end user may actually pay and
consume the product. I'm the end user of
the water bottle. But there's some difference
between end users and customers, but
there's somebody who's paying for
what you're doing, and you want to please
them, or somebody who's using what
you're producing, and you want to please them. But many of the customers
you guys will work for, very few of you
will probably end up handing the airplane
over, or the satellite, or the avionics system
to the paying customer. That'd be unusual. Some of you may. You may be the CEO or something. But as an engineer,
you'll probably be turning that over
to somebody who's going to build it or
test it or something. So that's your
customer, and that's what we call an
internal customer. And typically they
don't give you money, but they're the ones
who receive your work. Now what do you think
you have you have a process that has no customer? Are you going to be
adding value if nobody wants what you're doing? Probably not, OK. So everybody who's doing
something that's value added is going to have
a customer who's the next person in the
sequence of what they're doing. OK, and not only to customers
receive what you're doing, but as we said in
the homework problem, they give you some
of the inputs. They give you the specifications
or the delivery schedule. So the customers not
only receive the output but give you some of the input. OK, so we have a process and-- yeah. AUDIENCE: I was
just going to say that one of the good examples
of that-- and most folks don't think of it--
is car dealerships. Because most folks
think of you coming in to buy the car as the customer,
when, in fact, when they were trying to deploy OnStar, the
real reality of it was people only bought the cars
that the dealers were buying from the manufacturer. So they had to redo a bunch
of that to force it down through the dealerships. So that end user vice customer
discussion is valuable. EARLL MURMAN: Yeah. Yeah, there's a
difference between the end user and the customer,
not always, but I mean, there can be. Sometimes they're the same. OK, now a good way to understand
a process is to draw a map, and that's going to
be our next exercise. We're actually going
to map out a process. Don't try to read all this. It's made so you can't read it. But this is an
actual process map from one of our LAI
companies on the process they used to do a
release of a drawing after it was drawn, a
checkoff inspection process. And what's your first
impression of that process? It looks kind of
complicated, doesn't it? I mean, look at this thing here. This goes here,
and this goes here, and I can't find
where this goes. Everything go-- oh,
here, it goes here. But anyway, it's a visual. So a process map
is a visualization, a visual image of it. And when you're involving
50 people or 1,500 people, very few of those 50 people
know what the other person's doing, unless you try to map
it out and show it to them. And that's what leads
to this value stream map, which George mentioned. So the only way you can improve
a process is to understand it. You can't improve it if
you don't understand it. So one of things
about lean thinking is, we start with where
we're at, the current state, George said, and we
try to improve it. We don't throw it out
and reinvent the wheel and start with something
completely untested. We start with where we're at. We try to-- we being
the people doing it, the frontline workers,
the Joe Taylors, try to improve it and then
improve it again and again. And the way to improve
it is to understand it. And it's easier to understand
if you can visualize it. It's pretty hard if I tried to
describe this process to you in words or a long
document what it's like, but it's much easier if
you can visualize it. And a process map is just
an organized visualization of all the interrelated
activities, which, when combined, are
that set of activities that change in input to an output. That's called a process map. Any of you ever heard this
word, process map, before? No. Yeah, talk-- OK. This is remarkable. And this is why we're
teaching this class. I mean, I love
teaching aerodynamics. That's what I taught
here for many years. But when you guys
get out and try to apply that aerodynamics
to an aerospace problem, you're going to be in the midst
of one of these processes, and we don't teach you
anything about processes at MIT except here. And about half of what you need
to know is this kind of stuff, and the other half
is the aerodynamics. OK, so let's talk--
let's look at a-- this is a very simple process
to fix a hot dog. Now no one would
ever map this out, because you know
how to fix hot dogs. But OK, we want
to fix a hot dog, and so here's the process map,
and here's some symbology, and we'll go back and forth. So we start with the
customer, and that customer gives an order. So if it's you, you're
probably giving it to yourself, but it may be your roommate or
wife her boyfriend or whatever. I want a hot dog. OK, so we're going to use
a broken arrow like that to show information flow. So we get here, got an
order for a hot dog. So we need to find,
do we have a hot dog and do we have a
bun to give that? So that's the first question,
do we have any hot dogs? If the answer is
yes, do we nee-- I'm sorry, do we need a hot dog? If the answer is yes, we
have to go to the store and get that hot dog before
we can start to cook it. You might think of this as
being going to your supplier. If the answer's no, we
don't need a hot dog, we have one in inventory-- that's inventory--
go to the pantry. We'll get it, the bun or the
refrigerator or whatever, and then we can start
cooking the hot dog. So first, we got to
get the raw materials, the input for our process. So we got information. We got some raw materials. Then we're using
these double arrows to show that this is
the main process flow. Now what's flowing
in this process? The hot dog is flowing, OK. So we cook the hot dog. That's a task. We put it in the bun
and add the condiments. That's another task. And then we deliver the
order to the customer. But things aren't finished yet. We want to do a little clean up
to get ready for the next one. In the lean thinking, what
do we call this part in here? AUDIENCE: [INAUDIBLE] EARLL MURMAN: 5S. OK, we do a little
5S, clean things up. Then we ask, is that
the last hot dog and bun we have in the pantry? If the answer's
yes, what do we do? We make a shopping list. Now you've actually heard
this in a different term this morning but probably
haven't connected the dots yet. Anybody recognize
what this might be in terms of something Al
mentioned in his lecture? This is a kanban. This is a list that we're
now out of hot dogs, and we need some more hot dogs. And we'll come back
to that a little bit later in the lecture,
but it's a kanban. So we add it to
our shopping list, because now we know we need
some more, and then we stop. OK, so that's a
simple process map. And in doing these, since you're
working with multiple people, you have to agree
on some terminology, just like in
aerodynamics class, you have to agree that
alpha stands for angle of attack or structures
class, that L stands for the length of the beam. Otherwise you can't
communicate with each other. When you work
together as a group, you have to agree on some kind
of symbols for these things. And these are not unique. There are different
ways you can do it, but these are some ones
that are typically done. So this is the
main process flow. This is a secondary
or feeder flow. This information flow. So this means we're getting
something which is contributing to the main flow. We have a warehouse, we have
a task, we have inventory, we have a decision. OK, so now I'm going to
ask you to open your folder and pull out something called
Sasha and Andy's Hot Dog Stand. OK, it's in the right
side of your folder. It should be right
behind your 5S or right behind your
enterprise speaker notes. OK, so Sasha and
Andy have a hot dog stand that they've set
up at their local park. And they offer a hot dog
with a choice of fresh fruit and a beverage to any of the
walk-up customers in the park between 10:00 and 2:00. And they've set out condiments. The customers put their
own condiments on. And the feedback they're
getting is the customers like the hot dogs,
but they're saying it's an awful-- they have to
wait an awful long time to get it. So they've been doing
this for two weeks, making some summer
money, and they notice they're barely keeping
up with the customer demand. And they're making
a little money, and they'd like to
improve their process, because they can see that
the demand is growing. And so at the end of the week,
they sat down and came up with these 11 steps
in their process, and they've got some data
for each of the steps. Now we're going to start by
working with just the process steps. When you start adding
the data, then you get to what we call
a value stream map, and we'll be doing
that later on. So right now we want
to look at the process, and so here's our exercise. We got four tables. We got four easel charts. We got some post-its for you. And Hugh is going to describe
how to use those in a minute here. And so what you want to do
is to write down the process steps on the post-its. And to organize
them, it's nice-- it turns out it's better if you
do these things with post-its because you can move them
around until you arrive at what you decide your process map is. So you put those post-its
on the easel chart, and then you're going to
draw some lines to map out this process. And what I want to
point out is, don't get hung up on the symbology. The symbology is only
a means to an end. So if you want to use a
little different symbology, that's fine. Don't-- we gave you some to
use, but you don't have to feel constrained by that. And you want to identify
what are the inputs and outputs of the process. To do that, you
have to understand what the boundary of the process
is, what's within the process and what's outside the process. And then we're going to ask
you to present your process map to the rest of the
class and explain it. OK? So this will take about
15 minutes altogether. We'll give about 10 minutes
to do the process map. If you need a little bit more
time, we'll figure it out. And then about five
minutes to report out. AUDIENCE: I don't
know what happened after that [INAUDIBLE]. [INTERPOSING VOICES] AUDIENCE: Where? [INTERPOSING VOICES] AUDIENCE: Engaged. EARLL MURMAN: Yeah. AUDIENCE: They really are. EARLL MURMAN: Yeah. GUEST SPEAKER: They're
engaging very [INAUDIBLE].. It's good. EARLL MURMAN: So just to wrap up
this introduction of processes, processes really underlay
everything we do. I mean, there's this
phrase, if I have a hammer, everything looks like a nail. Well, if you start abstracting
what you do in life, you can abstract almost
anything to, it's a process. And it turns out this
is critically important. Process thinking is critically
important to improvements. The fundamentals
of lean thinking are the foundations of
modern process improvement. And you'll hear this word
a lot, process improvement. And so understanding
and improving processes is the key step to this
kind of productivity, which George was talking about
and Al's been talking about. And what's important
to realize is it's not that the
people are not capable. Most people that you
hire are actually quite capable of
doing something, maybe not what you
have them doing, but they're quite capable
of doing something. It's that you immersive them
in a system, as George said, which is not efficient, and
that's the process level. So lean thinking is not
about beating up people. It's about giving those
people an efficient process so that they can be productive. OK, now with that,
we're going to now segue to these five fundamental
principles of lean thinking. And these were
articulated in the book by Jim Womack and Dan Jones. The first thing is to
understand, what is value? And value is defined
by the customer in terms of specific
products and services. For engineers, this is very
hard to think about value, because there are no
units that go with it. It's not like speed or
mass or volts or something. There are units to go
with value, yet each of us makes value decisions every day. You made a value decision
to come take this course. However you did
that, you decided this course was going
to be valuable enough you wanted to come take it. You're the customer. You're our customers
for this course, and we're going to keep
asking you, are you satisfied? How can you help us improve it? So value's defined
by the customer. Once we understand
what value is, then we talk about
a value stream, and George mentioned
value stream mapping. And value stream are
the end to end actions that you've just mapped out
and processes and functions that transform the
inputs to the outputs. And what we want to do is
identify what in that stream is value added and
what's not value added. So you can think of the
customer says, I want something. There are a bunch
of steps to do that. Now I'll tell you a
little quick story here, is that when Boeing
commercial airplanes started thinking in terms of these
things, I was told by a friend there that they started with
that their output is to deliver an airplane to a customer. And they started
mapping backwards all of the activities they did
to develop that airplane back to the front. And then they compared that
with what they actually did. So this is the things they need
to do to deliver that product, but what do we actually do? And they found out
about 50% of the things they did to develop that
airplane added no value in the eyes of the customer. 50%. OK, so once you understand
that value stream, then you want to try
to have everything flowing through
that value stream smoothly, eliminating
all the waste and having everything
just add value. So you want to make-- want to have things
going smoothly. You don't want to have things
blocked, not flowing smoothly. And then when you can
get to that point, and we're going to go through
each of these five steps in more detail, than you
want to be able to have the customer pull that. So you'd like to be able to-- rather than-- there's
pull and push. So the push mentality is,
I'm going to build airplanes, or I'm going to
build spacecraft, or I'm going to do
engineering calculations or whatever you do. And you're thinking about
just doing your work. The pull process is
that you're responding to what the customer demand is. So the customer
wants the airplanes, the customer wants
your calculations, the customer wants your
widgets or whatever. And you're trying to get that
to them just as they want it. They're pulling it from you. And then once you
get to that point, then you just keep
making it better. As George says, do
a value stream map. And that's current. Say 18 months later, you
can probably do better. Lean thinking is
an endless journey. It's a Journey of just
continuing to improve, continuing to improve. As Al mentioned, this
is a sixth version of this course we've done. Actually, the first
version worked really well. We got fantastic student reviews
on the very first version, but we've made it a lot better. OK, so those are the five
fundamental principles of lean thinking. We'll come back to them
several times in the course. OK, now what's value
and non-value added? And as I said, this
is particularly hard for engineers, because we
don't-- it's not quantitative. Try to remember this. A value added activity
has three tests. One was, does it actually
transform or shape whatever's in the value stream,
material or information? Is it just moving the material
from one place to another? Does it take it from one
warehouse to another, or is it actually reshaping
it in that process? If it's just moving it,
is not adding any value. If it's reshaping
it and changing it, then it's adding value. So it has to actually
do something to it. Secondly, do you do it
right the first time? This is the quality. This is the fundamental
thing about quality. Do you do the right-- or do you
have to go back and do rework, as we heard about sending
it back to Norway? And finally, is
what you're doing something the customer wants? So those are the three tests. Now if it doesn't
satisfy those tests, then it's a non-value
added activity, and there are two
versions of this. Let me put them both up. Let's start with this one
first because it's easier. It's you're doing
something to it, but it adds no value in
the eyes of the customer. And it's just pure waste. It's waiting-- it's idle. It's sitting there,
just sitting idle. Nothing's happening to it. It's sitting there
for months and months. Nobody's working on it. Or it's going into
inventory and waiting, or it's being reworked. Or we got 27 signatures
that are being checked off. That's pure waste. Nothing useful is
being done at all, but it's consuming resources. In the middle category is
what we call necessary waste. It's consuming
resources, but it can't be eliminated based on the
current technology or policy or thinking. So Mark, is it? AUDIENCE: Yes. EARLL MURMAN: Mark
brought up this question. How do we know
whether it's worth investing that money to get
the number of signatures from 27 to four? You're going to have to do
some kind of cost benefit analysis or something and maybe
get a team together to fix it. If you think of
that, the customer doesn't care that
you're doing that, but that's a necessary
step to actually deliver the value to the customer. So the customer
doesn't want to pay you to do that study to
reduce the cost of signatures. But, eventually, by
doing that, you're going to be able to reduce
the cost of the product to the customer. So we have an activity
which doesn't add value in the eyes of the
customer but is necessary to complete your job. So example is
project coordination. If you all go to a
meeting Monday morning to coordinate working
on the project, the customer doesn't
care about that meeting. That's not in the contract, that
you'll have a meeting on Monday morning, please deliver me
the results of the meeting. But if you don't
go to that meeting and you all work on the
wrong things during the week, that would have
been a big mistake. So the coordination
meeting by itself is not something
the customer wants, but it's necessary waste. Or maybe you have to satisfy
some regulatory things, environmental concerns
or worker standards. This should actually
be company mandate. Did someone make a check? Because this should be not the
customer mandate but company mandate. Maybe the company has some
policies or it's legal. What you want to do is you
want to get rid of this stuff right away. It's not doing anything useful. You want to continually work
on minimizing this stuff, and you want to
emphasize this stuff. AUDIENCE: Earll? EARLL MURMAN: Yeah. AUDIENCE: I'd be interested
if the class would tell us whether they think inspection
is a value added task or not. EARLL MURMAN: Let's take a
look at that Inspections. Is inspection a value
added task or not? Well, if it catches
a mistake, I'd say it was a value added task. But if you don't run the process
right in the first place, maybe you won't need
to inspect-- maybe get rid of the inspection set. AUDIENCE: [INAUDIBLE] is
filling out a timecard, payroll. American Airlines doesn't care
one iota for you to do that. I mean, if they bought the
airplane for $125 million, that's all that-- they're going
to write you a check for that. That's it. But we all know that
we have to, in fact-- if you're going to get paid,
you have to fill out a timecard. EARLL MURMAN: OK,
let's keep going. These are good examples. Here's an example of-- actually, this is it. There you go George, inspection. Mistakes are-- inspection
is an example of waste. Bingo, we just covered this one. An inspection by itself
doesn't add value. OK, value stream. So that's value. Now let's move on
to value stream. So value stream is
all the activities that create the value. It starts with the raw materials
or initial information, and it ends with it
going to the customer. So the value stream are
all these activities that you receive
some-- customer needs or requirements or schedule,
so the customer specifies what they want. And then you do these activities
which transform that material or information to the customer. Now this being a
group of engineers, let me say that in
manufacturing, you're usually transforming material. It's easy to see. In engineering, you're actually
transforming information. You're doing designs. You're doing analysis. You're-- da-ta. So we work with information. Information is very hard to see. So one of the challenges
of applying lean thinking to engineering is to
realize that you're transforming information. OK, so that's what it says. What moves in a value
stream-- in manufacturing, material moves. In engineering or
travel requisitions, information's moving. As we've mentioned,
lean thinking is being applied a
lot to health care, and there, people are moving. OK, you're transforming
the person, so the person is what's
in the value stream. And actually, in education,
that's what it is, too. Hopefully, we're adding value
in these three days do you. OK, we're trying to transform
you in some positive way, and that's what we're doing. So you're our value
stream for now. OK, this comes pretty
much straight from Toyota. They identified, what are
the different categories you should look in for
waste, and they came up with seven categories. So producing more
than what you need. We often do this in
spades in engineering. We crank out lots of
numbers, whether we need them or not, because we
can do it, right. I mean, boy, that's great. I mean, I can give
you anything you want, and so I'll just do that. Well that's maybe
not adding value. You generate information
and put it into inventory. No again, let me put this
in engineering context, since you're engineers. You do the calculations, you do
them three months ahead of time and save them. Boy, you're really good. Well, the trouble with
that is three months later, the world's changed,
and your calculations may have to be redone
because they're obsolete. There's new information
or something. So they lost value
sitting in inventory. Transportation. You're just moving things. Maybe you carry the
report across campus and put it over there,
and then later on, you carry it back and so on. If you can get rid
of those steps, those are non-value added steps. Unnecessary movement
is you bring everybody together for your meeting here,
and you found out you really didn't need to do that. You could have
done it virtually. You took a lot of time to
bring people together here. They had to walk across campus,
spend 15, 20 minutes doing that, when you could have
done it in some virtual mode or by telecon or
something like that. Waiting. So you're ready to
do the next job, but the person, your supplier--
you're a customer for somebody. They're the supplier. They haven't given you
the information yet, so you just wait an
extra couple of days because they haven't done their
work, and that's wasted time. Defects, I think
that's pretty clear. You make mistakes,
and those mistakes propagate in the system
and create other mistakes. Or over-processing. You calculate 16 digits
when you're not sure whether the first
one's right or not. Or these view graphs. You keep working
on the view graphs to make them better and
better, but really, it's not adding any value. OK, so that's value
stream quickly. Flow. Now that you've identified
what's value added, you want to get it to flow. So here, we need to
think about time, because flow has a connotation
of something's moving in time, controlling the process,
making sure things are done in
sequence, eliminating bottlenecks and stoppages, and
eliminating unplanned rework. Now in engineering, there's
often a lot of iterative loops which are necessary,
because you have to start with some
approximation, do a calculation, do
another approximation. Those ones, if you think
of them carefully, are OK, but it's the unplanned
ones that you do. You did the calculation, but
you forgot to do something, so you got to go
back and redo it. That's unplanned. OK, so in looking at flow-- and this is a change
in mindset, the kind of thing George
was talking about is difficult-- you want to
look at not what you're doing but what's going in
the value stream. So if you have a
company that has a lot of different departments
and the departments are only thinking about their job, you're
going to have a hard time. What you have to
look at is what's going through those departments. So you have to,
as Will would say, strap yourself
onto the activity. Think of going with it. And that's how to
think about flow. So you have to go-- and
George mentioned this. He said Lockheed and Northrop
Grumman and the supplier in Norway got together. They went beyond the
walls of Northrop Grumman. You have to do that. You have to go
beyond these walls you're used to working within. OK, time, so it's an essential
metric for lean improvement. And there are different
ways to measure time. There are different
kinds of time, and we're going to go through
these different times. There's wait time, processing
time, cycle time, and lead time or customer demand time. And different organizations
have different definitions. There's not universal
definitions for these things. So if you're in a group,
agree on your terminology, and we'll see this in a minute. So the important
thing is you're all using the same mental concept
for the words you're using. And it may not be exactly
what you see here. If you go to work
at an internship somewhere this
summer, make sure when they talk about cycle
time, ask them, OK, what's your definition
of cycle time? You'll probably find out
nobody can give it to you. [CHUCKLES] But ask them. OK, so we'll give you the ones. Wait time. Wait time is the time that
there's work in process. Something's going through. A job's going through
this value stream, and it's called work in process. And wait time is it's
just sitting idle. Nothing's happening to
the-- it's in a queue. It's in storage or
some other place. And so sometimes these are
some other names that are-- we'll use the word wait
time, but some other names that other places might use
are queue time or delay time. So if we have a
typical process here, it's not unusual to
find a lot of time, things are just waiting
to be worked on. Then processing time
is when you're actually doing something. So it's time that activities
are being performed on that work in process. And it may consist of value
added time and non-value added time in the color code
we talked about before. So that's processing
time, and here are some other names
that people use, touch time, in process
time, response time. OK, and then cycle time. Now cycle time's
the time it takes to actually execute those
activities in a process from beginning to end. And you have to define what the
boundaries of your process are. So cycle time is the
boundaries of your process. So it may be a single task. You may talk about what the
cycle time of my single task is, or a group of tasks, or
a single process or a group or processes. So you have to talk about the
cycle time to do something, and it includes the processing
time and the wait time. And here's some other names. So in this particular
diagram, the end to end time is the cycle time. We have wait time, non-value
added processing time, and value added processing time. Your sheet that I gave you,
the sheet for your exercise, has a bunch of times here. Now a caution is these times
are calculated differently. Sometimes it's a caution. Sometimes it's the
time to cook a hot dog, and sometimes it's
time to fill in order. How many hot dogs are
in the average order? Two. So you have to convert all these
times to the time per order. The right hand column is
time to complete an order. And now I'm going to ask you,
since we're short of time, I want the first thing is for
you guys to decide on a process by how you're going to
do this calculation, because otherwise,
it'll take us too long. So you got six to seven
people at a table. So maybe you can
allocate some results-- allocate some activities. So here's one way. You might have one
member who's just going to write their
answers on the flip chart. You might divide up
the work here and say, give one person to
calculate the time per order for the first two things
and for the other person, for the next two things. This is additive. They can be done independently. And then you got to add them
all up for what the total cycle time is. So first thing
I'd like you to do is just to agree on
the process you're going to use at your table
to do this calculation. Then do the calculation,
and then we'll give you your answers. And then we're going to stop
and get ready for our trip. Do we have a total time? AUDIENCE: 340. EARLL MURMAN: 340. OK. You guys have a total time? AUDIENCE: 420. EARLL MURMAN: 420. OK. Good. Hey, first of all, I want to
congratulate you doing that under a time constraint. I'm going to hand out the
instructors' solution, which came out 446, so-- OK. Now let me say the
process map, there's nothing particularly
unique about this drawing. It could be done
somewhat different ways. We'll get to it in a slide
coming up a little bit later, so let's not look at that. But let's look at the
cycle time calculations, which is this sheet here. So before we left and went
and saw that great New Balance tour, we came up with these
cycle time calculations. So you can see, and the
instructors came up with 446. So let's just look at where some
of those variations might be. So the first one on step
one is taking the order. 60 seconds spent per customer. So time per order is 60 seconds. That's pretty straightforward. And then Sasha takes the orders
and puts it on Andy's board. It sits there for 30 seconds. So that's another 30 seconds. Then the time spent to
produce the cooked hot dog is 50 seconds, and the
average order is two hot dogs. So we came out with 110 seconds. Then it takes 20 seconds
per dog to put the-- to wrap it and put it in the
container, put the fruit on. So that's 40 seconds,
but now 10% of them are rejected and have
to go back through that. Excuse me, it was
back up 110 seconds. I missed that. That's right. So step three is 50
seconds to cook a hot dog. Two hot dogs, 100 seconds,
but then there's 10% reject. So we added a 10%
penalty on there, and the same with step four. 20 seconds per hot dog, two hot
dogs per order is 40 seconds. 10% penalty is 44. Same-- and then we
got to check and see if the order's complete. That's 10 seconds per dog. See if it has fruit
on it and so on. So that's 22 seconds. It sits 30 seconds on the
counter, but 10% of them go through that a second time. So that's 33. Sasha does a final check. Again, she's got to check
that, and 10% are rejected. That's 11. So now we're past
the rejection state. On step eight, Sasha adds the
beverage, 10 seconds per order. Sasha delivers it to the
customer, chats it up a bit. That's 30 seconds. And then we got this extra
work that isn't done in cycle. It's done in parallel, as the
south west team said there. 10 minutes per hour,
and there are-- I've forgotten how many orders
there are per hour right now, but anyway, it works out
to 48 seconds per order. So the instructors came
up with 446 seconds. You could do it maybe a little
bit differently, but certainly, particularly steps 10
and 11, you might not know how to account for those. But that's what we came up with. So let's use that as a baseline. OK, so that completes
that exercise. Now the rest of this lecture,
you're going to see-- we heard a lot of it while
we were up in Lawrence at New Balance shoes. But let's keep going. So we talked about value. We heard about
value streams, boy. Now they-- here's the
interesting thing, New Balance, they've organized
themselves by value streams. They don't even talk
about departments or function anymore. We got this value stream
and that value stream. And I've heard that in
other organizations, too, that they're
organized by value streams. So it's kind of an
organizational principle. AUDIENCE: I think you
told me they have five. EARLL MURMAN: Five
value streams. AUDIENCE: Yeah. EARLL MURMAN: Yeah. So we're now on flow. And we're on these-- just to
back up here a second, we're looking at cycle time, process
wait times over time, process and wait time, cycle time. A lot of organizations
will map out these, what are called
time value charts, actually map out for
a particular value stream what all these times
are and go measure them. And now people walk around
with stopwatches and actually measure, how much time
is it taking to do this? How much time is it
sitting in inventory? How much time is it waiting
for somebody to approve? And you make these time value
charts and map it all out. And it's not unusual to see this
much red on a time value chart, that nothing of any value
is being done to whatever's going through the value stream. So Al, I don't-- I heard some things in the
early days of aerospace that there'd be some component
going onto an aircraft, and it would be, 5% of it's
time was there any value added activity going onto it. 95% of the time it was sitting
on some dock or some pallet. AUDIENCE: The two
biggest wastes we always talk about were move and queue,
the extra transportation time that we really didn't need
because the stuff wasn't where it was supposed to
be, and the queue time waiting for a mechanic to be
able to start doing something. And the mechanic
had to make sure he had the tools, the
instructions, and the paper-- the paper, the
part, and the tools. EARLL MURMAN: Yeah. So that's where
you want to start. What you want to do
is get rid of that. As I said before, when
we went to New Balance, we're not talking about making
the people work twice as fast. That's not where the payoff is. The people are probably
working pretty good already. What you want to do is get
rid of these activities that just are not
contributing to anything. So the big cycle
time savings come from reducing the wait time
and the non-value added time. OK, some tools. Kitting, now we didn't
see this up at New Balance because they weren't
really doing assembly. This comes in more when you're
doing assembly, when you're getting parts from different
locations that have either been bought from suppliers
or manufactured before you get to final assembly. But it's typical in assembly
that you get a bunch of parts in and you got to
put them together. And one of the lean
tools is to kit those. Put all those parts needed
for one item, whatever it is-- in aerospace, you'd
use to call it a ship set, but
could be anything. Put all those in a kit. And the kit is often
made out of Styrofoam, and it has the shapes
cut out for the parts, and the wrenches that go
with it might be right there. Everything you need to install
comes to you in one package. AUDIENCE: And instructions
are right there, too, on the top left corner. EARLL MURMAN: Yeah. Yeah, the instructions, work
instructions are right up here. And so the person doing
the final assembly doesn't have to run
all around and collect all this information
and get it in one place. This is a huge savings. And often suppliers will
deliver things in the kits. It's going to come right
to the factory in the kits. And we didn't see
that at New Balance because they really weren't
doing final assembly so much. Mistake proofing. Another way to enable flow
is to eliminate mistakes. Mistake proofing is
just designing things so it's impossible
to make a mistake. Mistakes happen. I can tell you that from
firsthand experience last week at my house. OK, so you get to flow. Then next thing you
want, to get to pull. We heard that up at New
Balance, was customer pull. So no one produces
a good or service until someone
downstream requested it. There actually was a great
question that came up-- I don't remember who answered
it-- in the final session to Claudio. Do you ever find out you've
produced more than you need? And he says, yeah,
and we stop until we need that, because that's not
being pulled by the customer. So that goes into inventory. Stuff staying in the
inventory costs you money. You have to put it in. You have to take it out. You have to rent
the space for it. And oh, by the way, while
it's staying in inventory, it's getting obsolete. So you don't want to do that. So you want to respond to pull. And so the ideal system is
almost what we heard there, the customer goes into
the store and says, I'd like a pair of
these New Balance shoes. The store calls up New Balance. New Balance says, we'll
make them tomorrow, and they send them out. I mean, that's almost
the ideal situation. And-- yeah. AUDIENCE: What happens when
you have an unanticipated surge in demand? And I mean, OK, with
shoes, you can produce them the next day, but larger
systems, you can't, so. EARLL MURMAN:
Well, you're right. So you have to figure out,
what is your surge capacity? How much excess capacity
do you have in the system to meet that surge? You probably have enough to meet
5% or 10%, but if you get 50%, then you're going to
have to add more lines. [INAUDIBLE], for example. AUDIENCE: Yeah, well, the MRAP,
these new armored vehicles to replace the Hummers, I
mean, there's a huge demand, and the numbers
keep fluctuating. But they wanted
like 17,000 of them between the Army and
the Marine Corps. They've changed those
numbers, and the Marines are going to cut it down. But they've got like five
contractors now trying to make them. And there's that tremendous
demand, save lives and all that. But their lead
times for forgings, lead time from
machine parts, it just takes so long to do
it, and no matter-- it's one of those
things that we wish we had thought about it earlier. So that's part of it. Sometimes you can't
react to the demand. EARLL MURMAN: But
this last quote's important, is that pull systems
are more agile and responsive because you have to design
them to be that way. So you can't meet
all situations. There's going to be a certain
amount of tension there. But a pull system is
better than a push system where you make as
many as you can and hope somebody's
going to buy them. OK, so here are some things
that, once you get flow, you get to move to pull. OK. Ooh, anybody hear about takt
time up there in Lawrence? OK. OK, balanced work, standard
work, single piece flow, kanban. OK, and then, yeah, I mean, we
heard all those terms up there. And then what we
didn't hear too much was just in time
delivery of all material. But in a pull system,
you want the suppliers who send you the material to
deliver it the day you need it, or the hour you need it, or
whatever your time period is. So Toyota's suppliers are
right outside the Toyota plant, and Toyota doesn't receive
shipments, put them somewhere, and then move them to the
factory to the assembly line. They just receive the
shipment, and they go right to the assembly line. OK, so how do you create the--
well, what's the strategy? You want to think
of the customer and work backwards
through the system to figure out how long
it's going to take you to respond to the customer. If the customer's lead
time, the certain lead time you have with
the customer-- we heard it could be as short
as a day at New Balance. If your cycle time is
less than lead time, then you can meet
the customer demand. If your cycle time is
greater, the cycle time it takes you to produce it's
greater than the lead time, then you're going to need
some kind of inventory or buffer to meet
customer demand. OK, this is-- I should
let Al do this slide. If I do it injustice, tell me. This is Al's slide, actually. But Dell computers is the
classic example of this. You call them up,
place an order, and when they get the
order, the suppliers know immediately you
ordered a-- and by the way, you give them the money with
your credit card number. So they're making
the computer, not on money they borrow
from the bank, but on the money
you've given them. The suppliers are online. They know right away. They start working
on the computer, and it's shipped in a day. So Dell was a great pull system. OK, this takt time
we heard, what is it? Takt time, it comes
from the German word for, I think it was
like the metronome. AUDIENCE: Yeah, and like
tachometer with the-- EARLL MURMAN: Yeah. OK, so it's like a
drumbeat for the process. So what it is is the time
that you have available, say a day, and the customer
demand for your shipment. And that means you got to make
one of those every takt time to meet the customer demand. OK, so let's work
through the example. AUDIENCE: Yeah, just while
you're talking about that, I mean, I'll give
you a real example. You've heard me refer to
the Apache for the Army. And when we were
at peak production, we had 21 production
days in a month. If you take 30 days and
you take the weekends out, it's like 21 days in a month. And the army wanted 144
year, which is 12 a month. So that says, every 21
days, we had to produce 12, and that says that we had to
produce one every 1.75 days. And that Apache line
moved every 1.75 days. That's it. EARLL MURMAN: OK, so
that's a good example. And so here is just
another example. 235 days a year, 40 orders. The takt time is 235
divided by 40, 6 days. OK, so for our hot dog
stand, for 50 customers, what's our takt time? Well, 50 customers in a day. So what's the time in the day? We got how many hours? Four hours, times how
many minutes per hour? 60. OK, so that's 240 minutes. 50 customers. So that works out
to be 4.8 minutes. We have to hit a takt time
of 4.8 minutes per hot dog. That's not-- if you can't cook
a hot dog in five minutes, you're not going to be
in business too long, OK. But now if we go
up to 75 customers, then it's going to be the same. This is for 50. For 75, it's going to be 240-- oops-- divided by 75. So that means we got to get to
takt time down to 3.2 minutes. OK, now what's our cycle time? Our cycle time is 446 seconds. So oh, OK, 7.43 minutes. So let's come back. We'll come back to that in the
next module and look at that. But our cycle time right now
is longer than our takt time, but we have two people working. So if we work that
through, we'll find out we can meet the customer demand. OK, one of the ways to get a
pull is to have balanced work. We heard that up in Lawrence. So if we're going to have
a cycle time of 30 days but we have to deliver something
in six days, what do we do? Well, we want to have a
sequence of six-day operations. And so everything
every six days moves, and once we start the
system, that every six days, something comes out. And what we do is we
have balanced everything, balanced work. Everything is taking six
days to do so we can all run to the drumbeat. And we heard that
up at Lawrence, where they said that,
at least on the tour I was on, that they had
added some work at one of the workstations so
they had balanced work across the workstations. So you noticed they were all
moving at about the same time. OK, that's balanced work. So you want to balance
the work amongst the different operations to
all operate at the takt time. Standard work, one way to
do that is to get everything down to a standard process
so that there's not a variation from operator
to operator or from line to line so that everything's
operating at the same level. OK, and that gives
you repeatability. And then single piece
flow, this we heard much more about up there than
I want to describe here. But the idea is they've
reorganized themselves from doing a bunch
of batch processes, of making a lot of components
and then just piling them up, to having them all in
those U-shaped cells. And you get single piece flow. And one of the big advantages
of that is if there's a mistake, you find it right away
rather than create a whole batch of parts and
then finding the next day they're all wrong and
you have to throw them out and redo them. In single piece flow, you
find out in the next operation that there's something gone
amiss with that process, that production system, or maybe
the machine's out of balance, or the worker's not
feeling well or whatever. You find out right away, and so
you avoid the scrap and rework. AUDIENCE: Got a question. EARLL MURMAN: Yeah. AUDIENCE: Isn't there
a compromise, though, going to single piece flow? Because if they were making
a different color shoe ever every single piece,
they'd have to constantly be changing the color of the
thread and sewing machines and that sort of thing. So isn't there a
compromise in terms of types of retooling you have
to do, the lower and lower? [INAUDIBLE]? EARLL MURMAN: Yeah, one of
the things you want to do is get the change very quickly,
so you could change quickly between the two threads. So if you got to use
different color threads for different shoes, if you
could make that change very quickly, then it's OK. If you can't make
it quickly, then you can't do that single piece flow. So this led to-- this was a
big breakthrough at Toyota where they did what they called
single minute exchange of die, wasn't it? AUDIENCE: Yeah. EARLL MURMAN: Yeah. Where they could change
out the die shape in the stamping machine
in one minute so they could respond to
that type of change. AUDIENCE: At New Balance
there, in answer to a question, they said that it was a
big deal, multi-hour thing to change the model
of shoe, but they could change out the size
of shoe very quickly. EARLL MURMAN: Yeah. AUDIENCE: Just a couple minutes. So [INAUDIBLE]. EARLL MURMAN: OK, we heard
about kanban, I mean, and we saw this up there. We have a need for a part. That part's at a, what we
call in this particular case, a supermarket. It's not always this
way, but supermarket. Take the part out,
and then whoever is supplying those
parts will say, oh, we have an empty shelf
in the supermarket. We'll put those parts back in. And that's a kanban system. There are other kinds
of kanban systems, but they all follow the
same basic principle that the production or
supply of a component is done in response to the
demand of the next station in the sequence down the
line so that you're always pulling things through. Now what's the opposite of that? The opposite of that
is you do a forecast. You say, I'm going to need
so many parts in March and so many parts in April. And then you order them, and
maybe you get some discounts because you order big parts. They all show up in April,
and you don't need them. OK, and so that's
the opposite system, and that's usually not very-- that's usually very wasteful. Visual control. Another thing for pull
is make things visible. We saw that up in Lawrence
with the goals for the day and the boards and so on. Make things visible so
everybody can understand what the situation is. And a particular
instance of that is called an andon light,
which is a group of lights that indicate whether the process,
that current process, that activity on the production
line, is performing well or is getting out of whack. And we didn't see this up
there too much at New Balance because everything
was going smoothly. But there were some lights
up there if you looked. And typically what you
see in a lean factory is red, yellow, green lights. If everything's going
smoothly, everything's green. And you can look out-- you can
look across the whole factory and see everything's
going through. As soon as there's a
problem, if it's just going to be a little problem
and not a serious problem, you pull the yellow
light, and somebody comes, the supervisor comes or
the flow coordinator, whoever it was--
they called it flow coordinator up there-- will
come and say, do you some help? What's happening? You say, yeah, my machine's
getting out of whack, or I'm running out of
thread, or whatever. And then if it really gets
serious, it becomes red. And when it's a red light,
the production line stops. And when the
production line stops-- and at Toyota, one of the big
things that came out of Toyota was every worker can stop
the whole production line. And somebody comes and helps
them, figures out what's wrong, gets it fixed, and gets the
production line running. And usually what happens
is, once you set up this kind of system, you
don't have much stoppage because you respond ahead of
time with the yellow light or make sure that
things are working OK. OK, lastly is to
pursue perfection. And this is just the process
of continuous improvement. So you just want to continually
look for waste reduction. Make sure that
everybody can see what's going on so that they can
bring their suggestions forward to continuously
improve the system. And I think George
mentioned the five whys. Or maybe Claudio did. I think it was Claudio who
mentioned the five whys. Five whys is, when
you ask somebody, why isn't something working,
whatever the answer they give you, you say, well, why
is that, and why is that, and why is that? You just try to get
back to what the root cause is, not the first apparent
cause, but the root cause. And so this is the example
that people use a lot. So why is the Jefferson
Monument deteriorating? It gets washed too much. Say, so why does it
get washed too much? Well, it always has
bird droppings on it. So why does it have
bird droppings on it? Because the birds
come to the monument to feed on the spiders. You go, well, why do they
come feed on the spiders? Because the spiders are
feeding on the gnats. And why are the gnats there? Because the lights are
left on all the time. So the reason the Jefferson
Monument's deteriorating is because the lights
are left on all the time. So this is an example
of a five whys. It's called root cause analysis. Just keep-- in average, if you
ask at least five questions, you'll get to what
the root cause is, why something's happening. And that's part of the
pursuit of perfection. OK, so these are some
of the lean concepts we introduced so far. Most of these we saw up
on-- we didn't see this one at Lawrence, but they
had eight types of waste. And I didn't see the board
there on our tour that showed the eight wastes, but
he mentioned [INAUDIBLE] wast. AUDIENCE: Yeah, and that
was very good, a pictorial. EARLL MURMAN: OK. They've added one [INAUDIBLE]. AUDIENCE: The eighth
was very interesting. It was associate creativity. Yeah. EARLL MURMAN: What as it? AUDIENCE: Associate creativity. AUDIENCE: Employee creativity. EARLL MURMAN: Oh,
too much creativity? AUDIENCE: No, no. EARLL MURMAN: [LAUGHS] No? AUDIENCE: Waste of that. EARLL MURMAN: OK. The waste of associate
creativity, OK. Yeah, so that was a new one. But pretty much the rest
of these we saw up there. OK, so I think we'll
just wrap up here.
