변경 관리 데이터 템플릿

변경 요청 ID는 변경 요청을 생성할 때마다 부여되는 고유한 영숫자 코드입니다. 단일 변경 케이스의 기본 키로, 요청 시작부터 종료까지 관련된 모든 작업, 승인 및 로그를 연결합니다.

process mining에서는 각 변경의 전체 진행 과정을 재구성하는 데 이 속성이 필요합니다. 공통 변경 요청 ID를 기준으로 이벤트를 묶으면 분석가는 프로세스 흐름을 시각화하고, 케이스 처리 시간을 계산하며, 변경 생애주기별 차이를 분석할 수 있습니다. 이 ID를 바탕으로 케이스 단위 분석을 수행하면 개별 변경이 시스템에서 어떻게 진행되는지 명확하게 파악할 수 있습니다.

단일 변경과 관련된 모든 이벤트를 추적하고 연결하는 데 필요한 ID로, 프로세스 발견과 적합성 검사에 중요한 기준이 됩니다.

일반적으로 변경 요청 트랜잭션의 헤더나 기본 레코드에서 확인할 수 있습니다.

이벤트 시작 시간은 변경 요청 생애주기에서 활동이 시작된 시점을 나타냅니다. 이벤트를 시간순으로 정렬하고 활동별 처리 시간과 전체 케이스 처리 시간을 계산하는 데 필요한 타임스탬프입니다.

프로세스 분석에서는 활동을 올바른 순서로 정렬해 이벤트 로그를 구성하는 데 사용합니다. 활동 간 주기 시간, 대기 시간, 전체 케이스 처리 시간 등 시간 관련 지표를 계산하는 데도 필요합니다. 타임스탬프를 분석하면 시간이 가장 오래 걸리는 단계를 파악하고 프로세스를 단축할 기회를 찾을 수 있습니다.

이벤트 순서를 정하고 프로세스 흐름을 파악하며 주기 시간과 대기 시간 등 성과 지표를 계산하는 데 필요합니다.

변경 요청의 이벤트 로그나 감사 추적에서 확인할 수 있습니다. '생성일', '시작일' 또는 '타임스탬프'로 표시되기도 합니다.

활동명은 변경 요청 생애주기의 개별 단계나 주요 시점을 나타냅니다. 예를 들어 '위험 평가 완료' 또는 '변경 승인'이 이에 해당합니다. 각 활동은 작업이 수행되거나 의사결정이 내려지거나 프로세스가 다음 단계로 넘어간 시점을 나타냅니다.

이 속성은 프로세스 맵을 구성하는 데 기본이 됩니다. 프로세스 그래프의 노드를 정의하므로 분석가는 이벤트 순서를 시각화하고, 일반적인 경로를 파악하며, 표준 절차에서 벗어난 흐름을 찾을 수 있습니다. 활동을 분석하면 병목, 재작업 반복, 변경 프로세스 단계 간 비효율적인 인계도 확인할 수 있습니다.

프로세스 단계를 정의해 흐름을 시각화하고 병목, 재작업 및 이탈을 분석할 수 있습니다.

일반적으로 변경 요청과 연결된 활동 로그, 이벤트 이력 또는 감사 추적 테이블에서 확인할 수 있습니다.

소스 시스템 속성은 이벤트 데이터의 출처를 나타냅니다. 여러 ITSM 도구나 통합 시스템을 사용하는 환경에서는 데이터 출처를 구분하고 데이터 무결성과 맥락을 확인하는 데 도움이 됩니다.

주요 프로세스 흐름 분석에 항상 사용되는 것은 아니지만, 데이터 검증과 거버넌스에 유용합니다. 데이터 수집 문제를 해결하고, 별도 플랫폼을 사용하는 시스템이나 사업부 간 프로세스 성과를 비교할 때도 활용할 수 있습니다. 예를 들어 인프라 변경과 애플리케이션 변경에 서로 다른 시스템을 사용하는 기업이 있습니다.

데이터 출처를 식별하므로 데이터 검증, 문제 해결, 여러 시스템에 걸친 프로세스 분석에 필요합니다.

소스 데이터의 필드에 저장되어 있거나 데이터 추출 및 변환(ETL) 과정에서 추가될 수 있습니다.

최종 데이터 업데이트 타임스탬프는 특정 레코드를 소스 시스템에서 마지막으로 가져온 시점을 나타냅니다. 데이터 파이프라인을 관리하고 분석에 최신 데이터가 반영되도록 하는 데 필요한 메타데이터입니다.

데이터 엔지니어와 분석가는 이 속성을 통해 데이터의 최신성을 확인할 수 있습니다. 데이터 추출 프로세스의 상태를 모니터링하고 process mining 분석이 최근의 관련 정보를 기반으로 하는지 확인하는 데 사용합니다. 일반적으로 프로세스 자체를 분석할 때는 사용하지 않지만, 데이터 거버넌스와 신뢰성을 위해 중요합니다.

데이터의 최신성을 확인하고 데이터 파이프라인 상태를 모니터링해 프로세스 분석의 신뢰성을 높입니다.

일반적으로 데이터 추출, 변환 및 적재(ETL) 과정에서 생성되어 추가됩니다.

담당 사용자는 변경 요청이나 활동을 맡은 특정 담당자입니다. 팀 단위 할당보다 세분화된 업무량과 책임 현황을 보여줍니다.

사용자 단위 데이터를 분석하면 성과 관리와 교육 기회 파악에 도움이 됩니다. 프로세스에 숙련된 담당자나 특정 작업에 어려움을 겪는 담당자를 확인할 수 있습니다. 재작업 분석에도 활용할 수 있습니다. 예를 들어 특정 담당자가 처리한 변경이 더 자주 거부되거나 보완이 필요한지 확인할 수 있습니다. 다만 이 정보는 징계 목적이 아니라 개선을 위해 신중하게 사용해야 합니다.

개인별 업무량과 성과를 세부적으로 분석해 팀 내 전문가와 교육이 필요한 영역을 파악할 수 있습니다.

일반적으로 변경 요청 레코드나 작업별 세부 정보에서 확인할 수 있으며, '담당자' 또는 '할당 대상'으로 표시되기도 합니다.

담당 팀은 특정 단계에서 변경 작업을 맡은 사람들의 그룹을 나타냅니다. 평가 팀, CAB와 같은 승인 위원회 또는 구현을 수행하는 기술 팀이 이에 해당할 수 있습니다.

이 속성은 리소스 배분, 업무량 분포 및 팀 간 인계를 분석하는 데 필요합니다. 소셜 네트워크 분석을 통해 그룹 간 소통 패턴과 병목을 파악할 수 있습니다. 팀별 소요 시간을 측정하면 업무가 과중한 그룹이나 책임을 넘기는 과정에서 지연이 자주 발생하는 지점을 찾을 수 있습니다.

팀 간 인계를 분석하고 리소스 병목을 찾아 조직 전체의 업무량 분포를 파악하는 데 필요합니다.

변경 요청 레코드나 활동별 세부 정보에서 확인할 수 있습니다. '할당 그룹' 또는 '팀'으로 표시되기도 합니다.

변경 상태는 특정 시점의 변경 요청 단계나 최종 결과를 나타냅니다. 일반적으로 프로세스의 주요 시점과 연결되어 진행 상황을 개괄적으로 보여줍니다.

이 속성은 두 가지 방식으로 사용할 수 있습니다. 현재 상태를 보여주는 스냅샷 속성으로는 열려 있는 변경 요청의 현황을 확인할 수 있어 처리량과 적체를 추적하는 운영 대시보드에 유용합니다. 이벤트 속성으로는 상태 변경 자체를 활동으로 간주할 수 있어 상세 활동 데이터가 부족할 때 이벤트 로그를 보완할 수 있습니다. 상태 전환을 분석하면 생애주기를 파악하고 변경이 지연되는 지점을 찾을 수 있습니다.

변경 진행 상황을 보여주므로 병목, 처리량 및 현재 변경 적체 상태를 분석할 수 있습니다.

변경 요청의 헤더 레코드에서 확인할 수 있습니다. 과거 상태 변경 이력은 감사 로그에 있을 수 있습니다.

변경 유형은 변경 요청에 필요한 워크플로, 승인 단계 및 긴급도를 결정하는 중요한 분류입니다. 표준 변경은 일반적으로 사전 승인된 저위험 변경입니다. 일반 변경은 전체 평가 및 승인 절차를 따르며, 긴급 변경은 긴급한 업무상 필요에 따라 신속하게 처리합니다.

변경 유형별 프로세스 분석은 변경 관리 분석의 주요 활동입니다. 유형별 워크플로의 성과와 규정 준수를 비교할 수 있습니다. 예를 들어 긴급 변경이 실제로 더 빠른 경로를 따르는지, 표준 변경이 간소화된 사전 승인 절차를 따르는지 확인할 수 있습니다. 이렇게 구분하면 프로세스 차이를 파악하고 적절한 수준의 거버넌스가 적용되는지 확인할 수 있습니다.

변경 유형마다 정해진 프로세스 흐름, 승인 요건 및 성과 기대치가 다르므로 분석을 구분하는 데 필요합니다.

변경 요청의 기본 레코드나 헤더 데이터에서 확인할 수 있습니다.

영향받는 업무 서비스는 변경 대상인 핵심 업무 기능을 나타냅니다. 예를 들어 '이메일 서비스'나 '온라인 뱅킹'이 있습니다. 업무 서비스를 지원하는 서버나 애플리케이션 같은 특정 기술 구성 항목(CI)일 수도 있습니다.

이 속성은 변경 관리 프로세스에 중요한 업무 맥락을 제공합니다. IT 활동만이 아니라 업무 영향을 기준으로 분석할 수 있습니다. 예를 들어 변경이 가장 자주 발생하는 서비스를 찾아 불안정성이나 높은 혁신 활동을 나타내는지 확인할 수 있습니다. 또한 기술 변경을 지원 대상 업무 기능과 연결해 변경 우선순위와 위험을 평가하는 데 도움이 됩니다.

IT 변경을 업무 맥락과 연결해 변경 활동과 관련 위험의 영향을 가장 많이 받는 업무 서비스를 분석할 수 있습니다.

변경 요청의 기본 레코드에서 확인할 수 있으며, 구성 관리 데이터베이스(CMDB)와 연결되어 있는 경우가 많습니다.

변경 우선순위는 변경 요청의 상대적 중요도를 정하는 분류입니다. 팀이 일정을 정하고 리소스를 배분해 중요한 변경부터 처리하도록 돕습니다. 우선순위는 변경이 업무에 미칠 수 있는 영향과 구현의 긴급도를 바탕으로 정하는 경우가 많습니다.

process mining에서는 우선순위를 기준으로 데이터를 필터링하고 비교할 수 있습니다. 분석가는 우선순위가 높은 변경이 낮은 변경보다 실제로 더 빠르게 처리되는지 확인할 수 있습니다. 차이가 있다면 리소스 배분 문제, 중요 변경의 승인 병목 또는 우선순위 규칙의 일관성 없는 적용을 나타낼 수 있습니다.

우선순위가 높은 변경이 낮은 변경보다 빠르게 처리되는지 분석해 우선순위 정책의 효과를 확인할 수 있습니다.

변경 요청의 기본 레코드나 헤더 데이터에서 확인할 수 있습니다.

위험 수준은 변경 실패 가능성과 그에 따른 잠재적 부정적 영향을 평가한 값입니다. 이 평가에 따라 필요한 테스트, 검토 및 승인 수준이 달라집니다. 일반적으로 위험이 높은 변경은 낮은 변경보다 더 엄격한 검토 절차를 거칩니다.

이 속성을 사용하면 위험을 기준으로 프로세스를 분석할 수 있습니다. 예를 들어 위험이 높은 변경이 Change Advisory Board(CAB)의 검토를 받는 등 적절한 수준의 검토를 거치는지 확인할 수 있습니다. 위험 수준과 결과를 연계해 위험이 높은 변경의 실패율이 더 높은지 분석할 수도 있습니다. 실패율이 높다면 위험 평가나 완화 절차를 개선해야 할 수 있습니다.

프로세스 통제와 승인 워크플로가 평가된 변경 위험에 맞게 적용되는지 분석할 수 있습니다.

변경 요청의 헤더 데이터나 위험 평가 세부 정보에서 확인할 수 있습니다.

이벤트 종료 시간은 활동이 끝난 시점을 나타냅니다. 이벤트 시작 시간과 함께 사용하면 변경 생애주기의 각 단계에 걸린 처리 시간을 정확하게 계산할 수 있습니다.

이 속성은 성과 분석의 기본이 됩니다. 시작 시간과 종료 시간의 차이는 활동의 처리 시간을 나타내고, 한 활동의 종료 시점부터 다음 활동의 시작 시점까지는 대기 시간을 나타냅니다. 이 차이를 구분하면 지연이 작업 자체에 오래 걸려서 발생하는지, 작업 사이의 유휴 시간 때문에 발생하는지 파악해 개선 방향을 정할 수 있습니다.

활동별 소요 시간을 정확히 계산해 부가가치가 있는 처리 시간과 부가가치가 없는 대기 시간을 구분할 수 있습니다.

활동 로그나 감사 추적 테이블에서 확인할 수 있습니다. 값이 없다면 다음 이벤트의 시작 시간으로 계산할 수 있는 경우도 있습니다.

변경 결과 사유는 변경 요청이 해당 결과로 종료된 이유를 설명합니다. 성공한 변경은 '성공'으로 표시할 수 있습니다. 실패한 변경은 '실패 - 롤백 시작'으로 표시할 수 있습니다. 거부되거나 취소된 변경에는 '근거 불충분' 또는 '요청자 취소'와 같은 사유가 기록됩니다.

이 속성은 실패하거나 거부된 변경의 근본 원인을 분석하는 데 중요합니다. 사유를 분류하고 분석하면 반복되는 실패 유형을 찾을 수 있습니다. 예를 들어 '정보 불충분'으로 거부되는 변경이 많다면 변경 제출 절차를 개선해야 한다는 신호일 수 있습니다. 이 데이터는 변경 실패율과 최초 승인율 같은 KPI를 계산하고 이해하는 데도 도움이 됩니다.

실패, 거부 또는 취소된 변경의 근본 원인을 분석하는 데 필요한 데이터를 제공해 향후 변경 요청의 품질을 높일 수 있습니다.

변경 요청 레코드의 종료 세부 정보에서 확인할 수 있습니다. '종료 코드', '해결 방법' 또는 '거부 사유'로 표시되기도 합니다.

계획 완료일은 변경의 마감일로, 업무 요건이나 서비스 수준 계약(SLA)에 따라 정하는 경우가 많습니다. 변경 관리 프로세스의 적시성과 성과를 측정하는 기준으로 사용됩니다.

이 속성은 SLA 성과 분석에 필요합니다. 실제 완료일과 계획 완료일을 비교하면 주요 성과 지표인 정시 완료율을 계산할 수 있습니다. 계획일을 지키지 못한 변경을 분석하면 승인 병목, 리소스 제약 또는 비현실적인 계획 등 지연의 근본 원인을 찾을 수 있습니다.

SLA 규정 준수와 정시 완료를 측정하고 프로세스 지연의 근본 원인을 파악하는 데 필요한 속성입니다.

일반적으로 변경 요청의 헤더 데이터에서 확인할 수 있습니다.

변경 긴급도는 업무 요건을 충족하기 위해 변경을 얼마나 빨리 구현해야 하는지를 나타냅니다. 잠재적 영향도와는 별도로 시간적 시급성을 반영합니다. 예를 들어 영향도는 낮지만 마케팅 캠페인 시작 전에 사소한 문제를 해결해야 하는 변경은 긴급도가 높을 수 있습니다.

긴급도는 우선순위를 계산하는 주요 요소이며, 변경 관리 프로세스가 적시에 대응하는지 분석하는 데 사용됩니다. 분석가는 긴급도가 높은 변경이 실제로 더 빠르게 처리되는지 확인할 수 있습니다. 긴급도별 주기 시간을 비교하면 프로세스가 업무 요구에 맞게 대응하는지, 시간적 시급성과 관계없이 모든 변경을 같은 속도로 처리하는지 파악할 수 있습니다.

긴급도별 주기 시간을 비교해 시간에 민감한 업무 요구에 프로세스가 얼마나 신속하게 대응하는지 분석할 수 있습니다.

변경 요청의 기본 레코드나 헤더 데이터에서 확인할 수 있습니다.

변경 사유는 변경 요청의 배경이 되는 업무상 동인을 설명하는 텍스트입니다. '왜 이 변경을 진행하는가?'에 답하며, '중요 취약점 보안 패치' 또는 '고객 경험 개선을 위한 신규 기능'과 같은 맥락을 제공합니다.

자유 형식 텍스트인 경우가 많지만, 분류하거나 텍스트 마이닝 기법으로 분석하면 유용한 정성적 정보를 얻을 수 있습니다. 업무 부문별 변경 수요를 파악하는 데 도움이 됩니다. 예를 들어 변경의 상당수가 버그 수정 때문이라면 소프트웨어 품질 문제를 시사할 수 있습니다. 특정 기간에 전략적 프로젝트 관련 변경이 많아지는 경우도 확인할 수 있습니다.

변경을 시작하는 업무상 이유를 파악해 조직 내 주요 변경 동인을 분석할 수 있습니다.

일반적으로 변경 요청의 최초 제출 양식이나 헤더 세부 정보에서 확인할 수 있습니다.

변경 영향도는 변경이 업무 운영, 서비스 또는 인프라에 미칠 수 있는 영향을 나타냅니다. 긴급도와 함께 변경의 전체 우선순위를 정하는 주요 기준입니다. 예를 들어 고객이 직접 이용하는 중요 서비스에 영향을 주는 변경은 영향도가 높습니다.

영향도별 분석을 통해 중요 서비스에 영향을 주는 변경을 적절히 관리할 수 있습니다. 적합성 검사에서 영향도가 높은 변경이 특정 승인이나 테스트 단계를 반드시 거치는지 확인할 수 있습니다. 영향도가 높은 변경은 검토와 테스트가 더 광범위해 구현에 시간이 더 걸리는지도 비교할 수 있습니다.

업무 영향도가 높은 변경이 더 엄격한 검토와 테스트 절차를 거치는지 확인해 적절한 거버넌스가 적용되도록 합니다.

변경 요청의 기본 레코드나 헤더 데이터에서 확인할 수 있습니다.