Managing Product Change

Products evolve over time as product quality is improved, market requirements change, and innovative ideas are incorporated into existing products. Informal changes can be easily adopted early in the product life cycle before a product is released. However, when product designs mature and are released to production, a more formal process must be used as change planning becomes more complex and costs rise.

Windchill facilitates both informal and formal change processes. The formal change process for every company is unique; however, there are many best practices that all companies share. Windchill includes a formal change process that captures common best practices.

The standard Windchill process is composed of five basic steps pictured in the following diagram. Each step is driven by an automated workflow. Click the flow chart box to go directly to a description of the basic process step.

• Step 1-Identify issue—An issue is any reported problem or suggested improvement to a product design and is typically captured in a problem report. The issue is analyzed, discussed, and validated before it is moved to the next step. The use of problem reports is optional; issues may also be documented by change requests and change notices.

• Step 2-Request change—One or more validated issues is addressed by a change request. Change requests start the change process and capture all the relevant data and analysis, including the technical and business justification to execute the change.

The complexity of the change determines whether a simple or robust change process is used. Change requests can be passed through a simplified workflow, referred to as the fast track process, when the changes to be made do not affect orders, production, or retrofits to fielded units. A more robust process, called the full track, is used when the change is complicated, costly, or large in scope. Your company has unique guidelines for determining the track to take.

• Step 3-Plan change—When a change is accepted for implementation, the work to document and implement the change must be planned. A change notice records the implementation plan. The plan includes separate tasks that are associated to the product data to be changed. A schedule is proposed and recommendations are made for the disposition of existing product inventory. Implementation is triggered by the workflow when the plan is approved.

• Step 4-Change implementation—Change tasks are distributed to the people responsible for updating product documentation and capturing new product configurations. New product configurations are released to manufacturing when the physical implementation begins.

• Step 5-Physical implementation—Changes are incorporated in production, and the new and modified parts are inspected to make sure they comply with design requirements. Variances from product specifications are managed using a deviation/waiver process.

The four basic change objects described above are linked together to provide a complete history of the change process. The network of change objects and their relationships is illustrated by the following diagram. Notice that the change object network is created starting with the problem report, at the upper left, moving toward the change task at the lower right. The change object network is resolved in the opposite order, starting with the completion of the change tasks and working backward to the problem report at the upper left.

You can create a change request from the information page of a part or document, or from an existing problem report. When the change request is created from the problem report, the two change objects are automatically related to each other. The affected data can be copied from the problem report to the change request. More than one problem reports can be addressed by one change request.

When the change request is accepted by the change review board for implementation, a user creates the change notice from the change request, automatically relating the two objects. The change notice is made up of one or more change tasks required by the implementation plan, once again adding to the change object network. Each change object has an out-of-the-box workflow that drives it to completion. The separate workflows are linked together so that the completion of tasks in one workflow trigger the start of tasks in the next. The workflow closes the process loop, as the changes are completed, by changing the state of the change objects and sending notifications to stake holders.

The diagram above illustrates the complete change process, using all change objects starting with the problem report. The process can be shortened by starting with a change request or change notice.