Global 8D – D2: Define the Problem

Posted by Graham Cripps on Thu, Jul 30, 2015 @ 10:30 AM

Global 8D – D2: Define the Problem

Defining the problem is a process for 'digging down' and getting a more detailed and refined understanding of the problem.

At this stage of the problem solving process we are looking to provide concise data and determine the exact nature of the problem.

A common problem in any problem solving activity is distinguishing between the problem and the symptom of the problem.

Describing the problem is carried out in two stages:

Problem Statement - A concise statement that identifies the object experiencing the defect and the nature of the defect (the defect will typically be a symptom for which the cause is unknown)

Problem Description - Established by asking the question "What is wrong with what?" and testing it with repeated Whys (Stair-stepping)

Problem Statement

At this stage it is important to note that problem solving is about taking all of the data and information around the problem (or symptom) and drilling down, using a structured process and a multi-disciplined team. However, if assumptions are made without gathering the data, too often the symptom may well become the focus of the effort rather than the problem itself

Let me explain using a simple example

Example: “Every time I put the wall mounted heater on in the kitchen it blows a fuse”. So, the problem is the heater and the symptom or effect is a blow fuse? This is an assumption at this stage as we do not have any other information like:

How much load is on the circuit already?
Is the socket used for any other electrical appliance of this size?
Has the heater been plugged into another socket to try it out?
And so on……

This is a simple example but does demonstrate how easy it is to jump to what appears to be a natural conclusion.

If we are to get to the bottom of the problem and fix it for good then we must be driven by facts and not assumptions.

Starting with the problem description, we must ensure we keep focused on what we know. So using the above example and what we actually know at this point, using the sentencing technique of what is wrong (the problem) with what (the object), our problem statement becomes 'the fuse blows'

So, if I assumed that the heater was faulty, scrapped it and bought a new one, would this necessarily solve the problem? At this point I don’t actually know. However, think about a problem in the workplace and how expensive replacing an item could end up!

We now have a problem statement, we now need to look at developing this to a full problem description

Problem Description

A Problem Description is the output of a process that utilises the IS/IS NOT Form to amplify the Problem Statement. This is the next step in better understanding the problem.

g8d_-is_is-not_template

This techniques looks at 'what the problem is and what the problem is not but logically could have been' and looks to provide information on:

what the defect is/is not but could be

where it does/does not occur but could

when it does/does not occur but could

how big it is/is not but could be

The IS/IS NOT process also identifies data that needs to gathered where necessary to better understand the problem.

Example: A factory is making metal lamp shades for the domestic market. These are fabricated and then painted using a robotic paint plant in several colours. Some of the blue finished product has a defect, paint runs. Therefore:

What: the problem is on the blue lamp shades and is not on any of the other colours, but could be

Where: the defect is on the top flat and is not anywhere else, but could be

When: the defect is apparent after the finish coat and is not apparent after the base coat

How big: the defect is consistently on 20% of all blue product and is not higher or lower, increasing or decreasing but could be.

NOTE: This is only a part of the data and information that is gathered during this process. For more information download our free Is/Is Not template by clicking on the button at the end of this article.

The problem description could now be formatted as follows:

'20% of the blue finished product are consistently rejected for paint runs on the top flat. Defects are not seen after base coat'

Next Time

Having determined what the problem is and what it is not, the next article will be focusing on what is the differencebetween the products that have the problem and those that do not and what has changed for the problem to have appeared.

Graham Cripps

Results Consortium Ltd

www.resultsresults.co.uk

0 Comments Click here to read/write comments

Topics: Global 8D, G8D, Is/Is Not, Problem Desciption

Global 8D - D1: Establish the G8D Team

Posted by Graham Cripps on Thu, Jul 30, 2015 @ 10:00 AM

Global 8D – D1: Establish the G8D Team

In this article I will look at teamwork and how to establish a problem solving team that will be effective and cohesive.

Having an effective team is crucial to the success of the problem solving effort. We need a multidiscipline and experienced team to be able to provide the effort needed in getting to the root cause of the problem. This is the goal of all structured problem solving tools.

In this article I will discuss the following issues:

Team skills
Team roles
Team responsibilities

Having established management support for the G8D process to be applied to the problem, this implies that the right people will be released at the right time.

Team Skills (And Knowledge)

The skills that the team members require will include, but are not restricted to:

Knowledge of the process where the problem has manifested itself
Knowledge of the item (part, sub-assembly, outcome)
Technical knowledge of the item under analysis
Customer usage and application knowledge (internal or external customers)
Decision making
Conflict resolution
Communication skills
Data analysis skills

The makeup of the team will depend upon the initial perception of the problem. However, the team composition may need to change during the G8D process. This is because the team’s understanding of the problem will grow and as it does may need additional of different skills to help resolve the process.

Team Roles

There are a number of roles in effective teamwork that, when applied in the spirit of supporting the team, ensure that the team has the very best chance of success.

Before we go any further I would like to give a definition of a team.

Teamwork 'A team is a small number of people with complementary skills who are committed to a common purpose, performance goal and approach for which they hold themselves mutually responsible'

In other words a cohesive team.

The recommended team roles are:

Champion: the champion will normally be the responsible person that is feeling the pain of the problem. The champion will not normally attend the meetings but will support the team, in particular gaining access to the resources required for the problem solving effort

Team Leader: the team leader’s role is to manage the business of the team for the team. The activities will include setting the agenda, arranging the meeting venue, managing the activities and communicating with the champion

Time Manager: this is not a time keeper! The time manger takes on the responsibility on behalf of the team to manage the allotted team meeting time. Working with the team leader, they will issue a timed agenda, allocating fixed times for each topic on the agenda. During the meeting, the time manager will advise the team of remaining time for each subject and, with the team, agree amendments on a running basis if a topic is running over and considered important enough to do so

Scribe: is the person that captures the outcomes of the meeting as agreed by the team and publishes on behalf of the team

Facilitator: the facilitator looks after the team process and ensures that everyone is involved in the process steps and captures what went well for the team members

G8D Coach – this is optional, but recommended where some, or all, of the team members have no experience of G8D process application. This should be an internal resource where ever possible to maximise the possible problem solving effort

Team Responsibilities

The responsibilities of the individual team members will be allocated by the team and will involve some or all of the following:

Data collection
Data analysis
Decision making processes
Experimentation
Solution verification and validation
Modelling and/or experimentation
Managing resources
Planning and implementation of solution (see also Plan-Do-Check-Act)
Communication

These are the common skills required in addition to the general problem solving and technical skills required to contribute to the problem solving effort

Complete G8D Report (Template)

The G8D report has is a reporting summary for the G8D process efforts and is designed to be completed at each stage of the process

G8D Report

At this stage the G8D Report is completed by the team to show all the team members and circulated to all interested parties.

Circulation of the G8D report will vary at different stages of the G8D process and will normally be agreed with the Champion before circulation.

You can dowload a free, editable version of this report template via the button at the bottom of this article.

Assessing Questions

At the end of each stage there are a number of assessing questions that should be asked by the team leader or champion to ensure that all the factors have been considered and all necessary actions completed

In particular at this stage the questions will include:

Have all changes been documented?
Is the ERA continuing to be effective?
Is the team composition correct to proceed to the next step?
Have all the measurables been established?
Is a Service Action required?

Next Time

I hope you will join me again for the next article when I will be discussing how to clearly describe the problem (Problem Description), and look at one of the main reasons problem solving efforts fail to succeed

Graham Cripps
Results Consortium Ltd

www.resultsresults.co.uk

0 Comments Click here to read/write comments

Topics: root cause analysis, Global 8D, G8D, PDCA, Plan Do Check Act, Problem Desciption, Continuous Improvement, decision making

Global 8D – D0: Prepare for the G8D process

Posted by Graham Cripps on Thu, Jul 30, 2015 @ 09:00 AM

Global 8D – D0: Prepare for the G8D process

Introduction - D0 Prepare for the Global 8D process (and establish the Emergency Response Action)

This is the first article in a series of nine that I will be publishing over the next two weeks, they will give a high level explanation of the Global 8D Problem Solving process. In the this article I will be looking at the first step.

Each step will be complete with access to tools and templates that support the G8D process as well as those hints and help topics that would normally be included in our training program.

The steps are:

D0 – Prepare for the G8D process

D1 – Establish the Team

D2 – Describe the problem

D3 – Develop the Interim Containment Action (ICA)

D4 – Define and verify root cause and escape point

D5 – Implement and validate the Permanent Corrective Action (PCA)

D6 - Implement and validate the PCA

D7 – Prevent recurrence

D8 – Recognise team and individual contributions

As we go through the G8D process I will be using a number of terms that may not be familiar to everyone. In all cases I will try and pre-empt your questions. However, if you need any further explanations you can contact me via our web site www.resultsresults.co.uk and I will do my best to assist you.

D0 – Prepare for the G8D Process

There are three activities within this first step: -

Determine if the problem warrants the effort of a full G8D process.
Protect the customer
Complete the G8D repsort

If it is established that a full G8D is not required then a simpler problem solving model should be used that will solve the problem at root cause.

Root cause is the level at which, when identified and eliminated, the problem cannot recur.

Determine if the problem warrants the effort of a full G8D process

The G8D process is a team based problem solving methodology. Team members will be involved, some times over long periods of time, in this problem solving activity. The G8D process is used if a problem meets the following criteria, it:

Has a definition of the symptom(s) - the symptom has been quantified.
Has identified the customer(s) and affected parties who experienced the symptom(s).
Has measurements to quantify the symptom(s) and demonstrate that a performance gap exists, and/or the priority (severity, urgency, growth) of the symptom warrants initiation of the process.
Has an unknown cause.
Has management commitment to dedicating the necessary resources to fix the problem at root cause level and to prevent recurrence.
Has a problem symptom complexity that exceeds the ability of one person to resolve the problem.

If any of the above is not met then a practical problem solving method should be applied. e.g. 5Y’s analysis etc.

Protect the customer

Protect the customer from the effects of the problem (symptom) by introducing an Emergency Response Action (ERA), this could either be an external or internal customer. The purpose of the ERA is to protect the customer from the effects of the problem and 'buy time' to be able to solve the problem at route cause.

The ERA should be verified before full implementation to ensure that it stops the symptom reaching the customer.i.e. should switch problem off whan put in place and switch problem on again when removed. Note: in some complex sittuations it may be necessary to model the ERA for verification purposes.

By its nature an ERA will add cost, so it is important to resolve the problem as quickly as possible. Once the problem has been fully understood, the ERA is reviewed and replaced with an Interim Containment Action (ICA). The ICA is normally more considered, and often more cost effective, than the ERA. We will discuss this further in D3.

Complete the G8D report (Template)

The G8D report has is a reporting summary for the G8D process efforts and is designed to be completed at each stage of the process (D0 to D8)

Global 8D Report

The report is laid out to facilitate a summary report at each stage of the process. This must be fully supported by all the data and activity reports that will be generated as a result of the problem solving effort.

The G8D report cannot be completed without the problem solving effort having identified the root cause(s) and the necessary corrective actions having taken place.

At every stage effort needs to be made to gather and record the necessary data and information to ensure the corrective actions are effective and for the business to benefit from the lessons learnt.

Assessing Questions

You can download a copy below

I hope you will join me again for the next article when I will be discussing how to form an effective G8D Team.

Graham Cripps

Results Consortium Ltd

1 Comment Click here to read/write comments

Topics: Root Cause, root cause analysis, Global 8D, G8D, Interim Containment Action, Permenant Corrective Action, 8D, 8D benefits, Continuous Improvement

Active Listening - Needs More Than Your Ears

Posted by Graham Cripps on Tue, Jul 28, 2015 @ 09:22 AM

Active Listening - Needs More Than Your Ears!

graham_cripps_dec_2010_formal

Active Listening is something that some people find difficult to grasp. Active listening is about ensuring and confirming understanding

Have you ever asked the question of someone close to you "Are you listening to me?"

I have found that we believe we hear, and we believe we understand, without any reference point other than ourselves.

For example, you ask someone to do something and they say "Okay, I'll do that later, I need to finish this first". There are a few problems here already!

When is later?
What will you actually do?
Is what they are doing more important?
Do they really know what you want them to do?

When we ask someone to do something we have a mental 'picture' in our head of what that something looks like. Likewise, if you are asked to do something, the person asking has their mental 'picture'.

This 'picture' is more than just a 2D image, it has other facets that we need to consider, such as emotions, beliefs and values.

Active Listening is about making sure your vision of something and the other persons vision are closely aligned, we all know what happens if they are not!

We need to use questioning and observation as part of Active Listening: questioning our understanding by restating what you believe has been said, probing into what the other persons something looks like, observing the body language as we restate to look for physical signs of agreement

As business leaders we should always be striving to understand what the WHOLE picture is all about.

0 Comments Click here to read/write comments

Topics: Problem solving, Continuous Improvement, Leading Teams, People Development, Stress Management, Management Tools & Techniques, Mental Toughness, Leadership, MTQ

SPC - Understanding Capability

Posted by Graham Cripps on Mon, Jul 27, 2015 @ 12:12 PM

SPC - Understanding Capability

Having capable processes is critical to any improvement initiative. in this article we will look at what capability means and how to measure it.

In previous articles we have looked at process output and how the data can be used to control the process. Having this data available means that you can also calculate capability.

We will look at the prime capability indices:

C_p- Process potential capability

C_{pk –}Ongoing process capability

First, let us look at what capability is. By definition process capability is a ratio, over time, of how the process meets the specification. However the process must be stable and in control, that is that there are no special causes or variation present.

Process potential capability is a ratio and calculated by:

C_p= USL – LSL

6σ

SPC_B6_P1

This diagram shows the upper and lower specification limits and a process that is centered whereby + / - 3σ falls within these limits. Where 6σ is equal to the specification then the process has a potential capability of 1.0. However, there is a possibility that 0.27% will fall outside specification limits.

SPC_B6_P2

In the graphic to the right we have three centered processes, each with a different process spread. From the top the spread is less than the specification, therefore the C_p will be greater than 1.

The middle example has a spread equal to the specification

The lower process has a spread greater than the specification therefore the C_p will be less than one (eg not capable).

In many cases the process spread will not be centered about the centre of the specification so we need a method for calculating capability in these circumstances.

SPC_B6_P3

This graphic shows that we need to calculate the capability for each half of the process spread, where the process capability is calculated by taking the lesser of C_PKL(capability lower) and C_PKU(capability upper). The calculations for these are:

C_PKL = X – LSL and C_PKU = USL – X

3σ 3σ

The following three examples are provided to aid your visualisation of capability for three process outputs.

SPC_B6_P4

Here the process is centered so the C_PKL and C_PKU are the same.

SPC_B6_P5

In this example the potential C_p is 1.00, or the process spread is equal to the specification limits. However, if we take into consideration the location of the data relative to the specification, the C_pk is 0.00

SPC_B6_P6

In this final example we can see that the process spread is below the specification limit. C_p is still 1.00 but the C_pk is minus 1.00

There is a capability exercise available for download at the end of this article, which will provide an opportunity for you to practice using four examples (the answers will be provided for you to check against with article 7, be sure to watch out for this later this week!).

Recommended Target C_pk Values

There are some practical considerations when looking at process capability. These are due to:

The data used in the examples above is based on averages of sub-groups of data (averages, X-bar)
Allowing for process shift due to common causes of variation
Allowances for measurement accuracies
Allowing for the 0.23% probability of producing outside the + / - 3σ

There are some industry standards established and these should be established in all cases. However, as a rule of thumb, we can recommend that for initial capability the C_pk should be between 1.60 and 1.80. For ongoing capability, the C_pk value should be between 1.40 and 1.60.

0 Comments Click here to read/write comments

Topics: Continuous Improvement, Statistical Process Control, SPC

FMEA - Some frequently asked questions answered!

Posted by Graham Cripps on Fri, Jul 24, 2015 @ 01:30 PM

FMEA FAQ's (Frequently Asked Questions)

"When do I carry out an FMEA?"

FMEA is a predictive risk assessment tool and looks at the probablility of failure of a design or process.

As Machinery FMEA and System FMEA are also based upon Design FMEA, you can assume the followingcomments apply accordingly.

For Design FMEA (DFMEA), the FMEA should be carried out prior to setting up the process and already have the output from the DFMEA. The FMEA concentrates on the probablity of failure of the process to perform in terms of the process purpose or outcome and requires the following information:

Design specification
Design verification test planning
Reliability test data

For a Process FMEA (PFMEA), the FMEA should be carried out prior to settng up the process and already have the output from the DFMEA. The FMEA concentrates on the probability of failure of the process to perform in terms of the process purpose or outcome and requires the following information:

Critical charateristics of the design
Process capability (if known)
Machinery FMEA if available

These are ideal conditions, however an FMEA performed on existing products or processes can also provide valuable data and information for both the design and process teams

"How do I ensure that our FMEA efforts are well managed?"

For FMEA to be a useful tool for any business it must be an integrated part of the business process. Therefore this process, like any other, requires management support.

In order to have a framework for managing FMEA's someone that has a vested interest in the outcome of the FMEA and in a management role would be tasked with assessing each stage of the process to ensure all process steps have been completed successfully.

There are a whole set of assessing questions that are asked at the end of each stage of the FMEA process. These questions are designed to assist the team and the manager to focus upon each stage of the FMEA process to ensure full completion.

The following is a small selection of the questions but a full copy can be accessed by selecting the button at the end of this article.

These assessing questions are those followinng the review of existing design controls of a DFMEA:

Have all the failure modes within the scope of this DFMEA been considered?
Have all the controls been realistically onsidered and entered onto the FMEA record?
Have the design verification specifications been used as part of the controls review?
Have all outstanding questions on the question log been answered?
Are there any new questions to be added to the log?
Has the DFMEA been communicated to all involved / interested parties?

"What is an FMEA Application Workshop?"

There are a lot of training courses, including the ones we offer, that tell you how to carry out an FMEA. However, the most effective way of learning is doing.

Our application workshops are run over two to four days and are a mixture of "show and tell" on your own design and process, not a case study.

The purpose of the workshop is not to fully complete an FMEA but to provide the ooportunuty for the attendees to be able to practice all steps on a design or process they are familiar with and have an outcome that can be taken away and completed with the new knowledge and experience.

This approach provides a feeling of relevance for the attendees and the opportunity to practice in a facilitated environment.

We also offer a review service, during the Workshop process, whereby one of our experienced practitioners will review one or more of your FMEA's and provide constructive fedback on the content. We have found this to be a valuable addition to the Workshop format, providing guidance and support for our clients.

To find out more about our FMEA Application Workshops please click the button below.

"How do I use RPN to prioritise actions to be taken?"

In its simplest form, the RPN figure is used to rank priority of actions to be taken by considering the highest RPN number first. It has long been recognised that this method does not discriminate between the severities of the effects of failure.

There are two available methods (RPN and SOD)and we would recommend the following method.

Known as S-O-D (Severity - Occurrence - Detection) it involves looking at the severity ratings of 10 first. To prioritise these, take S x D (product of severity and detection) to prioritise within this group. If the two are the same, then use the RPN number within that sub-group.

Then repeat for severities of 9 etc. See the following example:

						PRIORITY
	S	O	(s X o)	D	RPN	RPN Method	S-O-D Method
EX 1	10	1	10	1	10	9	3
EX 2	10	6	60	3	180	3	1
EX 3	10	3	30	2	60	5	2
EX 4	4	7	28	1	28	8	5
EX 5	4	3	12	3	36	7	4
EX 6	4	10	40	10	400	1	6
EX 7	2	10	20	10	200	2	7
EX 8	2	7	14	3	42	6	9
EX 9	2	7	14	7	98	4	8

If we use the RPN method then moderate severity becomes the first priority for action, whilst a failure mode with an effect of 10 and a relatively high probability of occurrence is third.

The S-O-D method is more logical and still provides a reliable structure for prioritisation.

0 Comments Click here to read/write comments

Topics: Design FMEA, Process FMEA, FMEA Template, FMEA Form, FMEA Action Planning, FMEA ranking tables, DFMEA, How to construct a boundary diagram, Continuous Improvement, FMEA FAQ's

Poka Yoke (Error Proofing)

Posted by Graham Cripps on Fri, Jul 24, 2015 @ 01:00 PM

Poka Yoke

Poka Yoke, also known as error proofing, is a systematic process for the review and reduction of the source of errors in a process.

Errors are the source of defects, so eliminating errors will eliminate the associated defects.

Shigeo Shingo introduced the concept of Poka Yoke at Toyota Motor Corporation in 1961. Originally known as baka-yoke (which means fool proofing), the name was altered to Poka Yoke to prevent offence and is pronounced POH-kah YOH-kay'.

Shingo said "Defects arise because errors are made. Errors will not turn into defects if feedback and action takes place at the error stage"

When To Consider Poka Yoke

The best time to consider error proofing is at the process design stage, Process FMEA facilitates this as part of the 'Control' considerations.

However, in a number of cases, error proofing (Poka Yoke) is used as an integral part of continuous improvement (Lean and 6σ) and problem solving activities.

Common Causes Of Error

Machining the wrong part
Operation error (wrong specification used)
Adjustment, measurement or dimension error
Errors caused by badly maintained equipment
Errors caused by incorrect or unsuitable equipment
Process ommissions
Process errors (not following standard procedure (SOPs))
Set up errors
Missing parts
Incorrect part used
Wrong form used
Incorrect details entered

It would be easy to blame 'people' but in fact the root cause of the error is the process or SOP itself. This needs to be fixed at root cause level, and this is where Poka Yoke is used.

The Process

There are a few steps to be considered and these are:

Define the error (the root cause of the defect)
Establish Poka Yoke device or process
Test the Poka Yoke device, validate and evaluate (cost, effectiveness, complexity)
Plan and implement the Poka Yoke device
Verify improvement
Sustain the improvement (make it the new way)
Replicate - use the lessons learnt

Update All Records

Ensure that all documentation is updated, which should include:

Control Plans
Reaction Plans
Process FMEAs

We have a SnapShot, PowerPoint and Worksheet available for FREE download, please find access to these below:

0 Comments Click here to read/write comments

Topics: Poka Yoke, error proofing

Interpreting An SPC X-bar And Chart

Posted by Graham Cripps on Thu, Jul 23, 2015 @ 03:29 PM

Interpreting An SPC X-bar And R Chart

In the last few articles we have looked at the basics behind SPC and the completion of an SPC chart. Now we have a completed chart we will look at how to interpret it. Firstly, however, we need to lay a few more foundations.

Types Of Distribution

We will cover the most common types, which are Gaussian, Bimodal and Skewed distributions. We will also consider the other descriptors, being the location (mean, mode and median) as well as spread.

Skewed Distribution - this is where the data is skewed to one side. the mode (highest occurring data point), the mean (or average) and median (middle number) do not coincide.

Bimodal - here we have a distribution that typically contains two of something (two processes, two tools or cavities, two measuring stations). As will be seen later, this can be misleading when trying to interpret the SPC chart. It is important to ensure that data is collected from one source only.

Gaussian - a distribution that is equally dispersed about the mean value. The mean, mode and median values are the same. In SPC we use this form of distribution by taking several samples (the sub-group), as this will tend any distribution towards a Gaussian curve. This enables probability to be assessed.

The problem with some processes is that they do not behave in a way that presents the data in a normal (Gaussian) distribution. As mentioned in previous articles, we use sub-groups of data, which have the tendency to present the data in a normalised format.

Control Limits

Control limits are calculated based upon what the process is generating. As previously mentioned, control limits should only be calculated when the process is devoid of special causes of variation, and when all the normal causes of variation have been included. This includes but is not limited to:

Changes of shift
Normal changes in the environment (internal and external)
Change of supply of materials (under normal circumstances)
Autonomous maintenance
A minimum of twenty data sub-sets

This applies to both control limits for range (R) and for averages (X-bar) of sub-sets.

Interpreting The Sample X-bar And R Chart

As part of the last SPC article you will have given access to a sample chart (if you have not yet downloaded this you can find it here). We will be referring to this chart during the remainder of this article so having it to hand will be useful.

The sample chart has been produced based on data from a machining operation, producing a small shaft.

The 7 Point Rule

Well, not really a rule, more of a recommendation. However, in the article titled 'Probability And SPC', we discussed what we can expect from a process under normal conditions.

SPC_B5_P4 The possible outcomes could be any one of the following eight:

All above the mean
All below the mean
All within the +/- 1 σ
All within the +/- 2 σ
In one half of the distribution
All going up
All going down
In the outer 1/3 area

The 7 Point Rule suggests that under normal circumstances we would expect that each sub-set of data would not have more than seven successive points that are in one of the eight possible outcomes.

This is based upon the probability of this occuring of 1 / 128 or 2⁷.

In other words, each data set has two possible outcomes, either a repeat of one of the above possible outcomes or any other outcome.

For example, if the last data set was in the +/- 1 σ area, you would not expect to see a further six based upon the probablity theory.

The Range Plot

SPC_B5_P5

In this example we can see there are no seven points that could be considered to be 'out of control' conditions.

Out of control conditions are those situations that are brought about due to a change. A special cause of variation is present.

The X-bar Plot

Again this is taken from the chart previously provided

SPC_B5_P6

At first sight all would appear to be good. However, there are a number of successive points within the +/- 1 σ area, this would need further investigation.

In this example, the control limits have been calculated based upon the first set of twenty sub-sets of data, so 'Whats the problem?' you may ask.

SPC_B5_P7

We have seen a lot of instances where the individual data values have not been plotted as part of the SPC chart.

Not plotting this information, as in this case, can lead to misinterpretation of the X-bar plot.

Here we can see that there are two distinct distributions of the individual data points, in other words a bimodal distribution. As previously stated, this cannot be used in an X-bar and R chart, as it will be masked by the process of calculating the mean values of each sub-set of data.

The investigation would need to centre on what has caused this bimodal distribution (special cause)

This example clearly shows the need for plotting of the individuals

Summary

Reviewing the example X-bar and R chart shows how powerful this tool can be for reviewing the control of processes.

We have used an example of a manufacturing machining process but SPC is just as applicable to many other processes, not just manufacturing. In fact, any process from which data can be gathered can be controlled using SPC.