Which of the following is a dfss methodology

Understanding Six Sigma, Root Cause Analysis, and Lean
With the myriad of Six Sigma variations and buzzwords throw around every day, it can get confusing as to which technique you should use to solve different kinds of problems. Use the attached framework to put the various methodologies into perspective.

(For a detailed explanation of each technique refer to the following sections.)

Problem Recurrence

Problem Complexity

One Time/In Frequent

Frequent

Simple

Root Cause Analysis

DMAIC – Define Measure Analyze Improve Control

Complex

DFSS – Design for Six Sigma

DMAIC – Define Measure Analyze Improve Control

The inherent logic behind using these methodologies is as follows:

If this is a one-time problem and the solution is relatively simple then the rigor of using a multi-step methodology may be overkill and can actually detract from the adoption of Six Sigma within your organization. Instead, you should resolve the problem using a simpler methodology knows as Root Cause Analysis (RCA). It is critical to understand that RCA is an iterative process-- you may have to go through multiple iterations to actually get to the root cause.

If you are unsuccessful at resolving the problem after a few iterations at root cause, you should realize that the problem recurrence is not one time nor simple and move on to the Define Measure Analyze Improve Control (DMAIC) methodology. The DMAIC methodology is most effective for - improving well defined operating processes that require the reduction of defects.

However, if you are faced with a complex problem such as development of a new software solution that will occur one time where the cost of failure is high, using a Design for Six Sigma (DFSS) or Design Measure Analyze Design and Verify (DMADV) process is the way to go.

What is Lean?
Lean has a tool set that is geared to improve process flow. Six Sigma was designed to specifically focus on process variation. If you are to consider the problems we face in IT everyday around performance or improving the speed of processes, the lean methodology is ideal for attacking those kinds of problems. For instance, suppose you have a batch process that prints invoices everyday which can’t commence prior to 1 am and needs to be complete prior to 6 am. This problem can be solved using both Lean and Six Sigma toolsets depending on the constraints of the problem.

Let’s suppose you observe the problem and notice that the process always starts at 1 am and completes anywhere between 3-7 hours on any given day. In that case, the process variation is what is causing the defect and a DMAIC methodology would be appropriate to use. If, on the other hand, you notice that it usually takes the job anywhere from 6.5 hours to 7 hours to complete (very small variation), then a lean toolset would be more effective since your focus is really on improving the overall throughput (cycle time) of the process rather than reducing the variation around the process. In the real world, these problems are related to both process variation and cycle time so you can use toolsets from both methodologies hand in hand to attack the problem.

Root Cause Analysis facts
Root Cause Analysis generally is applicable in situations where a defect occurs and there is a possibility that it might be beneficial to identify and address the real cause so that the situation does not occur again. Simply put, RCA is finding the real cause of the problem and dealing with it rather than simply continuing to deal with the symptoms of that problem.

Consider the realm of Information Technology where quite often a server or piece of software will become unresponsive because the server runs out of disk space. When this happens, you can easily resolve the problem by making space available and getting the application functional again. However, did you actually address the root cause of the problem? Perhaps you should have determined why the server ran out of disk space in the first place. Walking through a systematic process using Six Sigma tools can help address these issues and improve the quality of IT processes.

General principles of root cause analysis
Aiming corrective measures at root causes is more effective than merely treating the symptoms of a problem. To be effective, RCA must be performed systematically, and conclusions must be backed up by evidence.

There is usually more than one root cause for any given problem.

Here is the general process for performing and documenting an RCA-based Corrective Action (note that this forms the most critical part of successful corrective action, because it directs the corrective action at the root of the problem):

Define the problem.

Gather data/evidence.

Identify issues that contributed to the problem.

Find root causes.

Develop solution recommendations.

Implement the recommendations.

Observe the recommended solutions to ensure effectiveness.

Root cause analysis techniques
The following tools can be used to attack problems using Root cause analysis techniques are included as part of the toolkit.

· 5 Whys

· Failure mode and effects analysis

· Pareto analysis

· Fault tree analysis

· Ishikawa diagram, also known as the fishbone diagram or cause and effect diagram

DFSS Facts
DFSS is the acronym for Design For Six Sigma. Unlike the DMAIC methodology, the phases or steps of DFSS are not universally recognized or defined -- almost every company or training organization will define DFSS differently. Many times a company will implement DFSS to suit their business, industry and culture; other times they will implement the version of DFSS used by the consulting company assisting in the deployment. Because of this, DFSS is more of an approach than a defined methodology.

DFSS is used to design or re-design a product or service from the ground up. Producing such a low defect level from product or service launch means that customer expectations and needs (CTQs) must be completely understood before a design can be completed and implemented.

One popular Design for Six Sigma methodology is called DMADV. The five phases of DMADV are defined as: Define, Measure, Analyze, Design and Verify.

Define the project goals and customer (internal and external) requirements.

Measure and determine customer needs and specifications; benchmark competitors and industry.

Analyze the process options to meet the customer needs.

Design (detailed) the process to meet the customer needs.

Verify the design performance and ability to meet customer needs.

A slight modification on the DMADV methodology is DMADOV: Define, Measure, Analyze, Design, Optimize and Verify.

Optimize uses advanced statistical tools and modeling to predict and optimize the design and performance.

Validate makes sure that the design you've developed will meet the customer CTQs.

As you can see, the DFSS approach can utilize any of the many possible methodologies. The fact is that all of these DFSS methodologies use the same advanced design tools (Quality Function Deployment, Failure Modes and Effects Analysis, benchmarking, Design of Experiments, simulation, statistical optimization, error proofing, Robust Design, etc.). Each methodology primarily differs in the name of each phase and the number of phases (and, of course, the acronym).

Lean Facts
Lean is a business system focused on managing processes and improving them by compressing time rather than keeping each of the assets busy.

Every organization is a collection of several primary value cresting processes (design and production) and a host of supporting processes (such as finance and maintenance). A process is a sequence of steps that must be carried out in proper order to create value for the customer and managed as a whole and not separately.

The best way to learn to see your processes is to take a product and follow its path from beginning to end—from order entry to delivery to the customer. Mapping what we call a value stream reveals how the current process operates today—not how it is supposed to operate. It also reveals all the wasted time and effort in the process. It is both a consciousness raising exercise for all those involved and a powerful diagnostic of how broken the current process is.

Key Principles of Lean Thinking

In their 1996 book Lean Thinking, James P. Womack and Daniel T. Jones defined a set of five basic principles that characterize a lean enterprise:

Specify value from the standpoint of the end customer by product family.

The critical starting point for lean thinking is value. Value can only be defined by the ultimate customer. And it's only meaningful when expressed in terms of a specific product (a good or a service, and often both at once), which meets the customer's needs

You should begin by identifying all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value. The value stream is the set of all the specific actions required to bring a specific product through the critical management tasks of any business: the problem-solving task running from concept through detailed design and engineering to production launch, the information management task running from order-taking through detailed scheduling to delivery, and the physical transformation task proceeding from raw materials to a finished product in the hands of the customer

Your goal is to make the remaining value-creating steps occur in a tight and integrated sequence so the product will flow smoothly toward the customer focusing on speed and cycle time.

As flow is introduced, let customers pull value from the next upstream activity.

Lean enterprises can now make a revolutionary shift: instead of planning activities to operate by a forecast, they can now simply make what the customer tells them to make.

These steps lead to greater transparency, enabling managers and teams to eliminate further waste, pursue perfection through continuous improvement.