Creating a change request at the Initiate stage

1. 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, to identify the company for which you are creating the record, select the required value from the list, and then click Create. The Change form opens on the spoke server of the company that you chose. Continue with the rest of this procedure. The record that you create for the selected company is 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.
2. Use the following fields to specify the change coordinator:
   • Coordinator Group—Specify the group of people with the Infrastructure Change Coordinator functional role. This list is populated with the groups that have at least one user with an Infrastructure Change Coordinator functional role.

   • Change Coordinator—Specify the user responsible for the change. The list is populated with users that have the Change Coordinator or Change Manager functional role and who are included in the selected Coordinator Group. In Search mode, the Change Coordinator field is populated with all users of the selected coordinator group, irrespective of their functional role.

3. From the Service field, select the business service configuration item (CI) that relates to the change request that you are creating. 
   The Service field 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. When you select the Service CI, the Product Categorization values for the change request are populated with the matching Business Service CIs product categories.
   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, and storage. When business service CIs are created and made available on 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 Admin privileges.

4. (Optional) Select a change template to complete part of the change request. 
   Change templates are especially useful when you are creating any change request that follows well-defined methods for specific and repeated requirements. 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. For more information, see Applying a change template to an existing change request.
   

   Important

   If you select the change template after you start to enter the fields in the change request, 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.

   
   

5. (Optional) Enter a date in the Target Date field. 

6. The target date is the date by when the change must be completed, according to the applicable service level target. Alternatively, the target date can be a date that is agreed to on an ad hoc basis, for each change. The target date cannot be set to a date earlier than the current date, except for Latent changes. For detailed information about the dates related to a change request, see Tracking the time and effort for tasks.

7. Complete the following fields:

   Field name	Description
   Summary	Provide a brief description of the change.
   Class	Specify the relative urgency of the change, so that approvers can assess its magnitude. You can use the Class field to categorize a change based on the approval process. You can map each class to a different approval process, which drive the status transitions that can be defined according to the organization's requirement. You have the following options: Standard—Indicates a change that is typically pre-approved (for example, a computer upgrade) and only requires an approval by the change manager. The Standard changes follow the out-of-the-box change process defined as per ITIL specifications and a defined procedure with a well understood risk assessment. Normal—Indicates a change that must follow the complete change management process where risk assessment is typically based on many factors. Normal changes are often categorized according to the risk and impact to the organization. For example, minor change is low risk and impact, significant change is medium risk and impact, and major change is high risk and impact. Normal changes require some level of approvals to be carried out through the lifecycle of the change request. By definition, a normal change proceeds through all steps of the change management process, and those that are categorized as medium or high risk are reviewed by the Change Advisory Board (CAB). The default value is Normal. The out-of-the-box change follows this process. Emergency—Indicates a change that resolves an incident or problem deemed critical to business continuity and for which a workaround is not sufficient. These changes typically bypass the Normal change approval process and may have a process of their own. You must configure the approval process to follow Emergency changes. Expedited—Indicates a change that needs to be fast tracked, because there is some enterprise-wide impact and an associated risk. If you select this option, you must also select the Timing Reason (for example, Known error correction). You must configure the approval process for expedited changes. Just like normal changes, these changes also require some level of approvals to be carried out through the lifecycle of the change request. Latent—Indicates a change that has already been performed, but a request was not originally raised. For example, 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. Also, the Latent change requests are not displayed in the change calendar because the calendar does not display closed change requests. We recommend that you do not use Latent changes, but given the complexities and requirements of the business, sometimes, these types of changes are made. It is important to track these changes to determine a process for them to avoid the same change occurring in the future. 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 pre-approved no impact changes where the change is automatically scheduled after the approval phase is complete. For more information about the approval processes provided out of the box, see Approval processes provided out-of-the-box for Change Management. Best practice Although the change class is a required attribute, the Change Management application does not enforce the use of all these change classes. However, the Standard, Normal, and Emergency change classes are considered best practices and must be included in your implementation.
   Impact	Specify 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 to 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 for change requests.
   Urgency	Specify a value that indicates the importance of 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 the Impact and the Urgency: Number of customers affected by associated incidents Duration and scope of the service disruption Availability of a solution or workaround 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 for change requests.
   Priority	Specify your importance that you (as support staff) assign to the change request. This is set by the combination of the values that you have selected in the Impact and Urgency fields. 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 for change requests.
   Risk Level	The system automatically sets the risk assessment to Risk Level 1 (lowest level). However, we recommend that you answer all the risk related questions to allow the system to automatically set the risk assessment based on the answers provided. Important: The highest Risk level is Level 5. If the Risk level is set to 2 in the change request form, the value is stored as 1 in the system. Risk assessment involves computing the total risk based on risk-related questions and the derived risk factors. For more information, see Computing risk levels.

8. In the Initiate stage of the Process Flow Status bar, click the arrow and select Next Stage.
9. Review the information in the Change Initiation dialog box, and then click Save.

The newly created change is assigned to the appropriate group based on the predefined assignment routing. If there is no appropriate assignment routing, you are prompted to assign the change request manually.

Before you begin, ensure that Change Management is installed. You must have Change Master, Change User, or Change Submitter permission to create a change request by using email. 

The procedure in this topic provides only general information for creating a change request by using email. The email feature is configurable, so check with your system administrator for more information about  Configuring the Email Rule Engine and for the specific information that applies to your email environment. 

1. Open your email editor and create a new email message.
2. In the To field, enter the email account that is registered with the Email Engine to receive and generate application requests.
3. Complete the Subject field and the body text of the email according to the rules configured by your system administrator. 
   If global rules are used and no custom rules are defined, add CRQ: in the Subject field. Check with your system administrator for defined custom rules. 

4. If you have an attachment, add it to the email message.
   The system adds attachments to the application request's Work Information form. If you add multiple attachments, the system creates a zip file and adds it to the Work Information form.

   Important

   You cannot attach multiple attachments with the same file name.

5. Click Send.
   If BMC Helix Cognitive Automation is configured for your email system, a relevant template is applied to the change request. Also, if your email system is configured to send acknowledgments, you receive a confirmation message containing the change request ID. See the following figures with work notes: 
   
   This figure displays the template applied by Cognitive Service Management:
   
   
   In this figure, Cognitive Service Management could not find a relevant template:
   

You can use the BMC Atrium Impact Simulator application to proactively determine how a change to the availability of a CI affects other CIs and services. For example, you could run a simulation in BMC Atrium Impact Simulator to learn what devices and applications in the network would be affected if you were to take a server offline.

Using this tool provides many benefits for the change management staff:

• Generates "What if?" impact simulations to determine whether the change request will affect critical upstream business services. Using the Atrium Impact Simulator could potentially reduce the number of CAB meetings.
• Determines the approvers for the change request, based on the simulation result.
• Generates simulation reports for audit or compliance purposes.

You might also use BMC Atrium Impact Simulator to plan for disaster recovery. You can run simulations to determine where the network is weakest, and plan accordingly.

BMC Atrium Impact Simulator uses the impact relationships that you create between CIs. For information about creating relationships, see Defining and managing relationships.

When you run a simulation, you can specify an impact state for each CI in the simulation.

The following table lists the states that you can select in BMC Atrium Impact Simulator. 

When you run a simulation, BMC Atrium Impact Simulator uses these states and the impact relationships defined between CIs to predict the corresponding impact on those CIs. For example, a simulation that includes a server with an impact state of Unavailable might return several related CIs that are predicted to be unavailable as a result of the unavailable server. However, an Impaired server in that same simulation might return impacted CIs that are predicted to be only Slightly Impaired.

Priorities can help you understand the problems that you should address first if you were to make the changes that you simulated. For example, a simulation might reveal that if a server were to fail, email and payroll services might be disabled. The computed priority for these services would help you decide which service to restore first.

For more information, see  Simulating the impact of changes to CIs  in the BMC Helix CMDB documentation.

To perform an impact simulation for CIs and create a new change request related to this analysis using the Atrium Impact Simulator

1. On the Change Management console, select Functions > Atrium Impact Simulator. 
   The following figure illustrates the functional areas of the BMC Atrium Impact Simulator console.
   
   
   
   

   The following table describes what you can do in each of the functional areas:

   Functional area	Description
   CIs for Simulation
   CIs for Simulation table	Use this field to assign an impact state to the CI selected in the table. The left column of this table contains the Set CIs State for Simulation field.
   Add CI	Click to search for one or more CIs to add to the table.
   Remove CI	Click to remove the selected CI from the table.
   Simulate Impact	Click to run an impact simulation for the CIs in the table.
   Results
   Results in Topology	Displays the results of a simulation as a topology, including any impact relationships between the CIs. An icon on each CI image represents the predicted impact state for each CI, based on the simulation criteria.
   Results in Table	Displays the results of a simulation as a table. The Predicted Status column indicates the expected impact for each CI. To list only impacted service CIs, click Show Services. To list all impacted CIs, click Show All Results.
   Save Simulation	Save the simulation. Saved simulations can be loaded and compared.

   
   Here you choose the source CIs to include in a simulation. You can select one or several CIs, each with their own simulated impact state.

2. Click Add CI to search for and select CIs to add to the change request.
   1. In the Query window, run a query to return the CIs that you want to include in a simulation.
   2. In the results list, select one or more CIs to include in your simulation.
   3. In the CIs for Simulation section, select a CI, and then select an impact state in the Set CIs State for Simulation field.
   4. Repeat this step until every CI in the CIs for Simulation section has the impact state you want to simulate.
3. Click Simulate Impact to run an impact simulation for the CIs in the table. 
   You can view the results of the simulation on the Results in Table and Results in Topology tabs.
4. (Optional) You can filter the CIs by severity level or other options provided by the Atrium Impact Simulator.
5. To save the simulation, complete the following steps:
   1. Click Save Simulation.
   2. In the dialog box, enter a name for the simulation.
   3. Provide a description of the simulation, such as its purpose, and the source CIs used in the simulation.
   4. Click OK.
6. To create a new change request, select Relate to New > Change Request. 
   The Change form opens. The CIs from the Atrium Impact Simulator are related to the request in the Relationship tab. Work information is created for the change request, along with a simulation .csv file attached. 
   For more information, see Defining and managing relationships.
7. Enter the remaining information to create the request.
8. Click Save.