|
|
4th Annual Design for Six Sigma Conference
MonteLago Resort, Las Vegas, NV (Workshops: February 9, 2009. Conference: February 10 & 11, 2009) |
   |
| 01/08/2009 |
DFSS Education through University and Industry Partnership
Robert Shemenski, CANMC Engineering, ACE Discipline Chief, PRATT & WHITNEY
Many options exist for delivering DFSS training. Presented here is one option which leverages the strengths of academic education and industry experience. I will also discuss lessons learned from this educational experience and provide useful guidance for developing a DFSS training program.
Rensselaer Polytechnic Institute and Pratt & Whitney have developed a unique educational program that enables working engineers to simultaneously earn Lean Six Sigma Black Belt certification along with a Rensselaer Master of Science (M.S.) in Engineering Science degree. The format is an accelerated 30 credit hour graduate degree with an integrated Lean Six Sigma Black Belt Project. Courses are taught by RPI professors during evening hours and students apply Six Sigma concepts by working real-world projects as part of their day-to-day jobs. Project mentoring is done by an RPI academic advisor who may also be another Pratt & Whitney employee and an RPI alumnus.
Recognizing that many of the students are design engineers, RPI augmented the traditional DMAIC process improvement focus by adding Design for Six Sigma course to the curricula in 2008. The objective of this course is to provide a basic understanding and working knowledge of the DFSS process and the major tools used for the development of new products, processes and services.
A unique aspect of the course is the hands-on design project. The scenario used for this project is an imaginary miniature mechanical golf league seeking an alternative to the commercially available DOE Golfer. This device is considered expensive and difficult to operate.
Working in small teams, students follow the CDOV process to gather customer requirements, design, manufacture, and validate working prototypes of a new product design. During the final class session teams compete using their design prototypes on a miniature golf course set up in the classroom.
The results from the combination of academic education and hands-on experience were innovative and competitive designs and a lot of learning. With nearly 40 hours of in class instruction and nearly the same amount of experiential learning, this academic course could also serve as a model for a corporate DFSS training program. |
| 12/18/2008 |
Integration of Design and DFSS…A Powerful Route to Innovation and Holistic Product Design
Emil Georgiev, Design Research Leader, Global Design, GE Healthcare
Design for Six Sigma (DFSS) and Design have acquired reputations as being at the opposite ends of the spectrum when it comes to Innovation. Design - thinking like a designer (1) is rapidly establishing reputation as a transformational approach that has a potential to change the way products, services, processes or even strategies are being conceived and developed. It brings into focus the human element as an important factor in design by acknowledging that human preferences, behaviors and ability to make errors at a much higher rate then machines or industrial processes play an important role in the design process.
DFSS, while widely acknowledged as a superb methodology for development of new product and services from the perspective of the implementation phase, is considered, somewhat unfairly, as stifling to innovation and too engineering centric. GE Healthcare has a mature Six Sigma organization practicing DFSS and Lean on one hand while its fairly sizable Global Design organization was practicing User Centered Design (UCD) methodology. An effort starting in 2003 to facilitate the communications between Global Design and rest of GE Healthcare through Six Sigma implantation in Global Design resulted over time in the integration of the two methodologies (DFSS and User Centered Design) on two practical levels:
- User Centered Innovation focused on tackling the “fuzzy front end of innovation” that precedes the highly structured new product introduction process and
- Design for Usability - methodology focusing on the design of the User Interface of product and services
Observational research….the missing DFSS chapter
Understanding of customer needs is central for both DFSS as well as User Centered Design. The approaches are however different and, actually, quite complementary. The DFSS toolset associated with the Define step is not especially efficient when it comes down to capturing needs that our customers have difficulties articulating or are not aware of as well as in situations where customer “wants” are being verbalized by customers as “needs”.
The primary UCD method - direct observations (how customers work in their own environment using the products and services we are trying to innovate on), known also as Observational Research, is a powerful approach based on ethnography that fills these gaps.
It not only uncovers the true customer needs (spoken, unspoken and unmet) but also makes them much more easier for a solution provider organization to understand and internalize by putting them in the proper context uncovering also:
• Who are the customers – their roles and responsibilities
• What do they do and why do they do it - customer workflow
• What is the customer environment where products and services are being used
• Are there any safety hazards / product misuse
Intimate understanding of customer needs through Observational Research not only allows for more appropriately targeting of DFSS programs to design the intended products or services (HOW) but is also the foundation for an innovation approach that allows a solutions provider to determine (WHAT) product and services to develop for a given market segment.
User Centered Innovation – the DFSS roots
User Centered Innovation is a methodology that drives focused ideation / solution concept development, based on intimate understanding of customer needs and customer priorities. Understanding of customer needs leverages both Observational Research and the whole toolset offered by DFSS. The approach also borrows the DFSS principle to “Let the data lead us to the right conclusion”, although the term data applies here in a much broader sense to include customer needs and observations. The method consist of 3 principle phases and a post assessment – collection of customer needs from multiple sources, affinitization and prioritization of these needs by customers (another borrowing from DFSS that is usually accomplished using conjoint tools), development of solution ideas and solution concepts to address key needs / business opportunities during the Innovation Workout and disposition of the solution concepts
User Centered Innovation is an approach that generates and relies on significant amounts of data including initial inputs and processed data. The majority of the initial input data comes from observational research and direct customer inputs related to the needs prioritization efforts, The processed data is generated by the innovation team’s efforts to rationalize and affinitize these inputs as well as to develop individual solution ideas and solution concepts generated during the innovation workout.
The approach also incorporates significant elements of Karen Holtzblatt’s “Contextual Design” approach (2) for generation, consolidation and visualization of the data output from Observational Research as well as facilitation techniques and strategies from the Creative Problem Solving Group (3) for a number of facilitated steps including Innovation Workout.
The first two steps in the process – Customer needs collection and Prioritization of customer needs encompass the Design Research phase of the User Centered Innovation. The data generated in the Design Research phase is consolidated and visualized through workflow diagrams, storyboards, customer personas, key findings and other means of visual data presentations in preparation for the third step of the process, Innovation Workout.
Another critical input for the third step is an outline of the business priorities and goals with respect to the opportunity area where the User Centered Innovation effort is focused along with relevant competitive marketing and technology trends information. The Innovation Workout is typically a 3-4 day facilitated event. The innovation team goes through several steps including inputs review, opportunities brainstorming and opportunity mapping before developing individual solution ideas that are subsequently aggregated into initial solution concepts. This last step of the User Centered Innovation process, thereby creates a innovation funnel of solution concepts that address opportunities directly related to unmet customer needs and are also aligned with business needs / priorities.
Design for Usability….Incorporating User Interface design in DFSS
One of the biggest oversights so far in DFSS is not addressing explicitly the User Interface of products and services.
The User Interface is defined in a broadest sense as everything the customers come in direct contact with (visual, tactile etc.) when using a product or service. It includes, as applicable, product enclosure, hardware controls, graphical user interface, packaging, user manuals etc.
Every product, even the most simple one like bottled water, has it’s User Interface whether we are ready to acknowledge it or not. For the successful solution providers the design of the User Interface cannot be an after thought or a decoration effort on the way out of the door but is very often a critical element of the product or service’s commercial success (Apple being a prime example of it).
In our practice we have integrated User Centered Design (UCD) methodology that is widely used by designers / usability practitioners for the design of the User Interface within the DFSS framework which enables GE Healthcare to have a more holistic approach to total products and services design.
The integrated approach, Design for Usability, leverages the human-centric viewpoint and toolset from UCD with an added DFSS rigor of definition and measurement of the success criteria associated with the development. Both methodologies are merged in this new approach through the definition of Usability CTQs (4). Unlike the traditional DFSS CTQs which are internalized measures that when met enable us to meet the customer needs, the usability CTQs are a direct measurement of customer performance and track how successful they are in using our products or services.
Usability CTQs are based on human usability performance metrics that can have different layers (just like traditional CTQs) associated with system or subsystem levels of performance and testing (5). This performance metrics is defined (with the exception of overall satisfaction) within a context of specific user tasks through the usability attributes of efficiency, learnability, memmorability and user errors as described by Nielsen (6). The distribution of the data collected in the coarse of a usability evaluation is most of the time non-parametric and needs to be analyzed by nonparametric tools. Moreover, the fact that the metric is based on human performance implies higher error rates and a learning curve, where the short term data collected initially is usually worse then a long term dataset for users who are now experienced in using the product or service.
At GE Healthcare we have multiple examples in applying both User Centered Innovation and Design for Usability approaches in our innovation and product development practices resulting in the conceptualization and development of several highly successful products.
References
(1)“Design Thinking” by Tim Brown - Harvard Business Review, June 2008
(2)Contextual Design: A Customer-Centered Approach to Systems Designs by Hugh Beyer and Karen Holtzblatt, Academic Press, San Diego, 1998.
(3)Toolbox for Creative Problem Solving: Basic Tools and Resources by Scott G. Isaksen, K. Brian Dorval and Donald J. Treffinger, Creative Problem Solving Group – Buffalo, 1998
(4)Usability CTQs: Measuring Usability with Six Sigma, by Kevin Lee, Emil Georgiev, Michael Lechissi, Kate Gomoll and Debbie Zelnik; Proceedings of the 2005 annual UPA (Usability Professionals of America) conference
(5)Driving User Interface Design, Product Pricing and Product Positioning Strategies through Usability Performance Metrics by Emil Georgiev and Sandhya Pillalamarri; Proceedings of the 2007 annual UPA (Usability Professionals of America) conference
(6)Usability Engineering by Jakob Nielsen, Morgan Kaufman Publishers, 1994
|
| 12/12/2008 |
Design for Six Sigma at Ford
By Nathan Soderborg, DFSS Master Black Belt and Member, Office of the Technical Fellow for Quality Engineering, Ford Motor Company
Design for Six Sigma (DFSS) has been publicized as a product development approach that complements the Six Sigma problem solving methodology. Promoted as “Six Sigma goes upstream,” DFSS encourages systematic anticipation of customer needs and disciplined application of scientific and statistical methods to meet those needs. Many organizations, enthusiastic to build on Six Sigma momentum, generated their own DFSS processes before a standard template emerged.
While Six Sigma is widely recognized by the DMAIC acronym that represents its five standard phases (define, measure, analyze, improve, control), DFSS has no standard acronym. Therefore, organizations have adopted a variety of approaches that resulted in acronyms such as IIDOV, CDOV, IDOV, DMADV, DCOV and IDEAS. Despite these naming differences, all versions of
DFSS share fundamental strategies and tools that promote a common goal: to create a data driven product development culture that efficiently produces winning products.
Initial Assumptions
Ford decided to launch “consumer driven Six Sigma” in 1999, with an initial focus on two things:
1. Training Black Belts (BBs).
2. Completing DMAIC projects.
Management set targets for the percentage of each division trained and dollar savings resulting from projects. It created a central, prioritized list of all corporate quality issues to aid the coordination of improvement efforts with available resources.
The implementation strategy assumed people throughout the organization would be more likely to buy into Six Sigma if results were quickly realized from the company’s short-term (four to six month) “find and fix” DMAIC projects. That buy-in was considered necessary to start a culture
change. And while significant energy was focused on achieving the short-term targets, the importance of developing DFSS for the long term was also recognized.
A small development team with representatives from various divisions embarked on a plan to develop DFSS for Ford. The team held benchmarking discussions with early DFSS adopting companies and listened to consultants familiar with those efforts. Much of what was learned paralleled quality and reliability initiatives already under way at Ford.
The team settled on a four-phase process: define, characterize, optimize and verify (DCOV). The DCOV framework aligned with Ford’s existing product development (PD) system and built on the disciplines of systems, robust and simultaneous engineering, all of which had been in use at the company for more than 10 years. Introductory training in related tools was already available through the Ford technical education program (FTEP), an online curriculum all engineers
are expected to pass
Implementation began with Ford’s Powertrain Division, which wanted to apply DFSS to the development of new engines and transmissions. Work was divided into a large number of subprojects with an active BB assigned to each. Growth in the number of projects was driven by a senior vice president, who demanded regular status reports.
Key to progress was the strategic placement of a DFSS Master Black Belt (MBB) as manager of the
department responsible for the computer modeling of new engine designs. This manager teamed up with an engine program manager to act as working level champions for DFSS. Soon other divisions were launching DFSS by identifying beta projects and training teams to carry them out. Issues with the training and execution of these early projects highlighted implicit assumptions
that needed reevaluation. For example:
• The rationale for DFSS would be clear to midlevel management, and DFSS would be embraced as
a natural extension of Six Sigma.
• Projects would easily integrate into the company’s standard PD process because the DFSS steps had been carefully aligned to that process.
• Similar to DMAIC, steps to project completion could be detailed in a prescriptive set of procedures using a standard toolset.
• The DFSS training should follow the BB model, in which all participants receive extensive training in Six Sigma tools.
The following sections address these assumptions one at a time, explaining why they were flawed and outlining implementation changes required to maintain momentum of the DFSS rollout.
DFSS Rationale
DFSS proponents argue the benefits reaped from DMAIC defect reduction multiply when Six Sigma rigor is applied to defect prevention. But even when an organization has achieved significant DMAIC success, management may be legitimately skeptical of DFSS.
At Ford it became clear early on that DFSS acceptance could not be achieved riding on the coattails of Six Sigma. Basic questions such as “Isn’t DFSS just good engineering with a fancy brand name?” and “The tools are not new—so what is new?” needed to be clearly answered up front. To answer these questions, the team concluded Six Sigma culture, which establishes statistically
verifiable facts as an underpinning of all product decisions, could be a lever to increase the influence of Ford’s ongoing quality engineering initiatives.
DFSS packages methods and tools in a framework that promotes cultural change under a recognized
brand name that helps overcome an initial resistance to change. It is most useful if it generates permanent behavior changes that outlast its own life as a brand.
Given the DFSS toolset is not substantially new, the rationale for DFSS should not focus on tools. Over time, DFSS at Ford has emerged as a scientific approach to PD that leverages Six Sigma culture. It has become a means to reinstill rigorous deductive and inductive reasoning in PD processes. It requires:
• Identifying customer desires.
• Developing validated transfer functions (mathematical models) that describe product performance
through objective measures.
• Correlating these objective measures to customer desires and effectively assessing the capability to meet those desires well before product launch.
• Applying transfer function knowledge to optimize designs to satisfy customer desires and avoid failure modes.
Six Sigma culture aids implementation of these steps by providing:
• A cross company common language for problem resolution and prevention.
• A mind-set that demands the use of valid data in decision making.
• An expectation across the organization that results should be measurable.
• A disciplined project management system to help achieve timely results.
None of the elements of this approach are revolutionary, but together they provide a template for success. Based on experience applying DFSS, Frank McDonald, a VP of Cummins Inc., observed: “[DFSS] may sound like the latest new way if not for the fact that it really is more like the development of the old way to a higher standard that feels a lot like the right way.”
Recently, some DFSS proponents have contended that organizations should begin Six Sigma deployment with DFSS instead of DMAIC. Ford’s experience indicates otherwise. Short-term DMAIC projects led to rapid elimination of a significant number of issues and resulted in measurable financial benefits. This success boosted confidence in Six Sigma, and continued institutionalization helped build a culture receptive to DFSS. Furthermore, once BBs had successfully completed a few DMAIC projects, they were better equipped to support the longer and more complex DFSS projects.
Project Integration Within Existing Processes
Even when the rationale for DFSS is clear, practical reservations about its alignment with existing processes may remain. Ford had been evolving its PD system for years when DFSS was introduced. Natural fears arose that DFSS was intended to replace this system, potentially causing disruption and confusion. To counter those fears, senior management made it clear DFSS would not replace, but would augment, the existing PD process in specifically designated areas.
DFSS projects would demand a deeper dive into the establishment of customer connected performance targets (Y’s) and transfer functions that link those targets to critical design characteristics (X’s). This approach is consistent with the experience of other DFSS implementers:
“We shouldn’t tell our engineers we’re discontinuing the process they’ve been working with for 10 years and replacing it with DFSS. We should integrate DFSS deliverables into the current development process and ask project managers to commit to providing them,” said Doug Mader, president of SigmaPro.
Integrating DFSS deliverables into the current PD process sounds simple, but it involves real challenges. For example, PD entails at least three different categories of scope: the creation of a new product or technology, the evolution of a next generation product from a current design or the enhancement of an existing product. The rhythm and timing of DFSS projects associated with these efforts will vary depending on the category.
Boundaries are not always well defined, but the categories provide initial guidance for establishing project expectations and timing. Breakthrough projects have the most design latitude and typically require the most time to complete. Evolutionary projects have less design latitude, and their timing is tied to standard PD milestones. Adjustment projects have the least design latitude, and they are generally expected to be completed as soon as possible.
In addition to delivering an optimized design, each DFSS project at Ford is required to institutionalize learning and transfer functions by developing design guidelines and training that can be reused in the future. This effort to reduce waste in the PD factory is what distinguishes an adjustment DFSS project from a DMAIC project.
Some practitioners use different process phases for different categories of projects. For example, the
authors of Design for Six Sigma in Technology and Product Development use invent, innovate, develop, optimize and verify (IIDOV) to describe DFSS for technology development and concept, design, optimization and verify (CDOV) to describe product commercialization (design). To reduce confusion, Ford uses the DCOV abbreviation for all categories of DFSS projects.
A second challenge in integrating DFSS deliverables into the current development process is determining the manager to which they should be assigned. DFSS projects typically deal with the most challenging designs, such as new concepts or technologies linked to a compelling business case or complex systems that have exhibited problems in the past. In the first case, no natural project owner may have yet evolved in the organization. In the second case, the natural owner
may not be clear or may be disputable because product attributes and system interface issues often cut across system boundaries.
Even if the organization dictates a clear owner, the fact existing designs are underperforming indicates a need for a new approach. In each of these cases, it is critical to apply basic project definition and management techniques. These include:
• Ensuring the team is led by someone who has responsibility for the design and can engage the
appropriate technical expertise.
• Providing mentoring in statistical and PD tools—for example, assigning BBs and MBBs or their
equivalents.
• Securing an executive Champion to actively support and review the project.
• Committing the team and Champion to a project charter that outlines goals aligned with organizational objectives, scope matched to team resources, roles and responsibilities, and key project milestones with delivery dates.
The importance of active senior management leadership cannot be overestimated at the project or organizational level. In a division whose senior leader actively drove DFSS from the start, project numbers grew exponentially over the first three years of implementation. In a similar sized division, in which DFSS deployment leaders solicited projects from mid-level management, project numbers remained in the low teens for the same time period.
Process Flexibility
The variety of scope addressed by DFSS projects means DFSS needs to be more comprehensive and flexible than DMAIC. In DMAIC, BBs identify and reduce the frequency of defects generated by existing processes. The majority of work is analysis. In DFSS, teams must not only anticipate and prevent defects, they must anticipate and meet explicit and latent customer needs.
DFSS must address all three types of quality represented in Noriaki Kano’s model: basic, performance and excitement. DFSS requires a balance of analysis and synthesis—the synthesis of new designs and design standards from a combination of deductive and inductive reasoning based on experience, observation and theory. While analysis often proceeds linearly or is at least guided by procedure, synthesis proceeds iteratively and sometimes unpredictably as connections are made between disparate ideas. Such iteration is an inherent part of the PD progression from the conceptual to the concrete. Elements of each DCOV phase are repeated as designs proceed from concept to computer model to prototype to production.
Compounding the challenge of DFSS is the added uncertainty about future customer desires and future sources and levels of production and usage variability that will affect product performance. Assessing these types of uncertainty is often not possible by collecting frequency data from existing processes and making statistical inferences. Such phenomena are either not random or their random nature is not discernible.
So in addition to being equipped with statistical tools, DFSS teams must have knowledge about nonstatistical methods outside the typical BB curriculum, including methods for obtaining consumer insight, cascading customer desires down to component specifications, designing for robustness, mistake proofing and verifying designs with small sample sizes for testing. This methodology expertise, typically provided by BBs and MBBs, must be combined with deep technical expertise in the product functionality in question. An ideal situation occurs when a BB from a functional area finishes certification and returns to the area to support related DFSS work.
The Ford team initially devoted time to devising a single DFSS flowchart. Attempts to capture any substantial detail were finally abandoned because they ended up being redundant to existing PD flowcharts and failed to adequately address different project categories and represent iteration in the process. It was also difficult to clearly represent the proper relationship between tools and outcomes in a single chart.
The team, therefore, decided to produce two documents:
1. A tool matrix to outline which tools might be applied at each project phase
2. A project checklist to delineate intended outcomes at each phase. It is used with the understanding some items may not apply to a particular project as determined by the MBB and executive Champion.
Training
One of the key DFSS implementation challenges is training. Ford first applied a typical BB training model to entire teams. Team members attended two weeks of classroom training during the early months of a project. They studied a curriculum that included in-depth coverage of process and tools.
Participants in these pilot teams had two major concerns:
1. Some general tool and process information was redundant to FTEP.
2. Not all the specialized tools presented would apply to a particular project. For those that would—due to the extended length of DFSS projects— the team members worried they would forget much of the training by the time they needed to apply it. They concluded it was inefficient to train all team members in all tools.
As a result of the feedback, DFSS training was restructured. To enhance continued adherence to the
process, teams now meet periodically in workshops corresponding to each project phase (D, C, O and V). Instead of teaching tools, the workshop teaches the process and describes the results expected from the team. The bulk of the time is devoted to helping the team make progress on its specific project by interpreting data and formulating strategies for the technical work ahead. By the end of each workshop, the team has a written work plan for the project’s next steps.
A team process leader, typically a trained BB, guides the application of Six Sigma tools. An MBB facilitates the workshops, collaborates with team leaders throughout the project and provides additional training in advanced DFSS tools as required.
To supplement knowledge of basic DFSS tools already provided through FTEP, Ford’s office of the
Technical Fellow in Quality Engineering sponsors reliability and transfer function seminars for the engineering community at large and targeted to DFSS teams. Baseline DMAIC skills are also reinforced as engineering organizations near completion of a corporate mandate requiring all engineers to achieve DMAIC Green Belt status.
Implementing DFSS can be challenging for any organization. Experience at Ford revealed the challenges are more likely to be cultural and organizational than technical. Through adjustments based on lessons learned, DFSS at Ford has emerged into what it is today: an enhancement to the current PD system that leverages the company’s extensive Six Sigma skill base and culture to fundamentally understand product performance and deliver customer satisfying, robust designs. It adapts to wide ranges of scope and allows flexibility in the choice of tools to achieve the required
results. It augments existing training with just-in-time workshops to help teams efficiently deliver results.
ACKNOWLEDGMENTS
Many people have contributed to the success of DFSS at Ford. I have had the pleasure of collaborating with Dave Amos, Tim Davis, Agus Sudjianto, Tom McCarthy, Chris Gearhart, Bob Thomas, Ellen Barnes, Garry Smith, Fred Johns, Sam Hamade, Mahesh Vora, John King and Belinda Hodge.
REFERENCES AND NOTES
1. Kai Yang and Basem El-Haik, Design for Six Sigma: A Roadmap for Product Development, McGraw-Hill Professional, 2003.
2. IIDOV = invent, innovate, develop, optimize, verify.
CDOV = concept development, design development, optimization, verify certification.
IDOV = identify, design, optimize, validate.
DMADV = define, measure, analyze, design, verify.
DCOV = define, characterize, optimize, verify.
IDEAS = identify, design, evaluate, assure, scale-up.
3. C.M. Creveling, J.L. Slutsky and D. Antis Jr., Design for Six Sigma in Technology and Product Development, Prentice Hall PTR, 2003, p. xvi.
4. Douglas P. Mader, “DFSS and Your Current Design Process,” Quality Progress, July 2003, pp. 88-89.
5. Creveling, Design for Six Sigma in Technology and Product Development, pp. 8 and 51-52, see reference 3.
6. Charles Berger, et. al., “Kano’s Methods for Understanding Customer-
Defined Quality,” Center for Quality of Management Journal, Fall 1993, p. 3.
Source: Six Sigma Forum Magazine, November 2004
http://www.asq.org/pub/sixsigma/past/vol4_issue1/index.html |
| 12/12/2008 |
The Integration of DFSS, Lean Product Development and Lean Knowledge Management
By Kai Yang, Xianming Cai, Department of Industrial and Manufacturing Engineering Wayne State University
Abstract
Design for Six Sigma, lean product development, and lean knowledge management are three effective methodologies in improving the product development process. The performance of product development process can be measured by product value, product quality, product development lean time, efficiency, and product life cycle cost. Design for Six Sigma can greatly improve product value and quality. Lean product development and lean knowledge management can help to achieve better product development lead time and efficiency by reducing wastes. Lean knowledge management can also help to improve product value and reduce product life cycle cost by adopting better technology and practices. These three methodologies are complementary and should be integrated.
1. Introduction
For many industries, products are major revenue generators. Products with good value and quality will command higher price and generate more sales, thus create more revenues. For most of products, the ability of a product development process to accurately capture the market needs, respond quickly to shifting customer demands, and develop and launch the right product at right time is vitally important. Therefore, the product development process is one of the most important processes for many companies.
Compared with other types of processes, such as production processes and financial transaction processes, the product development process is usually a much more technically sophisticated, costly and time-consuming process.
Though Lean Six Sigma has achieved great success in many areas, rigidly plugging in a generic Lean Six Sigma approach to product development process is not appropriate and it could actually damage an originally effective product development process. One such example is discussed in a recent cover page story of Business Week ( Business Week, June 11, 2007 Issue), it described how an inappropriate Six Sigma deployment damaged 3M’s long tradition of innovation culture. A good example of appropriate application of Six Sigma and lean into a product development process is the Samsung Group, many reputable publications, including Fortune magazine, (Lewis 2005, Yun and Chua, 2002) described Samsung having developed a very effective Design for Six Sigma approach that has greatly improved Samsung’s capabilities in innovation, efficiency and quality in its research and development, and product development processes. An important tool in DFSS, Theory of Inventive Problem Solving (TRIZ), is a tool of choice for Samsung to greatly improve its innovation capability.
The appropriate implementation of Six Sigma and lean approaches into product development process is possible and can be extremely rewarding. A good Design for Six Sigma approach is the right way of implementation of Six Sigma into the product development process. It is our belief that this Design for Six Sigma approach should have a strong innovation arm that can greatly enhance, not to stifle, the innovation capability of the companies who are employ them.
Besides Six Sigma, how do we implement lean operation principles in product development process in order to greatly improve the product development process’s speed and efficiency? Again, rigidly plugging in a generic lean approach in the product development process is also not appropriate. The lean product development approach is a right approach for it. The lean product development process is a product development process that is able to develop products with maximum customer value and with minimum wastes in resource and high speed. The lean product development comes from many sources, they include Toyota product development system (Morgan, Liker 2006, Kennedy, 2003), Don Reinertsen’s work ( Reinertsen 1997), and Yang’s work (Yang 2008).
If we closely look at what a product development team is doing every day, we will find out that they are creating documents, compiling testing reports, doing design analysis, creating specifications, building prototypes, designing and making tools for producing the product, and so on. Whenever the product development team generates enough useful information to produce the product effectively, reliably, economically and with good quality, and the products shipped to customers are free of after sale problems, our product development job is done. Clearly, the nature of the product development process is an information and knowledge generation factory. Therefore, effective knowledge management is also very important in the product development process. Unfortunately, in most of real product development processes, the waste of knowledge and information is rampant, according to Kennedy (Kennedy 2003), and how to effectively manage the knowledge and information with minimal waste is a real challenge. In this paper, we will to present a lean knowledge management frame work which can take this challenge. There are two objectives for this paper. The first objective is to describe the frame works of DFSS, lean product development, and lean knowledge management. The second objective is to discuss how these three strategies can be integrated to greatly enhance the product development process.
In this paper, we will first discuss the performance metrics for the product development process in section 2, because the understanding these performance metrics is the key to evaluate a product development process and to access the roles of various methodologies, such as DFSS, in improving the product development process. Section 3 will give a brief description of DFSS. Section 4 will discuss the lean product development process. Section 5 will give an overview for our framework in lean knowledge management. Section 6 will discuss the roles of those methodologies in the product development process and how these methodologies can be integrated to achieve the optimal effect.
2. Product Development Performance Metrics
Product Value: Product value is the most important performance metric. Product value can be measured by the total profit, or total revenue generated by the product over its entire market life cycle. Unfortunately, it is a lagging performance metric, which means that we won’t know it exactly before the launch of the product. The product value is related to many factors, which include: 1. How well the voice of the customers are captured and deployed: If we develop a hit in market place, this product will generate a lot of profit. 2. Creativity and uniqueness: If we create a first of its kind product, and nobody else can provide the similar product, we will command the market price.
Product Quality: Product quality is a measure of quality, reliability and robustness. If a high value product has consistent, repeatable performance under various usage conditions, and can last a long time, the product will be very successful. Product quality can be measured before the launch of the product by product testing or even product performance simulation analysis. For some companies, design score cards are established to measure the product quality. Some lagging indicators, such as warranty costs, number of initial quality problems etc., can also be used to measure product quality.
Product development lead-time: The product development lead time is the length of time from the product development kick off time to the launch time of the product. Product development lead-time is a very important metric because it determines the speed with which new products can be introduced into the marketplace.
Efficiency: In product development, efficiency is the cost of manpower and other resources required for the product development.
Life cycle cost: Life-cycle cost is the total cost related to a product. It includes development costs, production costs, sales and distribution costs, service, support and warrantee costs, and disposal costs. A product with high life cycle cost will certainly lower its profitability. Product development has a particular vested interest in keeping the life cycle cost for any product as low as possible.
On a longer time scale, product value, product development lead-time, efficiency, and life cycle costs, will contribute a great deal to the level of customer satisfaction, market share, and revenues that the company will have. These will in-turn translate into profitability and influence the organization's long-term business viability.
Design for Six Sigma (DFSS), lean product development, and lean knowledge management are effective and complementary approaches which will enhance the product development performance metrics in different ways. In the subsequent section, we will discuss these three approaches and their particular contributions in the product development process.
3. Design for Six Sigma
Design for Six Sigma (DFSS) is a Six Sigma approach which involves designing or redesigning of products or processes. Design for Six Sigma is a comprehensive methodology that integrates discipline, training, project management, DFSS road maps and DFSS tools to lead the product development projects and improve the product development process. The goal of DFSS is to design or redesign the product to intrinsically achieve maximum product value and achieve superior quality and reliability. Similar to all Six Sigma activities, DFSS activities are featured by launching and completing carefully selected projects guided by DFSS roadmaps. There are two popular DFSS roadmaps, IDOV and DMADV.
IDOV is a four-phase process that consists of Identify, Design, Optimize and Verify.
1. Identify Phase: It begins the DFSS process with a formal tie of product development to the Voice of the Customer. This phase involves developing a team and team charter, gathering VOC, performing competitive analysis, and developing critical to quality characteristics (CTQ).
2. Design Phase: This phase emphasizes deploying CTQs into the product design. The tasks of this phase may include identifying functional requirements, developing alternative concepts, evaluating alternatives and selecting a best-fit concept, and deploying CTQs and predicting sigma capability.
3. Optimize Phase: The Optimize phase emphasizes detailed product design optimization to achieve excellent performance and robustness. The tasks of this phase may include developing detailed design elements, predicting performance, and optimizing parameter and tolerance design.
4. Validate Phase: The Validate phase consists of testing and validating the design.
Another popular DFSS roadmap is called DMADV, The five phases of DMADV are:
1. Define: Define the project goals and customer (internal and external) requirements. 2. Measure: Measure and determine customer needs and specifications; benchmark competitors and industry. 3. Analyze: Analyze the product design options to meet the customer needs. 4. Design: Design (in detail) to meet the customer needs. 5. Verify: Verify the design performance and ability to meet customer needs.
From the product design point of view, DFSS is a Six Sigma approach that works on the early stages of the product life cycle. DFSS can achieve many different objectives in these early stages in the product life cycle. In the ideation stage, DFSS can help to accurately acquire the voice of the customer (VOC) to ensure our product will satisfy the needs of the market. In concept development stage, DFSS can help to successfully deploy VOC into product design, create innovative product concepts, and generate design free of design vulnerabilities. In product design stage, DFSS can help to develop optimized product parameter and tolerance design to achieve high product quality, robustness and reliability. Overall, DFSS can help our product development process to achieve high product value.
3. Lean Product Development
Lean operation practices have achieved a great deal of success in both manufacturing industry and many service industries. Can these lean operation principles achieve the same drastic results in product development process? The answer to this question is positive. The birth place of lean manufacturing, Toyota, does have an edge in product development process compared with North American automobile companies. Toyota’s product development system gained a lot of attention and it is discussed in literature (Morgan and Liker 2006, Kennedy 2003).
However, there are many distinct differences between product development process and manufacturing process, so the lean principles have to be modified to work well in the product development process. For manufacturing processes, what we are going to produce is very clear in the beginning; the product that we produce has already been designed so the value of the product is already known. For the product development process, the value of the product is unknown until it is launched in the market place. For manufacturing process, the rework is treated as a waste; for product development process, iterative improvement on product design is quite common. Even the goal of lean operation is different between manufacturing process and product development process. For manufacturing operation, the goal of lean operation is to minimize the waste and increase the speed; for product development process, the goal is to simultaneously maximize the product value, quality, reduce waste, and increase development speed.
Based on these differences, we can give the following definition to the lean product development process: The lean product development process is aimed to deliver more value in the product by using less resources through:
• Thoroughly capturing the voice of customer and accurately deploying the customer value into design
• Accomplishing high product value and quality and low product cost by using the most appropriate technology and design
• Effectively transforming the voice of customer into high quality design with high speed and low cost
• Relentlessly decreasing the wastes in the product development process
4.1 Wastes in Product Development Process
All lean operations start with identifying and eliminating wastes in the process. Unlike the ‘seven wastes’ in the manufacturing process, there are no universally agreed waste categories for the product development. Here we have listed the following waste categories for the product development process:
1. Wasted sale opportunities due to poor product value: The following items are included in this waste category:
• Inability to capture right voice of the customer (VOC) information
• Inability to translate VOC into appropriate design
• Poor choice of technologies
• Poor innovation capabilities
• Failure to integrate innovation with VOC
• Poor quality, reliability and robustness in designed product
2. Waste in manpower, resource and time: The following items are included in this waste category:
• Waste of manpower and resource in non value added activities
• Overburden on the people or resource: Excessive work load and unrealistic deadline often lead to half cooked projects and bug-ridden designs, this will eventually lead to rework.
• Unproductive meetings: Meeting consumes man hours
3. Waste in knowledge and information: The following items are included in this waste category:
• Reinvention: If someone else has already done this work, reinvention certainly is a waste of manpower and resource
• Mismatch of subsystems: Many design rework problems happen in the unexpected subsystem interactions
• Information loss and re-creation: This happens a lot in most of companies
• Miscommunication: Miscommunication among product development team members often leads to doing the wrong work, and then we have to redo it
• Searching for information, waiting for critical information: This is certainly not a value added activity
4. Waste due to poor design practice: The following items are included in this waste category:
• Excessive design requirements: such as excessive tolerances, excessive material specifications, excessive operator requirements and so on
• Excessive complexity in design: The simplest design is best design, given that we can deliver all the product functions
• Poor product architecture: Poor product architecture often leads to redesign, mismatch, and performance problems.
Many approaches based on lean principles are developed to identify and eliminate these four categories of wastes. In this paper, we will discuss several lean product development methods.
4.2 Lean Task Management
Lean task management deals with the waste in manpower, resource and time. Lean task management consists of several approaches from various sources (Mascitelli 2004, Reinertsen 1997, Morgan and Liker 2006).
4.2.1 Increasing Effective Value Added Working time (Mascitelli 2004):
Based on lean principles, all tasks performed by design engineers can be classified into the following three categories:
1. Value Added: This category of tasks is the one that really move the product design forward and create values that external customers are willing to pay for the job done. The examples of tasks in this category include drafting new designs, conducting design simulation for improvement and creating application software codes.
2. Non Value Added but Necessary: This category of tasks is the one that may not move the product design forward and may not create values that external customers are willing to pay, but it is necessary under current circumstances. The examples of tasks in this category include design gate reviews, team coordination meeting and validation testing.
3. Waste: This category of tasks is the one that does not move the product design forward and it has no value for external customers. These tasks can be identified and eliminated. The examples of this category of tasks include time spent on moving from meeting to meeting, voice mail checking, searching for information and so on.
Macitelli stressed the importance of increasing the ratio of value added time, and to decreasing the ratio of non value added but necessary and the waste
Mascitelli stated that based on industry survey, in an 8 hour working day, the average value added time is only 1.7 hours in the Western companies. However, Toyota claimed that its average value added time is more than 50%.
Mascitelli also thinks that it is very important to allocate uninterrupted time slot, 3 hours or more, to each design engineer for each working day in order to greatly improve the productivity. From a human factor perspective, when design engineers are doing product development work, it takes some time to achieve mental focus on the job, and it takes some time to get even a small task completed.
4.2.2 Smoothing Product Development Job Flow
Product development is a complicated process which has multiple stages and involves many different departments and teams. Each team or engineer will work on several projects during the whole product development process, so some projects have to wait in the queue until the current project is finished so the team or engineer can free their hands to work on them. In this case, the product development process is a queuing network and how we sequence the jobs, how we assign the work load and timing will make a lot of difference in overall product development lead time and efficiency. The queuing theory can provide great help for us as how to reduce the waiting time and how to improve the throughput (number of projects finished/unit time).
There are several important results in queuing theory that are relevant to product development process.
1. Batch Queue is Inefficient
Batch queue means the jobs are coming to queue in big groups, or batches. It is a well known result in the queuing theory that the waiting time and queue length is significantly larger in a batch queue system than a queuing system in which the job arrivals are in small pieces, given if the service rates and total amount of jobs over a long period of time are the same for both queuing systems. The implication for the product development practice is that if we load product development team or engineer in big chucks of work, instead of one by one, our throughput will be low, and waiting time will be long.
2. Nonlinear relationship between capacity utilization and queue length
Queuing theory states that the relationship between capacity utilization and average waiting time is a nonlinear relationship. Capacity utilization is defined as the percentage of time that the server is busy. What this relationship indicates is that when the server is about partially loaded, the waiting time will be very low, however, if we increase the capacity utilization towards 100%, then queue length will grow very fast and the waiting time will be extremely high. The implication for the product development process is that overburdening the product team or engineers will make the product development lead time much longer.
3. Constant Job Arriving Rate vs Variable Arriving Rate
In queuing theory, it is also a well known result that given the same mean job arrival rate, the queuing system with higher variance in arrival rate will result in longer waiting time and queue length than that of the queuing system with lower variance in arrival rate. The implication for the product development process is that if we load job to engineers evenly, then the throughput will be higher.
4. Uneven Job Size vs Similar Job Size
Again, we are comparing two queue systems. Given that in both queues, the arriving time patterns are the same. The first queue system is such that every incoming job takes about same amount of time to finish by the server. The second queue system is such that every incoming job has different sizes, even if the average job processing time is the same as the first queue system. Then the waiting time and queue length of the first queue system will be shorter than the second one. The implication for the product development is that loading engineers with similar job sizes for each task will increase the job throughput.
Toyota product development system (Morgan and Liker 2005, Kennedy 2003) has developed some well established practices to ensure smooth product development job flows. Specifically, one of the key principles in Toyota product development system is to create leveled product development process flow. This principle calls for synchronizing activities across different functional departments in a product development organization. It also calls for evenly distributed workload to various departments and engineers. This approach create steady work load and job flow so the tasks will flow through the organization smoothly and waiting line will be unlikely to occur.
4.3 Set-Based Design
As we discussed earlier, the product development process is an information and knowledge generation process. Information has time value; we want the key information to be available earlier, rather than later. In Toyota’s product development process, (Morgan, Liker 2006) one of its design principles calls for “front-load the product development process to explore thoroughly alternative solutions while there is maximum design space”. The technical approach for this ‘front-loading’ principle is the set-based design practice.
Set-Based design approach is used in concept design stage. In regular design practice, we will start with a small number of design concepts, and then we will select one seemingly good concept, and move into detailed design and conduct evaluation test. If the test shows the concept is acceptable, we will move this concept to the parameter design, and prototyping stage. If the test shows this concept is not acceptable, we will start another raw concept and do another round of development; we may iterate this process until an acceptable design is found.
On the other hand, the set-based design will simultaneously start several concepts. The initial sets of concepts are coming from:
• Current knowledge
• New technology from recent research and development efforts
• Idea generation through brain storming
This initial set of concepts should include at least one concept that is relatively mature and reliable. After the initial set is selected, we divide the engineers into teams, each team works on one concept. Each team will grow its concept by detailization, design evaluation and tests. It is very important that the set-based design stay in the concept design stage, we can do some low cost CAD (Computer Aided Design) simulation, Alpha prototype, small scale lab test and so on. This will ensure that the set-based design approach will not be expensive and time consuming.
The whole set based design will be subdivided into several mini-stages, during its progress; the concepts are evaluated and tested and weaker concepts are eliminated. The advantages of set-based design include discovering better concepts early in the design process.
4.4 Lean Product
In Yang’s recent book, Voice of the Customer Capturing and Analysis (Yang 2008), it is stated that the product development process is an information creation process. The consumer of this information is the product design. Axiom 2 of the axiomatic design principles (Suh 1990) states that the best design is the design that delivers all product functions satisfactorily and has the lowest possible information content, or complexity level. In Yang’s book, it is stated that the ideal product development process is such that it creates information and knowledge at the highest efficiency, speed and quality, but the consumption of information for each product is minimum.
The information consumption is proportional to the complexity of the product design. So we need to trim all unnecessary complexities out of product design. A product design that is free of unnecessary complexities is called a lean product.
The complexity in engineering design is related to:
• Number of functions and parts
• Complexity in product architecture (How different modules and design parameters are related to each other)
• Uncertainty (such as uncertainty caused by variation, quality and technical immaturity)
• Complex relationship between design parameters and product performance
Based on the work of Huthwaite (Huthwate 2004), the following approaches can be used to reduce the unnecessary complexities in the product design and create lean products:
•Reducing unnecessary product functions and parts
• Loosening up unreasonable tolerances
• Using standard/out of shelf parts
• Controlling technical immaturity
• Avoiding complicated user/operator requirements
• Avoiding complicated interface requirements
In Toyota product development system, standardization is extensively used to reduce the information consumption in product design. One of Toyota’s product development principles is called utilizing rigorous standardization to reduce variation and create flexibility and predictable outcomes. This principle calls for applying the following four kinds of standardization over the product development organization:
1. Design standardization: Engineering checklist, standard architecture, share common components
2. Process standardization: Standardizing common tasks, sequence of tasks and task duration
3. Skill set standardization
4. Standardized skill inventories
This principle uses the fact that standardization will reduce complexities in product design and reduce confusions in communications among engineers. Standardization will make each job more transparent and uniform, so you can have more predictable outcomes. Standardization will also reduce the waste caused by reinvention, mismatch, information loss, and re-creation.
5. Lean Knowledge Management
5.1 Overview of Knowledge Management
Knowledge management is a process that an organization can use to identify, create, represent, and distribute knowledge. Knowledge management has always existed throughout the history. Apprenticeship, on-job training, corporate libraries are examples of knowledge management practices. With the advancement of computer technology, more and more computer based systems such as knowledge base, best practice database, expert systems have been introduced in the knowledge management system. There are numerous literatures in the area of knowledge management, Kotnour (1999), Nonaka and Takeuchi (1995), Liao (2003), and Stankosky(2005) are among the most informative literatures. In their 1995 book, The knowledge creating company, Nonaka and Takeuchi stated that a successful knowledge management and knowledge creation system is crucial for successes for many Japanese companies, in which it is really important to convert the individual’s knowledge from employees into organizational knowledge. Nonaka and Takeuchi discussed the distinction between explicit knowledge and tacit knowledge. Explicit knowledge is knowledge that can be explicitly expressed and communicated.
Written reports, presentations, research papers, books, instructional manuals, procedures, sound and visual records, and software are examples of explicit knowledge. On the other hand, tacit knowledge is knowledge that cannot be expressed explicitly in a stand-alone form. Tacit knowledge is buried deeply inside people and it is difficult to express and transmit it explicitly. However, it usually can be transmitted only through a lot of people-to-people interaction. The simplest example of tacit knowledge is that nobody can learn NBA basketball skills by reading or by watching audio/video media. Nonaka and Takeuchi stated that there is a big portion of knowledge within an organization that is in the form of tacit knowledge, and tacit and explicit knowledge can be transformed from one to another. A successful knowledge management program should be able to convert tacit knowledge into explicit knowledge in order to share it.
Thought it already becomes a multibillion dollar business, the traditional knowledge management programs do have a few pitfalls:
1. Based on the research of Morgan and Liker (Morgan and Liker 2007), many computerized knowledge management systems in Western companies suffer from obsolete and inadequate contents due to lack of constant inflow and updating of fresh knowledge.
2. Traditional knowledge management programs are based on managing explicit knowledge. There is little technical means to capture, convert and share tacit knowledge (Fahey and Prusak, 1998).
3. Most of computerized knowledge management systems are developed and driven by the advancement of IT technologies, few of them are designed based on the need of real product development practices, with the exception of Toyota (Morgan and Liker 2007).
We will first describe the role of knowledge and information in the product development process in section 5.2. In section 5.3 and 5.4, we will discuss our framework of a lean knowledge management system.
5.2 Knowledge and Information in Product Development
In Yang’s recent book (Yang 2008), Voice of the Customer Capture and Analysis, he described in detail that there are three types of knowledge and information activities in the product development process; they are information mining, information transformation and information and knowledge creation.
5.2.1 Information Mining
Information mining is the extraction of valuable information from information sources. For example, in research and publication work, the literature survey is an information mining work. In the product development process, there are two major types of information mining work, they are the mining of the voice of customer, and the mining of the technological information
1. Information Mining of the Voice of Customers - the product development is a sequence of ‘mapping’ processes. The very first step is the mapping from the customer domain to the function domain; this step is really a rigorous product definition step. The whole value of the product is largely determined by whether the product will be welcomed by the potential external customers, or buyers. It is not an exaggeration that accurately capturing the voice of customer is like a strike in the gold. There are numerous examples about the importance of the mining of the voice of the customer and success stories, such as Federal Express, Starbucks, and iPod.
2. Information Mining of the Technology Information and Knowledge - In product development process, we need to obtain the technological know-how and information to transform the voice of customer into reality. In this information mining work, the quality and speed of the information mining are very important.
The quality of this information mining means that we are getting the best technology in terms of performance, the cost of technology and the robustness of the technology. The speed of this information mining is also critically important; the ideal technology information mining process is featured by the abilities to pull the right technology information to the right people at high speed.
5.2.2 Information Transformation
Information transformation is similar to ‘mappings’ in Suh’s axiomatic design theory. Most of information transformation work deals with existing knowledge. For example, in automobile product development, body design and assembly is a big chunk of design work. Body styles have to change to make cars catch the fashion trend. But there is very little new knowledge needed in this design work. The types of work in this information transformation usually include:
• Given a need, ‘pull’ design solutions from a known source.
• Design of interfaces
• Shape and form design
• System flow down and integration
• Design analysis, simulation
• Testing
• Prototype building
For complicated products with thousands of parts or more, the scope of this information transformation work can be very large. We need a whole organization with many people; they have different tasks, different knowledge background and experience to work together. The information and knowledge need to flow smoothly through the whole organization.
5.2.3 Information and Knowledge Creation
In the product development process, there are some design tasks that no ready solutions can be pulled from somewhere. These tasks involve creating new information and new knowledge. Here are some of the scenarios:
• Resolution of some technical bottlenecks that nobody has accomplished before: For example, the fuel efficiency of internal combustion engine is low. With the increasing petroleum price, this technical difficulty needs to be resolved.
• Development of the new generation of product: we want to drastically improve our product’s performance, cost and so on to move ahead of competition. This improvement is not merely a fine tuning of existing product.
• Develop a product with new marketing concept.
• Technology push product development: Many research results are coming out from universities, research institution and so on, and many patents are created every year. Manufacturers are bringing these new technologies into their products.
5.3 Lean Knowledge and Management
As we discussed in Section 5.2, the product development process consists of information mining, information transformation and knowledge creation. An ideal product development process should be such that it creates information and knowledge at the highest efficiency, speed and quality. At the same time, the waste of information and knowledge in the product design is at a minimum. In actual product development processes, however, the waste of information and knowledge is difficult to see and is running rampant in many companies. An effective knowledge and information management system is crucial in a lean product development process. In this subsection, we are going to discuss the following approaches in lean knowledge and information management.
5.3.1 Knowledge and Information Supermarket
As we discussed earlier, the lean production system is based on the “pull” concept. The pull concept is derived from supermarket inventory replenish practice. In knowledge and information management, the concept of “supermarket” is also very appealing. In today’s electronic information technology, we do not need to consume and store multiple copies of information. However, the knowledge and information could become outdated and obsolete from time to time. The meaning of knowledge and information supermarket is the following:
1. The information and knowledge is always fresh and up to date.
2. The information and knowledge is sufficient to serve all the needs of the product development.
3. We know where each information and knowledge is stored.
4. The information is ready to be pulled at the right time, the right kind and right amount.
A good information and knowledge supermarket will greatly reduce the time and resource spent in retrieving and search information, misalignments in the product development projects, knowledge recreation, and reinvention.
5.3.2 Several Knowledge Management Practices in Toyota
There are several knowledge management practices that are derived from the real needs of the product development practice and they are proven to be very effective. They are V-Comm system and Visible knowledge.
V-Comm System
Toyota’s V-Comm system (Morgan, Liker 2006) is a knowledge and information management system that is close to our “information and knowledge supermarket” concept. V-Comm stands for “Visual and Virtual Communication” for Toyota. V-Comm was initially launched in 1996, as a ‘digital build’ software and it is improved continuously. In 2001, V-Comm become more mature, it helped Toyota to slash the car development time from 18 month to 11 Months. It is currently a software platform for design review and communication. V-Comm’s main functions include:
• Virtual design prototyping and production prototyping
• Design review and visual communication
• Model-based design simulation and error checking
• Knowledge database and communication
V-Comm’s knowledge database is very comprehensive and always kept up to date, it has the following contents:
• Best Practice Files
• Past Issues, quality hazards
• Recommended key specifications
V-Comm is a great success in lean knowledge and information management because it is right on the main traffic points of the product development process; and it is a system that is ready to pull information when needed at the right place. It is updated constantly and contain comprehensive amount of information and it is easy to search.
Visible Knowledge
Visible knowledge is a very important component of Toyota’s product development system. Visible knowledge is a practice to capture and illustrate knowledge so that it is easily shared with other people within the organization. Here we will show two important visible knowledge tools, the A3 report and the planning wall.
1. A3 Report
A3 report is a kind of report where A3 size papers (11’x17’) are used. Each report will use exactly one A3 size paper, or equivalent to a two pager report for regular 8’x11’ size paper. Based on the objectives, there are primarily three kinds of A3 report:
• Knowledge sharing
• Problem Solving
• Project Status Report
In Toyota, A3 report is one effective tool to convert individual employees’ tacit knowledge into explicit knowledge and let the whole organization to capture and share this knowledge. In many other western companies, half finished, ill placed, ill explained and incomplete reports and documents are very common; only the people who created them can understand them, and a lot of knowledge is in employees’ head. Employees’ turn over and retirement will create huge loss of knowledge for their employer.
In Toyota, before the meeting takes place, even if it is an one to one meeting, the participants usually e-mail an A3 report to each other. So before the meeting starts, the participants can get enough information on the subject from each other, then very quickly the serious discussion can take place so meetings will be very productive.
2. Planning Wall
Planning walls are the walls in the project control room for many Japanese companies. In these walls, various A3 reports are displayed, giving team members an immediate "bigger picture" view of the project objectives and how they relate to overall corporate objectives, visually-oriented progress reports for all parts of the project (color coded, to show which metrics are on target and which need immediate attention) and much more.
5.4 Computerized Lean Knowledge Management System
From our early discussion, a well structured knowledge and information supermarket that can provide all the right kind of knowledge and information for a product development process at right time and right place is essential to effectively create product design with minimum waste. This knowledge and information supermarket will only be possible with the aid of computer technology, and we will call it a computerized lean knowledge management system.
The main functions of this computerized lean knowledge management system should include:
1. Capture the relevant external explicit knowledge base for product development, such as relevant patents, technology information obtainable from open sources, such as university, internet, competitors’ products benchmarking and so on.
2. Capture, maintain and update the marketing and voice of customer information. (Omar, Harding and Popplewell 1999)
3. Capture, maintain and update corporation’s internal explicit knowledge base, such as computer files of standardized or custom made design modules, testing procedures, design check lists, technical reports, testing results and so on.
4. Capture, convert and share tacit knowledge of company employees, and possibly suppliers.
5. Facilitate easy access of all information for all kind of internal users, regardless of their professional affiliation, and location.
6. Manage the knowledge contents to ensure that the contents are well organized, constantly updated, and free of errors.
Based on these main functions, our proposed computerized lean knowledge management system has the following main modules: It is an integration of a traditional ECM and a centrally-managed CMS with a corporate Wiki.
Enterprise Content Management (ECM): It is a technical system that can capture, manage, store, preserve, update and deliver contents and documents based on organizational needs. ECM can be enabled by enterprise content integration technology (ECI). ECI is a middleware software technology that connects together all computer systems that manage documents and digital contents. (Fisher 2006, Bridges 2007)
Content Management System (CMS): It is a system used to manage the contents. Content management systems are deployed primarily for the interactive use by a potentially large number of contributors. (McQueen 2004, Huseyin and Yavuz 2005) For example, wiki software is the content management system for the website Wikipedia. Actually, we believe that Wikipedia is an excellent example of massive collection of information and knowledge from many individual users and massive transformation of tacit knowledge of web contributors into a great wealth of explicit information loaded on Wikipedia ready to be shared by people all over the world. Wikipedia is also a good example of information supermarket, because it is well organized, easy to find, and always up to date (Hoehndorf, et al. 2006). We believe that a content management system similar to wiki software can play a great role of capturing employees and suppliers tacit knowledge and converting it into a great knowledgebase.
6. The integration of DFSS, Lean Product Development and Lean Knowledge Management
Design for Six Sigma, lean product development, and lean knowledge management are three effective methodologies related to the product development process. These three methodologies improve the product development processes in different ways.
Design for Six Sigma consists of roadmap and tools that can improve the value and quality of designed product by better capturing the voice of customer, adopting better design practices, fostering innovation, and achieving better performance and robustness through parameter and tolerance design.
Lean product development is a custom made lean operation principle for the product development process that can reduce product development lead time, improve product development efficiency and reduce product development cost by reducing wastes in the product development process.
Lean knowledge management is a knowledge management system that supports lean product development practices and preserve and improve organizational knowledge. Lean knowledge management will reduce product development lead time, increase product development efficiency by greatly reducing the wastes of knowledge and information. Lean knowledge management may improve the product value by adopting better knowledge and technology in the product. Lean knowledge management may also reduce product and production cost by adopting better technology and practices.
References
Bridges, J. D. (2007), "Taking Ecm from Concept to Reality [Enterprise Content Management]," Information Management Journal, 41, 30-32.
Fahey, L. and Prusak, L.( 1998) " The Eleven Deadliest Sins of Knowledge Management", California Management Review, Vol. 40, No. 3, 1998, pp. 265-275
Fisher, G. (2006), "Enterprise Content Management," Information Management & Technology, 39, 162-163.
George, M., (2003) Lean Six Sigma for Service, McGraw-Hill, New York, 2003
Harris, C.M.(1998). Fundamentals of Queueing Theory. Wiley 1998, New York
Hoehndorf, R., et al. (2006), "A Proposal for a Gene Functions Wiki," Montpellier, France: Springer-Verlag, pp. 669-678.
Huseyin, S., and Yavuz, A. (2005), "Overcoming Scormification Difficulties in Implementing a Learning Content Management System," Santo Domingo, Dominican Republic: IEEE, pp. 3-11.
Huthwaite, B. (2004), The Lean Design Solution, Institute for Lean Design, Mackinac Island, Mich.
Kennedy, M. (2003), Product Development for the Lean Enterprise, The Oaklea Press, Richmond, Va.
Kotnour, T. (1999). A learning framework for knowledge management. Journal of Project Management. Vol. 3, No. 2, 32-38
Lewis, P. (2005), “A Perpetual Crisis Machine,” Fortune, Sept.19.
Liao, S. (2003) "Knowledge management technologies and applications -iterature review from 1995 to 2002", Expert System with Applications, 25 (2003) pp 155-164
Liker, J.K., (2004) The Toyota Way, McGraw-Hill, New York, 2004
Mascitelli, R. (2004) The Lean Design Guidebook, Technology Perspectives, Spi edition, Woodside, Calif.
McQueen, H. (2004), "Plan Ahead for Your Content Management System," Information Outlook, 8, 15-17.
Morgan, J., and J. Liker (2006), The Toyota Product Development System: Integrating People, Process and Technology, Productivity Press, Portland, Ore.
Nonaka, I., and H. Takeuchi (1995), The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation, Oxford University Press, New York
Ohno, T., (1990), Toyota Production System: Beyond Large Scale Production, Productivity Press, Portland, OR. 1990
Omar, A. R., Harding, J. A., and Popplewell, K. (1999), "Design for Customer Satisfaction: An Information Modelling Approach," Integrated Manufacturing Systems, 10, 199-209.
Pande, P.S., Neuman, R.P., Cavanagh, R.R., The Six Sigma Way: How GE, Motorola and Other Top Companies are Honing Their Performance, McGraw-Hill, 2000, New York
Reinertsen, D. (1997), Managing the Design Factory, Freedom Press, New York.
Stankosky, M. editor (2005), Creating the Discipline of Knowledge Management: The Latest in University Research, Butterworth-Heinemann, Burlington, MA, 2005
Suh, N. P., (1990), The Principles of Design, Oxford University Press, New York, 1st edition.
Womack, J. P., Jones, D. T., and Roos, D., (1990), The Machine that Changed The World, Rawson Associates, New York
Yang, K. (2008), Voice of the Customer Capture and Analysis, McGraw-Hill, New York.
Yun, J., and R. Chua (2002), “Samsung Uses Six Sigma to Change Its Image,” Six Sigma Forum Magazine, vol. 2, no. 1, November, pp. 13–16. |
|
|
