Control Chart Conundrum

Key is whether the stacking disrupts the time order of the data not whether the tests are valid or not.

The purpose of the control chart is to identify out-of-control conditions in order to bring the process in control, i.e. take action. The purpose is not to estimate control limits per se. The control limits are caclulated to allow you to determine out of control conditions. The control chart does not have the purpose of a survey where you combine samples in order to better estimate the population parameter. A population is static, a process is dynamic. In your case this means that you should keep the two charts separate because your purpose should be to monitor the variation of the two processes. The question becomes: what do you gain from a business point of view by adding the two samples. This is economic control of processes. So half of the formula is statistical, half is economical and action-oriented.

No and no.
Operator A/ Location1 is an apple; Operator B/ Location 2 is an orange. They’re not the same.
You need one chart for each location. If you want to compare the performance of the two locations, you can plot the charts, in time order, side by side, computing the control limits for each location separately (this is easy – peasy using the MINITAB Stages in Chart Options).
I think you may be missing the point here. What do want to do with the chart?

Define what’s your objective first and identify if the tool fits your objective in terms of the results you want to see.
Need to have two separate charts because 2 different parameters might affect the decision making. Better have a boxplot and two sample hypo test to see any significance or if the other is better.

Are measuring a product or a process characteristic?
If you want to compare different people at different locations, you could use a single control chart,stratified by location and person (I did a simulation, but can’t copy the chart into this e – mail)
You could use box plots, as was suggested previously, but you won’t get any idea of process stability.
If you want to show the stakeholder a single summary of the overall performance (assuming this is a product or service going to a customer somewhere), why don’t you just plot all the data on a histogram?
 

By mixing data you have lost the whole purpose of the control chart.
Read Shewhart, Deming and Wheeler for the basics.

Good luck alright … obviously another mindless SS consultant focussed on numbers rather than purpose.
Don’t mix data from different sources.

Pete, if you ride the high horse, at least know the technical defintions and be specific about the big words that you are using: “Control charts are really a homogneity test”, “mixed data” and “really be used to find sources of variation”. A little knowledge is very dangerous!

I am not a SS consultant, neither do I consider myself to be mindless. Also, I did not suggest mixing data from different sources. I suggested that the data be stratified by location and operator, and that a single chart plotting each stratum separately be used to compare each location/operator combination.
If this was unclear in my post, please advise why.
Thank you
Accrington

Homogeneity and rational subgrouping seem to be requirements of control charts.
http://www.sei.cmu.edu/str/descriptions/spc.html
“Next, the notions of homogeneity and rational subgrouping need to be understood and addressed. Homogeneity and rational subgrouping go hand in hand. Because of the non-repetitive nature of software products and processes, some believe it is difficult to achieve homogeneity with software data. The idea is to understand the theoretical issues and at the same time, work within some practical guidelines. We need to understand what conditions are necessary to consider the data homogeneous. When more than two data values are placed in a subgroup, we are making a judgement that these values are measurements taken under essentially the same conditions, and that any difference between them is due to natural or common variation. The primary purpose of homogeneity is to limit the amount of variability within the subgroup data. One way to satisfy the homogeneity principle is to measure the subgroup variables within a short time period. Since we are not talking about producing widgets but software products, the issue of homogeneity of subgroup data is a judgement call that must be made by one with extensive knowledge of the process being measured.
The principle of homogeneously subgrouped data is important when we consider the idea of rational subgrouping. That is, when we want to estimate process variability, we try to group the data so that assignable causes are more likely to occur between subgroups than within them. Control limits become wider and control charts less sensitive to assignable causes when containing non-homogeneous data. Creating rational subgroups that minimize variation within subgroups always takes precedence over issues of subgroup size.”
Dan