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

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

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

이 템플릿은 서비스 요청 프로세스 분석에 필요한 데이터를 체계적으로 수집하도록 돕습니다. 수집할 주요 속성과 추적할 활동을 안내하고, 시스템에서 해당 정보를 추출하는 방법도 설명합니다. 이 자료를 활용해 데이터 준비 과정을 간소화하고 운영 현황을 더 깊이 파악하세요.
  • 분석에 권장되는 주요 속성
  • 프로세스 탐색을 위해 추적할 주요 활동
  • Jira Service Management 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

서비스 요청 관리 속성

서비스 요청 관리를 종합적으로 분석하려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
5 필수 5 권장 7 선택 사항
이름 설명
서비스 요청 ID
ServiceRequestId
각 서비스 요청을 고유하게 식별하며, 관련 이벤트를 연결하는 기본 키입니다.
설명

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

process mining에서 이 ID는 케이스를 연결하는 데 필수적입니다. 각 활동, 상태 변경, 타임스탬프를 해당 요청에 정확히 연결해 일관된 프로세스 인스턴스를 구성하고 분석할 수 있습니다.

중요한 이유

이 ID는 관련 활동을 하나의 전체 프로세스 흐름으로 연결하는 기본 케이스 식별자이며, 프로세스 분석에 필요합니다.

확보 방법

Jira Service Management에서 이슈를 식별하는 'key' 필드입니다.

예시
SR-2023-001IT-45892HELP-105
시작 시각
EventTime
특정 활동이나 이벤트가 발생한 정확한 날짜와 시각입니다.
설명

시작 시각 또는 이벤트 타임스탬프는 활동이 발생한 정확한 시점을 기록합니다. 전체 프로세스의 시간 흐름을 파악하는 데 필요한 정보입니다.

이 타임스탬프를 기준으로 이벤트 순서를 정하고, 활동 간 소요 시간과 케이스의 전체 처리 시간을 계산하며, SLA와 같은 시간 기준 목표에 대한 프로세스 성과를 분석합니다. 타임스탬프가 정확하지 않으면 프로세스 흐름을 파악하거나 지연을 찾고 효율성을 측정하기 어렵습니다.

중요한 이유

이 타임스탬프는 이벤트 순서를 정하고, 소요 시간과 처리 시간을 계산하며, 프로세스 병목을 찾는 데 필요합니다.

확보 방법

Jira 이슈 변경 이력에서 각 상태 전환에 연결된 타임스탬프입니다. 이슈 생성 시각은 'created' 필드에 기록됩니다.

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

이 속성은 특정 시점에 서비스 요청에서 발생한 작업이나 상태 전환을 나타냅니다. 예를 들면 '요청 생성', '요청 할당', '해결 방안 적용', '요청 종료' 등이 있습니다.

이러한 활동의 순서와 빈도를 분석하는 것이 process mining의 기본입니다. 이를 통해 프로세스 맵을 시각화하고 병목을 찾으며 표준 워크플로에서 벗어난 사례를 파악할 수 있습니다. 이는 프로세스 효율성과 규정 준수 여부를 이해하는 데 중요합니다.

중요한 이유

프로세스의 단계를 정의하므로 프로세스 맵을 시각화하고 워크플로 패턴과 편차를 분석할 수 있습니다.

확보 방법

일반적으로 Jira 이슈의 'status' 전환 이력에서 가져옵니다. 이슈 변경 이력에서 상태 필드가 변경된 각 항목이 하나의 활동에 해당합니다.

예시
요청 분류정보 요청해결 방안 적용서비스 요청 종료
원천 시스템
SourceSystem
서비스 요청 데이터를 추출한 시스템입니다.
설명

이 속성은 데이터의 출처를 나타내며, 여기서는 Jira Service Management입니다. 단일 출처의 데이터를 분석할 때는 중요하지 않아 보일 수 있지만, 여러 시스템의 프로세스 데이터를 결합할 때는 반드시 필요합니다.

분석 시 데이터 계보를 추적하고 데이터 품질을 확인하는 데 도움이 됩니다. 여러 소프트웨어 플랫폼에 걸쳐 있거나 플랫폼 간 상호작용이 있는 프로세스를 필터링하고 비교할 수도 있습니다.

중요한 이유

데이터 출처를 식별합니다. 데이터 거버넌스를 관리하거나 여러 기업 시스템의 프로세스 데이터를 결합할 때 중요합니다.

확보 방법

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

예시
Jira Service ManagementJiraSM
최근 데이터 업데이트
LastDataUpdate
원천 시스템에서 데이터를 마지막으로 새로 고친 시각입니다.
설명

이 속성은 Jira Service Management에서 데이터를 가장 최근에 추출한 날짜와 시각을 기록합니다. 대시보드와 KPI에 포함된 데이터 및 분석 결과가 얼마나 최신인지 판단하는 데 필요한 정보입니다.

분석 결과를 바탕으로 의사결정을 내릴 때는 데이터의 시의성을 알아야 합니다. 이 타임스탬프를 통해 사용자는 실시간 정보와 이전 시점의 스냅샷 중 무엇을 보고 있는지 확인할 수 있으며, 이는 분석 결과의 활용도에 영향을 줍니다.

중요한 이유

데이터의 최신 여부를 나타내므로 최신 정보를 바탕으로 분석할 수 있습니다.

확보 방법

데이터 추출 도구나 스크립트가 실행을 마칠 때 생성하고 저장하는 메타데이터 필드입니다.

예시
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
SLA 기한
SlaDueDate
SLA에 따라 서비스 요청을 해결해야 하는 목표 날짜와 시각입니다.
설명

SLA 기한은 요청 해결 마감 시점을 나타내는 계산된 타임스탬프입니다. 요청의 우선순위와 유형, Jira Service Management에 설정된 서비스 수준 계약(SLA) 정책에 따라 결정됩니다.

이 속성은 '서비스 요청 SLA 성과' 대시보드와 'SLA 준수율' KPI를 구성하는 데 기본이 됩니다. 실제 해결 시각과 기한을 비교해 각 요청이 제때 완료되었는지, 지연되었는지, SLA 위반 위험이 있는지 판단할 수 있습니다.

중요한 이유

성과를 측정하는 기준입니다. SLA 준수 여부를 계산하고 작업 우선순위를 정하는 데 직접 활용됩니다.

확보 방법

SLA 정보는 Jira Service Management에서 관리하며 API로 확인할 수 있습니다. 동적으로 업데이트되는 사용자 지정 필드에 저장되는 경우가 많습니다.

예시
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
담당자
Assignee
현재 서비스 요청 처리를 맡은 사용자 또는 에이전트입니다.
설명

담당자는 서비스 요청의 다음 작업이나 해결을 책임지는 사람입니다. 요청이 여러 에이전트나 팀 사이에서 전달되면 수명 주기 동안 담당자가 여러 번 바뀔 수 있습니다.

이 속성은 업무량 분석, 성과 측정, 리소스 관리에 중요합니다. 에이전트별로 프로세스를 필터링하고 해결 시간을 비교하며, 병목을 일으키는 교육 필요성이나 업무량 불균형을 파악할 수 있습니다.

중요한 이유

에이전트별 업무량과 성과를 분석하고 리소스 배분을 파악하는 데 중요합니다.

확보 방법

Jira 이슈의 'assignee' 필드에 해당합니다.

예시
Alice JohnsonBob Williams미할당
요청 상태
RequestStatus
수명 주기에서 서비스 요청이 현재 어떤 상태인지 나타냅니다.
설명

이 속성은 서비스 요청의 현재 상태를 나타냅니다. 예를 들어 'Open', 'In Progress', 'Waiting for Customer', 'Resolved' 등이 있습니다. 요청이 현재 어느 단계에 있는지 보여줍니다.

활동 로그가 과거의 흐름을 보여준다면, 현재 상태는 진행 중인 업무량을 분석하고 지연된 항목을 찾는 데 유용합니다. 예를 들어 'Waiting for Vendor' 상태가 비정상적으로 오래 지속된 요청을 분석해 외부 의존성과 지연을 파악할 수 있습니다.

중요한 이유

각 케이스의 현재 상태를 보여주므로 진행 중인 업무를 분석하고 지연되거나 오래된 요청을 찾을 수 있습니다.

확보 방법

Jira 이슈의 'status' 필드입니다.

예시
접수진행 중고객 응답 대기해결됨
요청 우선순위
RequestPriority
서비스 요청에 지정된 우선순위입니다. 낮음, 보통, 높음, 긴급 등으로 구분합니다.
설명

요청 우선순위는 서비스 요청의 긴급성과 업무 영향을 나타냅니다. 이 분류에 따라 요청 처리 순서가 정해지며, 목표 해결 시간과 SLA에도 영향을 줍니다.

프로세스 분석에서는 우선순위를 기준으로 데이터를 나눠 볼 수 있습니다. 우선순위별 처리 시간과 SLA 준수 여부를 비교해 높은 우선순위의 요청이 더 빠르게 처리되고 목표를 충족하는지 확인할 수 있습니다. 이를 통해 우선순위 지정 체계가 효과적으로 운영되는지 검증할 수 있습니다.

중요한 이유

우선순위가 높은 요청이 더 신속하게 처리되고 엄격한 서비스 수준을 충족하는지 분석할 수 있습니다.

확보 방법

Jira 이슈의 'priority' 필드에 해당합니다.

예시
최고높음보통낮음
요청 유형
RequestType
서비스 요청의 분류입니다. 예를 들어 '접근 권한 요청'이나 '하드웨어 문제' 등이 있습니다.
설명

요청 유형은 서비스 요청의 성격에 따라 요청을 분류합니다. 요청 유형마다 해결 절차, SLA, 필요한 리소스가 다를 수 있으므로 분석에 기본이 되는 기준입니다.

요청 유형별로 프로세스를 분석하면 조직은 각 워크플로에 맞춰 개선할 수 있습니다. 예를 들어 '비밀번호 재설정' 요청과 '새 서버 프로비저닝' 요청의 병목은 서로 다릅니다. 이 속성은 '분류별 해결 품질'과 같은 대시보드를 구성하는 데도 중요합니다.

중요한 이유

서비스 요청 유형별로 프로세스, 업무량, 성과를 비교하는 데 필요합니다.

확보 방법

Jira의 'issuetype' 필드 또는 Jira Service Management의 사용자 지정 'Request Type' 필드에 해당하는 경우가 많습니다.

예시
새 계정 요청IT 지원 요청신규 직원 온보딩
SLA 상태
SlaState
서비스 요청이 SLA를 충족했는지, 위반했는지, 아직 진행 중인지 나타냅니다.
설명

SLA 상태는 SLA 기한 대비 성과에 따라 각 서비스 요청을 분류하는 계산 속성입니다. 가능한 값은 '준수', '위반', '진행 중' 등이며, 해결 타임스탬프를 'SlaDueDate'와 비교해 결정합니다.

이 속성은 '서비스 요청 SLA 성과' 대시보드의 기준이며, 'SLA 준수율' KPI 계산에 사용됩니다. 서비스 수준 준수 여부를 한눈에 보여주므로 보고, 계약 관리, 서비스 품질 유지에 중요합니다.

중요한 이유

SLA 성과를 명확하고 즉시 확인할 수 있습니다. 이는 서비스 품질과 계약상 의무 준수 여부를 판단하는 중요한 지표입니다.

확보 방법

데이터 변환 과정에서 계산합니다. 해결 시각이 'SlaDueDate'보다 빠르면 '준수', 그렇지 않으면 '위반'으로 표시합니다.

예시
준수위반진행 중
담당 팀
AssignedTeam
서비스 요청 처리를 맡은 팀 또는 그룹입니다.
설명

이 속성은 요청을 담당하는 팀을 나타냅니다. 일반적으로 개별 담당자보다 상위 수준의 그룹입니다. 1차 지원팀과 네트워크 운영팀의 성과를 비교하는 등 팀 단위 분석에 유용합니다.

'에이전트 업무량 및 해결 지표'와 같은 대시보드를 구성하는 데 중요한 기준입니다. 팀 단위로 성과 지표를 집계해 공정하게 비교하고, 각 팀이 전체 서비스 제공 프로세스에 어떻게 기여하는지 파악할 수 있습니다.

중요한 이유

개별 에이전트뿐 아니라 팀이나 부서 단위로 성과를 분석하고 업무량을 균형 있게 배분할 수 있습니다.

확보 방법

Jira의 사용자 지정 필드(예: 'Team')이거나 담당자의 사용자 프로필 속성에서 가져올 수 있습니다.

예시
IT 지원팀 - 1차인프라팀애플리케이션 지원팀
보고자
Reporter
서비스 요청을 처음 생성하거나 보고한 사용자입니다.
설명

보고자는 서비스 요청을 제출한 사람으로, 최종 사용자나 고객인 경우가 많습니다. 이 속성으로 프로세스를 시작한 이해관계자를 식별할 수 있습니다.

분석 시 보고자를 기준으로 사용자, 부서, 고객 그룹별 요청 패턴을 파악할 수 있습니다. '어느 부서에서 요청을 가장 많이 제출하는가?', '특정 사용자가 같은 문제를 반복해서 겪는가?'와 같은 질문에 답할 수 있습니다. 이 정보는 문제를 사전에 관리하고 사용자 교육을 개선하는 데 유용합니다.

중요한 이유

요청을 제출한 사람을 식별해 사용자, 부서, 고객별 요청량과 유형을 분석할 수 있습니다.

확보 방법

Jira 이슈의 'reporter' 필드에 해당합니다.

예시
Charles DarwinMarie CurieIsaac Newton
재개 여부
IsReopened
서비스 요청이 해결된 후 다시 열렸는지 나타내는 불리언 값입니다.
설명

계산된 이 속성은 요청의 워크플로에 '요청 재개' 활동이 포함되면 true로 설정되는 참/거짓 값입니다. 각 케이스의 활동 순서를 분석해 산출합니다.

이 값은 '서비스 요청 재개율' KPI를 계산하고 '재개된 서비스 요청 수' 대시보드를 구성하는 데 필요합니다. 재개율이 높으면 최초 해결 품질이 낮아 재작업이 발생하고 고객 만족도가 떨어질 수 있음을 나타냅니다. 이 값과 관련된 요청 유형이나 해결 결과를 분석하면 개선이 필요한 영역을 찾을 수 있습니다.

중요한 이유

재작업과 최초 해결 품질을 직접 측정합니다. 두 지표는 프로세스 효과와 고객 만족도를 판단하는 데 중요합니다.

확보 방법

데이터 변환 과정에서 케이스의 활동 순서에 'Resolved' 전환 이후 'Reopened' 전환이 있는지 확인해 계산합니다.

예시
truefalse
접수 채널
Channel
서비스 요청을 생성하는 데 사용한 방식입니다. 이메일, 포털, API 등이 있습니다.
설명

접수 채널 속성은 서비스 요청이 시스템에 들어온 경로를 나타냅니다. Jira Service Management에서 흔히 사용하는 채널은 고객 포털, 이메일, 에이전트의 직접 생성입니다.

채널별 프로세스 분석은 사용자 행동을 파악하고 서비스 제공 방식을 개선하는 데 중요합니다. 특정 채널로 접수된 요청의 해결 시간이 더 길거나 추가 확인이 더 많이 필요한지 알 수 있습니다. 이를 통해 포털 양식을 개선하거나 이메일 분석 규칙을 보완할 필요가 있는지 판단할 수 있습니다. 이 정보는 '서비스 요청 처리량 추세' 대시보드에도 활용됩니다.

중요한 이유

접수 채널이 해결 시간, 요청 내용의 명확성, 전체 프로세스 효율성에 영향을 주는지 분석할 수 있습니다.

확보 방법

Jira Service Management의 'Request channel type' 필드에서 확인할 수 있습니다. 별도의 API 접근 권한이 필요하거나 사용자 지정 필드에 저장되어 있을 수 있습니다.

예시
포털이메일API
조직
Organization
보고자가 소속된 고객사 또는 내부 부서입니다.
설명

이 속성은 보고자를 조직이나 부서별로 묶습니다. Jira Service Management에는 에이전트가 여러 고객사나 내부 팀의 요청을 관리할 수 있는 'Organizations' 기능이 내장되어 있습니다.

조직별 분석은 업무 맥락을 파악하는 데 도움이 됩니다. 어떤 고객사나 부서가 지원 리소스를 가장 많이 사용하는지, 특정 그룹에서 문제가 반복되는지, 사업 부문별로 SLA를 일관되게 준수하는지 확인할 수 있습니다.

중요한 이유

고객사 또는 내부 부서별 서비스 수요와 성과를 분석해 업무에 필요한 정보를 얻을 수 있습니다.

확보 방법

Jira Service Management에서 서비스 요청과 연결된 'Organizations' 필드의 데이터입니다.

예시
Acme Corporation재무부Global Tech Inc.
해결 결과
Resolution
해결된 서비스 요청의 최종 결과 또는 결론입니다.
설명

해결 결과 필드는 서비스 요청을 종료한 이유를 나타냅니다. 일반적인 값으로는 '완료', '처리하지 않음', '중복', '재현 불가' 등이 있습니다. 'Resolved' 또는 'Closed' 상태만으로는 알 수 없는 종료 사유를 제공합니다.

해결 결과를 분석하면 처리 결과의 품질과 특성을 파악할 수 있습니다. 예를 들어 '중복'으로 종료된 요청이 많다면 요청 제출 절차에 문제가 있을 수 있습니다. 어떤 해결 결과가 요청 재개로 이어지는지 추적하면 효과가 낮은 해결 방안을 찾을 수 있습니다.

중요한 이유

요청의 처리 결과를 파악하고, 해결 품질과 요청 종료 사유의 추세를 분석할 수 있습니다.

확보 방법

Jira 이슈의 'resolution' 필드에 해당하며, 일반적으로 이슈가 'done' 상태 범주로 전환될 때 설정됩니다.

예시
완료처리하지 않음중복수정 완료
필수 권장 선택 사항

서비스 요청 관리 활동

정확한 프로세스 탐색과 개선을 위해 이벤트 로그에 기록할 주요 단계와 마일스톤입니다.
5 권장 8 선택 사항
활동 설명
서비스 요청 생성
사용자가 포털, 이메일 또는 다른 채널을 통해 요청을 정식으로 제출하면 서비스 요청의 생애주기가 시작됩니다. Jira에서는 ‘Service Request’ 유형의 새 이슈가 생성될 때 이 이벤트가 기록되며, 생성 타임스탬프도 저장됩니다.
중요한 이유

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

확보 방법

이슈 이력 테이블에 명시적으로 기록되는 이벤트입니다. 활동 타임스탬프는 Jira 이슈의 ‘created’ 필드에 해당합니다.

기록

'issues' 테이블 또는 이력에서 이슈 생성 타임스탬프를 사용합니다.

이벤트 유형 explicit
서비스 요청 종료
서비스 요청을 최종적으로 행정 처리하는 단계입니다. 보통 'Resolved' 상태로 일정 기간이 지나면 자동으로 진행됩니다. Jira에서 이슈 수명 주기가 끝나는 시점입니다.
중요한 이유

프로세스의 최종 종료 이벤트입니다. 'Resolved'에서 'Closed'까지 걸린 시간을 분석하면 행정 처리에 드는 시간이나 자동 종료 정책의 영향을 파악할 수 있습니다.

확보 방법

이슈 이력에서 추론합니다. 타임스탬프는 'Closed' 또는 이에 준하는 최종 상태로 변경된 시각입니다.

기록

'Closed' 상태로 최종 변경된 시각을 확인합니다.

이벤트 유형 inferred
서비스 요청 해결
요청이 처리되고 해결 내용이 기록된 시점을 공식적으로 나타냅니다. Jira에서는 이슈가 처음으로 'Done' 범주의 상태에 진입할 때 'Resolution Date' 필드가 입력됩니다.
중요한 이유

프로세스의 주요 종료 시점으로, 해결 시간과 SLA 준수 여부를 계산하는 데 중요합니다. 이 시점부터 실제 작업이 종료됩니다.

확보 방법

명시적으로 기록되는 이벤트입니다. 타임스탬프는 Jira 이슈의 'Resolution Date' 필드 값이며, 이슈가 처음으로 'Done' 범주의 상태로 전환될 때 설정됩니다.

기록

Jira 이슈의 'resolutiondate' 필드를 사용합니다. 이 필드는 자동으로 입력됩니다.

이벤트 유형 explicit
요청 배정
서비스 요청이 해결을 위해 특정 상담원이나 팀에 배정될 때 발생하는 활동입니다. Jira는 ‘Assignee’ 필드의 변경을 명시적으로 추적하므로 배정 시점을 나타내는 타임스탬프를 확인할 수 있습니다.
중요한 이유

분류부터 배정까지 걸리는 시간과 상담원별 업무량 분포를 측정하는 주요 기준입니다. 대기 상태에서 실제 처리 단계로 넘어가는 시점을 나타냅니다.

확보 방법

이슈 이력에서 ‘Assignee’ 필드가 처음 설정되거나 미배정 상태에서 변경된 시점을 확인합니다.

기록

이슈 이력에서 ‘Assignee’ 필드가 처음 변경된 타임스탬프를 사용합니다.

이벤트 유형 explicit
해결 방안 제안
많은 서비스 데스크 워크플로에서 요청자에게 해결 방안을 제시하고 승인을 받는 별도 단계입니다. 이슈 상태가 ‘Pending Customer Acceptance’ 또는 ‘Awaiting Confirmation’과 같은 값으로 바뀌는 경우를 바탕으로 추정합니다.
중요한 이유

해결 방안을 제공한 뒤 고객의 응답을 기다리는 시간을 따로 측정해 내부 작업 시간과 구분할 수 있습니다.

확보 방법

이슈 이력에서 추정하며, 상태가 고객의 해결 방안 검증을 기다리는 상태로 바뀐 타임스탬프를 사용합니다.

기록

상태가 ‘Pending Customer Acceptance’ 또는 이에 해당하는 값으로 바뀐 타임스탬프를 확인합니다.

이벤트 유형 inferred
공급업체 협의 시작
서비스 요청이 외부 공급업체나 제3자에게 에스컬레이션되거나 이들의 조치가 필요한 시점을 나타냅니다. 이슈가 ‘Waiting for vendor’ 또는 ‘With Third Party’와 같은 상태로 바뀌는 경우를 바탕으로 추정합니다.
중요한 이유

공급업체 협의를 추적하면 내부 서비스 데스크가 직접 통제하기 어려운 외부 의존성과 지연을 파악할 수 있습니다.

확보 방법

이슈 이력에서 추정합니다. 이슈 상태가 지정된 ‘vendor’ 상태로 바뀐 시점의 타임스탬프를 사용합니다.

기록

'status' 필드가 'Waiting for Vendor'와 같은 값으로 변경된 타임스탬프를 찾습니다.

이벤트 유형 inferred
공급업체 협의 종료
외부 공급업체가 조치를 완료하고 서비스 요청이 내부 팀으로 돌아오는 시점을 나타냅니다. 이슈가 ‘Waiting for vendor’ 상태에서 벗어날 때를 바탕으로 추정합니다.
중요한 이유

공급업체 협의에 걸리는 시간을 측정하면 공급업체 성과를 관리하고 외부 업체가 전체 해결 시간에 미치는 영향을 파악할 수 있습니다.

확보 방법

이슈 이력에서 추정합니다. 이슈 상태가 ‘vendor’ 상태에서 ‘In Progress’ 상태로 바뀐 시점의 타임스탬프를 사용합니다.

기록

'status' 필드가 'vendor' 상태에서 'active' 상태로 변경된 타임스탬프를 찾습니다.

이벤트 유형 inferred
요청 분류
서비스 요청의 우선순위, 범주, 영향을 판단하는 초기 평가 단계입니다. 일반적으로 ‘New’에서 ‘In Progress’로 상태가 바뀌거나 전용 ‘Triaged’ 상태로 변경되는 경우를 바탕으로 추정합니다.
중요한 이유

분류까지 걸리는 시간을 분석하면 초기 요청 처리의 효율성을 평가할 수 있습니다. 이 단계의 지연은 전체 해결 시간과 SLA 준수율에 큰 영향을 줄 수 있습니다.

확보 방법

이슈 이력에서 초기 ‘New’ 또는 ‘Open’ 상태가 ‘In Progress’와 같은 진행 중 상태로 처음 바뀐 타임스탬프를 찾아 추정합니다.

기록

프로젝트 워크플로에 따라 ‘New’ 또는 이에 해당하는 초기 상태에서 처음 변경된 상태를 확인합니다.

이벤트 유형 inferred
요청 재개
이전에 해결된 서비스 요청이 다시 진행 중 상태로 돌아온 경우를 기록합니다. 해결 또는 종료 상태에서 열림 또는 진행 중 상태로 바뀌는 경우를 바탕으로 추정합니다.
중요한 이유

재개된 요청을 추적하면 해결 품질과 최초 해결률을 측정할 수 있습니다. 재개율이 높으면 해결 방안이 효과적이지 않았거나 문제가 반복된다는 뜻일 수 있습니다.

확보 방법

이슈 이력에서 ‘Resolved’ 또는 ‘Closed’ 범주의 상태가 ‘Open’ 또는 ‘In Progress’ 범주의 상태로 바뀐 경우를 찾아 추정합니다.

기록

상태 범주가 ‘Done’에서 ‘To Do’ 또는 ‘In Progress’로 바뀌었는지 확인합니다.

이벤트 유형 inferred
정보 요청
해결을 진행하기 위해 상담원이 요청자에게 추가 정보를 요청하는 시점을 나타냅니다. 일반적으로 이슈가 ‘Waiting for customer’ 또는 ‘Pending Input’과 같은 상태로 바뀌는 경우를 바탕으로 추정합니다.
중요한 이유

‘Information Requested’가 자주 반복되거나 오래 지속되면 초기 요청 내용이 불명확하거나 커뮤니케이션이 비효율적일 수 있으며, 이는 지연의 주요 원인이 됩니다.

확보 방법

이슈 이력에서 추정합니다. 이슈 상태가 ‘Waiting for customer’ 또는 이에 해당하는 상태로 바뀐 시점의 타임스탬프를 사용합니다.

기록

'status' 필드가 고객 응답을 기다리는 상태를 나타내는 값으로 바뀐 타임스탬프를 찾습니다.

이벤트 유형 inferred
정보 제공
요청자가 필요한 정보를 제공해 상담원이 업무를 재개할 수 있는 시점에 발생합니다. 요청자가 댓글을 추가하는 등의 동작으로 이슈가 ‘Waiting for customer’ 상태에서 벗어날 때를 바탕으로 추정합니다.
중요한 이유

고객에게 정보를 요청하고 답변을 받는 과정을 마무리하는 활동입니다. 정보 요청부터 수신까지 걸리는 시간은 프로세스 대기 시간의 주요 요소입니다.

확보 방법

이슈 이력에서 추정합니다. 이슈 상태가 ‘Waiting for customer’에서 ‘In Progress’ 상태로 바뀐 시점의 타임스탬프를 사용합니다.

기록

'status' 필드가 'waiting' 상태에서 'active' 상태로 변경된 타임스탬프를 찾습니다.

이벤트 유형 inferred
해결 방안 적용
상담원이 서비스 요청을 해결하는 데 필요한 조치를 수행하거나 해결 방안을 마련한 시점을 나타냅니다. 일반적으로 상태가 ‘Pending Review’ 또는 바로 ‘Resolved’로 바뀌는 경우를 바탕으로 추정합니다.
중요한 이유

핵심 해결 작업이 완료되는 시점입니다. 이 활동까지 걸리는 시간은 프로세스에서 실질적인 가치를 창출하는 주요 작업 시간을 나타내는 경우가 많습니다.

확보 방법

이슈 이력에서 추정하며, 상태가 ‘Resolved’, ‘Pending Acceptance’ 또는 이에 해당하는 종료 전 상태로 바뀐 타임스탬프를 사용합니다.

기록

'status' 필드가 작업 완료를 나타내는 값으로 변경된 타임스탬프를 찾습니다.

이벤트 유형 inferred
해결 확인
요청자가 제안된 해결 방안을 정식으로 수락하면 발생하며, 이때 ‘Resolved’ 상태로 자동 전환되는 경우가 많습니다. 일반적으로 이 상태 변경을 바탕으로 추정합니다.
중요한 이유

이 단계에서 해결 방안의 효과를 확인하고 SLA 시간을 멈춥니다. 고객이 수정 사항을 확인하는 데 걸리는 시간도 측정할 수 있습니다.

확보 방법

이슈 이력에서 추정합니다. 상태가 ‘Pending Customer Acceptance’에서 ‘Resolved’ 또는 ‘Closed’로 바뀐 시점의 타임스탬프를 사용합니다.

기록

'Pending Customer Acceptance'에서 'Resolved' 또는 'Closed' 상태로 변경된 시각을 확인합니다.

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

데이터 추출 가이드

Jira Service Management에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿으로 process mining을 시작하고 서비스 요청 관리를 개선해 보세요. 지금 운영 최적화를 시작하세요.

지금 Jira의 서비스 요청 관리 최적화

자동화율 70%를 달성하고 느린 요청 처리를 끝내세요. 지금 효율성을 높이세요!

무료 체험 시작

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