Creating a Change

Before you begin to create Changes in your data center, it is recommended that you review the Planning for Changes section of the information center. This section introduces workflows, response plans, and job plans, and describes how these aids make processing Changes easier and more efficient. Your administrator will have consulted the Planning section to set up response plans, workflows, and job plans that can be used for your Changes.

In addition, it is recommended that you review the "Change process overview" topics, along with the topics in the Process overview section that describe the Change types, the automatic selection of Change type, and fully automated Changes. When you create a Change, the workflow performs a number of calculations based on values that you have specified in the Change for risk, priority, impact, urgency, and probability of failure. The Process overview section describes these calculations.

After the workflow makes its calculations, a response plan is found that has conditions that match the Change values. The response plan locates the appropriate job plan for the change, and the job plan brings in a Change type that is used to determine the process steps that are followed. For more information, see "Process variations based on type."

The date and time at which you opened a new Change are displayed in the Reported Date field. After you save the new Change, its status is WAPPR.

Following is a set of guidelines for creating a Change. As these guidelines show, the interactions among the workflow, the response plan (if one is used), the job plan (if one is used), and your own specifications determine how the Change takes shape and how it will be processed.

Some of the information categories described in this topic do not apply if you are creating an express Change.

Opening a new Change

Note: This information assumes that the New Change dialog window is enabled in your Changes application. Your administrator might have disabled this dialog, or it might be disabled by default. If it is disabled, the dialog does not open, and you do not enter information there. Instead, enter all of the information for the Change in the Change tab.

To get started with the new Change, open the Changes application (Go To > Change > Changes), and click New Change. The New Change dialog opens, with a number automatically assigned; you can type a new number. Complete the following fields in the New Change window, and click Submit Now to create the new Change record. If you do not want to specify any of this information now, you can simply click Submit Now, and then supply the information on the Change tab.

Summary

Type a brief description of the Change. Make the summary as clear as possible, so that other users can obtain needed information about the Change. You can click the Long Description icon () beside the Summary field to enter more detailed information about the Change.

Details

Enter any additional details that you want to supply for the Change in this field.

Note: If you tab from the Summary to the Details field, you must press the Tab key twice to position the cursor in the Details field.

Change type

The Change type indicates the Change process steps that are needed. The built-in Change types include Normal, Standard, and Emergency. Each type uses a variation of the Change process steps. For example, in an advanced Change directed by the PMCHGMAIN1 workflow, the job plan that is applied brings in a type to match the requirements of the Change; if you have specified a different type, your specification is overwritten with the type that is associated with the job plan.

Take ownership?

Check this box if you want to take ownership of this Change. If you leave the box unchecked, you can supply a different owner or owner group later.

Start Change process workflow?

Check this box to start the workflow now. You can choose to start it later. The workflow that starts is the workflow that is specified as the pmchg.process.workflow property in the System Configuration application. This product ships with the PMCHGFIXD1 (express Change) workflow specified by default.

After you specify the information that you want to supply in this window and click OK, the new Change record is saved, and the Change is displayed in the Change tab. You can supply additional information for the Change at this time, or you can return to the Change and supply the information later.

Supplying Change information

After you open and summarize the new Change, you specify information that defines the overall purpose and scope of the Change.

The fields that are provided for defining the Change are labeled to indicate the information that you supply. For example, primary target CIs are entered in the Primary Targets section; specify additional targets in the Additional Targets section.

Not all fields in the new Change record are required; however, it is a good idea to provide as much detail as you can regarding the nature and need for the Change. You can open field-level help for each field to get a description of the field. To view field-level help, position your cursor in the field, and press Alt-i.

The items below provide guidelines for some of the key fields.

Recording the reason for the Change

In the Reason for Change field, you can record the positive benefits of implementing the Change. This information helps the Change assessors as they evaluate the projected outcomes that are expected to arise from the Change.

Recording the effect of not implementing the Change

In the Effect of Not Implementing field, you can record the business, technical, and financial effects of not implementing this Change. This information helps the Change assessors determine the consequences that the business might experience if the Change is not processed.

Specifying risk

The risk of a Change is an estimation of its potential to cause disruptive outages across the data center. A high-risk Change is one that is not performed often, involves many business-critical CIs, or is more likely to fail. A risk of 1 indicates a very critical risk; 4 indicates a relatively low risk. You can supply your estimate of the risk in the Risk field; if you are using the PMCHGMAIN1 workflow, the workflow will calculate risk.

Note: For information about how the workflow uses risk, failure probability, urgency, priority, and impact values to perform its calculations, see "Automatic selection of Change type" in the Change process overview section.

Specifying a failure probability

The failure probability reflects the likelihood that the Change will not be successful. Changes that are performed only occasionally might have a higher failure probability, because they cannot be predicted with accuracy. A high probability of failure might also indicate that the Change involves extremely business-critical CIs whose outages are not well understood. Failure probability ranges from 1 to 3. Job plans have associated failure probabilities; a value that is brought in by a job plan overwrites the previously supplied value if the failure probability is more likely than what was manually provided.

Specifying urgency, priority, and impact

In order to effectively assess the risk of implementing or rejecting a Change, assessors need an initial idea of the impact, urgency, and priority of the Change. You specify these values in the Impact, Urgency, and Priority fields.

In the Impact field, specify a number from 1 to 5 to indicate your estimate of the scope of possible disruption during Change implementation. This specification enables Change Owners to balance the need for a Change with its expected impact. A value of 1 specifies the most critical impact; 5 indicates the lowest impact.

You also specify a number from 1 to 5 in the Urgency field, which indicates your estimate of the current necessity for this Change. The urgency is based on how long the implementation can afford to be delayed. A value of 1 specifies the highest urgency; 5 indicates the lowest urgency.

Type a value in the Priority field to indicate the priority of the Change. Use a numeric value that you have established an a priority indicator. For example, you might want to type 1 to indicate the highest priority, 4 to indicate the lowest priority. The priority of a Change is derived from the agreed impact and urgency.

Specifying a category

The Change category is a rough sizing that indicates the amount of effort that you expect to be involved for this Change. You specify the category in the Change Category field. Select the value from the drop-down menu that most closely matches your estimates: Minor, for a relatively insignificant Change, Significant, for a Change that requires a sizable effort, and Major, for a highly intensive Change. For example, a category of Major might indicate that the Change will involve a large group of users and have a substantial impact across the data center.

Specifying a type

The Change type indicates the Change process steps that are needed. You can specify a type when you create the Change in the New Change window, or you can do so on the Changes tab. If you choose to specify the type in the Changes tab, in the Change Type field, select the value from the drop-down menu that most closely matches your estimates. The built-in Change types include Normal, Standard, and Emergency. Each type uses a variation of the Change process steps. In a PMCHGMAIN1 workflow-directed Change, the job plan that is applied brings in a type to match the requirements of the Change; if you have specified a different type, your specification is overwritten with the type that is associated with the job plan. For more information about the three Change types and the process that is followed for each, see "Process variations based on Change type."

Specifying a classification

The classification narrows or defines the overall nature or scope of the change, such as hardware, software, network, operating system, database, and so on. The classification is an important identifier.

When you specify a classification, you can select PMCHGHDW if the change involves hardware, or PMCHGSFW for general software changes. For more specific hardware or software changes that have classifications defined, you can select a classification that is nested under PMCHGHDW or PMCHGSFW, such as PMCHGWDW/DSKTOPS (desktops) or PMCHGSWF_MWINSTALL (middleware installation).

After you select a classification in the Classification field, any extended classification attributes are displayed in the Specifications section, where you can fill in attribute values for auditing, planning, and implementation purposes. Classification attributes capture information that is specific to the classification. For example, an "add memory" classification could have a "memory size" attribute.

Note: By default, the Specifications section is displayed only if the specified classification has extended attributes. However, your administrator might have configured the Changes application to display the Specifications section whether or not there are extended attributes.

If you specify a customer before setting the classification, you are presented with only those classifications that are valid for this customer. These classifications are global (not associated with any customer) or specifically associated with this customer or the parent of this customer. Classification attributes that are brought into the Specifications section are also either global or specifically associated with the customer or parent of the customer.

Specifying source and target CIs

For Changes that involve both a source CI and one or more target CIs, you specify both of these values. Typically, a source CI is a software image that will be installed on the target CIs during the Change implementation. A target CI is one that will be affected by the Change. You can launch from the source and target CI fields to the Configuration Items application and inspect CI topology views; if you select a CI in the topology, you can return to the Changes application with the selected CI in the field. You can also select a CI from a list of available CIs.

For more information about navigating the CI topology view and selecting a CI there, see the related topic "Navigating the CI topology."

Assigning an owner or owner group

If you did not take ownership of the Change in the Create a New Change Request window, you must assign ownership to another owner or owner group. For an advanced Change, if a response plan is applied to the Change, the response plan might bring in an owner or owner group. Otherwise, you manually assign an owner or owner group to the Change. Do so in any of these ways:

• In the toolbar, click and select an owner or owner group in the Select Owner dialog.
• To take ownership of the Change yourself, click in the toolbar.
• Select the Select Owner action, and select an owner or owner group in the Select Owner dialog.

Applying a response plan

A response plan is typically used to bring a job plan into a Change. Depending on how the response plan is set up, it might also supply an owner or an owner group, or other information that is defined for the response plan.

You can apply a response plan in either of two ways:

• Select the Apply Response Plan action after specifying a few initial values for the Change. The most appropriate response plan is selected and applied.
• Click to route the Change to the PMCHGMAIN1 workflow, or click to select from a list of all of the active workflows to which you can route the Change, including the built-in workflows and any custom workflows that you have created.

After you route the change to a workflow, the most appropriate response plan for this Change is located, based on the values in the Change and the conditions that are set on the Change response plans. This occurs by default if you use the PMCHGMAIN1 workflow; if you use a custom workflow, you must have included the Apply Response Plan action in that workflow.

If a customer is specified for the Change, a response plan that is associated with that customer is selected, if one exists. If no response plan is associated with the customer, a response plan that does not have a customer association (a global response plan) is selected.

Applying a job plan

A response plan can apply a job plan to the Change, or you can manually select a job plan by opening the Schedule tab and specifying a job plan in the Job Plan field. If you manually supply a job plan, and then apply a response plan, the response plan does not overwrite the job plan that you have manually supplied. After a job plan is brought into the Change, either manually or through the response plan, you can open the Schedule tab to view the tasks that the job plan has brought in. Open the Assessments and Approvals tabs to view the assessors and approvers, respectively, that are brought in by the job plan.

After a job plan is applied to a Change, you can replace the job plan if no task has been put in the INPRG status, and the Change is also not INPRG. To remove the job plan, select the Remove Work Plan action, and specify a different job plan in the Job Plan field.

Note: In the Schedule tab, if you click Add Task in the Tasks for Change section, the Job Plan field grays out, and you are unable to select a job plan. This occurs because you cannot select a job plan after you manually create one or more implementation tasks. If you click Add Task in error and want the Job Plan field to be selectable, you can save the Change, delete the task row, and save the Change again. The Job Plan field will then be selectable again.

Adding assessors and approvers

You can open the Assessments tab to add assessors or assessor groups that were not brought in from the job plan. Open the Approvals tab to specify additional approvers or approver groups for the authorization phase; you can also add schedule approvers in the Schedule Approvers section.

The Schedule Approvers table contains a column headed Conflict Approver. When you initially add schedule approvers, the check boxes in this column are not checked. During the scheduling phase, if schedule conflicts are detected, the workflow adds schedule approvers based on the detected conflicts; the Conflict Approver box is checked to indicate that an approver was added because of a conflict. Conflict approvers are cleared from the table when the schedule is updated and the conflicts recalculated.

The assessors and approvers that you specify are people or person groups that you have defined in the People application.

Using the workflow

When you open a new Change, you can check Start Change process workflow? in the Create a New Change Request window; this starts the workflow. At any time thereafter, you can click to route the Change to the workflow that is associated with your Change environment, or click to select from a list of active workflows, including the built-in workflows and any custom workflows that you have created. Initially, if the workflow contains the "Apply response plan" action, it can apply a response plan if one exists and you have not applied it manually.

After you route the Change to a workflow, the workflow icon changes to indicate that it is in progress. The icon changes to . The icon changes to .

While the workflow is in action during the Change process, owners of workflow assignments are notified when an assignment is ready to be completed. An assignment owner can click the assignment description in his or her inbox to go to the Change record and perform the assignment. To indicate that the assignment is completed, the owner can click in the inbox; or, in the Change, or .

The workflow displays messages about any problems that it encounters, assignments that must be completed at this time, and so on. The workflow icons revert to their original appearance after the workflow has ended for the Change.