커뮤니케이션(communication)
생산 하드웨어와 소프트웨어에 변화를 가할 때는 이러한 변화들과 여기에 포함된 모든 위험들에 대해 엔드유저에서부터 IT 경영진에 이르기까지 커뮤니케이션을 해야 한다. 아마도 이것은 성공에 있어 가장 큰 열쇠가 될 것이다. 사용자와 IT간의 효과적인 커뮤니케이션은 충돌을 밝혀내고 혼란을 막을 수 있게 해준다.
이것은 또한 사용자 커뮤니티가 임팩트 다운타임을 보다 잘 제어할 수 있게 해준다. 그리고 오픈 커뮤니케이션은 사용자들이 효율적인 인프라를 유지하는 데 필요한 노력을 파악할 수 있도록 도와주며, 이들이 팀의 일부임을 실감할 수 있게 해준다.

권한부여(authorization)
사용자 대표와 비즈니스 라인 매니저들, 그리고 IT 관리자들로 구성된 팀을 만들어 각각의 변화에 대한 권한을 부여하라. 어떠한 한 관리자가 사용자가 일하는 비즈니스의 모든 면을 다 알고 있을 수는 없다는 사실을 아는 게 중요하다. 이렇게 되면 네트워크 관리자가 회사의 세무 회계 시간이 다가온다는 사실을 알거나, 혹은 IT에서 정기적인 업그레이드를 위해 일련의 생산 시스템을 중단시키려고 하는 같은 날 밤에 CEO가 SEC로 회사 보고서를 보여주려 한다는 사실을 알게 되는 수준까지 가능하다.
변화 권한부여를 위한 일련의 점검 및 조정을 위임함으로써, 사업팀에서는 좋지 않은 시기에 일어날 변화를 막을 수 있는 능력을 갖출 수 있게 된다. 분명 사업팀에는 시스템 업그레이드에 대한 필요를 고려해야 하겠지만, IT도 또한 비즈니스가 없이는 IT 운영도 없다는 사실을 참작해야 한다.
어떤 사용자가 변화 권한을 부여할 수 있는지, 또 어떤 사용자가 실제로 이들을 할 수 있는지를 식별하기 위해서는 정책이 마련돼야 한다. CM 문서 프로세스의 일부로, IT 경영진에서는 요청을 평가하고, 필요한 자원을 파악하며, 우선순위를 정하고, 사용자 경영진으로 비용 추산액을 제공해야 한다. 일단 사용자 경영진에서 비용과, 변화에 연관된 어떠한 위험들에 대해 승인을 하면, IT 경영진에서는 적절한 스태프들을 배정하고, 변화 스케줄을 짤 것이다.
변화 권한부여는 변화에 대한 세부 사항을 명기하고, 적절한 정당화 사유를 제공하며, 미리 지정된 사용자 경영진의 승인 수준을 요구하는, 하나의 표준 요청 양식으로 문서화가 돼야 한다. 이러한 양식은 또한 IT 경영진의 승인을 위해서도 제공돼야 하며, 변화가 허가됐다는 사실을 입증하는 자료로서 보관돼야 한다. 테스트 결과가 검토됐으며, 정책별로 승인됐다는 문서도 또한 있어야 한다.
독자 설문조사에서 밝혀진 바와 같이, 변화는 기술 보유자에 의해 허가되는 경우가 많은데, 이들은 또한 변화를 만드는 사람들이기도 하며, 어떠한 정해진 변화 관리 위원회는 아니다. 사실 설문조사 응답자의 불과 19%만이 변화 관리위원회를 이용하고 있었다. 많은 조직에서는 분명 기술 보유자들이 변경을 이행할 수 있는 막대한 권한을 허가받고 있다.

승인(approval)
비즈니스와 IT 경영진은 CM팀과 별도로 생산 시스템에 배치되기 이전에 모든 변화를 승인해야 한다. 승인은 반드시 만족도 테스트 결과, 제안된 변화에 대한 철저한 검토의 증거, 그리고 변화가 조직 내의 생산성과 보안에 어떤 영향을 미칠 수 있는지에 대한 이해를 바탕으로 이뤄져야 한다.
변화 요청은 간단한 문서 양식이나 복잡한 전자 추적 시스템으로 만들어질 수 있다. 관리자 층이 몇 되지 않고, 시스템 관리자는 더더욱 얼마 없는 소규모 환경에서는 종이 요청양식이 가장 효과적이다. 크고 복잡한 조직에서는 전자 CM 시스템이 아마 이행할 가치가 있을 것이다. 잘 구축된 시스템은 미리 지정된 정책을 기반으로 다양한 경로를 통해 요청들을 라우팅한다.
생산 시스템에 새로운 파일 서버를 배치하겠다는 요청은 아마도 3~4단계의 승인 절차를 거치게 될 것이며, 여기에는 부서 매니저, 정보 보안 그룹, 아키텍처 그룹, 그리고 마지막으로 백업 및 복구 그룹이 포함될 것이다. 나아가 시스템은 전체 이행 과정 동안에 변화를 추적할 수도 있다.
종이든 전자 변화 관리든 한 가지 분명한 사실은 반드시 일종의 승인 양식이 이행돼야 한다는 것이다.

문서화(documentation)
권한부여, 테스팅 및 승인 절차를 적절한 형식을 갖춘 문서로 만들고, 관련된 모든 시스템, 운영 및 사용자 문서가 필요에 따라 업데이트되는지를 확인하라. 정확한 문서화는 성공적인 IT 조직의 핵심 요소며, 특히 어떠한 CM 프로그램에서든 매우 중요하다.
변화가 고려될 때는 여러 가지 변수들이 참작돼야 한다. 이러한 변수들 가운데 하나(혹은 그 이상)는 종종 내부 문서화에 의해 표현되는 경우가 많다. 오해를 불러일으키거나 잘못된 문서화는 잘못된 가정이 생겨나게 할 수 있으며, 또 종종 그렇게 되기도 한다. 이렇게 되면 변화 프로젝트의 무결성이 위험에 놓이게 된다.
우리는 이러한 문서화를 무시하는 사람들과 일해본 적이 많은데, 이들은 무선 액세스 포인트, 모뎀 및 추가 인터넷 PoP(Points of Presence) 같은 항목들을 종종 빠트리곤 한다. 이런 요소들을 문서에 담아두지 않으면, 변화 요청자는 잠재적인 위험을 알 수가 없으며, 쓸데없이 기업은 위험에 놓이게 된다.
한데 CM의 경우 문서화는 양방향 도로다. 일단 변화가 이행이 되면, 심지어 그 이전에도 모든 필요한 문서화 작업에서는 이러한 변화를 포함시켜 업데이트돼야 한다. 그렇지 않을 경우에는 변화를 만드는 사람들이 바로 변화 프로젝트의 성공을 위태롭게 하는 당사자가 될 수도 있다.

보안(security)
인프라에 허가받지 않는 변화가 생기는 것을 막기 위해 물리적 및 논리적 보안을 설정해야 한다. 많은 기업들이 정보의 무결성에 따라 살고 죽는다. 그 후의 결과를 완전히 이해하지 않고서 변화를 이행할 경우 기업(과 그 데이터)을 위험에 빠트릴 수 있다.
변화는 언제나 이행에 앞서 정보 보안 그룹에 의해 승인돼야 한다. 이것은 승인 사슬에 정보 보안 그룹을 바로 연결시킴으로써 이뤄진다. 이렇게 하면 위험 가능성이 있는 실수나 못보고 지나치는 경우를 피할 수 있다.

테스팅(testing)
배치 이전에 변화를 적절히 테스트 하라. 기업 인프라의 처음 설계 및 이행 과정에서와 같은 엄격한 테스트가 실행된 다음에, 생산 환경을 지원하는 장비에 변화를 가해야 한다. 이는 원래 IT와 사용자 개인이 변화가 기대하는 결과를 가져온다는 것을 확신할 수 있을 만큼 충분히 테스트를 수행할 필요가 있음을 의미한다. 어떤 변화는 본질적으로 다른 것들보다 위험이 더 크기 때문에, 여기서는 판단이 요구된다.
예를 들어 기간 비즈니스 애플리케이션을 지원하는 운영 시스템에의 변화는 불완전한 NIC를 교체하는 것보다 더 많은 테스트가 필요하다. 적절한 곳에서는 적절히 만들어진 변화 관리 프로그램이 또한 애플리케이션 소스 코드 평가와 같은 프로시저를 불러오기도 할 것이다.

스케줄링(scheduling)
모든 변화를 스케줄링하고, 이 스케줄을 사용자와 IT 경영진들에게 전달하라. 분열, 혼란, 그리고 프로세싱 에러 가능성을 최소화하기 위해서는 생산 시스템이나 네트워크 장비로의 변화를 스케줄링하는 절차가 있어야 한다. 또한 이러한 스케줄을 변화에 영향을 받게 될 사용자와 IT 팀에게 알리기 위한 방안도 필요하다. 기업에서 불편한 변화를 줄이기 위한 한 가지 흔한 방법으로 여러 개의 변화를 ‘릴리즈(release)’로 모으는 방법이 있다.
이러한 릴리즈 개념은 하드웨어와 소프트웨어 업체들에 의해 널리 이용되고 있으며, 변화의 일정 양을 주별, 월별, 혹은 분기별로 미리 짜여진 수많은 이벤트들로 줄여준다. 이 방안의 문제점으로는 긴급하게 필요한 변화가 지연될 가능성과, 장애관리의 어려움이 커짐에 따라 변화 후 문제가 생길 가능성이 보다 많다는 점을 꼽을 수 있다. 게다가 사업팀의 요구로 한 번 취소가 되면 그 이외의 주나 월, 분기에서 중요한 변화가 무효화될 수 있다. 이런 경우에는 응급 업데이트를 요청할 수 있는 프로토콜이 있어야 한다.

응급 프로시저(emergency procedures)
새로운 취약성을 차단하기 위한 패치와 같이, 앞서 얘기한 권한부여와 승인이 확보될 수 없을 때 발생하는 응급 변화를 처리하기 위한 적절한 프로시저를 결정하라. 이것은 종종 표준 편차(standard deviation)라고도 불린다. 많은 조직에서는 또한 정보 프로세싱을 24/7/365로 돌리고 있다. 이런 상황에서는 변화가 가끔씩 신속하게 이뤄져야 하며, 완전한 변화 승인 프로세스를 마치는 게 사실상 불가능할 수가 있다. 이런 사태가 불가피하다는 것을 안다면 편차 프로시저는 필수다.
표준 편차는 응급 상황에서 언제 누가 어떻게 대응을 해야 하는지를 결정할 수 있게 도와준다.

>> ‘언제(When)’는 관리자와 운영자가 편차가 적절한 때가 언제인지를 알아낼 수 있게 도와준다.
>> ‘누가(Who)’는 편차를 허용하기 위한 호출을 누가 만들 수 있는지, 그리고 사업팀과 기술팀의 관점 모두에서 누가 구두 승인을 제공해야 하는지를 지정한다.
>> ‘어떻게(How)’는 행동이 취해지기 전에 어떤 프로시저가 요구되는지를 엔티티가 결정할 수 있게 도와준다. 엔티티가 응급 유형으로 변화를 이행한다 하더라도 그 변화가 임시적으로 이뤄져야 한다는 의미는 아니다. 단지 이것은 회사에서 충분히 빨리 변화를 이행하지 못한 결과로 보다 많은 비용 손실이 나는 것을 막기 위해, 변화의 측면에서 보다 많은위험을 감수한다는 것을 의미한다.

표준 편차에 반드시 포함돼야 할 제어 요소들로는 다음과 같은 것들이 포함된다.

>> 경영진에 의한 사후 변화 분석
>> 변화에 따라 실시하는 사후 테스팅
>> 헬프데스크와 CM 시스템으로 사후 등록

업무 분담(segregation of duties)
변화를 요청하는 사람과, 이러한 변화의 권리를 부여하는 사람, 그리고 이들을 생산 시스템에 배치하는 사람이 서로간에 중복이 되지 않도록 하라. 회계 업계에서는 수십년간 업무 분장에 대한 필요를 인식해 왔지만, 최근에 이르러서야 IT에서 빛을 보고 있다. 기업에서 변화에 대한 효과적인 제어가 이뤄지려면, 어떤 한 사람이 변화의 요청, 승인 및 이행을 허용받아서는 안 된다. 이러한 권한을 허용한다면, 수많은 문제의 가능성들에 문을 열어주는 셈이 된다.

>> 변화를 만드는 사람이 기업의 필요를 완전히 이해하지 못할 수 있으며, 이러한 필요에 부합하지 않는 변화를 만들 수도 있다.
>> 부정직한 직원이 네트워크에, 혹은 심지어 애플리케이션 안으로 백도어를 만들 수 있다.
>> 보안 개념이 충분히 없거나 고려되지 않을 경우에, 이행된 변화로 인해 기업이 재정적 손실이나 명예훼손을 경험하거나, 혹은 법적인 책임을 지게 될 수 있다.

아무리 신중하게 책임을 분리시키려 하더라도 여러 그룹의 직원들이 서로 공모하여 해를 입힐 수 있는 변화를 만들어낼 경우에는 아무런 소용이 없다. 2002년 제정된 사베인스 옥슬리 법안(Sarbanes-Oxley Act)은 이 점을 염두에 두고 임원들이 내부 제어가 이행 및 감사되고 있다는 사실을 거론하지 않도록 금지하고 있다. 이는 오해를 불러일으키거나 가공된 정보에 대한 책임을 임원들에게 지움으로써 공모를 막기 위한 것이다.

철회 계획(back-out plans)
제안된 모든 변화가 뜻하지 않은 부정적인 결과가 나올 때 취소될 수 있도록 해야 한다. 앞서 언급한 것처럼 크고 복잡한 환경을 다룰 때는 고려해야 할 많은 변수들이 있다. 날짜가 지난 애플리케이션, 지원되지 않는 OS, 맞춤 코딩된 애플리케이션, 그리고 복잡한 보안 필터 등은 아무리 간단해 보이는 변화라 하더라도 이를 회사의 서비스 거부로 바꿔버릴 수 있다.
이러한 부정적 결과가 미치는 영향력을 줄이려면, 잘 정리된 변화 철회 프로시저를 승인 프로세스에 포함시켜야 한다. 철회 프로시저는 아마 상세한 백업 및 복구 프로시저이거나, 아니면 간단하게 변화에 앞서 고스트 이미지를 가지라는 것이 될 수도 있다. 어쨌든 이 프로시저는 상세하게 단계별로 안내가 돼야 한다. 결국 철회 프로시저를 이행하기로 할 때가 되면, 다시 온라인으로 돌려놓아야 한다는 엄청난 압박을 받고 있을 것이기 때문이다.

변화 종료(closing change)
마지막으로, 필요한 모든 변화의 단계들이 완료됐는지, 변화의 완료에 관한 모든 정보가 기록됐는지를 확인하라. 변화 관리는 하나의 전체 라이프 사이클로서, 요청에서 시작해서 필요한 모든 단계들이 있는지를 확인하는 전체 프로세스의 리뷰로 끝이 난다. 변화 후 분석을 통해, 기업에서는 프로세스를 지속적으로 발전시킬 수 있다. 이들은 또한 확인되지 않았던 곳들을 찾아내 업무에 지장을 주기 이전에 간과된 부분은 고칠 수도 있다.