Incident 관리 데이터 템플릿

ServiceNow 문제 관리
Incident 관리 데이터 템플릿

Incident 관리 데이터 템플릿

이 템플릿은 incident 관리 프로세스를 분석하고 최적화하는 데 필요한 데이터를 수집하는 방법을 안내합니다. 수집할 주요 데이터 속성과 추적할 활동을 정리하고, 원본 시스템에서 정보를 추출하는 방법도 설명합니다. 이 자료를 활용해 심층적인 프로세스 분석과 개선에 필요한 이벤트 로그를 구성하세요.
  • 수집 권장 속성
  • 추적할 주요 활동
  • ServiceNow Problem Management 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

Incident 관리 속성

Incident 관리 프로세스를 빠짐없이 분석하려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
5 필수 4 권장 10 선택 사항
이름 설명
이벤트 시각
EventTime
활동이 발생한 시점을 나타내는 정확한 타임스탬프입니다.
설명

이벤트 시각은 타임스탬프라고도 하며, 활동이 완료되거나 상태가 변경된 정확한 날짜와 시간을 기록합니다. ServiceNow에서는 감사 기록에 저장된 각 변경 사항의 sys_updated_on 필드에 기록되는 경우가 많습니다.

이 속성은 이벤트 순서를 올바르게 정하고 시간 기반 분석을 수행하는 데 필요합니다. 처리 시간, 대기 시간, 활동 간 소요 시간을 계산해 병목을 찾고 SLA 기준 성과를 측정하며 프로세스 효율을 파악하는 데 사용합니다. 시간 기반 지표의 신뢰성을 확보하려면 타임스탬프가 정확해야 합니다.

중요한 이유

이 타임스탬프를 기준으로 모든 활동을 시간순으로 정렬하고 처리 시간과 병목 등 시간 기반 지표를 계산할 수 있습니다.

확보 방법

ServiceNow sys_audit 테이블의 sys_created_on 필드 또는 마지막 상태에 해당하는 incident 테이블의 sys_updated_on 필드입니다.

예시
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
인시던트 ID
IncidentId
각 인시던트 레코드를 식별하는 고유 ID로, 전체 수명 주기를 추적하는 기본 키입니다.
설명

인시던트 ID는 ServiceNow에 보고된 각 인시던트에 부여되는 고유 참조 번호입니다. 인시던트가 생성된 순간부터 종료될 때까지 관련 활동, 업데이트, 소통 내역을 연결하는 기준이 됩니다.

process mining 분석에서 이 ID는 필수입니다. 각 케이스의 이벤트 순서를 연결해 프로세스 맵을 발견하고, 변형을 분석하며, 전체 처리 시간을 계산할 수 있습니다. 케이스마다 고유한 인시던트 ID가 없으면 해결 과정에서 인시던트가 거친 경로를 추적할 수 없습니다.

중요한 이유

인시던트 수명 주기의 모든 이벤트를 연결하는 필수 케이스 ID로, 처음부터 끝까지 프로세스를 분석할 수 있게 합니다.

확보 방법

ServiceNow 인시던트 테이블의 number 필드입니다.

예시
INC0010001INC0010045INC0010239
활동 이름
ActivityName
인시던트 수명 주기에서 특정 시점에 발생한 이벤트나 작업의 이름입니다.
설명

활동 이름은 'Incident Created', 'Assigned To Agent', 'Incident Closed'처럼 인시던트 관리 프로세스의 특정 단계나 상태 변경을 나타냅니다. 일반적으로 'State'나 'Assignment Group'과 같은 주요 인시던트 필드의 변경 또는 특정 로그 항목을 바탕으로 생성합니다.

이 속성은 프로세스 맵을 구성하는 데 중요합니다. 프로세스 그래프의 노드를 정의해 분석가가 인시던트 흐름을 시각화하고, 일반적인 경로를 파악하며, 활동 간 병목과 프로세스 변형을 분석할 수 있게 합니다. 활동 이름의 세분화 수준과 정확도는 프로세스 분석의 품질에 직접 영향을 줍니다.

중요한 이유

프로세스 맵의 단계를 정의하며, 모든 process mining 분석과 시각화의 기반이 됩니다.

확보 방법

파생 속성으로, 일반적으로 sys_audit 또는 incident 테이블의 state, assignment_group, assigned_to 필드 변경을 바탕으로 데이터 변환 로직에서 생성합니다.

예시
인시던트 생성배정 그룹 변경해결안 제시인시던트 종료
소스 시스템
SourceSystem
데이터를 추출한 시스템입니다.
설명

이 속성은 인시던트 데이터의 출처를 나타내며, 여기서는 ServiceNow Problem Management입니다. 일반적으로 데이터 추출 및 변환 과정에서 고정값으로 추가합니다.

여러 시스템의 데이터를 함께 분석하는 환경에서는 데이터 계보를 추적하고 데이터를 구분하는 데 이 필드가 중요합니다. 지표와 프로세스를 올바른 맥락에서 분석하고, 소스 시스템별 프로세스를 비교할 수 있습니다.

중요한 이유

데이터 출처에 관한 맥락을 제공해 데이터 계보를 추적하고 여러 시스템 환경에서 데이터를 올바르게 해석할 수 있게 합니다.

확보 방법

일반적으로 데이터 추출 과정에서 고정값으로 추가합니다.

예시
ServiceNow 문제 관리ServiceNow
최근 데이터 업데이트
LastDataUpdate
소스 시스템에서 이 레코드의 데이터를 마지막으로 새로 고친 시각입니다.
설명

이 속성은 ServiceNow에서 데이터를 마지막으로 추출하거나 업데이트한 날짜와 시간을 기록합니다. 프로세스 이벤트가 아니라 분석 대상 데이터의 최신 상태를 나타내는 메타데이터 필드입니다.

분석 정보가 얼마나 최신인지 파악하는 데 중요합니다. 사용자는 데이터의 최신 시점을 확인할 수 있으며, 이는 운영 대시보드와 최근 이벤트를 바탕으로 한 의사결정에 필요합니다. 데이터의 관련성과 최신성에 대한 기대치를 관리하는 데도 도움이 됩니다.

중요한 이유

데이터의 최신 상태를 알려주므로 분석의 관련성과 정확성을 판단하는 데 중요합니다.

확보 방법

데이터를 불러올 때 데이터 추출 도구나 프로세스가 이 타임스탬프를 생성하고 입력합니다.

예시
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
담당자
AssignedTo
현재 인시던트 처리를 맡은 사용자 또는 담당자입니다.
설명

이 속성은 특정 시점에 인시던트를 담당하는 지원 담당자를 식별합니다. 업무량 분배, 담당자별 성과, 개인 간 인계를 파악하는 데 중요합니다.

분석 시 '담당자' 정보를 활용하면 리소스 배분을 시각화하고 업무가 과중한 담당자를 찾을 수 있습니다. 인계 및 재배정 대시보드에서는 인시던트의 담당자가 바뀐 횟수를 추적하는 데도 사용합니다. 담당자별 해결 시간을 분석하면 성과가 높은 담당자나 추가 교육이 필요한 담당자를 파악할 수 있습니다.

중요한 이유

담당자별 업무량과 성과, 개인 간 인계를 분석해 리소스 운영 효율을 파악할 수 있습니다.

확보 방법

ServiceNow incident 테이블의 assigned_to 필드입니다.

예시
Beth AnglinDavid LooHoward Johnson
배정 그룹
AssignmentGroup
인시던트 처리를 담당하는 지원팀 또는 그룹입니다.
설명

배정 그룹은 인시던트 해결을 맡은 담당자 팀을 나타냅니다. 예를 들어 인시던트가 1차 헬프 데스크에서 전문 2차 네트워크 팀으로 이관될 수 있습니다.

이 속성은 팀 간 인계를 분석하고 시스템 차원의 병목을 찾는 데 중요합니다. '인계 및 재배정률' 대시보드는 이 데이터를 바탕으로 이관에 자주 관여하는 팀을 보여줍니다. 지원 그룹별 성과를 비교하고 조직 내에서 해결 전문성이 어디에 있는지도 파악할 수 있습니다.

중요한 이유

담당 팀을 추적해 팀별 성과와 업무량, 그룹 간 인계를 분석할 수 있습니다.

확보 방법

ServiceNow incident 테이블의 assignment_group 필드입니다.

예시
서비스 데스크네트워크 지원데이터베이스 관리자
우선순위
Priority
대응의 긴급도를 결정하는 인시던트 우선순위입니다.
설명

우선순위는 ServiceNow의 주요 필드로, 인시던트 처리 순서와 속도를 결정합니다. 일반적으로 인시던트의 영향도와 긴급도를 기준으로 정하며 SLA 목표에 직접 영향을 줍니다.

이 속성은 구간별 분석과 성과 분석의 기반입니다. 'SLA 준수 현황' 대시보드에서는 우선순위를 기준으로 우선순위가 높은 인시던트가 목표 시간 내에 해결되는지 확인합니다. 우선순위별 처리 시간을 분석하면 중대 인시던트가 덜 중요한 인시던트보다 실제로 빠르게 처리되는지 검증할 수 있습니다. 거의 모든 KPI와 대시보드에서 중요한 분석 기준입니다.

중요한 이유

업무상 중요도에 따라 인시던트를 구분할 수 있어 SLA 준수 모니터링과 리소스 배분에 중요합니다.

확보 방법

ServiceNow incident 테이블의 priority 필드입니다.

예시
1 - 긴급2 - 높음3 - 보통4 - 낮음
인시던트 상태
IncidentState
수명 주기에서 인시던트의 현재 상태입니다.
설명

인시던트 상태는 'New', 'In Progress', 'On Hold', 'Resolved'와 같이 인시던트가 현재 어느 단계에 있는지 나타냅니다. process mining에서는 상태 변경을 기준으로 이벤트 로그의 활동을 생성하는 경우가 많습니다.

각 상태에 머문 시간을 분석하면 병목을 찾을 수 있습니다. 예를 들어 'On Hold' 상태가 오래 지속되면 외부 요인이나 사용자에 대한 의존성이 있을 수 있습니다. 상태 변경 순서는 프로세스 맵의 기반이 되어 인시던트가 해결에 이르는 과정을 보여줍니다.

중요한 이유

인시던트 진행 상황을 추적하며, 단계별 소요 시간과 프로세스 병목을 분석하는 데 중요합니다.

확보 방법

ServiceNow incident 테이블의 incident_state 또는 state 필드입니다.

예시
신규진행 중사용자 정보 대기해결됨종료됨
Problem ID
ProblemId
Incident가 더 큰 문제와 연결된 경우, 연결된 Problem 레코드의 식별자입니다.
설명

Problem ID는 incident를 Problem Management 모듈의 해당 레코드와 연결합니다. 여러 사용자나 서비스에 영향을 주는 더 큰 근본 문제의 증상으로 incident가 확인되면 이 연결을 설정합니다.

이 연결 정보는 '반복 incident 건수' 대시보드와 '반복 incident 비율' KPI에 중요합니다. 분석가는 이를 바탕으로 같은 근본 원인에서 비롯된 incident를 묶고, 문제의 전체 영향을 측정하며, 문제 해결의 효과를 추적할 수 있습니다. Problem과 연결된 incident가 많다면 지원 조직이 사후 대응에 치우쳐 있음을 나타낼 수 있습니다.

중요한 이유

Incident를 근본 원인과 연결하므로 반복 문제를 분석하고 Problem Management의 효과를 측정하는 데 필요합니다.

확보 방법

ServiceNow incident 테이블의 problem_id 필드입니다.

예시
PRB0040001PRB0040015PRB0040102
SLA 기한
SlaDueDate
SLA에 따라 incident를 해결해야 하는 목표 날짜와 시간입니다.
설명

SLA 기한은 incident의 해결 마감 시점을 나타내는 계산된 타임스탬프입니다. 우선순위 등 incident의 특성에 따라 적용되는 서비스 수준 계약(SLA)을 기준으로 정해집니다.

이 속성은 'SLA 준수 현황' 대시보드와 '중요 incident SLA 위반율' KPI에 필요합니다. 실제 해결 시간과 비교하는 기준으로 사용됩니다. SLA 기한이 임박한 incident를 분석하면 선제적으로 에스컬레이션하고 우선순위를 조정하는 데 도움이 됩니다.

중요한 이유

해결 목표 시점을 정해 SLA 준수 여부를 측정하고 목표를 지키지 못할 위험이 있는 incident를 찾을 수 있습니다.

확보 방법

일반적으로 incident 테이블과 연결된 task_sla 테이블에서 확인할 수 있습니다. 해당 타임스탬프 필드는 planned_end_time입니다.

예시
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
SLA 위반 여부
IsSlaBreached
Incident 해결이 SLA 기한을 넘겼는지 나타내는 플래그입니다.
설명

서비스 수준 계약(SLA) 위반 여부를 표시하는 계산된 불리언 속성입니다. 실제 해결 시각을 'SLA 기한'과 비교해 산출합니다. 해결 시각이 기한보다 늦으면 true로 설정됩니다.

이 속성은 'SLA 준수 현황' 대시보드와 관련 KPI의 기반이 됩니다. 복잡한 시간 비교 결과를 true 또는 false로 나타내므로, SLA를 위반한 incident를 쉽게 필터링하고 범주, 할당 그룹, 우선순위 등 공통 특성을 분석할 수 있습니다.

중요한 이유

SLA 준수 분석을 간소화해 목표를 지키지 못한 incident를 쉽게 필터링하고 자세히 분석할 수 있습니다.

확보 방법

'Resolved At' 타임스탬프와 'SlaDueDate' 타임스탬프를 비교해 계산합니다. (Resolved At > SlaDueDate).

예시
truefalse
구성 항목
ConfigurationItem
Incident의 영향을 받은 특정 IT 구성 요소, 서비스 또는 자산입니다.
설명

구성 항목(Configuration Item, CI)은 Configuration Management Database(CMDB)에 등록된 자산 중 incident의 영향을 받은 항목입니다. 서버, 애플리케이션, 노트북 또는 네트워크 장비가 여기에 해당할 수 있습니다.

CI별로 incident를 분석하면 신뢰성이 낮은 자산이나 서비스를 찾는 데 도움이 됩니다. IT 인프라의 어느 부분에서 incident가 많이 발생하는지 파악해 업그레이드나 교체 투자를 결정할 수 있습니다. process mining에서 CI를 기준으로 필터링하면 중요 애플리케이션 관련 incident가 다른 incident와 다르게 또는 더 효율적으로 처리되는지 확인할 수 있습니다.

중요한 이유

영향을 받은 자산을 식별해 IT 인프라의 문제 구성 요소를 찾고 개선 활동의 범위를 좁힐 수 있습니다.

확보 방법

ServiceNow incident 테이블의 cmdb_ci 필드입니다.

예시
SAP ERP 운영 환경Oracle DB Server 05이메일 서비스
범주
Category
하드웨어, 소프트웨어, 네트워크 등 인시던트의 상위 분류입니다.
설명

범주는 인시던트의 성격을 큰 범위에서 분류합니다. 하위 범주와 함께 사용하면 인시던트를 적절한 지원팀에 라우팅하고 보고서 작성 및 추세 분석에 활용할 수 있습니다.

process mining에서는 '인시던트 분류 정확도'와 '반복 인시던트 건수' 대시보드에 이 속성이 중요합니다. 처리 중 범주가 변경된 인시던트를 분석하면 초기 분류 과정의 문제를 찾을 수 있습니다. 범주별로 프로세스 맵을 필터링하면 특정 유형의 인시던트가 다른 해결 경로를 따르거나 고유한 병목을 겪는지도 확인할 수 있습니다.

중요한 이유

인시던트 유형을 분석하고 분류 정확도를 측정하며 라우팅과 추세 분석에 활용할 수 있습니다.

확보 방법

ServiceNow incident 테이블의 category 필드입니다.

예시
하드웨어소프트웨어네트워크데이터베이스
신고자
CallerId
Incident를 처음 신고한 사용자입니다.
설명

신고자는 incident의 영향을 받고 이를 신고한 최종 사용자 또는 고객을 나타냅니다. 이 정보로 서비스 중단의 영향을 받는 대상을 파악할 수 있습니다.

신고자가 항상 프로세스 흐름의 중심인 것은 아니지만, 신고자별 incident를 분석하면 특정 개인이나 부서가 문제의 영향을 유독 많이 받는지 확인할 수 있습니다. 이를 통해 교육이 필요하거나 특정 환경에 문제가 있는지 파악할 수 있습니다. 또한 만족도 조사와 안내를 위해 고객과 직접 연결하는 데도 활용됩니다.

중요한 이유

영향을 받은 사용자를 식별해 부서별 또는 개인별 분석을 수행하고 사용자 안내에 필요한 맥락을 파악할 수 있습니다.

확보 방법

ServiceNow incident 테이블의 caller_id 필드입니다.

예시
Abel TuterCarolina PashDon Goodliffe
심각도
Severity
Incident가 비즈니스에 미친 영향의 수준입니다.
설명

심각도는 incident가 비즈니스 운영에 미치는 영향의 크기를 나타냅니다. 긴급도와 함께 incident 우선순위를 자동으로 산정하는 데 자주 사용됩니다.

분석에서는 'SLA 준수 현황' 대시보드의 주요 기준으로 활용됩니다. 조직은 이를 통해 업무 중단이 큰 incident에 대해 서비스 수준을 지키고 있는지 확인할 수 있습니다. 우선순위가 운영 관점의 성과를 보여 준다면, 심각도는 비즈니스 관점에서 성과를 살펴보게 합니다.

중요한 이유

Incident가 비즈니스에 미친 영향을 측정하므로 대응 우선순위를 정하고 중요 문제의 처리 성과를 분석하는 기준이 됩니다.

확보 방법

ServiceNow incident 테이블의 severity 필드입니다.

예시
1 - 높음2 - 보통3 - 낮음
재개 여부
IsReopened
해결된 뒤 incident가 다시 열렸는지 나타내는 플래그입니다.
설명

Incident가 'Resolved' 또는 'Closed' 상태에 도달한 뒤 상태가 다시 활성 상태(예: 'In Progress')로 바뀌면 이 불리언 플래그가 true로 설정됩니다. 일반적으로 이벤트 로그에서 'Incident Reopened' 활동을 찾아 확인합니다.

재개된 incident는 해결이 불완전하거나 효과적이지 않았음을 보여 주는 강한 신호입니다. 이러한 사례를 분석하면 성급하게 종료했거나 처음에 제대로 해결하지 못해 문제가 반복된 경우를 찾을 수 있습니다. 재개율이 높으면 사용자 만족도와 팀 생산성이 낮아질 수 있으므로 품질 관리의 주요 지표로 활용됩니다.

중요한 이유

해결 과정의 문제를 파악해 해결된 것으로 처리한 뒤 추가 작업이 필요했던 incident를 보여 줍니다.

확보 방법

각 incident의 활동 순서를 확인해 'resolved' 상태 뒤에 'open' 상태가 나타나는지 판별합니다.

예시
truefalse
재할당 횟수
ReassignmentCount
Incident가 다른 그룹이나 담당자에게 재할당된 횟수입니다.
설명

이 필드는 incident가 서로 다른 할당 그룹 간에 이관된 총횟수를 기록합니다. 프로세스의 마찰을 직접 보여 주는 지표로, 주요 성과 지표로 자주 사용됩니다.

'인계 및 재할당 비율' 대시보드와 'incident당 평균 인계 횟수' KPI를 산출하는 주요 데이터입니다. 재할당 횟수가 많으면 최초 배정이 부정확하거나, 지원 단계별 역량이 부족하거나, 프로세스 책임이 불분명할 수 있습니다. 재할당을 줄이면 일반적으로 해결 시간이 단축되므로 프로세스 개선 활동의 목표로 삼는 경우가 많습니다.

중요한 이유

프로세스 인계 횟수를 직접 측정합니다. 이는 비효율, 부정확한 배정, 개선 기회를 파악하는 주요 지표입니다.

확보 방법

ServiceNow incident 테이블의 reassignment_count 필드입니다.

예시
0135
해결 코드
ResolutionCode
인시던트를 최종적으로 어떤 방식으로 해결했는지 나타내는 코드입니다.
설명

해결 코드는 적용한 해결책의 유형을 나타냅니다. 예를 들어 사용자가 직접 해결했는지, 알려진 오류를 수정했는지, 임시 해결책을 제공했는지를 구분합니다. 일반적으로 담당자가 인시던트를 종료할 때 이 필드를 입력합니다.

이 속성은 '해결 유형별 효과' 대시보드에 직접 활용됩니다. 영구적인 해결책과 임시 해결책으로 종료된 인시던트 수를 비교할 수 있으며, 이는 서비스 품질과 장기적인 안정성을 보여주는 지표입니다. 임시 해결책의 비율이 높으면 근본 문제가 충분히 해결되지 않고 있을 수 있습니다.

중요한 이유

해결 방식을 구분해 영구적인 해결책과 임시 해결책을 분석하고 근본 원인을 파악하는 데 활용할 수 있습니다.

확보 방법

ServiceNow incident 테이블의 close_code 필드 또는 사용자 지정 해결 코드 필드입니다.

예시
해결됨(임시 조치)해결됨(영구 조치)미해결(사용자 취소)알려진 오류
필수 권장 선택 사항

Incident 관리 활동

정확한 프로세스 탐색과 최적화를 위해 이벤트 로그에 기록해야 할 주요 프로세스 단계와 이정표입니다.
6 권장 7 선택 사항
활동 설명
배정 그룹 변경
인시던트가 한 지원 그룹에서 다른 그룹으로 넘어가는 인계를 나타냅니다. 최초 입력 이후 'assignment_group' 필드가 다시 변경된 시점을 확인해 기록합니다.
중요한 이유

잦은 재배정은 최초 라우팅 오류, 복잡한 프로세스 또는 지식 부족을 나타낼 수 있습니다. 이 활동은 '인시던트당 평균 인계 횟수' KPI를 측정하는 데 중요합니다.

확보 방법

최초 배정 이후 'assignment_group' 필드가 변경된 내역을 'sys_audit' 테이블에서 추적해 추론합니다.

기록

감사 로그에서 'assignment_group' 필드가 변경된 시각을 모두 확인합니다.

이벤트 유형 inferred
업무 시작
담당자가 인시던트를 조사하거나 처리하기 시작했음을 나타냅니다. 일반적으로 인시던트 상태가 'New' 또는 'Assigned'에서 'In Progress'와 같은 진행 중 상태로 바뀐 시점을 기준으로 추론합니다.
중요한 이유

이 시점부터 초기 대기가 끝나고 실제 해결 작업이 시작됩니다. 병목을 분석하려면 업무 시작까지 걸린 시간을 측정해야 합니다.

확보 방법

'sys_audit' 테이블에서 'incident' 테이블의 'state' 필드가 'In Progress'처럼 업무 진행을 나타내는 값으로 바뀐 시점을 찾아 추론합니다.

기록

'state' 필드가 'In Progress' 또는 이에 해당하는 값으로 바뀐 시각을 확인합니다.

이벤트 유형 inferred
인시던트 생성
ServiceNow에 새 인시던트가 정식으로 등록되면 인시던트 수명 주기가 시작됩니다. 인시던트 레코드의 생성 시각을 사용해 이 이벤트를 명시적으로 기록합니다.
중요한 이유

이 이벤트는 프로세스의 기본 시작 이벤트입니다. 이 활동부터 해결까지 걸린 시간을 분석하면 전체 처리 시간과 SLA 준수 여부를 측정할 수 있습니다.

확보 방법

'incident' 테이블의 'sys_created_on' 타임스탬프를 이 활동의 명시적 이벤트 시각으로 사용합니다.

기록

인시던트 레코드의 'sys_created_on' 타임스탬프를 사용합니다.

이벤트 유형 explicit
인시던트 종료
인시던트가 완전히 해결되고 확인을 마쳐 추가 조치가 필요하지 않은 상태를 나타내는 수명 주기의 마지막 활동입니다. 종료 시각을 사용해 이 이벤트를 명시적으로 기록합니다.
중요한 이유

최종 종료 이벤트인 이 활동은 인시던트의 전체 처리 기간을 계산하고 해결 후 처리에 걸린 시간을 분석하는 데 필요합니다.

확보 방법

'incident' 테이블의 'closed_at' 타임스탬프를 명시적 이벤트 시각으로 사용합니다. 일반적으로 'state' 필드가 'Closed'로 바뀔 때 설정됩니다.

기록

인시던트 레코드의 'closed_at' 타임스탬프를 사용합니다.

이벤트 유형 explicit
인시던트를 그룹에 배정
인시던트를 처리할 지원 그룹이 지정될 때 발생합니다. 라우팅의 주요 단계이며, assignment group 필드의 변경을 확인해 기록합니다.
중요한 이유

배정 내역을 추적하면 인계, 그룹별 대기 시간, 라우팅 비효율 및 병목을 분석할 수 있습니다.

확보 방법

'sys_audit' 테이블에서 'incident' 테이블의 'assignment_group' 필드가 입력되거나 변경된 시점을 추적해 추론합니다.

기록

'assignment_group' 필드 변경 시각을 감사 로그에서 가져옵니다.

이벤트 유형 inferred
해결안 제시
지원 담당자가 해결책을 적용하고 인시던트 상태를 'Resolved'로 변경한 시점을 나타냅니다. 최종 종료에 앞서 거치는 주요 단계입니다.
중요한 이유

이 활동은 실제 작업이 끝나고 확인 단계가 시작되었음을 나타냅니다. 이 시점부터 'Incident Closed'까지 걸린 시간을 보면 사용자 확인이나 검증 과정의 지연을 파악할 수 있습니다.

확보 방법

'sys_audit' 테이블에서 'incident' 테이블의 'state' 필드가 'Resolved'로 변경된 시점을 기준으로 추론합니다. 이때 'resolved_at' 타임스탬프가 입력되는 경우가 많습니다.

기록

'state' 필드가 'Resolved'로 바뀐 시각이나 'resolved_at' 타임스탬프를 사용합니다.

이벤트 유형 inferred
사용자 확인 대기
제안된 해결책이 효과가 있었는지 사용자가 확인할 때까지 인시던트가 대기 상태에 놓입니다. 일반적으로 해결 처리 후 'Awaiting User Info'와 같은 특정 상태가 된 시점을 기준으로 추론합니다.
중요한 이유

사용자의 응답이 늦으면 이 상태가 주요 병목이 될 수 있습니다. 이 활동에 걸린 시간을 측정하면 소통의 공백과 종료 절차를 자동화할 기회를 찾을 수 있습니다.

확보 방법

해결 처리 후 특정 대기 상태로 변경된 시점을 'sys_audit' 테이블에서 찾아 추론합니다. 상태 이름은 'Awaiting Caller'처럼 사용자 지정일 수 있습니다.

기록

사용자 입력을 기다리는 상태를 나타내는 값으로 'state'가 바뀐 시각을 확인합니다.

이벤트 유형 inferred
인시던트 분류
Category, Subcategory, Priority 등의 필드를 설정해 인시던트를 처음 분류하는 단계입니다. 일반적으로 생성 직후 해당 필드가 처음 입력되거나 수정된 시점을 감사 기록에서 찾아 이 이벤트를 추론합니다.
중요한 이유

정확한 분류는 올바른 라우팅과 우선순위 지정에 중요합니다. 이 활동을 추적하면 재분류율과 재분류가 해결 시간에 미치는 영향을 분석할 수 있습니다.

확보 방법

'sys_audit' 테이블에서 해당 인시던트의 'category', 'subcategory' 또는 'priority' 필드가 처음 변경된 시점을 찾아 추론합니다.

기록

감사 로그에서 분류 필드가 처음 업데이트된 시각을 확인합니다.

이벤트 유형 inferred
인시던트 에스컬레이션
인시던트의 우선순위나 심각도가 높아져 더 신속한 대응이나 다른 리소스가 필요한 경우 발생합니다. 'priority' 필드 값이 상향 조정된 시점을 찾아 추론합니다.
중요한 이유

에스컬레이션은 인시던트가 처음 예상한 것보다 심각하거나 SLA 위반에 가까워졌음을 나타내는 경우가 많습니다. 이 이벤트를 분석하면 프로세스 예외가 발생하는 상황을 파악할 수 있습니다.

확보 방법

'sys_audit' 테이블에서 'priority' 필드가 더 높은 긴급도를 나타내는 값으로 변경된 시점을 찾아 추론합니다.

기록

'priority' 필드 값이 높아진 시점을 확인합니다(예: '3 - Moderate'에서 '2 - High'로 변경).

이벤트 유형 inferred
인시던트 재개
해결 처리 후에도 문제가 계속된다고 사용자가 알리면 발생합니다. 인시던트 상태가 'Resolved'에서 'In Progress'와 같은 진행 중 상태로 돌아간 시점을 기준으로 추론합니다.
중요한 이유

재개된 인시던트는 해결에 실패해 재작업이 발생했음을 나타냅니다. 해결 품질과 최초 해결률을 측정하려면 이 활동을 추적해야 합니다.

확보 방법

'sys_audit' 테이블에서 'state' 필드가 'Resolved'에서 'In Progress' 또는 'Assigned'와 같은 진행 중 상태로 바뀐 시점을 찾아 추론합니다.

기록

'state'가 'Resolved'에서 진행 중 상태로 바뀐 시각을 확인합니다.

이벤트 유형 inferred
인시던트를 담당자에게 배정
지원 그룹 내 특정 담당자가 인시던트 처리를 맡는 시점을 나타냅니다. 'assigned_to' 필드의 변경을 추적해 기록합니다.
중요한 이유

담당자별 업무량과 최초 문의 해결 현황을 자세히 파악할 수 있습니다. 그룹에 배정된 뒤 담당자가 실제 업무를 시작하기까지 인시던트가 얼마나 대기하는지도 확인할 수 있습니다.

확보 방법

'sys_audit' 테이블에서 'incident' 테이블의 'assigned_to' 필드가 입력되거나 변경된 시점을 추적해 추론합니다.

기록

'assigned_to' 필드 변경 시각을 감사 로그에서 가져옵니다.

이벤트 유형 inferred
인시던트를 문제 레코드에 연결
인시던트가 문제 레코드와 정식으로 연결되어 더 큰 근본 문제의 일부임을 나타내는 활동입니다. 인시던트 레코드의 'problem_id' 필드에 값이 입력된 시점을 기준으로 추론합니다.
중요한 이유

문제 레코드에 연결하면 사후적인 인시던트 대응에서 선제적인 근본 원인 분석으로 전환할 수 있습니다. '반복 인시던트 건수' 대시보드에도 활용됩니다.

확보 방법

'incident' 테이블의 'problem_id' 참조 필드에 값이 입력된 시점을 찾아 추론합니다.

기록

감사 로그에서 'problem_id' 필드가 입력된 시각을 확인합니다.

이벤트 유형 inferred
지원 의견 추가
지원 담당자가 업무 메모를 작성하거나 사용자에게 공개되는 의견을 추가합니다. 인시던트 활동 스트림에 명시적으로 기록되는 이벤트입니다.
중요한 이유

지원팀의 소통과 조사 활동을 추적합니다. 의견이 작성된 빈도와 시점을 분석하면 조사 과정을 파악할 수 있습니다.

확보 방법

'incident' 테이블의 'work_notes' 및 'comments' 필드에 입력된 내용을 기록하는 'sys_journal_field' 테이블에서 가져옵니다.

기록

요소가 'work_notes' 또는 'comments'인 저널 항목의 생성 타임스탬프를 사용합니다.

이벤트 유형 explicit
권장 선택 사항

데이터 추출 안내

ServiceNow Problem Management에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿을 활용하면 incident 관리 process mining을 시작하는 데 필요한 준비를 마칠 수 있습니다. 지금 incident 해결 프로세스를 개선해 보세요.

Incident를 더 빠르게 해결하고 ServiceNow 운영 효율을 높이세요.

ServiceNow에서 MTTR을 35% 줄이세요. 문제를 찾아 만족도를 높이세요.

무료 체험 시작하기

신용카드가 필요하지 않습니다. 몇 분 만에 최적화를 시작할 수 있습니다.