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

서비스 요청 ID는 전체 처리 기간 동안 각 서비스 요청을 고유하게 식별하는 기본 키입니다. 케이스 식별자 역할을 하며 관련 활동, 상태 변경, 속성을 하나의 일관된 프로세스 인스턴스로 연결합니다.

process mining 분석에서 이 ID는 각 요청의 전체 흐름을 재구성하는 데 필수적입니다. 모든 이벤트를 공통 CaseId로 묶으면 분석가는 프로세스 흐름을 시각화하고 케이스 처리 시간을 계산하며 요청별 처리 방식의 차이를 파악할 수 있습니다. 서비스 요청 관리 프로세스를 분석할 때 기준이 되는 식별자입니다.

서비스 요청의 모든 이벤트를 연결해 전체 프로세스 흐름을 확인하는 데 필요한 ID입니다.

일반적으로 서비스 요청의 헤더나 기본 트랜잭션 테이블에서 찾을 수 있습니다.

시작 시간은 특정 활동이 시작된 날짜와 시각을 정확히 기록합니다. 이 타임스탬프는 이벤트를 시간순으로 정렬하고 활동별 소요 시간과 전체 케이스 처리 기간을 계산하는 데 중요합니다. 정확한 이벤트 로그를 구성하려면 프로세스의 각 활동에 시작 시간이 있어야 합니다.

프로세스 분석에서는 시작 시간을 사용해 처리 시간, 활동 간 대기 시간, 활동별 작업 시간과 같은 KPI를 계산합니다. 시간에 따른 프로세스 흐름을 확인해 지연을 파악하고 시간이 가장 많이 걸리는 단계를 찾을 수 있습니다. 성과 분석을 위해서는 정확한 타임스탬프가 필수입니다.

이 타임스탬프는 이벤트를 올바른 순서로 정렬하고 처리 시간이나 병목 등 시간 관련 지표를 계산하는 데 중요합니다.

이벤트 로그나 감사 추적 테이블에서 찾을 수 있으며, 각 활동 레코드의 '생성일' 또는 '이벤트 타임스탬프'로 기록되는 경우가 많습니다.

활동 속성은 서비스 요청에 대해 수행된 특정 단계나 작업을 나타냅니다. '요청 생성', '요청 배정', '작업 진행 중', '요청 종료'와 같은 활동이 순서대로 이어져 프로세스를 구성합니다. 각 활동은 서비스 요청 처리 과정에서 특정 시점을 나타냅니다.

활동 분석은 process mining의 핵심입니다. 실제 프로세스 흐름을 발견하고 시각화할 수 있습니다. 활동의 순서와 빈도를 살펴보면 자주 발생하는 경로, 표준 프로세스에서 벗어난 흐름, 요청이 지연되는 병목, 불필요하게 단계를 반복하는 재작업을 파악할 수 있습니다.

프로세스의 단계를 정의하므로 실제 흐름과 병목, 편차를 파악할 수 있습니다.

서비스 요청과 관련된 상태 변경 로그, 이벤트 테이블 또는 감사 추적에서 가져오는 경우가 많습니다.

원천 시스템 속성은 데이터가 추출된 IT Service Management(ITSM) 플랫폼이나 기타 애플리케이션의 이름을 나타냅니다. 여러 시스템을 사용하는 환경에서는 이 필드로 데이터 출처를 구분하고 데이터 계보를 명확히 할 수 있습니다.

대부분의 프로세스 흐름 분석에 직접 사용되지는 않지만, 데이터 거버넌스와 검증, 문제 해결에 중요합니다. 여러 출처의 데이터를 결합할 때 이 속성으로 시스템별 프로세스 흐름을 나누어 보면 플랫폼 간 프로세스 실행 방식이나 데이터 품질의 차이를 확인할 수 있습니다.

데이터의 출처를 명확히 해 데이터 거버넌스와 문제 해결을 지원하며, 여러 시스템을 연동한 환경에서 특히 유용합니다.

이 값은 일반적으로 데이터 추출(ETL) 과정에서 추가하며, 원천 시스템에 기본으로 포함된 필드는 아닙니다.

최종 데이터 업데이트는 가장 최근에 데이터를 추출하거나 새로 고친 시점을 나타냅니다. 분석 중인 데이터가 얼마나 최신인지 알려 주므로, 분석 결과가 현재 상태를 반영하는지 과거 시점의 스냅샷을 반영하는지 판단할 수 있습니다.

이 속성은 운영 모니터링과 보고에 중요하며, 분석 결과의 최신성을 파악하는 데 필요한 맥락을 제공합니다. 데이터의 최신성을 확인해 결과를 신뢰하고 근거 있는 의사결정을 내릴 수 있습니다. 예를 들어 일주일 전에 업데이트된 데이터를 보여 주는 대시보드는 한 시간 전에 업데이트된 대시보드와 다르게 해석해야 합니다.

데이터의 최신성을 나타내며, 분석의 적시성과 최신 정보에 기반한 결과를 보장하는 데 중요합니다.

일반적으로 데이터 추출(ETL) 과정에서 생성하고 저장하는 메타데이터 필드입니다.

SLA 기한은 요청에 적용되는 서비스 수준 계약을 기준으로 계산한 목표 시점입니다. 요청의 우선순위와 유형, 생성 시점 등의 요소를 반영해 예상 해결 기한을 정합니다.

이 속성은 SLA 준수 분석의 기준입니다. 실제 해결 시점과 SLA 기한을 비교하면 요청이 기한 내에 해결되었는지, SLA를 위반했는지 확인할 수 있습니다. 서비스 품질을 측정하는 주요 KPI이며, 지연과 SLA 위반을 일으키는 반복적인 문제를 찾는 데 사용됩니다.

성과 측정의 기준으로, SLA 준수율을 계산하고 기한을 넘긴 요청을 파악하는 데 사용됩니다.

적용된 SLA 정책에 따라 계산되는 서비스 요청 레코드의 필드인 경우가 많습니다.

담당 팀은 서비스 요청 처리를 책임지는 지원 그룹을 의미합니다. 필요한 전문성에 따라 요청이 1차 헬프데스크, 네트워크 팀, 소프트웨어 개발팀 등 여러 팀으로 전달될 수 있습니다.

팀 간 인계 분석은 서비스 관리 process mining의 주요 영역입니다. 이 속성을 사용하면 팀 간 요청 이관을 시각화해 소통 공백이나 지연을 찾을 수 있습니다. 또한 팀별 효율성, 요청량, 추가 에스컬레이션 없이 요청을 해결하는 능력을 비교해 성과를 평가할 수 있습니다.

팀 간 인계를 분석하고 이관 지연을 파악하며 팀별 성과를 비교하는 데 중요합니다.

서비스 요청 레코드의 표준 필드입니다. 이 필드의 변경 사항은 감사 로그에 기록됩니다.

담당자는 특정 시점에 서비스 요청 처리를 책임지는 사람입니다. 요청 처리 기간 동안 담당자가 바뀔 수 있습니다.

이 속성은 성과와 업무량 분석에 중요합니다. 담당자별 평균 해결 시간과 처리 건수를 측정하고 비교할 수 있습니다. 담당자 간 재배정도 분석할 수 있으며, 이를 통해 초기 분류, 담당자 전문성 또는 업무량 배분에 문제가 있는지 파악할 수 있습니다.

담당자별 성과와 업무량 분포, 담당자 간 재배정 빈도를 분석할 수 있습니다.

서비스 요청 레코드에서 확인할 수 있습니다. 이 필드의 변경 사항은 감사 로그나 이력 테이블에 기록되는 경우가 많습니다.

서비스 유형은 서비스 요청의 성격을 분류합니다. 새 하드웨어나 소프트웨어 접근 권한 요청부터 일반 문의와 기술 지원까지 다양한 유형이 포함될 수 있습니다. 이 분류를 통해 요청을 적절한 팀으로 전달하고 서비스별 수요를 파악할 수 있습니다.

프로세스 분석에서는 서비스 유형을 기준으로 데이터를 나누어 살펴볼 수 있습니다. 서비스 유형별로 프로세스 맵을 필터링하면 요청 유형에 따라 처리 흐름이 크게 다르거나 처리 시간이 길고 재작업이 잦은 경우를 찾을 수 있습니다. 이를 바탕으로 특정 서비스 범주에 맞춘 프로세스 개선을 추진할 수 있습니다.

요청 범주별 프로세스를 필터링하고 비교해 유형별 병목이나 비효율을 파악할 수 있습니다.

서비스 요청 레코드의 표준 필드이며, 서비스 카탈로그와 연결되는 경우가 많습니다.

요청 상태는 처리 과정의 특정 시점에 서비스 요청이 어떤 상태인지 나타냅니다. 일반적인 상태에는 신규, 진행 중, 대기, 해결, 종료가 있습니다. 이 속성을 통해 전체 프로세스에서 요청이 어느 단계에 있는지 확인할 수 있습니다.

요청 상태를 분석하면 프로세스 흐름과 상태 전환을 파악할 수 있습니다. 상태별로 케이스를 필터링하고 특정 상태에 머물러 있는 요청을 찾으며 각 상태에서 보낸 시간을 측정할 수 있습니다. 예를 들어 요청이 '대기' 상태에 머무는 시간을 분석하면 사용자나 외부 팀의 정보를 기다리느라 발생하는 지연을 확인할 수 있습니다.

요청이 각 상태에 머무는 시간을 분석해 프로세스의 병목이나 지연을 파악할 수 있습니다.

서비스 요청 기본 테이블이나 상태 이력 로그에서 확인할 수 있습니다.

요청 우선순위는 지원팀이 처리 순서를 정하는 데 사용하는 분류입니다. 일반적으로 요청이 비즈니스에 미치는 영향과 긴급성을 함께 고려해 정합니다. 우선순위는 낮음, 보통, 높음, 긴급 등으로 구분할 수 있습니다.

이 속성은 성과 분석과 리소스 배분에 중요합니다. 우선순위별 처리 시간과 SLA 준수 여부를 비교해 높은 우선순위의 요청이 적절히 처리되는지 확인할 수 있습니다. 낮은 우선순위의 요청이 방치되는지, 지원팀이 우선순위 기준을 제대로 따르는지도 파악할 수 있습니다.

요청이 비즈니스 중요도에 맞게 처리되는지 분석하고 우선순위가 해결 시간에 미치는 영향을 파악하는 데 필요합니다.

일반적으로 서비스 요청 기본 레코드에 포함된 표준 필드입니다.

이 불리언 속성은 서비스 요청이 정해진 서비스 수준 계약을 준수했는지 나타냅니다. 요청이 'SlaDueDate' 이후에 해결되었으면 true, 그렇지 않으면 false입니다.

이 속성을 사용하면 SLA 준수 보고와 분석이 간편해집니다. 매번 날짜를 비교하는 대신 간단한 플래그로 데이터를 필터링하고 집계할 수 있습니다. SLA 성과를 보여 주는 대시보드의 주요 지표로, 서비스 목표를 충족하지 못한 요청의 건수와 비율을 빠르게 파악할 수 있습니다.

SLA 성과를 명확하고 간단한 플래그로 표시해 기한을 넘긴 요청을 쉽게 필터링하고 보고할 수 있습니다.

데이터 변환 과정에서 최종 해결 타임스탬프와 'SlaDueDate' 필드를 비교해 계산하는 파생 속성입니다.

이 속성은 서비스 요청을 시작한 사람의 부서나 사업 부문을 식별해 요청에 조직 정보를 더합니다.

부서별 요청을 분석하면 부서별 요구와 추세, 문제를 파악할 수 있습니다. 예를 들어 재무 부서에서 특정 유형의 요청이 많이 발생한다면 맞춤형 교육이나 시스템 개선이 필요할 수 있습니다. 또한 부서별 비용 배분 보고와 조직 전반의 IT 서비스 수요 파악에도 활용할 수 있습니다.

조직 정보를 제공해 사업 부문별 요청 유형과 서비스 수요를 분석할 수 있습니다.

일반적으로 직원 디렉터리나 ITSM 시스템에 등록된 요청자의 사용자 프로필에서 가져옵니다.

재배정 횟수는 서비스 요청이 한 담당자나 팀에서 다른 담당자나 팀으로 이관된 횟수를 나타내는 지표입니다. 횟수가 많으면 최초 배정 오류, 담당자 지식 부족, 불명확한 프로세스 책임 등의 문제가 있을 수 있습니다.

이 지표는 프로세스 비효율을 보여 주는 주요 지표입니다. process mining에서 요청이 여러 담당자나 팀 사이를 오가는 정도를 수치로 확인할 수 있습니다. 재배정 횟수가 많은 케이스를 분석하면 초기 분류 절차 개선, 담당자 교육 강화, 팀별 책임 조정 등 요청을 처음부터 적절한 곳으로 전달하기 위한 개선점을 찾을 수 있습니다.

프로세스 비효율을 파악하는 주요 지표입니다. 재배정 횟수가 많으면 해결 시간이 길어지고 사용자 만족도가 낮아지는 경우가 많습니다.

특정 'CaseId'에서 'AssignedAgent' 또는 'AssignedTeam' 필드가 변경된 횟수를 세어 계산하는 지표입니다.

접수 채널은 셀프서비스 포털, 이메일, 전화 또는 API 등 서비스 요청이 생성된 경로를 나타냅니다. 채널에 따라 처리 방식이나 사용자의 기대가 다를 수 있습니다.

접수 채널별로 프로세스를 분석하면 유용한 정보를 얻을 수 있습니다. 예를 들어 셀프서비스 포털로 접수된 요청은 형식이 잘 갖춰져 있어 이메일 요청보다 빠르게 해결될 수 있습니다. 이메일 요청은 데이터를 수동으로 입력해야 할 수 있습니다. 이 분석을 통해 효율적인 채널의 이용을 늘리거나 비효율적인 채널의 처리 방식을 개선할 수 있습니다.

접수 방법이 프로세스 효율성, 해결 시간 또는 최초 접촉 해결률에 영향을 주는지 파악할 수 있습니다.

일반적으로 서비스 요청 레코드의 표준 필드에서 확인할 수 있습니다.

종료 시간은 특정 활동이 완료된 날짜와 시각을 정확히 기록합니다. 시작 시간이 활동의 시작을 나타낸다면 종료 시간은 끝을 나타내며, 한 프로세스 단계의 소요 시간을 정의합니다. 일부 이벤트는 순간적으로 발생하므로 별도의 종료 시간이 없을 수 있습니다.

이 속성은 활동별 처리 시간을 계산하는 데 필요합니다. 종료 시간에서 시작 시간을 빼면 담당자나 시스템이 작업에 실제로 들인 시간을 측정할 수 있습니다. 이를 통해 시간이 오래 걸리는 활동과 개선 또는 자동화가 필요한 단계를 파악할 수 있습니다.

활동별 처리 시간을 계산해 프로세스에서 특히 시간이 오래 걸리는 단계를 찾을 수 있습니다.

이벤트 로그나 감사 추적 테이블에서 찾을 수 있습니다. 값이 명시적으로 제공되지 않으면 다음 활동의 시작 시간을 사용해 계산해야 할 수 있습니다.

해결 코드는 서비스 요청의 결과를 체계적으로 분류합니다. 예를 들면 '사용자가 해결', '하드웨어 교체', '소프트웨어 배포', '중복 요청' 등이 있습니다. 일반적으로 담당자가 요청을 종료할 때 입력합니다.

이 코드는 근본 원인 분석에 유용합니다. 해결 코드별 빈도를 분석하면 반복되는 문제와 일반적인 해결 방법, 지식 문서 작성이나 해결 자동화 기회를 찾을 수 있습니다. 예를 들어 '비밀번호 재설정'으로 해결된 요청이 많다면 셀프서비스 비밀번호 재설정 도구에 투자할 근거가 될 수 있습니다.

요청 해결 방식을 분류해 근본 원인을 분석하고 추세와 선제적 문제 관리가 필요한 영역을 파악할 수 있습니다.

서비스 요청을 해결하거나 종료할 때 담당자가 직접 입력하는 경우가 많은 필드입니다.