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.
ANNALISA WEIGEL: So if I can have your attention please,
we are going to break from our simulation for just a moment
to talk about our next module, called Lean Engineering Basics.
There are two key takeaways that we'd
like you to get from this module,
and they're worth reiterating and I
will say them several times during the course
of the module.
The first thing we want you to internalize
is that lean thinking applies to engineering just as much as it
applies to factory processes.
And two, that engineering plays a critical role
in creating value in lean enterprise.
And our presentation today is broken down
along those two lines.
And I'm going to start talking about why lean thinking applies
to our engineering processes.
Here are our learning objectives for this module.
They are five-fold.
So at the end, you should be able to explain
how our lean principles and practices apply to engineering.
You should be able to explain why
customer value and this upfront part of engineering
and the conceptual design are critical to product success.
You should be able to describe how lean engineering enables
lean throughout the whole enterprise and the product
lifecycle.
Fourth, you should be able to describe some tools we
use for lean engineering.
And lastly, you should be able to apply lean engineering
techniques to redesign your simulated airplane.
So we'll spend the first half of this module talking concepts.
And we'll spend the second half of this module
in an active learning exercise, trying
to apply some of the things we learned
to the redesign of your simulated airplane.
A few days ago, we had a question
about wastes in engineering compared
to wastes in the factory.
And this chart is actually the answer to that question.
We did say we'd defer it a few days,
and now we're going to tackle it.
So here are five lean thinking steps
we talked about in the first day, what
they mean for the manufacturing process, and then lastly,
how we translate those over into engineering.
Now, one of the challenges we've had
in applying lean to engineering has
been a reaction from the engineering group that says,
well, you know, you can apply lean in the factory,
but engineering is just different.
You can't really apply it here.
And yes, of course, engineering is different than the factory
operations.
But that doesn't mean that these lean principles-- which
are very universal, and you've seen
applied across the enterprise from office processes
to manufacturing-- why they can't
apply to engineering as well.
The difference, mainly, from manufacturing to engineering,
is a thing that's flowing through the system.
So in a manufacturing context, you
have the raw materials that are flowing through the system,
and being processed and changed.
In engineering, it's really information
that is flowing through the value stream-- that
is being processed and changed.
Your design emerges, uncertainties are reduced,
expectations are clarified, and so on.
These are all examples of the information
that's flowing through your engineering value stream.
So for manufacturing, the addition of value at any step
is pretty visible.
We told you that you have to look and see
if a thing is physically changed to add value.
And you can usually see that as your material gets processed.
This is a little bit harder to see in engineering.
When you change part of your design
or when you do an analysis, it's not
quite as easy to see that you've change the information.
But you usually have.
The second contrast in that manufacturing, your goal
is very defined.
When you start manufacturing, you
have a very specific set of specs and drawings.
And at the end, you expect to come out
with exactly the product that you wanted to when you started
the manufacturing process.
Now this is different than engineering,
because in engineering our goal is emergent.
We have some sense that there are requirements,
and we have maybe some notion of how we might meet those.
But the whole process of engineering and design
is to look at different alternatives
and to then come up with a set of specifications for product
that you can build.
So your goal is really emergent in that sense.
Now, we go down to the value stream.
You can do a value stream map for information
just like you can for material flow.
The one difference is what's actually flowing through that.
Now, if we move on to our concept of flow, which
is trying to make everything seamlessly go,
in manufacturing, iterations are usually considered waste.
They're indicative of rework in the process,
or a process or design that wasn't spec'd right up front.
But in engineering, as you all probably
recognize, mostly being engineering students,
iterations are OK.
We plan to do these.
And that's a key word there is that planned iterations are
good.
We recognize that going through analysis,
and looking at problems, and looking them
again is important.
The key there is that you want your planned iterations
to be as efficient as you can.
The fourth concept of pull, which in a manufacturing sense
is driven by tag time, for the engineering processes, that's
usually driven by your enterprise
needs for new products to be developed.
And then, the concept of perfection,
which in a manufacturing context means
processing without repeating errors, how does that
translate into engineering?
We would think of it as engineering processes
that enable your whole enterprise improvement.
And I'm going to expand on that concept in the second half
of the lecture.
Here, we're revisiting our seven wastes that we identified--
over-production, inventory, transportation,
unnecessary movement, waiting, defective outputs,
and over-processing.
So I'd like you all to think back
to your engineering experience, either from classes or maybe
from summer jobs.
And I'd like to hear some examples, in an engineering
context, of any of these seven wastes.
Go ahead, please.
AUDIENCE: So yesterday, at the New Balance factory,
we were on the right side of the factory.
We were talking about how the upper part and the lower
part of the shoe was actually manufactured in China.
But then, they shifted back over here just to essentially glue
the top and bottom parts together so
that they can say, assembled in the United States.
And our group asked if wasn't that a waste in transportation,
the cost, and the time, and all that kind of stuff
just so they could say, assembled in the United States.
And they want-- they felt that it was worth it that they could
just say, you know--
that they put the US logo on it in turn
for having that transportation waste.
ANNALISA WEIGEL: Interesting, OK, so that to me
has some elements of both manufacturing
and the engineering design, and perhaps
some business strategy to it.
Can we try to think of just isolating examples
to the engineering process.
Think about conceptual design.
And let's talk about some examples.
Go ahead.
AUDIENCE: Well, at my internship last summer,
they were talking about how a lot of older people
had really great skills in specific areas.
And they were worried that the older engineers weren't
communicating those skills to the younger engineers.
And so when they left, there would be waste,
because people would have to relearn
that specific engineering skill.
So they created a Boeing Wikipedia,
and were encouraging engineers to type up articles
to try to keep that information that other people needed.
ANNALISA WEIGEL: That's a very interesting example.
Let me ask the class--
these are the seven waste categories.
What do you-- which category do you
feel that example might fit in?
Inventory-- having more material or information than you need?
Any other thoughts?
OK, Earl, you have an important--
AUDIENCE: Just that New Balance, we
heard an eighth waste category, which
was, for their environment, unused associates creativity,
which was sort of a loss of human-- a waste
of human resources.
Would this fall in that category?
ANNALISA WEIGEL: Yeah, to me it falls in eight.
I might also say it perhaps falls in one, if I thought
that I had to produce two engineers,
and the information wasn't officially being
passed between the first one who got the knowledge.
And then, I had to go through the exact same steps
to get the second engineer that same knowledge
without taking any advantages.
But this is one of the interesting examples
of translating largely manufacturing
a material-based instances of waste into engineering, is
that sometimes is a very clear translation.
And sometimes it's a little harder
to figure out where it is.
But I think we can all agree that example that Emily gave,
it's feels like there's something
that's being wasted there in an engineering sense.
A lot of experience--
and engineers' knowledge is very experiential--
is being gathered, and then sort of just
left to go away and not be utilized by the company
anymore.
Let's take another example.
AUDIENCE: I was just wondering, could that
be thought of as over-processing as well,
because you need to kind of do more
from scratch training of the [INAUDIBLE]??
ANNALISA WEIGEL: Yeah, I could take that argument, definitely.
Can you-- go ahead.
AUDIENCE: I guess I may be missing a point.
So I just want to clarify, how does it
help me to solve the problem by classifying it
in one of these seven ways?
For example, if I know what the problem is I'm throwing out
talent, I'm throwing out knowledge
that I've got to then retrain, how can I use these--
sort of this classification-- to help me solve it?
ANNALISA WEIGEL: Sure, what you're doing
is you are standing on the shoulders of giants of people
who spent decades of years, and probably
millions of hours of brainpower, trying to figure this out.
So let's start with this is our analogy.
And then we'll probably create unique categories of waste
that apply to engineering.
But this is a great start, where in absence
of some classification system, you
may spend a lot of time trying to figure out what that is.
So it's really just a creative tool for us
to help understand the parallels to engineering.
AUDIENCE: I think it's more of, like,
finding waste you use these.
If you like looking at your organization,
you would look through this and be, like, oh, OK,
I see this, and this, and this, and it
helps you find new waste instead of just analyzing waste
that you probably [INAUDIBLE].
ANNALISA WEIGEL: Excellent, thank you.
Let's have another example of a waste
that's different than the ones we talked about.
[INAUDIBLE]?
AUDIENCE: Mine would be either waiting
or an unnecessary movement.
I was working with GE Nuclear in California.
And every time we were doing a purchasing order
or test specifications that had to be approved,
it had to be approved in Georgia, which is a three hour
time difference.
Which means that either you have to come to the office at 6:00
in the morning if you're wanting your thing
to be processed right away when they open,
or you have to stay up later at night to finish it.
So everybody was very upset about that.
We were losing six hours in a day of work.
And the tests were being done in Massachusetts.
So the engineers had to fly over there,
spent some time running through the tests
and get the results back.
And it was a waste of time for everyone,
and energy, and other things.
ANNALISA WEIGEL: Great, great, and a good example
of waiting-- waiting is a very common kind of waste,
if you think about information and design that's happening.
How about other examples?
AUDIENCE: I work here at MIT, and the first week, I had
to buy something for a project.
And no one how to buy anything.
Like, my advisor didn't know.
Eventually, they found out that the woman in charge
had just moved, and no one had replaced her.
So I guess it was waiting, or a defective output,
or something like that.
ANNALISA WEIGEL: There's several kinds
of problems with that particular process, yeah.
Unnecessary movement also happens quite frequently
in an engineering sense, as well as transportation.
So if you think about how many times you move information,
change information from the inputs of one analysis program
into a format that's compatible with another analysis program--
think about going back and forth here on campus between MATLAB
and Excel happens frequently.
Now, if you go out into a very complex industry
like aerospace, the tools are far more complex.
And translating the inputs of one of the outputs
to another, and so on, is a large deal.
They're not necessarily made to be compatible.
And then, we heard [INAUDIBLE] talk
about a lot of unnecessary movements
that may happen-- moving people to various places
to test things to get analysis results for your design.
Because sometimes these complex products
are so large and expensive, we can't
afford to have testing facilities locally
to try to minimize that kind of waste.
All right, we're starting to get a sense.
And we'll talk about them further
as we go through the simulation game and the rest
of our module today.
I wanted to point out some data that we
have about the efficiency of engineering processes.
If you have any doubt that there's waste in engineering,
this should help convince you that there
is at least by some informed people.
So this is a measure of effort that's wasted.
40% of the product development effort
was classified as pure waste.
About 30% is necessary waste.
In another survey, we had 30% of product development
time that was charged to just set up and waiting.
You can easily see why those don't add a lot of value
to the customer.
And not only is effort wasted, but time is wasted.
62% of tasks, on average, were idle at any given
time in a survey of particular companies.
And 50% to 90% of task time is found
to be idle in various Kaizen-type events that
are run in an engineering context
at different kinds of companies.
So clearly, lots of room for improvement
here in the process of engineering.
There's been a good body of research done here at MIT.
And they produce the Product Development Value Stream
Mapping manual.
And this is authored by Hugh, who's in the back of the room.
The same basic techniques apply as you might do value stream
mapping in the factory context to the engineering context,
except that the flows are information rather
than physical, and your value added
steps help to transform this knowledge
or to reduce the uncertainty, which is a primary role of why
we do analysis in engineering.
And if you're interested, you can consult this publication.
There's a lot more material here than we
can cover in this module.
But let me give you some real-life examples
of organizations that have applied product development
value stream mapping and had some successes.
So this is an example on the F16.
And they had some particular problems
with what they call their build-to-Package process.
So if, for some reason, they needed
to make changes to the build-to-packages,
like you all have in front of you for your SIM,
there was a big, long process that
actually had to happen from I need a change to,
OK, I can actually make a change.
It numbered a lot of steps.
You can kind of count them all here.
It goes here, and then it goes down there,
and then it goes all the way through there,
and all the way through there before we get out to a change.
So applying some of the tools of value stream mapping,
the F16 build-to-package process was reduced down to something
like this.
So now, we had single-piece flow being
able to go through the system.
We had an allowance for parallel processing of tasks,
rather than single processing of tasks.
Concurrent engineering principles
were brought in to help achieve this kind of leanness
in process, as well as co-location
of all the various different units between design,
and manufacturing, and quality that
needed to be co-located to accomplish this.
And if you wanted some illustration
of the results that can be achieved,
we have that here in this slide.
So this is actually a picture here
of the build-to-package support center
that resulted from this value stream mapping activity.
It's a facility that's down on the shop floor.
So it's very close to the things that they're trying to change.
They created these kinds of improvements-- in cycle time,
from getting a change request in to having implemented that,
75% reduction of cycle time.
Process steps were reduced by 40%, handoffs by 75%,
and travel distance of the information, and paperwork,
and so on was reduced by 90%.
These are very, very real kinds of savings
that can be achieved in the engineering process
by the application of value stream mapping techniques.
Now, we're going to move on to the second concept
that we'd like you to take away.
And that is that engineering plays a critical role
in creating value in the enterprise.
So we've just seen how we can apply some of our lean thinking
techniques-- including value stream
mapping, the concepts of waste, and so on-- to the process.
But then, there's a really important reason
why we want to lean out the engineering process.
Because it's a key enabler for lean
in the rest of the enterprise.
The reason for that is represented here on this chart.
So we have on the y-axis, essentially,
the percentage of your lifecycle budget
that you might attribute to these.
And here on the x-axis, we have lifecycle phases,
starting from concept development
through detailed design, production use, and disposal.
Here, we show various curves.
So as you go through the engineering design process,
you as engineers are making choices.
You decide to use a particular material.
You decide on a particular design.
That has manufacturing implications, performance
implications, and so on.
And as you make those choices, which
are right here in conceptual design,
you are determining a priori the cost
of that system by your choices.
At the same time as we move through this process,
the leverage that management has to make any changes
starts to go down dramatically, because a lot
of the knowledge and the cost is being committed there.
But as cost is being committed early,
it's really not being incurred by your organization
for a while.
Because you're not buying materials,
you're not bending metal, you're not into the expensive parts.
That starts to happen over here.
But yet, you've already decided it way back here
in conceptual design.
And a similar curve is shown for knowledge.
This is what we know about the design
of the product, the performance, the quality, the use,
the reliability, and so on.
As you start out early in a design,
you just don't know a lot about it.
It's a process of discovery, and analysis, and refinement.
And that knowledge grows as you go further down
in the lifecycle phase.
But it doesn't grow nearly as fast as you're committing cost
to that.
So there's a lot of uncertainties
that exist in the process.
But it's this extreme leverage that we
have up here in concept development
to determine all of the properties of our system
that's so fundamentally important.
And this is why lean thinking needs
to start with engineering.
Because the engineers are making those critical choices
that are going to determine cost, and performance,
and reliability, and safety, and usability, and maintainability,
and so on.
So lean engineering is really about doing the right thing
right.
It's got three components to it.
You first have to create the right products.
You have to do that with effective enterprise
and lifecycle integration.
And you have to use efficient engineering processes.
And we're going to take each of those in turn.
So creating the right product means focusing on the customer.
And to do that, you have to shift some resources up front
to the conceptual design process so that you can spend
enough time to really make the right choices
about the product.
Effective enterprise and lifecycle integration
means that we should use our lean engineering
tools so we can create value throughout the product
lifecycle and enterprise, and being efficient while we do so,
so apply the lean thinking to eliminate waste
and improve the processes of engineering.
So starting out with our first point
about creating the right products,
how do you know what's right?
The customer is the one who specifies that for you.
And generally, when they're thinking about value,
they have got four large elements in mind
that sum up to be their value.
There are some elements of features, and performance,
and quality.
There's some element of schedule and when I can get it.
There's an element of cost that they have to pay for that.
And then there's some element of price--
of what it costs you to make that.
And if you think to any purchase that you make,
you are either consciously or unconsciously balancing
all these parts that equate to value
of a product in your mind.
So you may want a computer that has
a certain kind of performance and price to you.
But if you can't get it for four weeks,
you may decide that that's not really a good value
proposition for you.
And you may choose to set some other combination of attributes
for yourself that really defines value.
Engineering drives the cost of all the products.
So 80% of the product's cost is determined
through the engineering design when these choices are made.
So the number of parts that you have,
every part costs some money.
Parts have to be inventoried.
Parts have to be designed.
Parts have to be transported, they have to be maintained,
they have to be quality controlled, and so on.
And each of those actions incurs a particular cost, as well as
tolerances on parts.
I'm sure some of you who have gone through engineering
classes have talked about how strict tolerances can really
increase the cost of producing a product.
Whereas if you relax tolerances, you
may get to a slightly lower cost on your parts.
You can think of assembly techniques-- different assembly
techniques cost different amounts of money,
some are much more complex and complicates-- as well as
processes to treat raw materials,
and the tooling approach that you might use, again,
that ranges from cheaper to more expensive.
Materials-- if you want to build something out of titanium,
it's going to cost you differently
than to build it out of other materials.
Avionics and software, design complexity,
whether or not you're reusing previous design efforts--
these all contribute to the product's cost.
And these are choices that the engineer is making.
So this is, yet again, another illustration
of why it's so important to try to make the right choices,
spend the amount of time you need to do that up front.
This is a reflection back to our suppliers talk.
Don't forget suppliers.
They're a critical component of your design
and ensuring that you have the right cost on your system.
Typically, 60% to 80% of value is added by suppliers.
So when you think about the engineering processes,
don't neglect them.
One of the best practices for achieving the engineering
result that you want is to use integrated product and process
development.
It's a concept that utilizes a couple of elements-- first,
the principles of systems engineering
to translate your customer needs into a product architecture
and a set of specifications; using integrated product teams
so that you can bring knowledge from all
the different lifecycle parts into your engineering activity.
Remember, we talked about the cost committed
early on in the engineering activity and the uncertainty
of knowledge.
One way to increase the amount of knowledge you have
is to bring people in from all the different lifecycle phases.
So bring someone in from manufacturing.
Bring someone in from the customer community who uses it.
Bring somebody in from all the different parts
so that you can increase your knowledge as early as you can.
Third, the IPPD approach utilizes modern engineering
tools.
And we're going to give some examples of that
in a few slides.
And it all can't really function unless we've
got the right kind of human resources
on board, which may require a certain skill set
or certain set of people.
So it's not just that you have capable tools,
you need capable processes, and you
need capable people to actually execute this successfully.
So here's a list of some of our tools of lean engineering.
And I'm also going to show a couple of detailed examples
in the next couple of slides.
So we have digital tools that increase
the timing of handoffs, decrease waiting, increase quality.
There are production simulation tools that you can use,
which are much cheaper on a computer
than actually having to go out, and build a physical part,
and try to play around with that.
You can think about common parts and specs
in reusing design, the design for manufacturing assembly,
which we're going to talk about in the context of our planes,
and so on.
All of these are very useful tools for lean engineering.
And to show you that these are being used out in industry,
this is an example from Boeing.
This shows you how they brought together
various different digital tools that went
into producing the hardware.
So they were able to use a CAD program
to do different layouts and three-dimensional
visualizations.
They had a parametric solids modeling tool.
They had some assembly models that were done in 3D CAD.
They electronically release their build-to-packages.
They used a computer to simulate the manufacturing and assembly.
And all this was done with far less cost
than trying to go and build your hardware,
and do all of your playing around in the physical space.
So I'll give you an example of the production simulation.
I need to break a moment and go into my movie.
Let's move on to another tool of lean engineering, that's
common parts and reusing designs.
So if you're using common parts, and you're
reducing the total part count as a result,
you're reducing costs, because every part that you don't have
to design, you don't have to manufacture, and QC, and tag,
and everything.
These are some great illustrations
of trying to use what we call mirror parts.
Do you need to have parts designed differently
for the right hand side and the left hand side?
Could you reconceive your design such
that they used a common part?
And this would then save on the number of unique parts.
Also have to realize that common parts can increase
the quality of your design--
less points of potential failure,
less points of uncertainty, fewer moving
parts in your manufacturing process, less room--
I'm sorry, fewer mistakes to be made
in mistaking one part for another
if I've got all common parts and so on.
So let's talk about part count reduction.
This is largely a goal of what's called design
for manufacturing and assembly.
So I'd like some input from you guys
on why we would reduce part count?
We've covered a lot already, so you can kind of shout them out.
AUDIENCE: Faster assembly.
ANNALISA WEIGEL: Faster assembly.
What else?
AUDIENCE: Easier for your supplier.
ANNALISA WEIGEL: Easier for the supplier.
Thank you, Mr. supplier.
Thank you, that was good.
Yes?
AUDIENCE: Less variation--
ANNALISA WEIGEL: Less variation,
AUDIENCE: --to get tolerance build-ups?
ANNALISA WEIGEL: Yes, indeed.
Does everybody catch that, the concept of tolerance build-ups?
If you're reducing the part count,
each part has a specific tolerance to it.
The more parts you label together,
kind of that-- the bigger that uncertainty
in potential tolerance grows.
If fewer parts, that comes down.
What else?
That is good.
AUDIENCE: Less chance of delivering mistakes?
ANNALISA WEIGEL: Fewer chances to make mistakes,
because every part I handle has some probability that I'm
going to make a mistake with it, and I have a few of those.
Yeah, what else?
AUDIENCE: In many designs, increasing part count
requires increased lubrication.
And oftentimes, joints and things--
the more parts you have, the more
need for lubrication, more work, [INAUDIBLE]..
ANNALISA WEIGEL: Sure, so operational considerations
that you might want to think about.
And what are others?
[INAUDIBLE]?
AUDIENCE: Simplifying the supply chain?
ANNALISA WEIGEL: Simplifying the supply chain, yep.
Others?
Go ahead.
AUDIENCE: Depends on situation, it
could be cheaper [INAUDIBLE].
ANNALISA WEIGEL: Right, yes, it reduces cost.
That's what your boss really wants to hear.
It's going to reduce some cost for the enterprise.
We've covered almost all of these.
They were-- excellent discussion, and some others
that we brought up that aren't quite on this list.
It's important to keep in mind, though,
that sometimes, but not all the time, reducing your part count
would require some performance trades.
So cost and schedule savings may be big,
but you may be trading off a little bit of performance.
And if your customer is OK with that,
then everybody wins in the end.
One particular aspect in aerospace systems
is, of course, mass when you're thinking about that.
And sometimes, going to common parts and fewer parts
can increase mass, which may sort of dictate
a performance ding to the system, but like I said,
not always.
And I think I'll show you an example later on that
demonstrates that really clearly.
So what I want to do now is take you into an active learning
exercise.
And we're going to think about applying these lean engineering
principles and practices to redesigning
your airplane with a goal for part count reduction,
and designing for manufacturing and assembly.
So your first goal is to satisfy the customer.
And the customer has a couple of desires.
They want the mold line of the airplane to remain the same--
exactly the same.
So this is the outer shape.
The customer also requires that the landing gear--
but just the landing gear--
must be brown.
So it comes from a particular kind of material,
and the customer feels that they really
need the strength of that material on the landing gear.
So those have to stay the way they are.
Thirdly, the customer has the desire for in-service quality
to go up.
Right now, the airplane is kind of fragile.
You may have been handling a full airplane
and noticed that the tail section tends
to break off quite easily.
Hugh will demonstrate.
Oh, my goodness.
[LAUGHS] So the wing is also, apparently a fragile part.
It depends on where you hit the airplane.
But for example, I was sitting at the customer
mat at one table.
I took delivery of an aircraft.
And as soon as I grabbed it, the tail section fell off.
This is a real thing.
So perhaps, you can address the customer's desire
for a slightly more robust design.
And fourthly, as we've been talking
about from the beginning, the customer
really wants 12 airplane to be delivered per round.
So they want you to increase the delivery quantities.
You want to think about reducing your manufacturing cost,
because this is good for your enterprise.
So your parts are going to cost $5 per part,
regardless of part.
Less parts then equals more capacity for you.
And thirdly, we want you to incorporate the suppliers.
What kinds of innovations could you
generate by working better with your suppliers?
Could you reduce a part desercity?
What else could you do applying lean engineering principles
in concert with your supplier?
So I'm going to give you about 20 minutes
or so to talk in your teams and redesign your aircraft.
You're going to work with your facilitator.
And you need to demonstrate that it
satisfies all of these criteria for the customer.
[INTERPOSING VOICES]
ANNALISA WEIGEL: All right, everybody take your seats
again, please.
I could tell you're all having fun redesigning your airplanes.
Let me use the next couple of slides
to finish out this module to give you
some motivation for why lean engineering has been helpful
in practice.
I'm going to cite a couple of real world examples here.
The first is an exercise in design for manufacturing
assembly to reduce part counts.
In the latest iteration of the F-18, called
the E/F, the company the builds that
went on a part count reduction exercise
by employing design for manufacturing assembly
techniques.
In each of the major assemblies for the plane,
they went and reduced the part counts
from the C/D version, which was a previous iteration,
to the E/F version.
So in total, we went from having 14,000 plus parts in the C/D
version, to having just over 8,000 parts in the E/F version.
This was a 42% part count reduction.
Now, we talked before about how sometimes, part count
reductions come with sacrifices in performance.
But this was not the case.
So the F-18 E/F version turned out
to be 25% more capable than its previous predecessor.
So this was an excellent win-win situation.
And not only was the customer happier about the increased
performance, they were absolutely delighted
by the lower cost of the plane, because parts that are not
on the plane don't have to be designed,
they don't have to be tooled, they
don't have to be NC programmed, they
don't have to be manufactured or assembled, anything.
They don't have to be stored, they
don't have to be inventoried, they
don't have to be controlled, and they don't have to be scrapped.
And if you have fewer parts, they
don't need to have spare parts for those extra parts as well.
So that reduced maintenance and repair costs.
Question?
AUDIENCE: Does the manufacture necessarily
have to pass on the cost to the consumer [INAUDIBLE],,
because I imagine quite a bit of time and money
goes into R and D to try to get the cost [INAUDIBLE]..
ANNALISA WEIGEL: Yeah, so there certainly
was a lot of engineering costs to redesign the plane.
And there was an interesting arrangement
between this company and the government.
So there was some, if you would call it,
cost-saving sharing or profit sharing that went on.
So the company was incented and rewarded
for keeping costs down.
They didn't have to give all that savings back
to the government.
They didn't get to keep it all either.
But they got to keep enough that it
was an incentive for them to actually meet these objectives.
And at the time, this was somewhat
of a radical way of thinking about government contracting
as well.
And that's not a trivial area to overlook.
Because sometimes, those contracting and legal issues
can keep you from doing what otherwise
might seem very lean to you.
Let's look at another example of how
lean engineering tools helps reduce the manufacturing label.
So what I'm showing you here on the y-axis
is account of manufacturing labor in terms of hours.
And on the x-axis is the number of production units
that we have.
So right here is where the first physical production
unit is made.
This blue line right here shows the labor hours
per production unit before lean engineering processes and tools
were applied.
This curve down here shows the results
after lean engineering processes were applied.
And what happened was that nine units were actually
built virtually before anything got to the manufacturing floor,
such when they did get to the first physical unit
that was produced, the total manufacturing
hours to do that was significantly
less than previously, before learning the lean tools.
And in addition, the sort of steady-state manufacturing
hours required for the same comparable kind of product
was much lower, in the end, than using the non-lean processes.
This is another example of how better engineering
tools help reduce some of the costs associated.
So on the y-axis here, we have a staffing level.
And on the x-axis here, we have months
from the end of the conceptual design phase.
And this just shows the results of the design and IPT
labor that was required for vehicles of comparable sizes.
And what you see is that, as we slowly
introduced different kinds and better of lean engineering
tools, we were able to reduce the staffing level
and shrink the time that was required
to accomplish that milestone.
And lastly, lean engineering enables faster delivery times.
And particularly because spacecraft
have such a slow reputation in the industry,
I thought I'd show you a space example.
This is Iridium, which is a satellite program.
And where it's typical to have 12 to 18 months of cycle
time in the satellite industry, this particular program
accomplished a cycle time with 25 days, which
was just literally unheard of.
And they did it largely through the application
of lean engineering and lean manufacturing practices
to the program.
So just to wrap up, we talked in this module
about lean engineering, and how lean engineering can enable
lean manufacturing, and how working with the supply chain,
all these three things can come together
to create affordability of our products across the enterprise
through the application of lean, by reducing costs per unit
as we go down the assembly line.