Phases of an advanced Change
The PMCHGMAIN1 workflow is provided to manage an advanced Change that includes all of the steps in the ITIL-aligned process. You can use the PMCHGMAIN1 workflow to manage a wide range of Changes, and you can also create workflows that support your specific business needs.
If you start the workflow when you create a Change, the workflow
that starts is the one that is specified as the pmchg.process.workflow
property in the System Configuration application. This product ships
with the PMCHGFIXD1 express workflow specified, but you can edit the
system property to configure your Change environment to use the PMCHGMAIN1
workflow. When you edit the system property to specify a workflow,
that workflow is linked to the workflow icon (
) in the Changes application toolbar. See "Specifying your
default workflow" for more information.
For guidelines for choosing the right default workflow for your business needs, see "Determining the right default workflow."
The following table summarizes the major phases of a full Change directed by the PMCHGMAIN1 workflow. If you modify the PMCHGMAIN1 workflow or use a custom workflow for a Change, your process steps might differ. In addition, depending on the type of a Change that you are processing, the workflow might skip steps that are not required for its Change type. For more information, see "Process variations based on Change type."
At various points in the process, the workflow notifies users of assignments that they need to fulfill in order for the process to proceed. These task assignments are shown in the Current Workflow Assignments dialog box, which is displayed in the Changes application. See "Current Workflow Assignments" for more information.
Each of the phases described in this table has its own information center section, where you can obtain more detailed information.
| Change phase | Description |
|---|---|
| Initiating a Change | A new Change can be initiated in either of two ways: by creating a Change work order directly in the New Change dialog, or by submitting a request for Change (RFC) through the Process Requests application. For both methods, initial values are supplied, such as an owner or owner group. A submitted RFC is displayed in the start center of a Change Owner, who can accept or reject the request. If a request is accepted, a Change work order is created in the Changes application, and the Change is displayed on lists of Changes that are in progress. The Change Owner can modify any of this information, add new information, or otherwise modify the Change. |
| Accepting and categorizing a Change | After you supply the necessary information for a new Change work order, the user can start the process workflow. The workflow examines your input, validates the supplied information, and calculates the preliminary impact, priority, and risk. Based on these calculations and other information, a response plan is automatically selected; the response plan supplies a job plan for the Change. The job plan determines the sequence of process steps that are needed for the Change. If any information is missing, the workflow prompts the user to supply it. After the workflow verifies that the Change is completely defined and ready for processing, IT managers verify that the Change conforms to your business policies. The assessment phase can then begin. |
| Assessing a Change | The workflow assigns assessment tasks to all
of the assessors and assessor groups that will perform technical and
business assessments. Assessors record their assessments, adding any
implementation notes that need to be considered for the Change. If
a standard Change is preauthorized prior to the assessment step, the
workflow skips the assessment, scheduling, and authorization phases. After the technical and business assessments are completed, the Change Owner or a Change Analyst analyzes the assessment results, creates any additional implementation tasks that are needed, and attaches one or more target CIs to each task. After all of the tasks are created and associated with target CIs, the workflow uses this updated information to recalculate CI impacts and the risk of the Change. |
| Scheduling a Change | The workflow kicks off the scheduling phase
by notifying the Change Owner that tasks are ready to be scheduled.
Scheduling occurs in the Graphical Scheduling application. The application
takes into account blackout periods, change windows, task owner shifts,
and so on, to schedule tasks. Changes can be scheduled automatically
using the critical path method (CPM). If the CPM cannot find workable
dates and times for the tasks, the tasks can be scheduled manually.
Additionally, the Change Owner is notified of any conflicts, such
as change window conflicts, blackout period conflicts, and so on.
Based on these conflicts, schedule approvers might be asked to approve
the schedule before this phase can be completed. An emergency Change has a shortened scheduling phase in which conflicts are calculated but ignored; no schedule approval assignments are sent. |
| Authorizing a Change | The workflow determines the authorization level that is required for the Change, based on its risk and other factors. All of the approvers and approver groups that are associated with the authorization are notified that their approvals are needed. If any approver votes not to approve, the Change owner can decide whether to resubmit the Change; resubmitted Changes return to the assessment phase. If the owner chooses not to resubmit, the Change is rejected and the workflow exits. |
| Implementing a Change | The work plan routes the implementation tasks
to task owners, in the correct order, by displaying assignments in
the Current Workflow Assignments dialog as the tasks need to be performed.
After the implementation tasks are completed, you can request that
CIs be updated. A Change results in modifications to configuration items (CIs), assets, locations, or some combination of these. You can specify the updates that will result from a Change at any time before the change is completed. You can update configuration item (CI) attributes, asset attributes, and location attributes. When the Change is completed, the attribute values of a CI in the configuration management database (CMDB) can be set to the values specified by the Change. |
| Reviewing and closing a Change | After the implementation tasks are completed,
the workflow sends an assignment to the Change Owner to confirm that
the Change was implemented. After obtaining reviews from key stakeholders,
the Change Owner indicates whether the result is satisfactory. If
it is, the Change is closed. If the result is not satisfactory, the
workflow initiates the creation of a process request, a Change work
order, or an incident so that outstanding issues can be resolved.
The Change Owner supplies review comments in the Log tab before closing
the Change. If a Change is of the standard type, the post-implementation review phase is skipped; the Change is closed after implementation completes. |