Integrating Lean and DFSS
in Product Development
A Lean Master Case Study
By
Cliff Fiore
Integrating Lean and DFSS in Product Development
1.0 Introduction
A key tenet of lean is the elimination of waste. To identify waste, lean practitioners
employ a tactic of analyzing a process from the perspective of the “thing” going through
the process. In a manufacturing environment, the thing is the product that is being
created. So, in terms of identifying waste, this is a fairly straight-forward proposition.
By following the product, one can identify non-value-added activities, such as
transportation as the product is moved from one machine to the next, or waiting in the
form of high levels of work-in-process (WIP) inventory scattered across the factory floor.
If we consider non-factory processes like product development, identification of the
thing going through the process is more abstract. With administrative processes, the
thing is not a physical product that we can see or touch, but rather information. In the
case of product development, this information is in the form of the product definition,
and is captured in a blueprint, which is typically the output of the process. This is an
important consideration, because in order to eliminate waste, we need to be able to
recognize how information is being created, gathered, and used in the context of the
process.
2.0 Lean Principles
The philosophy of lean is underpinned by 5 principles. These well-documented
principles embody the objectives of lean and for many companies, supported the initial
deployments of lean, primarily in the manufacturing arena. However, as companies
began to extend lean applications beyond the factory floor and into administrative areas,
the consideration of information as the thing going through the process added a new
dimension to the traditional lean principles.
2.1 Lean Principles for Product Development
As noted with product development, activities are centered on the product definition. As
a design matures through the process, this information becomes more detailed and
specific. Consequently, consideration in the use and creation of information to support
the product definition was the key theme in introducing three lean principles for product
development. These principles are offered not as a replacement for the traditional 5
principles, but rather as an extension of the original principles tailored to meet the needs
of product development.
2
Work on what’s important means picking projects with high value that align with the
core competencies of the business. In addition, it means establishing clear
requirements in terms of customer needs, aligning those requirements with the
company’s known capabilities, and insuring the technology is mature and matches the
needs of the product.
Concentrate the work means performing work in the shortest time possible with
minimal hand-offs between individuals. This is accomplished by matching work demand
with resource capacity, and minimizing multitasking. It also deals with human issues
related to proper staffing of projects with adequate and capable resources.
Reuse knowledge means to leverage the company’s existing product portfolio, product
knowledge, and technical skill base in support of new product design. It means using
appropriate levels of expertise, learning as much as you can, and capturing the
knowledge you have.
3.0 Product Line Challenges
The Pneumatic Controls product line is based in Tempe, Arizona. Pneumatic valves are
used for a variety of different purposes in an aircraft. Honeywell has a long history in
developing valves and has been a market leader in this industry for 30+ years. The
technology for this product line is well-established and used by many companies.
As market leader, Honeywell had a successful track record in winning a high
percentage of new business opportunities. However, this position began to change
during the early 2000 timeframe. A sustained trend in losing bid proposals caused
3
Honeywell to re-assess the business climate. Customers indicated they were satisfied
with the technological aspects of Honeywell products, but the cost of these products
was too high, and it took Honeywell too long to bring the products to market.
Essentially, in the eyes of the customer, a pneumatic valve product had turned into a
commodity. Unlike the past, customers were no longer willing to pay for any
technological advantage for a product of this type. Instead, they wanted a basic
pneumatic valve product that met their needs, at the lowest cost, and in the shortest
time possible.
3.1 Identifying the Problem
In response to the customer feedback, Honeywell launched a lean project to address
the issues. Building on the success of applying lean in the factory, this represented one
of the first opportunities to apply lean in an administrative process, and specifically
product development.
The effort was initiated by conducting a lean baseline event. A major finding from this
activity was the method that was used for leveraging existing product knowledge:
As noted previously, Honeywell had a long history in developing pneumatic valve
products. Consequently, the company had a large existing product portfolio,
representing products it had developed over a long period of time. Due to the breadth
of this portfolio, nearly every customer request for new product resulted in a derivative
design (a new product with closely matching requirements) to something already in the
portfolio. Given this condition, the product line had adopted the following approach for
designing pneumatic valves:
The Pneumatic Controls design strategy for a new product was to find an existing
design in the product portfolio that closely matched the customer requirements
(i.e. a “similar to” product), and use this design as the baseline for developing the
new product with the lowest cost in the shortest time possible.
Given the existing portfolio, this was an extremely viable and appropriate strategy, but
the lean baseline event discovered a flaw in the product line’s execution of this strategy.
3.2 Impact on the Design Process
Historically, when a product development team would complete the design for a new
product, the team would release the set of blueprints, and the team would disband and
go on to the next project. There was never any activity to capture the product data for
the just-completed design for future applications. The existing design would go into a
“black hole” with no visibility within the organization except for the memories of the
individuals who worked on the project. The consequence of this situation was profound.
4
When a new product development team would be formed and attempt to execute the
design strategy in finding a baseline product for a new design, the process was ad-hoc
at best. With no infrastructure in place to access the existing product portfolio, team
members were resigned to asking colleagues if they knew of a good product match, rely
on their past project experiences, or in desperate situations, go look at parts in the
factory in an attempt to find a product match.
Using this approach, identification of the baseline product nearly always resulted in a
poor selection. This had a significant impact on the design process, and in particular,
on the development cycle time for the product. This also had a major impact on product
cost. An incompatible baseline selection resulted in a proliferation of component parts
(this is illustrated in the graphic below):
To clarify, the mismatched baseline selection resulted in the creation of many new
component parts, whereas a closely matched baseline product would afford the
opportunity to reuse the designs of existing components and circumvent the need to
create new ones. Compounding the problem, newly designed parts were typically
purchased in lower volumes than existing parts, resulting in higher part cost.
4.0 The Solution to Support the Reuse Principle
The inability to find a compatible baseline product relates directly to the third product
development principle of reusing knowledge. In response to this issue, the product line
initiated a project to comprehensively catalog the data for the products and component
parts in its portfolio. This was accomplished using a four-step process:
5
Attributes represent dimensional features of a part, material designations, or
performance characteristics. The overriding criteria for identifying the attributes for each
family was determining what information was important for a product development team
to know, in order to determine if an existing part design could be used in a new product
application. Typically, 10-15 attributes were identified for each part family.
The last step in the process, loading the data in a database, was a critical element to
insure success for the future in leveraging the existing product data to support the
design strategy. An example search screen of the database for one part family
(Butterfly Plates) is shown below:
As shown in the screen shot, a subset of the cataloged attributes was selected to build
the search screen. Once selections were made and the user executed the query, the
database provided a report that displayed part numbers, and the cataloged data for
each part, that matched the search criteria.
6
5.0 Influence of the Product Architecture
Examination of the value stream during the lean baseline event uncovered a secondary
issue:
A typical pneumatic valve contains approximately 120 individual components. When
the product development team would create the assembly drawing for the product, the
bill-of-material (BOM) would simply list all 120 individual components on the drawing.
This resulted in a single-level, flat structure for the BOM as shown below:
Historically, the engineering team viewed a pneumatic valve assembly as nothing more
than a “bag of parts”, and the BOM structure on the assembly drawing reflected this
philosophy. During the review of the value stream, however, it was discovered that the
manufacturing team did not share this same perspective. When the product was
assembled in the factory, the technicians would first put together groupings of parts to
create a series of sub-assemblies, and then the sub-assemblies (or modules) were put
together to create the finished product. This was a significant revelation for the
engineering team. The team realized that if it could replicate the manufacturing
approach of creating and reusing modules, it could further reduce the cycle time and
cost for developing products.
5.1 Adoption of the Modular Design Approach
In response to this, the engineering team launched an improvement activity to create a
series of modules to support pneumatic valve design. This resulted in the adoption by
the product line of a new approach for designing pneumatic valves, referred to as the
modular design approach. This action represented a fundamental change in the
product architecture for a pneumatic valve.
7
5.2 Business Impact of Modules
The introduction of modules had a significant business impact, as illustrated by the
regulator module:
With the traditional design approach, the product line had created over time,
approximately 400 different versions of regulators. After analyzing the functional
requirements, it was determined that a family of 9 regulator modules could replace the
400 versions previously created. This was a clear illustration of the continued failures
by the product line to leverage the existing product portfolio effectively – as well as the
failure to adopt the third product development principle (reusing knowledge).
The 9 regulator modules provided the benefit of dramatically reducing the total number
of component parts needed to be maintained, as shown in the graphic below:
8
The following benefits were also realized from the introduction of the regulator module:
•
A 58% cost reduction* was achieved by procuring the fully-assembled module
from one supplier, as opposed to procuring individual components from multiple
suppliers and performing an in-house assembly. (*Regulator unit cost reduced
from $210 to $90; based on yearly usage, over $1M annual cost savings)
•
40 hours of design time was eliminated. Going forward, designers would simply
select an appropriate design to use from among the 9 available module
configurations. There was no longer a need for designing a regulator as part of a
new product design.
•
A 15% in-house rejection rate was eliminated for regulator leakage. As part of
developing the module, a requirement to perform a leakage test was included
and performed by the supplier. This eliminated all in-house failures Honeywell
was previously experiencing.
5.3 Modification to the Product Bill-of-Material
The use of modules also impacted the structure of the bill-of-material on the assembly
drawing. As opposed to the flat structure for the BOM previously employed, the
modular design approach introduced a multi-level BOM with many fewer parts. This
resulted in a BOM structure that mirrored the way the product was assembled in the
factory (see graphic below):
6.0 Design for Six Sigma (DFSS) Tie-In
Improvements initiated in the product development arena can influence other
downstream processes in the value stream. This is further exemplified by the additional
activities that took place within the Pneumatic Controls product line:
As a result of collecting product data structured around part families, the Pneumatic
Controls product line was able to work with the Integrated Supply Chain (ISC)
organization and select key partnering suppliers to manufacture the all of the parts for
the entire family. This positioned suppliers for success by providing them with
groupings of parts with similar configurations that enabled them to utilize common
9
tooling, standardize the manufacturing process, and ultimately create lean
manufacturing cells. This was done for multiple part families for the Pneumatic Controls
product line, resulting in cost savings between 15-20% of the aggregate spend per
family, equating to annual part cost savings of over $1M/year (first year: $1.6M
savings). This approach, of grouping common parts together in packages to support
supplier selections, proved to be far superior to the old approach of selecting suppliers
on a part-by-part basis.
With key suppliers selected, it was then feasible for Honeywell to work with these
supplies and institute quality control efforts focused on process control. Prior to
selecting partnering suppliers, the supply base was simply too large for Honeywell
resources to be engaged in to adequately support this activity.
Statistical process control (SPC) data was gathered from the supplier’s process control
programs and used as the basis for assessing each supplier’s process capability. This
information became the cornerstone for improving product quality and supporting the
product line’s Design for Six Sigma (DFSS) activities. Design for Six Sigma
represented the enabler for the product line in producing new, high-quality designs.
This sequence of activities is summarized in the graphic below:
7.0 Complementary Nature of Lean and Six Sigma
Successful adoption of the lean principles can have a profound business impact for
Honeywell. For the Pneumatic Controls product line, as a result of employing the
modular design approach and building the infrastructure to leverage the existing product
portfolio to support reuse, the overall product development cycle time was reduced by
over 30 percent (average development time was reduced from 36 weeks to 24 weeks).
10
The complementary nature of six sigma adds a powerful element for improving product
quality and producing high-quality designs. As demonstrated by the Pneumatic
Controls product line, using lean and six sigma together can make a significant
business impact on reducing cycle time, product cost, and quality defects.
8.0 Obtaining Team Member Buy-In
Introducing the new product architecture to the team represented a significant change in
designing a pneumatic valve. In the case, the key element that facilitated the
successful implementation with team members was the database tool described above.
The tool was the cornerstone of implementing the reuse philosophy. The key reason for
its success is that it made team member’s jobs easier. As described earlier, the old
approach of finding a baseline product was an ad hoc process at best. Now, team
members merely had to access the database and run a series of queries. Not only was
it faster than the old approach, but it provided the most comprehensive and complete
assessment for finding a baseline product match.
Team member’s saw the value in this, willingly used the tool, and embraced the new
design approach. The power in providing a solution that not only resulted in a more
streamlined process, but also improved worker efficiency, proved to be a winning
combination for success.
11