문제 관리 데이터 템플릿

BMC Helix ITSM
문제 관리 데이터 템플릿

문제 관리 데이터 템플릿

이 템플릿은 BMC Helix ITSM의 근본 원인 조사 워크플로를 분석하는 데 필요한 구조를 제공합니다. 상세한 이벤트 로그를 만드는 데 필요한 속성과 프로세스 활동, 데이터 추출 방법을 함께 안내합니다. 가이드를 따라 분석하면 숨은 병목을 찾아내고 인시던트를 근본적으로 해결하는 과정을 간소화할 수 있습니다.
  • 근본 원인 분석에 필요한 데이터 필드
  • 추적을 위한 표준 프로세스 단계
  • BMC Helix ITSM 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

문제 관리 속성

이 표에는 문제 관리 전체 주기를 면밀히 분석하는 데 필요한 이벤트 로그 데이터 필드가 정리되어 있습니다.
5 필수 9 권장 5 선택 사항
이름 설명
문제 기록
ProblemRecord
문제 조사 사례를 식별하는 고유 ID입니다.
설명

이 속성은 문제 관리 프로세스에서 사례를 식별하는 기준이 됩니다. BMC Helix ITSM에서는 일반적으로 PBM:Problem Investigation 양식의 'Problem ID' 필드에 해당하며, 예를 들어 PBI00000012345와 같은 값이 사용됩니다. 문제를 처음 등록한 시점부터 최종 종결 및 구현 후 검토까지 관련된 모든 활동을 연결합니다.

process mining 분석에서는 이 속성을 기준으로 개별 이벤트를 하나의 프로세스 인스턴스로 묶습니다. 이를 통해 분석가는 특정 문제 조사 사례의 전체 흐름을 시각화할 수 있습니다. 이 식별자가 없으면 서로 다른 지원 그룹과 조정 담당자가 수행한 작업을 순서대로 연결할 수 없습니다.

이 필드는 이벤트 로그의 기본 키로 사용되며, 문제별 총 주기 시간이나 우선순위별 문제 수와 같은 사례 단위 집계를 계산하는 데 필요합니다.

중요한 이유

프로세스 뷰를 구성하고 특정 문제의 전체 처리 과정을 추적하는 데 필요한 기본 키입니다.

확보 방법

PBM:Problem Investigation 양식의 'Problem ID' 필드

예시
PBI00000004512PBI00000004513PBI00000004514
이벤트 시간
EventTime
특정 활동이 발생한 시각입니다.
설명

이 속성은 활동이 발생한 정확한 날짜와 시간을 기록합니다. BMC Helix ITSM에서는 'Submit Date', 'Last Modified Date' 필드나 상태 변경 이력을 담은 테이블의 타임스탬프에 해당합니다.

분석 시 이벤트를 시간순으로 정렬하고 소요 시간을 계산하는 데 사용합니다. 이를 통해 'Investigation Cycle Time'이나 'Workaround Publication Lead Time'처럼 프로세스의 두 지점 사이에 걸리는 시간을 측정할 수 있습니다.

정확한 타임스탬프는 병목을 찾는 데 중요합니다. 연속된 이벤트 사이의 시간 차이를 계산하면 초기 배정 단계인지 최종 검토 단계인지, 지연이 발생한 지점을 정확히 파악할 수 있습니다.

중요한 이유

시간 기반 KPI를 계산하고 이벤트 순서를 정하는 데 사용됩니다.

확보 방법

PBM:Problem Investigation과 연결된 이력 테이블 또는 감사 로그

예시
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
활동
Activity
발생한 특정 작업 또는 상태 변경 이벤트입니다.
설명

이 속성은 'Problem Record Logged', 'Root Cause Identified', 'Solution Database Updated'와 같이 문제 관리 수명 주기에서 수행된 구체적인 단계를 나타냅니다. BMC Helix에서는 Problem Investigation 모듈의 상태 이력, 감사 로그 또는 특정 트랜잭션 타임스탬프를 바탕으로 도출하는 경우가 많습니다.

이 속성은 프로세스 탐색의 중심이 됩니다. 활동 순서를 분석하면 process mining 도구가 프로세스 맵을 구성해 설계된 프로세스와 실제 업무 흐름을 비교하고, 반복 경로와 재작업, 표준 운영 절차에서 벗어난 부분을 보여줍니다.

실제로 어떤 일이 있었는지 파악하려면 활동 이름을 정확히 기록해야 합니다. 이 데이터를 활용하면 근본 원인 파악부터 변경 요청 시작까지와 같이 특정 단계 사이의 전환 시간을 측정할 수 있습니다.

중요한 이유

프로세스 맵의 노드를 정의하고 워크플로를 시각화하는 데 사용됩니다.

확보 방법

PBM:Problem Investigation 상태 이력 또는 PBM:AuditLogSystem에서 도출

예시
문제 기록 등록지원 그룹에 배정조사 시작근본 원인 파악
소스 시스템
SourceSystem
데이터가 생성된 시스템입니다.
설명

이 속성은 프로세스 데이터를 추출한 소프트웨어 시스템을 식별합니다. 여기서는 'BMC Helix ITSM'이 해당합니다. 여러 ITSM, 개발 또는 외부 공급업체 도구의 데이터를 process mining에 통합하는 다중 시스템 환경에서 특히 중요합니다.

분석 시 이 필드는 기록의 출처를 확인하는 메타데이터로 사용됩니다. 예를 들어 프로세스 뷰에 문제 관리를 위한 BMC Helix 데이터와 소프트웨어 개발을 위한 별도 시스템(예: Jira)의 데이터가 함께 포함된 경우, 이 속성으로 출처별 분석을 나눌 수 있습니다.

기술 문제를 해결할 때도 도움이 됩니다. 데이터 품질 문제가 발생하면 소스 시스템을 확인해 특정 추출 절차나 원본 데이터베이스까지 원인을 추적할 수 있습니다.

중요한 이유

특히 여러 시스템의 데이터를 통합한 프로세스 뷰에서 데이터의 출처를 추적하고 맥락을 파악할 수 있습니다.

확보 방법

추출 과정에서 고정값으로 입력

예시
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
최종 데이터 업데이트
LastDataUpdate
데이터를 추출하거나 마지막으로 새로 고친 시각입니다.
설명

이 속성은 데이터를 process mining 애플리케이션에 마지막으로 불러온 시점을 나타냅니다. 분석가는 이를 통해 조회 중인 데이터가 최신인지 확인할 수 있습니다. 일반적으로 추출 스크립트나 데이터 파이프라인 도구가 생성합니다.

분석 시 오래된 데이터를 바탕으로 의사결정을 내리는 일을 방지하는 데 도움이 됩니다. 예를 들어 관리자가 '미해결 문제 기록'을 볼 때 데이터가 한 시간 전에 업데이트됐는지 일주일 전에 업데이트됐는지에 따라 현재 업무량에 대한 해석이 달라집니다.

증분 데이터 로드에도 사용됩니다. 마지막 업데이트 시점을 추적하면 ETL 프로세스가 이전 추출 이후 변경된 기록만 가져올 수 있어 성능을 높이고 시스템 부하를 줄입니다.

중요한 이유

데이터의 최신 상태를 확인하고 증분 데이터 로드 방식을 지원합니다.

확보 방법

추출 시점의 시스템 시간

예시
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
SLA 기한
SLADueDate
문제를 해결해야 하는 목표 날짜와 시간입니다.
설명

서비스 수준 계약에 따라 문제를 해결해야 하는 기한을 나타내는 속성입니다. BMC Helix에서는 'Target Resolution Date' 또는 계산된 SLA 마일스톤 타임스탬프에 해당하는 경우가 많습니다.

'SLA 준수 및 위반 추이' 대시보드의 기준이 됩니다. 이 타임스탬프를 '해결 확인' 활동의 타임스탬프와 비교해 SLA를 준수했는지 위반했는지 계산합니다.

이 날짜를 시각화하면 팀이 기한에 얼마나 임박해 문제를 해결하는지 확인할 수 있습니다. 며칠 전에 해결하는지, 아니면 SLA 위반 직전에야 해결하는지 파악해 리소스 계획에 반영할 수 있습니다.

중요한 이유

규정 준수 및 적시성 지표를 계산하는 기준입니다.

확보 방법

PBM:Problem Investigation 양식의 'Target Resolution Date' 필드

예시
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
SLA 위반 여부
IsSLABreached
문제 해결에 허용된 시간을 초과했는지 나타내는 플래그입니다.
설명

문제 레코드가 서비스 수준 계약을 위반했는지 나타내는 참/거짓 속성입니다. '해결 확인' 타임스탬프를 'SLA 기한'과 비교하거나 SLM 상태에서 직접 가져와 계산합니다.

'SLA 준수 및 위반 추이' 대시보드에 사용됩니다. 프로세스를 준수와 미준수로 간단히 구분할 수 있어, 실패한 프로세스의 특성을 쉽게 확인할 수 있습니다(예: 'SLA를 위반한 사례는 모두 X 지원 그룹이 담당했는가?').

프로세스 실패의 근본 원인을 분석할 때 주요 필터로 활용됩니다. 'IsSLABreached = True'로 필터링한 다음 프로세스 맵에서 공급업체 승인을 기다리는 시간이 길어지는 등 지연이 발생한 지점을 확인할 수 있습니다.

중요한 이유

규정 준수 보고와 실패 원인 분석을 간소화합니다.

확보 방법

SLM:Measurement 양식 또는 계산값

예시
truefalse
관련 인시던트 수
RelatedIncidentCount
이 문제 레코드에 연결된 인시던트 수입니다.
설명

문제와 연결된 인시던트 수를 집계해 문제의 영향을 수치화하는 속성입니다. BMC Helix에서는 PBM 레코드와 관련된 HPD:Help Desk 양식의 레코드 수를 집계하는 경우가 많습니다.

'인시던트 연결 밀도' KPI를 산출하는 데 사용됩니다. 수치가 높으면 서비스 데스크에 상당한 부담을 주는 영향도 높은 문제일 수 있습니다. '우선순위'와 함께 분석하면 인시던트가 많이 발생한 문제가 실제로 중요 문제로 처리되는지 확인할 수 있습니다.

백로그의 우선순위를 정하는 데도 도움이 됩니다. 인시던트 500건이 연결된 문제는 인시던트 1건만 연결된 '긴급' 문제보다 우선 처리할 수 있습니다. 전자를 해결하면 서비스 데스크의 업무 부담을 더 크게 줄일 수 있기 때문입니다.

중요한 이유

문제가 운영에 미치는 영향과 사용자의 불편을 수치화합니다.

확보 방법

HPD:Associations 또는 HPD:Help Desk에서 관련 행을 집계해 계산

예시
15120
근본 원인 범주
RootCauseCategory
문제의 근본 원인을 분류한 값입니다.
설명

이 속성에는 근본 원인을 파악할 때 선택한 범주(예: '소프트웨어 오류', '하드웨어 장애', '프로세스 공백')가 저장됩니다. BMC Helix에서는 일반적으로 'Root Cause' 또는 'Generic Categorization' 메뉴에서 선택합니다.

이 속성은 '해결 효과 및 품질' 뷰에 필요합니다. 조직은 특정 근본 원인 유형과 재작업률 또는 조사 시간의 상관관계를 확인할 수 있습니다. 예를 들어 '소프트웨어 오류' 문제를 해결하는 데 '하드웨어 장애' 문제보다 두 배 더 오래 걸리는 패턴이 드러날 수 있습니다.

'근본 원인 분류율'을 계산하는 데도 사용됩니다. 이 필드의 값 중 '알 수 없음'이나 '기타'가 차지하는 비율이 높다면 기술 교육을 강화하거나 분류 항목을 더 세분화할 필요가 있음을 나타냅니다.

중요한 이유

시스템 전반의 문제 추세를 분석하고 선제적인 문제 관리를 지원합니다.

확보 방법

PBM:Problem Investigation 양식의 'Root Cause' 또는 분류 탭 필드

예시
소프트웨어 모듈네트워크 인프라인적 오류
문제 관리 담당자
ProblemCoordinator
조사를 조정하도록 지정된 담당자입니다.
설명

이 속성은 문제 기록을 담당하는 특정 사용자를 나타냅니다. BMC Helix ITSM에서는 'Problem Coordinator' 필드에 해당합니다. 다른 사람에게 작업을 위임하더라도 이 담당자가 문제의 전체 처리 과정을 관리합니다.

이 속성은 '지원 그룹 업무량 분배' 대시보드에 활용됩니다. 관리자는 이를 통해 특정 담당자에게 조사가 과도하게 몰리는지, 다른 담당자에게 여력이 있는지 확인할 수 있습니다. 개인별 성과를 분석해 교육이 필요한 담당자나 성과가 높은 담당자를 파악하는 데도 도움이 됩니다.

process mining에서는 이 필드를 리소스 속성으로 사용합니다. 담당자 간 업무 흐름을 시각화하고, 특정 전문가 한 명에게 지나치게 의존해 업무가 중단될 위험이 있는 지점을 찾을 수 있습니다.

중요한 이유

개인별 리소스 분석과 업무량 조정에 활용됩니다.

확보 방법

PBM:Problem Investigation 양식의 'Problem Coordinator' 필드

예시
홍길동김영희시스템 관리자
서비스 CI
ServiceCI
영향을 받은 주요 비즈니스 서비스 또는 구성 항목입니다.
설명

이 속성은 문제와 관련된 서비스 구성 항목(CI)을 식별합니다. 예를 들면 '이메일 서비스', 'SAP ERP', 'Wi-Fi 네트워크'가 있습니다. BMC Helix에서는 'Service+' 필드 또는 기본 CI 관계에 해당하는 경우가 많습니다.

분석 시 제품이나 서비스별로 문제 기록을 나눠 볼 수 있습니다. IT 책임자는 이를 통해 어떤 서비스가 가장 취약하고 문제 조사 기록을 가장 많이 발생시키는지 파악할 수 있습니다. 제품 차원을 추가해 '처리량 및 우선순위별 건수' 대시보드에도 활용할 수 있습니다.

이 속성을 'Investigation Cycle Time'과 함께 분석하면 핵심 뱅킹 시스템처럼 복잡한 서비스의 조사에 인쇄 서비스 같은 일반 서비스보다 본질적으로 더 오랜 시간이 걸리는지 확인할 수 있습니다.

중요한 이유

프로세스 성과를 특정 비즈니스 제품이나 서비스와 연결합니다.

확보 방법

PBM:Problem Investigation 양식의 'ServiceCI' 또는 'CI Name' 필드

예시
이메일 서비스급여 시스템기업 VPN
우선순위
Priority
영향도와 긴급도를 기준으로 산정한 문제의 우선순위입니다.
설명

이 속성은 문제 기록의 우선순위(예: 긴급, 높음, 보통, 낮음)를 나타냅니다. BMC Helix에서는 일반적으로 영향도와 긴급도 선택값을 바탕으로 계산합니다.

분석 시 '처리량 및 우선순위별 건수' 대시보드에 사용합니다. 조직은 이를 통해 리소스가 비즈니스 요구에 맞게 배정됐는지 확인할 수 있습니다. 예를 들어 '긴급' 문제는 '낮음' 우선순위 문제보다 초기 배정이 빠르고 전체 주기 시간이 짧아야 합니다.

우선순위별로 필터링하면 개선 활동의 초점을 정할 수 있습니다. '낮음' 우선순위 프로세스의 병목은 허용할 수 있지만, '긴급' 프로세스에서 같은 지연이 발생하면 비즈니스 연속성과 SLA 준수에 큰 위험이 됩니다.

중요한 이유

비즈니스 중요도에 따라 분석을 나누고 SLA 분석을 지원합니다.

확보 방법

PBM:Problem Investigation 양식의 'Priority' 필드

예시
긴급높음보통낮음
조사 시작 사유
InvestigationDriver
문제 조사를 시작한 이유입니다.
설명

이 속성은 문제 기록을 시작하게 된 계기를 분류합니다. 예를 들면 '인시던트 건수', '주요 인시던트', '공급업체 알림', '선제적 추세 분석'이 있습니다. BMC Helix에서는 'Investigation Driver' 필드에 해당합니다.

이 속성은 '선제적 식별 추세' 대시보드에 활용됩니다. 조직은 인시던트에 대응하는 사후 조치에서 문제가 발생하기 전에 위험을 파악하는 선제적 문제 관리로 전환하고 있는지 측정할 수 있습니다.

'Investigation Driver'별 프로세스 흐름을 분석하면 사유에 따른 처리 방식의 차이를 확인할 수 있습니다. 예를 들어 '선제적' 문제는 즉각적인 서비스 중단을 일으키지 않아 대기열에 더 오래 머무를 수 있지만, '주요 인시던트'로 시작된 문제는 신속히 처리될 수 있습니다.

중요한 이유

사후 대응 업무와 선제적 업무를 구분하며, 이는 프로세스 성숙도를 보여주는 주요 지표입니다.

확보 방법

PBM:Problem Investigation 양식의 'Investigation Driver' 필드

예시
사후 대응형선제 대응형반복 인시던트
지원 그룹
SupportGroup
현재 문제 조사를 담당하는 기술팀입니다.
설명

이 속성은 이벤트 발생 시점에 문제 기록을 담당한 지원 그룹(예: '서버 관리', '데이터베이스 지원')을 나타냅니다. BMC Helix에서는 'Assigned Group' 필드에 해당합니다.

이 속성은 '지원 그룹 업무량 분배' 및 '지원 그룹 재배정 분석' 대시보드에 중요합니다. 분석가는 팀별로 프로세스 맵을 나눠 살펴보고, 어느 그룹이 가장 많은 업무를 처리하는지와 조사 과정에서 어느 그룹에 병목이 발생하는지 확인할 수 있습니다.

지원 그룹 간 인계를 분석하면 해결되지 않은 티켓이 팀 사이를 반복해서 오가는 현상을 파악할 수 있습니다. 이는 조직 내 책임이 불분명하거나 지식 관리가 미흡하다는 신호일 수 있습니다.

중요한 이유

조직 단위 분석과 팀별 병목 파악에 사용됩니다.

확보 방법

PBM:Problem Investigation 양식의 'Assigned Group' 필드

예시
서비스 데스크 1차 지원백오피스 지원네트워크 관리
관련 변경 요청 ID
RelatedChangeRequestId
문제 해결을 위해 생성한 변경 요청의 식별자입니다.
설명

문제 레코드와 연결된 변경 요청(Change Request)의 ID(예: CRQ0000...)를 담는 속성입니다. 조사 단계에서 영구적인 해결책을 구현하는 단계로 넘어가는 것을 나타냅니다.

'근본 원인 파악부터 변경 착수까지 걸린 시간' KPI를 계산하는 데 필요합니다. 근본 원인을 찾은 시점부터 변경 프로세스를 시작할 때까지의 지연 시간을 process mining 도구로 측정할 수 있습니다. 이 인계 단계에서 추진력이 떨어지는 경우가 많습니다.

'프로세스 완결성'을 확인하는 데도 도움이 됩니다. 상태가 '완료'로 종료된 문제 레코드에 관련 변경 요청이나 임시 해결책이 없다면, 근본 원인을 찾고도 실제로 해결하지 않은 프로세스 위반일 수 있습니다.

중요한 이유

문제 관리 프로세스와 변경 관리 프로세스를 연결합니다.

확보 방법

PBM:Investigation Associations 또는 Relationship 탭

예시
CRQ00000021345CRQ00000021346
임시 해결책 상태
WorkaroundStatus
유효한 임시 해결책을 확인하고 게시했는지 나타냅니다.
설명

임시 해결책(Workaround)의 상태를 추적하는 속성입니다. '임시 해결책 있음'과 같은 참/거짓 값이나 상태 문자열로 표시할 수 있습니다. BMC Helix에서는 'Workaround' 필드에 내용이 있는지 또는 특정 상태 플래그가 설정되었는지를 기준으로 판단하는 경우가 많습니다.

'임시 해결책 게시 성과' 대시보드에 사용됩니다. 근본 원인을 조사하는 동안 팀이 영향을 얼마나 효과적으로 줄이는지 확인할 수 있습니다. '임시 해결책 없음'으로 필터링한 프로세스 화면에서는 조사 중에도 업무에 큰 영향을 받는 사례를 확인할 수 있습니다.

품질 감사에도 활용됩니다. 영구 해결책(변경 요청)도 임시 해결책도 없이 문제 레코드를 종료했다면 일반적으로 프로세스 실패로 보고 검토해야 합니다.

중요한 이유

조사 중 영향을 줄이는 조치의 효과를 측정합니다.

확보 방법

PBM:Problem Investigation 양식의 'Workaround' 필드 내용 확인

예시
활성없음폐기됨
재할당 횟수
ReassignmentCount
지원 그룹이 변경된 총횟수입니다.
설명

단일 케이스에서 '지원 그룹에 할당' 활동이 발생한 횟수를 집계하는 속성입니다. 프로세스의 마찰과 라우팅 효율성을 직접 보여줍니다.

'지원 그룹 재할당 분석' 차트에 반영됩니다. 값이 높으면 문제가 여러 그룹 사이를 오가는 것으로, 초기 분류가 제대로 이루어지지 않거나 복잡한 문제의 담당자가 명확하지 않을 수 있습니다. 이는 주기 시간이 늘어날 가능성을 보여주는 선행 지표입니다.

관리자는 이 지표를 활용해 교육이 필요한 부분을 찾습니다. 서비스 데스크가 '데이터베이스' 문제를 먼저 '네트워크' 그룹에 보내고, 네트워크 그룹이 다시 데이터베이스 그룹으로 돌려보내는 일이 반복되면 재할당 횟수가 증가합니다. 이를 통해 초기 진단 절차를 개선할 필요가 있음을 알 수 있습니다.

중요한 이유

프로세스에서 낭비와 지연, 담당 주체의 불명확성을 파악합니다.

확보 방법

활동 이력을 기준으로 계산

예시
015
조사 주기 시간
InvestigationCycleTime
조사 시작부터 근본 원인 파악까지 걸린 시간입니다.
설명

'조사 시작' 활동부터 '근본 원인 파악' 활동까지의 시간을 측정하는 계산 속성입니다. 문제 관리 프로세스에서 실질적인 가치를 더하는 핵심 작업 시간을 나타냅니다.

'근본 원인 조사 주기 시간' 대시보드에 반영됩니다. 관리자는 이를 통해 문제의 기술적 복잡도와 조사팀의 효율성을 파악할 수 있습니다. 시간이 지나치게 짧으면 추측에 의존했을 가능성이 있고, 지나치게 길면 조사가 지연되고 있을 수 있습니다.

'지원 그룹'과 '우선순위'별로 비교하면 문제를 더 빠르게 진단하는 데 어떤 팀에 더 나은 도구, 교육 또는 공급업체 지원이 필요한지 파악할 수 있습니다.

중요한 이유

기술 조사 단계의 주요 효율성 지표입니다.

확보 방법

활동 타임스탬프를 기준으로 계산

예시
4500000120000
지역
Region
문제가 발생했거나 관리되는 지역입니다.
설명

문제가 발생했거나 관리되는 지리적 위치(예: '북미', 'EMEA')를 나타내는 속성입니다. BMC Helix에서는 요청자 또는 영향을 받은 자산과 연결된 'Region' 또는 'Site' 필드에 해당하는 경우가 많습니다.

분석 시 지역별로 데이터를 구분하는 데 사용됩니다. 특정 지역에서 문제가 더 많이 발생하거나 해결 시간이 더 오래 걸리는지 파악할 수 있습니다. 이를 통해 지역별 지원 인력 배치나 인프라 품질의 차이를 확인할 수 있습니다.

전 세계에 사업장을 둔 조직이 일관된 서비스를 제공하는 데 유용합니다. 'APAC'의 '조사 주기 시간'이 'NAM'의 두 배라면, 해당 지역의 리소스 배분이나 프로세스 준수 여부를 살펴볼 필요가 있습니다.

중요한 이유

지역별 프로세스 성과를 비교할 수 있습니다.

확보 방법

PBM:Problem Investigation 양식의 'Region' 필드

예시
미주EMEAAPAC
필수 권장 선택 사항

문제 관리 활동

조사와 해결 단계를 빠짐없이 파악하려면 다음 주요 프로세스 단계와 상태 변경을 추적해야 합니다.
9 권장 4 선택 사항
활동 설명
근본 원인 파악
문제 기록의 상태가 원인을 파악했음을 나타내는 단계로 바뀌는 시점입니다. Status가 'Root Cause Identified'로 변경되면 이 이벤트로 판단합니다.
중요한 이유

'Root Cause Investigation Cycle Time' 대시보드의 주요 마일스톤입니다. 분석 단계에서 해결책 마련 단계로 전환됐음을 나타냅니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Root Cause Identified'.

기록

Status 필드에서 Root Cause Identified로의 전환 확인

이벤트 유형 inferred
문제 기록 등록
시스템에 Problem Investigation 기록을 처음 생성하는 단계입니다. PBM:Problem Investigation 양식에 새 항목을 저장하면 이 이벤트가 명시적으로 기록됩니다.
중요한 이유

프로세스 인스턴스의 시작을 나타냅니다. 전체 주기 시간과 초기 응답 지표를 계산하는 데 필요합니다.

확보 방법

PBM:Problem Investigation 양식의 'Submit Date' 타임스탬프 또는 'Status' = 'Draft' 생성 로그.

기록

PBM:Problem Investigation 기록이 생성될 때 기록됩니다.

이벤트 유형 explicit
문제 기록 종결
문제 기록을 최종적으로 행정 종결하는 단계입니다. 이 이벤트로 프로세스 인스턴스가 종료됩니다.
중요한 이유

표준 종료 이벤트입니다. 전체 주기 시간 분석과 'Incident Linkage Density' 계산에 필요합니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Closed'.

기록

Status 필드에서 Closed로의 전환 확인

이벤트 유형 inferred
문제 기록 취소
해결 전에 문제 기록을 종료하는 단계입니다. 상태가 'Cancelled' 또는 'Rejected'가 되면 기록합니다.
중요한 이유

불필요한 작업이나 유효한 중복 사례를 파악하는 데 활용됩니다. 대체 종료 지점을 나타냅니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Cancelled' 또는 'Rejected'.

기록

Status 필드에서 Cancelled로의 전환 확인

이벤트 유형 inferred
변경 요청 시작
Infrastructure Change Request를 Problem Investigation에 연결하는 단계입니다. 구현 단계의 시작을 나타냅니다.
중요한 이유

'Root Cause to Change Lead Time' KPI 산출과 Problem 프로세스와 Change 프로세스 간 단절을 파악하는 데 필요합니다.

확보 방법

PBM:Investigation_Associations 테이블 또는 'Infrastructure Change ID' 필드 입력.

기록

PBM:Investigation_Associations에 연결 정보가 생성될 때 기록됩니다.

이벤트 유형 explicit
임시 해결책 정의
문제 기록의 Workaround 필드에 내용을 입력하거나 수정하는 단계입니다. 임시 해결책이 문서화됐음을 나타냅니다.
중요한 이유

'Workaround Publication Lead Time' KPI 산출을 지원하며, 인시던트 영향을 완화하는 시점을 나타냅니다.

확보 방법

PBM:Problem Investigation 양식의 'Workaround' 텍스트 필드 변경.

기록

'Workaround' 필드에 값이 입력되거나 수정됐는지 확인

이벤트 유형 inferred
조사 시작
문제 기록이 실제 분석 단계로 전환되는 시점입니다. Status 필드가 'Under Investigation'으로 바뀌면 이 이벤트로 판단합니다.
중요한 이유

실제 작업 단계의 시작을 나타내며 'Investigation Cycle Time' KPI를 산출하는 데 활용됩니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Under Investigation'.

기록

Status 필드에서 Under Investigation으로의 전환 확인

이벤트 유형 inferred
지원 그룹에 배정
문제 기록을 특정 기술팀에 배정하는 단계입니다. 'Assigned Group' 필드의 변경을 추적해 기록합니다.
중요한 이유

'Mean Time to Initial Assignment' KPI를 비롯해 인계와 반복 이관 현상을 측정하는 데 필요합니다.

확보 방법

PBM:Problem Investigation 양식의 'Assigned Group' 필드 변경 이력 또는 감사 로그.

기록

업데이트 전후의 'Assigned Group' 필드 비교

이벤트 유형 inferred
해결 확인
영구적인 해결책이 성공적으로 적용됐음을 확인하는 시점입니다. Status가 'Solution Implemented' 또는 'Completed'로 바뀌면 이 이벤트로 판단합니다.
중요한 이유

'Problem SLA Adherence Rate' 산출에 활용되며 기술 작업이 완료됐음을 확인합니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Solution Implemented' 또는 'Completed'.

기록

Status 필드에서 Solution Implemented로의 전환 확인

이벤트 유형 inferred
Known Error로 등록
문제 조사 기록과 연결된 Known Error 기록을 생성하는 단계입니다. 관련 기록 생성 이벤트로 처리됩니다.
중요한 이유

문제를 공식적으로 등록해 더 널리 공유하고 장기적으로 추적하기 시작했음을 나타냅니다.

확보 방법

PBM:Problem Investigation ID와 연결된 PBM:Known Error 기록 생성.

기록

PBM:Known Error 기록이 생성될 때 기록됩니다.

이벤트 유형 explicit
Solution Database 업데이트
영구적인 해결책이 제안되거나 파악됐음을 나타내는 'Solution Database' 상태로 기록이 전환되는 단계입니다.
중요한 이유

구현 전에 해결책을 정의하는 진행 상황을 추적합니다.

확보 방법

PBM:Problem Investigation 양식의 'Status' 필드 = 'Solution Database'.

기록

Status 필드에서 Solution Database로의 전환 확인

이벤트 유형 inferred
구현 후 검토 완료
PIR 단계의 완료를 의미합니다. PIR 상태에서 다른 상태로 전환되거나 연결된 PIR Task가 종료된 경우 이를 기록합니다.
중요한 이유

'Post Implementation Review Compliance'와 프로세스 품질 감사에 직접 활용됩니다.

확보 방법

PBM:Problem Investigation 양식의 'PIR Required' 플래그가 설정되었거나 연결된 유형이 'PIR'인 Task가 완료된 경우입니다.

기록

PIR 상태 완료 또는 PIR Task 종료를 기준으로 산출합니다.

이벤트 유형 inferred
조정 담당자 재배정
지원 그룹 내 Problem Coordinator가 변경되는 단계입니다. 'Problem Coordinator' 필드의 변경을 추적해 기록합니다.
중요한 이유

업무량 분배와 개인별 리소스 병목을 분석하는 데 도움이 됩니다.

확보 방법

PBM:Problem Investigation 양식의 'Problem Coordinator' 필드 변경 이력.

기록

업데이트 전후의 'Problem Coordinator' 필드 비교

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

데이터 추출 가이드

BMC Helix ITSM에서 문제 관리 데이터를 추출하는 방법

시작할 준비가 되셨나요?

이 템플릿을 BMC Helix ITSM 데이터에 적용해 서비스 안정성을 높여 보세요. 설정에 관해 궁금한 점이 있으면 저희 팀이 도와드리겠습니다.

문제 관리 병목을 지금 해결하세요

처리 주기를 30% 단축하고 서비스 안정성을 높이세요.

무료 체험 시작하기

신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.