Understanding Change Request Management

You can access the main Change Request page by using any of the five available methods. After the page appears, you can see the six distinct sections on the Change Request page:

• Requestor Information section.

  The user must enter a change request requester. The agent can select a person from any available employee record. The system provides the default values for the requester's department, location, manager’s name, and manager’s telephone fields from the employee record that was selected.

• Change Request section.

  In this section, you record information about the nature of the change request. The Summary, Business Unit, Request Type, Status, and Priority fields are required to save the change request. The other fields are informational only. You configure values for these fields. You set up these values by navigating to select Set Up CRM, then select Product Related, then select Change Management.

  See Understanding Change Request Management.

• Product Information section.

  This section enables you to link a particular product to a change request.

  Users can link affected product groups or installed products to the change request using the Lookup button. They can refine the affected product further by linking the specific asset tag of the item affected. The View Affected Parties link appears when the selected installed product has specific employees linked to it. Clicking this button results in the appearance of all of the linked employees.

• Change Control section.

  This section is used to record more specific information about the change request. The Impact, Category, Release #, Resolution, and Requested By Date fields are informational only.

  The start dates and start and end times are not only informational; the system uses these fields to calculate duration. The 24/7 check box enables work to be scheduled beyond a normal Monday to Friday, 9 to 5 work week.

  The system uses the values entered in the Schedule subsection as a guide for the phase and for the task start and end dates. All phase and task dates, whether built manually in the Phase Summary section on the main Change Request page or populated automatically from the Phase Model setup option, are not allowed to start before the start date indicated in the Schedule subsection in the Change Control section. The system provides the value in the End Date field by default. It is the last date on the last task when the phase model or task model was either built or automatically loaded.

• Phase Summary section.

  Use this section to manage the phases and tasks that are associated to a change request. Only phases are displayed in this grid. You can view associated tasks and phases on the Tasks page. Each phase in the Phase Summary section consists of a task or set of tasks that need to be completed in order for a change to be successful. Any required approvals should be presented in the form of an approval task.

  See Tasks Page.

  You can build phases manually in this grid. Alternatively, you can have the system automatically populate phases and tasks by selecting a template and clicking the Load button.

  See Setting Up Phase Templates.

  You can load any template by choosing the appropriate template name and clicking the Load button.

  If users click the Load button without first selecting a phase template, all phase templates whose type, subtype, or priority fields match the type, subtype, and priority fields of the change request appear. Users then select the desired phase template, thus populating the phases in the Phase Summary grid and tasks on the Task page. You can manually build phases by clicking the Add Phase button.

• Audit History section.

  This section tracks the dates and times that the change request was created and modified.

See Accessing Change Requests.

Notes pages follow the standard Notes and Attachments format that is used throughout the PeopleSoft CRM application suite. During the course of a change cycle, specific types of documentation may be required, such as backout plans, design documents, or a cost benefit analysis.

To identify these common documents within a specific note, PeopleSoft Change Management provides a Note Type field. Before adding an attachment to the note, you can identify the note type from the drop-down list box. The user configures the values in this field.

The Tasks page displays all tasks, process flow steps, and decision points that are associated with a Change Request. PeopleSoft Change Management carries the task ID link to point to the Task Management application for the actual definition of the task.

Task Management tracks each task associated with a change request. Change Management uses Task Management functions for task groups to further define and control the process flow of a change request.

Tasks can be added, deleted, and edited from this page. They can be added automatically using the phase model or added manually.

AAF events control the process flow of a change request. Whenever an event is processed on a change request, it is audited and then appears on the History Events page.

Whenever a change is processed on a change request, it is audited and then appears on the History Audit page. The records to be audited are configurable when you set up your PeopleSoft CRM applications. History interactions appear when email is used to notify an assigned worker of a task action or status change.

The Related Changes page provides the ability to link similar change requests in either a parent/child or an equal relationship.

A status change is referred to as cascading when a status change on one change request causes the same status change on one or more change requests automatically. Cascading changes occur when a user manually changes the status or when an AAF rule executes unattended.

Several conditions must exist for cascading status changes to occur. First, the change request whose status is being changed must be related to another change request. Two characteristics define each relationship:

• Type

• Hierarchical indication

When the type is Global and the hierarchy indicator is a parent of the change request whose status is changing, then a cascading status occurs. If the status change is to a final type status (such as Closed, Completed, or Rejected) then the system displays a related change request with the two characteristics. These changes apply to online manual status changes.

For AAF rule execution status changes, the status is cascaded automatically when the Changed To status is marked as a cascading type status (see Status setup for this indicator).

See Understanding AAF.

PeopleSoft Change Management also provides the ability to link cases and defects to a change. If a change request was initiated by defect identification or from a help desk case, you can link those defects and cases directly to the change request.

Linking a defect or case to a change request enables the user to drill down into these other objects directly from PeopleSoft Change Management. It also causes the change to be linked to the defect or case, and provides the ability to drill down into the Change Request from either PeopleSoft HelpDesk or PeopleSoft Quality Management.

Conversely, you can create and link change requests to defects from PeopleSoft Quality Management and to cases from PeopleSoft HelpDesk. Linking from either of these two applications also creates the linkage in PeopleSoft Change Management.

Linking cases and defects also causes status updates to be forwarded to the help desk agent or the quality analyst. You can determine and configure the type and frequency of the updates using AAF policies.

You will not be able to create either a case or a defect from PeopleSoft Change Management. Similarly, no cascading status functionality exists among cases, defects, and change requests.

Interested parties, such as individuals who are not part of the change process by way of an assigned task or role, can receive notifications and updates about the change status through their inclusion on the Interested Parties page.

Users can designate interested parties to receive updates for only specific phases or for all phases.

Interested parties are limited to employees. You can determine and configure the type and frequency of the updates using AAF policies.