변경 관리 데이터 템플릿

Ivanti Cherwell
변경 관리 데이터 템플릿

변경 관리 데이터 템플릿

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

변경 관리 속성

변경 관리를 분석하고 프로세스를 파악하는 데 필요한 데이터 필드입니다. 이벤트 로그에 포함하는 것을 권장합니다.
5 필수 6 권장 8 선택 사항
이름 설명
변경 요청 ID
ChangeRequestId
변경 요청 사례 하나를 고유하게 식별하며, 요청 시작부터 종료까지 관련된 모든 활동을 묶는 식별자입니다.
설명

변경 요청 ID는 변경의 전체 수명 주기에서 각 변경 건을 고유하게 식별하는 기본 키입니다. process mining에서 사례 식별자로 사용되며, 제출, 평가, 승인, 구현 등의 이벤트를 하나의 일관된 프로세스 인스턴스로 연결합니다.

변경 요청 ID를 기준으로 데이터를 분석하면 변경 관리 프로세스를 처음부터 끝까지 파악할 수 있습니다. 개별 변경을 추적하고 전체 처리 시간을 계산하며, 각 요청에서 발생한 프로세스 이탈이나 병목을 식별할 수 있습니다.

중요한 이유

관련 이벤트를 연결하는 필수 사례 식별자입니다. 변경 요청의 전체 진행 과정을 추적하고 성과를 분석할 수 있습니다.

확보 방법

일반적으로 Ivanti Cherwell의 Change Request 비즈니스 객체에서 기본 식별자로 사용됩니다.

예시
CR-105421CR-105422CR-105423
이벤트 시각
EventTime
변경 요청에서 특정 활동이나 이벤트가 발생한 시각입니다.
설명

이벤트 시각은 타임스탬프라고도 하며, 활동이 발생한 정확한 날짜와 시간을 기록합니다. 이벤트를 시간순으로 정렬하는 데 필요한 데이터이며, 시간 기반 process mining 분석의 기초가 됩니다.

이 속성을 사용해 활동 간 소요 시간과 사례별 전체 처리 시간을 계산하고, 프로세스의 대기 시간이나 지연을 파악할 수 있습니다. 변경 승인 처리 시간과 같은 시간 목표 대비 성과를 모니터링하는 대시보드를 만드는 데도 필요합니다.

중요한 이유

성과와 소요 시간을 분석하는 기준이 되는 타임스탬프입니다. 처리 시간을 계산하고 병목을 파악하며 SLA 준수 여부를 모니터링할 수 있습니다.

확보 방법

일반적으로 Ivanti Cherwell의 Change Request 객체와 관련된 상태 변경 로그, 감사 추적 또는 저널 항목의 타임스탬프에서 확인할 수 있습니다.

예시
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
활동 이름
ActivityName
변경 관리 프로세스에서 특정 시점에 발생한 이벤트나 작업의 이름입니다.
설명

활동 이름은 변경 요청의 수명 주기에서 발생한 특정 단계나 주요 시점을 나타냅니다. 예를 들어 '평가를 위한 변경 제출' 또는 'CAB에서 변경 승인'이 있습니다. 이러한 활동은 발견된 프로세스 맵의 노드를 구성합니다.

분석에서는 프로세스 흐름을 시각화하고 이벤트 순서를 파악하며 표준 절차에서 벗어난 부분을 찾는 데 이 속성을 사용합니다. 활동 간 전환 시간을 계산하고 지연이 발생하는 지점을 파악하는 데도 활용됩니다.

중요한 이유

실제 프로세스 흐름을 발견하고 시각화하는 데 필요한 속성입니다. 병목, 재작업 반복, 규정을 준수하지 않는 경로를 식별할 수 있습니다.

확보 방법

Ivanti Cherwell의 Change Request 객체와 관련된 상태 변경, 저널 항목 또는 특정 이벤트 로그에서 생성됩니다.

예시
변경 평가 요청 제출변경 승인 대기변경 구현 완료
소스 시스템
SourceSystem
데이터를 추출한 기준 시스템입니다. 이 화면에서는 'Ivanti Cherwell'입니다.
설명

이벤트 데이터의 출처 시스템을 나타내는 속성입니다. 여러 시스템을 함께 사용하는 환경에서는 데이터 출처를 구분하는 데 도움이 됩니다. 이 데이터 모델에서는 Ivanti Cherwell에서 가져온 데이터임을 나타내는 고정값으로 설정됩니다.

단일 소스 모델에서는 값이 고정되어 보일 수 있지만, 데이터 거버넌스와 추적성, 향후 다른 시스템과의 연동에 중요합니다. 데이터 출처를 명확히 하고 데이터 품질을 관리하는 데 도움이 됩니다.

중요한 이유

데이터 출처에 대한 정보를 제공하므로 데이터 거버넌스, 문제 해결, 추적성 확보에 중요합니다.

확보 방법

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

예시
Ivanti Cherwell
최종 데이터 업데이트 시각
LastDataUpdate
이 이벤트의 데이터를 소스 시스템에서 마지막으로 추출하거나 새로 고친 시각입니다.
설명

이 속성은 Ivanti Cherwell에서 데이터를 마지막으로 가져온 날짜와 시간을 기록합니다. 프로세스에서 발생한 이벤트가 아니라 데이터의 최신 상태를 나타내는 메타데이터입니다.

대시보드 사용자는 이를 통해 분석에 사용된 데이터가 얼마나 최신인지 확인할 수 있습니다. 데이터 새로 고침 일정을 관리하고 데이터의 기준 시점을 파악한 상태에서 의사결정을 내리는 데 도움이 됩니다.

중요한 이유

데이터의 최신 상태를 나타냅니다. 사용자가 분석 결과를 신뢰하고 현재 운영 상황과의 관련성을 판단하는 데 중요합니다.

확보 방법

데이터 추출, 변환, 적재(ETL) 과정에서 각 레코드에 생성해 기록하는 타임스탬프입니다.

예시
2024-05-21T02:00:00Z
목표 완료일
TargetCompletionDate
변경 구현을 완료하기로 계획했거나 합의한 기한입니다.
설명

목표 완료일은 변경을 완전히 구현하고 검증할 것으로 예상되는 시점입니다. 서비스 수준 계약(SLA)에 포함되는 경우가 많으며 성과를 측정하는 주요 기준으로 사용됩니다.

기한 준수 여부를 모니터링하는 데 필요한 속성입니다. 실제 완료일과 비교해 '정시 변경 완료율' 및 '변경 SLA 준수율' KPI를 계산합니다. 목표 기한을 놓칠 가능성이 있는 변경을 미리 파악하는 데도 도움이 됩니다.

중요한 이유

정시 완료와 SLA 준수 여부를 측정하는 기준이 됩니다. 이는 프로세스 효율성과 신뢰성을 나타내는 주요 지표입니다.

확보 방법

일반적으로 Change Request 객체의 날짜 필드이며, 'Target Date', 'Due Date' 또는 'SLA Target'으로 표시됩니다.

예시
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
변경 담당 팀
ChangeTeam
현재 변경 요청을 담당하는 팀 또는 그룹입니다.
설명

변경 담당 팀은 변경 요청을 맡은 그룹 또는 부서입니다. 변경 담당자와 마찬가지로 프로세스 진행 중 팀이 바뀔 수 있으며, 서비스 데스크에서 네트워크 엔지니어링 팀으로 책임이 이관되는 경우가 이에 해당합니다.

이 속성은 팀 간 인계를 분석하고 특정 팀으로 인해 반복되는 지연을 파악하는 데 필요합니다. 어느 팀의 업무가 과중한지, 어디에서 의사소통 문제가 발생하는지 확인할 수 있으며, '변경 인계 및 리소스 활용' 분석에 직접 활용됩니다.

중요한 이유

팀별 책임을 파악해 프로세스 병목을 분석하고 팀 성과를 측정하며 그룹 간 인계 지연을 이해할 수 있습니다.

확보 방법

일반적으로 Change Request 객체의 'Owned By Team' 또는 이와 유사한 그룹 할당 필드에 저장됩니다.

예시
네트워크 운영데이터베이스 관리애플리케이션 지원
변경 담당자
ChangeOwner
현재 변경 요청을 담당하는 사용자 또는 담당자입니다.
설명

변경 담당자는 특정 단계에서 변경 요청을 맡고 그 결과에 책임지는 사람입니다. 요청이 수명 주기의 다음 단계로 이동하면서 담당자가 바뀌기도 하며, 이는 담당자 간 인계를 나타냅니다.

변경 담당자를 분석하면 리소스별 업무량을 파악하고 특정 담당자와 관련된 병목을 찾을 수 있습니다. 지연의 주요 원인이 될 수 있는 인계 현황을 분석하는 데도 필요합니다. '변경 인계 및 리소스 활용' 대시보드에서 활용됩니다.

중요한 이유

담당자별 책임을 추적해 업무량 분포, 인계 빈도, 리소스별 병목을 분석할 수 있습니다.

확보 방법

일반적으로 Change Request 비즈니스 객체의 'Owned By' 또는 'Assigned To' 필드에 해당합니다.

예시
Alice JohnsonBob WilliamsCharlie Brown
변경 상태
ChangeStatus
변경 요청의 현재 또는 최종 상태입니다. 예를 들어 'Closed', 'Rejected', 'In Progress'가 있습니다.
설명

변경 상태는 특정 시점의 변경 요청 상태나 최종 결과를 나타냅니다. 사례의 해결 상태를 파악하고 예외를 식별하는 데 중요한 속성입니다.

프로세스 분석에서는 거부되거나 취소된 변경만 분석하는 등 특정 결과를 기준으로 데이터를 필터링할 때 사용합니다. '변경 요청 거부율'과 같은 KPI를 계산하는 데 활용되며, 변경 관리 프로세스의 전반적인 상태와 효율성을 파악하는 데 필요합니다.

중요한 이유

변경 요청의 결과를 나타내며, 거부율과 완료율, 미종료 사례와 종료 사례의 분포를 분석할 수 있습니다.

확보 방법

Ivanti Cherwell의 Change Request 비즈니스 객체에 있는 'Status' 필드에 해당합니다.

예시
승인거부종료취소승인 대기
변경 위험 수준
ChangeRiskLevel
변경에 대해 평가한 위험 수준입니다. 예를 들어 'Low', 'Medium', 'High'가 있습니다.
설명

변경 위험 수준은 평가 단계에서 변경으로 발생할 수 있는 부정적 영향을 수치화해 분류한 값입니다. 이 평가 결과는 승인 절차와 필요한 검토 수준에 영향을 주는 경우가 많습니다.

process mining에서는 위험 평가의 일관성을 분석하고 위험 수준과 프로세스 진행 방식의 관계를 파악하는 데 사용합니다. 예를 들어 고위험 변경에 더 엄격한 승인 절차가 적용되는지, 구현 시간이 더 오래 걸리는지 확인할 수 있습니다. '변경 위험 평가 일관성' 대시보드에서 활용됩니다.

중요한 이유

위험 수준이 프로세스 흐름, 승인 처리 시간, 성공률에 미치는 영향을 분석할 수 있습니다. 고위험 변경이 적절한 검토를 받는지 확인하는 데 도움이 됩니다.

확보 방법

일반적으로 위험 평가 활동 중 입력하는 값으로, Change Request 객체의 'Risk Level' 또는 이와 유사한 필드에 저장됩니다.

예시
낮음보통높음매우 높음
변경 유형
ChangeType
변경의 분류입니다. 예를 들어 'Standard', 'Normal', 'Emergency'가 있습니다.
설명

변경 유형은 변경의 성격, 긴급성, 영향에 따라 변경 요청을 분류합니다. 일반적인 유형으로는 사전 승인된 저위험 변경인 Standard, 전체 평가와 승인이 필요한 Normal, 즉시 구현이 필요한 Emergency가 있습니다.

이 속성을 기준으로 프로세스 성과를 유형별로 비교할 수 있습니다. 예를 들어 Emergency 변경이 더 빠른 경로로 처리되는지, Standard 변경이 실제로 불필요한 지연 없이 처리되는지 확인할 수 있습니다. '문제가 많은 변경 유형 성과' 대시보드의 주요 분석 기준입니다.

중요한 이유

변경 유형별로 프로세스를 나누어 성과를 비교하면 'Emergency'와 같은 특정 유형이 병목이나 절차 이탈을 일으키는지 파악할 수 있습니다.

확보 방법

Change Request 비즈니스 객체의 'Change Type' 또는 'Category'와 같은 분류 필드에 해당합니다.

예시
표준일반긴급
거부 사유
ChangeRejectionReason
변경 요청이 거부된 이유를 설명하는 문구 또는 분류입니다.
설명

변경 요청이 거부되면 승인자가 제시한 사유를 이 속성에 기록합니다. 미리 정의된 목록에서 선택하거나 직접 입력할 수 있습니다.

'거부된 변경 요청 분석' 대시보드에 필요한 정보입니다. 거부 사유를 분류하고 분석하면 정보 누락, 불충분한 위험 평가, 사업상 이해 충돌 등 변경 요청 제출 과정에서 반복되는 문제를 파악할 수 있습니다. 이를 바탕으로 향후 변경 요청의 품질을 높일 수 있습니다.

중요한 이유

변경이 실패한 이유를 직접 파악할 수 있어 제출 및 평가 절차를 개선하고 전반적인 거부율을 낮추는 데 도움이 됩니다.

확보 방법

일반적으로 전용 'Rejection Reason' 필드나 메모 필드에 기록하며, 상태가 'Rejected'로 변경될 때 입력합니다.

예시
구현 계획의 세부 정보 부족위험 평가 미완료다른 예정된 변경과 일정 충돌
구현 주기 시간
ImplementationCycleTime
변경 구현을 시작한 시점부터 완료한 시점까지의 계산된 시간입니다.
설명

변경 구현 단계에 걸린 시간을 측정합니다. 'Change Implementation Started' 활동부터 'Change Implemented' 활동까지의 시간을 계산합니다.

이 속성은 '평균 변경 구현 시간' KPI를 계산하고 '변경 구현 흐름 및 지연' 대시보드를 지원합니다. 계획 지연과 실행 지연을 구분해 기술 구현 작업 자체의 개선에 집중할 수 있습니다.

중요한 이유

실제 구현 단계의 성과를 분리해 살펴보므로 승인 지연과 구분하여 기술 또는 리소스 관련 병목을 파악할 수 있습니다.

확보 방법

process mining 도구 또는 데이터 변환 과정에서 구현 시작 이벤트와 종료 이벤트의 타임스탬프 차이를 계산합니다.

예시
4시간 15분1일 2시간30분
변경 요청자
ChangeSubmitter
변경 요청을 처음 생성하거나 제출한 사용자입니다.
설명

이 속성은 변경 요청을 시작한 사람을 식별합니다. 이후 구현을 맡는 변경 담당자와 다를 수 있습니다.

변경 요청자를 분석하면 요청 품질과 관련된 패턴을 파악할 수 있습니다. 예를 들어 특정 사용자나 팀이 불완전한 요청을 자주 제출해 거부나 재작업으로 이어지는지 확인할 수 있습니다. 이 정보를 활용해 필요한 교육을 제공하고 제출 품질을 높일 수 있습니다.

중요한 이유

변경 요청의 시작점을 추적해 사용자나 팀별 제출 품질을 분석하고 교육이 필요한 부분을 파악할 수 있습니다.

확보 방법

일반적으로 Change Request 객체의 'Created By' 또는 'Requested By' 필드에 해당합니다.

예시
Susan MillerDavid ChenMaria Garcia
변경 우선순위
ChangePriority
변경 요청의 긴급성과 사업 영향을 나타내는 우선순위입니다.
설명

변경 우선순위는 변경의 긴급성과 영향을 함께 고려해 정합니다. 팀이 업무의 우선순위를 정하고 리소스를 효율적으로 배분해 가장 중요한 변경을 먼저 처리하도록 돕습니다.

분석에서는 우선순위가 높은 변경이 낮은 변경보다 빠르게 처리되는지 확인할 수 있습니다. 예상과 다른 결과가 나타나면 우선순위 결정이나 실행 과정의 비효율 또는 병목을 나타낼 수 있습니다.

중요한 이유

프로세스에서 영향이 큰 변경을 적절히 우선 처리하는지, 해당 변경이 의도한 대로 신속하게 진행되는지 분석할 수 있습니다.

확보 방법

일반적으로 Change Request 객체의 'Priority' 필드에 해당합니다. 직접 설정하거나 영향 및 긴급성 필드에서 산출할 수 있습니다.

예시
1 - 매우 높음2 - 높음3 - 보통4 - 낮음
사업 부문
BusinessUnit
변경을 요청했거나 변경으로 이익을 얻는 사업 부문 또는 부서입니다.
설명

이 속성은 변경 요청을 'Finance', 'Marketing', 'Operations'와 같은 조직 내 특정 부문과 연결합니다. 기술 중심의 프로세스에 사업 맥락을 더합니다.

사업 부문별로 분석하면 변경 수요가 어디에서 발생하는지 파악할 수 있습니다. 비용 배부 모델을 수립하고, IT 변경이 각 사업 부문에 미치는 영향을 이해하며, 특정 부문의 변경이 다른 부문보다 복잡하거나 지연되는지 확인하는 데 도움이 됩니다.

중요한 이유

사업 맥락을 제공해 조직 관점에서 변경 수요와 영향, 성과를 분석할 수 있습니다.

확보 방법

Change Request 객체의 필드에 저장하거나 요청자의 사용자 프로필에서 가져올 수 있습니다.

예시
재무인사영업 및 마케팅운영
실제 완료일
ActualCompletionDate
변경이 실제로 구현되고 완료 검증을 마친 시각입니다.
설명

실제 완료일은 변경 요청의 구현 작업이 끝난 시점을 나타냅니다. 계획된 기한과 비교해 성과를 측정하는 주요 기준입니다.

목표 완료일과 함께 사용해 변경이 기한 내에 완료되었는지 판단합니다. '정시 변경 완료율'과 같은 KPI를 계산하고 구현 단계의 지연 원인을 분석하는 데 필요한 속성입니다.

중요한 이유

실제 완료 시각을 기록해 정시 완료율을 계산하고 지연 규모를 분석할 수 있습니다.

확보 방법

변경 요청 상태가 'Implemented' 또는 'Completed'로 바뀔 때 기록하는 경우가 많습니다. 별도 필드에 저장하거나 상태 변경 시각으로 추론할 수 있습니다.

예시
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
영향을 받는 서비스
ServiceAffected
변경의 영향을 받는 주요 비즈니스 서비스 또는 구성 항목(CI)입니다.
설명

이 속성은 변경 요청의 대상인 주요 IT 서비스, 애플리케이션 또는 인프라를 식별합니다. 변경 관리 프로세스와 전반적인 IT 서비스 관리 환경을 연결합니다.

영향을 받는 서비스별 분석은 '문제가 많은 변경 유형 상위 항목' KPI에 중요합니다. 변경이 가장 자주 발생하는 서비스와 거부율이나 지연이 높은 서비스가 무엇인지 파악할 수 있습니다. 서비스 담당자는 이 정보를 바탕으로 안정성을 높이고 기술 부채를 관리할 수 있습니다.

중요한 이유

변경을 특정 비즈니스 서비스와 연결해 불안정성이 높거나 문제가 많은 변경이 자주 발생하는 서비스를 파악할 수 있습니다.

확보 방법

일반적으로 구성 관리 데이터베이스(CMDB)와 연결되며, Change Request 객체의 'Primary CI' 또는 'Service' 필드에 저장됩니다.

예시
이메일 서비스(Exchange)ERP 시스템(SAP)코어 네트워크 스위치(CISCO-4500X)
정시 완료 여부
IsOnTimeCompletion
변경이 목표 날짜까지 완료되었는지 나타내는 계산 플래그입니다.
설명

'ActualCompletionDate'와 'TargetCompletionDate'를 비교해 산출하는 불리언 속성입니다. 각 변경 요청의 기한 준수 여부를 명확하게 표시합니다.

이 플래그는 '정시 변경 완료율' KPI를 계산하는 기준입니다. 대시보드에서 필터로 사용하면 지연된 변경을 쉽게 분리해 분석하고, 지연의 공통 원인을 파악할 수 있습니다.

중요한 이유

기한 준수 여부를 성공 또는 실패로 명확히 표시해 성과 분석을 간소화하고, 정시 완료 KPI를 계산하는 데 활용합니다.

확보 방법

원본 시스템에 없는 속성입니다. 데이터 변환 과정에서 'ActualCompletionDate' <= 'TargetCompletionDate'를 비교해 계산합니다.

예시
truefalse
필수 권장 선택 사항

변경 관리 활동

정확한 프로세스 파악과 성과 측정을 위해 이벤트 로그에 기록할 주요 단계와 마일스톤입니다.
7 권장 7 선택 사항
활동 설명
CAB 변경 승인
변경 자문 위원회(CAB) 또는 지정된 승인 기관이 변경 진행을 승인하는 주요 단계입니다. 변경 요청 상태가 ‘승인됨’으로 업데이트된 시점으로 추정합니다.
중요한 이유

이 활동은 승인 주기 시간을 측정하는 종료 지점입니다. 승인이 완료되면 프로세스가 다음 단계로 진행되어 계획과 구현을 시작할 수 있습니다. 변경 승인 주기 시간 KPI를 측정하는 데 중요합니다.

확보 방법

변경 요청 객체의 감사 이력에서 ‘상태’ 필드가 ‘승인됨’으로 바뀐 타임스탬프를 확인해 추정합니다.

기록

상태가 ‘승인됨’으로 바뀐 시점으로 추정합니다.

이벤트 유형 inferred
구현 후 검토 수행
완료된 변경을 공식적으로 검토해 성공 여부를 평가하고 교훈을 기록한 시점을 나타냅니다. 상태가 'Post Implementation Review'로 변경된 시점으로 추론하는 경우가 많습니다.
중요한 이유

이 활동을 추적하면 변경에 대한 피드백 절차가 마무리되었는지 확인할 수 있습니다. 지속적인 개선에 필수적이며 구현 후 검토율 KPI와 직접 연관됩니다.

확보 방법

Change Request 객체의 감사 이력에서 'Status'가 'Post Implementation Review'와 같은 상태로 변경된 시각을 기록해 추론합니다.

기록

'Post Implementation Review' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 구현 완료
변경에 필요한 기술 작업이 완료된 시점을 나타냅니다. 변경 요청 상태가 'Implemented' 또는 검증을 기다리는 유사한 상태로 업데이트될 때 기록합니다.
중요한 이유

성공 여부를 판단하는 주요 단계이며, 정시 변경 완료율 및 평균 변경 구현 시간 KPI를 계산하는 데 사용됩니다. 실행 단계의 종료를 나타냅니다.

확보 방법

Change Request 객체의 감사 로그에서 상태가 'Implemented' 또는 'Pending Verification'으로 변경된 시각을 기준으로 추론합니다.

기록

'Implemented' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 요청 생성
이 활동은 시스템에서 새 변경 요청이 시작되는 시점을 나타냅니다. 일반적으로 변경 요청 비즈니스 객체에 새 레코드가 생성될 때 기록되며, 전체 프로세스의 시작점이 됩니다.
중요한 이유

프로세스의 주요 시작 이벤트입니다. 이 활동부터 다른 활동까지 걸린 시간을 분석하면 전체 진행 기간을 확인하고 초기 단계의 지연을 파악할 수 있습니다.

확보 방법

변경 요청 레코드의 생성 타임스탬프에서 가져옵니다. Ivanti Cherwell에서는 일반적으로 변경 요청 비즈니스 객체의 ‘CreatedDateTime’ 필드에 저장됩니다.

기록

레코드 생성 타임스탬프에서 직접 가져옵니다.

이벤트 유형 explicit
변경 일정 확정
변경 구현 날짜와 시간이 공식적으로 확정되어 기록되는 시점을 나타냅니다. 상태가 ‘일정 예약됨’으로 업데이트될 때 기록됩니다.
중요한 이유

승인된 변경안을 실행 계획으로 전환하는 주요 확정 단계입니다. 구현을 시작하기 위한 선행 조건입니다.

확보 방법

Change Request 객체의 이력을 바탕으로, 'Status' 필드가 'Scheduled'로 변경된 시각을 기록해 추론합니다.

기록

'Scheduled' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 종료
변경 관리 프로세스가 성공적으로 완료되는 최종 단계입니다. 변경 요청 상태가 'Closed'로 설정되어 모든 작업이 끝났음을 나타낼 때 기록합니다.
중요한 이유

성공적으로 완료된 변경의 전체 처리 시간을 계산하는 데 필요한 최종 성공 단계입니다. 프로세스의 모든 단계가 끝났음을 확인합니다.

확보 방법

Change Request 객체의 감사 이력에서 최종 상태가 'Closed'로 변경된 시각을 기준으로 추론합니다.

기록

최종 상태가 'Closed'로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
영향 및 위험 평가 완료
변경 요청의 위험 및 영향 분석이 완료된 시점을 나타냅니다. 일반적으로 변경 요청 상태가 ‘승인 대기’처럼 승인 준비가 완료되었음을 나타내는 상태로 바뀌는 시점으로 추정합니다.
중요한 이유

이 활동을 추적하면 평가 단계에 걸리는 시간을 측정하고 승인 전에 위험 분석이 일관되게 이루어지는지 확인할 수 있습니다. 위험 평가 준수율 KPI를 관리하는 데도 도움이 됩니다.

확보 방법

변경 요청 객체의 이력에서 추정합니다. ‘상태’ 필드가 ‘평가 중’에서 ‘CAB 승인 대기’와 같은 상태로 변경된 타임스탬프를 기록합니다.

기록

상태가 ‘CAB 승인 대기’로 바뀐 시점으로 추정합니다.

이벤트 유형 inferred
구현 계획 수립
작업, 리소스, 롤백 계획을 정하는 등 변경에 대한 세부 계획이 완료된 시점을 나타냅니다. 변경 상태가 ‘승인됨’에서 ‘일정 예약됨’으로 바뀌는 시점으로 추정하는 경우가 많습니다.
중요한 이유

이 활동에 걸리는 시간으로 변경 계획 단계의 효율성을 파악할 수 있습니다. 승인이 완료된 뒤에도 이 단계의 지연은 전체 변경 일정에 영향을 줄 수 있습니다.

확보 방법

상태가 ‘승인됨’에서 ‘일정 예약됨’으로 바뀐 타임스탬프를 기준으로 추정할 수 있습니다. 또는 특정 계획 필드에 값이 입력된 시점을 기준으로 삼을 수 있습니다.

기록

상태가 ‘승인됨’에서 ‘일정 예약됨’으로 바뀐 시점으로 추정합니다.

이벤트 유형 inferred
변경 검증 수행
변경이 성공적으로 완료되었고 부정적인 영향이 발생하지 않았는지 확인하는 테스트 및 검증 단계입니다. 상태가 'Verification' 또는 'Testing'으로 변경된 시점으로 추론합니다.
중요한 이유

이 활동의 빈도와 소요 시간을 분석하면 품질 보증 절차가 누락되지 않았는지 확인할 수 있습니다. 변경으로 인한 사고를 예방하는 데 중요한 단계입니다.

확보 방법

Change Request 객체의 상태 변경 시각을 기록합니다. 예를 들어 상태가 'Verification' 또는 'User Acceptance Testing'으로 바뀐 시점입니다.

기록

'Verification' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 구현 시작
변경의 기술적 실행이 시작되는 시점을 나타냅니다. 일반적으로 변경 요청 상태가 'In Progress' 또는 'Implementing'으로 바뀐 시점으로 추론합니다.
중요한 이유

이 활동은 구현 기간의 시작을 나타냅니다. 이 시점부터 'Change Implemented'까지 걸린 시간이 실제 구현 기간이며, 전체 처리 시간의 주요 구성 요소입니다.

확보 방법

Change Request 객체의 감사 이력을 바탕으로 추론합니다. 'Status' 필드가 'In Progress' 또는 'Implementing'과 같은 값으로 변경된 시각입니다.

기록

'In Progress' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 반려
승인 단계에서 변경 요청을 최종 반려하는 활동입니다. 변경 요청 상태가 ‘반려됨’으로 설정될 때 기록됩니다.
중요한 이유

프로세스가 종료되는 중요한 실패 지점입니다. 반려된 변경과 그 사유를 분석하면 최초 요청의 품질을 높이고 변경 요청 반려율 KPI를 관리할 수 있습니다.

확보 방법

감사 이력에서 변경 요청 객체의 ‘상태’ 필드가 ‘반려됨’으로 업데이트된 타임스탬프를 확인해 추정합니다.

기록

상태가 ‘반려됨’으로 바뀐 시점으로 추정합니다.

이벤트 유형 inferred
변경 승인 대기
변경 요청이 변경 자문 위원회(CAB) 또는 다른 승인 기관의 결정을 공식적으로 기다리는 기간을 나타냅니다. ‘승인 보류’ 또는 ‘CAB 대기’와 같은 상태로 추정합니다.
중요한 이유

중요한 대기 시간 활동입니다. 소요 시간을 분석하면 변경 관리에서 지연이 자주 발생하는 승인 워크플로의 병목을 찾을 수 있습니다.

확보 방법

변경 요청 비즈니스 객체의 ‘상태’ 필드가 ‘승인 보류’ 또는 이에 해당하는 값으로 업데이트된 타임스탬프에서 가져옵니다.

기록

‘승인 보류’ 상태에 진입한 시점으로 확인합니다.

이벤트 유형 inferred
변경 취소
승인되었거나 진행 중인 변경 요청이 완료 전에 철회된 최종 상태를 나타냅니다. 상태가 'Cancelled'로 업데이트될 때 기록합니다.
중요한 이유

프로세스가 종료되는 또 다른 경로입니다. 변경이 취소된 이유와 시점을 분석하면 계획, 리소스 배분 또는 사업 우선순위 변경과 관련된 문제를 파악할 수 있습니다.

확보 방법

Change Request 객체의 'Status' 필드가 'Cancelled'로 업데이트된 시각을 감사 이력에서 기록해 추론합니다.

기록

'Cancelled' 상태로 변경된 시점을 기준으로 추론합니다.

이벤트 유형 inferred
변경 평가 요청 제출
새로 생성된 변경 요청을 최초 평가를 위해 공식 제출하는 단계입니다. 일반적으로 변경 요청 상태가 ‘신규’ 또는 ‘초안’에서 ‘평가 중’과 같은 상태로 바뀌는 시점으로 추정합니다.
중요한 이유

초기 데이터 입력 후 공식 변경 프로세스가 시작되는 시점을 나타냅니다. 생성부터 제출까지 걸린 시간을 살펴보면 사용자 교육이 필요한지, 프로세스에 마찰이 있는지 파악할 수 있습니다.

확보 방법

변경 요청 객체의 감사 로그 또는 이력에서 ‘상태’ 필드가 ‘평가 중’ 또는 ‘제출됨’과 같은 값으로 바뀐 타임스탬프를 확인해 추정합니다.

기록

상태가 ‘신규’에서 ‘평가 중’으로 바뀐 시점으로 추정합니다.

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

데이터 추출 가이드

Ivanti Cherwell에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿으로 변경 관리 프로세스 분석을 시작하고 개선 기회를 찾아보세요. 지금 바로 변경 작업을 최적화하고 효율을 높여 보세요.

변경 성공률 95% 달성: 지금 Ivanti Cherwell 최적화

병목을 해소하고 위험을 줄여 변경 성공률 95%를 달성하세요.

무료 체험 시작

신용카드 없이 바로 시작할 수 있습니다.