보험금 청구 처리 데이터 템플릿
보험금 청구 처리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- Duck Creek Claims 데이터 추출 안내
보험금 청구 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| Claim ID ClaimId | 개별 보험금 청구 건을 식별하는 고유 ID로, 기본 케이스 식별자로 사용됩니다. | ||
| 설명 Claim ID는 보험금 청구 접수부터 종결까지 해당 청구 건과 관련된 모든 이벤트와 활동을 연결하는 기본 키입니다. 이를 통해 청구 처리 전 과정을 일관되게 추적할 수 있습니다. process mining 분석에서는 케이스 뷰를 구성하는 데 필요한 속성입니다. 분석가는 이를 사용해 각 청구 건의 전체 처리 경로를 추적하고, 처음부터 끝까지 걸리는 시간을 측정하며, 프로세스 변형을 분석할 수 있습니다. 중요한 이유 관련된 모든 이벤트를 연결하는 필수 Case ID입니다. 이를 통해 청구 처리 전 과정을 확인할 수 있습니다. 확보 방법 Duck Creek Claims의 기본 청구 엔터티 또는 테이블에서 기본 키로 사용됩니다. 구체적인 테이블과 필드 이름은 시스템 문서를 확인하세요. 예시 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| 이벤트 시각 EventTime | 특정 활동이나 이벤트가 발생한 시각을 나타내는 타임스탬프입니다. | ||
| 설명 이벤트 시각은 청구 처리 과정에서 기록된 각 활동의 날짜와 시간을 정확하게 나타냅니다. 시간에 따른 성과를 분석하는 데 중요한 정보입니다. 분석에서는 이 타임스탬프를 사용해 활동 간 처리 시간과 대기 시간을 계산하고, 전체 케이스 처리 기간을 측정하며, 기간별 프로세스 성과를 분석합니다. 시간 기반 프로세스 지표의 기본이 되는 데이터입니다. 중요한 이유 이 타임스탬프는 처리 시간과 기간 등 시간 기반 지표를 계산하는 데 필수적이며, 성과 분석과 병목 파악에 활용됩니다. 확보 방법 Duck Creek Claims의 이벤트 또는 트랜잭션 로그에 연결된 표준 타임스탬프 필드입니다. 'CreateDate', 'Timestamp', 'EventDate'와 같은 필드를 확인하세요. 예시 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 활동명 ActivityName | 특정 시점에 청구 건에서 발생한 업무 활동 또는 이벤트의 이름입니다. | ||
| 설명 이 속성은 '보험금 청구 접수', '손해사정 담당자 배정', '보험금 지급'과 같이 보험금 청구 프로세스에서 수행된 특정 단계나 작업을 나타냅니다. 각 활동은 청구 처리 과정의 개별 시점을 의미합니다. 활동의 순서와 빈도를 분석하는 것이 process mining의 기본입니다. 이를 통해 프로세스 모델을 발견하고, 병목과 재작업 루프를 파악하며, 표준 모델에서 벗어난 프로세스를 분석할 수 있습니다. 중요한 이유 활동명은 프로세스 흐름의 단계를 정의하며, 보험금 청구 프로세스를 발견하고 분석하고 모니터링하는 데 기본이 됩니다. 확보 방법 일반적으로 Duck Creek Claims의 이벤트 로그, 트랜잭션 이름 또는 상태 변경 기록에서 가져옵니다. 여러 원본 필드나 테이블의 값을 매핑해야 할 수 있습니다. 예시 보험금 청구 접수손해사정 담당자 배정조사 시작보험금 지급보험금 청구 종결 | |||
| 배정된 손해사정 담당자 AssignedAdjuster | 각 활동 시점에 청구 건을 담당하는 손해사정 담당자의 이름 또는 ID입니다. | ||
| 설명 이 속성은 활동을 수행하는 사용자 또는 리소스를 식별합니다. 청구 처리 과정에서 담당자나 팀이 바뀌면 값도 변경될 수 있습니다. 리소스별 성과와 업무량 배분, 인계 과정을 분석하는 데 필요합니다. 담당자별 처리량과 업무량 편차를 살펴보고 병목을 파악하는 대시보드에서는 업무가 개인별로 어떻게 배분되고 처리되는지 확인하기 위해 이 속성을 주로 활용합니다. 중요한 이유 리소스별 성과, 업무량 균형, 협업 패턴을 분석해 병목과 교육 필요성을 파악할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 확인하세요. 청구 작업, 이벤트 또는 기본 청구 엔터티와 관련된 테이블에서 사용자, 소유자 또는 담당자 필드를 찾으세요. 예시 John SmithJane DoeRobert Brownadjuster_1138 | |||
| 보험금 청구 상태 ClaimStatus | 특정 시점의 보험금 청구 상태입니다. 예를 들어 접수, 처리 대기, 종결 등이 있습니다. | ||
| 설명 보험금 청구 상태는 청구 건의 처리 과정에서 현재 상태를 나타냅니다. 전체 프로세스에서 청구 건이 어느 단계에 있는지 요약해 보여줍니다. 이 속성은 청구 건 전체를 개괄적으로 살펴보거나 사례를 필터링할 때 유용합니다. 특히 '종결 - 지급 완료', '종결 - 지급 거부'와 같은 최종 결과를 파악하는 데 중요하며, 결과 분석과 거부율 파악에 도움이 됩니다. 중요한 이유 청구 건의 현재 상태와 최종 결과를 보여주므로 결과 분석과 사례 필터링에 유용합니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 기본 청구 레코드에 포함되는 필수 필드입니다. 예시 접수처리 대기 - 정보 확인 중종결 - 합의 완료종결 - 지급 거부 | |||
| 부서 Department | 특정 시점에 활동이나 청구 건을 담당하는 부서 또는 팀입니다. | ||
| 설명 이 속성은 '초기 접수', '조사 부서', '합의 팀'과 같이 청구 건을 처리하는 기능별 그룹이나 부서를 나타냅니다. 프로세스 흐름을 조직 구조와 연결해 파악할 수 있습니다. 부서별 분석은 전체 수준에서 프로세스 성과를 이해하는 데 중요합니다. 부서 간 병목을 파악하고, 팀별 효율성을 측정하며, 조직 내 업무 흐름을 이해하는 데 도움이 됩니다. 중요한 이유 기능별 성과를 분석하고 부서 간 인계와 팀별 병목을 파악할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 확인하세요. 이 정보는 배정된 사용자의 프로필이나 대기열 또는 작업 그룹 배정 정보에 연결되는 경우가 많습니다. 예시 자동차 보험금 청구재산 보험금 청구, 대형 손해특별 조사 부서지급 처리 | |||
| 손실 금액 LossAmount | 청구 건에 보고된 손실의 추정 금액 또는 실제 금액입니다. | ||
| 설명 이 속성은 청구 건과 관련된 손실의 최초 추정 금액을 나타냅니다. 주요 재무 지표로, 청구 건의 배정 경로와 심각도, 필요한 조사 수준에 영향을 주는 경우가 많습니다. 분석 시 손실 금액을 기준으로 청구 건을 구분하고 재무적 영향과 프로세스 진행 방식의 관계를 파악할 수 있습니다. 예를 들어 금액이 큰 청구 건은 처리 경로가 다르거나 처리 시간이 더 길 수 있습니다. 이 속성은 운영 프로세스 데이터에 중요한 재무 맥락을 더합니다. 중요한 이유 청구 건의 재무적 맥락을 제공해 청구 금액이 처리 경로, 소요 시간, 결과에 미치는 영향을 분석할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 청구 건의 주요 재무 필드로, '보고된 손실액' 또는 '최초 준비금'으로 표시되는 경우가 많습니다. 예시 1500.0025000.50125000.00 | |||
| 청구 심각도 ClaimSeverity | 낮음, 보통, 높음 등 청구 건의 재정적 또는 운영상 복잡도를 분류한 값입니다. | ||
| 설명 청구 심각도는 예상되는 손해 규모나 청구 건의 복잡도를 나타냅니다. 최초 손해액 추정치, 사고 유형 또는 사전에 정한 업무 규칙을 기준으로 산정할 수 있습니다. 심각도가 높은 청구 건은 일반적으로 더 많은 단계와 긴 처리 시간, 전문 리소스가 필요하므로 성과 분석에 중요한 속성입니다. 심각도별 KPI를 구분하면 현실적인 성과 목표를 설정하고 복잡도가 프로세스 효율성과 결과에 미치는 영향을 파악할 수 있습니다. 중요한 이유 복잡도에 따라 청구 건을 구분해 처리 시간과 비용을 더 세밀하게 분석하고 현실적인 기준으로 비교할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 확인하세요. 전용 필드가 있거나 최초 손해 준비금 금액을 기준으로 산출할 수 있습니다. 예시 낮음중간높음재난 수준 | |||
| 청구 유형 ClaimType | 자동차, 재산 또는 배상 책임 등 보험금 청구의 유형입니다. | ||
| 설명 청구 유형은 보험 종목이나 손해의 성격에 따라 청구 건을 분류합니다. 청구 데이터를 구분하고 분석하는 기본 기준입니다. 이 속성을 사용하면 청구 유형별 프로세스 성과를 비교할 수 있습니다. 예를 들어 '자동차 보험, 전손' 청구는 '재산 보험, 침수 피해' 청구와 처리 절차가 다르고 KPI도 다릅니다. 청구 유형별 분석은 성과를 의미 있게 비교하고 유형에 맞는 프로세스 개선을 추진하는 데 필요한 맥락을 제공합니다. 중요한 이유 청구 유형마다 프로세스, SLA, 복잡도가 다를 수 있으므로 분석 결과를 구분하는 중요한 기준입니다. 확보 방법 Duck Creek Claims 문서를 확인하세요. 기본 청구 레코드에 포함된 주요 속성입니다. 예시 개인 자동차, 충돌상업용 재산, 화재산재 보상일반 배상 책임 | |||
| 목표일 내 처리 여부 IsOnTimeResolution | 청구 건이 처리 목표일까지 또는 그 전에 종결되었는지 나타내는 계산 플래그입니다. | ||
| 설명 이 불리언 속성은 '청구 종결' 활동의 타임스탬프와 해당 청구 건의 'ResolutionTargetDate'를 비교해 계산합니다. 청구 건별로 기한 내 처리(true) 또는 지연 처리(false) 여부를 표시합니다. 이 속성은 '기한 내 청구 처리율' KPI를 직접 지원합니다. 대시보드에서 SLA 준수율을 쉽게 집계하고 시각화할 수 있으며, 지연된 청구 건의 공통 특성(예: 특정 청구 유형, 부서, 프로세스 경로)을 찾아내는 상세 분석에도 활용할 수 있습니다. 중요한 이유 청구 건별 SLA 준수 여부를 직접 측정해 기한이 지난 청구 건을 필터링하고 원인을 분석할 수 있습니다. 확보 방법 원천 시스템의 필드가 아닙니다. 데이터 준비 과정에서 마지막 활동의 타임스탬프와 'ResolutionTargetDate' 필드를 비교해 계산합니다. 예시 truefalse | |||
| 보험증권 번호 PolicyNumber | 청구가 접수된 보험증권의 고유 식별자입니다. | ||
| 설명 이 속성은 청구 건을 해당 보험증권과 연결합니다. 청구 건과 관련된 보장 내용, 약관, 고객 정보를 확인할 수 있습니다. 프로세스 흐름 분석에 직접 사용하지 않는 경우도 있지만, 보험증권 번호를 활용하면 청구 데이터를 보강할 수 있습니다. 보험증권 및 고객 데이터와 결합해 고객군, 보험 유형, 가입 기간에 따라 프로세스 성과가 어떻게 달라지는지 분석하고, 사업 전반을 더 폭넓게 파악할 수 있습니다. 중요한 이유 청구 건을 고객 및 보험증권과 연결해 고객군이나 보험 유형별로 프로세스 성과가 미치는 영향을 폭넓게 분석할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 기본 청구 엔터티에 포함되는 표준 참조 필드입니다. 예시 PA-987654321CP-123456789WC-555444333 | |||
| 원천 시스템 SourceSystem | 이벤트 데이터를 추출한 시스템입니다. | ||
| 설명 이 속성은 청구 데이터가 생성된 원천 애플리케이션을 식별합니다. 이 경우 값은 항상 'Duck Creek Claims'입니다. 모든 데이터가 한 시스템에서 오면 중복 정보처럼 보일 수 있지만, 데이터 거버넌스와 추적성 확보에 중요합니다. 향후 여러 시스템의 데이터를 병합하는 경우에도 데이터의 출처와 구조를 확인할 수 있습니다. 중요한 이유 데이터 계보와 맥락을 제공하므로 데이터 거버넌스와 문제 해결에 중요합니다. 여러 시스템이 연동된 환경에서 특히 유용합니다. 확보 방법 일반적으로 데이터 추출 및 변환 과정에서 데이터의 출처를 표시하기 위해 추가하는 고정값입니다. 예시 Duck Creek Claims | |||
| 자동 처리 여부 IsAutomated | 사람의 개입 없이 시스템이 활동을 자동으로 수행했는지 나타내는 불리언 플래그입니다. | ||
| 설명 이 플래그를 사용하면 사용자 작업과 시스템 자동화를 구분할 수 있습니다. 자동 알림, 최초 데이터 검증, 자동 처리 단계 등이 시스템 자동화에 해당합니다. 이 속성을 분석하면 청구 프로세스의 자동화 수준을 파악할 수 있습니다. 자동화 도입의 효과를 측정하고 추가 자동화 기회를 찾으며, 자동 처리 단계가 후속 단계에 문제를 일으키지 않고 예상대로 작동하는지 확인하는 데 도움이 됩니다. 중요한 이유 자동화가 효율성과 비용에 미치는 영향을 측정하고, 사람의 개입 없이 처리할 수 있는 업무를 찾는 데 도움이 됩니다. 확보 방법 이 정보는 이벤트와 연결된 'user' 값(예: 'SYSTEM' 또는 'BATCH')이나 이벤트 레코드의 전용 플래그를 통해 추론할 수 있습니다. 예시 truefalse | |||
| 재작업 여부 IsRework | 활동이 재작업 루프에 포함되는지 나타내는 계산 플래그입니다. | ||
| 설명 다른 활동이 진행된 뒤 청구 건에서 활동이 반복되면 이 불리언 속성을 true로 설정합니다. 예를 들어 프로세스가 '손실 평가'에서 '조사 시작'으로 되돌아가는 경우입니다. 이 속성은 재작업을 정량화하고 분석하는 데 필요합니다. '청구 재작업률' KPI와 '청구 재작업 및 재처리 패턴' 대시보드에서 재작업이 발생한 활동과 사례를 직접 필터링하고 강조 표시할 수 있습니다. 이를 통해 프로세스의 비효율과 품질 문제를 파악할 수 있습니다. 중요한 이유 활동별 재작업을 수치화해 프로세스 비효율의 원인과 영향을 측정하고 시각화하며 분석할 수 있습니다. 확보 방법 원천 시스템의 필드가 아닙니다. 사례 내에서 반복되는 활동 순서를 감지하는 알고리즘을 사용해 데이터 준비 과정에서 계산합니다. 예시 truefalse | |||
| 종료 시간 EndTime | 활동이 완료된 시각을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 활동이 완료된 시각을 나타냅니다. StartTime이 활동 시작 시각을 나타낸다면 EndTime은 해당 작업의 소요 시간을 계산하는 데 필요한 종료 시각입니다. process mining에서는 활동의 시작 시각과 종료 시각을 모두 사용해 성과를 더 자세히 분석할 수 있습니다. 이를 통해 작업을 실제로 수행한 '처리 시간'과 작업 사이에 대기한 '대기 시간'을 정확히 계산할 수 있습니다. 두 시간을 구분해야 병목을 정확하게 파악할 수 있습니다. 중요한 이유 활동별 처리 시간을 정확히 계산하고 실제 작업 시간과 유휴·대기 시간을 구분할 수 있어 병목 분석의 정확도를 높입니다. 확보 방법 이벤트 로그에 별도의 타임스탬프 필드로 있을 수 있습니다. 없으면 같은 사례에서 다음 순서로 발생한 활동의 StartTime을 사용해 계산할 수 있습니다. 예시 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 지급 거부 사유 RejectionReason | 보험금 청구가 거부되거나 반려된 구체적인 사유입니다. | ||
| 설명 청구 건의 지급 거부가 결정되면 이 속성에 그 근거가 되는 사유를 기록합니다. 일반적으로 사전에 정의된 코드나 설명 중에서 선택합니다. 거부 사유 분석은 '청구 결정 및 거부 인사이트' 대시보드에 필수적입니다. 제출 서류의 반복적인 문제, 잠재적인 사기 유형, 약관 문구가 불명확한 부분을 파악하는 데 도움이 됩니다. 분석 결과를 바탕으로 접수 프로세스나 인수 심사 규칙을 개선할 수 있습니다. 중요한 이유 청구가 거부된 이유를 파악해 접수 프로세스 개선, 부적격 청구 감소, 교육이 필요한 영역 식별에 활용할 수 있습니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 일반적으로 청구 상태가 '지급 거부' 또는 이에 해당하는 상태로 변경될 때 이 필드에 값이 입력됩니다. 예시 보장 대상 사고가 아님보험 기간 만료중복 청구사기 의심 | |||
| 처리 목표일 ResolutionTargetDate | SLA 또는 내부 목표를 기준으로 청구 건의 처리가 완료될 것으로 예상되는 목표일입니다. | ||
| 설명 이 속성에는 청구 종결 기한이 저장됩니다. 기한은 규제 요건, 서비스 수준 계약(SLA), 내부 핵심성과지표(KPI)에 따라 정해지는 경우가 많으며, 청구 유형이나 심각도에 따라 달라질 수 있습니다. 이 날짜를 기준으로 '기한 내 청구 처리율' KPI를 계산하고 '청구 처리 목표 준수' 대시보드를 구성할 수 있습니다. SLA를 넘길 위험이 있는 청구 건을 미리 파악하고 업무 우선순위를 정하는 데 도움이 됩니다. 중요한 이유 서비스 수준 계약(SLA)과 내부 목표 대비 성과를 측정할 수 있습니다. 이는 고객 만족도와 규정 준수에 직접적인 영향을 줍니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 전용 SLA 날짜 필드일 수도 있고, 청구 접수일과 업무 규칙을 기준으로 계산할 수도 있습니다. 예시 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| 최종 데이터 업데이트 시각 LastDataUpdate | 원천 시스템에서 데이터를 가장 최근에 새로 고친 시각입니다. | ||
| 설명 이 속성은 데이터 세트가 마지막으로 업데이트된 시점을 나타내며, 분석 중인 데이터의 최신성을 확인하는 기준이 됩니다. 대시보드와 분석 화면에서 사용자에게 인사이트의 기준 시점을 알리는 데 사용됩니다. 최신 트랜잭션이 프로세스 뷰에 포함되었는지 판단하는 데도 도움이 됩니다. 중요한 이유 데이터의 최신성을 알려주므로 분석 결과를 해석하고 적시에 의사결정을 내리는 데 중요합니다. 확보 방법 이 타임스탬프는 데이터 추출, 변환 및 적재(ETL) 과정에서 생성되며, 일반적으로 데이터 세트의 메타데이터에 저장됩니다. 예시 2024-05-21T02:00:00Z | |||
| 합의 금액 SettlementAmount | 청구 건을 합의하기로 최종 결정한 금액입니다. | ||
| 설명 이 속성에는 산정 후 지급 승인을 받은 합의 금액이 기록됩니다. 지급이 이루어진 청구 건의 결과를 나타내는 주요 지표입니다. 재무 분석과 '지급 승인 및 지급까지 걸린 시간' 대시보드에 활용할 수 있습니다. 최초 '손실 금액'과 비교해 준비금 산정의 정확성을 분석할 수 있으며, 청구 프로세스의 재무적 결과를 파악하는 데도 중요합니다. 중요한 이유 청구 건의 주요 재무 결과를 나타내며, 재무 보고와 최초 손실 추정의 정확도 분석에 필요합니다. 확보 방법 Duck Creek Claims 문서를 참조하세요. 일반적으로 청구 건과 연결된 재무 거래 또는 지급 관련 테이블에 저장됩니다. 예시 1450.7522000.00115800.20 | |||
보험금 청구 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 보험금 지급 | 보험금 지급을 위한 재무 트랜잭션이 실행되는 활동입니다. 수표, EFT 또는 다른 방식으로 지급이 발송될 때 명시적 이벤트로 생성됩니다. | ||
| 중요한 이유 승인된 청구 건의 재정적 의무가 이행되는 시점을 나타냅니다. '지급 승인'부터 '보험금 지급'까지 걸리는 시간으로 재무 부서의 처리 효율성을 파악할 수 있습니다. 확보 방법 Duck Creek Claims의 재무 트랜잭션 테이블에서 확인할 수 있습니다. 이 테이블에는 각 지급이 특정 트랜잭션 코드와 시각으로 기록됩니다. 기록 지급 처리 시 개별 재무 트랜잭션 로그 항목이 생성됩니다. 이벤트 유형 explicit | |||
| 보험금 청구 거부 | 청구 건이 공식적으로 거부되어 프로세스가 종료되는 경우를 나타냅니다. 청구의 최종 상태가 'Denied' 또는 'Rejected'로 설정될 때 기록됩니다. | ||
| 중요한 이유 별도로 분석해야 하는 중요한 결과입니다. 청구가 거부된 이유와 시점을 파악하면 접수 절차를 개선하고 규정 준수를 관리하는 데 도움이 됩니다. 확보 방법 청구 엔터티 테이블에서 최종 상태가 'Denied', 'Rejected' 또는 'Closed without Payment'로 변경된 시점을 기준으로 추정합니다. 기록 청구의 최종 상태가 거부 사유로 설정된 시점을 기준으로 추정합니다. 이벤트 유형 inferred | |||
| 보험금 청구 결정 | '승인', '일부 승인', '거부'와 같은 청구 건의 공식 결정을 나타냅니다. 최종 결정 상태로 변경된 시점을 기준으로 추정하는 주요 단계입니다. | ||
| 중요한 이유 주요 의사결정 단계입니다. 이 단계까지 걸린 시간과 결정 결과는 프로세스 분석과 효율성 평가에 중요합니다. 확보 방법 전용 'Claim Decision' 또는 'Claim Status' 필드가 'Approved' 또는 'Denied'와 같은 최종 상태로 변경된 시점을 기준으로 추정합니다. 기록 청구의 기본 상태 또는 결정 필드가 업데이트된 시점을 기준으로 추정합니다. 이벤트 유형 inferred | |||
| 보험금 청구 접수 | 보험사가 최초 손해 통지(First Notice of Loss, FNOL)를 접수하는 첫 이벤트입니다. 보통 담당자나 보험 계약자가 시스템에 최초 청구 정보를 입력할 때 명시적인 트랜잭션으로 기록됩니다. | ||
| 중요한 이유 이 활동은 보험금 청구 처리 전 과정의 시작을 나타냅니다. 이 이벤트부터 다른 이벤트까지 걸리는 시간을 분석하면 전체 처리 기간과 접수 효율성을 파악할 수 있습니다. 확보 방법 Duck Creek Claims에서 새 청구 레코드가 처음 생성될 때 청구 또는 FNOL 로그 테이블에 명시적인 이벤트로 기록되는 경우가 많습니다. 기록 새 청구 레코드가 처음 생성될 때 기록되는 이벤트입니다. 이벤트 유형 explicit | |||
| 보험금 청구 종결 | 지급이 이루어지거나 청구 건이 합의된 후 청구 파일을 행정적으로 종결하는 마지막 활동입니다. 최종 상태가 'Closed'로 업데이트될 때 기록됩니다. | ||
| 중요한 이유 프로세스가 성공적으로 끝나는 시점을 나타냅니다. '보험금 청구 평균 전체 처리 시간'과 기타 주요 기간 지표를 계산할 때 종료 시점으로 사용됩니다. 확보 방법 청구의 기본 데이터 테이블에서 최종 상태가 'Closed' 또는 'Settled'로 변경된 시각을 기준으로 추정합니다. 기록 청구의 최종 상태가 'Closed'로 설정된 시점을 기준으로 추정합니다. 이벤트 유형 inferred | |||
| 지급 승인 | 산정된 합의금을 지급하도록 공식 승인하는 단계입니다. 관리자나 별도의 승인 권한자가 참여하는 독립 단계인 경우가 많으며, 명시적인 승인 트랜잭션으로 기록됩니다. | ||
| 중요한 이유 지급 전 주요 통제 지점이자 병목이 될 수 있는 단계입니다. '보험금 청구 결정'부터 이 단계까지 걸리는 시간은 '평균 보험금 청구 승인 시간' KPI로 측정합니다. 확보 방법 일반적으로 워크플로 또는 재무 모듈에서 특정 권한을 가진 사용자가 지급을 승인할 때 명시적 이벤트로 기록됩니다. 승인 로그에서 확인할 수 있습니다. 기록 워크플로 또는 트랜잭션 로그에 기록되는 명시적 승인 이벤트입니다. 이벤트 유형 explicit | |||
| 보험금 청구 등록 | 접수된 청구를 공식적으로 승인하고 등록하는 단계입니다. 이때 고유한 Claim ID가 부여됩니다. 초기 데이터 검증 후 시스템에서 자동으로 기록되는 경우가 많습니다. | ||
| 중요한 이유 이 단계에서 청구가 공식적으로 시작되고 손해사정 담당자 배정과 같은 후속 프로세스가 시작됩니다. 접수부터 등록까지 걸리는 시간은 초기 데이터 품질이나 시스템 부하 문제를 나타낼 수 있습니다. 확보 방법 기본 Claim ID가 생성되고 청구 상태가 'pending' 또는 'submitted'에서 'open' 또는 'registered'로 바뀐 시각을 기준으로 추정합니다. 해당 정보는 기본 청구 엔터티 테이블에서 확인할 수 있습니다. 기록 기본 청구 레코드의 생성 시각 또는 상태가 'Open'으로 변경된 시각을 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 손해사정 담당자 배정 | 등록된 청구 건에 손해사정 담당자 또는 처리 담당자를 배정하는 이벤트입니다. 시스템에 배정 내역이 기록되어 담당자가 변경되는 시점을 명확히 확인하고, 청구 건의 담당 주체를 파악할 수 있습니다. | ||
| 중요한 이유 리소스 배분과 담당자별 업무량을 분석하고 청구 건 배정 지연을 파악하는 데 중요합니다. 대기 시간이 발생할 수 있는 주요 인계 지점이기도 합니다. 확보 방법 기본 청구 데이터 테이블의 'Assigned Adjuster' 필드가 업데이트될 때 추적할 수 있습니다. 이 필드의 변경 이력이나 감사 로그에서 시각을 확인할 수 있습니다. 기록 담당자 필드가 입력되거나 변경될 때 감사 추적 로그에 기록됩니다. 이벤트 유형 explicit | |||
| 손해액 평가 | 조사 결과에 따라 지급 준비금을 설정하거나 조정하는 시점입니다. 청구 건의 재정적 영향을 추정하는 단계로, 준비금 금액을 입력하거나 조정할 때 기록됩니다. | ||
| 중요한 이유 프로세스의 주요 재무 확인 지점입니다. 이 단계가 언제 이루어지는지 분석하면 재무 평가의 속도와 정확성을 파악할 수 있습니다. 확보 방법 Duck Creek Claims의 청구 재무 트랜잭션 로그 또는 준비금 이력 테이블에 명시적인 재무 트랜잭션으로 기록되는 경우가 많습니다. 기록 청구 준비금을 설정하거나 조정할 때 기록되는 재무 트랜잭션입니다. 이벤트 유형 explicit | |||
| 조사 시작 | 보험금 청구의 공식 조사 단계가 시작되었음을 나타냅니다. 청구 상태가 'Under Investigation' 또는 이와 유사한 상태로 변경된 시점을 기준으로 추정하는 경우가 많습니다. | ||
| 중요한 이유 리소스가 많이 투입되는 단계의 시작을 나타냅니다. 조사 기간을 측정하면 '평균 조사 기간' KPI를 계산하고 프로세스의 주요 단계를 관리하는 데 도움이 됩니다. 확보 방법 기본 청구 상태 필드가 'Investigation in Progress' 또는 'Pending Inspection'으로 변경된 시각을 기준으로 추정합니다. 기록 조사 활동의 시작을 나타내는 청구 상태 변경을 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 조사 완료 | 필요한 사실을 모두 수집해 조사 활동을 마친 시점을 나타냅니다. 보통 청구 상태가 'Under Investigation'에서 'Pending Decision'과 같은 의사결정 상태로 바뀌는 시점을 기준으로 추정합니다. | ||
| 중요한 이유 조사가 완료되면 의사결정과 합의 단계가 진행될 수 있습니다. 이 단계의 지연은 후속 단계에 큰 영향을 줍니다. 확보 방법 청구 상태가 'investigation'에서 'review' 또는 'decision' 상태로 변경된 시각을 기준으로 추정합니다. 기록 조사 활동의 종료를 나타내는 청구 상태 변경을 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 초기 검토 완료 | 배정된 손해사정 담당자가 청구 건에 대한 첫 종합 검토를 마친 시점을 나타냅니다. 보통 배정 후 청구 상태가 'Assigned'에서 'Under Review' 또는 'Investigation'으로 바뀌는 등의 변화를 기준으로 추정합니다. | ||
| 중요한 이유 이 단계는 담당자가 첫 조치를 취하기까지 걸리는 시간을 측정하고 업무 적체 가능성을 파악하는 데 도움이 됩니다. 사람이 직접 처리하는 첫 주요 확인 지점입니다. 확보 방법 청구 상태 필드가 'Initial Review Complete' 또는 'Pending Information' 등으로 변경된 시점을 기준으로 추정합니다. 기록 담당자 배정 후 청구 상태 필드가 변경된 시점을 기준으로 추정합니다. 이벤트 유형 inferred | |||
| 추가 정보 요청 | 손해사정 담당자가 추가 정보가 필요하다고 판단해 보험 계약자나 제3자에게 요청을 보내면 발생하는 활동입니다. 시스템의 커뮤니케이션 또는 서신 모듈에 연결된 명시적 이벤트로 기록되는 경우가 많습니다. | ||
| 중요한 이유 이 활동이 자주 발생하면 초기 데이터 수집 과정에 문제가 있을 수 있습니다. 또한 대기 시간이 늘어나 전체 처리 시간에 영향을 줍니다. 확보 방법 발신 커뮤니케이션 로그(예: 서신, 이메일) 또는 Duck Creek Claims의 'Request for Information' 트랜잭션에서 확인할 수 있습니다. 기록 정보 요청 서신이나 작업이 생성될 때 기록됩니다. 이벤트 유형 explicit | |||
| 추가 정보 접수 | 요청한 정보를 접수해 보험금 청구 처리를 재개할 수 있는 시점을 나타냅니다. 담당자가 직접 기록하거나, 디지털 포털로 정보가 제출되면 자동으로 기록될 수 있습니다. | ||
| 중요한 이유 'Information Requested'부터 'Information Received'까지의 시간은 중요한 대기 구간입니다. 이 기간을 분석하면 외부 의존성과 커뮤니케이션 병목을 파악할 수 있습니다. 확보 방법 문서 관리 시스템 연동에서 명시적 이벤트를 가져오거나, 담당자가 문서를 받은 뒤 직접 로그를 입력하거나 상태를 변경해 기록할 수 있습니다. 기록 문서 업로드 또는 담당자의 수동 입력 시 기록되는 이벤트입니다. 이벤트 유형 explicit | |||
| 합의금 산정 | 승인 결정 후 최종 합의금 또는 지급액을 산정하는 활동입니다. 명시적인 단계로 기록되거나 시스템 재무 모듈에서 지급액이 확정된 시점을 기준으로 추정할 수 있습니다. | ||
| 중요한 이유 이 활동은 '합의금 재작업률' KPI를 측정하는 데 중요합니다. 한 청구 건에서 이 이벤트가 여러 번 발생하면 합의 단계의 비효율, 오류 또는 협상 과정을 나타낼 수 있습니다. 확보 방법 트랜잭션 로그에 명시적으로 기록되거나 청구 재무 데이터의 'Settlement Amount' 필드 변경을 기준으로 추정할 수 있습니다. 이 필드의 감사 로그가 주요 데이터 출처입니다. 기록 최종 지급액을 산정해 저장할 때 기록되는 이벤트입니다. 이벤트 유형 explicit | |||
데이터 추출 안내
단계
- Duck Creek Data Hub Configuration Utility에 접속: Duck Creek 환경에 로그인한 뒤 Data Hub 애플리케이션으로 이동합니다. 데이터 내보내기 설정을 만들거나 수정할 수 있는 권한이 필요합니다.
- 새 데이터 내보내기 작업 만들기: Data Hub 유틸리티에서 새 내보내기 작업을 시작합니다. ProcessMind_Claims_Event_Log_Export와 같이 용도를 알 수 있는 이름을 지정합니다.
- 데이터 소스 정의: 기본 Data Hub SQL 데이터베이스에 연결하도록 작업을 설정합니다. 관련 스키마에 대한 읽기 권한이 있는 사용자의 서버 이름, 데이터베이스 이름, 인증 정보를 입력해야 합니다.
- 추출 쿼리 입력: 내보내기 작업의 쿼리 정의 섹션으로 이동합니다. 아래 쿼리 섹션의 전체 스크립트를 복사해 쿼리 편집기에 붙여 넣습니다.
- 쿼리 매개변수 설정: 설정에서 매개변수 섹션을 찾아 쿼리에 사용된 @StartDate 및 @EndDate 매개변수의 값을 지정해 추출 기간을 설정합니다. 예를 들어 '2023-01-01'과 '2023-12-31'을 입력합니다.
- 출력 열 매핑: 출력 파일 설정을 구성합니다. SELECT 문에 정의된 열(ClaimId, ActivityName, EventTime 등)이 출력 파일의 열에 올바르게 매핑되었는지 확인합니다. 출력 파일의 머리글은 해당 이름과 정확히 일치해야 합니다.
- 출력 파일 설정: 출력 형식을 CSV로 지정합니다. ProcessMind와 호환되도록 구분 기호는 쉼표(,), 문자 인코딩은 UTF-8로 설정합니다.
- 저장 위치 지정: 생성된 CSV 파일을 저장할 파일 경로나 네트워크 위치를 지정합니다. 시스템에 해당 위치의 쓰기 권한이 있는지 확인합니다.
- 내보내기 작업 예약: 작업 일정을 설정합니다. 초기 분석에서는 수동으로 실행할 수 있습니다. 지속적으로 모니터링하려면 매일 또는 매주와 같이 반복 일정을 설정합니다.
- 작업 실행 및 파일 가져오기: 작업을 실행해 이벤트 로그 파일을 생성합니다. 완료되면 8단계에서 지정한 위치에서 CSV 파일을 가져옵니다.
- 업로드 준비: ProcessMind에 업로드하기 전에 CSV 파일을 열어 최종 점검합니다. 머리글이 올바른지, 날짜 형식이 일관적인지(YYYY-MM-DD HH:MI:SS), 데이터가 예상대로 표시되는지 확인합니다.
구성
- 사전 요구 사항: Duck Creek Data Hub 모듈에 액세스할 수 있어야 합니다. 내보내기 작업을 실행하는 사용자 또는 서비스 계정에는 Data Hub의 기본 데이터베이스 테이블(예: [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory])에 대한 읽기 권한이 있어야 합니다.
- 기간 설정: 쿼리는 @StartDate 및 @EndDate 매개변수를 사용합니다. 추출 기간을 지정하려면 이 값을 반드시 설정해야 합니다. 첫 분석에서는 완료된 사례와 진행 중인 사례를 충분히 포함할 수 있도록 6~12개월을 권장합니다.
- 필터링: 쿼리의 공통 테이블 식(CTE)에는 /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ 자리표시자가 있습니다. 특정 사업 부문(예: 'Personal Auto', 'Commercial Property')만 분석하려면 이 줄의 주석을 해제하고 수정해 데이터 양을 줄이세요.
- Data Hub 갱신 주기: Data Hub의 데이터 반영 지연을 고려하세요. 데이터는 실시간으로 갱신되지 않으며, 일반적으로 야간 등 정해진 일정에 따라 새로 고쳐집니다. 추출 데이터는 마지막으로 성공한 Data Hub 갱신 시점의 데이터입니다.
- 출력 형식: 내보내기 작업은 CSV와 같은 평면 파일을 생성하도록 구성해야 합니다. 데이터 필드 안의 쉼표를 처리할 수 있도록 텍스트 한정자를 큰따옴표(")로 설정하세요.
샘플 쿼리 sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; 시작할 준비가 되셨나요?
이 템플릿을 활용하면 보험금 청구 처리 최적화에 필요한 준비를 시작할 수 있습니다. 지금 데이터 분석을 시작해 유용한 인사이트를 찾아보세요.
보험금 청구 적체 해소: 지금 청구 처리 프로세스를 최적화하세요
자동 처리율 70%를 달성해 비용과 지연을 줄이세요.
14일 무료 체험을 이용해 보세요. 신용카드가 필요하지 않습니다.