Creating a change request
You create change requests by selecting Create New > Change Request. Your administrator might also have configured the system so that you can generate certain kinds of change requests through the Smart Recorder by submitting a service request. See Submitting service requests. If you need to copy an existing change request, use the mid-tier-based UI for the BMC Change Management application in the BMC Remedy ITSM Suite. For more information, see (BMC Change Management documentation).
You can use a change template that the administrator provides, or you can create a new change request. In both cases, a wizard in Smart IT helps you enter the necessary information, as described in the following example.
While searching for a template, the template appears if you type the exact name (including symbol) of the template as it was given in the ITSM while creating the template. For example, if you have given the template name in the ITSM as "Template<", you should search the template with the exact text as "Template<".
Example of creating a change request by using Smart IT
Allen Allbrook is a specialist in the network infrastructure group. His manager, Mary Mann, asks him to reconfigure the routing table of some networking equipment. Because this activity might affect technical or business services in the company environment, Allen must submit a change request according to his company's policy. The change must be properly documented, assessed for risk, and approved.
Allen determines that this reconfiguration will be a normal change that affects the Network business service. Because no change template is available for this type of change, Allen must create the change from scratch:
- Allen opens Smart IT from his desktop browser and selects Create New > Change Request.
He chooses the option to create a change request from scratch, and selects Normal from the available change classes.
The wizard opens with some information pre-populated and required fields clearly marked.
In the Basics section of the wizard, Allen provides a short summary of the change needed, and he records the impacted site. Type-ahead functionality allows him to correctly populate the Requested For and Affected Service fields. Allen chooses to let the system select the best match for the change assignment.
- In the CI section, Allen performs a few concurrent searches to locate the affected network device and then relates the CI to the change request.
Allen decides to enter additional information that is not required to create the initial change request:
In the Dates section, Allen specifies a range of dates approximately 3 weeks from today.
- In the Risks section, Allen answers a few questions that the system uses to calculate risk.
In the Documents section, Allen selects the Requirements and Backout Plan documentation types and records some initial notes for each.
Your organization might require specific types of documents depending on the class of change (such as Normal or Standard). For each type of documentation, you can record simple notes or upload files.
- Allen saves the change request.
The change request is created in Draft mode. A dialog is displayed that gives Allen the option of running an impact analysis now, or returning to the change request later to run the analysis manually.
- Allen clicks Submit and Prepare Impact Analysis.
While the impact analysis is running, Allen launches a new Smart IT window to continue working. He will receive a notification when the impact analysis is ready.
Allen is notified about future updates to this change request in his Updates feed. When adding notes to the change request, he can reference additional team members with "@" mentions so that they receive notifications in their Updates feeds.
When you create a change request, the calendar does not show any other existing changes for the same period. In Smart IT only individual change request, and in case of collision, the corresponding change requests that have collision are displayed. When you create multiple change requests and add the same CI to the change requests, it pushes the calendar to show the collisions. In Mid tier, change calendar shows changes happening regardless of collision.
Searching for CIs that are in Delete status
When you run a global search for CIs or when you relate CIs to an incident or a problem investigation ticket, by default the system does not display CIs in Delete status. However, you can search for CIs that are in Delete status from change requests and assets. On the Asset Console, to filter CIs in Delete status, you must select the Delete check box from the Status list.
To restore a CI that is in Delete status, when you create or edit change requests, on the CI tab, perform the advanced search and select the Delete check box to search for CIs in delete status. From the search result, relate the change request with multiple CIs that are in Delete status to track configuration changes made to the CIs.
Similarly, you can search for CIs in Delete status from assets. To do so, on the the Assets tab of the asset profile, click the Relate Existing Asset link. On the Relate Assets pane, perform the advanced search to search for CIs that are in Delete status. From the search result, relate the asset with multiple CIs that are in delete status.
- If you do not want the system to search for CIs in delete status, you must select the check boxes for the statuses that you want to search, and clear the Delete check box.
- By default, in the search result the system displays CIs in all statuses including the delete status.
Specifying change location
When creating change requests from scratch without using a change request template, in the Change Location field, you must specify the location where the change needs to be implemented. The change location depends on the following factors:
- The company specified in the Company list.
- The company and location of the customer specified in the Requested For field.
- The company and location of the service desk agent who is creating the change request.
These companies might not be same. The location in the Change Location field is driven by the company specified in the Company list. A company can have multiple locations.
Consider three companies—Company A, Company B, and Company C. The location details of these companies are as follows:
- Company A—Texas and New York
- Company B—Toronto and Vancouver
- Company C—Shanghai
The following table indicates the basis on which the location is specified in the Change Location field on the change request profile.
|Company and location of the service desk agent||Company specified in the Company list||Company and location of the person specified in the Requested For field||Location in the Change Location field|
|Company A (Texas)||Company A||Company A (New York)||Company A, New York. The location of the person specified in the Requested For field.|
|Company A (Texas)||Company B||Company B (Toronto)||Company B, Toronto. The location of the person specified in the Requested For field.|
|Company A (Texas)||Company A||Company B (Vancouver)||Company A, Texas. The location of the service desk agent.|
|Company A (Texas)||Company B||Company A (New York)||The Change Location field remains empty. To specify the location, in the Change Location field the system displays locations of the Company B.|
|Company A (Texas)||Company B||Company C (Shanghai)||The Change Location field remains empty. To specify the location, in the Change Location field the system displays locations of the Company B.|
When creating change requests by using change request templates, if the company specified in the template and the company selected in the Company list are similar, the location specified in the template is populated in the Change Location field. If the companies differ, the company location is populated based on the details given in the table in the example.
Additional considerations about activity notes
In BMC Change Management, you can add work notes to change requests and select the type of work note from the Work Info Type list. By default, the following subtypes are displayed in the Work Info Type list:
Work Info type
|Work Info subtypes|
Business Justification, and Requirements
Change Assessment, Potential Problems, Risk Assessment, and Service Impact Assessment
|Build||Backout Plan, Business Design, Development, Install Plan, Technical Design, and Test Plan|
|Execution||Backout Results - Details, Install Results - Details, and Test Results - Details|
|Closure||Cancellation Information, and Post implementation Review|
|Audit||Configuration Audit, SLM Compliance Audit, and SLM Process Review|
|General||General Information, Rejection Information, Email System, Paging System, and Chat|
- Work notes in BMC Change Management are referred to as notes in Smart IT and Work Info Type list is named as Type list.
- The information in this section is also applicable to release tickets in Smart IT.
Similarly in Smart IT, on the Activity tab of change requests, you can add notes and select a subtype from the Type list. By default, the subtypes under Execution, Closure, Audit, and General are displayed under the Type list.
In Smart IT, the subtypes under Requirements, Analysis, and Build are available as document types in the Documents tab of change requests. Thus, on the Activity tab of change requests they are not listed under the Type list, and in the filters under the Show Note Types list.
You must consider the following points:
- If you add a custom note type in BMC Remedy ITSM under the Requirements, Analysis, and Build types, the custom note type is displayed in the Type list in Smart IT.
- If you add a work note to a change request in BMC Change Management, and specify a work note subtype under Requirements, Analysis, or Build, then in Smart IT, that work note is added to the corresponding document type on the Documents tab.
- You cannot add custom document types on the Documents tab.
How administrators configure Smart IT change management functionality
The administrator must ensure that users have the minimum permissions needed to access change management functionality in Smart IT. For more information, see Smart IT roles and permissions.
Risk assessment is based on settings in BMC Remedy ITSM. The administrator must configure risk factor questions and derived risk factors as explained in of the BMC Change Management documentation.
The administrator also configures the change templates, task templates, and task group templates needed to implement change requests. For more information, see Scenarios for creating tickets using Smart IT.
For standard changes, the administrator should consider creating a service request definition (SRD) that generates a change request automatically. This way, the change request can be initiated by submitting a service request through the Smart Recorder.
If your organization requires custom fields to capture additional data in change requests, the administrator can add those fields to the change wizard. For more information, see Adding custom fields to your views using Smart IT.
The administrator can configure the attachment criteria, and the supported file extensions in BMC Remedy ITSM, in the Attachment Security tab of the Server Information form