시간이 경과하면서 제품 품질이 향상되고 시장 요구 사항이 바뀌며 혁신적 아이디어가 기존 제품에 결합되면서 제품은 발전하게 됩니다. 제품을 릴리즈하기 전, 제품 라이프 사이클의 초기에는 비공식적인 변경을 쉽게 채택할 수 있습니다. 하지만 제품 디자인이 숙성되고 생산에 돌입하게 되면 변경 계획이 더 복잡해지고 비용이 증가하기 때문에 보다 공식적인 프로세스를 사용해야 합니다.

Windchill에서는 비공식적 및 공식적인 변경 프로세스를 모두 진행합니다. 각 회사의 공식적인 변경 프로세스는 저마다 다르지만 모든 회사가 공유하는 여러 모범 사례가 있습니다. Windchill에는 일반적인 모범 사례를 캡처하는 공식적인 변경 프로세스가 포함됩니다.

표준 Windchill 프로세스는 다음 다이어그램에 표시된 5가지 기본 단계로 구성됩니다. 각 단계는 자동화된 워크플로에 의해 제어됩니다. 순서도 상자를 클릭하면 기본 프로세스 단계 설명으로 바로 이동합니다.

앞에서 설명한 네 가지 기본 변경 객체는 서로 연결되어 있으며 변경 프로세스의 전체 기록을 제공합니다. 변경 객체 네트워크 및 객체간 관계는 다음 다이어그램에 나와 있습니다. 변경 객체 네트워크는 왼쪽 위의 문제 보고서에서 시작해서 오른쪽 아래의 변경 임무 쪽으로 이동하면서 구성됩니다. 변경 객체 네트워크는 변경 임무 완료에서 시작해서 왼쪽 위의 문제 보고서까지 뒤로 작동하여 반대 순서로 해결됩니다.

부품 또는 문서의 정보 페이지나 기존 문제 보고서에서 변경 요청을 작성할 수 있습니다. 문제 보고서에서 변경 요청을 작성하는 경우 두 개의 변경 객체가 자동으로 서로 관련됩니다. 영향 받는 데이터를 문제 보고서에서 변경 요청으로 복사할 수 있습니다. 하나의 변경 요청에서 여러 문제 보고서를 처리할 수 있습니다.

검토 보드 변경(CRB)에서 변경 요청의 구현을 수락하면 사용자가 변경 요청에서 변경 공지를 작성하고 두 객체를 자동으로 관련시킵니다. 변경 공지는 구현 계획에 필요한 하나 이상의 변경 임무로 구성되며 변경 객체 네트워크에 다시 한 번 추가됩니다. 각 변경 객체에는 완료 시까지 제어하는 바로 사용할 수 있는 워크플로가 있습니다. 한 워크플로의 임무가 완료되면 다음 워크플로의 임무가 시작되도록 개별 워크플로가 연결됩니다. 변경이 완료되면 워크플로에서 변경 객체의 상태를 변경하고 이해 관계자에게 공지를 보내 프로세스 루프를 닫습니다.