서비스 요청 관리 데이터 템플릿
서비스 요청 관리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- BMC Helix ITSM 데이터 추출 안내
서비스 요청 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
Service Request ID
ServiceRequestId
|
각 서비스 요청을 식별하는 고유 ID로, 전체 처리 과정을 추적하는 기본 키입니다. | ||
|
설명
Service Request ID는 사용자나 시스템이 제출한 개별 서비스 요청을 고유하게 식별합니다. 최초 기록부터 최종 종료까지 이어지는 모든 이벤트를 연결하는 기준이므로 각 서비스 요청의 전체 처리 과정을 분석할 수 있습니다. process mining에서 이 ID는 케이스별 활동 순서를 재구성하는 데 필요합니다. 도구가 'Request Submitted', 'Request Assigned', 'Service Request Closed'와 같은 관련 이벤트를 하나의 프로세스 인스턴스로 묶을 수 있어 모든 프로세스 분석의 기반이 됩니다.
중요한 이유
이는 기본 케이스 식별자입니다. 이 값이 없으면 서비스 요청의 전체 처리 과정을 추적할 수 없어 프로세스 탐색과 분석도 불가능합니다.
확보 방법
일반적으로 BMC Helix ITSM의 'SRM:Request' 양식에 있는 'InstanceId' 또는 'Request Number' 필드입니다.
예시
SR000010572931SR000010572932SR000010572933
|
|||
|
시작 시각
EventStartTime
|
특정 활동이나 이벤트가 시작된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성에는 활동이 시작된 정확한 날짜와 시각이 기록됩니다. 최초 제출부터 최종 종료까지 로그의 모든 이벤트에 시작 시각이 있어야 프로세스의 시간 순서를 확인할 수 있습니다. 이 타임스탬프는 시간 기반 process mining 분석에 중요합니다. 처리 시간, 활동별 소요 시간, 단계 간 대기 시간을 계산하고 SLA 준수 여부를 확인하는 데 사용됩니다. 이를 통해 병목을 찾고 시간에 따른 프로세스 성과를 분석할 수 있습니다.
중요한 이유
시작 시각은 이벤트의 시간 순서를 보여 줍니다. 프로세스 소요 시간을 계산하고 지연을 찾아 프로세스 일정을 파악하는 데 필요합니다.
확보 방법
'SRM:Request' 양식과 연결된 감사 로그나 상태 이력 테이블의 타임스탬프 필드에 해당합니다. 최초 이벤트의 경우 'Submit Date'가 이에 해당할 수 있습니다.
예시
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
활동
ActivityName
|
서비스 요청 처리 과정에서 특정 시점에 발생한 이벤트나 작업의 이름입니다. | ||
|
설명
이 속성은 'Request In Review', 'Fulfillment In Progress', 'Service Request Resolved'와 같이 서비스 요청 프로세스의 특정 단계나 상태 변경을 나타냅니다. 각 활동은 서비스 요청의 전체 처리 과정에서 발생한 하나의 이벤트에 해당합니다. 활동의 순서와 빈도를 분석하는 것이 process mining의 핵심입니다. 이를 통해 프로세스 맵을 발견하고 병목을 파악하며 프로세스 변형을 분석할 수 있습니다. 어떤 활동이 어떤 순서로 얼마나 자주 발생하는지 이해하는 것은 프로세스 개선에 중요합니다.
중요한 이유
활동은 프로세스 맵을 구성하는 기본 요소입니다. 활동을 추적하고 시각화하면 실제 업무가 어떻게 진행되는지 분석할 수 있습니다.
확보 방법
일반적으로 'SRM:Request' 양식의 'Status' 및 'Status Reason' 필드 변경이나 관련 처리 애플리케이션 로그(예: Incident, Work Order)를 바탕으로 도출합니다.
예시
요청 승인 대기요청 처리 진행 중서비스 요청 해결서비스 요청 종료
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
소스 시스템에서 이 프로세스의 데이터를 마지막으로 새로 고친 시점의 타임스탬프입니다. | ||
|
설명
이 속성은 BMC Helix ITSM에서 데이터를 가장 최근에 추출한 날짜와 시각을 나타냅니다. 분석 대상 데이터의 최신성을 파악하고 분석이 어느 기간을 다루는지 확인할 수 있습니다. 이는 모든 process mining 대시보드나 분석에 필요한 주요 메타데이터입니다. 인사이트가 거의 실시간 데이터에 기반하는지 과거 시점의 데이터에 기반하는지 확인할 수 있어 분석 결과의 타당성과 활용도를 판단하는 데 도움이 됩니다.
중요한 이유
데이터가 얼마나 최신인지 알려 주므로 현재 이용 가능한 프로세스 성과 정보를 바탕으로 의사결정을 내리는 데 필요합니다.
확보 방법
데이터 추출 및 적재 과정에서 이 타임스탬프를 생성해 추가합니다.
예시
2024-05-21T08:00:00Z
|
|||
|
소스 시스템
SourceSystem
|
데이터를 추출한 시스템을 식별합니다. | ||
|
설명
이 속성은 프로세스 데이터의 출처를 나타냅니다. 이 보기에서는 서비스 요청과 관련된 모든 이벤트가 해당 시스템에서 추출되었음을 표시하기 위해 'BMC Helix ITSM'으로 고정 설정합니다. 여러 시스템이 연동된 환경에서는 데이터 계보를 파악하고 출처에 따라 데이터를 구분하는 데 이 필드가 중요합니다. 특히 여러 플랫폼의 데이터를 병합할 때 출처를 명확히 하고 추적할 수 있습니다.
중요한 이유
데이터 출처에 대한 정보를 제공하므로 여러 시스템을 사용하는 환경에서 데이터 거버넌스, 추적성, 문제 해결에 도움이 됩니다.
확보 방법
BMC Helix ITSM 자체의 필드가 아니라 데이터 추출 및 변환 과정에서 추가하는 고정값입니다.
예시
BMC Helix ITSM
|
|||
|
배정 담당자
AssignedAgent
|
현재 서비스 요청을 처리하도록 배정된 사용자입니다. | ||
|
설명
이 속성은 특정 시점에 요청을 담당하는 IT 담당자나 지원 인력을 식별합니다. 요청 처리 과정에서 이 필드의 값이 바뀌면 업무 인계나 재배정이 있었음을 나타냅니다. 담당자별 성과와 업무량을 분석하는 데 중요한 속성입니다. 담당자별 처리 건수와 평균 해결 시간, 재배정 빈도를 추적할 수 있습니다. 이 데이터는 리소스 관리와 교육 기회 파악에 활용됩니다.
중요한 이유
배정 담당자를 추적하면 업무 인계를 분석하고 개인별 성과를 측정하며 지원 팀의 업무량 분포를 파악할 수 있습니다.
확보 방법
서비스 요청과 연결된 처리 레코드(예: Work Order, Incident)의 'Assignee' 또는 'Assigned To' 필드에 해당합니다.
예시
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
배정 팀
AssignedTeam
|
현재 서비스 요청을 담당하는 지원 그룹이나 팀입니다. | ||
|
설명
이 속성은 요청을 처리하는 기능 그룹을 나타냅니다. 예를 들어 헬프 데스크, 네트워크 팀, 데이터베이스 관리팀 등이 있습니다. 이 필드가 변경되면 팀 간에 담당 업무가 이관된 것입니다. 담당 팀별로 분석하면 팀 단위의 병목을 찾고, 팀 간 인계 과정을 분석하며, 지원 그룹별 효율성을 평가할 수 있습니다. 요청 재작업 및 재할당 대시보드와 분류 효율성 대시보드의 주요 분석 기준으로, 조직 내 업무가 어떻게 배정되는지 파악하는 데 도움이 됩니다.
중요한 이유
기능 그룹 간 프로세스 흐름을 분석해 업무 배정의 비효율을 찾고 팀별 성과를 측정할 수 있습니다.
확보 방법
서비스 요청과 연결된 이행 레코드(예: 작업 주문, 인시던트)의 'Assigned Group' 필드에 해당합니다.
예시
서비스 데스크인프라 지원애플리케이션 지원 2단계
|
|||
|
서비스 유형
ServiceType
|
사용자가 요청한 서비스의 범주나 유형입니다. | ||
|
설명
서비스 유형은 요청의 성격을 분류합니다. 예를 들어 '신규 소프트웨어 요청', '비밀번호 재설정', '신규 직원 온보딩' 등이 있습니다. 프로세스 데이터를 필터링하고 세분화하는 기본 기준입니다. 프로세스 분석에서는 이 속성을 사용해 요청 유형별 성과를 비교합니다. '어떤 서비스 유형의 해결 시간이 가장 긴가?', '어떤 유형에서 재작업이 가장 많이 발생하는가?'와 같은 질문에 답할 수 있습니다. 해결 시간 및 SLA 준수 대시보드에 필요한 기준입니다.
중요한 이유
서비스 요청을 유형별로 나누어 프로세스 흐름을 비교하고 유형별 문제를 찾으며 개선 활동을 적절히 조정할 수 있습니다.
확보 방법
일반적으로 서비스 카탈로그에서 선택한 서비스를 바탕으로 'SRM:Request' 양식의 'Title' 또는 분류 필드에서 가져옵니다.
예시
새 하드웨어 요청소프트웨어 접근 권한 요청VPN 접근 설정
|
|||
|
요청 상태
RequestStatus
|
이벤트 발생 시점의 서비스 요청 상태입니다. 예를 들어 'In Progress', 'Pending', 'Closed'가 있습니다. | ||
|
설명
이 속성은 서비스 요청의 수명 주기에서 각 시점의 상태를 기록합니다. 상태는 각 활동의 맥락을 제공하며, '활동' 속성 자체를 도출하는 기준으로 사용되기도 합니다. 상태별 분석을 통해 요청이 '고객 대기' 또는 '승인 대기'와 같은 특정 상태에 머무는 시간을 파악할 수 있습니다. 외부 의존성이나 내부 대기열로 인한 병목과 지연을 찾는 데 필요한 분석입니다. 병목 파악 대시보드에서도 이 정보를 활용합니다.
중요한 이유
요청의 현재 상태를 보여 주므로 대기 상태와 진행 중 상태에 머문 시간을 비교해 병목을 찾을 수 있습니다.
확보 방법
'SRM:Request' 양식의 'Status' 필드입니다. 과거 값은 감사 로그에서 확인할 수 있습니다.
예시
계획 수립진행 중대기 중해결됨종료됨
|
|||
|
우선순위
Priority
|
서비스 요청에 지정된 우선순위로, 업무 영향도와 긴급성을 나타냅니다. | ||
|
설명
우선순위에 따라 요청을 처리할 순서와 속도가 정해집니다. 일반적인 값은 'Critical', 'High', 'Medium', 'Low'입니다. 요청이 업무에 미치는 영향과 긴급성을 함께 고려해 지정하는 경우가 많습니다. 우선순위별 분석은 우선순위가 높은 요청이 낮은 요청보다 빠르게 처리되는지 평가하는 데 필요합니다. 해결 시간 및 SLA 준수 대시보드의 주요 분석 기준으로, 가장 시급한 업무에 리소스가 적절히 배정되는지 확인할 수 있습니다.
중요한 이유
프로세스가 업무 우선순위를 적절히 반영하고 업무 영향도가 다른 요청에 기대한 서비스 수준을 제공하는지 평가할 수 있습니다.
확보 방법
'SRM:Request' 양식의 'Priority' 필드입니다.
예시
긴급높음보통낮음
|
|||
|
종료 시각
EventEndTime
|
특정 활동이나 이벤트가 완료된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
종료 시각은 활동이 끝난 시점을 나타냅니다. ITSM 시스템의 많은 활동은 상태가 즉시 변경되지만, 일부 활동은 소요 시간을 측정할 수 있습니다. 종료 시각이 있으면 이러한 활동의 소요 시간을 정확히 계산할 수 있습니다. 분석에서는 종료 시각과 시작 시각을 함께 사용해 개별 활동의 처리 시간을 계산합니다. 이를 통해 단계 사이의 대기 시간뿐 아니라 어떤 작업에 시간이 가장 많이 드는지도 파악할 수 있습니다.
중요한 이유
활동별 처리 시간을 계산할 수 있어 비효율적인 단계를 찾고 리소스가 어디에 시간을 쓰는지 파악하는 데 중요합니다.
확보 방법
종료 시각은 계산해 도출할 수 있습니다. 같은 케이스에서 한 활동의 종료 시각은 다음 순서 활동의 시작 시각과 같은 경우가 많습니다. 마지막 활동의 경우 해결 또는 종료 타임스탬프를 사용합니다.
예시
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
|
|||
|
SLA 목표 일시
SlaTargetDate
|
서비스 수준 계약(SLA)에 따라 서비스 요청을 해결해야 하는 날짜와 시간입니다. | ||
|
설명
SLA 목표 일시는 서비스 요청 완료 기한을 나타내는 계산된 타임스탬프입니다. 요청의 우선순위와 유형 등을 고려하는 서비스 계약 규칙에 따라 결정됩니다. 이 속성은 SLA 준수 현황 대시보드의 기본 기준입니다. 실제 해결 시간과 비교해 SLA 준수 여부를 판단합니다. 최종 해결 활동의 'EventEndTime'을 목표 일시와 비교하면 서비스 약속을 지켰는지 확인할 수 있습니다.
중요한 이유
서비스 약속에 대한 성과를 측정하는 기본 기준으로, SLA 준수 모니터링과 보고에 필요합니다.
확보 방법
이 날짜는 Service Level Management(SLM) 모듈에서 계산해 저장하며, 서비스 요청에 연결된 SLM 양식에서 확인할 수 있습니다.
예시
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
|
|||
|
SLA 위반 여부
IsSlaBreached
|
서비스 요청이 SLA 목표 일시 이후에 해결되었는지 나타내는 불리언 값입니다. | ||
|
설명
서비스 요청의 최종 해결 타임스탬프가 'SLA Target Date'보다 늦으면 이 계산값은 true로 설정됩니다. 요청별 SLA 성과를 간단한 참 또는 거짓 값으로 나타냅니다. 이 속성은 SLA 준수 현황 대시보드와 SLA 준수율 KPI에 필요합니다. 전체 준수율을 쉽게 집계하고, SLA를 위반한 요청과 준수한 요청의 프로세스 특성을 비교해 SLA 미준수의 원인을 찾을 수 있습니다.
중요한 이유
타임스탬프 비교 결과를 불리언 값으로 나타내므로 SLA 성과를 간편하게 분석하고 준수율을 측정해 시각화할 수 있습니다.
확보 방법
계산 필드입니다. 계산식은 다음과 같습니다. IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false.
예시
truefalse
|
|||
|
에스컬레이션 여부
IsEscalated
|
서비스 요청이 에스컬레이션되었는지 나타내는 불리언 값입니다. | ||
|
설명
서비스 요청이 기능적 또는 계층적 에스컬레이션을 거치면 이 값은 true로 설정됩니다. 요청 진행이 예상보다 늦거나 SLA 위반이 임박했거나, 승인 또는 조치를 위해 상위 권한이 필요한 경우 에스컬레이션이 발생할 수 있습니다. 이 속성은 요청 에스컬레이션 효율성 분석 대시보드의 주요 기준입니다. 에스컬레이션된 요청의 프로세스 경로를 필터링하고 분석해 에스컬레이션이 발생한 원인, 이후 해결까지 걸린 시간, 에스컬레이션 절차의 효과를 파악할 수 있습니다.
중요한 이유
에스컬레이션이 필요한 요청만 따로 분석해 표준 프로세스의 취약점이나 복잡한 문제를 유발하는 요인을 찾을 수 있습니다.
확보 방법
일반적으로 단일 필드로 기록되지 않습니다. 감사 로그에서 에스컬레이션 관련 활동을 확인하거나, 에스컬레이션 절차에 따른 우선순위 또는 담당자 변경을 확인해 계산합니다.
예시
truefalse
|
|||
|
요청 제출 채널
SubmissionChannel
|
서비스 요청을 제출한 방법 또는 채널입니다. | ||
|
설명
이 속성은 셀프서비스 포털, 이메일, 서비스 데스크 전화, 자동화된 시스템 알림 등 서비스 요청이 접수된 경로를 기록합니다. 채널에 따라 프로세스 유형과 해결 시간이 달라질 수 있습니다. 제출 채널별로 프로세스를 분석하면 특정 접수 방식에서 발생하는 비효율이나 모범 사례를 찾을 수 있습니다. 예를 들어 셀프서비스 포털로 접수된 요청은 처음부터 정보가 정확하게 입력되어 더 빨리 해결될 수 있습니다. 반면 이메일 요청은 수동 분류 작업이 더 많이 필요할 수 있습니다.
중요한 이유
접수 방식이 프로세스 효율성, 데이터 품질, 전체 처리 시간에 미치는 영향을 파악하고 채널별 개선을 추진할 수 있습니다.
확보 방법
'SRM:Request' 양식이나 연결된 이행 티켓의 'Client Type' 또는 'Reported Source' 필드에서 확인할 수 있습니다.
예시
셀프서비스 포털이메일전화시스템 자동 생성
|
|||
|
요청자 부서
RequestorDepartment
|
요청을 제출한 사용자가 속한 사업 부서 또는 조직 단위입니다. | ||
|
설명
이 속성은 요청자의 소속 부서를 나타냅니다. 예를 들어 재무, 인사, IT 등이 있습니다. 일반적으로 시스템에 등록된 사용자 프로필에서 가져옵니다. 부서별로 프로세스를 분석하면 부서별 요구 사항과 요청 패턴을 파악하고, 맞춤형 교육이나 서비스 개선이 필요한 영역을 찾을 수 있습니다. 예를 들어 재무 부서의 요청은 대기 시간이 더 긴지 확인할 수 있습니다.
중요한 이유
사업 부서별 서비스 이용 현황과 프로세스 성과를 분석해 부서별 문제나 추세를 파악할 수 있습니다.
확보 방법
일반적으로 'SRM:Request' 양식의 'Requested For' 사용자와 연결된 사용자 프로필에서 가져옵니다.
예시
재무영업인사정보 기술
|
|||
|
인계 횟수
HandoffCount
|
서비스 요청이 담당자나 팀 간에 재할당된 총횟수입니다. | ||
|
설명
이 지표는 서비스 요청 하나에서 'AssignedAgent' 또는 'AssignedTeam'이 변경된 횟수를 계산합니다. 인계 횟수가 많으면 프로세스가 분산되어 있거나, 최초 문의에서 해결되지 않거나, 업무 배정이 비효율적일 수 있습니다. 이 속성은 요청당 평균 담당자 인계 횟수 KPI의 기준이며 요청 재작업 및 재할당 대시보드에 사용됩니다. 인계 횟수가 많은 사례를 분석하면 분류 개선, 교육 강화, 해결 절차 간소화 기회를 찾아 지연을 줄이고 고객 만족도를 높일 수 있습니다.
중요한 이유
프로세스의 분산 정도와 커뮤니케이션 부담을 측정합니다. 인계 횟수가 많으면 해결 시간이 길어지고 프로세스 효율성이 낮아지는 경우가 많습니다.
확보 방법
고유한 서비스 요청 ID별로 'AssignedAgent' 또는 'AssignedTeam' 속성의 서로 다른 값을 세어 계산합니다.
예시
0135
|
|||
|
재작업 여부
IsRework
|
서비스 요청이 이전 단계로 돌아가는 등 재작업을 거쳤는지 나타내는 불리언 값입니다. | ||
|
설명
이 값은 프로세스 흐름에서 반복이나 재작업이 발생한 서비스 요청을 식별합니다. 예를 들어 '이행 진행 중'에서 '요청 검토 중'으로 되돌아간 요청은 재작업으로 볼 수 있습니다. 구체적인 기준은 업무 프로세스의 로직에 따라 달라집니다. 이 속성은 요청 재작업 및 재할당 분석 대시보드와 요청 재작업률 KPI에 직접 활용됩니다. 재작업 빈도를 측정하고, 초기 평가 오류나 정보 누락 등 비효율의 원인을 분석할 수 있습니다.
중요한 이유
'정상 경로'에서 벗어난 사례를 표시해 프로세스 비효율을 측정하고 반복 작업의 원인을 찾을 수 있습니다.
확보 방법
이벤트 로그의 활동 순서를 바탕으로 계산하는 속성입니다. 프로세스 흐름에서 이전 단계로 되돌아가는 움직임을 감지하는 로직이 필요합니다.
예시
truefalse
|
|||
|
종료 코드
CloseCode
|
서비스 요청을 종료한 최종 결과 또는 사유를 나타내는 코드입니다. | ||
|
설명
종료 코드는 서비스 요청의 해결 결과를 표준화된 방식으로 분류합니다. 예를 들어 서비스 데스크에서 해결, 사용자가 취소, 중복 요청 등이 있습니다. 종료 코드를 분석하면 요청의 일반적인 처리 결과를 파악할 수 있습니다. 사용자가 취소한 요청이 많다면 처리 과정이 길다는 신호일 수 있고, 중복 요청이 많다면 시스템이나 커뮤니케이션에 문제가 있을 수 있습니다. 이 속성은 해결 범주 정확도 대시보드의 분석에 활용됩니다.
중요한 이유
요청 결과를 구조화된 데이터로 제공해 해결 효과와 미완료 또는 취소 사유를 분석할 수 있습니다.
확보 방법
일반적으로 서비스 요청과 연결된 이행 티켓의 'Resolution' 또는 'Closure Code' 필드에서 확인할 수 있습니다.
예시
성공적으로 해결사용자가 취소더 이상 필요하지 않음자동 해결
|
|||
|
해결 범주
ResolutionCategory
|
요청 해결에 사용한 방법의 분류입니다. | ||
|
설명
이 속성은 요청을 해결한 방법을 구조화해 분류합니다. 예를 들어 소프트웨어 수정, 사용자 교육, 데이터 수정 등이 있습니다. 단순한 종료 코드보다 해결 방법의 구체적인 내용을 보여줍니다. 해결 범주 정확도 대시보드에서 초기 서비스 유형과 비교해 분류의 일관성을 확인할 수 있습니다. 해결 범주를 분석하면 문제 유형의 추세를 파악하고 선제적인 문제 관리에 활용할 수 있습니다. 예를 들어 사용자 교육으로 해결되는 요청이 많다면 교육 필요성을 확인할 수 있습니다.
중요한 이유
해결 방법을 파악해 반복되는 문제의 추세와 선제적인 문제 관리 또는 사용자 교육 기회를 찾을 수 있습니다.
확보 방법
이 정보는 이행 티켓의 운영 및 제품 분류 필드에 포함되며, 보통 'Resolution Category'로 표시됩니다.
예시
계정 관리하드웨어 장애소프트웨어 업그레이드정보 제공 완료
|
|||
서비스 요청 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
서비스 요청 제출
|
사용자가 새 서비스 요청을 작성해 제출하는 활동입니다. SRM:Request 양식에 초기 상태(일반적으로 'Submitted')로 새 항목이 생성되면 기록됩니다. | ||
|
중요한 이유
모든 서비스 요청 케이스의 시작점입니다. 전체 처리 기간을 측정하고 요청 접수량을 분석하는 데 필요합니다.
확보 방법
SRM:Request 양식에 기록된 생성 시각과 초기 상태(예: 'Submitted')를 바탕으로 이 이벤트를 추론합니다.
기록
상태가 'Submitted'인 새 Service Request ID의 생성 시각을 SRM:Request 양식에서 확인합니다.
이벤트 유형
inferred
|
|||
|
서비스 요청 종료
|
서비스 요청이 공식 종료되어 읽기 전용 보관 상태로 전환됩니다. 해결 후 확인 기간이 지난 다음에 종료됩니다. | ||
|
중요한 이유
이 활동은 프로세스가 완전히 끝나는 시점을 나타냅니다. 'Resolved'에서 'Closed'까지 걸리는 시간을 보면 종료 절차의 비효율을 찾을 수 있습니다.
확보 방법
SRM:Request 양식의 최종 상태가 'Closed'로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Closed'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
서비스 요청 취소
|
처리가 완료되기 전에 요청자나 서비스 데스크가 서비스 요청을 철회한 상태입니다. 요청 프로세스의 종료 상태입니다. | ||
|
중요한 이유
취소 사례를 추적하면 사용자가 잘못된 요청을 제출했거나 더 이상 서비스가 필요하지 않은 경우와 같은 패턴을 파악할 수 있습니다. 이 정보는 서비스 카탈로그 개선에 활용할 수 있습니다.
확보 방법
SRM:Request 양식의 상태가 'Canceled'로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Canceled'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
서비스 요청 해결
|
서비스 요청 처리가 완료되고 해결 결과가 요청자에게 전달된 상태입니다. 최종 확인을 기다리거나 정해진 기간이 지나면 자동으로 종료됩니다. | ||
|
중요한 이유
서비스 제공 주기가 끝나는 주요 기준점입니다. 해결 시간과 SLA 준수 여부를 측정하는 기본 종료 지점으로 사용됩니다.
확보 방법
SRM:Request 양식의 상태가 'Resolved' 또는 'Completed'로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Resolved' 또는 'Completed'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
요청 배정
|
서비스 요청을 처리할 담당자나 팀이 지정된 상태입니다. 분류 단계가 끝나는 시점이기도 합니다. | ||
|
중요한 이유
이 기준점은 분류 시간을 측정하고 담당자별 업무량을 분석하는 데 중요합니다. 재배정이 잦다면 라우팅 문제나 역량 부족을 나타낼 수 있습니다.
확보 방법
SRM:Request 또는 관련 처리 애플리케이션 양식(예: WOI:WorkOrder)의 'Assigned Group' 또는 'Assignee' 필드 감사 로그에서 이 이벤트를 직접 확인할 수 있습니다.
기록
감사 로그에서 'Assignee' 필드에 처음으로 null이 아닌 값이 설정된 시점의 타임스탬프입니다.
이벤트 유형
explicit
|
|||
|
요청 처리 진행 중
|
배정된 담당자나 팀이 서비스 요청을 실제로 처리하기 시작한 상태입니다. 요청이 대기열에서 진행 중인 작업으로 넘어갔음을 나타냅니다. | ||
|
중요한 이유
요청 처리 작업이 시작되는 시점입니다. 이 단계에 걸리는 시간을 분석하면 리소스 생산성과 처리 업무의 복잡도를 파악할 수 있습니다.
확보 방법
SRM:Request 양식의 상태가 'In Progress'로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'In Progress'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
사용자에게 정보 요청
|
담당자가 서비스 요청 처리를 계속하려면 요청자에게 추가 정보가 필요합니다. 이때 요청은 일반적으로 'Pending' 상태로 전환됩니다. | ||
|
중요한 이유
이 활동은 '외부 정보 대기 시간'을 계산하고 정보 누락으로 요청 처리가 중단되는 빈도를 파악하는 데 중요합니다.
확보 방법
SRM:Request 양식의 상태가 'Pending'으로 변경되고 상태 사유가 'Customer Hold' 또는 'Awaiting Information'과 같은 경우 이를 바탕으로 추론합니다.
기록
특정 상태 사유와 함께 'Pending' 상태로 변경된 시점의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
사용자의 해결 확인
|
요청자가 서비스가 만족스럽게 제공되었고 요청이 해결되었다고 직접 확인한 상태입니다. 이 확인으로 요청이 최종 종료되는 경우가 많습니다. | ||
|
중요한 이유
고객 만족도를 보여 주고 서비스 이용을 공식적으로 마무리하는 기준입니다. 프로세스상 해결과 고객의 수락을 구분할 수 있습니다.
확보 방법
사용자가 포털이나 이메일로 확인한 경우 SRM:Request 작업 로그나 활동 메모에 이 이벤트가 기록될 수 있습니다. 별도의 상태로 기록되지 않는 경우도 있습니다.
기록
SRM:WorkInfo 작업 로그에서 사용자의 확인이나 설문 완료를 나타내는 항목을 검색합니다.
이벤트 유형
explicit
|
|||
|
요청 거부
|
승인 단계에서 서비스 요청이 거부된 상태입니다. 처리가 시작되기 전에 프로세스가 중단되는 종료 상태입니다. | ||
|
중요한 이유
거부된 요청을 분석하면 요청 사유, 자격 기준 또는 승인 정책의 문제를 파악할 수 있습니다.
확보 방법
SRM:Request 양식의 상태가 'Rejected'로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Rejected'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
요청 검토 중
|
서비스 데스크에서 서비스 요청의 유형과 우선순위를 확인하고 적절한 처리 팀을 정하기 위해 초기 검토와 분류를 진행합니다. 일반적으로 요청 레코드의 상태 변경으로 표시됩니다. | ||
|
중요한 이유
이 활동을 추적하면 분류 효율성을 측정하고 제출부터 배정까지의 지연을 파악할 수 있습니다. 이는 '평균 분류 시간' KPI를 산출하는 데 중요합니다.
확보 방법
SRM:Request 양식의 상태가 'In Review' 또는 'Planning'과 같은 값으로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'In Review'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
요청 승인 대기
|
서비스 요청이 지정된 승인자나 승인 그룹에 제출되어 처리를 시작하기 전에 결정을 기다리는 상태입니다. 비용이나 접근 권한이 관련된 요청에서 흔히 거치는 단계입니다. | ||
|
중요한 이유
이 활동을 분리해 보면 승인으로 인한 지연을 따로 분석하고 승인 소요 시간을 측정해 승인 절차의 병목을 찾을 수 있습니다.
확보 방법
SRM:Request 양식의 상태가 'Waiting Approval'과 같은 값으로 변경된 기록을 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Waiting Approval'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
요청 승인 완료
|
필수 승인자가 서비스 요청을 공식 승인해 처리 절차를 진행할 수 있는 상태입니다. 일반적으로 'Waiting for Approval' 상태 다음에 발생합니다. | ||
|
중요한 이유
승인 하위 프로세스가 끝나는 시점을 나타냅니다. 승인에 걸리는 시간과 전체 해결 시간에 미치는 영향을 추적하는 주요 기준입니다.
확보 방법
SRM:Request 양식의 상태가 'Waiting Approval'에서 'Planning' 또는 'In Progress'와 같은 다음 상태로 변경된 기록을 바탕으로 추론합니다. 승인 결정 자체는 관련 승인 양식에 기록됩니다.
기록
승인이 완료된 후 'Waiting Approval' 상태에서 다른 상태로 변경된 시점의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
요청 처리 재개
|
일반적으로 사용자가 필요한 정보를 제공한 뒤 서비스 요청이 대기 상태에서 해제됩니다. 담당자가 요청 처리를 다시 시작합니다. | ||
|
중요한 이유
대기 기간이 끝나는 시점을 나타내므로 외부 정보 대기 시간과 SLA 준수에 미치는 영향을 정확히 측정할 수 있습니다.
확보 방법
SRM:Request의 상태가 'Pending'에서 'In Progress'로 변경되면 이를 바탕으로 추론합니다.
기록
SRM:Request의 'Status' 필드가 'Pending'에서 'In Progress'로 변경된 업데이트 이벤트의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
|
해결 방안 구현 완료
|
담당자가 서비스 요청 처리에 필요한 기술 작업을 완료한 상태입니다. 공식적으로 해결 처리하기 전에 사용자 확인을 받을 수 있습니다. | ||
|
중요한 이유
기술 작업 완료와 공식 해결을 구분하면 작업 완료부터 사용자 확인까지 발생하는 지연을 파악할 수 있습니다.
확보 방법
상위 SRM:Request가 'Resolved'로 표시되기 전에 백엔드 처리 티켓(예: Work Order)의 상태가 'Completed'로 변경된 기록을 바탕으로 추론할 수 있습니다.
기록
SRM:Request와 연결된 백엔드 티켓(Work Order, Incident 등)이 완료로 표시된 시점의 타임스탬프입니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내
시작할 준비가 되셨나요?
이 템플릿으로 데이터 수집을 간소화하고 process mining을 시작하세요. 지금 서비스 요청 관리 최적화를 시작할 수 있습니다.
서비스 요청 관리 효율 개선, 지금 시작하세요
자동화율 70%를 달성하고 처리 지연을 줄여 사용자 만족도를 높이세요.
신용카드 없이 몇 분 만에 시작할 수 있습니다.