품질 관리 데이터 템플릿
품질 관리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
품질 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
이벤트 시작 시각
EventStartTime
|
활동 또는 이벤트가 시작된 시각을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 특정 프로세스 단계가 시작된 날짜와 시각을 정확히 나타냅니다. 이벤트를 시간순으로 정렬하고 각 품질 이벤트 케이스의 프로세스 순서를 구성하는 데 사용하는 주요 시간 정보입니다. 분석에서는 이벤트 시작 시각을 기준으로 처리 시간, 소요 시간, 활동 간 대기 시간을 계산합니다. 연속된 단계 사이의 지연이 긴 구간을 찾아 병목을 식별하고, 근본 원인 분석 소요 시간과 같은 시간 기반 KPI의 성과를 추적할 수 있습니다.
중요한 이유
이 타임스탬프는 프로세스 분석의 기반으로, 시간 관련 계산과 활동의 올바른 순서 정렬을 가능하게 합니다.
확보 방법
일반적으로 품질 조치 및 수집 계획과 관련된 트랜잭션 로그나 이력 테이블에서 확인할 수 있습니다. 필드명은 CREATION_DATE 또는 이와 유사한 경우가 많습니다.
예시
2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
|
|||
|
품질 이벤트
QualityEventId
|
부적합, 불만 또는 이탈과 같은 단일 품질 이벤트를 식별하는 고유 식별자입니다. | ||
|
설명
Quality Event ID는 기본 케이스 식별자로, 최초 보고부터 최종 종료까지 관련된 모든 활동을 하나로 묶습니다. 각 품질 사고에는 고유 ID가 부여되어 조사 및 해결 과정의 전체 이력이 기록됩니다. process mining 분석에서 이 속성은 각 품질 이벤트의 전체 진행 과정을 재구성하는 데 필수적입니다. 전체 주기 시간을 계산하고, 프로세스 변형을 식별하며, 이벤트 유형별 처리 방식을 분석할 수 있습니다. 모든 활동 로그를 특정 Quality Event ID에 연결하면 분석가는 전체 프로세스 흐름을 시각화하고 시스템 차원의 병목이나 규정 준수 문제를 파악할 수 있습니다.
중요한 이유
이 ID는 단일 케이스의 범위를 정의하므로 품질 이벤트를 정확히 추적하고 처음부터 끝까지의 성과 지표를 계산하는 데 필요합니다.
확보 방법
일반적으로 Oracle Quality Management의 주요 품질 이벤트 또는 수집 계획 테이블에서 기본 키로 사용됩니다. 예를 들어 QA_RESULTS가 있습니다.
예시
NC-2023-00123CAPA-45892QE-500-A
|
|||
|
활동명
ActivityName
|
품질 관리 프로세스에서 수행된 특정 작업 또는 단계의 이름입니다. | ||
|
설명
이 속성은 품질 이벤트를 관리하는 과정에서 발생한 개별 이벤트나 조치를 나타냅니다. 시각순으로 정렬한 활동이 각 케이스의 프로세스 흐름을 구성합니다. 활동명 분석은 process mining의 중심입니다. 실제 프로세스 모델을 발견하고, 규정 준수 여부를 확인하기 위해 목표 모델과 비교하며, 특정 활동 사이의 병목이나 재작업 루프를 식별할 수 있습니다. 예를 들어 '조사 시작'부터 '근본 원인 분석 수행'까지 걸린 시간을 측정할 수 있습니다.
중요한 이유
이 속성은 프로세스 흐름을 매핑하고 이탈을 식별하며 실제 업무 수행 방식을 파악하는 데 필수입니다.
확보 방법
일반적으로 Oracle Quality Management 모듈의 이벤트 로그, 상태 변경 기록 또는 조치 이력 테이블에서 가져옵니다.
예시
품질 문제 식별조사 시작시정 조치 계획 승인최종 검토 및 종결
|
|||
|
근본 원인 범주
RootCauseCategory
|
품질 이슈의 근본 원인을 분류한 항목입니다. | ||
|
설명
근본 원인 분석을 마치면 조사 결과를 '장비 고장', '작업자 오류', '설계 결함'과 같은 사전 정의된 범주로 분류하는 경우가 많습니다. 이 속성에는 최종 분류 결과가 저장됩니다. 근본 원인 범주별 프로세스 분석은 개별 증상을 해결하는 데 그치지 않고, 시스템에 내재한 문제를 개선하는 데 도움이 됩니다. 예를 들어 근본 원인이 '교육 미흡'인 이벤트가 많다면 직원 교육 프로그램을 보완해야 한다는 점을 알 수 있습니다. 이는 예방 조치의 주요 목표입니다.
중요한 이유
실패의 근본 원인을 분석할 수 있어 사후 대응 중심의 품질 관리에서 예방 중심의 품질 관리로 전환하는 데 도움이 됩니다.
확보 방법
Oracle Quality Management 문서를 참조하세요. 수집 계획에서 사용자가 정의하는 항목일 가능성이 높으며, '근본 원인 분석 수행' 활동 후에 값이 입력됩니다.
예시
장비 오작동자재 결함작업자 오류절차 미준수
|
|||
|
담당 부서
ResponsibleDepartment
|
품질 이벤트 또는 현재 활동을 담당하는 부서나 기능 영역입니다. | ||
|
설명
이 속성은 품질 이벤트 처리를 맡은 팀이나 부서를 식별합니다. 품질 보증, 엔지니어링, 생산 또는 다른 부서가 담당할 수 있으며, 이벤트가 진행되는 동안 담당 부서가 바뀔 수 있습니다. process mining에서 담당 부서별 분석은 업무량 분포를 파악하고 부서별 병목을 식별하며 팀 간 성과를 비교하는 데 중요합니다. '품질 이벤트 리소스 배분' 대시보드에서 부서별 담당 활동 유형을 확인해 리소스 관리를 개선할 수 있습니다.
중요한 이유
부서별 업무량, 성과, 병목을 분석할 수 있어 리소스 계획과 조직 개선에 도움이 됩니다.
확보 방법
Oracle Quality Management 문서를 확인하세요. 품질 이벤트와 연결된 품질 조치 또는 배정 관련 테이블에 저장되어 있을 수 있습니다.
예시
품질 엔지니어링제조 운영공급업체 품질설계 엔지니어링
|
|||
|
담당 사용자
AssignedUser
|
활동을 수행하거나 품질 이벤트를 담당하는 사용자입니다. | ||
|
설명
이 속성은 특정 작업이나 품질 이벤트 전반을 담당하는 사람을 나타냅니다. 담당 부서보다 세부적인 정보를 제공합니다. 사용자별로 분석하면 개인별 업무량을 파악하고 교육 필요성을 확인하며 성과가 높은 사용자를 찾을 수 있습니다. 업무가 반복적으로 재배정되거나 특정 사용자에게서 정체되는 패턴도 확인할 수 있습니다. 이 수준의 정보는 성과 관리와 세부적인 리소스 최적화에 유용합니다.
중요한 이유
개인별 업무량과 성과를 세부적으로 분석해 리소스 제약이나 교육 기회를 파악할 수 있습니다.
확보 방법
Oracle Quality Management 문서를 확인하세요. 사용자 배정 정보는 일반적으로 품질 이벤트와 관련된 조치 또는 워크플로 테이블에 저장됩니다.
예시
j.smitha.jonesr.williams
|
|||
|
목표 해결일
TargetResolutionDate
|
품질 이벤트를 최종 종결할 예정일 또는 예상일입니다. | ||
|
설명
품질 이벤트를 완전히 해결해야 하는 기한을 나타내는 속성입니다. 서비스 수준 계약(SLA) 또는 내부 목표로 사용되며, 이벤트의 심각도나 유형에 따라 정하는 경우가 많습니다. 이 날짜는 성과 모니터링의 기준이 되며 'CAPA Impl. On-Time Rate' KPI 계산에 직접 사용됩니다. 활동의 실제 완료일과 목표일을 비교하면 적시성을 측정하고, 지연 위험이 있는 이벤트를 파악하며, 기한 내 처리 추이를 추적할 수 있습니다. 이를 바탕으로 해결 주기를 단축할 수 있습니다.
중요한 이유
기한 준수 성과를 측정하는 기준이며, 적시성 KPI를 계산하고 SLA를 관리하는 데 필요합니다.
확보 방법
Oracle Quality Management 문서를 참조하세요. 표준 날짜 필드이거나 품질 수집 계획에서 사용자가 정의한 항목일 수 있습니다.
예시
2023-05-302023-06-152024-01-10
|
|||
|
심각도
SeverityLevel
|
심각, 중대, 경미 등 품질 이벤트가 미치는 영향의 분류입니다. | ||
|
설명
심각도는 일반적으로 초기 분류 단계에서 평가하며, 품질 문제가 고객, 규정 준수 또는 비즈니스 운영에 미칠 수 있는 영향을 나타냅니다. 이 분류를 바탕으로 리소스 우선순위를 정하고 필요한 대응의 긴급성을 결정합니다. process mining에서 이 속성은 데이터를 구분해 분석하는 데 중요합니다. 분석가는 심각도가 높은 이벤트와 낮은 이벤트의 프로세스 흐름, 처리 시간, 결과를 비교할 수 있습니다. 이를 통해 '품질 이벤트 초기 분류 일관성' 대시보드와 '심각도별 해결률' KPI를 지원하고, 심각한 문제가 실제로 더 빠르고 효과적으로 처리되는지 확인할 수 있습니다.
중요한 이유
우선순위를 정하고 분석 대상을 구분해 영향이 큰 품질 이벤트를 효과적이고 효율적으로 관리할 수 있습니다.
확보 방법
Oracle Quality Management 문서를 참조하세요. 품질 수집 계획에서 설정할 수 있는 항목인 경우가 많습니다.
예시
1 - 중요2 - 주요3 - 경미4 - 정보 제공
|
|||
|
이벤트 종료 시각
EventEndTime
|
활동 또는 이벤트가 완료된 시각을 나타내는 타임스탬프입니다. | ||
|
설명
이벤트 종료 시각은 특정 활동이 완료된 시점을 나타냅니다. 이벤트 시작 시각과 함께 사용하면 해당 활동의 처리 시간을 계산할 수 있습니다. 일부 시스템에서는 활동이 즉시 완료되어 시작 시각과 종료 시각이 같을 수 있습니다. 이 속성은 상세한 소요 시간 분석에 필요합니다. 활동의 시작과 종료 사이의 능동 처리 시간과 한 활동의 종료부터 다음 활동의 시작까지의 대기 시간을 구분할 수 있습니다. 이를 통해 리소스가 실제로 투입되는 구간과 인계로 인해 지연이 발생하는 구간을 파악할 수 있습니다.
중요한 이유
활동별 처리 시간을 정확히 계산해 비효율적인 작업과 대기 시간이 긴 구간을 구분할 수 있습니다.
확보 방법
시작 시각과 같은 트랜잭션 또는 이력 테이블에서 확인할 수 있으며, LAST_UPDATE_DATE나 별도의 완료 시각 필드로 저장되기도 합니다. 다음 이벤트의 시작 시각을 기준으로 추론할 수도 있습니다.
예시
2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
|
|||
|
현재 상태
CurrentStatus
|
품질 이벤트 케이스의 현재 상태입니다. | ||
|
설명
이 속성은 'Open', 'Under Investigation', 'Pending Approval', 'Closed'와 같이 품질 이벤트의 현재 진행 상태를 나타냅니다. 데이터 추출 시점에 케이스가 프로세스의 어느 단계에 있는지 보여줍니다. 운영 현황을 모니터링하는 데 중요한 속성으로, '미해결 품질 이벤트 및 상태 개요' 대시보드에 직접 활용됩니다. 관리자는 현재 처리 중인 품질 문제를 빠르게 확인하고 리소스 우선순위를 정할 수 있습니다. process mining에서는 최종 상태별로 필터링해 프로세스 경로에 따른 결과를 분석할 수 있습니다.
중요한 이유
품질 이벤트 처리 현황을 실시간으로 파악해 진행 중인 케이스를 효과적으로 관리하고 우선순위를 정할 수 있습니다.
확보 방법
일반적으로 품질 이벤트의 기본 헤더 테이블에서 확인할 수 있으며, 이벤트의 마지막 상태를 반영합니다.
예시
진행 전진행 중승인 대기종결
|
|||
|
기한 내 완료 여부
IsOnTime
|
시정 조치가 목표 해결일까지 이행되었는지 나타내는 플래그입니다. | ||
|
설명
이 불리언 속성은 '시정 조치 이행' 활동의 완료 타임스탬프와 사례의 '목표 해결일'을 비교해 산출합니다. 목표일까지 또는 그 전에 조치를 완료하면 true, 그렇지 않으면 false입니다. 이 속성은 'CAPA Impl. On-Time Rate' KPI를 직접 지원합니다. 사례별 적시성을 명확하게 구분하므로 분석과 대시보드 구성이 간편해집니다. 서비스 수준 준수 여부를 모니터링하고 지연 원인을 파악하기 위해 쉽게 필터링하고 집계할 수 있습니다.
중요한 이유
목표 대비 기한 준수 여부를 간편하게 추적하고, 이 주요 KPI를 측정하고 보고할 수 있습니다.
확보 방법
데이터 변환 과정에서 계산하는 파생 플래그입니다. TargetResolutionDate와 해당 완료 활동의 타임스탬프가 필요합니다.
예시
truefalse
|
|||
|
사업부
BusinessUnit
|
품질 이벤트가 발생했거나 관리되고 있는 조직의 사업부 또는 부문입니다. | ||
|
설명
이 속성은 품질 이벤트를 조직 구조의 특정 영역에 할당합니다. 조직 단위별 품질 성과를 분석하고 비교하는 데 도움이 됩니다. 대기업에서는 사업부별로 프로세스를 분석해야 하는 경우가 많습니다. 사업부별 대시보드를 구성하고, 특정 부문의 품질 프로세스가 더 효율적인지 또는 고유한 과제를 겪고 있는지 파악할 수 있습니다. 이를 통해 전사 차원의 감독과 모범 사례 공유를 지원합니다.
중요한 이유
조직 내 여러 부문의 성과를 비교하고 분석하여 전사적인 품질 관리를 지원합니다.
확보 방법
일반적으로 거래와 연결된 조직 정보에 포함되며, 사용자 또는 부서의 마스터 데이터에서 가져오는 경우가 많습니다.
예시
의료기기소비자 가전자동차 부품
|
|||
|
소스 시스템
SourceSystem
|
데이터를 추출한 원본 시스템을 식별합니다. | ||
|
설명
이 속성은 이벤트 데이터의 원본 애플리케이션 또는 시스템을 나타냅니다. 기업 환경에서는 품질 이벤트 데이터가 Oracle Quality 모듈, 별도의 CAPA 시스템, 고객 불만 포털 등 여러 출처에서 들어올 수 있습니다. 분석 시 이 필드를 사용하면 데이터 계보를 파악하고 원본 시스템별로 프로세스를 구분할 수 있습니다. 데이터 거버넌스와 데이터 통합 문제 해결에도 중요하며, 여러 출처의 데이터를 결합한 프로세스 현황이 정확히 반영되도록 합니다.
중요한 이유
데이터 출처에 관한 정보를 제공하므로 데이터 검증과 거버넌스, 시스템별 프로세스 차이 분석에 중요합니다.
확보 방법
일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.
예시
Oracle Quality Management R12Oracle EBS 품질 관리QM-PROD
|
|||
|
시정 조치 계획 ID
CorrectiveActionPlanId
|
품질 이벤트 해결을 위해 생성한 시정 및 예방 조치 계획(CAPA)의 고유 식별자입니다. | ||
|
설명
이 속성은 품질 이벤트와 이를 해결하기 위해 수립한 시정 및 예방 조치 계획을 직접 연결합니다. 해당 계획은 자체 수명 주기를 가진 별도의 시스템 객체인 경우가 많습니다. 분석 시 이 ID를 사용해 품질 이벤트 프로세스 데이터와 CAPA 관리 프로세스 데이터를 결합하면 전체 상황을 파악할 수 있습니다. CAPA가 필요한 모든 이벤트에 계획이 지정되었는지 확인하고, 조치의 효과를 분석하는 데도 도움이 됩니다.
중요한 이유
문제인 품질 이벤트와 해결책인 CAPA를 연결하여 품질 관리 시스템을 처음부터 끝까지 종합적으로 분석할 수 있습니다.
확보 방법
품질 이벤트 레코드의 참조 필드로, CAPA 전용 테이블이나 모듈의 레코드를 가리킵니다.
예시
CAPA-2023-088CAPA-2023-091
|
|||
|
이슈 범주
IssueCategory
|
'제품 결함' 또는 '프로세스 이탈'과 같은 품질 이슈의 범주 또는 유형입니다. | ||
|
설명
이 속성은 품질 이벤트를 분류하여 유사한 이슈를 묶어 분석할 수 있게 합니다. 범주는 일반적으로 조직의 운영 환경에 맞게 정의합니다. 이슈 범주별로 프로세스를 분석하면 특정 문제 유형과 관련된 패턴을 찾을 수 있습니다. 예를 들어 '공급업체 자재' 이슈의 처리 주기가 '내부 프로세스' 이슈보다 훨씬 길다는 점을 확인할 수 있습니다. 이렇게 구분하면 개선 활동의 대상을 구체적으로 정할 수 있습니다.
중요한 이유
이슈를 범주별로 분류하면 특정 문제 영역의 추세와 근본 원인을 집중적으로 분석할 수 있습니다.
확보 방법
Oracle Quality Management 문서를 참조하세요. 품질 수집 계획에서 사용자가 정의한 항목일 가능성이 높습니다.
예시
제품 결함프로세스 이탈공급업체 자재고객 불만
|
|||
|
재작업 여부
IsRework
|
같은 사례에서 활동이 이전 단계를 반복하거나 재작업한 것인지 나타내는 플래그입니다. | ||
|
설명
이 불리언 플래그는 '시정 조치 계획 제안'과 같은 특정 활동이 하나의 품질 이벤트 사례에서 두 번 이상 발생하면 true로 설정됩니다. 이는 이전에 완료한 단계를 다시 수행해야 하는 프로세스의 반복 또는 수정이 있었음을 나타냅니다. 재작업을 파악하는 것은 process mining의 주요 기능입니다. 이 플래그를 사용하면 이러한 비효율을 수치화하고 '활동 재작업 빈도' KPI를 산출할 수 있습니다. 재작업이 잦은 단계와 발생 조건을 분석하면 교육, 데이터 품질 또는 승인 기준의 문제를 찾아 프로세스를 효율화할 기회를 확인할 수 있습니다.
중요한 이유
프로세스의 비효율과 반복을 표시하여 낭비를 수치화하고 재작업의 근본 원인을 파악할 수 있습니다.
확보 방법
데이터 준비 과정에서 이벤트 로그에 윈도 함수나 순차 분석을 적용해 계산합니다. 같은 사례에서 동일한 활동명이 여러 번 나타나는지 확인합니다.
예시
truefalse
|
|||
|
전체 처리 주기
TotalCycleTime
|
품질 이슈를 발견한 시점부터 최종 종결까지 걸린 총시간입니다. | ||
|
설명
이 속성은 단일 품질 이벤트 사례의 전체 처리 기간을 측정합니다. 첫 번째 활동('품질 이슈 확인')의 타임스탬프와 마지막 활동('최종 검토 및 종결')의 타임스탬프 간 차이로 계산합니다. 품질 관리 프로세스의 전반적인 효율성을 보여주는 주요 KPI입니다. '품질 이벤트 전체 처리 주기' 대시보드의 대표 지표로 사용됩니다. 시간에 따른 변화를 추적하고 심각도나 이슈 범주별로 구분하면 프로세스 상태와 개선 활동의 효과를 전반적으로 파악할 수 있습니다.
중요한 이유
품질 관리 프로세스의 시작부터 끝까지 전반적인 속도와 효율성을 측정하는 주요 KPI입니다.
확보 방법
process mining을 위한 데이터 처리 과정에서 사례별로 계산합니다. 각 QualityEventId의 첫 이벤트 시작 시각과 마지막 이벤트 종료 시각이 필요합니다.
예시
P30DT12HP15DP92D
|
|||
|
제품 식별자
ProductIdentifier
|
품질 이벤트와 관련된 제품의 식별자입니다. | ||
|
설명
이 속성은 품질 이벤트를 특정 제품, 자재 또는 서비스와 연결합니다. 제품 코드, SKU 또는 부품 번호일 수 있습니다. 이 연결 정보는 제품 품질 분석에 중요합니다. process mining을 활용하면 제품군별 품질 관리 프로세스를 비교하거나 품질 이슈와 자주 연관되는 제품을 파악할 수 있습니다. 이를 통해 개선이 가장 필요한 엔지니어링 또는 제조 영역을 우선순위에 따라 정할 수 있습니다.
중요한 이유
품질 이벤트를 특정 제품과 연결하여 제품별 품질 추세와 프로세스 차이를 분석할 수 있습니다.
확보 방법
이 정보는 품질 수집 계획의 필드에 저장되며, Oracle Inventory 품목 마스터와 연결되는 경우가 많습니다.
예시
SKU-100-A-REDPN-987654CHEM-X2
|
|||
|
종결 코드
ClosureCode
|
품질 이벤트를 종결한 이유나 결과를 나타내는 코드입니다. | ||
|
설명
품질 이벤트를 종결할 때 최종 결과를 분류하기 위해 종결 코드를 지정하는 경우가 많습니다. 예를 들면 '조치 효과 있음', '조치 불필요', '중복 이슈' 등이 있습니다. 이 속성은 결과 분석에 유용합니다. 종결 코드별로 필터링하면 성공적으로 해결된 경우와 그렇지 않은 경우의 프로세스 경로를 비교할 수 있습니다. '중복으로 종결된 이슈는 어떤 경로를 거치는가?'와 같은 질문에 답하고, 분류 및 우선순위 지정 과정의 비효율을 찾는 데 도움이 됩니다.
중요한 이유
사례의 결과를 파악할 수 있어 어떤 프로세스 경로가 성공적인 해결로 이어지는지 분석할 수 있습니다.
확보 방법
Oracle Quality Management 문서를 참조하세요. 최종 종결 활동 중에 입력하는 필드일 가능성이 높습니다.
예시
효과 있음조치 불필요중복위험 수용
|
|||
|
최근 데이터 업데이트
LastDataUpdate
|
소스 시스템에서 데이터를 가장 최근에 새로 고치거나 업데이트한 시각입니다. | ||
|
설명
이 속성은 process mining 데이터 세트에서 해당 이벤트의 데이터가 마지막으로 업데이트된 시각을 나타냅니다. 데이터의 최신성을 보여주므로 분석 결과가 얼마나 최근 정보를 반영하는지 파악할 수 있습니다. 대시보드와 보고서에서 이 타임스탬프는 사용자에게 분석 맥락을 제공하는 데 중요합니다. 실시간 데이터인지 특정 시점의 스냅샷인지 알려주므로, 운영 관련 의사결정을 내릴 때 참고할 수 있습니다. 데이터가 얼마나 최신인지 투명하게 확인할 수 있습니다.
중요한 이유
이 타임스탬프는 데이터의 최신성을 보여주므로 사용자가 프로세스 분석에 반영된 정보의 시점을 파악할 수 있습니다.
확보 방법
이 값은 데이터 ETL 과정에서 생성 및 저장되며, 일반적으로 데이터 파이프라인이 마지막으로 성공적으로 실행된 시각을 나타냅니다.
예시
2023-10-27T04:00:00Z2023-10-26T04:00:00Z
|
|||
품질 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
문제 분류 및 우선순위 지정
|
분석가가 초기 평가를 마치고 심각도, 우선순위, 문제 유형 등의 주요 속성을 지정할 때 발생합니다. 일반적으로 문제가 'New' 상태에서 'Assessed' 또는 'In Triage' 상태로 바뀔 때 기록됩니다. | ||
|
중요한 이유
이 단계는 '평균 초기 분류 처리 시간' KPI를 계산하는 데 중요합니다. 여기서 지연되면 전체 해결 과정이 늦어질 수 있으며, 특히 심각한 문제에 영향을 줍니다.
확보 방법
Quality Issue 기록의 상태가 'New'에서 'Under Assessment'로 바뀌거나 'Severity' 또는 'Priority'와 같은 필드에 처음으로 값이 입력될 때 추론합니다.
기록
상태 변경 또는 Severity나 Priority 필드에 처음 값이 입력된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
시정 조치 계획 승인
|
지정된 권한자가 제안된 시정 조치 계획을 공식 승인하는 활동입니다. 중요한 통제 지점으로, 일반적으로 명시적인 승인 작업이나 상태가 'Approved'로 바뀌는 방식으로 기록됩니다. | ||
|
중요한 이유
승인은 중요한 단계이자 병목이 자주 발생하는 지점입니다. 승인 시간을 분석하면 프로세스를 간소화하고 절차 준수 여부를 확인할 수 있습니다.
확보 방법
Quality Action 또는 CAPA 기록의 상태가 'Approved'로 바뀔 때 추론합니다. 승인 워크플로를 사용하는 Oracle 시스템은 감사 테이블에 이 변경을 명시적으로 기록하는 경우가 많습니다.
기록
'Approved' 상태로 변경된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
조사 시작
|
품질 문제의 근본 원인을 파악하기 위한 공식 조사 단계의 시작을 나타냅니다. 일반적으로 시스템에서 상태가 'Under Investigation'으로 바뀌는 방식으로 기록됩니다. | ||
|
중요한 이유
'근본 원인 분석 소요 시간' KPI를 측정하는 시작점이며, 공식 조사가 시작되기까지 문제가 얼마나 오래 대기하는지 파악하는 데 도움이 됩니다.
확보 방법
Quality Issue 또는 관련 Quality Action 기록의 상태가 'Investigation'으로 바뀔 때 추론합니다. 상태 변경 시각을 이벤트 시각으로 사용합니다.
기록
'Under Investigation' 또는 이에 준하는 상태로 변경된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
조치 효과 확인
|
실행한 시정 조치가 근본 원인을 해결하고 재발을 방지했는지 확인합니다. 사용자가 검증을 마치고 기록의 상태를 업데이트할 때 수집됩니다. | ||
|
중요한 이유
결과를 확인하는 중요한 단계이며 '효과성 검증률' KPI의 기준입니다. 시정 조치 주기를 마무리해 문제가 실제로 해결되었는지 확인합니다.
확보 방법
CAPA 기록의 상태가 'Verification Complete' 또는 'Effective'로 바뀔 때 추론합니다. 특정 검증 결과 필드에 값이 입력되는 경우도 있습니다.
기록
'Verification Complete' 또는 'Effective' 상태로 변경된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
최종 검토 및 종결
|
관련 조치가 모두 완료되었는지 확인하고 상위 품질 문제를 공식 종결하는 마지막 단계입니다. 기본 기록의 상태가 'Closed' 또는 'Resolved'로 최종 변경될 때 수집됩니다. | ||
|
중요한 이유
이 활동은 프로세스의 주요 종료 이벤트입니다. '평균 이벤트 처리 시간' KPI를 계산하고 전체 프로세스 처리량을 측정하는 데 필요합니다.
확보 방법
상위 Quality Issue 기록의 상태가 최종적으로 'Closed'로 바뀔 때 추론합니다. 변경 시각을 이벤트 시각으로 사용합니다.
기록
기본 Quality Issue 기록의 상태가 'Closed'로 바뀐 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
품질 문제 식별
|
부적합, 이탈 또는 고객 불만과 같은 새 품질 이벤트 기록이 생성될 때 발생하는 활동입니다. Oracle에서 사용자가 새 Quality Issue 또는 Quality Action 기록을 생성하면 명시적으로 기록됩니다. | ||
|
중요한 이유
시작 이벤트인 이 활동은 품질 관리 프로세스의 전체 처리 시간을 계산하고 유입되는 품질 이벤트의 규모를 파악하는 데 필요합니다.
확보 방법
Quality Issue 또는 Quality Action 기록의 생성 시각을 기준으로 이벤트를 수집합니다. QAM_QUALITY_ISSUES 또는 QAM_QUALITY_ACTIONS와 같은 테이블에서 확인할 수 있습니다.
기록
새 Quality Issue 또는 Action 기록이 생성될 때 이벤트를 기록합니다.
이벤트 유형
explicit
|
|||
|
근본 원인 분석 수행
|
근본 원인 분석(RCA)을 완료하고 결과를 기록하는 활동입니다. 일반적으로 조사팀이 품질 문제의 근본 원인을 기록하고 상태를 변경할 때 수집됩니다. | ||
|
중요한 이유
이 활동은 '근본 원인 분석 소요 시간' KPI의 종료점입니다. 여기까지 걸린 시간을 분석하면 문제 해결 단계의 병목을 찾을 수 있습니다.
확보 방법
상태가 'RCA Complete'로 바뀌거나 근본 원인 범주 필드에 값이 입력되고 기록이 저장될 때 추론합니다. 해당 업데이트 시각을 사용합니다.
기록
'RCA Complete' 상태로 변경되거나 근본 원인 필드에 값이 입력된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
시정 조치 계획 제안
|
문제를 해결하기 위한 단계를 정해 시정 조치를 정의하고 품질 문제에 연결할 때 발생합니다. 관련 Corrective Action 기록을 생성하거나 계획이 검토 준비를 마쳤음을 나타내는 상태 변경으로 기록할 수 있습니다. | ||
|
중요한 이유
문제 분석에서 해결 방안 설계로 넘어가는 시점을 추적합니다. 재작업 KPI로 측정한 이 단계의 재작업은 요구사항이 불명확하거나 계획이 효과적이지 않음을 나타낼 수 있습니다.
확보 방법
CAPA 객체에서 새 Corrective Action 기록을 생성해 명시적으로 기록하거나, 상태가 'Plan Proposed' 또는 'Pending Approval'로 바뀐 시점을 바탕으로 추론할 수 있습니다.
기록
'Pending Approval' 상태로 변경되거나 연결된 Corrective Action이 생성된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
시정 조치 실행
|
승인된 시정 조치 계획에 명시된 작업이 완료되었음을 나타냅니다. 일반적으로 사용자가 시정 조치 기록의 상태를 'Implemented' 또는 'Completed'로 변경할 때 기록됩니다. | ||
|
중요한 이유
계획된 조치가 실행되었음을 나타내므로 'CAPA 정시 실행률' KPI를 계산하는 데 중요합니다. 목표 날짜와 비교해 실행 시점을 확인할 수 있습니다.
확보 방법
관련 Quality Action 또는 CAPA 기록의 상태가 'Implemented' 또는 'Completed'로 바뀐 시점을 바탕으로 추론합니다.
기록
'Implemented' 또는 'Completed' 상태로 변경된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
예방 조치 식별
|
시스템 차원의 문제를 해결하고 유사한 품질 이벤트의 재발을 방지하기 위한 예방 조치(PA)를 생성하는 활동입니다. 원래 문제에 연결된 새 Preventive Action 기록을 생성하는 방식으로 기록하는 경우가 많습니다. | ||
|
중요한 이유
단일 문제 해결을 넘어 향후 문제를 예방하는 성숙한 품질 프로세스를 보여주는 활동입니다. 이를 추적하면 선제적인 품질 개선 수준을 측정할 수 있습니다.
확보 방법
유형이 'Preventive Action'인 새 Quality Action 기록이 생성될 때 수집합니다. 이 기록은 원래 Quality Issue 또는 Corrective Action에 연결되는 경우가 많습니다.
기록
'Preventive Action' 유형의 Quality Action 기록이 생성될 때 기록합니다.
이벤트 유형
explicit
|
|||
|
예방 조치 실행
|
시스템 차원의 위험을 줄이기 위해 예방 조치 계획에 정의된 작업이 완료되었음을 나타냅니다. 사용자가 예방 조치 기록의 상태를 'Implemented' 또는 'Completed'로 변경할 때 수집됩니다. | ||
|
중요한 이유
조직의 선제적 품질 개선 실행 역량을 측정합니다. 여기서 지연되면 조직 전반에 걸친 시스템 변경을 실행하는 데 어려움이 있음을 나타낼 수 있습니다.
확보 방법
관련 Preventive Action 기록의 상태가 'Implemented' 또는 'Completed'로 바뀔 때 추론합니다. 시정 조치 추적 방식과 유사합니다.
기록
Preventive Action 기록의 상태가 'Implemented'로 바뀐 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
이해관계자에게 해결 결과 통지
|
보고자나 영향을 받은 고객 등 관련 당사자에게 품질 이벤트의 해결 결과를 알리는 활동입니다. 기록하기 어려워 종결 후 상태 변경이나 기록된 의견을 바탕으로 추론할 수 있습니다. | ||
|
중요한 이유
'이해관계자 통지 지연 시간' KPI를 계산하는 데 중요합니다. 문제가 해결된 후에도 고객 만족과 내부 투명성을 위해 신속한 소통이 필요합니다.
확보 방법
자동으로 기록하기 어려운 경우가 많습니다. 'Notification Sent'와 같은 상태나 활동 또는 의견 필드의 기록을 바탕으로 추론할 수 있으며, 이를 추출하려면 별도의 로직이 필요할 수 있습니다.
기록
특정 상태 변경이나 활동 로그의 텍스트 분석을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
초기 검토 담당자에게 문제 배정
|
새로 생성된 품질 문제를 초기 검토와 평가를 위해 특정 사용자나 팀에 배정하는 활동입니다. 품질 문제 기록의 담당자 또는 소유자 필드 변경을 추적해 추론하는 경우가 많습니다. | ||
|
중요한 이유
초기 인계 과정을 추적하면 평가가 시작되기 전의 지연을 파악할 수 있습니다. 이 상태에 머문 시간을 분석하면 초기 분류 대기열의 적체 가능성을 확인할 수 있습니다.
확보 방법
Quality Issue 기록의 소유자 또는 담당자 필드 변경을 바탕으로 추론합니다. 감사 추적 테이블을 사용하거나 배정 워크플로와 관련된 상태 변경을 추적할 수 있습니다.
기록
Quality Issue의 'Assigned To' 또는 'Owner' 필드 변경을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
|
효과성 확인 필요
|
실행한 조치의 효과를 확인하기 위한 후속 검증이 필요하다고 시스템이나 사용자가 표시하는 활동입니다. 실행 후 자동 또는 수동으로 상태가 변경되는 경우가 많습니다. | ||
|
중요한 이유
이 단계에서 중요한 검증 절차가 시작됩니다. 조치 실행부터 이 활동까지 걸린 시간을 파악하면 필요한 후속 조치가 시작되기까지의 지연을 확인할 수 있습니다.
확보 방법
Quality Action의 상태가 'Pending Effectiveness Check' 또는 워크플로 내 이에 준하는 상태로 바뀔 때 추론합니다.
기록
'Pending Effectiveness Check' 상태로 변경된 시점을 바탕으로 추론합니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내서
시작할 준비가 되셨나요?
이 템플릿은 데이터를 빠르게 준비하고 품질 관리 프로세스 최적화를 시작할 수 있도록 설계되었습니다. 지금 효율성과 규정 준수를 높일 기회를 찾아보세요.
Oracle 품질 관리 개선으로 규정 준수 강화
비효율을 줄여 처리 시간을 30% 단축하세요.
신용카드가 필요하지 않습니다. 14일 무료 체험을 이용하세요.