Creating a change request at the Initiate stage - Classic view
This section describes how to create a change request at the Initiate stage when using the Classic View of BMC Change Management.
To create a change request at the Initiate stage
- From the IT Home Page, open the BMC Change Management application.
For more information, see IT Home page.
On the Change Management console, click Create or Create for Company (in a Hub and Spoke environment).
If you are working in a Hub and Spoke environment, you are asked to identify the company you are creating the record for. Select the company from the drop down list, then click Create. The Change form opens on the spoke server of the company you chose. Continue with the rest of this procedure.
The record that you create for the selected company is created and submitted on the spoke server where the company is defined.
In the Initiate stage, the change request initially appears in Draft status. The change request has not yet been submitted to the Change Management process.
To enter details about the company and user for which the change request is created, in the Requested for area, press Enter on the Last Name field search for the appropriate user. The Change Locationcan, by default, be updated to the selected user's location.
- If you create a new change from the Incident or Problem console, the change appears in Request for Authorization status because the reason for creating the change is already known. This information has been entered by the Incident or Problem before the new change is created.
- After they are updated, the Requested for fields cannot be modified.
By default, the Requested By fields are autopopulated with the details of the user who creates the change after the change request is submitted, if the user creating the change does not specify these details. If this user is not associated to a support group, the Support Company is set to the Location Company of the user. If this user is associated to a support group, the Support Company, Support Organization, and Support Group is set to the user's default Support Group.
You can modify the Requested By fields, if required. The Support Company field list is based on the user selected in the Last Namefield of the Requested By information.
- If the selected user does not belong to the support staff group all companies are listed similar to Change Location companies.
- If the selected user belongs to the support staff group this list is restricted to his Support Group companies.
From the Service field, select the business service configuration item (CI) that relates to the change request that you are creating. The Servicefield relates business service configuration items (CIs) to the change request at the time it is created. Business service CIs are related either to the customer directly or to the customer's company, organization, or department.
This field lists the CIs created under the Logical Entity > Business Service category. The business service CI is not a physical CI (such as a printer or a router); it is a logical CI. In this context, a logical CI is a business service that can be provided from one business, or organization within a business, to another. Service CIs can include customer support, employee provisioning, web farms, storage, and so on. When business service CIs are created and made available to the Service field menu, they are related either to a customer directly or to the customer's company, organization, or department. If you need to have a new business service CI added to the Service field menu, you must notify a system administrator with Asset Administrator privileges.
Selecting a business service CI automatically performs the following actions:
- Relates the business service CI to the change request as a Related to association type when the release is submitted. After it is established, you cannot remove the association created between the release request and the business service CI from the Relationships tab. However, you can select another service from the Service field when the change request is in Modify mode.
- Populates the Product Categorization of the change request based on the categorization of the business service CI. You can modify the Product Categorization values later.
(Optional but recommended) Select a template to complete part of the change request.
Change templates are especially useful in any change request that follows well-defined methods for specific and repeated requirements. Change templates can do more than prepopulate fields; they can also include CIs and tasks with the change request. BMC provides change templates for virtual machines that include standard tasks with the change request. For more information, see Selecting change templates.
The template is attached to the change request. The custom process flow associated with the change template applies to the change request. A new Work Info record is created that includes a textual representation of the change process flow. In the process flow bar, the options for next and back are changed to reflect the process flow.
If you start to enter fields in the change request and then select a change template, the change template overwrites any field values that are already present in the change request, including any relationships or tasks included with the change request.
- In the Initiate stage of the Process Flow Status bar, click the arrow and choose Next Stage.
The two tabs in the Change Initiation dialog box prompt you to enter required and optional information.
Enter the following information in the Required Information tab of the Change Initiation dialog box.
Briefly describe the change.
Specify the relative urgency of the change, so that the approvers can assess its magnitude.
You have the following options:
- Standard indicates a change (for example, a computer upgrade) that is typically preapproved and requires only approval by the change manager. Standard changes follow the out-of-box change process defined as per ITIL specifications. This configuration is not provided out of box.
- Emergency indicates a change that resolves an incident or problem deemed critical to business continuity and for which a workaround is not sufficient.
You must configure the Approval Process to follow for Emergency changes.
- Expedited indicates that a change has an enterprise-wide impact with an associated risk. If you select Expedited, you must also select the Timing Reason (for example, Known error correction).
You must configure the Approval Process to follow for Expedited changes.
- Latent indicates a change that has already been performed (for example, if a task implementer is assigned to replace the hard drive on a computer and then decides to upgrade the memory while the computer is open). Latent timing automatically sets the request status to Completed after you save the change request. The Target Date for a latent change can be earlier than the current date.
This out-of-the-box configuration of latent changes cannot be changed.
- Normal indicates a change that must follow the complete change management process. Normal changes are often categorized according to risk and impact to the organization (for example, minor change – low risk and impact, significant change – medium risk and impact, and major change – high risk and impact). By definition a normal change will proceed through all steps of the change management process and those that are categorized as medium or high risk will be reviewed by the Change Advisory Board (CAB).
The default value is Normal. Out of box a change follows this process.
- No Impact indicates a change that has no impact on the infrastructure and requires no approval.
By default, No Impact changes follow the Business Approval - No Impact phase and move to the Scheduled status. Use this process for preapproved no impact changes where the change is automatically scheduled after the approval phase is complete.
For more information on approval processes provided out of the box, see .
Reflects the extent to which the change affects the business.
The default value is 4-Minor/Localized. Impact is often directly related to the extent to which the service has degraded from agreed service levels. Impact can be measured by the number of people affected, the criticality of the system affected, and the loss of revenue as a result of the service degradation or disruption.
For detailed information about Impact, see Impact, urgency, and priority criteria.
Defines the importance the requester assigns to the change request and reflects how quickly a change must be implemented, or the time available to reduce the impact of the change on the business. The default value of the Urgency field is Low.
Use the following factors to determine Impact and Urgency:
- Number of customers affected by associated Incidents
- Duration and scope of the service disruption
- Availability of a solution or workaround
- The type of service being disrupted, usually based on the CI involved
- Awareness of the future impact on the business
For detailed information about Urgency, see Impact, urgency, and priority criteria.
Identifies the importance you (as support staff) assign to the change request.
Priority indicates the relative order in which to address the changes. It is influenced by considerations of risk and resource availability, but is primarily driven by the combination of Urgency and Impact. The default value of the Priority field is Low.\
For detailed information about Priority, see Impact, urgency, and priority criteria.
Defines the relative risk associated with the change, from 5 (highest risk) to 1 (lowest risk).
The default value is Risk Level 1. The Risk Level is used as a criterion to determine required approvals.
You can click the Risk Info icon to compute the risk level for the request. For more information, see Review and Authorize stage - Risk and impact analysis.
Defines the groups of people with the Change Coordinator functional role.
Note: If the user creating the change has the functional role of a Change Coordinator, the Coordinator Group, Change Coordinator, and Change location fields are auto filled with the user's details.
Defines the user responsible for the change. The list is populated with people with the Change Coordinator functional role and included in the Coordinator Group selected.
- The Change Coordinator field is found on the Assignment tab.
- When in the Search mode, the Change Coordinator field is populated with all users of the Coordinator Group selected, irrespective of their functional role.
Location of the company defined for the user requesting the change. Information for this field is related to the Requested By information provided for the change.
Note: The Change location details are found on the Assignment tab of the Change form.
Categorizes the request according to your organization's change type definitions. This value does not have any associated workflow.
- Project — Change requests that are part of larger scale changes, and usually consist of multiple change requests related to each other
- Change — A simple stand-alone change activity
- Release — Prior to the introduction of the Release Management module in BMC Change Management 7.5.00, this option was used to classify a change request as a release request. After a release request has been established, subsequent change records can be related as children or peer requests.
- Asset Configuration — Change request related to an asset configuration
- Asset Management — Change request related to managing an asset
- Asset Lease — Change request related to an asset lease
- Asset Maintenance — Change request related to maintenance of an asset
- Purchase Requisition — Change request related to a purchase requisition
Depending on which applications are installed, you might see other options.
Note: Asset type options only apply when BMC Asset Management is installed. It is used for integrations and workflow between BMC Asset Management and BMC Change Management applications.
Click the Optional Information tab, and then enter the following information.
Operational values are data-driven and are defined by the application administrator (for example, Tier 1 is Install, Tier 2 is Server, and Tier 3 is Hard Drive).
Product values are data-driven and are defined by the application administrator (for example, Tier 1 is Hardware, Tier 2 is Disk Device, and Tier 3 is Disk Array).
Product Name is data-driven and are defined by the application administrator (for example, Dell).
Model/Version is data-driven and are defined by the application administrator (for example, PowerEdge).
Manufacturer is the auto filled with the manufacturer defined for the selected Product.
Click Saveon the Change Initiation dialog box to generate the change request.
After you become familiar with Change Management functionality, you can bypass the Change Initiation dialog box and enter the required information directly into the Change form.
The Initiate Change dialog box automatically closes. You return to the New Change form, and the newly-created change is assigned to the appropriate group based on the predefined assignment routing.
If there was no appropriate assignment routing, you must manually assign the change request. For more information, see Working with change request assignments.
Most change requests must be approved before they move to the Review & Authorize stage. For more information, see Handling approvals for emergency change requests.
- Click Save.
By default, a new Work Info record is created that includes a textual representation of the default change process flow.