Sponsors:

서비스 지원 측정 기준

변경 관리

제7장

문제 관리와 마찬가지로 ITIL은 변경 관리에 있어서 2단계의 모니터링을 권장하고 있습니다. 첫 단계인 관리 보고는 문제 관리와 동일합니다. 두 번째 단계는 다소 다른데, 이 단계에는 BSI의 저작물인 “IT 서비스 관리에 대한 사례 코드(PD0005)”를 상호 참조하기 때문입니다. 이 단계에서는 상세한 변경 관리 보고에 초점을 맞춥니다. 두 단계 모두 변경 관리의 주요 목표를 명심해야 합니다.

변경 관리 프로세스의 목표는 변경 관련 사고가 서비스 품질에 주는 영향을 최소화하여 조직의 일상적인 업무를 개선하기 위해, 모든 변경이 효율적이고 즉각적으로 처리되도록 표준화된 방법과 절차가 사용되도록 보장하는 것입니다.

변경 관리는 모니터링, 측정 및 측정치 데이터를 풍부하게 제공합니다. ITIL은 다음과 같은 주요 이슈에 중점을 둡니다.

기간 중에 실행된 변경의 횟수, 총합 및 구성 항목(CI), 구성 유형, 서비스 등.
변경 이유 분석(사용자 요청, 향상, 비즈니스 요구사항, 서비스 요청, 인시던트, 문제 해결, 절차, 교육 향상 등).
변경이 성공적이었던 경우의 횟수.
취소된 변경 횟수 및 이유(예: 부정확한 평가, 결함).
변경으로 나타난 인시던트 수(문제 심각도 수준에 따라 분류) 및 이유(예: 부정확한 평가, 결함).
RFC 수(및 그 근원에서 나타나는 모든 경향).
실행된 변경에 대한 평가 횟수 및 미처리 검토의 크기(시간대별 분류).
CI 관련 높은 RFC 및 PR 발생율(특별 주의 요망), 이유 제공(예: 변덕스러운 사용자 요구사항, 민감한 구성요소, 결함).
비교를 위한 이전 기간(지난 기간, 지난해)의 수치.
RFC 거부당한 경우의 횟수.
성공적이지 못한 실행 변경의 비율(총합 및 CI별 분류).
CI 및 변경 관리 과정 단계별로 분류된 미처리 검토.

보시는 바와 같이 권장된 관리 보고는 넓은 범위를 다루지만 특정 변경의 세부적인 면이 아니라 상위 측정 단계에 중점을 둡니다. 각 보고 포인트는 좀더 분석해 볼 가치가 있습니다.

기간 중에 실행된 변경의 횟수, 총합 및 구성 항목(CI), 구성 유형, 서비스 등. 이것은 변경의 총 수를 나타내는 직관적인 수치이며 카테고리별로 분류한 것입니다. 이 수치는 IT 및 비즈니스 변경에 따라 변화의 수효 및 카테고리가 심하게 변동하기 때문에 바로미터 이상의 의미를 지니지 않습니다. 이 보고서는 구성(자산) 관리 관리자에게 중요한데 그 이유는 구성 항목(자산) 상태에 발생하는 변경은 반드시 변경 관리 과정을 거쳐야 한다는 것이 ITIL의 권장 사항이기 때문입니다. 어느 카테고리가 자신의 조직에 적용될 수 있는지 결정하되 지나치게 세부적으로 분류하지 않도록 주의하십시오. 분류가 지나치게 되면 정보를 주는 것이 아니라 혼란을 일으키게 됩니다.

비즈니스 조정 지표 – 거의 모든 변경 관리 보고는 비즈니스 커뮤니티에 흥미로운 것이지만 특히 이 보고는 비즈니스 영역에 따라 분류할 경우에 비즈니스 관리자에게 중요합니다.

변경 이유 분석(사용자 요청, 강화, 비즈니스 요구사항, 서비스 요청, 인시던트, 문제 해결, 절차, 교육 향상 등). 이 보고서는 유용한 정보를 제공하지만 매우 높은 수준으로 제공합니다. ITIL은 이 보고에 대한 시기를 추천하지는 않지만 지난 기간에 대한 상세 보고 및 12개월 등 여러 기간에 대한 누적 보고로 작성하여 특정한 경향을 나타낼 수 있습니다.

비즈니스 조정 지표 – 이 보고서는 비즈니스 커뮤니티가 요청하지 않은 변경의 이유에도 관심을 가진 비즈니스 관리자가 볼 수 있어야 합니다.

변경이 성공적이었던 경우의 횟수. ITIL은 “성공적”이라는 단어의 뜻을 구체적으로 밝히지 않지만 분명한 결론은 모든 변경이 이상 없이 실행되었음을 의미한다는 것입니다. 하지만 성공적이긴 했으나 시기상으로 뒤쳐진 경우, 혹은 취소한 다음에 다시 실행되거나 새로운 인시더트를 촉발하지 않은 변경의 경우는 어떻게 해야 할까요? 이 보고서가 유용성을 갖추려면 먼저 자신의 조직에 있어서 “성공적인” 변경이 어떤 것인지 정의해야 합니다. 결과적으로 성공적인 변경의 유형별로 이 보고서를 세분화합니다. 전반적인 수치 하나만이 나온 보고서는 이 중요한 변경 관리 구성요소에 거의 도움이 되지 않습니다.

비즈니스 조정 지표 – 이 수치는 비즈니스 관리자에게 중요한 보고 자료입니다. 비즈니스 관리자들이 가진 “성공적인 변경”에 대한 관점은 IT와 완전히 다를 수 있습니다. 비즈니스 관리자들은 이 보고서에 대한 첨부자료 혹은 온라인상으로 각 성공적인 변경에 대한 간단한 요약을 보고 싶어합니다. 이 보고서에서 언급하는 “성공적인” 변경과 관련하여 비즈니스 관리자들이 반응과 피드백을 보여줄 것으로 기대해 보십시오.

취소된 변경 횟수 및 이유(예: 부정확한 평가, 결함). ITIL 용어집에서 “취소”되었다는 말은 변경이 실행되긴 했지만 후에 다시 제거되고 변경 이전의 상태가 복구되었다는 뜻입니다. 부실한 효과, 과도한 신규 인시던트 발생, 변경으로 인한 구성요소의 부정적 영향 혹은 변경 요청(RFC)에서 명시된 요구사항을 만족시키지 못하는 등 여러 가지 이유로 변경은 취소될 수 있습니다. 취소된 변경이 요구사항을 만족시키지 못한다는 점은 명백합니다. 취소된 원인, 실패를 정정하기 위해 취한 조치 및 이후 동일하거나 유사한 경우를 방지하기 위해 실행된 변경 등을 포함하여 취소된 변경에 대한 설명을 이 보고서와 함께 제공하십시오.

비즈니스 조정 지표 – 이 수치 역시 비즈니스 관리자에게 중요한 보고 자료입니다. 비즈니스 관리자들은 자신들의 비즈니스 영역과 관련된 취소 변경에 대한 설명을 원할 것입니다. 많은 비즈니스 관리자들은 이 보고서를 활용하여 자신들의 환경에 취소된 변경이 미치는 영향, 효과 및 비용 등을 파악할 것입니다. 여기에 추가해서, 변경 관리 과정에서 취소되어야 할 변경이 파악되는 즉시 공지할 수 있어야 합니다.

변경과 연관된 인시던트의 영향을 최소화한다는 변경 관리의 목표와 직접적인 관련이 있다는 점에서 이는 또 다른 중요한 측정치입니다. 인시던트의 대부분이 실패 혹은 취소된 변경으로 인한 것이지만 모든 인시던트가 그렇지는 않습니다. 성공적인 변경 역시 결과적으로 인시던트를 촉발할 수 있습니다. 예를 들어, RFC마다 변경이 성공적일 수도 있지만 고객은 변경의 측면을 모두 이해하지 못하여 적시에 바로 교육이 필요한 경우도 있습니다. 이런 경우에는 변경 자체가 실패했다기보다는 변경 과정이 실패한 것입니다.

변경의 결과로 발생한 인시던트를 추적하고 보고하는 것은 극히 중요합니다. 이는 인시던트 및 변경 소프트웨어가 긴밀하게 통합되어 이 정보를 신속하고 손쉽게 추적할 수 있어야 함을 의미합니다. 또한 서비스 데스크 직원이 변경과 관련된 인시던트를 인식하도록 교육받아야 한다는 의미도 있습니다. 서비스 데스크 직원은 추적 과정을 위하여 변경 참조 번호를 포함하여 정확하게 세부사항을 기록해야 합니다.

이는 매우 중요한 보고서입니다. 또한 이 보고서에는 발생한 인시던트별로 이유를 포함하여 동일하거나 유사한 인시던트가 향후 다시 발생하지 않도록 교훈을 얻어야 합니다.

비즈니스 조정 지표 – 대부분의 경우 비즈니스 관리자 자신 혹은 그 직원이 인시던트의 원인이 되므로 비즈니스 관리자들은 이러한 인시던트를 잘 인식하고 있을 가능성이 높습니다. 이 보고서에 추가하여 비즈니스 관리자들은 언제든지 변경과 연관된 인시던트를 온라인으로 살펴볼 수 있어야 합니다.

RFC 횟수는 간단하고 명확한 측정치입니다. 다만 “근원에서 나타나는 모든 경향”을 파악하는 것이 어려운 부분입니다. 먼저 RFC 횟수가 수행되는 변경의 수와 항상 일치하는 것은 아니라는 사실을 명심하십시오. 예를 들어, RFC 중에는 거부당하는 것도 있으며 하나의 변경에 대해 여러 RFC가 나타날 수도 있습니다. 결과적으로 RFC 횟수는 수행된 변경의 수와 항상 동일하거나 이보다 더 커지게 됩니다. 이 보고서의 첫 부분에는 RFC 횟수가 들어가야 합니다. 짧은 요약에 “접수” 및 “거부”된 RFC로 분류된 총합을 포함하면 더욱 좋습니다.

경향을 제공해달라는 요청을 받게 되면 지식과 개입의 영역으로 넘어가게 됩니다. ITIL은 어떤 경향을 파악해야 하는지 정하지는 않습니다. 이는 각 조직별로 정해야 하는 사안입니다. 일반적으로 경향에는 다음과 같은 것이 있습니다: 비즈니스 단위별 RFC 증가/감소, 특정 소프트웨어 관련 RFC 증가/감소 또는 신기술을 요청하는 RFC. 이러한 경향은 정보를 수집하고 분석한 결과로만 파악할 수 있습니다. 이 분석에서 작성되는 보고서는 해당 기간에 대해 고유한 것이 됩니다.

비즈니스 조정 지표 – 실제 RFC 회수는 그다지 중요하지 않지만 비즈니스 관리자들은 경향에 큰 관심을 보입니다.

실행된 변경에 대한 평가 횟수 및 미처리 평가의 크기(시간대별 분류). ITIL은 다음과 같이 말합니다 “변경 관리는 비효율적 변경의 결과로 변경 관리 시스템 자체에 발생하는 문제 혹은 비효율성을 교정하는 후속 조치를 유발해야 한다.” 그러므로 변경 검토, 레코드 검토 및 미처리와 관련된 보고서를 작성하는 것은 중대한 일입니다. 예를 들어, 변경 미처리의 크기가 크다는 사실은 변경 관리의 자원이 부족함을 나타냅니다. 성공적이지 못한 변경의 수효가 많다는 점도 변경 평가 혹은 변경 축적이 만족할 정도로 수행되고 있지 않다는 뜻입니다.

변경 보고를 검토하게 되면 다른 과정에서의 문제도 집어낼 수 있습니다. 평가를 통해 문제 관리가 잘못된 근원을 다루고 있으며 기술 구성 요소의 안정성이 떨어지거나 절차 및 교육이 부적절함을 파악할 수 있습니다. 이 보고서는 준비에 시간이 걸리고 숙련된 분석을 요구하지만 변경 관리의 성공에 중대한 영향을 미칩니다. 아이러니컬하게도 이 보고에 대한 결과로 변경 관리를 향상시킨다는 관점에서 추가적인 RFC가 이루어질 가능성이 높습니다.

비즈니스 조정 지표 – 특히 관리자들의 절차 및 교육이 실효를 거두지 못하고 있을 때 이 보고서는 비즈니스 관리자들에게 매우 중요합니다. 비즈니스 관리자에게 이 보고를 준비할 때는 비즈니스 커뮤니티가 향상시킬 필요가 있는 영역에 관심을 끌어내도록 하십시오.

CI와 관련된 RFC 및 PR의 높은 발생율(특별 주의 요망), 이유 제공(예: 변덕스러운 사용자 요구사항, 민감한 구성요소, 결함). 이 말을 더 잘 이해하기 위해 괄호 안의 정보를 제거해 봅시다. 그러면 “단일 CI와 관련하여 이유를 밝혀주는 높은 RFC/PR 발생률”이 됩니다. 이제 뭔가 보이기 시작합니다. RFC 횟수 및 문제 보고를 활용하여 구성 항목(자산 구성요소)의 약점을 파악하도록 하십시오. CI의 약점을 빨리 파악할수록 더욱 신속하게 해결하여 고객 서비스 품질을 향상할 수 있기 때문에 이는 필수적인 보고 사항입니다. 이 보고서를 생성하려면 문제 데이터베이스와 변경 데이터베이스를 구성(자산) 데이터베이스와 대조하십시오. 이를 수행하려면 문제, 변경, 구성에 대해 호환성 있는 데이터베이스(혹은 단일 통합 데이터베이스)에 추가로 필요한 결과를 내놓을 수 있는 보고서 생성기가 필요합니다. 시간은 오래 걸리지만 이 보고서는 IT 관리자라면 반드시 읽어야 하는 것입니다.

비즈니스 조정 지표 – 이 수치 역시 비즈니스 관리자라면 “필수적인” 보고 자료입니다. 이 보고서는 단지 비즈니스 관리자에게 보여주는 것을 넘어서 내용을 함께 논의할 수 있어야 합니다. 이를 통해 비즈니스 관리자들은 RFC 및 PR 발생률이 높은 이유를 파악할 수 있습니다.

비교를 위한 이전 기간(지난 기간, 지난해)의 수치. 이 수치는 따로 분리되는 것이 아니라 앞서 설명한 경영 보고서에 필수적으로 들어가야 하는 구성 요소에 가깝습니다.

비즈니스 조정 지표 – 비즈니스 관리자들과 의견을 나누어 이 보고서에서 다루어야 할 기간을 결정하십시오.

RFC 거부당한 경우의 횟수. 이것은 RFC가 거부당한 이유를 분석한 내용을 포함시켜 한결 좋은 보고서가 될 수 있습니다. 통제력 상실, 무능 또는 RFC의 내용을 이해하지 못하는 등 한 조직에서 다양한 이유로 과도한 RFC가 발생할 수 있습니다. RFC를 거부하는 기준을 파악하여 공개해야 합니다.

비즈니스 조정 지표 – 이 보고서는 거부당한 RFC에 대한 분석과 함께 비즈니스 관리자가 볼 수 있도록 해야 합니다. 거부당한 RFC 가운데 대부분은 그 원인이 비즈니스 커뮤니티에 있으므로 이 보고는 비즈니스 관리자들이 절차와 과정을 향상시켜 불필요한 RFC를 줄이는데 도움이 될 수 있습니다.

취소된 변경에 대해 유사 보고서를 이전에 다룬 적이 있으며 같은 원칙이 여기서도 적용될 수 있습니다. 하지만 한가지 큰 차이점이 있다면 변경이 실패했다고 해서 반드시 취소된 것은 아니라는 점입니다. 간혹 실패한 변경은 취소가 어려운 나머지 우회 및 돌아가는 조치만이 이루어지기도 합니다.

그럼에도 불구하고 이 보고의 성격과 구조에는 변경이 없습니다.

비즈니스 조정 지표 – 이 보고서는 비즈니스 관리자에게 배포되어야 합니다. (앞부분의 “취소 및 보고” 평가를 참고하십시오.)

CI 및 변경 관리 과정 단계별로 분류된 미처리 변경. 미처리와 관련된 유사 보고서에 대해 이전에 다룬 바 있습니다. 하지만 그 보고서는 총합만을 다룬 반면 이 보고는 미처리에 대한 분석을 요구하는 것입니다. 자신의 조직에 맞게 카테고리를 조정할 수도 있습니다. 이 보고의 핵심 목적은 미처리가 발생하는 병목현상을 찾아내어 제거하는 것입니다. 미처리를 제거하는 것이 중요하기 때문에 이 보고서를 통해 IT 관리자 전체에게 이슈가 되어야 합니다.

비즈니스 조정 지표 – 이 보고서는 비즈니스 관리자가 “필수적으로” 봐야 하는 보고서 중의 하나로 변경을 지연시키는 백로그를 파악하고자 하는 관리자라면 더욱 그렇습니다. 또한 요청한 변경이 목표한 마감을 지키지 못할 경우에 즉시 비즈니스 관리자에게 통보해야 합니다.

이 경영 보고서는 변경 관리 문제를 매우 넓은 범위로 다루고 있습니다. 또한 IT 변경 관리에 실패할 경우 대혼란이 발생할 수 있으므로 이 보고서는 커다란 중요성을 갖습니다. 본 섹션 첫 부분에서는 ITIL이 BSI의 저작물인 “IT 서비스 관리에 대한 사례 코드(PD0005)”를 상호 참조했음을 언급했습니다. 이 사례 코드를 보면 다음 항목들을 추천하고 있습니다.

변경 요청 횟수.

거부당한 변경 횟수 및 비율.

긴급 변경.

변경 중의 상태.

아래 항목별로 분류한 실행 대기중의 변경:

카테고리

미해결기간

아래 항목별로 분류한 실행된 변경 횟수:

구성 관리

서비스

미처리 변경 및 병목현상.

변경 비용 및 비용 요약.

변경이 비즈니스에 미친 영향.

비즈니스 영역에 따른 변경.

CI에 대한 변경의 빈도.

관리 보고에서 다룬 이 항목 가운데 대부분은 이미 논의한 바 있습니다. 중요한 예외 항목은 다음과 같습니다.

긴급 변경.

변경 비용 및 비용 요약.

변경이 비즈니스에 미친 영향.

이 항목들은 아래에서 다루도록 하겠습니다.

긴급 변경. 긴급 변경의 대부분은 변경 관리 과정이 제대로 이루어지고 있지 않거나 일부 지원 그룹이 제대로 수행하고 있지 않음을 분명히 나타냅니다. 긴급 변경은 인시던트 중에 고객을 다시 돌아오게 할 수 있는 유일한 방법이 변경을 수행함으로써 근원을 제거하는 것인 경우와 같이 특수한 상황을 위해 남겨두어야 합니다. 긴급 변경은 변경 구축자가 예전에 요청된 변경에 작업하는 것을 잊었거나 하는 등의 무능을 이유로 발동되어서는 안 됩니다. 이 보고서에는 지원그룹별 횟수, 비즈니스 단위별 횟수 및/또는 CI별 횟수 등의 카테고리로 분류된 긴급 변경 전체에 대한 일반적인 전반 분석이 포함되어야 합니다. 긴급 변경의 이유 역시 포함되어야 합니다.

비즈니스 조정 지표 – 긴급 변경은 비즈니스 단위에 직접적인 영향을 미치므로 비즈니스 관리자가 반드시 보도록 해야 합니다. 비즈니스 단위가 과도한 긴급 변경 요청을 할 경우 서로 의견을 교환하여 변경 스케줄을 위한 회의를 해보십시오.

변경 비용 및 비용 요약. 재무 분석은 조직의 성격과 특성에 따라 달라집니다. 예를 들어, 과금을 하는 조직에서는 그렇지 않은 조직보다 훨씬 세분화된 분석이 필요하게 됩니다. 하지만 과금 여부와 무관하게 각 조직은 자신들의 변경 비용을 파악하여 이를 공개해야 합니다. 이 보고서는 모든 IT 관리자가 볼 수 있어야 합니다. 진행중인 변경에 대한 변경 보고에는 계속 추가되는 총 비용 내역을 포함하여 각 변경마다 현재까지 소모된 비용을 나타내야 합니다

비즈니스 조정 지표 – 비즈니스 관리자들은 자신들이 요청하는 변경의 비용이나 자신들의 비즈니스 영역에 영향을 미치는 변경의 비용을 알고 싶어할 것입니다. 또한 과금 역시 이러한 보고서의 내용에 영향을 미칠 것입니다. 이 보고서들은 비즈니스 관리자들에게 배포하여 요청하거나 자신들의 비즈니스 영역에 영향을 미치는 변경의 비용을 볼 수 있도록 해야 합니다.

변경이 비즈니스에 미친 영향. 많은 경우에 변경이 비즈니스에 미치는 영향은 변경의 성격이나 긴급성에 따라 독특해질 수 있습니다. 결과적으로 보고서로 생성되지는 않지만 이 정보는 변경 기록이 작성될 때마다 변경 관리 과정에 나타나는 변경의 종류에 따라 볼 수 있도록 해야 합니다.

비즈니스 조정 지표 – 이 보고서는 생각보다 비즈니스 관리자에게 중요합니다. 긴급성 혹은 비즈니스에 미치는 영향은 다양한 이유 덕분에 변경 주기 중에 바뀔 수 있습니다. 그러므로 비즈니스 관리자들이 모든 변경이 비즈니스에 미치는 영향을 살펴보는 것이 중요합니다.

앞서 언급한 바와 같이 변경 관리는 방대한 양의 측정 및 모니터링이 필요할 수 있습니다. 변경 관리의 ITIL 목표 한가지를 더 살펴보겠습니다.

변경이 일어날 때 매끄러운 전환을 촉진하기 위해 변경 관리 프로세스가 높은 가시성과 솔직한 의사소통 채널을 갖는 것이 특히 중요합니다.

여기서 키워드는 “높은 가시성과 공개된 의사소통 채널을 갖추는” 것입니다. 이 문구는 이 보고가 왜 그렇게 중요하며 비즈니스 조정 우선순위가 높은 이유를 나타냅니다. 변경 관리는 IT와 비즈니스간 통합을 성공적으로 이끌어내는 데 필수입니다. 결과적으로 위에 설명한 모든 보고서가 핵심적인 것입니다.

> > 제8장 - 릴리스 관리