제품 변경 관리
시간이 경과하면서 제품 품질이 향상되고 시장 요구 사항이 바뀌며 혁신적 아이디어가 기존 제품에 결합되면서 제품은 발전하게 됩니다. 제품을 릴리즈하기 전, 제품 라이프 사이클의 초기에는 비공식적인 변경을 쉽게 채택할 수 있습니다. 하지만 제품 디자인이 숙성되고 생산에 돌입하게 되면 변경 계획이 더 복잡해지고 비용이 증가하기 때문에 보다 공식적인 프로세스를 사용해야 합니다.
변경 프로세스
Windchill에서는 비공식적 및 공식적인 변경 프로세스를 모두 진행합니다. 각 회사의 공식적인 변경 프로세스는 저마다 다르지만 모든 회사가 공유하는 여러 모범 사례가 있습니다. Windchill에는 일반적인 모범 사례를 캡처하는 공식적인 변경 프로세스가 포함됩니다.
표준 Windchill 프로세스는 다음 다이어그램에 표시된 5가지 기본 단계로 구성됩니다. 각 단계는 자동화된 워크플로에 의해 제어됩니다. 순서도 상자를 클릭하면 기본 프로세스 단계 설명으로 바로 이동합니다.
• 1단계(문제 식별) - 문제는 제품 디자인에 대해 보고된 문제 또는 제안된 기능개선이며 일반적으로 문제 보고서에 캡처됩니다. 문제가 다음 단계로 이동하기 전에 문제를 분석, 토론 및 검증합니다. 문제 보고서 사용 여부는 선택적이며, 변경 요청 및 변경 공지에 의해 문서화될 수도 있습니다.
자세한 내용은 문제 보고서 정보를 참조하십시오.
• 2단계(변경 요청) - 변경 요청에서는 하나 이상의 검증된 문제를 처리합니다. 변경 요청 단계에서는 변경 프로세스를 시작하고 변경을 실행하는 기술적 및 비즈니스 명분을 포함하여 모든 관련 데이터와 분석을 캡처합니다.
변경의 복잡성에 따라 단순한 변경 프로세스를 사용할지, 아니면 강력한 변경 프로세스를 사용할지 결정됩니다. 변경 사항이 주문, 생산 또는 필드 단위 개량에 영향을 주지 않는 경우 빠른 경로 프로세스라고 하는 단순화된 워크플로를 통해 변경 요청을 전달할 수 있습니다. 전체 경로라고 하는 보다 강력한 프로세스는 변경이 복잡하거나 비용이 많이 들거나 범위가 큰 경우에 사용됩니다. 회사에는 사용할 경로를 결정하기 위한 고유한 지침이 있습니다.
자세한 내용은 변경 요청 정보를 참조하십시오.
• 3단계(변경 계획) - 변경 구현이 수락되면 변경을 문서화하고 구현하는 작업을 계획해야 합니다. 변경 공지는 구현 계획을 기록합니다. 계획에는 변경할 제품 데이터와 연관된 별도의 임무가 포함됩니다. 기존 제품 인벤토리의 처리에 대한 스케줄이 제안되고 권장 사항이 제공됩니다. 계획을 승인하면 워크플로에 의해 구현이 트리거됩니다.
자세한 내용은 변경 공지 정보를 참조하십시오.
• 4단계(변경 구현) - 제품 설명서를 업데이트하고 새 제품 구성을 캡처할 책임이 있는 사람에게 변경 임무가 배포됩니다. 물리적 구현이 시작되면 새 제품 구성이 제조 단계로 넘어갑니다.
자세한 내용은 변경 임무 정보를 참조하십시오.
• 5단계(물리적 구현) - 변경 사항이 생산에 통합되고 새 부품과 수정된 부품을 검사하여 설계 요구 사항을 준수하는지 확인합니다. 제품 사양의 분산은 편차/면제 프로세스를 사용하여 관리됩니다.
자세한 내용은 분산 정보를 참조하십시오.
Windchill 변경 객체 네트워크
앞에서 설명한 네 가지 기본 변경 객체는 서로 연결되어 있으며 변경 프로세스의 전체 기록을 제공합니다. 변경 객체 네트워크 및 객체간 관계는 다음 다이어그램에 나와 있습니다. 변경 객체 네트워크는 왼쪽 위의 문제 보고서에서 시작해서 오른쪽 아래의 변경 임무 쪽으로 이동하면서 구성됩니다. 변경 객체 네트워크는 변경 임무 완료에서 시작해서 왼쪽 위의 문제 보고서까지 뒤로 작동하여 반대 순서로 해결됩니다.
부품 또는 문서의 정보 페이지나 기존 문제 보고서에서 변경 요청을 작성할 수 있습니다. 문제 보고서에서 변경 요청을 작성하는 경우 두 개의 변경 객체가 자동으로 서로 관련됩니다. 영향 받는 데이터를 문제 보고서에서 변경 요청으로 복사할 수 있습니다. 하나의 변경 요청에서 여러 문제 보고서를 처리할 수 있습니다.
검토 보드 변경(CRB)에서 변경 요청의 구현을 수락하면 사용자가 변경 요청에서 변경 공지를 작성하고 두 객체를 자동으로 관련시킵니다. 변경 공지는 구현 계획에 필요한 하나 이상의 변경 임무로 구성되며 변경 객체 네트워크에 다시 한 번 추가됩니다. 각 변경 객체에는 완료 시까지 제어하는 바로 사용할 수 있는 워크플로가 있습니다. 한 워크플로의 임무가 완료되면 다음 워크플로의 임무가 시작되도록 개별 워크플로가 연결됩니다. 변경이 완료되면 워크플로에서 변경 객체의 상태를 변경하고 이해 관계자에게 공지를 보내 프로세스 루프를 닫습니다.
 | 위의 다이어그램은 문제 보고서에서 시작하는 모든 변경 객체를 사용하여 전체 변경 프로세스를 보여 줍니다. 변경 요청이나 변경 공지에서 시작하면 프로세스를 단축시킬 수 있습니다. |