¿Qué inspiró esta solicitud de lista de deseos?
Los grupos de control de procesos de mis empresas utilizan cada vez más la plataforma Process Screening y la tasa de alarma se está convirtiendo en una métrica clave para nosotros. Además, utilizamos cada vez más gráficos de tres vías, y en los gráficos de tres vías es tan importante rastrear y comprender la tasa de alarma en los gráficos internos como en los gráficos de media.Al intentar comparar los resultados entre plataformas, así como los resultados esperados, encontramos discrepancias.
he estado trabajando con @PatrickGiuliano en el soporte técnico de JMP para analizar cómo se ha diseñado la plataforma para que funcione frente a los objetivos de esta solicitud.
¿Cuál es la mejora que le gustaría ver?
La sección de tasa de alarma de la plataforma Process Screening (PS) es una excelente manera de poder determinar qué proceso atacar primero, así como realizar un seguimiento de los cambios de rendimiento a lo largo del tiempo y, al mismo tiempo, poder visualizar rápidamente las tendencias.Me gustaría ver lo siguiente:
- Las columnas "Columna de frecuencia de alarma" y "Cualquier alarma" deben respetar todas las frecuencias de alarma seleccionadas calculadas a partir de los límites de control superior e inferior.Actualmente, solo calculan ambos límites de control para el gráfico de media (así como cualquier otra prueba), pero solo el límite de control superior para el "Límite de rango excedido" cuando se selecciona un gráfico de tres vías.
- No respetar el LCL provoca diferentes tasas de alarma al visualizar un proceso en el generador de gráficos de control y PS.Esto también crea gráficos de control que tienen un aspecto diferente al del generador de gráficos de control cuando se utiliza "mostrar gráfico como seleccionado" en el PS y se agrega el gráfico de dispersión, ya que solo se muestra el UCL.
- Los nombres de los gráficos de dispersión deberían cambiarse para que sean más claros."Límite de rango excedido" debe ir a "Límite de visualización excedido" y debe usarse con gráficos MR/-R/-S/S/R de tres vías y "Límite de MR de 3 vías excedido" debe usarse para gráficos MR en gráficos de tres vías.
- Las tasas de alarma y el recuento de alarmas no deben ser la suma de las tasas de alarma para cada columna de "Prueba" y "Límite de rango excedido" de tres vías.Solo deben resumirse en un subgrupo (por lo tanto, si algún subgrupo falla una "prueba" en el gráfico de media o el gráfico de dispersión del subgrupo excede un límite de control, eso solo debería hacer +1 en el valor de la columna "Cualquier alarma" y solo agregar + 1 al numerador de la columna "Tasa de alarma".Por ejemplo, si el subgrupo 2 (de 10) falla en la media y 3 vías dentro de los UCL del gráfico de dispersión, y es el único subgrupo que falla, entonces la "Tasa de alarma" debería ser 10% y "Cualquier alarma" debería ser 1. Actualmente esto se mostraría como 20% y 2, lo cual es una visión engañosa del proceso.
- Dado que el objetivo de Process Screening es ser una especie de ventanilla única para obtener una descripción general de todos sus procesos, sería un valor agregado para los usuarios que la plataforma tenga una tasa de alarma general que refleje todos los tipos de alarma seleccionados por el usuario.(Por lo tanto, me gustaría ver una tasa de alarma de medias, una tasa de alarma de RM, una tasa de alarma de rango dentro y una tasa de alarma general que indique cualquier prueba seleccionada por los usuarios para marcar un subgrupo como defectuoso {MR para un I- El gráfico de RM se puede excluir aquí ya que abarca "dos subgrupos}).
Cómo podría verse esto:
Nota: mantener la coherencia con Control Chart Builder usando "Probar todo más allá de los límites - Todo" en lugar de "Habilitar todas las pruebas" podría funcionar mejor.Me di cuenta de eso después de hacer esta foto de arriba.
En la imagen a continuación puede ver ambos problemas para los elementos 1 y 3:
- No hay límites de control inferiores en ninguno de los gráficos de dispersión y la plataforma no respeta ninguna violación del LCL (lo cual es un problema para -R o -S o los gráficos internos en los gráficos de tres vías) y, por lo tanto, conduce a una tasa de alarma incorrecta.
- Para el subgrupo de electricidad, está fuera de control tanto para la barra X como para el rango dentro de los gráficos y, por lo tanto, se cuenta como dos alarmas, cuando solo debería contarse como una (ya que el denominador es el número de subgrupos).Por lo tanto, la tasa de alarma debería ser 3/17, no 4/17.
Si por alguna razón el elemento 1 de arriba no se puede agregar, al menos, entonces los nombres deben cambiarse a " Superior límite de rango de movimiento excedido” y “ Superior límite de rango excedido” para que el usuario no asuma que incluye ambos debido a la convención de nomenclatura actual.
¿Por qué es importante esta idea?Esto es importante por las siguientes razones:
- Debería obtener los mismos resultados tanto del Generador de gráficos de control como del Detección de procesos, especialmente porque el Detección de procesos lo enviará al Generador de gráficos de control como una función disponible en la plataforma.
- El seguimiento y la comprensión de la variación dentro del proceso es tan importante como la variación entre los medios y es especialmente crítico cuando se utilizan gráficos de tres vías.
- Diferentes empresas tendrán diferentes prioridades sobre qué tasas de alarma importan y, por lo tanto, el grupo de usuarios debería poder controlar qué mostrar en la plataforma de detección de procesos (por ejemplo, si se activan o desactivan los LCL en los gráficos MR y R).
Vaya, ojalá haya quedado claro.¡Avíseme si necesito aclarar algo!
esteban
Gracias por tu compromiso @shampton82 !
Tengo algunos comentarios menores.
Respecto a su discusión sobre el cálculo de la tasa de alarma. Creo que es necesario aclararlo directamente al usuario en la plataforma, ya sea como información sobre herramientas, botón de divulgación o similar; cómo se está calculando.Tampoco estoy en desacuerdo con su opinión sobre el cálculo, y estoy de acuerdo en que debería alinearse con Control Chart Builder, especialmente si la plataforma está diseñada para poder controlar Control Chart Builder desde allí.
En la figura que describe las tasas de alarma, la anotación para el cálculo está ligeramente equivocada (solo un error tipográfico). 4/17 es 0,235 2 9 no 0,2359. También sugiera poner algunas palabras en la imagen directamente para describir completamente cuáles son sus expectativas en comparación con lo que informa JMP.Algo redundante, pero creo que es útil para otras personas que vean/interpreten su solicitud, especialmente para las personas que no están tan familiarizadas con la plataforma PS o los gráficos SPC en general.
