변경 요청은 변경 관리자 I이 관련 문제 보고서를 하나 이상 검증할 때 작성됩니다. 변경 요청의 목적은 제안된 솔루션, 비용 분석 및 명분을 포함하여 공식적인 변경 분석을 기록하는 것입니다. 변경 요청의 정보는 변경의 구현 여부를 결정하는 데 사용됩니다. 다음 다이어그램은 변경 요청 프로세스 흐름을 보여 줍니다.

문제 보고서의 정보 페이지에서 변경 요청을 작성하고 두 객체를 자동으로 연결할 수 있습니다. 제품 또는 라이브러리의 폴더 안에 변경 요청을 직접 작성할 수도 있습니다.

변경 요청 작성자는 이름 및 설명을 포함하여 중요한 식별 정보를 입력합니다. 변경 요청에 카테고리, 우선 순위, 필요 일자, 제안된 솔루션 및 연관 비용이 포함될 수도 있습니다. 첨부에서 추가 설명을 제공합니다.

자세한 내용은 변경 요청 작성를 참조하십시오.

변경 요청이 완료되면 검토 및 가능한 승인을 위해 워크플로로 제출됩니다.

변경 관리자 I 역할을 수행하는 사람은 변경 요청을 분석할 책임이 있습니다. 변경 요청 워크플로에서 생성된 임무가 변경 관리자의 내 임무 테이블로 보내집니다. 임무 정보 페이지에는 변경 요청에 대한 지침과 링크가 제공됩니다. 변경 관리자는 다음을 결정할 수 있습니다.

변경 관리자가 분석과 구현을 계속하도록 결정하면 변경 요청이 단순 또는 복잡으로 분류됩니다. 단순한 변경은 소규모이고 돈이 많이 들지 않으며 영향이 제한됩니다. 또한 추가 검토 및 분석 없이 구현으로 바로 넘어갑니다. 대부분의 변경은 단순한 변경이며 이 빠른 경로 워크플로 경로를 사용해야 합니다. 복잡한 변경은 대규모이고 돈이 많이 들며 큰 영향을 주는 변경이며, 전체 경로 워크플로 경로를 사용해야 합니다.

자세한 내용은 빠른 경로 및 전체 경로 복잡성 결정를 참조하십시오.

전체 경로는 자세한 분석과 명분이 필요하며 검토 보드 변경(CRB) 회의에서 승인되어야 합니다. 검토 보드 변경(CRB) 회의 전에 필요한 분석을 수행하고 변경 요청에 기록하는 것은 변경 관리자 I의 책임입니다.

검토 보드 변경(CRB)은 변경 요청 정보를 사용하여 변경 요청을 거부 또는 승인하거나 추가 분석과 설명을 위해 돌려보냅니다. 변경 요청이 승인되면 변경 계획 및 변경 공지 작성으로 넘어갑니다.