When an object needs one or more changes, you use a CO to manage the changes. When you create a CO, a change action (CA) is generated and connected to the CO for each intended change. A change order will have one or more change actions for the implementation of the changes. After all the changes are reviewed and approved, the change order moves to the approved state. Once the change order is completed, its associated change actions are completed. Change Management creates an approval route for routes that the change process creates regardless of whether you create a review route template or an approval route template. A CO follows one of two lifecycles based on whether it is the formal change or the fast track policy. See Formal Change Lifecycle and Fast Track Change Lifecycle. Child Change OrdersIf a change is complex, you can break it into several child COs that are governed by a parent CO. Whether you can add a CO as a child to another depends on the policy of both:
For either change policy, child COs can be added to a parent CO only when the parent is in the In Work state or earlier. A child can have only one parent and a child of its own but recursive parent-child relationships are not allowed. The parent is automatically promoted to the In Approval state when the last child CO or CA is promoted to the Approve state. If any child CO is either not approved or is canceled, the parent will not be promoted to In Approval. Promoting the parent CO to Completed will not complete its child COs. You must promote the child COs individually and manually. If one or more children cannot be promoted, the parent CO will not be promoted. Change Order ApplicabilityYou can assign applicability to a change order that is defined by product revision, manufacturing plan, units, or date. Change order applicability lets you manage changes that may be too large or impractical for a CA. For example, a change to a part may require changes in design and in manufacturing. In which case, the design and manufacturing organizations may each require a CA to implement the change. So, the CO may have an applicability of EXL[2014-2017], Design may have an applicability for CA1 of EXL[2016-2017] while Manufacturing has an applicability for CA2 of EXL[2017]. The applicability definitions for the CO, its child COs (if any), and its associated CAs are independent of each other. Note:
Applicability definitions are not transferred between the CO and CA
or validated against each other.
Change Order DependenciesChange objects that have dependent change objects cannot be completed until the dependent change objects are completed. Dependent change objects can be promoted to any state before the Completed state. You cannot establish dependency between:
|