변경 관리 데이터 템플릿
변경 관리 데이터 템플릿
- 심층 분석을 위해 수집할 권장 속성
- 프로세스에서 추적할 주요 활동과 마일스톤
- 관련 소스 시스템별 데이터 추출 안내
변경 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
변경 요청 ID
ChangeRequestID
|
변경 요청을 식별하는 시스템 생성 고유 식별자로, 기본 케이스 식별자로 사용됩니다. | ||
|
설명
변경 요청 ID는 전체 변경 주기에서 각 변경 작업을 식별하는 고유 키입니다. 관련 활동, 승인, 작업을 하나로 묶어 process mining에서 단일 케이스의 기준이 됩니다. 이 ID를 기준으로 분석하면 최초 요청부터 최종 종료까지 변경 관리 전 과정을 확인할 수 있습니다. 주기 시간 측정, 병목 파악, 개별 변경별 프로세스 차이 분석에 필요합니다.
중요한 이유
관련 이벤트를 하나의 프로세스 인스턴스로 연결하는 기본 속성으로, 변경 관리 프로세스를 처음부터 끝까지 분석할 수 있게 합니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Infrastructure Change ID' 필드(Field ID 1000000182)에서 확인할 수 있습니다.
예시
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
시작 시간
EventStartTime
|
특정 활동이나 이벤트가 시작된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 활동이 발생한 정확한 날짜와 시간을 기록합니다. 예를 들어 변경 요청이 제출, 승인 또는 종료된 시점을 기록합니다. 프로세스 타임라인을 분석하는 데 필요한 속성입니다. 활동 간 주기 시간 계산, 대기 시간 측정, 시간에 따른 성과 추세 파악, 이벤트 순서 확인에 사용합니다. 정확한 타임스탬프는 시간 기반 프로세스 분석의 토대입니다.
중요한 이유
소요 시간 계산, 성과 분석, 프로세스 내 이벤트 순서 파악에 필요한 시간 정보를 제공합니다.
확보 방법
'CHG:ChangeRequest_AuditLog' 양식의 'Audit Date' 필드 또는 특정 상태 변경과 연결된 'Last Modified Date'에서 가져옵니다.
예시
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
활동
ActivityName
|
변경 관리 프로세스에서 수행한 특정 이벤트 또는 작업의 이름입니다. | ||
|
설명
이 속성은 변경 요청 주기의 단일 단계 또는 상태 변경을 나타냅니다. 예를 들어 '변경 요청 제출'이나 '변경 요청 승인'이 이에 해당합니다. 이러한 활동이 프로세스 맵을 구성합니다. 활동의 순서와 소요 시간을 분석하면 프로세스 흐름을 파악하고 표준 절차에서 벗어난 부분을 찾아 병목을 확인할 수 있습니다. 활동 이름은 일반적으로 시스템 감사 로그에 기록된 상태 전환을 바탕으로 정합니다.
중요한 이유
프로세스 단계를 정의해 프로세스 흐름을 시각화하고 분석할 수 있게 합니다. 프로세스 흐름은 process mining의 기반입니다.
확보 방법
'CHG:ChangeRequest_AuditLog' 양식의 상태 전환 또는 'CHG:Infrastructure Change' 양식의 'Status' 필드 변경을 추적해 도출합니다.
예시
변경 요청 제출위험 평가 완료변경 요청 승인변경 이행 완료
|
|||
|
원천 시스템
SourceSystem
|
데이터를 추출한 시스템의 이름입니다. | ||
|
설명
이 속성은 프로세스 데이터의 출처를 나타냅니다. 여기서는 'BMC Helix ITSM'입니다. 여러 시스템의 데이터를 결합해 분석하는 환경에서 데이터 거버넌스와 추적성을 확보하는 데 도움이 됩니다. 예를 들어 변경 데이터를 재무 또는 프로젝트 관리 시스템의 데이터와 결합할 때 이 필드를 사용하면 데이터 출처를 명확히 구분할 수 있습니다.
중요한 이유
데이터 출처에 대한 맥락을 제공해 추적성과 올바른 해석을 지원합니다. 특히 여러 시스템을 함께 분석할 때 유용합니다.
확보 방법
일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다.
예시
BMC Helix ITSMHelix ITSM 운영 환경BMC Remedy AR System
|
|||
|
최근 데이터 업데이트
LastDataUpdate
|
원천 시스템에서 이 레코드의 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 BMC Helix ITSM에서 데이터를 마지막으로 추출한 날짜와 시간을 나타냅니다. 이벤트가 발생한 시간이 아니라 데이터를 가져온 시간입니다. 분석 대상 데이터의 최신성을 파악하고 데이터 새로 고침 주기를 관리하는 데 필요합니다. 대시보드와 보고서에서 이 타임스탬프를 통해 분석 결과가 얼마나 최신인지 확인할 수 있습니다. 진행 중인 프로세스를 모니터링할 때 특히 중요합니다.
중요한 이유
데이터의 최신성을 나타내며, 분석과 대시보드가 프로세스의 가장 최근 상태를 반영하는지 확인하는 데 중요합니다.
확보 방법
일반적으로 데이터 추출 시 ETL 도구나 데이터 파이프라인이 생성하고 입력하는 메타데이터 필드입니다.
예시
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
구현팀
ImplementationTeam
|
변경 사항을 구현하는 업무를 담당하는 팀입니다. | ||
|
설명
이 속성은 변경 요청에 필요한 작업을 수행하도록 지정된 기술 또는 운영 그룹을 나타냅니다. 변경 수명 주기의 구현 단계에서는 보통 'Assigned Group'으로 기록됩니다. 이 정보는 '변경 프로세스의 리소스 병목' 대시보드에 중요합니다. 구현팀별 활동 소요 시간과 건수를 분석하면 관리자는 업무량 불균형, 기술 격차 또는 변경 배포를 지연시키는 기타 리소스 제약을 파악할 수 있습니다.
중요한 이유
담당 팀별 성과를 분석해 구현 단계의 리소스 관련 병목을 파악할 수 있습니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'ASGRP'(Assigned Group) 필드에서 확인할 수 있습니다.
예시
서버 운영데이터베이스 관리자SAP Basis 팀클라우드 인프라
|
|||
|
변경 유형
ChangeType
|
표준, 일반, 긴급 등 변경의 분류입니다. | ||
|
설명
이 속성은 변경의 성격과 따라야 하는 프로세스에 따라 변경 요청을 분류합니다. 일반적인 유형으로는 사전 승인된 저위험 변경인 표준 변경, 전체 평가와 승인이 필요한 일반 변경, 긴급한 문제로 신속한 처리가 필요한 긴급 변경이 있습니다. 변경 유형별 분석은 프로세스 차이를 파악하는 데 중요합니다. 예를 들어 '긴급 변경 건수 및 영향' 대시보드는 이 필드를 사용해 긴급 변경과 서비스 안정성에 미치는 영향을 추적합니다. 변경 유형별로 정해진 절차를 따르는지도 확인할 수 있습니다.
중요한 이유
프로세스를 유형별로 나누어 서로 다른 변경 워크플로를 비교하고 분석할 수 있습니다. 규정 준수와 성과 분석에 필요한 속성입니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Change Type' 필드에서 확인할 수 있습니다.
예시
표준일반긴급영향 없음
|
|||
|
상태
Status
|
변경 요청 주기에서 현재 진행 중인 단계 또는 상태입니다. | ||
|
설명
'Status' 필드는 특정 시점의 변경 요청 단계를 나타냅니다. 예를 들어 'Draft', 'Request For Authorization', 'Completed' 등이 있습니다. 활동은 이러한 상태 간 전환을 바탕으로 도출하며, 상태 자체는 현재 작업량을 분석하는 데 유용합니다. 이 속성은 '변경 처리량 및 현재 상태' 대시보드에 사용되어 진행 중인 변경 건수를 단계별로 보여줍니다. 관리자는 이를 통해 진행 중인 작업과 리소스 배분 현황을 파악할 수 있습니다.
중요한 이유
변경 처리 현황을 실시간으로 보여주어 진행 중인 작업과 전체 변경 요청의 현재 상태를 분석할 수 있습니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Status' 필드에서 확인할 수 있습니다.
예시
초안승인 요청일정 수립 완료이행 진행 중완료
|
|||
|
승인 그룹
ApproverGroup
|
특정 단계에서 변경 요청을 승인할 책임이 있는 팀 또는 그룹입니다. | ||
|
설명
이 속성은 변경 사항을 검토하고 승인하도록 지정된 그룹을 나타냅니다. 변경에는 여러 승인 단계가 있을 수 있으므로, 변경 수명 주기 동안 기술 승인팀이나 업무 승인 위원회 등 서로 다른 그룹이 지정될 수 있습니다. 이 속성은 '변경 승인 병목' 대시보드에 중요합니다. 담당 그룹별 승인 소요 시간을 구분해 분석하면 업무가 과중하거나 비효율적으로 처리되어 프로세스가 지연되는 팀을 파악할 수 있습니다.
중요한 이유
담당 팀별 승인 소요 시간을 분석해 승인 프로세스의 병목을 파악할 수 있습니다.
확보 방법
변경 요청과 연결된 승인 관리 양식인 'AP:Signature'에서 가져옵니다. 승인 그룹은 이 레코드에 포함됩니다.
예시
변경 자문 위원회IT 보안네트워크 엔지니어링애플리케이션 개발
|
|||
|
우선순위
Priority
|
변경 요청의 업무상 중요도를 나타내는 우선순위입니다. | ||
|
설명
일반적으로 영향도와 긴급도를 종합해 우선순위를 정하며, 이에 따라 변경 요청의 처리 순서와 속도가 결정됩니다. 우선순위가 높은 변경은 더 신속하게 처리해야 하며, 더 엄격한 서비스 수준 계약(SLA)이 적용될 수 있습니다. 이 속성은 '변경 SLA 성과' 대시보드에서 우선순위별 성과를 구분해 분석하는 데 사용됩니다. '우선순위가 높은 변경의 SLA를 준수하고 있는가?'와 같은 질문에 답하고 리소스 배분을 결정하는 데 도움이 됩니다.
중요한 이유
업무상 중요도에 따라 성과를 분석할 수 있어 가장 중요한 변경을 효율적으로 처리하고 목표를 달성하는 데 도움이 됩니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Priority' 필드에서 확인할 수 있습니다.
예시
매우 높음높음보통낮음
|
|||
|
위험 수준
RiskLevel
|
변경 이행에 따르는 잠재적 위험을 평가한 값입니다. | ||
|
설명
위험 수준은 변경을 이행할 때 부정적인 결과가 발생할 가능성을 정성적 또는 정량적으로 평가한 값입니다. 승인 절차의 주요 입력값으로, 위험이 높은 변경일수록 더 면밀한 검토를 거칩니다. 이 속성은 변경 포트폴리오의 전반적인 위험 노출도를 파악하는 '변경 위험 프로필 분석' 대시보드의 주요 기준입니다. 초기 위험 평가가 미흡해 나중에 재평가하는 재작업 반복도 파악할 수 있습니다.
중요한 이유
프로세스의 규정 준수와 효율성을 분석하는 데 필요한 기준으로, 위험이 높은 변경이 적절한 검토를 받도록 하는 데 도움이 됩니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Risk Level' 필드에서 확인할 수 있습니다.
예시
1 - 매우 높음2 - 높음3 - 보통4 - 낮음5 - 계획 중
|
|||
|
SLA 목표 일시
SLATargetDate
|
변경 요청을 완료해야 하는 목표 날짜와 시간입니다. | ||
|
설명
서비스 수준 계약(SLA) 목표 일시는 변경 요청의 우선순위와 유형에 따라 정해지는 완료 기한입니다. 실제 완료 시간을 이 목표와 비교해 성과를 측정합니다. 이 속성은 '변경 SLA 성과' 대시보드의 기준이 됩니다. 실제 종료 시간과 목표를 비교하면 변경 요청이 SLA를 준수했는지 확인할 수 있습니다. SLA 성과를 분석하면 프로세스 효율성과 서비스 수준 약속의 이행 여부를 평가할 수 있습니다.
중요한 이유
성과 측정 기준으로 활용해 SLA 준수율을 계산하고 기한을 지키기 어려울 수 있는 변경 요청을 식별할 수 있습니다.
확보 방법
일반적으로 관련 SLA 관리 양식에 저장되어 변경 요청과 연결되며, 변경 양식에서도 확인할 수 있습니다.
예시
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
SLA 상태
SLAState
|
SLA 목표 대비 변경 요청의 계산된 상태입니다. | ||
|
설명
이 속성은 완료된 변경 요청이 서비스 수준 계약(SLA)을 준수했는지, 미준수 위험이 있었는지 또는 미준수했는지를 나타냅니다. 실제 완료 시각을 'SLATargetDate'와 비교해 계산합니다. '변경 SLA 성과' 대시보드의 주요 지표입니다. 서비스 약속에 대한 성과를 간결하게 보여주며, 우선순위, 변경 유형 또는 팀별로 데이터를 분석해 SLA 준수율이 낮은 영역을 찾을 수 있습니다.
중요한 이유
약속한 서비스 수준에 대한 성과를 직접 측정해 프로세스 효율성과 서비스 품질을 나타내는 지표로 활용할 수 있습니다.
확보 방법
데이터 변환 과정에서 최종 활동의 시각을 'SLATargetDate'와 비교해 계산합니다.
예시
기한 내 완료미준수 위험미준수
|
|||
|
관련 인시던트 ID
RelatedIncidentID
|
해당 변경으로 인해 발생한 인시던트의 식별자입니다. | ||
|
설명
이 속성은 변경 요청을 이후에 발생했을 수 있는 인시던트와 연결합니다. 이 관계를 통해 변경 사항이 서비스 안정성에 미친 후속 영향을 파악할 수 있습니다. '변경으로 인한 인시던트 발생률' KPI를 계산하는 데 필요한 주요 속성입니다. 이 연결 정보를 추적하면 조직은 변경 프로세스의 품질을 측정하고, 구현 후 문제가 자주 발생하는 변경 유형, 팀 또는 서비스를 식별할 수 있습니다.
중요한 이유
변경 사항의 부정적 영향을 직접 측정해 변경 품질과 위험 관리의 효과를 평가하는 KPI를 제공합니다.
확보 방법
일반적으로 인시던트 양식('HPD:Help Desk')에서 이 관계를 설정합니다. 인시던트의 원인으로 변경 요청을 연결할 수 있습니다.
예시
INC000000987654INC000000987655INC000000987656
|
|||
|
긴급 변경 여부
IsEmergencyChange
|
변경 유형이 'Emergency'인 경우 true로 설정되는 불리언 플래그입니다. | ||
|
설명
이 파생 플래그는 긴급 변경 여부를 명확한 이진 값으로 표시해 분석을 간소화합니다. 'ChangeType' 속성의 값을 기준으로 합니다. 주로 '긴급 변경 건수 및 영향' 대시보드와 '긴급 변경 비율' KPI를 지원하는 데 사용됩니다. 긴급 변경 데이터를 쉽게 필터링하고 집계할 수 있어, 분석 도구에서 복잡한 필터를 설정하지 않고도 발생 빈도와 시간에 따른 추세를 추적할 수 있습니다.
중요한 이유
긴급 변경 데이터를 쉽게 필터링하고 대시보드에서 확인하며 관련 KPI를 계산할 수 있어 분석이 간편해집니다.
확보 방법
데이터 변환 과정에서 생성되는 파생 속성입니다. 로직은 다음과 같습니다. IF 'ChangeType' = 'Emergency' THEN true ELSE false.
예시
truefalse
|
|||
|
긴급도
Urgency
|
변경 이행의 시간적 긴급성을 나타내는 값입니다. | ||
|
설명
긴급도는 변경을 얼마나 신속하게 이행해야 하는지를 나타냅니다. 영향도와 함께 변경 요청의 전체 우선순위를 계산하는 기준입니다. 긴급도는 '변경 위험 프로필 분석' 대시보드의 주요 속성으로, 변경 관리 프로세스에 가해지는 시간 압박을 파악하는 데 도움이 됩니다. 긴급도 추세를 분석하면 시간에 민감한 요청이 많이 발생하는 근본 원인을 찾을 수 있습니다.
중요한 이유
변경의 시간적 긴급성을 나타내며, 프로세스가 긴급도가 서로 다른 요청을 효과적으로 처리하는지 분석하는 데 도움이 됩니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Urgency' 필드에서 확인할 수 있습니다.
예시
1 - 매우 높음2 - 높음3-중간4-낮음
|
|||
|
변경 요청자
ChangeSubmitter
|
변경 요청을 작성하고 제출한 사람입니다. | ||
|
설명
이 속성은 변경 요청을 시작한 사람을 나타냅니다. 일반적으로 시스템의 'Submitter' 또는 'Reported By' 사용자로 기록됩니다. 항상 주요 분석 기준으로 사용되는 것은 아니지만, 변경 요청이 어디서 비롯되는지 파악하는 데 유용합니다. 예를 들어 특정 부서나 직무에서 변경 요청이 주로 발생하는지 분석하면 업무 수요와 계획 수립에 관한 정보를 얻을 수 있습니다.
중요한 이유
변경 요청을 시작한 사람을 파악해 프로세스 내 수요 패턴과 사용자 행동을 분석할 수 있습니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Submitter' 필드에서 확인할 수 있습니다.
예시
Allen AllbrookMary MannBob Baxter
|
|||
|
영향도
Impact
|
변경이 업무 서비스와 IT 인프라에 미칠 것으로 평가된 영향입니다. | ||
|
설명
영향도는 변경이 업무 운영, 서비스, 사용자에게 미칠 수 있는 영향을 측정합니다. 긴급도와 함께 변경 요청의 우선순위를 정하는 주요 기준입니다. 분석에서는 '변경 위험 프로필 분석' 대시보드에 영향도를 활용해 변경 포트폴리오가 업무에 미칠 수 있는 결과를 종합적으로 파악합니다. 영향도가 높은 변경의 분포를 이해하면 위험 관리 전략과 리소스 계획을 세우는 데 도움이 됩니다.
중요한 이유
변경이 업무에 미칠 수 있는 결과를 수치화해 서비스에 미치는 영향의 심각도에 따라 위험을 분석하고 우선순위를 정할 수 있습니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Impact' 필드에서 확인할 수 있습니다.
예시
1 - 광범위2 - 상당함3 - 보통4 - 경미함
|
|||
|
영향을 받는 서비스
AffectedService
|
변경 사항의 영향을 받는 업무 또는 기술 서비스입니다. | ||
|
설명
이 속성은 변경 요청을 Configuration Management Database (CMDB)에 정의된 특정 서비스와 연결합니다. '이메일 서비스'와 같은 사용자 대상 업무 서비스일 수도 있고, '인증 서비스'와 같은 백엔드 기술 서비스일 수도 있습니다. '긴급 변경 건수 및 영향' 대시보드에서 변경 사항과 영향을 받는 서비스를 연결하는 데 사용됩니다. 이를 통해 서비스별 안정성을 파악하고 긴급 조치가 자주 필요한 서비스를 식별할 수 있습니다.
중요한 이유
기술 변경 사항을 업무 서비스에 미치는 영향과 연결해 업무 맥락을 파악하고, 서비스 중심의 프로세스 분석을 지원합니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'ServiceCI' 필드 또는 관련 Configuration Item (CI) 관계에서 가져옵니다.
예시
사내 이메일SAP ERP고객 관계 관리온라인 뱅킹 포털
|
|||
|
재작업 여부
IsRework
|
활동이 재작업 루프에 해당하거나 프로세스의 이전 단계로 되돌아가는지를 나타내는 플래그입니다. | ||
|
설명
변경 요청이 수명 주기의 이전 단계로 돌아가면 이 불리언 속성이 true로 설정됩니다. 예를 들어 'Scheduled'에서 'Risk Assessment'로 되돌아가는 경우입니다. 이러한 역행은 재작업에 해당하며, 비효율의 원인이 되는 경우가 많습니다. 이 플래그는 '변경 재작업률' KPI를 계산하고 '변경 재작업 및 평가 효율성' 대시보드를 지원하는 데 사용됩니다. 재작업 빈도를 수치화하고 자주 발생하는 프로세스 단계를 찾아 초기 계획과 평가에서 개선이 필요한 부분을 파악할 수 있습니다.
중요한 이유
재작업 루프에 포함된 활동을 표시해 프로세스의 비효율을 직접 파악하고, 개선이 필요한 부분에 집중할 수 있습니다.
확보 방법
계산된 속성으로, 케이스의 활동 순서를 분석해 도출합니다. 데이터 변환 과정에서 프로세스 흐름의 역행을 감지하는 로직을 적용합니다.
예시
truefalse
|
|||
|
종료 시간
EventEndTime
|
특정 활동이나 이벤트가 끝난 시점을 나타내는 타임스탬프입니다. | ||
|
설명
종료 시간은 활동이 완료된 시점을 나타냅니다. process mining에서는 해당 케이스의 다음 활동 시작 시간을 종료 시간으로 계산해 앞선 단계의 소요 시간을 구하는 경우가 많습니다. 케이스의 마지막 활동은 시작 시간과 같은 시각을 사용하거나 별도의 종료 타임스탬프를 사용할 수 있습니다. 이 속성은 각 활동의
중요한 이유
활동별 소요 시간을 정확히 계산할 수 있어 병목 파악과 프로세스 성과 측정의 기반이 됩니다.
확보 방법
계산된 속성으로, 일반적으로 데이터 변환 과정에서 해당 케이스의 다음 이벤트 시작 시간을 사용해 도출합니다.
예시
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
종료 코드
CloseCode
|
변경 요청을 종료할 때 최종 결과를 나타내는 코드입니다. | ||
|
설명
종료 코드는 변경 요청을 종료한 사유를 표준화해 나타냅니다. 예를 들어 '성공', '문제 발생 후 성공', '원복', '취소' 등이 있습니다. 최종 상태만으로는 알기 어려운 변경 결과를 더 구체적으로 보여줍니다. 종료 코드를 분석하면 구현된 변경의 품질과 성공률을 평가할 수 있습니다. 예를 들어 '원복'된 변경이 많다면 계획이나 테스트에 문제가 있을 수 있습니다. 이를 프로세스 개선을 위한 지표로 활용할 수 있습니다.
중요한 이유
각 변경의 결과를 명확하고 일관된 형식으로 기록해 성공률과 실패 또는 취소 사유를 분석할 수 있습니다.
확보 방법
'CHG:Infrastructure Change' 양식의 'Status Reason' 또는 이와 유사한 종료 코드 필드에서 확인할 수 있습니다. 이 필드는 마지막 단계에서 활성화됩니다.
예시
성공문제 발생 후 성공원복취소
|
|||
변경 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
변경 요청 생성
|
시스템에 변경 요청 레코드가 처음 생성된 시점을 나타냅니다. CHG:Change 양식에서 변경 요청 항목이 생성된 타임스탬프를 기준으로 이벤트를 기록합니다. | ||
|
중요한 이유
모든 변경 요청의 시작점으로, 전체 처리 주기를 측정하고 접수되는 변경 건수를 분석하는 데 필요합니다.
확보 방법
CHG:Change 양식의 'Submit Date' 또는 감사 로그(예: HPD:Help Desk Audit Log)에 기록된 레코드 생성 타임스탬프를 기준으로 이벤트를 기록합니다.
기록
CHG:Change 양식의 레코드 생성 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
변경 요청 승인
|
변경 요청을 공식 승인하고 진행을 허가하는 주요 단계입니다. 최종 승인이 끝난 뒤 상태가 일반적으로 'Scheduled' 또는 'Planning In Progress'로 바뀌는 시점을 기준으로 추정합니다. | ||
|
중요한 이유
승인 단계가 끝나는 시점으로, 승인 병목과 Average Change Approval Time KPI를 측정하는 데 중요합니다. 프로세스의 주요 의사 결정 단계이기도 합니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 'Request For Authorization'과 같은 승인 상태를 벗어나는 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 최종 승인 단계를 지나 'Scheduled' 등으로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 이행 완료
|
변경 이행 작업이 성공적으로 완료된 시점을 나타냅니다. 일반적으로 상태가 'Completed'로 업데이트되고 사유가 성공으로 표시될 때 기록합니다. | ||
|
중요한 이유
배포 단계가 끝나는 주요 이정표입니다. Change Implementation Cycle Time을 계산하고 변경으로 인한 장애를 분석하는 데 필요합니다.
확보 방법
CHG:Change 양식의 'Status'가 'Completed'이고 'Status Reason'이 'Successful'로 설정된 경우를 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Completed'로 업데이트된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 일정 수립
|
승인된 변경의 이행 일정을 공식적으로 확정한 시점을 나타냅니다. 시스템에서 상태가 'Scheduled'로 바뀌는 시점에 기록합니다. | ||
|
중요한 이유
이 단계는 변경을 이행할 준비가 되었음을 나타내는 주요 이정표입니다. Change Implementation Cycle Time 및 Average Implementation Wait Time KPI 측정의 시작점입니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 상태가 'Scheduled'로 바뀐 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Scheduled'로 업데이트된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 종료
|
시스템에서 변경 요청을 공식 종료하는 마지막 활동입니다. 변경 요청 상태가 'Closed'로 설정될 때 기록합니다. | ||
|
중요한 이유
변경 주기가 성공적으로 끝나는 시점입니다. 전체 프로세스 소요 시간과 처리량을 측정하는 데 필요합니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 상태가 'Closed'로 바뀐 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Closed'로 업데이트된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
위험 평가 완료
|
제안된 변경의 위험 평가가 완료된 시점을 나타냅니다. 변경 요청 상태가 업데이트되거나 특정 위험 평가 작업이 종료된 시점에 기록하는 경우가 많습니다. | ||
|
중요한 이유
이 활동을 추적하면 변경 관리 정책의 규정 준수 여부를 확인할 수 있습니다. 평가 단계의 지연을 파악하고, 프로세스가 이 단계로 되돌아오는 경우 Change Rework Rate를 분석하는 데도 도움이 됩니다.
확보 방법
CHG:Change 양식의 상태 변경(예: '변경 요청' 상태로 전환) 또는 CHG:Task 양식에서 관련 작업이 완료된 시점을 기준으로 도출합니다.
기록
CHG:Task에서 연결된 '위험 평가' 작업이 '종료' 또는 '완료'로 표시된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
테스트 완료
|
변경 이행 후 테스트 또는 검증이 완료된 시점을 나타냅니다. 변경 요청과 연결된 전용 테스트 작업이 종료될 때 기록하는 경우가 많습니다. | ||
|
중요한 이유
이 활동을 추적하면 Average Testing Cycle Time을 측정하고 품질을 확인할 수 있습니다. 최종 검증 전 검증 프로세스의 병목을 파악하는 데도 도움이 됩니다.
확보 방법
상위 변경 요청에 연결된 CHG:Task 양식의 테스트 작업 레코드가 완료된 시점을 기준으로 도출합니다.
기록
CHG:Task에서 연결된 '테스트' 또는 '검증' 작업이 '종료' 또는 '완료'로 표시된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 검증 완료
|
이행과 테스트 후 이해관계자가 변경의 성공 여부를 공식 확인한 시점을 나타냅니다. 최종 종료 전에 상태가 바뀌는 시점으로 기록하는 경우가 많습니다. | ||
|
중요한 이유
검증은 변경을 종료하기 전 마지막 품질 확인 단계입니다. 변경이 목표를 달성했으며 의도하지 않은 부정적 영향을 일으키지 않았는지 확인합니다.
확보 방법
CHG:Change 양식의 상태가 'Completed'에서 'Verification' 또는 'Closed'로 바뀌는 등의 변경을 기준으로 추정합니다.
기록
이행 활동 후 CHG:Change의 'Status' 필드가 'Closed'로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 요청 거부
|
승인자가 변경 요청을 공식적으로 거부한 시점을 나타냅니다. 상태가 'Rejected'로 바뀌는 시점에 기록하며, 프로세스의 종료 상태에 해당합니다. | ||
|
중요한 이유
거부 사유를 추적하면 정보 누락이나 높은 위험 등 거부 원인을 파악할 수 있습니다. 이를 분석해 향후 변경 요청의 품질을 높일 수 있습니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 상태가 'Rejected'로 전환된 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Rejected'로 업데이트된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 요청 제출
|
변경 요청을 검토와 승인을 위해 공식 제출한 시점을 나타냅니다. 일반적으로 변경 요청 상태가 'Draft'에서 'Request For Authorization'으로 바뀌는 시점으로 추정합니다. | ||
|
중요한 이유
이 활동부터 승인 절차가 시작됩니다. 최초 검토를 기다리는 시간을 측정하고 Change Approval Time KPI를 분석하려면 이 활동을 추적해야 합니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 'Request For Authorization'으로 전환된 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Draft'에서 'Request For Authorization'으로 변경된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
변경 취소
|
변경 요청이 이행 또는 완료되기 전에 취소된 상태를 나타냅니다. 변경 요청 상태가 'Cancelled'로 업데이트될 때 기록합니다. | ||
|
중요한 이유
취소를 추적하면 변경 요청을 철회한 이유를 파악할 수 있습니다. 초기 계획 미흡, 우선순위 변경, 리소스 제약 등의 문제를 확인하는 데 도움이 됩니다.
확보 방법
CHG:Change 양식의 상태 변경 이력에서 상태가 'Cancelled'로 바뀐 시점을 기준으로 추정합니다.
기록
CHG:Change의 'Status' 필드가 'Cancelled'로 업데이트된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
영향 분석 완료
|
변경으로 발생할 수 있는 결과를 파악하기 위한 영향 분석이 완료된 시점을 나타냅니다. 일반적으로 상태 업데이트나 관련 작업 종료를 기준으로 추정합니다. | ||
|
중요한 이유
이 활동은 계획 효율성과 재작업에 미치는 영향을 파악하는 데 중요합니다. 소요 시간과 발생 빈도를 분석하면 초기 평가 단계를 개선할 수 있습니다.
확보 방법
CHG:Task 양식의 '영향 분석' 작업 완료 시각 또는 CHG:Change 양식의 특정 상태 전환을 기준으로 도출합니다.
기록
CHG:Task에서 연결된 '영향 분석' 작업이 '종료' 또는 '완료'로 표시된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
이행 계획 수립
|
변경 이행을 위한 세부 계획을 작성하고 문서화한 상태를 나타냅니다. 일반적으로 변경과 연결된 계획 작업이 완료될 때 기록합니다. | ||
|
중요한 이유
이 활동이 완료되어야 일정을 수립하고 변경을 이행할 수 있습니다. 소요 시간을 분석하면 변경 실행 전 계획 단계의 지연을 파악할 수 있습니다.
확보 방법
상위 변경 요청에 연결된 CHG:Task 양식의 특정 계획 작업 레코드가 완료된 시점을 기준으로 도출합니다.
기록
CHG:Task에서 연결된 '구현 계획' 작업이 '종료' 또는 '완료'로 표시된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
이행 후 검토
|
변경 이행 후 공식 검토가 완료된 시점을 나타냅니다. 일반적으로 이행 후 검토(PIR) 작업이 종료될 때 기록합니다. | ||
|
중요한 이유
이 활동은 조직의 학습과 프로세스 개선에 중요합니다. Post-Implementation Review Rate KPI를 측정하면 변경에서 얻은 교훈을 반영하고 있는지 확인할 수 있습니다.
확보 방법
상위 변경 요청에 연결된 CHG:Task 양식의 '구현 후 검토' 작업이 완료된 시점을 기준으로 도출합니다.
기록
CHG:Task에서 연결된 'PIR' 작업이 '종료' 또는 '완료'로 표시된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 준비해 오늘부터 변경 관리 프로세스 개선을 시작하세요. 운영 전반의 현황을 파악하고 효율을 높일 수 있습니다.
변경 관리를 개선해 서비스 중단을 예방하세요
변경 성공률을 95%로 높이고 서비스 중단에 따른 비용을 줄이세요.
신용카드가 필요하지 않습니다. 설정은 몇 분이면 완료됩니다.