cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Choose Language Hide Translation Bar

Updates to Process Screening Platform (centered around alarm rates in the output table)

What inspired this wish list request? 

My companies' process control groups are increasingly using the Process Screening platform and the alarm rate is becoming a key metric for us.  Also, we are using three-way chart more and more, and it is just as important on three-way charts to track and understand the alarm rate on the within charts as the mean charts.  When trying to compare results across platforms as well as expected results, we found discrepancies.

 

I've been working with @PatrickGiuliano at JMP Technical Support to work through how the platform has been designed to function vs this requests goals.

 

What is the improvement you would like to see? 

The alarm rate section of the Process Screening (PS) platform is a great way to be able to pareto out what process to attack first as well as track performance changes over time while also being able to quickly visualize trends.  I would like to see the following:

  1. The "Alarm Rate Column" and "Any Alarm" columns should respect all selected alarm rates as calculated off both upper and lower control limits.  Currently they only calculate off both control limits for the mean chart (as well as any other tests) but only the upper control limit for the "Range Limit Exceeded" when a three-way chart is selected.
    • Not respecting the LCL causes different alarm rates when viewing a process in PS vs Control Chart builder.  This also creates control charts that are different looking than Control Chart builder when using "show chart as selected" in the PS and adding in the dispersion chart as only the UCL is shown.
  2. The names for the dispersion charts should be changed to be clearer.  "Range Limit Exceeded" should go to "Disp Limit Exceeded" and be used with MR/-R/-S/three way S/R charts and "3W MR Limit exceeded" should be used for MR charts on three-way charts.
  3. The alarm rates and alarm count should not be the sum of the alarm rates for each "Test" column and three way "Range Limit Exceeded".  They should only sum up across a subgroup (so if any subgroup fails a "test" on the mean chart or the subgroup dispersion chart exceeds a Control limit, that should only +1 the value on the "Any Alarm" column and only add +1 to the numerator in the "Alarm rate" column.  For example, if subgroup 2 (of 10) fails for the mean and 3 way within dispersion chart UCL's, and is the only subgroup to fail then the "Alarm Rate" should be 10% and the "Any Alarm" should be 1.  Currently this would show as 20% and 2, which is a misleading look at the process.
  4. Since the goal of Process Screening is to be a kind of one-stop shop for an overview of all your processes, it would be value-added to the users to have the platform have the overall alarm rate reflect all the alarm types being selected by the user.  (So, I would like to see a Means alarm rate, MR alarm rate, Range Within alarm rate, and an Overall alarm rate which flags for any tests that were selected by the users to flag a subgroup as defective {MR for an I-MR chart can be excluded here as it spans "two subgroups}).  

              How this might look:

shampton82_1-1674446957988.png

 

shampton82_2-1674446968556.jpeg

 

Note: took keep consistent with Control Chart Builder using “Test All Beyond Limits - All” vs "Enable all tests" might work better.  I noticed that after I made this picture above.

 

In the picture below you can see both issues for items 1 and 3:

  1. There are no lower control limits on either of the dispersion charts and the platform does not respect any violations of the LCL (which is an issue for -R or -S or the within charts in three-way charts) and thus, leads to a incorrect alarm rate.
  2. For the electricity subgroup, it is out of control for both the X-Bar and Range within charts and thus is counted as two alarms, when it should only be counted as one (as the denominator is the number of subgroups).  Thus, the alarm rate should be 3/17 not 4/17.
  3. shampton82_0-1674445718517.png

     

If for some reason item 1 from above cannot be added on, at the very least, then the names should be changed to “Upper moving range limit exceeded” and “Upper range limit exceeded” so that the user won't assume that they include both due to the current naming convention.

 

 

 

Why is this idea important?  This is important for the following reasons:

  1. You should get the same results from both Control Chart Builder and Process Screening, especially since Process Screening will send you to Control Chart builder as an available feature in the platform.
  2. Tracking and understanding within process variation is just as important as variation between the means and is especially critical when using three-way charts.
  3. Different companies will have different priorities on what alarm rates matter and thus the user group should be able to control what to display in the Process Screening platform (e.g. whether to turn on or off LCLs in MR and R charts).

Whew, hopefully that came out clear.  Please let me know if I need to clear anything up!

 

Steve

 

2 Comments

Thank you for your engagement @shampton82

 

I have a few minor comments.

 

Regarding your discussion about the alarm rate calculation. I think it needs to be clarified for the user in the platform directly, as either as a tooltip, a disclosure button, or similar; how it is being calculated.  I don't disagree with your thoughts about the calculation either -- and I agree it should align with Control Chart Builder, especially if the platform is designed to be able to Control Chart Builder from it.

 

In the figure describing the alarm rates, the annotation for the calculation is slightly off (just a typo). 4/17 is 0.23529 not 0.2359.  Also suggest putting some words on the picture directly to fully describe what your expectation is versus what JMP is reporting.  Kind of redundant but helpful I think for others viewing/interpreting your request especially people not as familiar with the PS Platform or SPC charting in general.

mia_stephens
Staff
Status changed to: Investigating