Benefits of Best Practice view in the Release Management module
The following table describes the benefits of the Best Practice view in the Release Management module of Change Management.
Benefits to the Best Practice view of the Release Management form
Feature | Best Practice view | Benefits |
|---|---|---|
Assignment | Fields on Main view:
| Key information for managing release requests includes knowing which group and which person is responsible for coordinating the release until it is closed. Best practice recommends that that the release coordinator is the same person who creates the release request. This is why these fields are automatically completed with the submitter's information if that person has the functional role of Release Coordinator. If you leave the fields blank, the Assignment rules determine the field values after the submission. |
Release Location | Fields on Main view:
| Key release management information includes knowing where the release is coordinated from. The application also uses this field to determine access rights for multitenancy implementations. |
Service | Field on Main view:
| This field was moved to the Main view, because the information it contains is considered key information. Out-of-the-box, the Service field is a required field. This ensures that service awareness is used for routing purposes and metrics can be tracked by the selected Service. However, you can configure the field to not be required. |
Template | Field on Main view:
| Adding the Template field to the Main view encourages the use of templates and enables you to search and report on the changes created by template. |
Notes | Field on Main view: | The Notes field contains key release information. |
Business Justification | Field on Main view:
| The Business Justification field contains key release information. |
Target Date | Field on Main view: | The Target Date is part of the key release information. The Target Date is the date by when the release must be completed, according to the applicable service level targets. Alternatively, the target date can be a date that is agreed to on an ad hoc basis, for each release. |
Work Info | Fields and table on Work Detail tab (shown initially): | Key release information includes Work Info entries. |
Release Type | Field on Main view | The Release Type is used to identify the type of release that is being handled. |
Requester | Fields not available | Best practice recommends that you review the related incident requests or known errors, or both, to determine who requested the release. The release could have been requested by multiple people. |
Time Spent | Field on Date/System tab: | The Cumulative Efforts field was added in preparation for the automatic roll-up of time tracked in related activities and changes. |
Approval | Table on Main view (Work Detail tab) | The Approvers table contains key release information. |
Operational Categorization | Fields available for quick selection using the Select Operational link under Quick Actions. Customers can view all operational and product categorization values using the Categorization links. | Research suggested that most BMC customers use the operational categorization fields only sporadically. This means that even when the fields are completed, they cannot be used for reporting, because they are not consistently completed. Based on this, access to the fields was moved to a tab, which you configure to appear or be hidden, according to your organization's needs. You can specify the operational categorization values for each template. |
Product Categorization | Fields on Categorization tab (if configured to be displayed):
| These fields were moved to the Navigation pane, because using the CMDB is a better way to perform grouping, trending, and assignment. This, and wanting to reduce the registration time of new incident request records, means that now the product categorization is automatically completed based on the product categorization of the related service. |
Financials | Available as a link under Links | Nonessential information is moved to other areas, providing a more streamlined application. |
Dates | Fields on the Date/System tab with the exception of Actual Start Date and Actual End Date | The two date fields are not considered essential for the release resolution or for reporting purposes. |
Next Stage | The Next Stage button was introduced in the Best Practice view. | These buttons were added to increase efficiency. |
Read-only behavior | When you do not have modify access, the following message is displayed at the top of the form: You do not have permission to modify this ticket. The fields are not disabled or read-only, but you cannot save any modifications. | This aids with simplification and enhances performance. |