Change Managment

Change Managment

• 7.1 서론
  • 7.1.1 기본사항
• 7.2 목표
  • 7.2.1 효과
• 7.3 프로세스
  • 7.3.1 변경 관리 활동
  • 7.3.2 다른 프로세스와의 관계
• 7.4 활동
  • 7.4.1 기록
  • 7.4.2 접수
  • 7.4.3 분류
  • 7.4.4 계호기 및 승인
  • 7.4.5 조정
  • 7.4.6 평가
  • 7.4.7 긴급 변경의 구축
• 7.5 프로세스 관리
  • 7.5.1 관리 보고
  • 7.5.2 성과 지표
• 7.6 비용 및 예상 문제점
  • 7.6.1 비용
  • 7.6.2 예상 문제점

7.1 서론

비즈니스에 영향을 주는 IT 인시던트가 변겅과 관련이 잇는 경우가 많다. 그런 인시던트의 원인은 다양하다. 부주의'자원부족'준비 부족'부실한 파급효과 분석'부적절한 테스트;도입 과정의 문제 대문에 발생할 수 있다. 변경과 관련된 인시던트를 제대로 관리하지 못하면, IT 서비스 제공자와 비즈니스 자체가 통제불능 상태에 바지게 된다. 인시던트가 발생한다. 업무량의 증가를 감안하지 못하고 변경 관리를 시작하면 부실한 관리가 될 수 에 없다, 이렇게 되면 IT 서비스의 유지와 운영에 큰 영향을 주게된다.  변경 관리(Change Management)는 변경 프로세스를 관리하여, 최종적으로는 변경과 관련된 오류와 인시던트의 발생을 제한하는 데 목적이 있다. 변경 관리의 모토는 다음과 같다. 

모든 변경이 개선은 아니다. 하지만 모든 개선은 변경이다.

신규 개발 및 개선 제안, 변경, 솔루션으로 이어지는 변경 관리 프로세스를 하나의 사이클로 보여준다.

7.1.1 기본사항 

변경 관리 주체 
두 종류의 변경 관리 주체가 있다. 
- 변경관리 매니저 - 모든 RFC의 선별'접수'분류를 책임지는 사람
- 변경 자문 위원해 - CAB는 주기적으로 회의를 개최하여 변경 사안을 평가하고 중요도를 분류하며 계획한다. 

프로세스 범위 
변경관리 프로세스의 범위는 구성관리 및 릴리스 관리 프로세스의 범위와 함께정한다. 구성 관리는 변경의 파급 효과를 평가하는 데 필요한 정보를 제공한다. 변경 구축 이후에 구성 관리는 CMDB를 업데이트한다. 

7.2 목표 

변경 관리의 목표는 서비스 품질에 미치는 파급 효과를 가능한 적게 하면서 표준방법과 절차에 다라 변경을 신속하세 처리하는 것이다, 모든 변경은 추적 가능해야한다. 즉 "무엇이 변했는가?"라는 질문에 대답할 수 있어야 한다. 

7.2.1 효과 

변경 관리의 효과를 정리하면 다음과 같다. 

- 변경과 IT 서비스 품질에 미치는 부정적인 영향을 최소화한다. 
- 변경 예정 사항의 구축 비용을 보다 정확히 예측할 수 있다. 
- 변경 성공률을 높인ㄱ다. 도한 필요할 때는 백아웃을 보다 효과적으로 진행할 수 있다.
- 변경에 관한 관리 정보가 개선되어, 문제 영역을 더 정확히 진단할 수 있다. 
- 보다 안정되고 우수한 IT 서비스를 통해 사용자 생산성이 개선된다.
- 긴급한 변경이나 백아웃 때문에 일상 업무가 방해되는 일이 없으므로, IT 작업자의 생상성이 개선된다.

7.3프로세스

7.3.1 변경 관리 활동

변경 관리 프로세스는 RFC각각을 승인하거나 기각처리한다. 변경 관리 매니저가 업무를 처리하지만, 보다 중요한 변경인 경우에는 CAB가 결정을 내린다. 변경 관리의 투입 부분은 다음과 같다. 
- RFC(변경요청)
- CMDB(특히 변경의 파급 효과 분석)
- 다른 프로세스의 정보(데이터베이스, 예산 정보등)
-변경 계획(Forward Schedule of Change, FSC)

변경 관리 프로세스의 결과는 다음을 포함한다. 

- 변경 계획 업데이트
- 구성 관리 및 링리스 간리 추진
- 변경자문위원회(CAB) 의제, 회의록, 조치사항
- 변경 관리 보고서

7.3.2 다른 프로세스와의 관계 

변경관리는 다른 프로세스와 다음과 같은 관계에 있다. 

• 인시던트 관리
  • 인시던트 관리는 두가 측명에서 변경관리와 관계를 맺고 있다. 우선 변경 관리는 인시던트 관리가 요청한 변경을 처리하여 인시던트 영향을 최소화한다. 그러나 아무리 구주의해도 변경의 도입은 새로운 오류아 신시던트로 이어질 수 있다. 구축 과정이 부실하거나 사용가 변경을 받아들일 준비가 되어 있지 않은 경우에 그런 사태가 발생한다. 변경 구축과 관련된 정보를 인시던트 관리의 관련자에게 통보해야, 변경 관련 인시던트를 신속하게 파악하고 조치할 수 있다.

• 구성관리
  • 변경관리와 구성관리는 긴밀하게 연계되어 있다. 심지어 두 프로세스를 효과적으로 통합시킬 수 있으며, ITIL 서비스 지원 가이드라인은 두 프로세스를 통합하여 하나로 만들 것을 권고하고 있다.

• 문제관리
  • 변경 관리와 문제 관리는, 변경 관리와 인시덭느 관리의 관계와 비슷하다.

• 릴리스 관리
  • 변경은 새로운 애플리케이션이나 인프라스트럭처의 개발과 배포로 이어지기도 한다. 이런 부분은 릴리스 관리 영역의 대상이 된다. 또한 동일 영역의 IT 애플리케이션이나 인프라스트럭처에 영향을 주는 많은 변경 사안은 링리스 관리를 통해 함께 배포될 수 있다.

• 서비스 수준 관리
  • 서비스 수준 관리는 변경이 서비스와 비즈니스 프로세스에 미치는 파급 효과를 파악하는 데 관여한다.

• 가용성 관리
  • 가용성 관리는 서브시 가용성 개성과 관련된 변경을 제기한다. 또한 변경이 의도했던 대로 구축되었는지 확인하다.

• 용량 관리
  • 용량 관리 매니저는 장기간에 걸친 변경의 누적 효과에 중점을 둔다. 용량 관리는 용량 꼐획을 토대로 기존 용량 활용도 개선 및 확대를 위해, 개선과 변경이 필요한 사안을 RFC를 통해 요청한다.

• IT 서비스 연속성 관리
  • 서비스 연속성 확보를 위한 예ㅒ방 대책과 복구 계획을 항상 모니터해야 한다. 인프라 스트럭처가 변경되면 기존 계획도 바꿔야 할 필요가 생기기 때문이다.

7.4 활동

변경 관리 프로세스의 주요 활동은 다음과 같다.
기록 > 접수 > 계획 및 승인 > 조정 > 평가

7.6 비용 및 예상 문제점

7.6.1 비용

대표적인 변경 관리 관련 비용은 다음과 같다.
인건비, 도구비용

7.6.2 예상 문제점

변경관리를 도입할 때 다음의 문제가 발생할 수 있다.

• 종이 기반 시스템은 활요하기 너무 어려워 많은 문제를 유발한다.
• IT 인프라스트럭처의 모든 부분을 모니터 항 수 있는 변경 관리의 권한에 저항하는 사람이 있을 수 있다. 변경을 추진랑 때는 전체적인 업무 조정이 필요하다는 점을 모두가 인식해야 한다.
• 합의된 절차를 지키지 않고 마음대로 변경을 추진하여는 경우도 발생한다. 그러한 행위에는 단호하게 대처할 필요가 있다.

다음 방식으로 일부 문제를 해결할 수 있다.

• 각각의 변경을 절차에 따라 처리한다.
• 모든 IT 관련자와 공급업체가 변경 관리 프로세스를 수용하고 임의로 변경을 추진하지 않도록 교육시킨다.
• CI 변경을 CMDB에 입력하도록 구성 관리와 협조한다.