When you reject a Change Action in 3DEXPERIENCE, several scenarios can occur, and the impact of rejection can vary depending on the phase of the Change Action and the specific configurations of your environment. Here are the main effects of rejection and their implications:
1. Cancellation of modifications in progress
Initial phases (Preparation or Validation) :
If the change action is rejected during the preparation or validation phase, the associated modifications are generally not yet fully implemented in the production system. In this case, the rejection results in the cancellation of the changes in progress.
Here’s what often happens:
-
Preparation or Validation phase :
- Description: Modifications are in preparation or awaiting validation.
- Impact of rejection: As these changes have not yet been integrated into the production system, their rejection automatically deletes them, with no impact on validated data.
Example: A 3D model modified in a local work session which has not yet been saved on the 3DEXPERIENCE platform.
- Return to previous state: modified objects remain in their original state before the change action was initiated.
Advanced phases (Execution) :
If the change action is rejected after it has begun to run but before it has been finalized, the changes may already have had some impact on the system.
In this case :
- Cancellation of partially applied modifications:
- Description: Changes have begun to be applied and have had an impact on the system.
- Rejection impact: Rejection requires manual intervention to restore objects to their previous state. This may include deleting specific versions or restoring old versions.
Example: A part that has been partially modified and saved in the 3DEXPERIENCE platform, but not yet fully propagated to all views or configurations.
- Deleting changes: Objects that have been modified can be restored to their previous state using revisions.
Closing phase (changes fully implemented) :
If the change action is rejected after execution, the consequences are quite different:
-
- Description: The changes have been fully implemented and are active in the production system.
- Impact of Rejection: Once changes have been finalized and integrated, they cannot simply be deleted. A new change action is required to make corrections.
Example: Structural changes to a product or manufacturing updates that have been fully validated and integrated into production processes.
2. Standby or Review
When a change action is rejected, it can be put on hold for further analysis. This enables teams to understand why changes have been rejected, and to decide whether they should be corrected or abandoned altogether.
- Reviewing changes: A team can be assigned to review changes and propose adjustments before resubmitting them for approval.
- Suspension: The change action is temporarily paused until further decisions are made.
Example: If a manufacturing process change is rejected because of concerns about its feasibility, the team can review the changes and adjust the plan before resubmitting them.
3. Communication and Documentation
Rejection of a change action must be clearly communicated to all stakeholders concerned. The reasons for rejection must be well documented to avoid misunderstandings and to assist future decision-making.
- Rejection report: A report detailing the reasons for rejection and possible impacts must be created and shared.
- Change history: The rejected change action must be properly recorded in the system to maintain a clear history of decisions.
Example: If a product design change is rejected, a report explaining why the changes are not acceptable is sent to the design and project management teams.
4. Restitution and Remediation
For changes already implemented, restitution involves returning objects to their previous state. This can include operations such as :
- Restore previous versions: Previous versions of modified objects are reactivated or restored to their active state.
- Data cleansing: Data entered or modified by the rejected change action is cleaned from the system.
Example: If a design file is modified and the change action is rejected, the previous version of the file can be restored and the modified version deleted from the system.
Conclusion
Rejecting a change action in 3DEXPERIENCE has various implications, depending on the phase of the change action and the nature of the modifications made. The rejection process is designed to minimize the impact of errors and enable efficient change management, ensuring that system objects are always in a consistent, validated state.
👉BONUS👈
Best practices to avoid data loss
To minimize the risk of data loss and ensure effective change management, here are a few best practices:
-
Always work in the context of a Change Action:
- Benefit: Keeps track of all modifications and associates them with a specific change action.
- Practice: Ensure that all changes to a product or document are linked to a valid change action.
-
Using Review :
- Benefit: Revisions allow you to keep track of changes and return to a previous version if necessary.
- Practical: Create a new revision before making major changes. Use the revision history to manage changes.
-
Perform regular backups :
- Advantage: Regular backups ensure that you can recover data in the event of rejection or error.
- Practical: Schedule automatic backups of critical projects and documents.
-
Audit and validate changes before final approval:
- Benefit: Minimize errors by validating changes with stakeholders before final validation.
- Practice: Conduct change reviews with multidisciplinary teams to identify potential problems.
-
Document and communicate the reasons for rejection :
- Benefit: Clear documentation helps you understand why a change was rejected and how it can be corrected.
- Practical: Create detailed reports for each release and share them with all relevant stakeholders.
