서비스 요청 관리 데이터 템플릿

ServiceNow
서비스 요청 관리 데이터 템플릿

서비스 요청 관리 데이터 템플릿

이 데이터 템플릿은 서비스 요청 관리의 process mining을 쉽게 시작할 수 있도록 구성했습니다. 수집해야 할 필수 속성, 추적해야 할 주요 활동, ServiceNow에 맞는 실용적인 데이터 추출 방법을 안내합니다. 템플릿을 활용하면 정확한 분석과 효과적인 최적화에 필요한 데이터를 빠짐없이 확보할 수 있습니다.
  • 수집 권장 속성
  • 프로세스 탐색을 위해 추적할 주요 활동
  • 단계별 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

서비스 요청 관리 속성

서비스 요청 관리 프로세스를 자세히 분석하려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
5 필수 6 권장 10 선택 사항
이름 설명
서비스 요청 ID
ServiceRequestID
각 서비스 요청 레코드를 고유하게 식별하는 ID입니다.
설명

Service Request ID는 사용자가 제출한 각 서비스 요청을 고유하게 식별하는 기본 키입니다. 요청이 처음 기록된 시점부터 최종 종료까지 발생하는 모든 이벤트를 연결합니다. process mining에서는 이 ID를 사용해 각 요청의 전체 처리 과정을 재구성하고 수명 주기를 빠짐없이 분석합니다.

중요한 이유

필수 Case ID입니다. 관련 활동을 하나의 프로세스 인스턴스로 연결해 프로세스 흐름, 변형 경로, 처리 시간을 분석할 수 있습니다.

확보 방법

ServiceNow Request [sc_request] 테이블의 'number' 필드입니다.

예시
REQ0010001REQ0010025REQ0010112
시작 시간
EventTime
활동이나 이벤트가 시작된 시각을 나타내는 타임스탬프입니다.
설명

이 속성에는 서비스 요청 프로세스에서 각 활동이 발생한 날짜와 시각이 정확히 기록됩니다. 프로세스 맵을 작성하고 시간 기반 분석을 수행하는 데 필요한 이벤트 순서를 제공합니다.

정확한 타임스탬프는 처리 시간과 대기 시간, 작업 소요 시간을 계산하는 데 필요합니다. 이를 바탕으로 병목과 SLA 위반을 찾아내고 시간에 따른 성과 추이를 분석할 수 있습니다.

중요한 이유

이벤트 순서를 정확히 정하려면 반드시 필요한 타임스탬프입니다. 처리 시간과 병목을 파악하는 등 성과 및 소요 시간 분석의 기준이 됩니다.

확보 방법

일반적으로 관련 ServiceNow 테이블(예: sc_request, sc_task)의 'sys_updated_on' 또는 'sys_created_on' 필드나 감사 추적 기록(sys_audit)에서 가져옵니다.

예시
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
활동
ActivityName
서비스 요청 수명 주기에서 발생한 특정 이벤트나 작업의 이름입니다.
설명

활동 속성에는 서비스 요청 프로세스에서 각 단계의 이름이나 상태 변경이 기록됩니다. 예를 들어 '요청 생성', '요청 승인', '상담원에게 할당', '요청 종료'와 같은 이벤트가 포함될 수 있습니다.

이러한 활동을 분석하면 프로세스 흐름을 시각화하고 자주 발생하는 경로를 파악하며 표준 절차와의 편차를 찾을 수 있습니다. 요청 처리 과정에서 실제로 어떤 일이 일어나는지 이해하는 기반이 됩니다.

중요한 이유

프로세스 맵의 단계를 정의하는 필수 속성입니다. 병목과 재작업 루프, 규정 준수 문제를 찾는 등 모든 프로세스 분석에 필요합니다.

확보 방법

'sc_request' 또는 'sc_req_item' 테이블의 'State'나 'Stage' 필드 변경 내역 또는 감사 추적 기록(sys_audit)에서 가져옵니다.

예시
서비스 요청 생성요청을 그룹에 배정서비스 요청 해결사용자에게 정보 요청
소스 시스템
SourceSystem
데이터가 생성된 시스템입니다.
설명

이 속성은 데이터의 소스 시스템을 나타냅니다. 이 사례에서는 ServiceNow입니다. 여러 시스템의 데이터를 결합해 프로세스 전체를 파악할 때 유용합니다.

단일 소스만 분석하는 경우에도 데이터 출처를 명확히 하고 데이터 거버넌스와 관리를 지원합니다. 사용자는 분석 중인 데이터가 어디에서 왔는지 확인할 수 있습니다.

중요한 이유

데이터 거버넌스와 추적 가능성, 데이터 맥락을 파악하는 데 필요한 메타데이터입니다. 여러 기업 시스템의 데이터를 결합할 때 특히 유용합니다.

확보 방법

일반적으로 데이터 추출 및 변환 과정에서 추가하는 고정값입니다.

예시
ServiceNow
최근 데이터 업데이트
LastDataUpdate
가장 최근에 데이터를 새로 고치거나 추출한 시각입니다.
설명

이 속성은 소스 시스템에서 데이터를 마지막으로 추출해 process mining 도구에 적재한 날짜와 시각을 나타냅니다. 분석 대상 데이터가 얼마나 최신인지 확인할 수 있습니다.

분석가는 이 정보를 통해 최신 데이터를 기준으로 분석하는지 확인할 수 있습니다. 운영 현황을 모니터링하고 적시에 데이터에 근거한 의사결정을 내리는 데 필요한 정보입니다. 분석 결과가 어느 시점의 데이터를 반영하는지도 파악할 수 있습니다.

중요한 이유

데이터의 최신성을 확인할 수 있어 분석 결과를 신뢰하고 적시에 데이터에 근거한 의사결정을 내리는 데 도움이 됩니다.

확보 방법

데이터 수집 과정에서 추가하는 메타데이터 필드로, ETL 작업이 완료된 시각을 나타냅니다.

예시
2023-10-27T04:00:00Z
SLA 준수
MadeSLA
서비스 요청이 Service Level Agreement에 정해진 시간 안에 해결되었는지 나타내는 불리언 값입니다.
설명

이 속성은 서비스 요청이 해결 시간에 관한 Service Level Agreement(SLA)를 준수했는지 나타냅니다. 서비스 약속에 따른 성과를 직접 측정하는 주요 결과 지표입니다.

이 값을 분석하면 SLA 준수율 KPI를 산출할 수 있습니다. SLA를 준수한 요청과 위반한 요청의 프로세스 경로를 비교하는 차원으로 활용하면 SLA 미준수와 관련된 공통 패턴이나 활동을 찾을 수 있습니다. 이를 통해 위험을 사전에 모니터링하고 서비스를 지속적으로 개선할 수 있습니다.

중요한 이유

서비스 약속에 따른 성과를 직접 측정하고, 준수 사례와 미준수 사례를 비교해 SLA 위반의 근본 원인을 분석할 수 있습니다.

확보 방법

ServiceNow Task SLA [task_sla] 테이블의 'has_breached' 필드입니다. 값을 반전해야 합니다(예: MadeSLA = NOT has_breached).

예시
truefalse
담당자
AssignedTo
특정 시점에 서비스 요청을 처리할 책임이 있는 사용자입니다.
설명

이 속성은 서비스 요청을 맡은 담당자나 기술자를 식별합니다. 요청이 다른 담당자에게 인계되면 값이 변경됩니다.

'Assigned To' 필드를 분석하면 업무량 분배와 개인별 성과, 인계가 해결 시간에 미치는 영향을 파악할 수 있습니다. 리소스 활용 현황을 확인하고 재배정을 줄이기 위한 교육이나 프로세스 명확화 기회를 찾는 데도 도움이 됩니다.

중요한 이유

담당자의 업무량과 성과, 인계를 분석할 수 있습니다. 리소스 관리와 특정 담당자에게서 발생하는 병목을 파악하는 데 필요합니다.

확보 방법

ServiceNow Request Item [sc_req_item] 또는 Catalog Task [sc_task] 테이블의 'assigned_to' 필드입니다.

예시
Beth AnglinDavid LooHoward Johnson
배정 그룹
AssignmentGroup
서비스 요청을 처리하는 팀이나 그룹입니다.
설명

배정 그룹은 'Service Desk', 'Network Operations', 'Database Administration'과 같이 특정 단계에서 서비스 요청을 담당하는 팀을 나타냅니다. 기능별 조직 사이의 프로세스 흐름을 분석하는 데 필요한 속성입니다.

배정 그룹의 변경을 추적하면 팀 간 인계를 시각화하고 각 그룹의 대기열에서 대기한 시간을 측정하며 팀 간 의존성이나 지연을 파악할 수 있습니다. 부서 간 협업을 개선하는 데 유용합니다.

중요한 이유

팀별 업무 분배와 팀 간 인계를 추적하고, 팀별 병목이나 성과 문제를 파악하는 데 도움이 됩니다.

확보 방법

ServiceNow Request Item [sc_req_item] 또는 Catalog Task [sc_task] 테이블의 'assignment_group' 필드입니다.

예시
서비스 데스크IT 지원 2단계하드웨어 제공
범주
Category
하드웨어나 소프트웨어처럼 서비스 요청을 분류하는 상위 항목입니다.
설명

범주는 서비스 요청을 상위 수준에서 분류하는 항목입니다. 일반적으로 요청을 담당 팀에 배정하거나 접수된 요청 유형을 보고하는 데 사용합니다.

process mining에서는 범주를 기준으로 데이터를 필터링하고 차원별로 분석할 수 있습니다. 분석가는 요청 유형에 따라 프로세스 흐름, 처리 시간, 자동화율을 비교해 전체 데이터에서는 드러나지 않는 차이를 찾을 수 있습니다. 예를 들어 하드웨어 요청과 소프트웨어 요청은 처리 과정이 크게 다를 수 있습니다.

중요한 이유

서비스 유형별로 프로세스를 구분해 비교할 수 있어 범주별 문제와 개선 기회를 찾는 데 도움이 됩니다.

확보 방법

ServiceNow Request Item [sc_req_item] 테이블. 일반적으로 연결된 Catalog Item [sc_cat_item]의 범주를 사용합니다.

예시
하드웨어소프트웨어접근 권한 요청네트워크
상태
State
서비스 요청의 현재 운영 상태입니다.
설명

State 속성은 서비스 요청의 수명 주기에서 현재 단계를 나타냅니다. 예를 들어 'Open', 'Work in Progress', 'Pending', 'Closed' 등이 있습니다. 이 필드의 변경 내역을 바탕으로 프로세스 맵의 활동을 생성하는 경우가 많습니다.

State를 분석하면 요청이 특정 상태, 특히 대기 상태에 머문 시간을 파악할 수 있습니다. 'Awaiting User Information' 상태에서 대기한 시간처럼 처리 시간이 길어지는 원인이 되는 대기열과 지연을 찾는 데 도움이 됩니다.

중요한 이유

각 시점의 요청 상태를 확인할 수 있어 대기 시간과 대기열, 프로세스 단계별 소요 시간을 분석할 수 있습니다.

확보 방법

ServiceNow Request [sc_request] 또는 Request Item [sc_req_item] 테이블의 'state' 또는 'stage' 필드입니다.

예시
접수처리 중사용자 정보 대기완료 후 종료
우선순위
Priority
서비스 요청의 긴급도에 영향을 주는 우선순위입니다.
설명

우선순위는 서비스 요청의 상대적인 중요도와 긴급도를 구분하는 기준입니다. 일반적으로 영향도와 긴급도를 함께 고려해 정하며, 담당자가 먼저 처리할 요청을 결정하는 데 사용합니다.

우선순위별 데이터를 분석하면 우선순위가 높은 요청이 낮은 요청보다 빠르게 처리되는지 확인할 수 있습니다. 대시보드를 우선순위별로 필터링해 중요한 요청의 SLA 준수 여부를 살펴보고, 우선순위 지정 체계가 효과적인지도 평가할 수 있습니다.

중요한 이유

요청을 우선순위별로 나누어 우선순위가 높은 항목이 더 빠르게 처리되는지 확인할 수 있습니다. SLA 분석과 리소스 배분에 필요한 속성입니다.

확보 방법

ServiceNow Request [sc_request] 또는 Request Item [sc_req_item] 테이블의 'priority' 필드입니다.

예시
1 - 긴급2 - 높음3 - 보통4 - 낮음
만족도 점수
SatisfactionScore
요청 종료 시 요청자가 제출한 고객 만족도 평가입니다.
설명

이 속성은 서비스 요청이 해결된 후 최종 사용자가 제출한 만족도 점수를 기록합니다. 점수는 대개 1~5점으로, 사용자가 인식한 서비스 품질을 직접 측정합니다.

이 데이터는 고객 만족도 영향 분석 대시보드에 필요합니다. 처리 시간, 재작업, 인계와 같은 프로세스 지표를 최종 고객 경험과 직접 비교할 수 있습니다. 운영 효율성과 고객 결과를 연결해 프로세스 개선의 사업적 효과를 설명하는 데 도움이 됩니다.

중요한 이유

프로세스 성과 지표와 고객 결과를 직접 연결해 프로세스 비효율이 사용자 경험에 미치는 영향을 수치로 파악할 수 있습니다.

확보 방법

일반적으로 원래 요청과 연결된 Survey [asmt_assessment_instance] 테이블에서 확인할 수 있습니다.

예시
5431
요청 처리 시간
CaseCycleTime
서비스 요청 생성부터 최종 종료까지 걸린 총시간입니다.
설명

요청 처리 시간은 서비스 요청의 첫 이벤트 시각부터 마지막 이벤트 시각까지의 전체 기간을 측정하는 계산 지표입니다. 고객 관점에서 요청이 처음부터 끝까지 처리되는 데 걸린 시간을 나타냅니다.

전체 프로세스 효율성을 보여주는 주요 KPI입니다. 상위 수준의 대시보드에서 목표 대비 성과를 모니터링하고 시간에 따른 추이를 분석하는 데 사용합니다. 범주나 우선순위별로 나누어 분석하면 처리 시간이 가장 긴 요청 유형을 찾을 수 있습니다.

중요한 이유

프로세스의 처음부터 끝까지 성과를 측정하는 주요 KPI입니다. 상위 수준의 모니터링과 벤치마킹, 개선 영역 파악에 필요합니다.

확보 방법

각 고유 'ServiceRequestID'에 대해 최소 'StartTime'을 최대 'EndTime'에서 빼서 계산합니다.

예시
2 10:30:000 04:15:2210 00:05:00
자동화 여부
IsAutomated
활동을 시스템이나 자동화가 수행했는지 나타내는 값입니다.
설명

이 불리언 속성은 담당자가 직접 수행한 활동과 workflow 또는 연동 시스템이 자동으로 처리한 활동을 구분합니다. 예를 들어 '승인 요청'은 자동화될 수 있고, '담당자에게 요청 배정'은 수동으로 처리될 수 있습니다.

이 속성을 분석하면 서비스 요청 프로세스의 자동화 수준을 측정하고 높일 수 있습니다. 시간이 많이 걸리는 수동 작업을 찾아 향후 자동화 후보로 검토하면 효율성을 높이고 비용을 줄일 수 있습니다.

중요한 이유

자동화율을 측정하고 수동 작업의 자동화 기회를 찾아 효율성을 높이고 운영 비용을 줄일 수 있습니다.

확보 방법

작업을 수행한 사용자가 지정된 시스템 또는 연동 사용자에 해당하는지 확인해 산출합니다(예: 'sys_updated_by').

예시
truefalse
재개 횟수
ReopenCount
해결된 서비스 요청이 다시 열린 횟수입니다.
설명

이 속성은 서비스 요청이 해결 또는 종료 상태에서 접수 또는 처리 중 상태로 되돌아간 횟수를 기록합니다. 값이 0보다 크면 최초 해결이 성공적이지 않았음을 의미합니다.

이 지표는 재작업을 직접 나타내며, 최초 해결률 KPI를 구성하는 주요 항목입니다. 재개 횟수가 많으면 해결 품질이 낮거나 요청이 완전히 처리되지 않았거나 사용자의 요구를 잘못 이해했을 가능성이 있습니다. 이러한 문제는 프로세스 효율성을 떨어뜨리고 사용자 만족도를 낮춥니다.

중요한 이유

재작업과 해결 품질을 수치로 보여줍니다. 재개 횟수가 많으면 비효율, 낮은 최초 해결률, 고객 만족도 저하를 의심할 수 있습니다.

확보 방법

ServiceNow Request [sc_request] 또는 Request Item [sc_req_item] 테이블의 'reopen_count' 필드입니다.

예시
012
재작업 여부
IsRework
같은 케이스에서 이전 활동이 반복되었는지 나타내는 계산 값입니다.
설명

이 불리언 값은 서비스 요청에서 재작업이 반복되는 구간을 식별하기 위해 계산합니다. 같은 케이스에서 동일한 활동이 이미 발생한 경우 'true'로 표시합니다. 예를 들어 요청이 같은 팀에 두 번 배정되거나 사용자에게 정보를 여러 차례 요청한 경우입니다.

이 속성은 담당자 인계 및 재작업 대시보드와 요청 재작업률 KPI에 필요합니다. 전체 데이터에서는 잘 드러나지 않는 비효율적인 반복을 시각화하고 수치로 파악할 수 있습니다.

중요한 이유

프로세스 재작업을 직접 표시하고 수치화해 비용과 처리 시간을 늘리는 비효율적인 반복의 원인과 영향을 분석할 수 있습니다.

확보 방법

데이터 변환 중 같은 케이스에서 동일한 활동 이름이 이전에 발생했는지 확인해 계산합니다.

예시
falsetrue
접수 채널
ContactType
요청자가 서비스 요청을 제출할 때 사용한 방법입니다.
설명

Contact Type 또는 채널은 서비스 요청이 어떤 경로로 접수되었는지 나타냅니다. 일반적인 채널로는 서비스 포털, 이메일, 전화, 자동 알림이 있습니다.

접수 방법에 따라 프로세스가 달라질 수 있으므로 채널을 파악하는 것이 중요합니다. 예를 들어 포털로 접수된 요청은 형식이 표준화되고 자동화되어 이메일 요청보다 빠르게 처리될 수 있습니다. 채널별 분석을 통해 효율적인 접수 경로의 이용을 늘릴 수 있습니다.

중요한 이유

접수 채널에 따라 프로세스 효율성, 자동화 수준, 전체 처리 시간이 어떻게 달라지는지 파악해 사용자 접점 개선 방향을 정할 수 있습니다.

확보 방법

ServiceNow Request [sc_request] 또는 Interaction [interaction] 테이블입니다. 필드 이름은 대개 'contact_type'입니다.

예시
포털이메일전화셀프서비스
종료 시간
EndTime
활동이나 이벤트가 완료된 시각을 나타내는 타임스탬프입니다.
설명

종료 시간은 활동이 끝난 시점을 나타냅니다. 현재 활동의 소요 시간을 계산할 수 있도록 다음 활동의 타임스탬프를 기록합니다. 각 프로세스 단계에 걸린 시간을 계산하는 데 필요한 속성입니다.

분석가는 활동의 시작 시간과 종료 시간을 비교해 처리 시간과 대기 시간을 계산할 수 있습니다. 병목 파악, 리소스 효율성 측정, 시간 기준 목표 대비 성과 모니터링에 필요한 정보입니다.

중요한 이유

각 활동의 소요 시간을 계산하는 데 필요한 속성입니다. 성과 분석, 병목 파악, 리소스 활용도 분석의 기반이 됩니다.

확보 방법

파생 속성입니다. 해당 사례에서 다음 이벤트의 'StartTime'을 기준으로 계산합니다.

예시
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
최초 등록자
OpenedBy
서비스 요청을 처음 제출한 사람입니다.
설명

이 속성은 서비스 요청을 생성한 사용자를 식별합니다. 요청의 영향을 받는 사람과 같은 경우가 많지만, 관리자나 대리인 또는 자동화 시스템일 수도 있습니다.

최초 등록자나 해당 부서별로 요청을 분석하면 복잡하거나 문제가 있는 요청을 자주 제출하는 사용자 그룹과 같은 패턴을 찾을 수 있습니다. 이를 바탕으로 맞춤형 교육을 제공하거나 셀프서비스 이용을 돕는 지식 문서를 보완할 수 있습니다.

중요한 이유

사용자, 부서, 역할별 요청 패턴을 분석해 교육 계획과 대상별 프로세스 개선에 활용할 수 있습니다.

확보 방법

ServiceNow Request [sc_request] 테이블의 'opened_by' 필드입니다.

예시
Abel TuterFred LuddyDon Goodliffe
최초 해결 여부
IsFirstPassResolution
요청이 재개되지 않고 첫 시도에 해결되었는지 나타내는 값입니다.
설명

이 계산 속성은 서비스 요청이 한 번도 재개되지 않은 채 해결되고 종료된 경우에만 'true'로 표시되는 불리언 값입니다. 서비스 데스크가 제공한 해결의 품질과 효과를 보여주는 주요 지표입니다.

이 지표는 최초 해결률 KPI를 직접 뒷받침합니다. 최초 해결률이 높으면 효율적이고 품질 높은 서비스를 제공한다는 뜻이며, 고객 만족도 향상으로 이어집니다. 최초 해결에 실패한 케이스의 속성을 분석하면 교육 부족, 문서 미비, 최초 진단 오류와 같은 근본 원인을 찾을 수 있습니다.

중요한 이유

해결 프로세스의 품질과 효율성을 측정합니다. 최초 해결률이 낮으면 재작업과 고객 불만을 일으키는 근본 문제가 있을 수 있습니다.

확보 방법

케이스 단위로 계산합니다. 'ReopenCount'가 0이면 최초 해결로 간주합니다.

예시
truefalse
해결 코드
ResolutionCode
서비스 요청의 최종 해결 방식을 분류하는 코드입니다.
설명

해결 코드는 서비스 요청이 최종적으로 어떤 방식으로 해결되었는지 구조화해 분류합니다. 예를 들면 '자동화로 처리', '사용자 오류', '더 이상 필요하지 않음' 등이 있습니다.

이 속성은 지연 원인 분석 대시보드에 중요합니다. 해결 코드를 긴 처리 시간이나 높은 재작업률과 연계하면 시스템적인 문제를 찾을 수 있습니다. 예를 들어 '정보 불충분' 코드가 붙은 요청이 지속적으로 늦게 처리된다면, 최초 정보 수집 단계에 문제가 있음을 알 수 있습니다.

중요한 이유

해결 결과를 구조화된 데이터로 제공해 프로세스 지연, 재작업 및 기타 비효율의 근본 원인을 분석할 수 있습니다.

확보 방법

ServiceNow Request Item [sc_req_item] 또는 관련 task 테이블입니다. 필드 이름은 일반적으로 'close_code' 또는 'resolution_code'입니다.

예시
해결됨(영구 해결)미해결(재현 불가)요청 처리 완료사용자 취소
필수 권장 선택 사항

서비스 요청 관리 활동

정확한 프로세스 탐색과 병목 식별을 위해 이벤트 로그에 기록해야 할 주요 단계와 마일스톤입니다.
6 권장 8 선택 사항
활동 설명
사용자에게 정보 요청
이행 담당자가 처리를 계속하기 위해 최초 요청자에게 추가 정보를 요청할 때 발생합니다. 일반적으로 요청 상태가 'Awaiting User Info'와 같은 값으로 바뀐 시점으로 추정합니다.
중요한 이유

'요청자 정보 대기 시간 분석' 대시보드에 필요한 활동입니다. 사용자의 추가 정보를 기다리느라 지연된 시간을 측정할 수 있습니다.

확보 방법

sc_req_item의 state 필드가 지정된 정보 대기 상태로 바뀐 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sc_req_item.state가 'Awaiting User Info'로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
서비스 요청 생성
서비스 요청 수명 주기는 사용자가 서비스 카탈로그에서 요청을 제출할 때 시작됩니다. 이 활동은 sc_req_item(Requested Item) 테이블에 새 레코드가 생성된 이벤트로 기록됩니다.
중요한 이유

프로세스의 주요 시작 이벤트입니다. 전체 처리 시간을 계산하고 요청량과 제출 패턴을 분석하는 데 필요합니다.

확보 방법

sc_req_item 테이블 레코드의 생성 시각(sys_created_on 필드)에서 가져오는 명시적 이벤트입니다.

기록

sc_req_item 레코드의 sys_created_on 타임스탬프를 사용합니다.

이벤트 유형 explicit
서비스 요청 종료
서비스 요청 수명 주기가 최종적으로 끝나는 시점입니다. 일반적으로 요청이 'Resolved' 상태로 일정 기간 유지된 후 자동으로 종료됩니다. 이 기간에는 사용자가 요청을 다시 열 수 있습니다.
중요한 이유

프로세스가 성공적으로 끝나는 주요 이벤트입니다. 'Resolved'에서 'Closed'로 바뀌기까지 걸린 시간을 분석하면 자동 종료 정책을 평가할 수 있습니다.

확보 방법

sc_req_item의 state 필드가 'Closed Complete'와 같은 최종 종료 상태로 변경된 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sc_req_item.state가 'Closed Complete'로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
서비스 요청 해결
이행 담당자가 작업을 완료하고 해결책을 제공한 것을 나타냅니다. 요청 상태가 'Resolved' 또는 이에 해당하는 상태로 변경되면 기록됩니다.
중요한 이유

일반적으로 이 시점에 SLA 측정이 중단됩니다. 실제 이행 작업이 끝나는 시점으로, 전체 해결 시간을 계산하는 데 사용됩니다.

확보 방법

최종 종료 전에 sc_req_item의 state 필드가 '해결됨' 또는 이와 유사한 최종 상태로 업데이트된 경우로 추정합니다. 변경 사항은 sys_audit 테이블에서 추적합니다.

기록

sc_req_item.state가 'Resolved'로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
요청 승인
승인자가 연결된 승인 레코드를 'approved'로 표시하면 요청이 공식 승인되어 이행 단계로 넘어갈 수 있습니다.
중요한 이유

승인 단계에서 이행 단계로 넘어가는 주요 시점입니다. 이 단계에 도달하는 데 걸린 시간을 분석하면 이행 전 지연을 파악할 수 있습니다.

확보 방법

연결된 sysapproval_approver 레코드의 state 필드가 'approved'로 바뀐 시점으로 추정합니다. 이후 sc_req_item의 상태가 변경됩니다.

기록

sysapproval_approver.state가 'approved'가 된 타임스탬프를 확인합니다.

이벤트 유형 inferred
요청을 담당자에게 배정
특정 담당자가 서비스 요청을 처리하도록 배정되면 이 활동이 발생합니다. 요청이나 이행 작업의 'Assigned to' 필드 변경 내역을 확인해 기록합니다.
중요한 이유

인계 횟수와 담당자별 업무량을 측정하고, 담당자가 요청 처리를 시작하기 전 대기 시간을 분석하는 데 필요합니다.

확보 방법

sc_req_item 또는 sc_task 테이블의 assigned_to 필드가 변경된 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sys_audit에서 assigned_to 필드의 변경 내역을 추적합니다.

이벤트 유형 inferred
사용자가 정보 제공
요청자가 필요한 정보를 제공한 시점을 나타냅니다. 요청 상태가 'Awaiting User Info'에서 'Work in Progress'와 같은 진행 중 상태로 바뀐 시점으로 추정합니다.
중요한 이유

'사용자에게 정보 요청' 활동과 함께 분석하면 사용자가 정보를 제공하기까지 발생한 지연을 정확히 측정하고 커뮤니케이션 과정의 효율성을 평가할 수 있습니다.

확보 방법

sc_req_item의 state 필드가 정보 대기 상태에서 활성 상태로 바뀐 시점으로 추정합니다. 사용자가 댓글을 추가하거나 이메일에 회신하면 상태가 변경되는 경우가 많습니다.

기록

'사용자 정보 대기'에서 '작업 진행 중'으로 상태가 변경된 타임스탬프를 확인합니다.

이벤트 유형 inferred
승인 요청
서비스 요청을 관리자나 지정된 승인자에게 승인받도록 제출한 시점을 나타냅니다. 일반적으로 요청 상태가 'Pending Approval' 또는 이에 해당하는 상태로 바뀐 시점으로 추정합니다.
중요한 이유

승인 과정을 추적하면 승인 단계의 병목을 파악하고 이행을 시작하기 전까지 요청이 승인 대기 상태로 머문 시간을 측정할 수 있습니다.

확보 방법

sc_req_item의 state 필드가 승인 대기 상태로 바뀌거나 sysapproval_approver 테이블에 해당 레코드가 생성된 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sc_req_item.state가 'Pending Approval'로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
외부 공급업체 참여
서비스 요청이나 관련 작업이 이행을 위해 외부 공급업체에 전달된 것을 나타냅니다. 공급업체 전용 그룹에 배정되거나 요청에 특정 플래그가 설정된 내역으로 추정할 수 있습니다.
중요한 이유

이 활동을 분석하면 공급업체의 성과와 전체 요청 처리 과정에 미치는 영향을 파악할 수 있습니다. '외부 공급업체 참여 주기' 대시보드 분석에도 활용됩니다.

확보 방법

일반적으로 추정하는 이벤트입니다. assignment_group이 공급업체 그룹으로 설정되거나 sc_req_item 또는 sc_task 레코드의 특정 플래그 필드가 설정된 경우를 기준으로 삼을 수 있습니다.

기록

assignment_group이 확인된 공급업체 그룹으로 변경된 시점을 확인합니다.

이벤트 유형 inferred
요청 거부
승인 단계에서 요청이 공식적으로 거부된 경우를 나타냅니다. 요청을 종료하는 대체 경로이며, 승인자가 요청을 'rejected'로 표시할 때 기록됩니다.
중요한 이유

거부 내역을 추적하면 유효하지 않거나 잘못 전달된 요청, 요청 제출 과정의 문제를 파악할 수 있습니다. 프로세스 예외 경로를 분석하는 데도 활용됩니다.

확보 방법

연결된 sysapproval_approver 레코드의 state 필드가 'rejected'로 바뀐 시점으로 추정합니다. 일반적으로 상위 sc_req_item은 미완료 종료 상태로 변경됩니다.

기록

sysapproval_approver.state가 'rejected'가 된 타임스탬프를 확인합니다.

이벤트 유형 inferred
요청 재개
해결된 요청이 다시 열림 상태로 바뀐 경우를 기록합니다. 상태가 'Resolved'에서 'Work in Progress' 또는 이에 해당하는 상태로 변경된 내역으로 추정합니다.
중요한 이유

재작업을 직접 측정하는 지표이며 '최초 해결률' KPI를 계산하는 데 필요합니다. 수치가 높으면 해결 품질이 낮거나 처리가 완료되지 않았을 가능성이 있습니다.

확보 방법

sc_req_item의 state 필드가 해결 또는 종료 상태에서 열림이나 진행 중 상태로 바뀐 시점으로 추정합니다. 변경 내역은 sys_audit에 기록됩니다.

기록

sys_audit에서 상태가 'Resolved'에서 'Work in Progress'로 바뀐 내역을 확인합니다.

이벤트 유형 inferred
요청 취소
사용자나 담당자가 요청을 완료 전에 취소한 경우의 종료 상태입니다. 요청 상태가 'Cancelled' 또는 'Closed Cancelled'로 설정되면 기록됩니다.
중요한 이유

요청이 성공적으로 완료되지 않은 주요 종료 이벤트입니다. 취소 이유를 분석하면 사용자 요구, 프로세스 비효율성 또는 달라진 비즈니스 우선순위를 파악할 수 있습니다.

확보 방법

sc_req_item의 state 필드가 'Closed Cancelled'와 같은 최종 취소 상태로 변경된 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sc_req_item.state가 'Cancelled'로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
요청을 그룹에 배정
서비스 요청이 특정 이행 팀이나 그룹에 배정된 것을 나타냅니다. 요청 항목이나 연결된 작업의 assignment group 필드가 바뀐 내역을 찾아 이 이벤트를 추정합니다.
중요한 이유

그룹 배정을 추적하면 팀별 업무량을 분석하고 요청이 적절한 담당자에게 전달되기 전 발생하는 지연을 파악할 수 있습니다.

확보 방법

sc_req_item 또는 sc_task 테이블의 assignment_group 필드가 변경된 시점으로 추정합니다. 변경 내역은 sys_audit 테이블에 기록됩니다.

기록

sys_audit에서 assignment_group 필드의 변경 내역을 추적합니다.

이벤트 유형 inferred
이행 작업 생성
서비스 요청을 처리하는 데 필요한 특정 작업 항목 또는 Task가 생성되었음을 나타냅니다. Catalog Task 테이블에 새 레코드가 생성될 때 명시적인 이벤트로 기록됩니다.
중요한 이유

복잡한 요청은 개별 작업의 생성과 완료를 분석하면 이행 과정을 더 세밀하게 파악하고 지연이 발생하는 지점을 찾을 수 있습니다.

확보 방법

sc_req_item과 연결된 sc_task 레코드의 생성 시각(sys_created_on 필드)에서 가져오는 명시적 이벤트입니다.

기록

sc_task 레코드의 sys_created_on 타임스탬프를 사용합니다.

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

데이터 추출 가이드

ServiceNow에서 데이터 추출하기

시작할 준비가 되셨나요?

이 템플릿으로 process mining을 시작하고 서비스 요청 관리의 효율을 높이세요. 지금 워크플로를 개선해 요청을 더 빠르게 해결하고 고객 만족도를 높일 수 있습니다.

서비스 요청 관리 개선, 지금 시작하세요

서비스 요청의 자동화율을 70%까지 높이고 해결 시간을 단축하세요.

무료 체험 시작하기

신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.