변경 제어

품질 관리 시스템(QMS) 및 정보기술(IT) 시스템 내에서 변경 제어, 변경 관리, 체인지 컨트롤(change control)은 제품 또는 시스템에 대한 변경 사항이 통제되고 조율된 방식으로 도입되도록 하는 데 사용되는 공식적 또는 비공식적 프로세스이다. 이는 불필요한 변경 사항이 사전에 고려되지 않고 시스템에 도입되어 시스템에 오류를 발생시키거나 다른 소프트웨어 사용자가 수행한 변경 사항을 되돌리는 가능성을 줄인다. 변경 제어 절차의 목표는 일반적으로 서비스 중단 최소화, 백아웃 활동 감소, 변경 구현에 관련된 자원의 비용 효율적인 활용을 포함한다. 프로젝트 관리 연구소에 따르면, 변경 제어는 "프로젝트와 관련된 문서, 결과물 또는 기준선에 대한 수정 사항이 식별, 문서화, 승인 또는 거부되는 프로세스"이다.

변경 제어는 IT, 소프트웨어 개발, 제약 산업, 의료 기기 산업, 및 기타 엔지니어링/제조 산업을 포함한 다양한 산업에서 사용된다. IT 및 소프트웨어 산업의 경우 변경 제어는 더 광범위한 변화관리 분야의 주요 측면이다. 컴퓨터 및 컴퓨터 망 환경의 일반적인 예로는 소프트웨어 제품의 패치, 새 운영체제 설치, 네트워크 라우팅 테이블 업그레이드 또는 이러한 기반 시설을 지원하는 전력 시스템 변경이 있다.

ITIL의 특정 부분은 변경 제어를 다룬다.

 과정 
변화관리, 구성 관리 및 변경 제어 사이에는 상당한 중복과 혼란이 있다. 아래 정의는 아직 다른 정의와 통합되지 않았다.

변경 제어는 다음 여섯 단계로 설명할 수 있다.

 계획/범위
 평가/분석
 검토/승인
 구축/테스트
 구현
 종료

 계획/범위 
제안된 변경의 주요 및 보조 세부 사항을 고려한다. 여기에는 변경 식별, 소유자, 통신 및 실행 방법, 성공 확인 방법, 변경의 중요도 추정, 추가 가치, 비즈니스 및 산업 표준 준수, 완료 목표 날짜와 같은 측면이 포함되어야 한다.

 평가/분석 
영향 및 위험 평가는 다음 중요한 단계이다. 실행될 때 제안된 계획이 잘못될 수 있는가? 관련 시스템이 제안된 변경에 영향을 받을 것인가? 이 단계에서는 사소한 세부 사항도 고려해야 한다. 그 후, 제안된 변경에 이상적으로 고위험, 중간 위험 또는 저위험의 위험 범주를 할당해야 한다. 고위험 변경은 경영진 승인 및 이해 관계자 통지와 같은 많은 추가 단계를 요구하는 반면, 저위험 변경은 프로젝트 관리자 승인과 최소한의 문서화만 요구할 수 있다. 계획/범위에서 다루지 않은 경우, 특히 심각한 최악의 시나리오가 있는 고위험 변경의 경우 백아웃 계획의 필요성을 표명해야 한다.

 검토/승인 
변경 관리자, 변경 제어 위원회, 운영 위원회 또는 프로젝트 관리자 등 일반적으로 검토 및 승인 프로세스가 필요하다. 계획/범위 및 영향/위험 평가는 비즈니스 목표, 요구 사항 및 리소스의 맥락에서 고려된다. 예를 들어, 변경 요청이 심각도가 낮고 영향이 적은 문제이지만 해결하는 데 상당한 리소스가 필요한 것으로 판단되면 요청의 우선 순위가 낮아지거나 완전히 보류될 수 있다. 영향이 큰 변경이 요청되었지만 강력한 계획이 없는 경우, 검토/승인 주체는 추가 분석을 위해 완전한 비즈니스 사례를 요청할 수 있다.

 구축/테스트 
변경 제어 요청이 진행하도록 승인되면, 배송 팀은 테스트 또는 개발 환경에서 소규모 개발 프로세스를 통해 솔루션을 실행한다. 이를 통해 배송 팀은 유닛 테스트 및 회귀 테스트를 통해 증분적인 변경 사항을 설계하고 만들 기회를 얻는다. 저위험 변경의 경우 테스트 및 검증이 거의 이루어지지 않을 수 있지만, 주요 변경 사항은 구현 전에 상당한 테스트가 필요하다. 그런 다음 승인을 얻고 구현 단계를 수행할 시간과 날짜를 요청한다. 솔루션을 테스트할 수 없는 드문 경우, 변경/구현 기간에 대한 특별한 고려가 필요하다.

 구현 
대부분의 경우 변경 사항을 신속하게 진행할 기술 전문 지식을 갖춘 특별 구현 팀이 변경 사항을 구현하는 데 사용된다. 팀은 승인된 계획뿐만 아니라 조직 표준, 산업 표준 및 품질 관리 표준에 따라 변경 사항을 구현해야 한다. 구현 프로세스에는 문제 해결에 도움을 요청할 수 있는 이해 관계자를 포함하여 구현 팀 외의 추가 직원 책임이 필요할 수도 있다. 구현 후 팀은 사후 구현 검토를 수행할 수도 있으며, 이는 다른 이해 관계자 회의 또는 프로젝트 종료 절차 중에 이루어질 수 있다.

 종료 
종료 과정은 변경 제어에서 가장 어렵고 중요한 단계 중 하나일 수 있다. 이 최종 단계의 세 가지 주요 작업에는 프로젝트가 실제로 완료되었는지 확인하는 것, "프로젝트 완료 맥락에서 프로젝트 계획"을 평가하는 것, 그리고 프로젝트 성공의 가시적인 증거를 제공하는 것이 포함된다. 최선을 다했음에도 불구하고 변경 제어 과정에서 문제가 발생한 경우, 미래의 변경 사항에 배운 교훈을 적용할 의도로 발생한 일에 대한 사후 분석을 실행해야 한다.

 규제 환경 
우수 의약품 제조 및 품질관리 기준 규제 산업에서 이 주제는 사용자들에게 자주 접하게 된다. 이 개념을 이해하기 위해 다양한 산업 지침과 해설이 제공된다. 일반적으로 이 활동은 하나 이상의 표준 운영 절차에 의해 지시된다. 임상시험을 위한 정보기술 관점에서, 이는 다른 미국 미국 식품의약국 문서에 의해 안내되었다.

 같이 보기 
 변경 요청
 변경 주문
 엔지니어링 변경 주문
 문서화
 식별자
 버전 관리
 체인지로그
 살아있는 문서
 시방서
 표준화
 범위 (프로젝트 관리)

 각주 

 참고 문헌 

분류:프로젝트 관리
분류:정보 기술 관리
분류:소프트웨어 프로젝트 관리