Affected Objects, Review Objects, Affected End Items, and Resulting Objects
The Change Management process identifies a series of work that needs to be performed on a product or process. Through this process, the objects to be changed are identified as impacted by the change. The change is justified from a business and technical standpoint and the new and updated objects are identified as the result of the change and made available to the enterprise. To help identify, manage, and track these steps, there is a series of tables used in the Change Management process which include Affected Objects, Review Objects, Affected End Items, and Resulting Objects.
Affected Objects
The Affected Objects table is available on problem reports, variances (deviation or waiver), change requests, and change tasks. The Affected Objects table is used on the various change management objects to capture the objects involved as they evolve through the change management process:
• Problem report—The Affected Objects table identifies specific issues or improvements that need to be investigated. If it is determined that further action needs to be taken, affected objects can propagate to a change request if it is created from the problem report. For example, a heat exchanger has failed a set of performance tests in trials. The cause needs to be investigated and determine if a change is needed to meet the product requirements.
• Variance:
◦ Deviation—The Affected Objects table identifies specific objects that a supplier or manufacturer requests to be accepted that is outside of specifications provided. Typically, there is a time period and/or quantity associated to the acceptance. For example, the supplier produced a casting out of tolerance and asks engineering if the parts can be accepted rather than discarding them.
◦ Waiver—The Affected Objects table identifies specific objects that a manufacturing supply chain is requesting that either an alternate manufacturing process or an alternate part be used for a specific time period or quantity. For example, a supply chain notifies manufacturing and engineering that a pump from Supplier 1 is out of stock, but an equivalent pump from Supplier 2 is in inventory and requests to use that to satisfy production needs.
• Change request—The Affected Objects table identifies specific objects that are under consideration for the change. The objects on the change request give visibility to what will be impacted by the change. During the change request process, the technical and business justification of the change is validated. If the change request is approved, the data from affected objects can be propagated to the change tasks on the change notice, when created from the change request. For example, a new cost reduction initiative requires a frame and wire harness to be looked at for cost down while maintaining performance and safety requirements. The frame and wire harness are added as Affected Objects and can be used to also find their parent where used that might also be impacted.
• Change task—The Affected Objects table identifies specific objects to be changed or modified during the change. This also gives a clear indication of what work the user must focus on for the change task. This can result in Revisions, Supersedes, new objects, Save-As and other actions. On the change task, you can further identify Dispositions to help the enterprise understand the scope of the execution for the change. For example the previous cost reduction project is determined to go forward. Two change tasks are created, one for the frame and one for the wire harness so that the appropriate design tasks can be provided to the engineers. Comments and visual annotations are related to the Affected Objects on the change tasks so the engineers have detail about the work to be done.
The Affected Objects table allows you to add comments on each object to provide more detail. Further information, such as visual markups and structural annotations can be related to the objects in the table to provide more detail about the scope of the change.
Review objects are the subject for reviews. The Review Objects table available from a design and peer review pages lets you manage review objects.
Affected End Items
The Affected End Items table is used to capture End Items that are top level to parts being added to a change. This creates a relationship to the end item part and the change, allowing traceability of all changes that the end item part has undergone.
|
|
This is related to the part master for this part so that all the changes can be rolled up regardless of the part revision.
|
If you do not want to display the Affected End Items table for problem reports, variances, and change requests, navigate to > > , and set the preference to No.
|
|
The preference is ignored for problem reports, variances, and change requests that have existing affected end items or for changes that exist in project contexts.
|
An example of leveraging the Affected End Items table is using the Query Builder Report.
Resulting Objects
Resulting objects are the changed or new product or process objects that are going to be released to the enterprise as a result of the change. The Resulting Objects table is available from a change task within a change notice. On this table you can identify the changed objects that can be added in a variety of methods including:
• Revise from Affected Objects
• Supersede from Affected Objects
• Add through Search or Quick Entry
• Add using the Collector
From the Resulting Objects table there are two key change capabilities:
• Mass Change—The mass change operation can be performed from the Resulting Objects table. Mass change allows you to easily and efficiently update a large quantity of part structures. These updates can include
◦ Inserting, removing, and replacing parts
◦ Changing usage values such as Quantity, Line Number, and Find Number
◦ Inserting or removing documents and CAD documents
• Effectivity—Effectivity can be applied to objects that are managed using effectivity on the Resulting Objects table. Similar to mass change, the ability to propagate effectivity is only supported in the change process. This is so that large changes can be made easily, and the change process provides the oversight before the execution is made.
The
Resulting Objects table allows you to add comments to each object to provide more detail. For more information, see
Resulting Objects Table.
Resulting objects can also be viewed from a change notice, using the Change Summary table. This table enables you to see all of the affected and resulting objects in all of the change tasks for a change notice. The Change Summary table provides quick access to all of the data in one spot without having to navigate, allowing you to quickly understand and access the information.
From an object information page, you can also see which changes are affected and which are resulting, allowing you to understand the traceability to the changes that impacted it.
Resulting objects can also be displayed in the Change Notice Summary report. This report delivers a view of the resulting objects on the change notice and can be run with other reports. Information in this report includes the following:
• Resulting objects
• 1st level BOM changes for parts
• Disposition information and comments
• Attribute changes and related information changes
If desired, the report can be automatically generated as a PDF and stored on the change notice as an attachment. For example, you can generate the change summary report and attach it back to the change notice prior to the CIB review, and then create a PDF at release and store that as well.
The following code can be added to a Workflow expression robot where the following is true:
• The contextObject is the change notice to be processed.
• reportName is the report to be run.
• filename is the name of the PDF file to be generated.
ReportHandlerFactory.getInstance().handleReport( contextObject, reportName, ContentRoleType.SECONDARY, filename);
