이 위시리스트 요청에 영감을 준 것은 무엇입니까?
우리 회사의 프로세스 제어 그룹은 프로세스 스크리너 플랫폼을 점점 더 많이 사용하고 있으며 알람 비율은 우리에게 핵심 메트릭이 되고 있습니다. 또한, 우리는 3방향 차트를 점점 더 많이 사용하고 있으며 3방향 차트에서 내 차트의 알람 비율을 추적하고 이해하는 것은 평균 차트만큼 중요합니다.플랫폼 간 결과와 예상 결과를 비교하려고 할 때 불일치를 발견했습니다.
나는 함께 일해 왔다 @패트릭 줄리아노 JMP 고객 서비스에서 플랫폼이 작동하도록 설계된 방식과 이것이 요구하는 목표를 확인합니다.
당신이 보고 싶은 개선점은 무엇입니까?
PS(Process Screener) 플랫폼의 알람 속도 섹션은 어떤 프로세스를 먼저 공격할지 파레토를 파악하고 시간 경과에 따른 성능 변화를 추적하는 동시에 추세를 빠르게 시각화할 수 있는 좋은 방법입니다.다음을 보고 싶습니다.
- "Alarm Rate Column" 및 "Any Alarm" 열은 제어 상한 및 하한에서 계산된 모든 선택된 경보 속도를 존중해야 합니다.현재 평균 차트(및 기타 테스트)에 대한 두 제어 한계만 계산하지만 3방향 차트를 선택한 경우 "범위 한계 초과"에 대한 상위 제어 한계만 계산합니다.
- LCL을 준수하지 않으면 PS 대 제어 차트 빌더에서 프로세스를 볼 때 다른 경보 비율이 발생합니다.이것은 또한 PS에서 "선택한 대로 차트 표시"를 사용하고 UCL만 표시되는 분산 차트에 추가할 때 컨트롤 차트 빌더와 다르게 보이는 컨트롤 차트를 생성합니다.
- 분산 차트의 이름을 더 명확하게 변경해야 합니다."Range Limit Exceeded"는 "Disp Limit Exceeded"로 이동해야 하며 MR/-R/-S/three way S/R 해도와 함께 사용해야 하며 "3W MR Limit 초과"는 Three way 해도의 MR 해도에 사용해야 합니다.
- 알람 비율 및 알람 횟수는 각 "테스트" 열과 3방향 "범위 제한 초과"에 대한 알람 비율의 합계가 아니어야 합니다.하위 그룹에 대해서만 합산해야 합니다(따라서 하위 그룹이 평균 차트에서 "테스트"에 실패하거나 하위 그룹 분산 차트가 제어 제한을 초과하는 경우 "Any Alarm" 열의 값에 +1만 추가하고 +만 추가해야 합니다. "경보율" 열의 분자에 1을 입력합니다.예를 들어 하위 그룹 2(10개 중)가 분산 차트 UCL의 평균 및 3방향에 대해 실패하고 실패한 유일한 하위 그룹인 경우 "경보 비율"은 10%이고 "모든 경보"는 1이어야 합니다. 현재 이것은 20%와 2로 표시되며, 이는 프로세스를 잘못 보는 것입니다.
- 프로세스 스크리너의 목표는 모든 프로세스의 개요를 위한 일종의 원스톱 쇼핑이 되는 것이므로 사용자가 선택한 모든 알람 유형을 플랫폼의 전체 알람 비율에 반영하도록 하는 것은 사용자에게 가치를 더할 것입니다. .(그래서 저는 평균 경보 비율, MR 경보 비율, 범위 내 경보 비율, 하위 그룹을 불량으로 플래그 지정하기 위해 사용자가 선택한 모든 테스트에 플래그를 지정하는 전체 경보 비율을 보고 싶습니다. {MR for an I-MR 문자는 "2개의 하위 그룹"에 걸쳐 있으므로 여기에서 제외할 수 있습니다}).
이것이 어떻게 보이는지:
"Test All Beyond Limits - All"과 "Enable all tests"를 사용하여 컨트롤 차트 빌더와 일관성을 유지하면 더 잘 작동할 수 있습니다.이 사진을 찍고 나서 알았습니다.
아래 그림에서 항목 1과 3에 대한 두 가지 문제를 모두 볼 수 있습니다.
- 분산 차트 중 하나에 제어 하한이 없으며 플랫폼이 LCL 위반(-R 또는 -S 또는 3방향 차트의 내부 차트에 대한 문제임)을 준수하지 않으므로 잘못된 경보가 발생합니다. 비율.
- 전기 하위 그룹의 경우 차트 내의 X 막대 및 범위 모두에 대해 제어할 수 없으므로 하나로만 계산해야 할 때 두 개의 경보로 계산됩니다(분모는 하위 그룹의 수이므로).따라서 램 비율은 4/17이 아니라 3/17이어야 합니다.
어떤 이유로 위의 항목 1을 바로 임대할 수 없는 경우 이름을 " 높은 이동 범위 제한 초과" 및 " 높은 범위 제한을 초과했습니다.”라고 표시하여 사용자는 현재 명명 규칙으로 인해 둘 다 포함한다고 가정하지 않습니다.
이 아이디어가 중요한 이유는 무엇입니까?이는 다음과 같은 이유로 중요합니다.
- 특히 Process Screener가 사용자를 컨트롤 차트 빌더로 보내므로 Control Chart Builder와 Process Screener 모두에서 동일한 결과를 얻어야 합니다.
- 프로세스 변동 내에서의 추적 및 이해는 수단 간의 변동만큼 중요하며 특히 3원 차트를 사용할 때 중요합니다.
- 다른 회사는 중요한 경보 비율에 대해 서로 다른 우선 순위를 가지므로 사용자 그룹은 Process screener 플랫폼에 표시할 항목을 제어할 수 있어야 합니다.
휴, 분명하게 나왔으면 합니다.정리해야 할 것이 있으면 알려주세요!
스티브
