Define the Customer and Their Requirements
The focus of each project is the customer of the process. The customer is defined as the individuals or groups who receive the goods or services of the process. Customers can be external to the organization or an internal component of the organization. (For example, Human Resources has internal customers: the employees of the organization.)
During the Define Phase, the team seeks to better understand customers and their requirements. After interviewing or surveying customers, the team translates that information into measurable requirements that provide the team with insight on how to improve the process or solve the problem.
Tools: Voice of the Customer (VOC) Translation Matrix and Tree Diagram
Voice of the Customer (VOC) Translation Matrix
What is a Voice of the Customer (VOC) Translation Matrix?
The VOC (Voice of the Customer) Translation Matrix is a tool that helps teams take customer comments, determine the underlying issues represented by those comments and use this information to develop measurable customer requirements. The goal of this tool is to translate often vague comments into something concrete so that the team can focus their efforts to meet these requirements.
Voice of the Customer (VOC) Tree Diagram
What is a Tree Diagram?
A Tree Diagram is a type of chart where a concept is successively broken down into subconcepts with increasingly higher levels of detail. It therefore resembles a tree in its finished state, with the main concept serving as the trunk, while subconcepts branch off.
Inform Others of Project Progress
The team regularly updates the Project Sponsor, or Champion, of their progress and confirms they are on track to solve a worthwhile process issue. One of the best ways to update Sponsors and Stakeholders is the A3. The A3 is a customizable, one-page document used to easily communicate the team’s though process and the project status to others.
Another important group to stay connected to are the individuals who could be impacted by changes to the process being addressed. Stakeholder Analysis and management begins in the Define Phase and the team communicates with this key group throughout the project. This helps ensure they feel a sense of ownership and stay engaged throughout the improvement process.
A3
On a literal level, A3 refers to a ledger size (11×17) piece of paper. But in the Lean Six Sigma world, it is a tool to help see the thinking behind the problem-solving. Don’t mistake A3s as a document to be completed after the problem is solved. It’s important to use the A3 while working through the problem.
The practice of using A3s forces project teams to focus their efforts. At the same time, A3s make it easier for a leader or coach to review a problem solver’s work. A3s become valuable coaching tools since leaders can see and provide feedback on the problem solver’s thought process.
A3 Resources
The A3 Coaching Kit is a series of tools to support A3 Users, A3 Coaches and Mentors. The kit includes preparatory checklists, agendas, coaching questions, a method to track A3 User progress and space to capture A3 Coaching reflections. The A3 Coaching Kit supports the development of good problem-solving thinking by using the simple structure of the A3. The tools can be used for both virtual and onsite coaching sessions.
Relationship Map
What is a Relationship Map?
The Relationship Map is a visual mapping tool for listing and assessing the relationship of potential stakeholders to a given project. This is used in combination with the Stakeholder Analysis template.
Stakeholder Analysis
Measurement takes place throughout the life of a project, but a key question to answer in the Measure Phase centers on how the process currently performs. What is the magnitude of the problem? How bad is it?
As the team starts collecting data they focus on the process as well as what customers care about. That means initially there are two major targets: reducing lead time or improving quality.
During the Measure Phase, the team refines the definitions of each measure and determines the current performance—the baseline—of the process.
Determine How the Process Currently Performs
Teams establish the current state of the process before considering changes. The baseline becomes the standard against which the team assesses the impact of their solutions. This is a key step since the team must eventually compare the data collected during the Measure Phase against the data collected during the Improve Phase to confirm there is actual improvement.
Create a Plan to Collect the Data
Once the team clarifies the baseline measure, they must consider where to get the data, how much to collect, who will get it and how. A well-thought-out Data Collection Plan is critical since accurate and reliable data are key to good decision making.
Tools: Data Collection Plan
Data Collection Plan
What is a Data Collection Plan?
A Data Collection Plan is a well thought out approach to collecting both baseline data as well as data that can provide clues to root cause. The plan includes where to collect data, how to collect it, when to collect it and who will do the collecting. This plan is prepared for each measure and includes helpful details such as the operational definition of the measure as well as any sampling plans.
Ensure the Data is Reliable
Defining and refining process measures leads to collecting critical process information. This enables the team to make good project decisions. Reliable data ensures corrective actions are based on facts rather than assumptions and opinions.
Operational Definition
What is an Operational Definition?
Operational Definitions describe the terms used within measures such as “accurate” or “complete” and if it’s a time-based measure, they include the stop and start points. These detailed description of each measurement are designed to ensure that each measurement is interpreted the same way by different people. They are key to insuring the integrity of any measurement system.
Gather the Baseline Data
Data collection generally involves gathering system information, creating reports and manually collecting process information when it’s not readily available. The team creates Check Sheets for the manually-collected data and continues until they have a reliable data set to establish the baseline.
Check Sheet
What is a Check Sheet?
A Check Sheet is a simple tally sheet used to systematically collect data on the frequency of an occurrence (e.g., the frequency of defects).
Useful for all phases of DMAIC, Check Sheets are best used when the data can be collected by the same person or in the same location. It is particularly effective for identifying defect frequency, patterns of events, and possible defect causes.
Update Your Project Charter
Initial data collection efforts provide the team with helpful details around process performance and potential targets. The team refines their Project Charter with new data that more accurately reflects the problem and the goal. This process of refinement continues into the Analyze Phase.
Project Charter
What is a Project Charter?
The Project Charter is a living document that outlines a process improvement project for both the team as well as leadership. Teams use the charter to clarify the process issue being addressed, the reason for addressing it and what “success” looks like for those working on it. It’s also used to clarify what’s not being addressed. It is the first step in a Lean Six Sigma project, and therefore takes place in the Define Phase of DMAIC. The Project Charter is periodically reviewed and refined throughout the project.
The elements of a Project Charter generally include the:
- Problem Statement
- Business Case
- Goal Statement
- Timeline
- Scope
- Team Members
Project Charter Resources
How do you get to the root of the problem? How do you determine the true source of the issue so you can solve the problem for good? That is the crux of an improvement effort and the key focus of the Analyze Phase. This phase doesn’t always get the attention it deserves, but it’s the heart and soul of problem solving.
Teams often initiate projects with assumptions about what’s causing process issues. If preconceived notions go unchecked, teams can jump to solutions before verifying the true root causes. The result? Implementing solutions that fail to resolve the problem.
This wastes time, consumes resources, creates more variation and often causes new problems. The ideal is to study the process and the data to find clues to potential root causes. The idea is to develop hypotheses as to why problems exist and then work to prove or disprove those hypotheses.
Verification can involve data analysis, process observations or tests to turn potential causes “off and on.” The goal is to get crystal clear on the sources of process problems before considering solutions. This is the value and power of the Analyze Phase.
Closely Examine the Process
After conducting a Process Walk, creating high-level and detailed process maps and collecting process data, the team is able to scrutinize the process and reveal the pain points. This allows the team to take advantage of the collective wisdom of the process participants. They can expand the depth and breadth of their process knowledge by conducting any of the following:
- Time Analysis: focuses on the actual time work is being done in the process versus the time spent waiting. What teams discover is that whereas people are 99% busy, “things” are 99% idle.
- Value Added Analysis: adds another dimension of discovery by looking at the process through the eyes of the customer to uncover non-value-adding steps and the cost of doing business.
- Value Stream Mapping: combines process data with a map of the value-adding steps to help determine where Waste can be removed.
Tools: Value Stream Map and Value Added Flow Analysis
Value-Added Flow Analysis
What is a Value-Added Flow Analysis?
Value-Added Flow Analysis combines two powerful tools into one. The Value Analysis differentiates steps that add value in the eyes of the customer from those that do not, and Flow Analysis calculates the time spent on each step. This makes clear the time and effort being spent on non-value adding activities, the cost of doing business, and sets the stage for reducing waste and streamlining the process.
Graphically Display the Data
After collecting data, the team is able to display it using charts and graphs providing visual clues to process problems. Transforming spreadsheets of numbers into revealing visuals allows the team to easily communicate their findings to leadership and other process participants. Selecting the right charts and graphs provides the team with valuable insights about the causes of process issues.
Tools: Run Charts, Histograms, Pareto Charts and Box Plots
Run Chart (aka Time Series Plot)
A Run Chart is a time series plot that displays shifts and trends in data over time. This kind of chart can display continuous or discrete data and generally appears with a median or average line.
Run Chart Template
Histogram
Histograms, also known as Frequency Plots, are a are visual displays of how much variation exists in a process. They highlight the center of the data measured as the mean, median and mode. They highlight the distribution of the data measured as the range and standard deviation and the shape of a Histogram indicates whether the distribution is normal, bi-modal, or skewed.
Histogram Template
Pareto Chart
A Pareto Chart is a bar chart of discrete data that displays the most significant categories of defects in descending order. The chart was named after the Italian economist, Vilfredo Pareto, who discovered the “80/20 Rule.” The Pareto Chart uses the “80/20 Rule” to narrow the focus of process improvement to the 20% of defect categories causing 80% of the process issues.
Pareto Charts display both frequency of occurrences (bar graph) and cumulative percent of occurrences (line graph) on a single chart. The left Y-Axis shows frequency of occurrences, while the right Y-Axis shows the total percentage.
Pareto Chart Template
Box Plot (aka Box and Whisker Plot)
A Box Plot, or Box and Whisker Plot, is a graphical view of a data set that is divided into fourths or “quartiles.” It shows the center and spread of a data set but is most useful when comparing two or more “strata” or data sets such as the cycle time for two different departments.
Box Plot Template
Look for What Might Be Causing the Problem
After combining both Process Analysis and Data Analysis to uncover clues, the team adds their findings to the Cause & Effect or Fishbone Diagram. By continuously contributing to this living document, the team builds on the collective wisdom of process participants. Using the 5 Whys as a companion tool guides team members to drill past symptoms to the root causes of process issues. This helps the team dig down to the vital few causes of lost time, defects and waste in the process.
Fishbone Diagram (aka Cause & Effect Diagram)
What is a Fishbone Diagram (aka Cause & Effect Diagram)?
A Fishbone Diagram is a structured brainstorming tool designed to assist improvement teams in coming up with potential root causes for an undesirable effect. Its name derives from its resemblance to the bones of a fish. It is also known as a Cause and Effect Diagram or an Ishikawa Diagram after its creator.
Causes are often grouped into major categories, which are classically defined as the 6 Ms (or the 6 Ps):
- Man/Mind Power (People)
- Method (Process)
- Machines (Program)
- Materials (Product)
- Measurements (Policy)
- Milieu/Mother Nature (Place)
This tool is used in tandem with The 5 Whys.
Fishbone Diagram Resources
How to Increase the Effectiveness of Your Next Cause & Effect Diagram
The Cause & Effect Diagram is a popular tool and it appears in most continuous improvement projects. But in reviewing the project examples and publications, I am amazed at how many different ways this tool is utilized.
No one can say there is only one correct way to use any tool, although certainly some approaches are more useful than others. For me, the test of any tools usage is “does it provide the user with information about the current system.”
Does it provide the user with information about the current system?
Let’s start with a definition of what this tool is. A Cause & Effect Diagram is a visual tool that aids in identifying the sources of variation within a process. The graphical layout is easily identifiable, often referred to as a “fishbone diagram” or the “Ishikawa diagram.” It has the effect labeled in the right hand box and is connected with branches or “bones” on which causes are listed.
The steps to create this diagram are typically listed as:
- Document the effect
- Label the branches/bones
- Brainstorm for potential causes and add them to the branches
- Identify the most significant/probable cause(s)
While accurate in what you do, they don’t provide much assistance in how to do this. Here are four ways the Cause & Effect Diagram (C&E Diagram) can provide more information:
- Label the cause “bones” with categories that are process specific
- Document the “effect” to show process variability, not the defect condition
- Use “causal” wording that is measurable or quantifiable
- “See”/visualize the correlation of the causes to the effect
1. Label the causal “bones” with categories that are process specific.
The diagram is typically shown with six branches and labeled with the six generic causal categories. Sometime these generic categories are referenced as 6Ms or 4Ms, a P and an E (as Manpower is relabeled as People, and Mother Earth is relabeled as Environment). Certainly, these typical settings are logical in that they represent the categories of variation that exist for any process. But their use is not mandated. Both the number of legs and the labels can and should be modified to fit the process under study.
In working with a variety of processes, I find that these typical settings can be limiting to the improvement team.
In transactional processes, for example, sometimes “Machine” can be difficult to understand. Changing the branch name to “Computer Software”, “System”, or even the specific application name can aid in understanding and identifying the variation.
Eliminating the “People” label and replacing it with multiple branches, each with specific job functions, such as “Operator” or “Design Engineer,” can provide more clarity and space.
Eliminating the “People” label and replacing it with multiple branches, each with specific job functions, such as “Operator” or “Design Engineer,” can provide more clarity and space.
Similarly, “Materials” may be better served by relabeling or adding more branches for specific process materials.
“Methods” may be better understood as “Standard Operating Procedures” or other forms of process documentation.
Finally, I find that teams may not clearly understand the “Environment” or “Measurement” branches. “Environment” is typically interpreted as the physical environment, which may have little or no impact on the listed effect. Opening the branch to include the “political” or “emotional” environment can be useful; however, it remains process dependent.
Measurement variation is many times overlooked in process analysis and can be significant. Spending time with the team to discuss the definitions to these branches can be useful in identifying the sources of variation they hold, but I must admit that space on a single page C&E diagram can be a limitation. On occasion, combining these into a single branch labeled as “Other” has seemed the best solution for the team.
Historically, C&E diagrams were hand drawn. With the advance of graphical software applications, many diagrams are now electronically formatted. Limiting a cause & effect diagram to a single piece of paper is an unnecessary constraint. Expanding the diagram to multiple pages can allow the number of branches to be expanded and thereby increase the analytical value of the tool.
How often is this currently practiced? When is the last time you saw a two-paged C&E diagram or one with more than six branches?
Expanding to multiple pages allows more space so that multiple “causes”can to be included.
I have watched a team waste time during brainstorming the initial creation of this tool by debating which category a given “cause” should be placed. Given the goal of this tool is to identify causes of variation, rather than debate the issue, label it in any, both, or all locations and later use data to determine which category is really appropriate. Expanding to multiple pages allows more space so that multiple “causes”can to be included.
2. Document the “effect” to show process variability, not the defect condition.
In almost all of the cause & effect diagrams I see, the effect is labelled with the defect condition from a single process event.
When “cycle time too long” is the listed effect, the mental picture I have is a condition from one end of the distribution, rather than the variation of the total distribution.
Figure 3 depicts the output variation. Certainly the specification or a service level agreement can establish the defect condition, but by labeling the C&E diagram effect in this way, do we limit the thinking about the causes? How can we understand all the causes of variation in cycle time if we only think about the times that are beyond the specification?
To me, the C&E diagram implies correlation, even if it cannot be easily measured.
“Causality (also referred to as causation) is the relationship between an event (the cause) and a second event (the effect), where the second event is understood as a consequence of the first.”
If this is true, then shouldn’t the C&E effect diagram help us visualize that correlation, not just the conditions when the defective result occurred?
Adding a cause to a branch on the diagram implies it is a contributory cause. That means, when the cause is present, one would expect the effect will have a different outcome result than when it is not present. If this is true, then shouldn’t the C&E effect diagram help us visualize that correlation, not just the conditions when the defective result occurred?
I believe this is more than mere semantics. I believe it has an impact on how the causes are listed and labeled. It is a simple change. The labeled effect becomes “cycle time varies”. In making this change, the total variation is more in focus. I start to explore why and when cycle times are extremely short, not just the small segment that are defective.
3. Use “causal” wording that is measurable or quantifiable.
When a team is brainstorming causes, there is a tendency to add a qualifying adjective – “training” becomes “lack of training”. Other qualifying words like “inadequate,” “improper” are commonly observed.
I believe using these words transforms it from a cause to an implied solution. Does not “lack of training” really mean, if we provided more training the effect would not exist? It moves the team away from confirming the correlation to simply implementing a solution.
If one buys into changing how the effect is listed (to show variation – section 2 above), then changing the wording on the listed causes to measurable or quantifiable descriptions strengthens the correlation message.
For example, if “lack of training” implies the solution of providing training. By asking, “What would training change?” – one may provide an answer such as “operator knowledge”. Isn’t the “level of operator knowledge” really the type of cause we are looking for?
Ideally, all causes listed should be measurable. “Lack of Training” is not. “Operator knowledge” is measurable, albeit difficult. If the intended purpose of the cause & effect diagram is to list sources of variation, with the cause written as “Operator Knowledge”, one can envision a distribution of knowledge among the operators.
I suggest working with the team to eliminate these qualifying adjectives. “Procedure not followed” becomes “% of procedure followed” or some other means of measuring the difference from one process cycle to the next. “Inadequate staffing” becomes “number of man-hours utilized.” These causes are measurable and again I would expect there to be measurable variation from one process cycle to another.
Some causes are attributes in nature. For example, a cause such as “location” would imply that variation existed from location to location. In this example, the procedure is an attribute. It is an individual entity without variation – a specific version of a given document. These types of causes still work for me, but how I analyze the data simply changes. If I have two locations or two different procedures, I simply collect output data and stratify it by the attribute and use a hypothesis test to check for statistical significance.
Using these re-wording suggestions, the revised cause & effect begins to look like the Figure 5.
In situations where I have used these first three suggestions, the team found the diagram easier to understand and thereby more useful.
4. “See”/visualize the correlation of the causes to the effect.
Now, with wording that implies variation in the output (effect) and the inputs (causes), the next step is to validation the causes with data. With the possible correlation more visible from the diagram, the use of multiple regression, ANOVA, and hypothesis tests can begin to provide actual statistical evidence of the relationship. I challenge the team to draw what they would expect the correlation to be, even if they are yet to collect the data.
In some cases, collecting the data may be challenging. How do you measure the operator’s knowledge? But I do find this correlation discussion, even if only hypothetical, goes a long way in gaining knowledge about the process. You will find that many times, another “Why” question is generated, and then the “5 Whys” analysis really becomes meaningful.
The Heart of Your Process Improvement Effort
By utilizing these four suggestions, I think the C&E diagram becomes the heart of any process improvement effort and provides key learning that should be carefully retained and not be lost simply because personnel move onto other positions or subject matter experts retire. I believe it will greatly increase the leverage you get from this tool.
Craig Tickel
5 Whys
What are the 5 Whys?
5 Whys is a simple but effective method of analyzing and solving problems by asking “why” five times, or as many times as needed, in order to move past symptoms and determine root cause. This approach is used in tandem with Cause-and-Effect or Fishbone Diagrams.
Verify the Cause(s) of the Problem
Before moving on to the Improve Phase the team confirms the proposed root causes by using data, process analysis, process observation and comparative analysis. Verification can be as simple as watching the problem in action or as complex as designing and running hypothesis tests—there are many methods but no one best way.
Root Cause Hypothesis
What is a Root Cause Hypothesis?
Root Cause Hypothesis is an educated guess as to the cause of a problem in a process. Root Cause Hypothesis is part of the Analyze Phase in DMAIC. In order to form Hypotheses regarding the causes of process issues, one must conduct Root Cause Analysis which involves questioning and investigating to move past symptoms to the the true root of the problem.
Update Your Project Charter
During the Analyze Phase, the team often finds additional detail around process performance and the potential for improvement. The team updates the Project Charter with the new information. By the end of the Analyze Phase, it might be time to bring in new team members.
The uncovered root causes might exist in departments that aren’t represented on the current project team. When that happens, it’s critical to add the right people to the team before moving to the Improve Phase. Don’t make the mistake of fixing someone’s process without involving them!
Комментариев нет:
Отправить комментарий