ITIL Foundation 시험 수준에서 변경과 관련된 프랙티스는 두 가지이다.
• 서비스 요청 관리 Service request management
• 변경 통제 Change Enable (Change control)
이 중 먼저 서비스 요청 관리에 대해 알아보기로 한다.
서비스 요청 관리는 고객과 서비스 제공자 양자가 미리 합의된 서비스 수준을 기반으로 서비스 요청이 이행되도록 하는 것으로, 일반적으로 이러한 요청은 사전 합의된 활동을 말한다.
서비스 요청
"A request from a user or a user’s authorized representative that initiates a service action that has been agreed as a normal part of service delivery"
"서비스 딜리버리라고 사전에 합의한 서비스에 대해 사용자나 사용자의 권한 대리자가 요청하는 것"
잘 사용하던 앱이 갑자기 안 돼서 고장문의를 하는 것은 인시던트인 데 반해, 서비스 요청이라는 것은 내 PC에 S/W를 설치해 달라는 것이나 특정 사이트에 접속할 수 있는 권한을 요청하는 것(방화벽 오픈 요청도 마찬가지)과 같이 이러한 유형의 일들은 자주 또는 종종 사용자가 요청하겠다 싶어 미리 정의한 일들이라고 할 수 있다.
서비스 요청의 유형으로는 다음과 같은 것들이 있다.
- Service Action : 위에서 말한 PC나 S/W 설치, 메일용량 증설 요청
- 정보 요청 : 사용방법 문의, 회의실 사용 문의
- 자원 접근 : 사내 시스템 권한 요청, 개발용 서버 요청
- 피드백 : 서비스에 대한 칭찬이나 불만 제기
이러한 것들은 사전에 정의되어 있어야 한다. 그래서 보통 시스템을 통해 서비스 요청을 하는 경우는 위와 같은 유형 중 하나를 선택하도록 되어 있다. 서비스 데스크에 전화를 걸어서 뜬금없이 택시 예약을 해 달라고 할 수는 없는 것이다. (물론 보통 '기타' 항목이 존재하므로 웬만한 건 다 할 수 있는 것이 현실이라 하겠다)
양사가 사전에 합의하여 정의하는 것은 서비스 카탈로그에 속한 것들이어야 한다. 서비스 카탈로그에 대해서는 뒤에 따로 포스팅을 할지 모르겠으나 간단히 말하면 제공하는 서비스들에 대한 단일한 정보 원천이라고 이해할 수 있다. (서비스 카탈로그 관리는 ITIL 4 Foundation 시험 범위가 아니다)
위에서 잠깐 언급한대로 서비스 요청은 인시던트와는 다르다. 조직에서 이 둘을 같이 취급하게 되면 심각한 인시던트로 인한 서비스 중단시간이 늘어질 수 있는 문제가 생기므로 반드시 둘을 구분해서 취급해야 한다.
이 서비스 요청 관리가 ITIL v3에서는 요청 이행 관리(Request Fulfilment Management)라는 이름으로 존재했었다. 아무래도 요청을 받아 처리하는 것에 중점을 둔 것 같은 이름이나 사실 ITIL v2에서도 현재와 동일하게 서비스 요청 관리였다. 인시던트나 문제 관리처럼 프로세스 전체를 포괄적으로 대표하는 용어인 현재가 더 맞는 게 아닌가 싶다.
서비스 요청은 사전에 정의된 요청이므로 요청 이행(fulfilment)은 요청의 시작부터 승인을 거쳐 종료되기까지 표준화된 절차에 의해 수행되는 것이 보통이다. 프로세스의 각 단계에서 수행해야하는 작업에 대한 명확한 지침과 절차가 작성되어 있어야 한다.
변경 관리 프랙티스에서 나오겠지만 서비스 요청은 표준 변경 (Standard Change)의 한 형태라고 할 수 있다. 절차가 간단하고 영향도가 크지 않은 만큼 요청부터 종료까지 이를 자동화하여 Self-Service가 가능하도록 구현하는 것이 가장 좋다. 자동화는 고객과 사용자 경험을 가장 바람직하게 만들어 주기 때문이다.