이 위시리스트 요청에 영감을 준 것은 무엇입니까?
우리 회사의 프로세스 제어 그룹은 점점 더 프로세스 스크리닝 플랫폼을 사용하고 있으며 경보율은 우리에게 핵심 지표가 되고 있습니다. 또한 우리는 3방향 차트를 점점 더 많이 사용하고 있으며, 3방향 차트에서는 평균 차트만큼 내부 차트의 경보 비율을 추적하고 이해하는 것이 중요합니다.플랫폼 간 결과와 예상 결과를 비교하려고 시도한 결과 불일치가 발견되었습니다.
나는 함께 일해 왔습니다 @PatrickGiuliano JMP 기술 지원팀에서는 요청 목표에 맞춰 플랫폼이 어떻게 작동하도록 설계되었는지 알아보겠습니다.
당신이 보고 싶은 개선점은 무엇입니까?
프로세스 스크리닝(PS) 플랫폼의 경보율 섹션은 어떤 프로세스를 먼저 공격할지 파레토화하고 시간 경과에 따른 성능 변화를 추적하는 동시에 추세를 신속하게 시각화할 수 있는 좋은 방법입니다.나는 다음을 보고 싶습니다:
- "경보 속도 열" 및 "모든 경보" 열은 제어 상한 및 하한을 모두 계산하여 선택한 모든 경고 속도를 준수해야 합니다.현재는 평균 차트(및 기타 테스트)에 대한 두 가지 관리 한계만 계산하지만 3방향 차트를 선택한 경우 "범위 제한 초과"에 대한 관리 상한만 계산합니다.
- LCL을 준수하지 않으면 PS 대 제어 차트 빌더에서 프로세스를 볼 때 경고 비율이 달라집니다.또한 PS에서 "선택한 차트 표시"를 사용하고 UCL만 표시될 때 분산 차트에 추가할 때 관리 차트 빌더와 모양이 다른 관리 차트를 생성합니다.
- 분산 차트의 이름을 더 명확하게 변경해야 합니다."Range Limit Exceeded"는 "Disp Limit Exceeded"로 이동해야 하며 MR/-R/-S/3방향 S/R 차트와 함께 사용해야 하며 "3W MR 제한 초과"는 3방향 차트의 MR 차트에 사용해야 합니다.
- 경보 비율과 경보 횟수는 각 "테스트" 열과 3방향 "범위 제한 초과"에 대한 경보 비율의 합이 되어서는 안 됩니다.하위 그룹 전체에 대해서만 합산해야 합니다. 따라서 하위 그룹이 평균 차트에서 "테스트"에 실패하거나 하위 그룹 분산 차트가 관리 한계를 초과하는 경우 "모든 경보" 열의 값에 +1만 추가하고 +만 추가해야 합니다. "경보 속도" 열의 분자에 1을 입력합니다.예를 들어, 하위 그룹 2(10개 중)가 분산 차트 UCL 내 평균 및 3방향에 대해 실패하고 유일한 하위 그룹이 실패한 경우 "경보 비율"은 10%이고 "모든 경보"는 1이어야 합니다. 현재 이는 20%와 2로 표시되며, 이는 프로세스를 잘못 보는 것입니다.
- 프로세스 스크리닝의 목표는 모든 프로세스의 개요를 볼 수 있는 일종의 원스톱 상점이 되는 것이기 때문에 플랫폼이 선택한 모든 알람 유형을 반영하는 전체 알람 비율을 갖도록 하는 것이 사용자에게 부가 가치가 될 것입니다. 사용자.(따라서 사용자가 하위 그룹을 결함으로 표시하기 위해 선택한 모든 테스트에 대해 표시되는 평균 경보 비율, MR 경보 비율, 범위 내 경보 비율 및 전체 경보 비율을 보고 싶습니다. MR 차트는 "두 개의 하위 그룹}에 걸쳐 있으므로 여기에서 제외될 수 있습니다.
이것이 어떻게 보일 수 있습니까?
참고: "한계를 넘어선 모든 테스트 - 모두"와 "모든 테스트 활성화"를 사용하여 관리도 작성기와 일관성을 유지하는 것이 더 효과적일 수 있습니다.위 사진을 찍고 나서야 알았습니다.
아래 그림에서는 항목 1과 3에 대한 두 가지 문제를 모두 볼 수 있습니다.
- 분산 차트에는 더 낮은 제어 한계가 없으며 플랫폼은 LCL 위반(-R 또는 -S 또는 3방향 차트의 내부 차트에 대한 문제)을 존중하지 않으므로 다음과 같은 문제가 발생합니다. 잘못된 경보율.
- 전기 하위 그룹의 경우 차트 내의 X-Bar와 범위 모두에 대해 통제 범위를 벗어났기 때문에 두 개의 경보로 계산되지만 한 개로만 계산되어야 합니다(분모는 하위 그룹의 수이므로).따라서 경보율은 4/17이 아닌 3/17이어야 합니다.
어떤 이유로 위의 항목 1을 추가할 수 없는 경우 최소한 이름을 "로 변경해야 합니다. 높은 이동 범위 제한을 초과했습니다.” 및 “ 높은 범위 제한을 초과했습니다.” 현재 명명 규칙으로 인해 사용자가 둘 다 포함한다고 가정하지 않도록 합니다.
이 아이디어가 왜 중요한가요?이는 다음과 같은 이유로 중요합니다.
- 컨트롤 차트 빌더와 프로세스 스크리닝 모두에서 동일한 결과를 얻어야 합니다. 특히 프로세스 스크리닝이 플랫폼에서 사용 가능한 기능으로 컨트롤 차트 빌더로 전송되기 때문입니다.
- 프로세스 변동 내에서 추적하고 이해하는 것은 평균 간의 변동만큼 중요하며 3방향 차트를 사용할 때 특히 중요합니다.
- 회사마다 경보율이 중요한 우선순위가 다르므로 사용자 그룹은 프로세스 스크리닝 플랫폼에 표시할 내용(예: MR 및 R 차트에서 LCL을 켜거나 끌지 여부)을 제어할 수 있어야 합니다.
휴, 분명하게 밝혀졌기를 바랍니다.정리해야 할 사항이 있으면 알려주세요!
스티브
참여해주셔서 감사합니다 @shampton82 !
몇 가지 소소한 의견이 있습니다.
경보율 계산에 관한 귀하의 논의와 관련하여. 툴팁, 공개 버튼 또는 이와 유사한 형태로 플랫폼 내 사용자에게 직접적으로 명확하게 설명할 필요가 있다고 생각합니다. 어떻게 계산되고 있는지.나는 계산에 대한 귀하의 생각에 동의하지 않으며 특히 플랫폼이 제어 차트 작성기를 사용할 수 있도록 설계된 경우 제어 차트 작성기와 일치해야 한다는 데 동의합니다.
경보율을 설명하는 그림에서 계산에 대한 주석이 약간 벗어났습니다(단지 오타임). 4/17은 0.235입니다. 2 9는 0.2359가 아닙니다. 또한 JMP가 보고하는 내용과 기대하는 바를 완벽하게 설명하기 위해 그림에 단어를 직접 입력하는 것이 좋습니다.다소 중복되지만 도움이 되는 것으로 생각됩니다. 특히 PS 플랫폼이나 SPC 차트 전반에 익숙하지 않은 사람들이 귀하의 요청을 보거나 해석하는 경우에 그렇습니다.
