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

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

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

이 템플릿은 서비스 요청 관리 프로세스를 효과적으로 process mining하기 위해 필요한 데이터를 수집하는 방법을 안내합니다. 수집할 주요 속성과 추적할 활동을 정리하고, 시스템에서 데이터를 추출하는 실용적인 방법도 제공합니다. 이 자료를 활용해 분석에 필요한 이벤트 로그를 구성하세요.
  • 심층 분석에 권장되는 속성
  • 프로세스 발견을 위해 추적할 주요 활동
  • 원본 시스템에서 데이터를 추출하는 방법
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

서비스 요청 관리 속성

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

Service Request ID는 사용자나 시스템이 제출한 각 서비스 요청을 고유하게 식별합니다. 최초 기록부터 최종 종료까지 이어지는 모든 이벤트를 연결하는 기준이므로, 각 서비스 요청의 전체 처리 과정을 분석할 수 있습니다.

중요한 이유

관련된 모든 활동을 하나의 프로세스 인스턴스로 연결하는 필수 케이스 식별자입니다. 이를 통해 종단 간 프로세스를 분석할 수 있습니다.

확보 방법

Service Request 비즈니스 객체의 기본 키이며, ServiceReq 테이블의 ServiceReqNumber로 저장되는 경우가 많습니다.

예시
SR-0012345SR-0012346SR-0012347
이벤트 시간
EventTime
특정 활동이나 이벤트가 발생한 시점을 나타내는 타임스탬프입니다.
설명

시작 시간이라고도 하는 이벤트 시간은 활동이 시스템에 기록된 정확한 날짜와 시간입니다. 이벤트 순서를 정확히 정하는 데 필요하며, 처리 시간과 대기 시간, 활동 소요 시간 등 시간 기반 process mining 분석의 기준이 됩니다.

중요한 이유

이 타임스탬프는 이벤트를 시간순으로 정렬하고 모든 시간 기반 지표를 계산하는 데 필요하며, 성과 분석의 중요한 기준입니다.

확보 방법

감사 로그, 저널 항목(예: Journal.CreatedDateTime) 또는 Service Request와 연결된 상태 변경 기록에서 확인할 수 있습니다.

예시
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
활동명
ActivityName
서비스 요청 수명 주기의 특정 시점에 발생한 이벤트나 작업의 이름입니다.
설명

이 속성은 'Request Submitted for Approval' 또는 'Service Request Resolved'와 같은 서비스 요청 프로세스의 특정 단계나 상태 변경을 나타냅니다. 활동의 순서와 빈도를 분석하면 프로세스 흐름을 이해하고 병목을 찾으며 표준 절차에서 벗어난 지점을 파악할 수 있습니다.

중요한 이유

프로세스 맵의 단계를 정의해 프로세스 흐름을 시각화하고 분석할 수 있습니다. 재작업과 병목, 이탈을 찾는 데도 활용됩니다.

확보 방법

일반적으로 Ivanti Service Manager의 상태 변경 내역, 저널 항목 또는 감사 로그의 이벤트 설명에서 가져옵니다.

예시
서비스 요청 생성요청 승인서비스 요청 해결서비스 요청 종료
원천 시스템
SourceSystem
데이터를 추출한 시스템입니다.
설명

이 속성은 프로세스 데이터의 출처를 나타냅니다. 이 보기에서는 모든 데이터가 Ivanti Service Manager에서 왔음을 나타내는 동일한 값이 사용됩니다. 여러 시스템의 데이터를 병합할 수 있는 환경에서 데이터의 출처와 맥락을 명확히 하는 데 중요합니다.

중요한 이유

데이터의 출처를 명확히 해 분석 결과를 해당 원천 시스템에 정확히 연결할 수 있습니다. 여러 시스템을 사용하는 환경에서 특히 유용합니다.

확보 방법

일반적으로 데이터 추출 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.

예시
Ivanti Service Manager
최근 데이터 업데이트
LastDataUpdate
원천 시스템에서 데이터를 가장 최근에 새로 고친 시점의 타임스탬프입니다.
설명

이 속성은 Ivanti Service Manager에서 데이터를 마지막으로 추출한 날짜와 시간을 나타냅니다. 분석 대상 데이터의 최신성을 확인하고, 분석에 포함된 기간과 다음 업데이트 시점을 파악할 수 있습니다.

중요한 이유

데이터가 얼마나 최신인지 알려줍니다. 현재 이용할 수 있는 프로세스 성과 정보를 바탕으로 의사결정을 내리는 데 중요합니다.

확보 방법

데이터를 추출할 때 생성되어 데이터 세트에 기록되는 값입니다.

예시
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
SLA 기한
SLADeadline
서비스 요청을 해결해야 하는 기한을 나타내는 타임스탬프입니다.
설명

SLA 기한은 서비스 수준 계약을 준수하기 위해 서비스 요청을 해결해야 하는 날짜와 시간입니다. 일반적으로 요청의 우선순위와 유형 등을 기준으로 산정합니다. 실제 해결 시각과 이 기한을 비교해 SLA 준수 여부를 측정합니다.

중요한 이유

실제 성과를 평가하는 기준으로, SLA 준수율을 계산하고 기한을 넘길 위험이 있는 요청을 파악하는 데 활용됩니다.

확보 방법

Ivanti에서 계산 필드로 제공되는 경우가 많으며, Service Level Agreement 또는 Offering 관련 필드에 'ResolutionTargetDateTime'과 같은 이름으로 저장될 수 있습니다.

예시
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
SLA 상태
SLAStatus
서비스 요청이 SLA 기한 내에 해결되었는지 나타냅니다.
설명

이 파생 속성은 해결 시각과 SLA 기한을 비교해 각 서비스 요청을 '준수' 또는 '위반'으로 표시합니다. 'SLA 준수 성과' 대시보드와 '서비스 수준 계약 준수율' KPI의 기준이 됩니다. 각 케이스의 ResolutionDateTime과 SLADeadline을 비교해 판정합니다.

중요한 이유

서비스 약속을 얼마나 잘 지켰는지 직접 측정하므로 서비스 품질을 평가하고 사용자의 신뢰를 유지하는 데 중요합니다.

확보 방법

'ResolutionDateTime'과 'SLADeadline'을 비교해 계산합니다. ResolutionDateTime <= SLADeadline이면 '준수', 그렇지 않으면 '위반'입니다.

예시
준수위반
담당 상담원
AssignedAgent
서비스 요청을 담당하도록 지정된 개별 사용자 또는 상담원입니다.
설명

담당 상담원은 서비스 요청을 처리하는 책임이 있는 특정 담당자입니다. 이 속성을 활용하면 개인별 성과 관리, 업무량 조정, 교육 기회 파악에 필요한 분석을 수행할 수 있습니다. 상담원 간 재할당을 추적하면 '요청당 평균 재할당 횟수'와 같은 KPI를 계산하고 프로세스의 비효율을 파악할 수 있습니다.

중요한 이유

개인별 업무량과 성과, 재할당 패턴을 분석할 수 있습니다. 이를 통해 교육, 보유 기술 또는 초기 배정 과정의 문제를 파악할 수 있습니다.

확보 방법

일반적으로 Service Request 객체의 'Owner'와 같은 필드에서 확인할 수 있습니다. 재할당될 때마다 값이 바뀔 수 있으므로 이벤트 로그에서 변경 내역을 추적해야 합니다.

예시
앨리스 존슨밥 윌리엄스찰리 브라운다이애나 프린스
담당 팀
AssignedTeam
현재 서비스 요청을 처리하도록 지정된 지원 팀 또는 그룹입니다.
설명

이 속성은 특정 시점에 서비스 요청을 처리할 책임이 있는 팀을 식별합니다. 팀 간 인계, 팀별 처리 시간, 팀별 요청 건수를 분석하면 업무량 분포를 파악하고 병목을 찾으며 팀 성과를 평가할 수 있습니다. SLA 준수와 상담원 업무량 관련 대시보드에도 직접 활용됩니다.

중요한 이유

담당 팀과 인계 내역을 추적해 팀 간 지연, 업무량 균형, 프로세스에서 병목이 되는 팀을 분석할 수 있습니다.

확보 방법

일반적으로 Service Request 객체의 'OwnerTeam'과 같은 필드나 관련 할당 레코드에 저장됩니다.

예시
IT 서비스 데스크네트워크 운영인사 지원시설 관리
서비스 요청 상태
ServiceRequestStatus
이벤트 발생 시점의 서비스 요청 상태입니다.
설명

이 속성은 서비스 요청의 상태를 기록합니다. 예를 들어 '접수됨', '진행 중', '대기 중', '해결됨', '종료됨' 등이 있습니다. 상태 변경은 프로세스 로그의 활동을 정의하는 경우가 많습니다. 상태별 소요 시간을 분석하면 요청이 '대기 중' 상태에 지나치게 오래 머무는 경우처럼 병목을 찾을 수 있습니다.

중요한 이유

시점별 요청 상태를 확인할 수 있어 특정 상태에 머문 시간을 계산하고 프로세스가 정체되는 지점을 찾는 데 도움이 됩니다.

확보 방법

Service Request 객체의 표준 필드이며, 일반적으로 'Status'라는 이름을 사용합니다.

예시
접수됨진행 중고객 응답 대기요청 이행 완료종료됨
서비스 요청 유형
ServiceRequestType
서비스 요청의 분류 또는 범주입니다.
설명

이 속성은 서비스 요청을 '하드웨어 요청', '소프트웨어 설치', '비밀번호 재설정' 등으로 분류합니다. 서비스 유형별로 프로세스 성과, 처리 주기, SLA 준수 여부를 비교할 수 있어 분석에 중요한 기준이 됩니다. 차이를 파악하면 서비스 유형에 맞춰 프로세스를 개선하고 리소스를 더 효과적으로 배분할 수 있습니다.

중요한 이유

요청 유형별로 프로세스를 나누어 분석하면 특정 유형의 요청에서 지연, 재작업 또는 SLA 위반이 더 자주 발생하는지 확인할 수 있습니다.

확보 방법

Service Request 비즈니스 객체의 필드일 가능성이 높으며, 보통 'Service' 또는 'Category'라는 이름을 사용합니다. 'SvcReqTmplLink_Category'와 같은 구체적인 필드명은 Ivanti Service Manager 문서를 확인하세요.

예시
새 하드웨어 요청소프트웨어 액세스계정 변경정보 문의
우선순위
Priority
서비스 요청에 지정된 우선순위입니다.
설명

우선순위는 서비스 요청의 긴급도를 나타내며, 일반적으로 '낮음', '보통', '높음', '긴급' 등으로 구분합니다. 이 속성을 분석하면 우선순위가 높은 요청을 실제로 더 신속하게 처리하는지 평가할 수 있습니다. 우선순위별 처리 주기와 SLA 준수 여부를 비교해 우선순위 규칙이 의도대로 작동하는지 확인합니다.

중요한 이유

우선순위 지정 전략의 효과를 평가하고, 우선순위가 높은 요청이 낮은 요청보다 빠르게 해결되는지 확인하는 데 중요합니다.

확보 방법

Service Request 객체의 표준 필드이며, 일반적으로 'Priority'라는 이름을 사용합니다.

예시
1 - 긴급2 - 높음3 - 보통4 - 낮음
이벤트 종료 시간
EventEndTime
활동이 완료된 시점을 나타내는 타임스탬프입니다.
설명

이벤트 종료 시간은 활동이 완료된 시점을 나타냅니다. 이벤트 시간(시작)부터 이벤트 종료 시간까지의 간격은 해당 활동의 처리 시간입니다. 이 시간을 분석하면 프로세스에서 시간이 가장 오래 걸리는 단계를 파악하고, 비효율적인 부분과 개선이 필요한 영역을 찾을 수 있습니다.

중요한 이유

활동별 소요 시간을 계산할 수 있어 프로세스 병목과 장시간 실행되는 작업을 파악하는 데 도움이 됩니다.

확보 방법

별도의 필드로 제공되지 않을 수 있습니다. 같은 케이스에서 다음 순서로 진행되는 활동의 시작 시간이 종료 시간으로 사용되는 경우가 많습니다.

예시
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
해결 시각
ResolutionDateTime
서비스 요청이 공식적으로 해결된 날짜와 시간입니다.
설명

케이스 수준의 속성으로, 요청을 공식적으로 종료하기 전에 서비스가 제공되거나 문제가 해결된 최종 시점을 기록합니다. 이 타임스탬프는 서비스 요청의 전체 처리 주기를 계산할 때 기준이 되는 종료 시점입니다. 프로세스 전반의 효율성과 SLA 준수 여부를 측정하는 데 중요합니다.

중요한 이유

전체 프로세스 처리 주기를 계산하는 종료 시점을 정의하며, 서비스 제공 효율성을 평가하는 주요 성과 지표로 활용됩니다.

확보 방법

Service Request 객체의 특정 타임스탬프 필드이며, 'ResolvedDateTime' 또는 이와 유사한 이름을 사용하는 경우가 많습니다.

예시
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
공급업체명
VendorName
요청 해결에 참여한 외부 공급업체의 이름입니다.
설명

이 속성은 서비스 요청을 지원하거나 완료하기 위해 참여한 외부 공급업체를 식별합니다. 공급업체별 성과를 측정하고 비교할 수 있어 '외부 공급업체 활동 시간' 대시보드에 필요합니다. 공급업체 관계를 관리하고 외부 의존성으로 발생하는 병목을 파악하는 데도 도움이 됩니다.

중요한 이유

외부 업체의 성과와 전체 서비스 요청 해결 시간에 미치는 영향을 분석해 공급업체 관리에 활용할 수 있습니다.

확보 방법

서비스 요청과 연결된 작업 객체의 필드이거나, 공급업체가 지정된 경우 Service Request 자체의 특정 필드일 수 있습니다.

예시
Dell 지원Oracle 컨설팅Microsoft 프리미어 지원null
요청자 부서
RequestorDepartment
서비스 요청을 제출한 사용자가 속한 부서입니다.
설명

이 속성은 서비스 요청을 시작한 직원 또는 시스템의 부서를 식별합니다. 예를 들어 '영업', '재무', '인사' 등이 있습니다. 조직 내 부서별 서비스 품질과 수요를 분석할 수 있으며, 특정 부서의 해결 시간이 더 길거나 요청 건수가 더 많은지 확인하는 데 도움이 됩니다.

중요한 이유

사업 부문별 서비스 이용 현황과 품질을 분석해 부서별 문제나 추세를 파악할 수 있습니다.

확보 방법

일반적으로 Service Request와 연결된 요청자의 사용자 프로필에서 가져옵니다. Profile.Employee 객체의 'Department' 필드일 수 있습니다.

예시
재무영업마케팅정보 기술
재개 횟수
ReopenCount
해결된 서비스 요청이 다시 열린 횟수입니다.
설명

이 속성은 서비스 요청이 '해결됨' 또는 '종료됨' 상태에서 다시 '진행 중' 상태로 바뀔 때마다 증가하는 카운터입니다. 재개 횟수가 많으면 최초 해결의 품질이 낮거나, 해결이 불완전하거나, 문제가 반복된다는 신호일 수 있습니다. '서비스 요청 재작업률' KPI를 계산하는 데 직접 활용됩니다.

중요한 이유

재작업을 직접 측정하며 해결 품질을 보여주는 주요 지표입니다. 횟수가 많으면 최초 조치가 효과적이지 않았을 가능성이 있습니다.

확보 방법

일반적으로 Service Request 객체의 카운터 필드이며, 상태가 특정 조건에 맞게 변경될 때 비즈니스 규칙에 따라 값이 증가합니다. 필드명은 'ReopenCounter'일 수 있습니다.

예시
0123
재작업 여부
IsRework
서비스 요청에 재작업 활동이 있었는지 나타내는 불리언 플래그입니다.
설명

서비스 요청이 해결된 후 다시 열리거나 특정 활동이 반복되는 등 재작업 징후가 있으면 이 계산 플래그가 true로 설정됩니다. '서비스 요청 재작업률' KPI를 쉽게 계산하고 '재작업 및 재할당 흐름'과 같은 대시보드에서 비효율적인 프로세스 사례를 필터링할 수 있습니다.

중요한 이유

추가로 계획되지 않은 작업이 필요한 요청의 규모를 쉽게 파악해 품질과 효율성 문제를 확인할 수 있습니다.

확보 방법

데이터를 바탕으로 산출합니다. 'ReopenCount' 값이 0보다 큰지 확인하거나, '상담원에게 할당됨' 이벤트가 여러 번 발생하는 것과 같은 특정 활동 순서를 탐지해 판정할 수 있습니다.

예시
truefalse
접수 채널
Channel
서비스 요청을 제출한 방법 또는 채널입니다.
설명

접수 채널은 셀프서비스 포털, 이메일, 전화 또는 다른 시스템의 자동 생성 등 서비스 요청이 생성된 경로를 나타냅니다. 채널별 요청 건수와 해결 시간을 분석하면 효율적인 채널과 프로세스 개선 또는 사용자 교육이 필요한 채널을 파악할 수 있습니다.

중요한 이유

사용자 행동과 채널별 효율성을 파악해 서비스 제공 전략과 자동화 기회를 검토하는 데 도움이 됩니다.

확보 방법

Service Request 객체의 'Source' 또는 'CreatedBy' 유형 필드에 저장되는 경우가 많습니다.

예시
셀프서비스이메일전화직접 입력
할당 횟수
AssignmentCount
서비스 요청이 할당 또는 재할당된 총 횟수입니다.
설명

이 계산 지표는 서비스 요청별 할당 관련 활동(예: '팀에 할당됨', '상담원에게 할당됨')의 횟수를 셉니다. 흔히 '티켓 핑퐁'이라고 부르는 잦은 재할당은 라우팅 비효율, 최초 접점 해결 실패 또는 팀별 책임 불명확을 나타낼 수 있습니다. '요청당 평균 재할당 횟수' KPI를 계산하는 데 필요한 속성입니다.

중요한 이유

비효율적인 인계와 라우팅 문제를 수치로 파악할 수 있습니다. 횟수가 많으면 해결 시간이 길어지고 사용자의 불만이 커질 가능성이 높습니다.

확보 방법

데이터 준비 단계에서 고유한 ServiceRequestID별 할당 관련 활동의 발생 횟수를 세어 계산합니다.

예시
12345
해결 범주
ResolutionCategory
서비스 요청의 해결 방법을 분류한 항목입니다.
설명

해결 범주는 서비스 요청이 최종적으로 어떤 방식으로 해결되었는지 체계적으로 분류합니다. 일반적으로 범주와 하위 범주로 구성되며, 근본 원인 분석과 추세 보고에 활용됩니다. 반복되는 문제나 자주 수행되는 이행 작업을 파악해 서비스를 개선하거나 지식 문서를 작성할 수 있습니다.

중요한 이유

해결 방식의 특성을 파악해 자주 발생하는 문제, 서비스 개선 기회, 자동화 후보를 찾을 수 있습니다.

확보 방법

일반적으로 해결 시 입력하는 분류 필드에 저장됩니다. 예를 들어 'ResolutionCategory' 또는 사용자 지정 종료 코드 필드가 있습니다.

예시
사용자 교육 필요소프트웨어 배포 완료하드웨어 수리 완료액세스 권한 부여
필수 권장 선택 사항

서비스 요청 관리 활동

정확한 프로세스 발견과 분석을 위해 이벤트 로그에 기록해야 할 주요 단계와 이정표입니다.
5 권장 9 선택 사항
활동 설명
담당자에게 요청 배정
특정 담당자가 서비스 요청을 맡습니다. 개인 담당자를 지정하는 'Owner' 필드에 처음으로 값이 입력되거나 값이 변경될 때 이 활동을 추론할 수 있습니다.
중요한 이유

이 시점에 초기 대기 또는 대기열 시간이 끝납니다. 이 활동 전까지 걸린 시간을 측정하면 리소스 배분 문제를 파악하고 Agent Workload 대시보드를 지원할 수 있습니다.

확보 방법

Service Request 레코드의 'Owner' 필드에 값이 입력되거나 변경된 내역을 감사 이력에서 확인합니다.

기록

레코드 생성 또는 팀 배정 후 'Owner' 필드에 담당자 이름이 처음 입력된 시점의 타임스탬프입니다.

이벤트 유형 inferred
서비스 요청 생성
새 요청이 정식으로 제출되어 Ivanti에 기록되면 서비스 요청 수명 주기가 시작됩니다. Service Request 비즈니스 객체에 새 레코드가 생성되고 고유한 Service Request ID가 발급될 때 이 이벤트를 기록합니다.
중요한 이유

이 이벤트는 프로세스의 주요 시작점입니다. 여기서 해결까지 걸린 시간을 분석하면 전체 처리 시간과 프로세스 효율을 측정할 수 있습니다.

확보 방법

Service Request 레코드의 생성 타임스탬프에서 확인합니다(예: ServiceReq 비즈니스 객체의 CreatedDateTime 필드).

기록

ServiceReq 테이블에서 레코드 생성 타임스탬프로 식별하는 생성 이벤트입니다.

이벤트 유형 explicit
서비스 요청 종료
서비스 요청이 공식적으로 종료되어 추가 조치를 할 수 없는 상태입니다. 'Resolved' 상태로 일정 기간이 지나면 자동으로 종료되는 경우가 많으며, 수명 주기의 최종 단계입니다.
중요한 이유

이 활동은 프로세스의 최종 종료 시점입니다. 'Resolved'에서 'Closed'까지 걸린 시간을 살펴보면 확인 절차나 자동화된 시스템 처리의 지연을 파악할 수 있습니다.

확보 방법

Service Request 레코드의 'Status' 필드가 'Closed'로 변경된 내역과 해당 타임스탬프를 확인합니다.

기록

감사 이력에서 'Status' 필드가 'Closed'로 업데이트된 내역을 확인합니다.

이벤트 유형 inferred
서비스 요청 해결
서비스 요청이 해결되고 사용자에게 해결책이 제공된 상태입니다. 일반적으로 상태가 'Resolved'로 변경될 때 기록하는 주요 시점이며, 이때 SLA 측정이 종료되는 경우가 많습니다.
중요한 이유

해결 시간과 SLA 준수 여부를 측정하는 중요한 종료 지점입니다. 생성부터 이 활동까지 걸린 시간은 프로세스 성과를 나타내는 주요 KPI입니다.

확보 방법

Service Request 레코드의 'Status' 필드가 'Resolved'로 변경된 내역과 해당 타임스탬프를 확인합니다.

기록

감사 이력에서 'Status' 필드가 'Resolved'로 업데이트된 내역을 확인합니다.

이벤트 유형 inferred
팀에 요청 배정
서비스 요청이 처리를 위해 특정 지원팀에 배정됩니다. Service Request 레코드의 'OwnerTeam' 필드에 값이 입력되거나 해당 값이 변경되었는지 확인합니다.
중요한 이유

이 이벤트는 팀별 성과와 업무량 배분, 팀 간 인계 시간을 분석하는 데 중요합니다. 프로세스에서 어느 팀이 병목인지 파악하는 데 도움이 됩니다.

확보 방법

Service Request의 감사 이력이나 저널에서 'OwnerTeam' 필드의 변경 내역을 추적합니다.

기록

'OwnerTeam' 필드 업데이트 이벤트이며, 일반적으로 감사 추적에 기록됩니다.

이벤트 유형 explicit
사용자가 정보 제공
요청자가 필요한 정보를 제공해 담당자가 업무를 재개할 수 있습니다. 요청 상태가 'Waiting for Customer'에서 처리 중 상태로 바뀔 때 이 이벤트를 기록합니다.
중요한 이유

이 이벤트로 정보 요청이 완료됩니다. 정보를 요청한 시점부터 받은 시점까지의 시간은 프로세스 지연과 재작업 경로를 분석할 때 중요한 요소입니다.

확보 방법

Service Request의 'Status' 필드가 'Waiting for Customer'에서 'Active' 또는 'In Progress'와 같은 처리 중 상태로 변경된 경우를 확인합니다.

기록

사용자 대기 상태에서 처리 중 상태로 변경된 내역을 확인합니다.

이벤트 유형 inferred
사용자에게 정보 요청
배정된 담당자가 요청 처리를 계속하기 위해 요청자에게 추가 정보를 요청합니다. 요청 상태가 'Waiting for Customer'와 같은 값으로 변경될 때 이 이벤트를 기록합니다.
중요한 이유

이 활동은 최초 정보가 부족해 발생한 지연을 보여줍니다. 빈도와 소요 시간을 추적하면 Information Request Impact Analysis를 수행하고 프로세스 개선 지점을 찾는 데 도움이 됩니다.

확보 방법

Service Request 레코드의 상태가 'Waiting for Customer' 또는 'Pending'과 같은 값으로 변경된 경우를 확인합니다.

기록

'Status' 필드가 지정된 사용자 대기 상태로 변경되었는지 확인합니다.

이벤트 유형 inferred
서비스 요청 재개
문제가 계속되거나 해결책이 만족스럽지 않아 이전에 해결된 서비스 요청이 다시 활성화되었습니다. 상태가 'Resolved'에서 'Active' 또는 'Assigned'와 같은 처리 중 상태로 바뀔 때 확인합니다.
중요한 이유

이 활동은 재작업과 최초 해결 품질 저하를 직접적으로 보여줍니다. 재개 이벤트를 분석하면 프로세스의 취약점을 찾아 Service Request Rework Rate KPI를 개선할 수 있습니다.

확보 방법

감사 이력에서 'Status' 필드가 'Resolved' 또는 'Closed'에서 처리 중 상태로 변경된 경우를 확인합니다.

기록

종료 상태('Resolved', 'Closed')에서 진행 중 상태('Active', 'Assigned')로 변경된 경우입니다.

이벤트 유형 inferred
서비스 요청 처리 완료
담당자나 시스템이 서비스 요청 처리에 필요한 모든 작업을 완료했습니다. 상태가 'Fulfilled'로 변경될 때 확인하며, 이 상태는 최종 'Resolved' 상태보다 먼저 나타나는 경우가 많습니다.
중요한 이유

이 시점은 기술적 또는 절차적 작업이 완료되었음을 나타냅니다. 최종 확인과 종료 전까지 실제 처리에 걸린 시간을 측정하는 기준입니다.

확보 방법

Service Request 레코드의 'Status' 필드가 'Fulfilled'로 변경된 경우를 확인합니다.

기록

레코드 이력에서 'Status' 필드가 'Fulfilled'로 변경된 내역을 확인합니다.

이벤트 유형 inferred
서비스 요청 취소
해결되기 전에 사용자나 담당자가 서비스 요청을 취소했습니다. 상태가 'Cancelled' 또는 'Withdrawn'으로 변경될 때 확인하는 대체 종료 상태입니다.
중요한 이유

이는 표준 절차와 다른 방식으로 프로세스가 종료된 경우입니다. 요청이 취소된 이유를 분석하면 요청 프로세스 자체의 문제나 사용자 요구의 변화를 파악할 수 있습니다.

확보 방법

Service Request 레코드의 'Status' 필드가 'Cancelled'로 변경된 경우를 확인합니다.

기록

감사 이력에서 'Status' 필드가 'Cancelled'로 업데이트된 내역을 확인합니다.

이벤트 유형 inferred
외부 공급업체 참여
서비스 요청 처리가 외부 공급업체나 제3자에게 전달됩니다. 일반적으로 상태가 'Waiting for 3rd Party' 또는 이와 유사한 값으로 변경될 때 확인합니다.
중요한 이유

이 활동은 공급업체 성과와 전체 주기 시간에 미치는 영향을 측정하는 데 필요합니다. 공급업체 관련 지연을 분석하고 외부 공급업체 활동 소요 시간 대시보드를 지원합니다.

확보 방법

Service Request 레코드의 상태가 'Waiting for 3rd Party' 또는 'Pending Vendor'와 같은 값으로 변경된 경우를 확인합니다.

기록

'Status' 필드가 지정된 공급업체 대기 상태로 변경되었는지 확인합니다.

이벤트 유형 inferred
요청 승인
서비스 요청에 필요한 승인이 모두 완료되어 처리를 진행할 수 있는 상태입니다. 승인 워크플로가 성공적으로 끝나 요청 상태가 변경될 때 이 이벤트를 기록합니다.
중요한 이유

이 활동은 승인 단계가 끝나고 요청 처리가 시작되는 주요 시점을 나타냅니다. 승인 프로세스 자체의 효율을 측정할 수 있습니다.

확보 방법

'Waiting for Approval'에서 'Approved' 또는 'Fulfilled'로 상태가 변경된 경우를 확인합니다. FRS_Approval 비즈니스 객체에 명시적인 이벤트로 기록될 수도 있습니다.

기록

Service Request 레코드의 'Status' 필드가 승인 대기 상태에서 처리 중 상태로 변경된 경우입니다.

이벤트 유형 inferred
요청 승인 제출
서비스 요청을 처리하기 전에 필요한 승인을 받도록 제출한 상태입니다. 일반적으로 요청 상태가 'Submitted' 또는 'Pending Approval'로 바뀌면 확인할 수 있으며, 이때 승인 워크플로가 시작되는 경우가 많습니다.
중요한 이유

이 활동을 추적하면 승인 단계의 지연을 파악할 수 있습니다. 이 단계에서 오래 대기하면 전체 해결 시간과 사용자 만족도에 영향을 주는 큰 병목이 될 수 있습니다.

확보 방법

Service Request 레코드의 상태가 'Submitted' 또는 'Waiting for Approval'과 같은 값으로 바뀌었는지 확인합니다. FRS_Approval 또는 FRS_ApprovalVoteTracking 비즈니스 객체에서 데이터를 가져올 수도 있습니다.

기록

Service Request 레코드의 'Status' 필드가 승인 대기 상태로 변경된 경우입니다.

이벤트 유형 inferred
우선순위 변경
서비스 요청이 처음 생성된 후 우선순위가 변경되었습니다. 필드별 변경 내역이 기록된 감사 로그나 이력에서 확인합니다.
중요한 이유

우선순위 변경을 추적하면 Prioritization Effectiveness Overview를 확인하는 데 도움이 됩니다. 에스컬레이션이 적절히 처리되는지, 최초 우선순위가 정확했는지 파악할 수 있습니다.

확보 방법

Service Request 레코드의 감사 이력에 명시적으로 기록된 이벤트입니다. 이 이력에는 'Priority' 필드의 변경 내역이 포함됩니다.

기록

시스템 감사 추적에 기록된 'Priority' 필드 업데이트 이벤트입니다.

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

데이터 추출 가이드

Ivanti Service Manager에서 데이터를 가져오는 방법

시작할 준비가 되셨나요?

상세한 데이터 템플릿을 활용해 서비스 요청 관리 프로세스를 더 깊이 이해하세요. 지금 운영을 최적화해 보세요.

지금 서비스 요청 관리를 최적화하세요

느린 요청 처리를 개선하고 사용자 불편을 줄여 자동화율 70%를 달성하세요.

무료 체험 시작하기

신용카드 없이 몇 분 만에 설정할 수 있습니다.