ITSM 프로세스간 Chain-Model 수립을 통한 시너지효과

이번 호에서는 ITIL 각 프로세스의 정의에 대한 설명 보다는 프로세스란 무엇인가, ITIL의 프로세스는 서로 어떠한 연관 관계를 갖으며 상호작용을 하는가에 대해 알아보겠다.
ITIL은 IT 운영에 대한 선진 사례의 집합이다. 어떻게 하면 IT 운영을 하는데 더 효율적이고 효과적일 것인가를 고민한 흔적들의 집합이다. 이를 단지 IT 인프라스트럭쳐의 운영 관점에서 본 것이 아니라 비즈니스와 서비스 관점에서의 IT 운영을 바라보며 IT 서비스 관리를 위한 프로세스들을 정리해 놓은 것이다. 그렇다고 해서 ITIL이 절대 진리이자 바이블인 것은 아니다. 하지만 ITIL 프로세스 프레임워크를 유지하는 상태에서 조직에 적합한 부분은 수용하며 적합하지 않은 부분에 대해서는 조직에 맞게 조정하여 수용한다면 이익을 얻을 수 있다라는 것에 대해서는 의심할 여지가 없다.

필자가 생각하는 ITIL의 장점 중의 하나는 효율적이고 효과적인 IT 운영을 위해서 어떠한 프로세스 영역에 대해 고민하여야 하는가에 대한 프레임워크를 제시했다는 것이다. 이 프레임워크는 비즈니스와 서비스 관점에서 IT 자원을 배치한다. 비즈니스의 요구에 따라 IT 자원의 가용성과 용량을 설계하고 고객의 요구에 맞는 IT 서비스 수준을 관리한다. 이러한 목표에 따라 일상적인 IT 운영 업무가 이루어 진다. IT를 단지 기술적인 시각에서 바라보는 것이 아니라 비즈니스와 서비스 관점에서 바라본다는 것 자체만으로 처음 ITIL을 접했을 때 느꼈던 신선함은 대단한 것이었다.

둘째는 IT 운영 프레임워크 내에 정의되어 있는 각 프로세스간의 유기적인 관계에 대해 명확한 정의가 되어 있다는 것이었다. 단순히 하나의 프로세스 만을 바라보는 것이 아니라 모든 프로세스가 정교한 시계 톱니처럼 서로 물려서 유기적으로 돌아 가는 IT 운영 서비스의 모습을 그려 놓았다는 것이다. 이와 같이 유기적인 관계를 이루다 보니 단계적인 ITSM 프로세스의 도입 시 선행 도입되어야 하는 프로세스 (구성 관리와 같은)가 존재하기도 한다.

프로세스 접근
그럼, 프로세스란 무엇인가? 프로세스에 대한 ISO의 정의를 보면 ‘인풋을 아웃풋으로 변환시키는 상호 관련되거나 상호 작용하는 일련의 활동’ 으로 되어 있으며 참고 사항에서 프로세스로의 인풋은 일반적으로 다른 프로세스의 아웃풋이라고 정의한다. ITIL에서는 프로세스를 ‘정의된 목표 달성 혹은 목적을 만족시키기 위하여 수행되는 활동들의 연결 집합’이라고 정의한다. 프로세스의 정립이란 비즈니스 목적 달성을 위한 행위들을 모으고 행위간의 인풋과 아웃풋을 정의하며  이 행위 그룹(프로세스)의 소유자와 자원, 관련 조직의 역할과 책임을 정의하는 것이다. 또한 품질 관리 및 지속적인 개선을 위하여 각 프로세스에는 KPI가 정의된다. 이러한 그룹은 여러 개가 있을 수 있으며 이를 ITIL의 코어인 ITSM에서는 아래와 같이 구분한 것이다.

서비스 서포트 (Service Support)
        구성 관리 (Configuration Management)
        인시던트 관리 (Incident Management)
        문제 관리 (Problem Management)
        변경 관리 (Change Management)
        릴리즈 관리 (Release Management)
        서비스 데스크 (Service Desk :Function)

서비스 딜리버리 (Service Delivery)
        서비스 수준 관리 (Service Level Management)
        가용성 관리 (Availability Management)
        용량 관리 (Capacity Management)
        IT 서비스 연속성 관리 (IT Service Continuity Management)
        재무 관리 (Financial Management)

비즈니스 목표 달성을 위해 조직이 효율적이고 효과적으로 운영되기 위해서는 서로 연관되고 상호 작용하는 여러 프로세스에 대해 명확하게 정의하고 조직 내에서 공유하며 운영해 나가야 한다. 하나의 프로세스의 아웃풋은 다른 프로세스의 인풋이 된다. (모든 아웃풋이 다른 프로세스의 인풋이 되는 것은 아니다.) 우리의 몸이 건강하게 유지되기 위해서는 맑은 피가 온 몸을 원활하게 흘러야 한다. 프로세스도 마찬가지이다. 각 단위 프로세스가 잘 수행되어도 일부 얻을 수 있는 이익은 있겠지만 그 이익을 최대화 하기 위해서는 프로세스와 프로세스간의 인/아웃풋이 원활한 상호작용을 해야 하는 것이다. 하나의 프로세스의 아웃풋에 대한 품질이 떨어진다는 것은 다른 프로세스로 좋지 않은 인풋이 들어 간다는 것이다. 그러므로 하나의 프로세스 아웃풋의 잘못된 결과는 조직 전반 프로세스에 영향을 미칠 수 도 있는 것이다. 자, 이제 ITSM의 각 프로세스는 어떠한 유기적인 관계를 갖고 있으며 이는 어떠한 Synergy 효과를 갖는지 살펴 보도록 하자.

구성 관리 (Configuration Management)
구성 관리는 모든 다른 서비스 관리 프로세스에 없어서는 안 되는 기본적인 요소이다. 구성 관리에서는 IT 서비스를 제공하는 모든 인프라스트럭쳐(H/W, S/W, 관련 문서, 관련 조직 등)의 정보를 식별하고 관리하며 다른 모든 ITSM 프로세스에 유효한 정보를 제공한다. 다른 모든 프로세스들은 구성 관리 데이터베이스 (CMDB: Configuration Management Database)의 정보를 바탕으로 업무를 수행한다. 구성 관리는 일반적으로 이야기 하는 자산 관리 (Asset Management)와는 차이가 있다. 자산 관리는 각 자산의 화폐가치, 사업 단위, 위치 등에 대한 정보만을 관리하며 각 아이템간의 관계정보는 관리하지 않는다. 그러나 구성 관리는 아이템 간의 다양한 관계 정보에 대한 정보를 관리한다. CMDB는 서비스 지원 프로세스 그룹 전반에 걸쳐 이용되며 인시던트 및 문제는 하나의 구성 요소의 결점 발생 시 그 근본 원인이 무엇인지 구성 항목 간의 관계를 보며 보다 쉽게 해결안을 도출 할 수 있다. CMDB는 또한 결점이 발생한 구성 항목과 사용자 정보, 그 와 관련된 인시던트, 문제 정보 등에 대한 링크 정보 또한 갖게 되며 과거 해결책에 대한 정보 제공을 한다.

구성관리는 변경 관리 전반에 걸쳐 정확한 정보를 제공할 의무가 있으며 변경에 의한 구성 항목의 상태 변경 정보를 지속적으로 업데이트하며 관리하여야 한다. 이 때 변경 관리와 구성 관리 사이에는 원활한 커뮤니케이션이 이루어 져야 한다. 만약 CMDB의 데이터에 대한 부정합이 발견되었다면 왜 그런 일이 발생한 것일까? 하나는 변경 관리 프로세스를 타지 않은 임의 변경이 발생하였을 경우이고 또 다른 경우는 변경 관리 프로세스로부터 변경 사항에 대한 정보를 구성 관리 프로세스가 받지 못한 경우이다. 최소한 변경의 진행은 구성 관리 시스템의 통제 하에서 적용되고 기록되도록 해야 한다는 것이 ITIL의 권고 사항이다. 모든 변경 요청은 구성 관리 데이터베이스 (CMDB)에 기록되어야만 하며 그 기록은 변경 요청이 승인되고 적용되는 동안 지속적으로 업데이트 되어야 한다.

구성 관리 시스템은 인프라스트럭쳐의 어떠한 다른 구성 요소가 변경 될 시 영향을 받게 되는 다른 구성 항목간의 관계에 대한 정보를 식별한다. 그러므로 구성항목의 담당자는 변경에 의해 발생할 수 있는 충격에 대해 사전에 파악하여 예방할 수 있다.

서비스 딜리버리 프로세스 또한 CMDB 데이터에 의존적이다. 서비스 수준 관리는 서비스를 제공하는 IT 구성 요소 조합에 대한 식별이 필요하며 이를 통해 고객과의 서비스 수준 협의를 셋업하는 것이 가능해 진다.  재무 관리는 비용 청구 시 특히 각 비즈니스 단위별로 사용된 구성요소에 대해 알아야 할 필요가 있다. IT 서비스 연속성 관리와 가용성 관리는 위험  분석 및 CFIA (Component failure impact analysis) 를 위하여 IT 구성 항목에 대한 식별이 필요하다. 구성 관리에서는 IT 서비스 트랜젝션을 구성하는 컴포넌트에 대한 정보를 가용성 관리에 제공하는 것이다. 또한 용량 관리에도 IT 구성 항목의 현재 Spec 정보를 제공하며 용량 관리에 의한 변경 발생 시 CMDB는 업데이트 되게 된다.

인시던트 관리 (Incident Management)
인시던트 관리 프로세스와 문제 관리 프로세스, 변경 관리 프로세스, 그리고 서비스 데스크 기능 사이에는 밀접한 연관 관계가 있다. 인시던트 관리(Incident Management) 프로세스는 인시던트의 가장 빠른 해결을 목표로 하며 동일 인시던트가 반복적으로 발생하거나 근본 원인을 알아내지 못한 경우에는 문제로 상태가 변경되어 문제관리(Problem Management) 프로세스에 이관되며 문제의 원인을 분석하기 위한 활동을 수행한다. 문제의 원인과 해결책이 밝혀진 경우에는 알려진 에러(Known Error)로 상태가 바뀌며 변경으로 문제가 해결되는 경우에는 RFC(Request For Change)가 발동되어 변경을 수행하고 최초의 인시던트를 종료하는 라이프 사이클을 거치게 된다. 이러한 예에서 보듯 우리가 흔히 얘기하던 ‘장애’라는 개념을 ITIL에서는‘인시던트’→‘문제’→’에러’→‘알려진 에러’→‘RFC’와 같이 프로세스에 따라 세부적으로 구분해 용어를 정의하고 있으며 이는 서비스에 영향을 미치는 부정적인 요소의 구조적 해결 접근법을 제시한다. 이 부분이 서비스 서포트(Service Support)의 핵심이다.

그림1: 인시던트, 문제, 변경 간의 관계

비즈니스의 중요도와 요구 사항에 따라 가용성 관리 프로세스는 IT 서비스의 가용성 설계를 수행한다. 이 때 서비스에 따라 가용성 목표가 설정되며 이 아웃풋은 인시던트 관리 프로세스의 인풋 요소로 들어가 인시던트 우선 순위 별 해결 목표 시간이 설정되게 된다.
인시던트 우선 순위 및 에스컬레이션 절차는 서비스 수준관리 프로세스 및 SLA 문서의 일부분에서 협의될 필요가 있다.

문제 관리 (Problem Management)
사전 예방적이고 진보적인 문제 관리 프로세스가 매력적이라고 할지라도 인시던트 관리 프로세스의 정립이 되지 않은 상태에서 문제 관리 프로세스를 수행 할 수는 없다. 그 이유는 간단하다. 문제 관리 프로세스의 가장 중요한 인풋 요소가 정제된 인시던트이기 때문이다. 문제는 임팩트가 동일한 증상을 보이는 여러 인시던트 혹은 임팩트가 큰 하나의 인시던트 라고 정의한다. 인시던트에 대한 기록 및 초기 분류 및 범주화, 그리고 용이한 검색 혹은 리포팅이 되지 않는 상태에서 문제 관리 프로세스는 정의되기가 어렵다. 물론 감성적으로 ‘요새 이런 요청건이나 장애가 많이 발생하는 것 같은데… 조직내에서 어떤 장애가 이슈가 되서 팀장 회의 때 도마 위에 올랐었지… 와 같은 케이스로 인해 문제가 초기화 되고 진행 될 수 있을지는 모른다. 그러나 그 것은 프로세스가 아닌 이벤트 이다. 지속적인 활동이 아닌 순간적인 활동일 뿐이며 그 결과에 대해서는 진화해 나가기 위한 유용한 정보를 기대할 수 없다.

문제 관리는 또한 인시던트의 트랜드 식별 및 개선을 위한 활동을 위하여 가용성 관리와 밀접하게 상호 커뮤니케이션 할 필요가 있다. 성공적인 문제 관리를 통해 인시던트의 재발을 방지하여 인시던트의 발생 주기(MTBSI :Mean Time Between System Incident)를 늦출 수 있으며 이를 통해 가용성 목표를 달성할 수 있다.

변경 관리 (Change Management)
변경 관리 프로세스는 변경에 의해 발생할 수 있는 영향에 대한 식별을 위해 구성 데이터의 정확성에 의존적이다. 그러므로 변경 관리 프로세스와 구성 관리, 릴리즈 관리 프로세스는 밀접한 연관 관계를 갖고 있다. 가용성 관리와 용량 관리, IT 서비스 연속성 관리의 결과로 IT 인프라스트럭쳐의 변경이 발생할 수 있다. 이러한 모든 IT 인프라스트럭쳐의 변경 사항은 변경 관리 프로세스를 통해 통제 된다.

인시던트의 구조적 해결 접근 방법을 통해 하나의 인시던트는 문제를 거쳐 RFC로 확장되면서 변경 관리의 인풋 요소로 들어오게 된다. 변경의 결과는 인시던트와 문제의 해결책 인풋 요소로 들어가게 된다. 그러므로 인시던트의 기록은 문제, 알려진 오류, 변경 기록과 동일한 CMDB에 기록하던지, 혹은 적어도 인터페이스를 개선하여 새로운 키 입력이 필요하지 않도록 구현하는 것이 권고되어 진다.

변경 관리 프로세스의 상세는 사용자가 변경 요청을 위한 절차를 어떻게 수행해야 하는지에 대해 SLA에 명문화 되어 있어야 하며 변경 적용시의 영향도에 대해 분석이 되어야 한다. 변경의 상세는 서비스 데스크에 알려질 필요가 있다. 일반적인 변경일지라도 변경의 적용으로 인한 인시던트 및 고객의 서비스 요청 발생 가능성은 증가한다.

릴리즈 관리 (Release Management)
변경은 종종 신규 하드웨어, 신규 소프트웨어 버전, 그리고 신규 문서등의 필요에 대한 결과이며 통제되고 분배되어야 하는 신규 ‘패키지 릴리즈’의 한 부분이다. 롤 아웃의 관리는 변경 관리 및 구성 관리와 밀접한 관계를 갖고 있다. 릴리즈 절차는 또한 인시던트 관리와 문제 관리의 일부 영역과 관련된다.

서비스 데스크 (Service Desk :Function)
서비스 데스크는 일상적으로 수행되는 IT 운영 업무에 대해 사용자와 서비스 제공자간에 단일 접점을 제공한다. 또한 IT 운영 조직 사이에 전략적 단일 접점 제공의 역할을 수행하며 커뮤니케이션 능력을 향상시킨다. 연관된 각 프로세스는 서비스 데스크 기능을 중심으로 정보를 공유하고 교환하며 원활한 흐름을 유지한다.  서비스 데스크는 사용자로부터의 변경 요청을 위한 받아들이고 변경을 초기화 하는 역할을 수행한다. 변경 관리를 위하여 논의되는 변경 스케줄, 그리고 변경 진행으로부터 알려진 정보를 사용자에게 알리는 역할을 수행한다. 그러므로 변경 관리는 서비스 데스크에 의해 변경 활동에 대한 지속적인 정보 제공을 수행해야 한다.

표준 변경의 경우, 서비스 데스크는 인시던트 해결을 위한 변경에 대한 권한을 일부 위임 받을 수 있다. 이와 같은 변경의 범위는 사전 정의 되어야 하며 변경관리 기능은 이와 같은 모든 변경에 대하여 통보 받아야 한다.


지금까지 간략하게 서비스 서포트 부분의 프로세스 관계에 알아 보았다. 우리가 너무도 자주 보던 ITIL Service Support 프로세스 다이어그램을 프로세스간 Chain Model을 고려하며 다시 바라보면 좀 더 빠른 이해가 될 것이다.

그림 2: ITIL Service Support 프로세스 다이어그램

서비스 수준 관리 (Service Level Management)
비즈니스 및 고객의 요구 사항에 부응하는 수준의 IT 서비스를 제공하고 그에 합당한 보상을 받는 것이 서비스 수준 관리의 목적이다. 서비스 수준 관리 프로세스는 서비스 수준 협약 (SLA) 및 운영 수준 협약(OLA) 혹은 계약들을 보장하기 위한 책임을 가지며 서비스 품질에 영향을 미치는 반대 급부를 최소화 하도록 보장하는 역할을 수행한다. 이 프로세스는 변경이 제안되었을 때, 그리고 그것들이 적용된 이 후 둘 다에 서비스 품질 및 SLA에 변경이 끼치는 영향에 대한 평가를 포함한다. SLA에 있어서 가장 중요한 목표 설정 중에 하나는 서비스 가용성과 관련이 있으며 이는 동의된 시간 내의 인시던트 해결이 필요하다. 서비스 수준 관리는 서비스 딜리버리 (Service Delivery)를 통해 수립되는 서비스 제공 계획 및 목표 설정에 대해 고객과 협의를 하며 서비스 서포트 (Service Support) 전 영역의 업무 수행 목표를 제공하는 연결 고리 역할을 수행한다. ITSM의 모든 프로세스는 고립된 기능으로 존재하는 것 아니라 다른 프로세스간에 효율적이고 효과적으로 연계 되는 것이다. 또한 지원 프로세스의 기반이 없는 SLA는 무의미하며 SLA의 내용을 충족 시킬 수 가 없게 된다.

가용성 관리 (Availability Management)
가용성 관리는 비즈니스 요구사항에 부합하는 IT 서비스의 가용성을 만족 시키기 위하여 IT 서비스의 설계, 적용, 측정 및 관리와 관련된 것이다. 가용성 관리는 왜 IT 서비스의 단절이 발생하는지, 그 이유에 대한 이해가 필요하며 서비스의 복구에 얼만큼의 시간이 소요되는 지에 대한 이해가 필요하다. 인시던트 관리와 문제 관리는 이와 같은 활동들이 진행되도록 하는 핵심 인풋을 제공한다. 가용성 관리는 서비스 수준 관리에 현 조직의 IT 서비스 가용성 능력에 대한 정보를 제공해야 하며 개선 계획을 마련해야 한다. 또한, IT 서비스 가용성에 대한 측정 및 리포팅은 SLA 를 충족시키기 위한 가용성 수준을 보장한다. 가용성 관리는 지원 서비스 검토를 위한 가용성의 측정 및 리포팅을 제공하는 것으로 서비스 수준 관리를 지원한다.

용량 관리 (Capacity Management)
용량 관리는 비즈니스 요구 사항과 직접적인 관련이 있으며 이는 단순히 시스템 구성요소 개별의 성능에 관련된 것이 아니다. 용량 관리는 용량 이슈와 관련된 문제 사항의 식별 및 인시던트 해결 활동을 포함한다.

용량 관리 활동은 적절한 가용 용량을 보장하기 위한 변경 요청 (RFC)을 발동 시킨다. 이러한 변경 요청 (RFC)은 변경 관리 프로세스를 전제로 해야 하며, 변경 적용은 영향을 받는 관련 CI들 (하드웨어, 소프트웨어 및 문서를 포함하여)에 대한 구성 정보의 획득으로부터 시작한다. 용량 관리는 용량 및 성능에 영향을 끼치는 것과 관련된 모든 변경의 완료 후 이에 대한 평가 활동에도 참여하여야 한다. 용량 관리는 특히 용량 관련 변경의 진행 지연에 대한 영향도에 대해 관심을 기울여야만 한다. 단일 변경에 영향을 미치는 사소한 것들이 조합되어 종종 처리 용량의 요구 수준 초과, 파일 저장소의 문제, 응답시간의 저하의 문제를 유발 시킬 수 있기 때문이다. 서비스 수준 관리와의 관계는 가용성 관리와 마찬가지로 현 조직의 IT 용량 및 성능 수준 제공 및 비용 대비 용량 정보 등을 제공하여 적절한 수준의 서비스 용량에 대한 인지를 가능하게 해야 하며 이를 토대로 고객과의 용량 관련 서비스 수준에 대한 합의가 이루어 지게 된다.

IT 서비스 연속성 관리IT Service Continuity Management
IT 서비스 연속성 관리는 이상 상황으로 인해 비즈니스에 단절이 발생할 경우 최소한의 비즈니스 요구 사항을 지원하기 위하여 사전 정의되고 동의된 수준의 IT 서비스를 지속적으로 제공할 수 있는 조직 및 인프라 능력에 대한 관리이다. 구성 관리 데이터는 IT 서비스 연속성 관리 계획 및 진행을 수월하게 하기 위하여 필요하다. 인프라스트력쳐와 비즈니스의 변경은 지속성 계획에 있어서 잠재적인 영향도에 대한 평가가 필요하며 IT와 비즈니스 계획은 변경 관리 절차를 조건으로 해야 한다.

재무 관리 (Financial Management)
재무 관리는 TI 서비스 제공을 위한 비용에 대한 회계에 대한 책임을 갖는다. 그리고 청구를 통하여 고객으로부터 서비스 제공에 대한 비용 회수의 역할을 수행한다. 이 프로세스는 서비스 제공에 실제 원가를 식별하기 위하여 용량 관리, 구성 관리 및 서비스 수준 관리와 밀접한 인터페이스를 수행한다. 재무 관리는 개별 고객의 IT 관련 지출 및 IT 부서의 예산 수립 협상 동안에 IT 부서와 고객 관계 관리자와의 밀접한 연관 관계를 가진다.

 

그림 3: ITIL Service Delivery 프로세스 다이어그램

지금까지 살펴 보았듯이 ITSM의 모든 프로세스들은 상호 연관 관계를 갖고 있으며 단일 프로세스의 개선 만으로는 커다란 이익을 보기가 힘들다. 각 프로세스의 목표를 달성하기 위해서는 다른 프로세스에 의존성이 크기 때문이며 프로세스간의 상호 작용에 대한 관리가 필요하다. 이를 위해 ITSM 프로세스간의 인/아웃풋을 상세 정의하는 프로세스 Chain-Model 수립이 필요하며 이를 통해 Synergy 효과를 기대할 수 있는 것이다. 조직 전체의 관점에서 바라보며 IT 자원과 프로세스들을 재 배열하고 연관 관계를 수립하여 프로세스간 원활한 상호작용을 수행하도록 한다면 IT 서비스 품질의 증대와 고객 만족(모든 프로세스간에 정보 공유로 처리 시간의 단축 및 고객의 요청 누락 방지, 고객에 대한 지속적인 정보 제공이 가능해 진다.)이라는 이익을 얻을 수 있다. 그럼에도 불구하고 많은 조직들은 무슨 이유에서인가 전체 프로세스간 정보 교환 및 통합을 꺼린다. 이렇게 밀접한 상호 연관 관계에도 불구하고 다른 프로세스간의 커뮤니케이션은 쉽지 않다. 기능 중심 조직이 되었던 프로세스 중심 조직이 되었던, 자신의 조직이 아니면 상호 배타적인 문화가 형성되기 쉽기 때문에 커뮤니케이션의 어려움은 더욱 커질 수 있다. 이러한 문제에 대한 해결 접근 방법 중 하나는  최대한 명료하게 서로간의 관계 설정에 대해 정의하여 놓고 서로 공유할 수 있는 공식적인 채널을 마련해 놓는 것이다. 공식적인 채널 마련이라는 것은 하고 싶은 말을 할 수 있는, 말을 하면 들어 줄 수 있는, 듣고 나면 뭔가 대답을 해줄 수 있는 준비가 되어 있다는 것이다. 각 프로세스는 다른 프로세스를 자기의 고객이라고 생각하고 고객을 만족 시키기 위하여 어떻게 해야 할지를 고민해 볼 필요가 있다. 프로세스간 원활한 커뮤니케이션은 프로세스 선 순환 모델의 기본 전제 조건이다. 

[출처] ITSM 프로세스간 Chain-Model 수립을 통한 시너지효과|작성자 제브라