T-DMAIC For Teams

DMAIC for Teams
Section 1: Team Tools in Define

Section 2: Team Tools in Measure
Section 3: Team Tools in Analyze
Section 4: Team Tools in Improve
Section 5: Team Tools in Control
Section 6: Team Tools in Realize
© Lean Methods Group. All rights reserved. No portion may be copied, rewritten, reproduced, or published.
Page 1 of 52
DMAIC for Teams
Module Objectives
In this module we are going to discuss the responsibilities for team members that participate on Six Sigma teams
in the define phase, the measure phase, the analyze phase, the improve phase, the control phase, and the
realization phase.
Page 2 of 52
DMAIC for Teams
Section 1: Team Tools in Define

Define Phase
We’re going to talk about each phase and your role as a team member in that phase.
The purpose of the define phase is to make sure project objectives and metrics are clearly defined. Team
members also need to be selected during the define phase.
This is important information because you as a team member need to understand how the project could
potentially impact your daily work. You will also want to support and sanity-check the Black Belt and Champions
definition of the project itself. That will require you to assist with potentially any application of affinity diagrams and
understanding metrics, the types of metrics there are, and how they are used in the definition of a project
objective.
Although there are many tools the Six Sigma team will apply in the define phase, these are the two that will most
likely involve team participation.
Page 3 of 52
DMAIC for Teams
Project Metrics Defined – Part 1
As a team member you need to understand the different types of metrics that are out there. This slide is going to
define the different types of project metrics.
The first metric is something called the business metric.
This is a high-level metric that Champions care about. These metrics are usually directly related to the health
of a business or of a functional area within a business. For example scrap rates, or yield rates, or overtime
hours, or things along those lines. They are very high-level to the business.
Secondly, we have process metrics.
Process metrics is what the Black Belt and team members can actually do something about. This metric is
measured directly from the process; it’s usually an output of the process. We also call process metrics
primary metrics for the project. These are usually items like height, or weight, or defect rate, something that
you can measure directly from the process. You as a team member will assist the Black Belt in collecting data
on process metrics, so be ready.
Page 4 of 52
DMAIC for Teams
Project Metrics Defined – Part 2
Next, there’s financial metrics.
Financial metrics are how we measure how well the project is doing relative to saving our organization money.
Financial metrics are translated from business and process metrics, and are usually defined by the finance
rep. They always include some kind of estimation of dollars.
And lastly, but very importantly, is something called the consequential metric.
Any time you impact the process in a positive manner, you risk the potential possibility of something negative
happening to counteract this gain. So consequential metrics are what we watch to prevent any negative
consequences to our process. They are what keep us honest and what makes sure we don’t just shift costs
from one bucket of a project to another. I’m sure your Six Sigma team leader will ask you to help define the
consequential metrics of a project.
Page 5 of 52
DMAIC for Teams
Primary Metrics
Let’s take a closer look at the process metrics.
These are the primary and consequential metrics that you as a team member will help the Black Belt improve.
Most of the time the primary and consequential metrics can be lumped into one of the following three categories:
 Either a cycle time project;

 A defect rate project; or
 A consumption project.
A cycle time metric is measured in terms of cycle time per unit. Cycle time projects can be tricky to measure, as
we don’t always standardize when the clock starts and stops.
A defect-based metric can be a DPU, that’s defects per unit, a RTY rolled throughput yield, or a PPM parts per
million, or even a percent defective or DPMO.
And lastly, we can use the consumption category to define a Six Sigma project primary metric. This is a metric
which measures the ability of a process to consume a particular resource such as a raw material or electricity.
For every project a primary metric needs to be defined. Once a primary metric is defined we can also identify
consequential metrics.
Page 6 of 52
DMAIC for Teams
Consequential Metrics
A consequential metric is something that can be measured that can potentially go wrong if you are successful in
improving the primary metric. It measures any potential negative consequences; hence it’s called a consequential
metric. Let’s look at some examples.
In the first case, a cycle time reduction project, we could argue that adding labor would usually reduce the cycle
time of some process. You have more people hence you can do it faster, but adding labor to speed up the cycle
time is actually a negative consequence and not desirable.
Adding labor will add cost and obviously that is counter-productive to the intent of a Six Sigma project. So in the
ideal case we should be able to reduce cycle time without adding labor and therefore labor is tracked as a
consequential metric. If the primary project metric is a defect rate such as a DPU, PPM or RTY, some may argue
that we have high defect rates because we rush through our production processes. And if we were allowed more
time, we could actually reduce our defect rate. So again with Six Sigma we don’t want to decrease defect rate at
the expense of increased cycle time. Therefore a possible consequential metric for a defect project is cycle time
per unit.
In the last example, consumption is the category for the primary metric. Let’s assume our project deals with
reducing the consumption of a certain raw material. There is a potential that you may negatively affect your quality
level if you use less raw material. Maybe the strength of your product, for example, will suffer if you use less
aluminum in it. So a quality metric, such as how much strength your product has, can make a great consequential
metric for a consumption project. In summary, the primary metric tracks the gain of a Six Sigma project; the
consequential metric keeps us honest.
Page 7 of 52
DMAIC for Teams
Establishing a Project Objective
Once the project metrics are defined for a project we can set the objectives for the project. This is typically done
by the Champion, but the team members need to make sure they sanity-check this information.
Let’s assume we have a project that has a primary metric of rolled throughput yield. The rolled throughput yield is
the primary metric. Whenever we set objective statements for a Six Sigma project they must be written in the
following format:
We must improve some primary metric from some baseline level to some target level by some specific time
frame.
And we are going to track that primary metric over time. So in this particular chart we can see that our baseline is
running at roughly 87% rolled throughput yield. In our target we want to be at roughly 98%.
So we can write our project objective statement for the project as improving rolled throughput yield (our primary
metric) from 87% (our baseline level) to 98% (our target level) by, say, January 1, 2003. And then, we can track
our performance to that objective statement throughout the course of the project.
Many times in the define phase of a project we can’t fill in the baseline level or the target level because we don’t
have any historical data. One key role of a team member is to assist the Six Sigma Black Belt with obtaining that
baseline data and that oftentimes requires the team members to implement a data collection system.
Page 8 of 52
DMAIC for Teams
Affinity Diagrams
The affinity diagram is a tool for freely generating the collected ideas into different topics. If any of you know the
definition of affinity, the definition out of Webster’s Dictionary says that we have a tendency or a slant towards one
thing or another. So here, our goal is to lump all the potential ideas into categories that represent an affinity for all
of the post-it’s under that idea.
The simple process for actually applying an affinity diagram is first, and most important, you state the clear
problem that you want to brainstorm affinity ideas for.
Second, you go about and you generate these ideas on the problem in question, writing them down on cards or
sticky notes.
Next, or third, you arrange the cards or sticky notes into their related groups or affinities.
And last, you create a title or a heading for each group. Just remember that this tool is used to help clarify the
problem in the define phase of training, not to actually generate any solutions
Page 9 of 52
DMAIC for Teams
Create an Affinity Diagram (Activity)
In this activity, you will be given a problem to work on with an Affinity Diagram. After reading the problem, sort and
group ideas by dragging each note into the category to which you think it belongs. Then click the “Check
Answers” button.
When you are finished with this activity, please click the “Continue” button at the lower right hand corner.
Press “Start” to begin.
Page 10 of 52
DMAIC for Teams
Section 2: Team Tools in Measure

Measure Phase
We have now described how the team members are going to assist the Six Sigma project leader in the define
phase. In the measure phase you have some important responsibilities as well.
In the measure phase the job of the whole team is to evaluate and document the current state of the process. We
can do that through the application of tools like process maps, fishbones, and cause and effect matrices. So your
role as a team member is going to be to help with the application of these techniques.
In addition to brainstorming tools in the measure phase, we also have more technical tools called Gage R&R and
capability analyses. As a team member, your Black Belt will need help in collecting data to conduct and
implement both gage studies and capability analyses. We will introduce them later here in this module just so you
have a brief understanding of each.
Page 11 of 52
DMAIC for Teams
Process Mapping
One of the absolutely, positively most important tools in the measure phase is the process map. Process mapping
exercises can be very, very critical to the success of Six Sigma projects, especially those in transactional
environments.
When we first apply process mapping we document the process and we might find that it appears to be quite
simple, it may only include two or three tasks. The work of the team is to actually come in and figure out the true
process.
Almost always the true process in practice requires many more steps than is typically documented or thought to
exist. So the role of the team members in process mapping is to make sure that the actual process gets
documented and understood. Once the actual process is documented and understood, we can then truly work
from a good foundation to improve the process.
Page 12 of 52
DMAIC for Teams
Cause and Effect Fishbone
One other technique that’s commonly applied in the Measure phase is the Fishbone or Cause and Effect diagram.
The Fishbone diagram takes a particular business issue at the head of the fish and assigns different categories of
causes that can cause that error or defect or problem to occur. Those categories of the fish are driven, in part, by
the type of environment the project is in.
In a manufacturing environment, those categories are typically:
 Personnel,
 Material,
 Measurement,
 Environment,
 Machine and
 Method.
In a transactional environment, the categories are commonly:
 Places,
 Policies,
 Procedures and
 Personnel.
Let’s take a look at an example.
Page 13 of 52
DMAIC for Teams
Cause and Effect Fishbone
A financial services company has a large group of people transferring data from paper forms into a computer
database for a payout from a retirement plan.
The problem, listed at the head of the fish, is that the cycle times of the entry have high variation. The company
wishes to reduce the average cycle time of entering data.
In the Places category, the company has two data entry operations: East Coast and West Coast. This could be a
source of variation. In addition, in both sites they have entry associates in two types of office layouts: individual
cubicles and open bay offices.
Under the Personnel category, general experience with data entry could be a factor in cycle time, as well as how
long an associate has been working at this particular company doing this task.
You may want to take a moment and read through the other items.
Because the fishbone is such a great brainstorming tool, team member involvement is critical. The first time we do
a fishbone, we want to make sure we brainstorm any and all possible causes that might be affecting the issue at
the head of the fish.
Page 14 of 52
DMAIC for Teams
Cause and Effect Matrix – Ranking the Outputs
The Cause and Effect Matrix — C & E Matrix for short — is another great brainstorming tool for teams. It is an
effective way to help rank the inputs of the process by the customer priorities.
At the end of the process mapping, a Six Sigma practitioner may have dozens of potential inputs. The C&E Matrix
helps prioritize the effort – that is, arrive to a semi-scientific conclusion of the relative importance of each input.
The team then agrees to work on the most important items, as scored by the C&E matrix.
The procedure for constructing a C&E Matrix is as follows:
The first step is to list the outputs that the customer cares about across the top of the form. In this case, the
customer cares about receiving accurate, timely payment. Those are also called the Y’s, or the outputs, or
even the CTQ’s that are important to the customer.
This brings us to step 2 – ranking the outputs according to customer priorities relative to their importance on a
scale of 1 to 10; 10 being critically important and 1 being barely important. Notice here that the customer
cares about receiving the payment first, accuracy second and timeliness third.
Page 15 of 52
DMAIC for Teams
Cause and Effect Matrix – Scoring the Inputs
The third step is to list the Process Steps from the Process Map in the first column, then the process inputs,
also determined from the process map, in the next column. This example only has the first two steps of a
complex process listed: Participant Information Entry and Determination of the Reason for Distribution. The
input column then lists all of the inputs for each process step.
In this example, we have listed all of the data entries that contain the information that is required for
accurate, timely retirement plan distributions for the first two steps in the data entry process.
The longest part of the C&E Matrix process is the fourth step – scoring the inputs. For every input, the team
decides how to rank that input in relation to how it affects each of the selected outputs. For example, let’s
follow the rankings for Mailing Address.
In terms of receiving the payment and timeliness, the correct mailing address is critical, so it is ranked
nine on a scale of 1 to 10, 10 being the most critical. Accurate addresses have nothing to do with
accuracy of the payment, so the effect on accuracy is zero. These judgments are made for every input’s
effect on every output.
Page 16 of 52
DMAIC for Teams
Cause and Effect Matrix – Totals
The final step for the C&E Matrix is to calculate the score for each input. The score is the sum product of the
individual input scores and the output score. Let’s use the Social Security Number as an example:
 For the output “Received Payment (Output Score 10),” the Input score is 9. We multiply 9 times 10 for
the first column,
 Then 9 times 9 for the second column “Accuracy of Payment;”
 Then 9 times 7 for “Timeliness” and add the products together.
That is, 90 + 81 + 63 equals 234. This process is continued for all of the inputs.
You can see the scores for each input on the right side of the matrix in the Total column.
Interpretation is simple: The inputs with the largest scores have the highest importance. In other words, when
it comes to this activity, the priority list is highest inputs first. We can see how we ranked each of the inputs in
the Totals column which helps us identify areas of focus for the project.
Page 17 of 52
DMAIC for Teams
Cause and Effect Matrix – Conclusions
Since the C&E Matrix is based on collective opinions, sometimes the first few highest ranked inputs are the
obvious ones. In other words, no surprises.
But very often, the next group will contain some important nuggets. Many times, the sources of unwanted
variability are found in the second and third tier responses.
In this example, ensuring that the Social Security Number is correct is of highest importance so it falls into the first
tier, with all of the fields relating to mailing address and plan type in the second tier. And the phone number field,
employer and date of birth in the third tier.
In this example, as we will discuss later, the SSN is one of the fields that is optically scanned for increased
accuracy. Unfortunately, the mailing address, except for zip code, is one of the manually entered fields with a high
probability of errors.
Page 18 of 52
DMAIC for Teams
Cause and Effect Matrix – Conclusions
It’s important to remember the Cause & Effect Matrix is a team tool. The C&E team should be the same as the
process mapping team, but a couple of additions to the team may be in order.
For instance, since you are attempting to rank customer priorities, an actual customer or a staff member from
customer relations might be a welcome addition to the team.
The key to developing a meaningful C&E matrix is having a team that is actively engaged in identifying and
ranking critical inputs and outputs, so be prepared to actively participate with your team.
Page 19 of 52
DMAIC for Teams
Measurement Systems Analysis
In order for us to be able to move along through DMAIC on a Six Sigma project, we need to verify that we can
accurately and precisely measure each of our inputs and outputs in a process. In order to assess the capability of
our measurement system, to measure our inputs and outputs accurately, we can conduct what are known as
Gage Studies or Measurement Systems Analysis studies.
Both variable gages and attribute gages can be assessed using R&R, or Repeatability and Reproducibility studies.
By the way whenever you hear someone say Gage Studies or R&R, or MSA, they all mean the same thing, they
are used interchangeably.
Some examples of variable gages are voltmeters, calipers, graduated cylinders, reflectometers, pressure gauges,
thermometers. We can also use clocks, because clocks measure cycle time as a variable gauge.
Some attribute gauges are feeler gauges, go/no-go gauges, and any and all visual inspection is also an attribute
gauge, and needs a measurement systems analysis study to qualify it.
Your Black Belt or Six Sigma project team leader is going to need your help in executing these gage studies, and
that usually involves collecting data on certain parts of the process or measurement system.
Page 20 of 52
DMAIC for Teams
Transactional Gages
A common misconception is that gage studies are only for manufacturing projects. There are many instances
where an analysis of a transactional measurement system will provide necessary insight into the process and the
problem.
Consider the financial services example we have been discussing, where personnel are entering data from a
paper form into a computer database. In this case, one of the measurement systems analysis or MSA’s we might
run regards the ability of an optical scanner to repeatedly scan the social security numbers from hand printed
forms into the database.
In addition to the optical scanner, a random sample of applications are manually checked by the Quality Control
department. This is an ideal place for an Attribute Gage study for the inspection process.
Can each inspector find the errors the same way as every other inspector?
Can they do it twice?
Page 21 of 52
DMAIC for Teams
Transactional Gages
Another application of MSA for transactional projects is the verification of resource utilization. For example, having
each associate keep track of their own cycle times and then compare them to the amount of time that a particular
file on the computer is open or active. Anyone who has contacted a call center has probably heard the recording,
“this call may be recorded for quality control purposes.”
Many times the Quality Control department reviews some of the call center’s daily interactions and scores
different characteristics of the calls. A common gage study is to play recorded calls to several Quality Control
operators and compare the scores from each of them.
Anytime there is measurement data, there is a need to verify the truthfulness and variability of that data. Even for
transactional projects, data can only be trusted when the measurement system has been verified.
Page 22 of 52
DMAIC for Teams
Capability
The last important tool in the measure phase that your Six Sigma Team Leader will need help with is capability.
Capability analysis represents how capable a process is to deliver to a particular specification.
In this illustration, we see that the plus and minus three sigma limits of a process lie within the design width. That
means that the upper and lower spec limits are actually outside the plus and minus three sigma limits of the
process.
Capability analysis will compare the process width to the design width, and give you a numerical quantification of
the capability of a process. These quantifications can be measured as CPK’s, defect levels, or sigma levels. Your
Black Belt will need your help in collecting data so that a capability measurement can be made on your process.
Page 23 of 52
DMAIC for Teams
Section 3: Team Tools in Analyze

Analyze Phase
We’ve covered your role as a team member now in the define phase and the measure phase. Let’s talk about
what you will help with in the analyze phase.
The purpose of the analyze phase is to collect data from existing processes and identify the critical variables.
Your role in the analyze phase will be first of all to assist with the creation of what is called a process F-M-E-A.
FMEA stands for Failure Modes and Effects Analysis. This is another great process brainstorming tool; I think
you’ll love it.
Your second role in the Analyze Phase will be to assist with passive data collection. Passive data collection on
input and output variables will be used by the Six Sigma team leader to explore and graphically analyze your
process. This passive data will also be used in a statistical manner to give results about which inputs and outputs
are in fact critical in the process.
Page 24 of 52
DMAIC for Teams
FMEA – Initial Assessment – Part 1
One of the brainstorming tools in the Analyze Phase is called the FMEA, or Failure Mode and Effects Analysis.
The first part of the FMEA is called the initial assessment. This is really a monster spreadsheet that documents all
potential FM’s, or failure modes, and their effects on a process.
When you complete an FMEA for the complete process it can be 20, 30 or 40 pages long. During a project, the
team will only start the FMEA for the portion of the process that they’re trying to address in the project. What we’ll
do here is walk through the columns of the FMEA just to familiarize you with the columns. As your Team Leader
takes you through the process, you will begin to understand each column in more detail. The example displayed
here continues our earlier scenario for transferring data from paper forms into a computer database.
The first column is the process function: these are the process step names. The two process steps illustrated
here are for verification of social security numbers and verification of addresses.
The second column is the actual potential failure mode: these are the ways that the process may potentially
fail to meet the process requirement and/or design intent. These are the actual defect names that you find in
your process, so you’re going to list the failure modes that can occur for each specific process function in the
second column.
Page 25 of 52
DMAIC for Teams
The third column is called the Potential Effects of Failure. The question that you can answer in this column is,
“What are the effects of each failure mode on the outputs and/or the customer requirements?” Meaning, if you
get a defect or a failure mode called “invalid Social Security Number,” what effect will it have on the customer
requirement? In this particular case, invalid Social Security Number would cause the application to be
returned to the customer, causing annoying delays.
Once you know the potential effect, you can then rank the impact of that effect on the customer.
That is the column called SEV, which stands for Severity. How severe is the effect to the customer? In this
case the severity was ranked at a three. The range can be anywhere between 1 and 10, 10 reserved for the
worst possible effect and 1 being used for practically no effect.
The fifth column is called Potential Causes of Each Failure. This is where the team can document how the
failure occurred, what were the root issues that could have caused this failure mode to occur? In this case,
invalid Social Security Number was caused by an unreadable entry that resulted in the application being
returned to the customer.
After you list your potential causes of failure, you want to document how often they occur, and that is done in
the column called OCC, or Occurrence. This is how often the cause of the failure mode occurs. Sometimes
we don’t track how often the cause occurs so then the number used in that column would be how often the
failure mode occurs. Here we have ranked it at six, and again the scale is 1 to 10.
Page 26 of 52
DMAIC for Teams
The next column, called Current Process Control, answers the question, “What are the existing controls and
procedures in place, typically test and inspection, that either prevent or detect when a cause or failure mode
occurs?” In this case we can make a measurement called Auto-read/Visual Inspection that detects when an
Invalid Social Security Number occurs or when it is unreadable.
Once we list our current process controls we can document how well they operate.
This is how well you can detect the cause or the failure mode when it occurs. Again, this is done on a scale of
1 to 10. Low numbers indicate a very good probability of detecting the cause or failure mode when it occurs.
High numbers indicate you have a very poor ability to detect the potential cause or failure mode.
The last, but probably one of the most important and most utilized columns of an FMEA is something called
the RPN. The RPN is simply the multiplication of the Severity column times the Occurrence column times the
Detection column. This column can range anywhere between 1 and 1000. One would be if your Severity,
Occurrence, and Detection were all documented as ones. One thousand would be if each of those numbers
was documented as a 10. Lower numbers mean you have greater control in your process; higher numbers
indicate there are issues that you may want to address within the project.
Page 27 of 52
DMAIC for Teams
FMEA – Actions and History
The second part of the FMEA worksheet is where you document what you can possibly do to fix high RPN issues.
Notice the column headings:
 Recommended Actions;
 Responsibility and Completion Date;
 And the specific Actions to be Taken,
 Followed by the new Severity, Occurrence, Detection, and RPN numbers that resulted after the
recommended actions were completed.
I’ll let you read through these at your leisure; you can always document team progress in an FMEA by using the
second half of the FMEA process. It’s where you can document the actions and history of a project to see how the
process was improved on its way to completion.
Page 28 of 52
DMAIC for Teams
Passive Data Collection
Team members are an incredibly important part of passive data collection. Passive data is utilized in the Analyze
Phase to make sure that we identify critical variables.
Passive data means collecting data from the process as it runs in its standard mode passively, meaning we don’t
actively go change anything in the process when collecting this data, we just let it run in its natural state.
Collecting data means we collect data on both our process input variables, and our process output variables at
the same time.
From passive data collection, we are able to identify sources of variability in the process. Specifically what we’re
usually looking for is variability in the means. Which input variables can cause our means to move around? We
can also and sometimes harder to find, identify variables, input and output variables, which cause variability in the
standard deviation of our process. That’s the spread of our distribution. Passive data collection will facilitate
finding out which input variable caused variation in our outputs.
You as team members play a critical role in identifying and documenting that data so that we can determine which
inputs caused variation in our outputs.
Page 29 of 52
DMAIC for Teams
Section 4: Team Tools in Improve

Improve Phase
We have now covered your role as a team member in the Define Phase, the Measure Phase, and the Analyze
Phase. Now we’re going to talk about what you can do to help the team achieve its goal in the Improve Phase.
The purpose of the Improve Phase is to use designed experiments to determine and characterize the process.
This means we’re seeking to find “Y” as a function of “X”. Meaning, which outputs of the process are functions of
which inputs. If we can achieve this equation, and determine Y as a function of X, we are very, very close to
implementing improvements that will sustain us long-term.
Your role as a team member in the improve phase is to assist with the planning and execution of any appropriate
designed experiments. You will also be part of actively changing the process and collecting data on it.
Page 30 of 52
DMAIC for Teams
Active Data
Designed experiments require us to actively change the process. Let’s list the different types of inputs that we
may have to change. We have some process that exists. That process has controllable inputs coming into it.
Controllable inputs are inputs that can be intentionally changed by the users or designers of the process.
In our example, the layout of the paper form and the layout of the data entry screen are controllable inputs. Ideally,
all of the inputs that might affect the outputs would be controllable; unfortunately that’s not the case. We have two
other categories of inputs. One is called discrete input noise variable.
Discrete noise variables are variables that cannot be measured on a continuous scale but may have some
impact on the process.
For example, different operators, different sites, different days of the week are all discrete noise variables. The
process is intended to run exactly the same, but it actually varies, according the level of noise variable. For
example, in our data entry center, we noticed that Monday has a lower cycle time and a lower error rate than
Tuesday, Wednesday and Thursday. Friday has a higher cycle time and error rate. Why? We don’t know yet, but
these variations are noticed and the team begins to try to understand how days of the week can affect the
process. The last type of input variable that comes into a process is called a continuous noise variable.
Continuous noise variables are variables that we can’t or don’t control that can be measured on a continuous
scale.
Page 31 of 52
DMAIC for Teams
For example, the number of users on the data entry system, or the transaction volume. We can measure these
inputs, and they might affect our important outputs, cycle times and errors, but we don’t usually control them.
Page 32 of 52
DMAIC for Teams
Active Data – Continued
The goal of the Improve phase is to identify the relationships between all the critical inputs and the outputs. This
will require the team member’s support to assist with data collection and modifications that need to be
implemented within our process to make sure we can study any active changes within the process. Sometimes
that requires us to establish controls to be set and maintained at the correct levels on previously uncontrolled
noise variables. In many cases, we must understand the relationships between the uncontrollable noise variables
so we can compensate for their effect with another control variable.
For example, we might want to find that transaction volume, a continuous noise variable, has a large impact on
cycle time. Also, it was differences in transaction volume throughout the day that caused our cycle times to vary
throughout the day. We might have to design a scheduling system, a controllable input, to level the transaction
volume across the day so cycle time doesn’t vary so much.
The point of Active Data collection, aka experimentation, is to establish these cause and effect relationships
between the control and noise inputs and the outputs.
This is the focus of Six Sigma – determining Y as a function of X.
Page 33 of 52
DMAIC for Teams
Experiments Defined
The biggest part of the improve phase is the execution of designed experiments. So let’s see what Douglas C.
Montgomery, a famous author, college professor, and practitioner of designed experiments, has to say about the
definition of a designed experiment. Here is his definition for a DOE or design of experiment:
“An experiment is a test or series of tests, in which purposeful changes are made to input variables of a
process or system, so that changes in the output responses can be observed and identified”.
The key points here are, that through designed experiments, we’re making not arbitrary, but purposeful, specific
intentional changes to a process and often times we try to exaggerate those changes so that we can measure the
effect that change has on our output. These purposeful changes are made to process input variables, and again
they’re exaggerated so that if they do affect the output we’ll be able to see the effect relatively quickly.
The whole point here is to make sure that we can characterize “Y” as a function of “X” and designed experiments
will allow us to do so.
Page 34 of 52
DMAIC for Teams
Experiments for Transactional Projects
Experimentation is as critical for the transactional projects as it is for the manufacturing projects. Experimentation
is just another name for active data collection.
The most efficient way to characterize a process is by a statistically Designed Experiment, even in the
transactional world.
Briefly, a Designed Experiment, or DOE, is defined as a test, or series of tests, in which purposeful changes are
made to relevant input variables of a process or system so that the change in the output responses can be
observed and identified. One of the primary things a DOE helps us to determine is the relationship of Y as of
function of X in our process.
Page 35 of 52
DMAIC for Teams
Experiments for Transactional Projects
Let’s look at a couple of examples.
A common application of DOE in the transactional world is in Marketing. Establishing the correct combination of
mailers, advertisements, personal contact, and follow up can be crucial to the success of a product.
Another example is bill collecting. A hospital wanted to increase the efficiency of collecting from its clients. They
designed an experiment to examine when it was best to send the bill, the reminder letter, a follow-up courtesy call,
and the timing of each of these. The hospital wanted to decrease the number of outstanding bills sent to its
outside collection agency.
Page 36 of 52
DMAIC for Teams
Experiments for Transactional Projects – Continued
Returning to our data entry example, the paper forms that the client fills out are downloaded from the Internet and
printed. The company did an experiment on readability by the auto-scanner looking at the factors:
 Type of printer – laser or inkjet;

 Type of writing instrument used – blue ink, black ink, or pencil;
 Paper type – pure white or partial recycle; and
 Form type – 2 sided, folded 11x17 or 4 page, 8 ½ by 11.
Finally, the most common type of transactional experiment is for sorting out individual process differences.
Commonly the factors are different methods of doing the process at several critical points. A DOE is conducted to
determine which combination of the choices provides the best output. In addition to finding the best operating
point, a well-designed DOE can provide information about the amount of variation and/or degradation that can
accompany using the other settings. This can convince people to run the process by the “correct method.”
Page 37 of 52
DMAIC for Teams
Designed Experiments – Conclusion
The challenge to executing designed experiments is setting up the treatment combinations and running them in a
controlled manner on our process. It’s important to recognize that setting up and running designed experiments
can be a timely and costly endeavor. In addition, the objectives of the DOE and a plan for executing the
experiment must be clearly communicated to everyone on the team in order to ensure its success.
While designed experiments do require a financial and a time commitment from management and from team
members, the return on a DOE can be truly limitless in terms of the information you can gather about your
process.
The meaningful information collected can be used to optimize and streamline processes to improve efficiency and
ultimately boost your bottom line. Therefore, we should work hard to provide the right support and the right culture
to make designed experiments part of our everyday working environment.
Page 38 of 52
DMAIC for Teams
Section 5: Team Tools in Control

Control Phase
We’ve covered Define, Measure, Analyze, and Improve. Now were going to talk about what your role is in the
Control Phase.
The Control Phase is where the rubber meets the road. It’s where we implement all our learnings from the prior
phases and hopefully make sure that we can sustain our gains long-term.
The purpose of the control phase is to optimize process output variables and implement the solution that was
discovered by the team.
Your role in this phase is to take ownership of the solution that your team has recommended, and secondly to
drive the implementation of the control plan to the process.
Page 39 of 52
DMAIC for Teams
Introduction to Control Plans
As a Six Sigma team takes a business issue through the DMAIC process, many things are learned. Many things
are also changed in the process. In order for your process to stay optimized, a document is used to describe all
the items that need to be controlled in order for your process to stay healthy.
The items that you need to control for a process to stay healthy are:
 The location of data that’s critical to the process;

 Who the individuals responsible are for that process;
 Any process documentation like process maps or FMEA’s;
 Any decision rules that are made relative to when a process goes out of control;
 The process flow diagram, any process controls such as mistake proofs or SPC charts;
 Any methods used in the process like procedures and how to run the process;
 How often you need to sample and how many items you need to sample for making sure the product is
defect-free;
 Any measurements of process characteristics; and
 Any preventative maintenance items.
All of these items are documented in the Control Plan. The Control Plan becomes a living document that the
process owners and process doers use to make sure that the gains of the Six Sigma project are maintained long
term.
Page 40 of 52
DMAIC for Teams
Control Plans
Here we see an example of a small part of a control plan for our data entry example. Let’s just follow the last row
across the plan called Manual Data Entry.
The first column is the process step. This should be taken directly from the process map. All process step names
should be coherent across all the tools in a Six Sigma project.
Column two is a description of what is controlled. In this case we are looking to determine the average utilization
of our associates.
In the third column, we want it identified as an input or an output. Early in a project, many of the items entered on
a control plan are outputs. By the end of the project, it is desired that they be mostly inputs. Input control is the
goal. In this case, unfortunately, utilization is an output. But notice the first three rows: these are inputs that we
are controlling in the process.
The fourth column is the requirement. In the Manual Data Entry step, it is desired that the associates be utilized
70 percent on average, actually entering data from the forms into the database.
Page 41 of 52
DMAIC for Teams
Control Plans – Continued
The next columns are about the measurement system.
For Measurement Method, we are using a software package called CustTrac. It records the amount of time the
associate is actively entering data into a particular file. The software totals the time the associate was entering the
data and compares it to a typical 8 hour cycle.
The next column is the method of control used on the process. In other words, how do we use the measurements
to provide control information? In this case, the data will be tracked on an Xbar and S control chart.
The next two columns refer to sample size and frequency. Following our example, we will be randomly sampling
50 associates every day and plotting the data on the control chart.
Who does the measurement? That is the subject of the next column. For the control chart, it will be up to the
Section Manager to keep track of the information.
The next column is location of the information. This control chart will be displayed on the Productivity Statistics
bulletin board.
The next to last column is about the decision rule. What do we do with the control information? In this case, the
best section gets a reward. In fact, this data is actually going to be used for another project later.
The last column is to identify the process documentation that concerns the control process for that input or output.
Page 42 of 52
DMAIC for Teams
Control Plans – Summary
In summary, a Control Plan is a list of all the activities that we need to execute to control a process.
It is also a method of identifying any holes that exist in the control system.
It is a list of control activities yet to be implemented, and it can serve as an input to the FMEA for a mature
process, or an output of an FMEA for a new process which is typically the case with Six Sigma projects.
Page 43 of 52
DMAIC for Teams
Team Activities
The team members of a Six Sigma project have very important activities in the Control Phase. After the Control
Plan is written, it’s time to actually make this Control Plan a living document. Several activities by the team
members can assist in this effort.
 First of all, we’re going to develop improved methods of work, new standard operating procedures, and
new process maps will help us to deliver a healthier process.
 Secondly, we’re going to establish and document the optimized process. This can involve additional data
collection along with maintaining of some records longer term.
 Third, the Six Sigma team leader should be able to move on, which means that we need to close the
project, and the team, along with the process doers, need to inherit the results of the solution, and need
to maintain that solution long-term.
 This will also require educating non-team members in the new process. You may be asked as a team
member to help in this endeavor.
Page 44 of 52
DMAIC for Teams
Project Transition Action Plans
Have any of you heard of an action plan?
An action plan is a document that lists all of the activities required for some project. Well a Six Sigma project
has an action plan as well; it’s called the Project Transition Action Plan or P-T-A-P.
The Project Transition Action Plan lists any and all activities that team members, process owners, Black Belts,
Green Belts, maintenance personnel, or any supporters of this project need to do to actually finish the project.
We have an example here of a project titled the “Form Processing Cycle Time” and we’re going to document just
some ideas that may appear on a project transition action plan.
The transition owners are Tracy Lord and George Kittrich. They are going to work closely with the team leader,
typically a Black Belt, to implement and make sure that these activities happen. Making these activities happen is
going to be key in making sure the gains are sustained long-term, and we are able to close the project
successfully.
The third item listed at the top of the project transition action plan is simply the plan date. That’s just the date this
document was created. We notice here that there are five actions listed that will be required for completion of the
project. Each item has an action owner, somebody who’s going to be responsible for making that item happen,
the initials of that individual, the scheduled completion date, as well as the actual completion date.
Page 45 of 52
DMAIC for Teams
Project Transition Action Plan – Example
For example, some items that we may find on the Project Transition Action Plan are installing the remaining Opti-
scans. This will be completed by George Kittrich. Scheduled date is August 1st. As we use this plan, we track the
actual completion date when it happens as a record. In some cases, we may find discrepancies on our project
financial forecast, so tracking the actual completion dates might help explain some of this.
Some additional actions are required. For example, transferring the improved process from the East Coast office
where the project was conducted to the West Coast office. This will be the responsibility of C.K.D. Haven. So we
notice that we can keep going with these normal actions to be completed and then the transition owner should
track these actions to make sure they get done over a short time.
And the last, and probably most important portion of the Project Transition Action Plan, are the signatures. That
means we need to make sure that the individuals whose names are listed as the action owners on this document
buy in to the fact that they will be responsible for these activities. So we have some signatures required at the
bottom.
This becomes a healthy working document for making sure all activities are completed for the successful
implementation and transition of the project back to the process doers and away from the project team leader.
Page 46 of 52
DMAIC for Teams
Section 6: Team Tools in Realize

Realize Phase
The Realization Phase of the Six Sigma project is an exciting time. This is where we get to celebrate our gains
and successes.
The team members, along with finance, measure the results once the solution is in place, and this happens in the
Realization Phase. The role of the team members is to ensure ongoing process controls are maintained. This just
means that we want you as team members to take ownership and ongoing implementation of the Control Plan.
Tools that are utilized during this phase relate to tracking project metrics and project savings. The team members
can be involved in tracking the metrics and finance is involved in tracking the savings.
Page 47 of 52
DMAIC for Teams
Money Matters – Tracking Financial Metrics
The most important reason why we execute Six Sigma projects is because they have meaningful bottom line
impact to our organization. In the Realization Phase, finance representatives are tasked with monitoring and
tracking the gains of Six Sigma projects for the following twelve months.
Usually Six Sigma projects are targeted at reducing costs in an organization, and we should just understand that
that will, long-term, lead to increased profits. The finance reps do this by tracking financial benefits that tie directly
to our profit and loss statements or our balance sheets. So every month finance reps will take a look at monthly
reports and make sure that the gains from your Six Sigma project hit the bottom line.
This requires you, as team members, to understand some level of financial metrics as well as process metrics.
The reason we track financial benefits is so we can roll up many Six Sigma projects and track the savings from
multiple projects over time. Thus the finance reps track the financial metrics of a project over time.
Page 48 of 52
DMAIC for Teams
Process Matters – Tracking Process Metrics
While finance reps track finance metrics, team members track process metrics, and boy, do they matter.
A common project metric is one that comes and can be measured directly from the process. For example, PPM or
parts per million in thousands. Over the life of the project we are obviously trying to improve this process metric.
As this bar shows, we have done a pretty good job.
Once the project is closed and you are in realization, you want to track that process metric long-term to make sure
it stays in control. So as an active, valuable team member, we’ll ask for your assistance in the data collection to
make sure our process metrics stay in control.
Page 49 of 52
DMAIC for Teams
Name That Tool (Activity)
In this activity, you will be presented with several of the tools you have just seen. Each tool will describe itself.
Can you name each tool correctly?
When you are finished with this activity, click the “Continue” button in the lower right hand corner.
Press “Start” to begin.
Page 50 of 52
DMAIC for Teams
Tools by Phase (Activity)
Please click on a tool, then click on the phase where it’s used.
Page 51 of 52
DMAIC for Teams
Module Review
Team members are the most important critical players on a Six Sigma team. Hopefully you’ve learned in this
module what it takes to be a valuable team member throughout the phases of the Six Sigma methodology.
Page 52 of 52

T-DMAIC For Teams

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

T-DMAIC For Teams

Загружено:

Авторское право:

Доступные форматы

DMAIC for Teams

Section 1: Team Tools in Define

Section 1: Team Tools in Define

Project Metrics Defined – Part 1

The first metric is something called the business metric.

Secondly, we have process metrics.

Project Metrics Defined – Part 2

Next, there’s financial metrics.

Let’s take a closer look at the process metrics.

 Either a cycle time project;

Establishing a Project Objective

Create an Affinity Diagram (Activity)

Press “Start” to begin.

Section 2: Team Tools in Measure

Cause and Effect Fishbone

In a manufacturing environment, those categories are typically:

In a transactional environment, the categories are commonly:

Let’s take a look at an example.

Cause and Effect Fishbone

Cause and Effect Matrix – Ranking the Outputs

The procedure for constructing a C&E Matrix is as follows:

Cause and Effect Matrix – Scoring the Inputs

Cause and Effect Matrix – Totals

Cause and Effect Matrix – Conclusions

Cause and Effect Matrix – Conclusions

Measurement Systems Analysis

Section 3: Team Tools in Analyze

FMEA – Initial Assessment – Part 1

FMEA – Initial Assessment – Part 2

FMEA – Initial Assessment – Part 3

FMEA – Actions and History

Passive Data Collection

Section 4: Team Tools in Improve

Active Data – Continued

This is the focus of Six Sigma – determining Y as a function of X.

Experiments for Transactional Projects

Experiments for Transactional Projects

Let’s look at a couple of examples.

Experiments for Transactional Projects – Continued

 Type of printer – laser or inkjet;

Designed Experiments – Conclusion

Section 5: Team Tools in Control

Introduction to Control Plans

 The location of data that’s critical to the process;

Control Plans – Continued

The next columns are about the measurement system.

Control Plans – Summary

Project Transition Action Plans

Have any of you heard of an action plan?

Project Transition Action Plan – Example

Section 6: Team Tools in Realize

Money Matters – Tracking Financial Metrics

Process Matters – Tracking Process Metrics

Name That Tool (Activity)

Press “Start” to begin.

Tools by Phase (Activity)

Вам также может понравиться