¿Qué inspiró esta solicitud de lista de deseos?
Los grupos de control de procesos de mi empresa utilizan cada vez más la plataforma de detección de procesos y la tasa de alarmas se está convirtiendo en una métrica clave para nosotros. Además, usamos cada vez más el gráfico de tres vías y es tan importante en los gráficos de tres vías rastrear y comprender la tasa de alarma en los gráficos internos como en los gráficos medios.Al intentar comparar los resultados entre plataformas, así como los resultados esperados, encontramos discrepancias.
he estado trabajando con @patrickgiuliano en el servicio al cliente 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 Screener (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 tasa de alarma" y "Cualquier alarma" deben respetar todas las tasas 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 medio (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 cuando se visualiza un proceso en el generador PS vs Control Chart.Esto también crea gráficos de control que tienen un aspecto diferente al del generador de gráficos de control cuando se usa "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 deben cambiarse para que sean más claros."Límite de rango excedido" debe ir a "Límite de visualización excedido" y usarse con gráficos MR/-R/-S/S/R de tres vías y "Límite de MR de 3 W excedido" debe usarse para gráficos de MR en gráficos de tres vías.
- Las tasas de alarma y el conteo 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 sumarse en un subgrupo (por lo que si algún subgrupo falla en una "prueba" en el gráfico de medias o el gráfico de dispersión del subgrupo excede un límite de control, eso solo debería +1 el valor en la columna "Cualquier alarma" y solo agregar + 1 al numerador en la columna "Tasa de alarma".Por ejemplo, si el subgrupo 2 (de 10) falla para 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" debe ser 10% y "Cualquier alarma" debe ser 1. Actualmente esto se mostraría como 20% y 2, lo cual es una mirada engañosa al proceso
- Dado que el objetivo del evaluador de procesos 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 la 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 medios, una tasa de alarma de MR, una tasa de alarma de rango interior y una tasa de alarma general que señale cualquier prueba seleccionada por los usuarios para marcar un subgrupo como defectuoso {MR para un I-MR char se puede excluir aquí ya que abarca "dos subgrupos"}).
Cómo podría verse esto:
Se mantuvo consistente con Control Chart Builder usando "Probar todo más allá de los límites: todo" frente a "Habilitar todas las pruebas" podría funcionar mejor.Lo noté después de hacer esta foto.
En la imagen a continuación, puede ver ambos problemas para los elementos 1 y 3:
- No hay límites de control más bajos en ninguno de los gráficos de dispersión y la plataforma no respeta ninguna violación del LCL (que es un problema para -R o -S o los gráficos internos en los gráficos de tres vías) y, por lo tanto, genera una alarma incorrecta. índice.
- 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 debe contarse como una (ya que el denominador es el número de subgrupos).Por lo tanto, la tasa de alarma debe ser 3/17, no 4/17.
Si por alguna razón no se puede actuar sobre el artículo 1 de arriba en el mismo contrato de arrendamiento, 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 suponga que incluyen 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 de Control Chart Builder como de Process Screener, especialmente porque Process Screener lo enviará al generador de Control Chart.
- El seguimiento y la comprensión dentro de la variación 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.
- Las 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 Process Screener.
Vaya, espero que haya salido claro.¡Avísame si necesito aclarar algo!
Steve
