변경 관리 데이터 템플릿
변경 관리 데이터 템플릿
- 수집 권장 속성
- 정확한 프로세스 탐색을 위해 추적할 주요 활동
- ServiceNow에서 데이터를 추출하는 방법
변경 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
변경 요청 ID
ChangeRequestNumber
|
변경 요청을 식별하는 고유 값으로, 관련 이벤트를 묶는 기본 케이스 ID입니다. | ||
|
설명
변경 요청 ID는 변경 관리 프로세스 분석의 기준이 됩니다. 'CHG0030001'과 같이 각 변경 요청에 부여되는 고유 번호로, 관련 활동과 승인, 작업을 연결합니다. process mining에서는 이 속성을 사용해 개별 변경의 전체 흐름을 재구성합니다. 분석가는 생성부터 종료까지 전체 생명주기를 추적해 각 변경이 시스템에서 어떻게 진행되는지 파악할 수 있습니다. 이 ID를 기준으로 프로세스를 분석하면 주기 시간을 계산하고 재작업 반복을 찾으며 프로세스 변형을 이해할 수 있습니다.
중요한 이유
이 ID를 사용하면 변경의 전체 생명주기를 추적하고 요청별 프로세스 흐름, 소요 시간, 규정 준수 여부를 분석할 수 있습니다.
확보 방법
ServiceNow 테이블: change_request, 필드: number
예시
CHG0030001CHG0030045CHG0030112
|
|||
|
이벤트 시간
EventTime
|
특정 활동이나 이벤트가 발생한 정확한 시각입니다. | ||
|
설명
이벤트 시간은 활동이 수행되거나 상태 변경이 기록된 날짜와 시각을 나타냅니다. 이벤트를 시간순으로 정렬하고 소요 시간을 분석하는 데 필요한 속성입니다. process mining에서는 이 속성을 사용해 활동 간 주기 시간, 처리 시간, 대기 시간을 계산합니다. 변경 승인 주기 시간이나 변경 프로세스 전체 흐름처럼 성과를 분석하는 대시보드에도 필요합니다. 정확한 타임스탬프는 지연을 찾고 SLA를 기준으로 프로세스 효율을 측정하는 토대입니다.
중요한 이유
이 타임스탬프는 이벤트 순서를 정확히 정하고 주기 시간, 소요 시간, SLA 준수 여부 등 시간 기반 지표를 계산하는 데 필요합니다.
확보 방법
ServiceNow 테이블: sys_audit, 필드: sys_created_on. 각 변경이 기록된 시각을 제공합니다.
예시
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
활동 이름
ActivityName
|
변경 관리 프로세스에서 발생한 특정 이벤트나 작업의 이름입니다. | ||
|
설명
활동 이름은 변경 요청 생명주기의 개별 단계나 상태 변경을 나타냅니다. 예를 들어 '평가 대기 중인 변경', '승인 요청', '변경 구현 완료' 등이 있습니다. 이러한 활동은 발견된 프로세스 맵의 노드를 구성합니다. 활동을 분석하면 프로세스 흐름을 자세히 살펴볼 수 있습니다. 활동의 순서와 빈도를 추적해 일반적인 경로, 표준 프로세스에서 벗어난 흐름, 변경이 자주 지연되는 병목을 찾을 수 있습니다. 프로세스를 시각화하고 단계 간 전환 시간을 계산하는 데도 기본이 됩니다.
중요한 이유
프로세스 맵의 기반이 되는 속성으로, 프로세스 흐름을 시각화하고 병목과 편차를 분석할 수 있습니다.
확보 방법
'change_request' 테이블의 'state' 필드나 기타 주요 상태 필드 변경에서 가져오며, 대개 'sys_audit' 테이블에 기록됩니다.
예시
변경 승인구현 시작변경 종료변경 취소
|
|||
|
구성 항목
ConfigurationItem
|
변경 대상인 특정 IT 구성 요소, 서비스 또는 시스템입니다. | ||
|
설명
구성 항목(CI)은 구성 관리 데이터베이스(CMDB)에 등록된 자산 중 변경의 영향을 받는 항목입니다. 서버, 소프트웨어 애플리케이션, 네트워크 장치 또는 업무 서비스가 해당할 수 있습니다. 이 속성은 변경에 관한 중요한 맥락을 제공합니다. process mining에서는 변경 대상 자산 유형별로 분석을 나눌 수 있습니다. 예를 들어 '변경 테스트 소요 시간 분석' 대시보드에서 이 속성을 사용해 애플리케이션이나 시스템별 테스트 시간을 비교하고, 테스트 주기가 긴 CI를 찾을 수 있습니다.
중요한 이유
영향을 받는 애플리케이션, 서비스 또는 시스템별로 분석을 필터링해 구성 요소별 문제를 찾는 데 필요한 업무 맥락을 제공합니다.
확보 방법
ServiceNow 테이블: change_request, 필드: cmdb_ci
예시
SAP ERPOracle Database 19c이메일 서비스WebServer-01
|
|||
|
담당 그룹
AssignmentGroup
|
변경 요청을 담당하는 팀 또는 그룹입니다. | ||
|
설명
담당 그룹은 'CAB Approval', 'Network Engineering', 'Database Administrators'와 같이 변경 요청을 현재 맡고 있는 팀을 나타냅니다. 기능별 프로세스 성과를 분석하는 데 중요한 기준입니다. 이 속성으로 팀 단위 효율을 측정하고 특정 그룹의 병목을 찾으며 팀 간 인계가 원활한지 분석할 수 있습니다. '부서 간 업무 인계 효율' 및 '변경 구현 처리량' 대시보드는 팀 간 의존성으로 발생하는 지연을 찾기 위해 이 데이터를 활용합니다.
중요한 이유
팀별 성과를 분석해 그룹별 병목을 파악하고 기능 영역 간 인계 효율을 측정할 수 있습니다.
확보 방법
ServiceNow 테이블: change_request, 필드: assignment_group
예시
CAB 승인네트워크 팀서버 지원데이터베이스 관리자
|
|||
|
변경 상태
ChangeState
|
'Assess', 'Authorize', 'Implement', 'Closed' 등 변경 요청의 현재 또는 과거 상태입니다. | ||
|
설명
변경 상태 속성은 특정 시점의 변경 요청 상태를 나타냅니다. 변경 생명주기에서 현재 위치를 요약해 보여줍니다. 특정 이벤트를 나타내는 활동과 달리 상태는 해당 이벤트의 결과로 형성된 조건입니다. 분석에서는 변경 상태를 기준으로 케이스를 분류하고 결과를 파악합니다. 예를 들어 'Closed' 상태인 변경만 분석하거나, 많은 변경이 'Authorize' 상태에서 멈춘 이유를 조사할 수 있습니다. 'Failed' 상태가 있는 경우 변경 실패율과 같은 KPI 분석에도 직접 활용됩니다.
중요한 이유
변경 요청의 상태를 파악해 결과 분석, 케이스 필터링, 지연된 변경 식별에 활용할 수 있습니다.
확보 방법
ServiceNow 테이블: change_request, 필드: state
예시
평가승인일정 수립구현검토종료취소
|
|||
|
변경 유형
ChangeType
|
'Standard', 'Normal', 'Emergency'와 같은 변경 분류입니다. | ||
|
설명
변경 유형은 변경 요청의 성격, 위험도, 승인 요건에 따라 요청을 분류합니다. Standard 변경은 사전 승인되며, Normal 변경은 전체 프로세스를 따르고, Emergency 변경은 신속 처리 경로를 이용합니다. 변경 유형마다 정해진 프로세스가 다르므로 프로세스 분석의 기본 기준으로 활용됩니다. Normal 변경과 Emergency 변경의 성과를 비교하면 규정 준수와 효율에 관한 정보를 얻을 수 있습니다. '위험 평가 표준화' 대시보드에서도 유사한 변경이 일관되게 처리되는지 확인하는 데 사용합니다.
중요한 이유
변경 유형별로 승인된 프로세스 흐름과 성과 기준이 다르므로 유형별 분석에 활용할 수 있습니다.
확보 방법
ServiceNow 테이블: change_request, 필드: type
예시
표준일반긴급
|
|||
|
우선순위
Priority
|
변경 요청의 영향도와 긴급성을 기준으로 정한 우선순위입니다. | ||
|
설명
우선순위는 변경 요청의 중요도를 나타내며 처리 순서를 정하는 기준입니다. 변경의 영향도와 긴급성을 바탕으로 산정하는 경우가 많으며, 'Critical', 'High', 'Moderate', 'Low' 등의 값으로 표시됩니다. 우선순위별 분석은 우선순위가 높은 변경을 낮은 변경보다 신속하게 처리하는지 확인하는 데 필요합니다. 분석가는 '중요 변경 성과' 대시보드에서 중요도가 높은 변경의 주기 시간과 실패율을 추적할 수 있습니다. 우선순위가 낮은 변경이 높은 변경보다 더 빨리 완료된다면 리소스 배분이나 프로세스 실행에 문제가 있을 수 있습니다.
중요한 이유
가장 중요한 변경에 리소스가 적절히 배분되는지 평가하고 해당 변경의 성과를 별도로 모니터링하는 데 필요합니다.
확보 방법
ServiceNow 테이블: change_request, 필드: priority
예시
1 - 매우 높음2 - 높음3 - 보통4 - 낮음
|
|||
|
위험 수준
RiskLevel
|
'High', 'Moderate', 'Low'와 같은 변경의 평가 위험 수준입니다. | ||
|
설명
위험 수준은 변경 요청의 위험 평가 결과입니다. 변경을 구현할 때 발생할 수 있는 부정적 결과의 가능성을 수치화해 필요한 검토와 승인 수준을 정하는 데 도움이 됩니다. '위험 평가 표준화' 대시보드에서 유사한 변경에 일관된 위험 등급이 부여되는지 확인하는 데 사용합니다. 위험 수준별 프로세스 흐름을 분석하면 고위험 변경이 저위험 변경보다 엄격한 승인 및 테스트 절차를 따르는지도 확인할 수 있습니다. 이는 규정 준수 점검에 중요합니다.
중요한 이유
규정 준수 여부를 분석하고 고위험 변경이 적절한 검토와 엄격한 프로세스를 거치는지 확인하는 데 필요합니다.
확보 방법
ServiceNow 테이블: change_request, 필드: risk
예시
높음보통낮음
|
|||
|
종료 시간
EndTime
|
활동이 끝난 시각입니다. 다음 활동의 시작 시각을 기준으로 산출하는 경우가 많습니다. | ||
|
설명
종료 시간은 활동이 완료된 시점을 나타냅니다. 소스 시스템에는 이벤트 시작 시각이 기록되는 경우가 많아 종료 시간은 추론하는 경우가 많습니다. 일반적으로 같은 케이스에서 다음 활동의 타임스탬프를 종료 시간으로 계산합니다. 이 속성은 처리 시간이라고도 하는 각 활동의 소요 시간을 계산하는 데 필요합니다. 단계별 소요 시간을 파악하면 프로세스의 병목과 비효율을 찾을 수 있습니다. 케이스의 마지막 활동에서는 종료 시간이 시작 시간과 같습니다.
중요한 이유
활동 처리 시간을 계산할 수 있어 병목을 찾고 특정 프로세스 단계의 소요 시간을 측정하는 데 도움이 됩니다.
확보 방법
일반적으로 데이터 변환 과정에서 같은 CaseId의 다음 이벤트에 해당하는 StartTime을 사용해 계산합니다.
예시
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
SLA 상태
SlaState
|
변경 요청의 SLA 준수 상태입니다. 예: '정상 진행', '위험', '위반'. | ||
|
설명
SLA 상태는 변경 요청이 SLA에 정해진 시간 내에 진행되는지를 나타냅니다. 프로세스의 각 단계에서 상태를 추적할 수 있습니다. 이 속성은 서비스 수준 약정 준수 여부를 모니터링하는 데 중요합니다. '변경 SLA 성과 개요' 대시보드와 '변경 SLA 준수율' KPI의 기본 데이터로 사용됩니다. SLA가 위반된 지점과 원인을 분석하면 반복적으로 발생하는 지연을 해결하고 서비스 제공의 예측 가능성을 높일 수 있습니다.
중요한 이유
기한 준수 성과를 직접 측정해 SLA 위반을 사전에 모니터링하고 분석할 수 있으며, 이를 통해 서비스 제공을 개선합니다.
확보 방법
ServiceNow의 'task_sla' 테이블에서 변경 요청과 같은 작업의 SLA 데이터를 가져오거나, 기한 필드를 바탕으로 계산할 수 있습니다.
예시
정상 진행위험위반
|
|||
|
긴급성
Urgency
|
변경 요청을 얼마나 신속하게 처리해야 하는지를 높음, 보통, 낮음 등의 등급으로 나타냅니다. | ||
|
설명
긴급도는 변경을 얼마나 빨리 구현해야 하는지를 나타냅니다. 비즈니스 관점에서 요청의 시간적 민감도를 반영하며, 영향도와 함께 전체 우선순위를 산정하는 데 사용됩니다. 우선순위는 분석의 기본 필드이고, 긴급도는 추가 맥락을 제공합니다. 특정 변경이 긴급으로 분류된 이유와 안정성을 해치지 않으면서 프로세스가 이를 효과적으로 처리하는지 살펴볼 수 있습니다. 조직이 긴급한 요청에 대응하느라 지나치게 많은 시간을 보내는지도 확인할 수 있습니다.
중요한 이유
변경 요청의 시간적 민감도를 파악해, 프로세스가 시간에 민감한 요청을 효과적으로 처리하는지 분석할 수 있습니다.
확보 방법
ServiceNow 테이블: change_request, 필드: urgency
예시
1 - 높음2 - 보통3 - 낮음
|
|||
|
담당 사용자
AssignedToUser
|
특정 시점에 변경 요청을 담당하는 사용자입니다. | ||
|
설명
이 속성은 변경 요청 작업을 맡은 사용자를 나타냅니다. 요청이 여러 단계와 팀을 거치는 동안 담당자가 여러 차례 바뀔 수 있습니다. 사용자별로 분석하면 업무량 분배와 개인별 성과를 파악하고 교육이 필요한 부분을 찾을 수 있습니다. 담당 그룹과 함께 분석하면 사용자 간 업무 인계가 얼마나 원활한지도 확인할 수 있습니다.
중요한 이유
사용자별 업무량과 성과를 추적하고, 리소스 간 인계 지연을 분석하는 데 도움이 됩니다.
확보 방법
ServiceNow 테이블: change_request, 필드: assigned_to
예시
Beth AnglinDavid LooAbel Tuter
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
이 레코드의 데이터를 소스 시스템에서 마지막으로 새로 가져온 시각입니다. | ||
|
설명
이 속성은 데이터를 마지막으로 추출한 시각을 제공합니다. 분석 대상 데이터가 최신인지 파악하는 데 필요한 메타데이터입니다. 분석가는 이 타임스탬프로 최신 데이터인지 확인하고 데이터의 시점을 파악합니다. 진행 중인 프로세스 성과를 모니터링하는 운영 대시보드에서는 특히 중요합니다. 오래된 데이터를 바탕으로 의사 결정하지 않도록 확인할 수 있습니다.
중요한 이유
데이터의 최신 여부를 나타내므로 분석과 대시보드가 현재 상황에 맞는 정보를 기반으로 하는지 확인할 수 있습니다.
확보 방법
데이터 추출 및 변환(ETL) 과정에서 생성되는 메타데이터로, 데이터를 가져온 시각을 나타냅니다.
예시
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
소스 시스템
SourceSystem
|
데이터를 추출한 시스템입니다. 일반적으로 'ServiceNow'를 가리킵니다. | ||
|
설명
이 속성은 프로세스 데이터의 출처를 나타냅니다. 여기서는 ServiceNow가 예상되지만, 데이터 거버넌스를 위해 중요하며 여러 시스템의 데이터를 통합하는 경우에도 활용됩니다. 분석 시 데이터 계보를 명확히 하고 데이터 출처를 검증하는 데 도움이 됩니다. ITSM 도구나 통합 시스템을 여러 개 사용하는 조직에서는 이 속성으로 플랫폼별 프로세스를 필터링하고 비교할 수 있습니다.
중요한 이유
프로세스 데이터의 출처를 기록해 데이터 계보를 명확히 합니다. 데이터 거버넌스와 여러 시스템의 데이터 분석에 중요합니다.
확보 방법
일반적으로 데이터 추출 및 변환(ETL) 과정에서 추가하는 고정 값입니다.
예시
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
영향도
Impact
|
변경이 업무 운영에 미칠 수 있는 영향으로, 높음, 보통, 낮음 등의 척도로 평가합니다. | ||
|
설명
영향도는 변경 요청이 적절히 처리되지 않을 경우 업무에 미칠 수 있는 영향을 나타냅니다. 긴급성과 함께 변경의 전체 우선순위를 정하는 기준으로 사용됩니다. 영향도별 분석을 통해 중요 서비스에 영향을 주는 변경이 적절한 주의를 기울여 관리되는지 확인할 수 있습니다. '중요 변경 성과' 대시보드에서 업무 영향도가 높은 변경을 따로 살펴보고 모니터링하는 데 사용합니다. 또한 정당한 사유 없이 영향도가 높은 변경에 낮은 위험 수준이 부여되지 않았는지 확인해 위험 평가의 일관성을 점검할 수 있습니다.
중요한 이유
업무에 미칠 수 있는 영향을 기준으로 변경의 우선순위를 정하고, 영향도가 높은 변경이 적절한 주의를 기울여 관리되는지 확인하는 데 도움이 됩니다.
확보 방법
ServiceNow 테이블: change_request, 필드: impact
예시
1 - 높음2 - 보통3 - 낮음
|
|||
|
재작업 여부
IsRework
|
같은 케이스에서 이전 단계를 반복한 활동이면 true인 불리언 플래그입니다. | ||
|
설명
이 계산 속성은 재작업에 해당하는 활동을 식별합니다. 이미 완료한 단계로 되돌아가야 할 때 재작업이 발생합니다. 예를 들어 변경이 승인 후 거부되어 재평가를 위해 되돌아가는 경우입니다. 이 플래그는 프로세스 비효율을 수치화하는 데 중요합니다. '변경 재작업률' KPI와 '변경 실패 및 재작업 분석' 대시보드에 직접 활용됩니다. '재작업 여부'가 true인 활동을 필터링하면 초기 평가가 불완전했거나 요구사항이 바뀌는 등 재작업 원인을 분리해 살펴보고 낭비를 줄일 수 있습니다.
중요한 이유
반복 작업을 표시해 프로세스 비효율을 직접 수치화하고, 프로세스가 되풀이되거나 노력이 낭비되는 원인을 찾아 해결하는 데 도움을 줍니다.
확보 방법
데이터 변환 중 해당 CaseId에서 같은 활동(또는 표준 흐름상 이전 활동)이 이미 발생했는지 확인해 계산합니다.
예시
truefalse
|
|||
|
종료 코드
CloseCode
|
변경 요청을 종료할 때 결과를 나타내는 코드입니다. 예: '성공', '실패'. | ||
|
설명
종료 코드는 완료된 변경 요청의 최종 결과를 기록합니다. 변경이 성공적으로 구현되었는지, 문제가 있었는지, 아니면 롤백되었는지를 공식적으로 나타냅니다. 이 속성은 '변경 실패율' KPI를 산출하는 직접적인 입력값입니다. 종료 코드별 분포를 분석하면 변경 작업의 성공률을 수치로 파악할 수 있습니다. 프로세스 맵에서 종료 코드가 '실패'인 변경만 필터링하면 실패로 이어지는 공통 프로세스 패턴을 찾아 근본 원인을 분석할 수 있습니다.
중요한 이유
변경 결과를 직접 측정하는 지표로, 변경 실패율 산출과 실패 원인 분석에 필요한 기본 데이터를 제공합니다.
확보 방법
ServiceNow 테이블: change_request, 필드: close_code
예시
성공문제가 있었지만 성공실패 / 롤백
|
|||
|
처리 시간
CycleTime
|
변경 요청이 생성된 시점부터 종료될 때까지 걸린 총시간입니다. | ||
|
설명
처리 시간은 변경 요청의 전체 수명 주기에 걸리는 시간을 측정하는 케이스 단위 지표입니다. 해당 변경 요청에서 가장 먼저 발생한 이벤트의 타임스탬프와 가장 나중에 발생한 이벤트의 타임스탬프 간 차이로 계산합니다. 프로세스 전반의 속도를 측정하는 주요 KPI입니다. '변경 프로세스 전체 흐름' 대시보드에서 프로세스 성과를 개괄적으로 보여주는 데 사용됩니다. 처리 시간 추이를 분석하고 변경 유형이나 우선순위별로 비교하면 전략적인 프로세스 개선 기회를 찾을 수 있습니다.
중요한 이유
변경 프로세스의 시작부터 끝까지 걸리는 시간을 측정해 전반적인 처리 속도와 효율성을 보여주는 주요 지표입니다.
확보 방법
데이터 분석 중 케이스별로 최대 StartTime에서 최소 StartTime을 빼서 계산합니다.
예시
60480012096002592000
|
|||
변경 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
변경 구현 완료
|
구현 작업이 완료되어 변경 사항을 검토, 확인 또는 테스트할 수 있는 상태입니다. 변경 요청 상태가 'Implement'에서 'Review'로 바뀌면 이 활동으로 추론합니다. | ||
|
중요한 이유
구현 단계가 끝나는 중요한 시점입니다. '변경 실패율' 및 '변경 재작업률' KPI를 계산하는 데 사용됩니다.
확보 방법
상태가 'Implement'에서 'Review'와 같은 다음 상태로 변경될 때 추론합니다. 타임스탬프는 change_request 테이블의 'state' 필드 감사 이력에서 가져옵니다.
기록
'state' 필드가 'Implement'에서 'Review'로 변경되는 시점을 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 승인
|
변경 요청에 필요한 승인이 모두 완료되어 일정 수립 및 구현 단계로 진행할 수 있는 상태입니다. 최종 승인이 내려지고 'approval' 필드가 'approved'로 설정될 때 기록되는 중요한 단계입니다. | ||
|
중요한 이유
이 단계에서 승인 절차가 완료됩니다. 승인 주기 시간을 측정하고 의사 결정 과정의 병목을 찾는 데 필요합니다.
확보 방법
change_request 테이블의 'approval' 필드가 'approved'로 변경될 때 추론합니다. 타임스탬프는 이 변경의 감사 이력에서 가져옵니다.
기록
'approval' 필드가 'approved'로 바뀐 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
변경 요청 생성
|
시스템에 새 변경 요청 레코드가 생성되는 활동입니다. 변경 관리 프로세스의 공식적인 시작점이며, change_request 테이블에 새 항목이 추가될 때 기록됩니다. | ||
|
중요한 이유
이 프로세스의 주요 시작 이벤트입니다. 이 활동부터 다른 활동까지 걸린 시간을 분석하면 전체 리드 타임을 파악하고 프로세스 초기에 발생하는 지연을 찾을 수 있습니다.
확보 방법
ServiceNow change_request 테이블의 레코드 생성 시각(sys_created_on)에 해당하는 이벤트입니다.
기록
change_request 테이블의 sys_created_on 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
변경 일정 수립
|
승인된 변경에 계획된 시작일과 종료일이 지정되어 구현 일정에 공식적으로 등록된 상태입니다. 변경 요청 상태가 'Scheduled'로 바뀌면 이 활동으로 추론합니다. | ||
|
중요한 이유
계획 및 승인 단계와 실제 구현 단계를 구분하는 활동입니다. 이 상태에 머문 시간은 승인 후 작업 시작까지의 지연을 나타낼 수 있습니다.
확보 방법
change_request 테이블의 'state' 필드가 'Scheduled'로 변경될 때 추론합니다. 타임스탬프는 해당 감사 로그 항목에서 가져옵니다.
기록
change_request 테이블의 감사 이력에서 'state' 필드가 'Scheduled'로 변경된 시점을 추적합니다.
이벤트 유형
inferred
|
|||
|
변경 종료
|
변경 요청이 성공적으로 완료되고 검토되어 종료된 상태입니다. 프로세스의 주요 성공 종료점이며, 변경 상태가 'Closed'로 바뀔 때 기록됩니다. | ||
|
중요한 이유
변경 생명주기가 성공적으로 완료된 시점입니다. 프로세스 전체 소요 시간과 SLA 준수 여부를 측정하는 종료 이벤트입니다.
확보 방법
change_request 테이블의 'state' 필드가 'Closed'로 설정될 때 추론합니다. 타임스탬프는 최종 상태 변경의 감사 이력에서 가져옵니다.
기록
'state' 필드가 'Closed'로 업데이트된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
변경 취소
|
구현이 완료되기 전에 변경 요청이 철회되거나 중단된 상태입니다. 'state' 필드가 'Canceled'로 설정될 때 기록되는 대체 종료 상태입니다. | ||
|
중요한 이유
취소된 변경을 분석하면 불필요한 요청이 생성되거나 승인 단계에서 너무 오래 대기하다가 효력이 없어지는 등 프로세스의 비효율을 찾을 수 있습니다.
확보 방법
change_request 테이블의 'state' 필드가 'Canceled'로 설정될 때 추론합니다. 타임스탬프는 이 상태 변경의 감사 로그에서 가져옵니다.
기록
'state' 필드가 'Canceled'로 업데이트된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
위험 및 영향 평가 완료
|
변경 요청의 위험 및 영향 분석이 완료된 상태입니다. 승인을 요청하기 전의 중요한 단계이며, 변경 상태가 'Assess'에서 'Authorize' 또는 'Awaiting Approval'로 바뀌면 완료된 것으로 추론하는 경우가 많습니다. | ||
|
중요한 이유
평가 단계의 소요 시간을 추적하면 '평균 위험 평가 주기 시간' KPI를 산출할 수 있습니다. 평가 프로세스를 표준화하고 분석이 지나치게 오래 걸리는 지점을 찾는 데도 도움이 됩니다.
확보 방법
change_request 테이블의 'state' 필드가 'Assess'에서 'Authorize'로 변경될 때 추론합니다. 이벤트 타임스탬프는 이 상태 변경의 감사 로그에서 가져옵니다.
기록
'state' 필드가 'Assess'에서 'Authorize'와 같은 다음 상태로 변경되는 시점을 확인합니다.
이벤트 유형
inferred
|
|||
|
검토 진행 중
|
변경이 성공적으로 완료되어 목표를 달성했는지 확인하기 위해 구현 후 검토(PIR)를 진행하는 상태입니다. 변경 요청의 'state'가 'Review'로 설정될 때 기록됩니다. | ||
|
중요한 이유
검토 단계의 소요 시간을 분석하면 변경 성공 여부를 확인하는 과정에서 발생하는 지연을 찾을 수 있습니다. 이 단계를 건너뛴 규정 미준수 변경도 확인할 수 있습니다.
확보 방법
change_request 테이블의 'state' 필드가 'Review'로 변경될 때 추론합니다. 타임스탬프는 이 상태 변경의 감사 로그에서 가져옵니다.
기록
change_request 감사 이력에서 상태가 'Review'로 변경된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
구현 시작
|
변경 구현 작업이 시작된 상태입니다. 변경 요청의 'state'가 'Implement'로 업데이트되면 기록되며, 계획 단계에서 실행 단계로 전환되었음을 나타냅니다. | ||
|
중요한 이유
실제 구현 작업이 시작되는 시점입니다. '평균 구현 소요 시간' KPI를 측정하고 팀의 업무 효율을 분석할 때 기준점으로 사용합니다.
확보 방법
change_request 테이블의 'state' 필드가 'Implement'로 변경될 때 추론합니다. 타임스탬프는 이 상태 전환의 감사 로그에서 가져옵니다.
기록
change_request 감사 이력에서 상태가 'Implement'로 변경된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
변경 반려
|
승인자 또는 CAB가 변경 요청을 거부한 상태입니다. 요청을 수정해 다시 제출하지 않는 한 이 활동은 요청의 종료 상태가 됩니다. 'approval' 필드가 'rejected'로 설정될 때 기록됩니다. | ||
|
중요한 이유
반려 내역을 추적하면 정보 누락이나 높은 위험도 등 거부 사유를 파악할 수 있습니다. 이를 분석해 향후 변경 요청의 품질을 높일 수 있습니다.
확보 방법
change_request 테이블의 'approval' 필드가 'rejected'로 변경될 때 추론합니다. 타임스탬프는 감사 이력에서 가져옵니다.
기록
'approval' 필드가 'rejected'로 바뀐 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
변경 재개
|
변경 요청이 이후 단계에 도달한 뒤 'Implement' 또는 'Assess'와 같은 이전 상태로 돌아간 경우입니다. 비선형 상태 전환을 통해 추론하며 재작업이 발생했음을 나타냅니다. | ||
|
중요한 이유
재작업 반복을 파악하고 '변경 재작업률'을 계산하는 데 중요한 활동입니다. 재개가 잦다면 구현 품질, 테스트 또는 계획에 문제가 있을 수 있습니다.
확보 방법
change_request 감사 이력의 상태 변경 순서를 분석해 추론합니다. 'Review'와 같은 이후 상태에서 'Implement'와 같은 이전 상태로 전환되면 재개 이벤트로 간주합니다.
기록
'state' 필드의 이력에서 순서를 거슬러 이전 상태로 돌아가는 전환을 감지합니다.
이벤트 유형
inferred
|
|||
|
승인 요청
|
변경 요청을 관리자나 Change Advisory Board(CAB)에 공식적으로 제출해 승인을 요청한 활동입니다. 변경 요청의 승인 상태가 'requested'로 설정될 때 기록됩니다. | ||
|
중요한 이유
승인 주기의 시작을 나타냅니다. 이 이벤트부터 '변경 승인'까지 걸린 시간을 측정하면 '평균 변경 승인 시간' KPI를 바로 산출할 수 있습니다.
확보 방법
change_request 테이블의 'approval' 필드가 'requested'로 변경될 때 추론합니다. 타임스탬프는 해당 필드의 변경 이력이 기록된 sys_audit 테이블에서 가져옵니다.
기록
change_request 테이블의 'approval' 필드가 'requested'로 설정된 시각입니다.
이벤트 유형
inferred
|
|||
|
평가 대기 중인 변경
|
변경 요청이 제출되어 기술 및 업무 평가를 기다리는 상태입니다. 일반적으로 변경 요청의 상태가 'Assess' 또는 이에 준하는 값으로 바뀌면 이 활동으로 간주합니다. 이는 요청이 초안 단계를 벗어났음을 나타냅니다. | ||
|
중요한 이유
요청자에서 평가팀으로 처음 인계되는 데 걸린 시간을 측정하는 데 도움이 됩니다. 이 단계의 지연은 초기 데이터 품질 문제나 평가 리소스 부족을 나타낼 수 있습니다.
확보 방법
change_request 테이블의 'state' 필드가 일반적으로 'Assess'와 같은 값으로 변경될 때 추론합니다. 타임스탬프는 해당 필드 변경에 대한 감사 이력(sys_audit)에서 가져옵니다.
기록
change_request 테이블의 감사 이력에서 'state' 필드가 'Assess'로 변경된 시점을 추적합니다.
이벤트 유형
inferred
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 준비하고 ServiceNow 변경 관리 프로세스의 인사이트를 확인하세요. 지금 프로세스 효율을 높여 보세요.
변경 실패를 줄이고 ServiceNow 성과를 높이세요!
병목을 찾아 변경 성공률을 손쉽게 95%까지 높이세요.
신용카드 없이 몇 분 만에 설정할 수 있습니다.