Using Change Management

This chapter provides an overviews of accessing and managing change requests and discusses how to:

• Access new and existing change requests.

• Manage basic change request information.

• Manage tasks.

• Manage notes.

• Manage related changes.

• Manage related actions.

• Manage interested parties.

• View change request history.

See Also

Setting Up Change Management

Understanding Change Request Access

This section discusses the five ways to access change requests:

• Through the HelpDesk menu.

  Simply navigate to HelpDesk, Create a Change Request or HelpDesk, Search Change Requests.

  Note. If you want to create a new change request, a blank Change Request page appears. If you want to search for existing change requests, the configured search page for Change Management appears.

• From the HelpDesk case.

  From the HelpDesk case object, the Actions section of the case allows the user the ability to directly create a new change request. Creating the request for change from the case creates a direct linkage between the change request and the case. The change request can be viewed from the case, and the case can then be viewed from the change request.

• From the Quality Management Defect.

  Using Related Actions functionality, a new Change Request can be created directly from the defect. Also, an existing change request can be identified and linked to the defect. Linking will cause the change request to be viewed from the defect, and the defect to be viewed from the change request.

• From the Worker 360-Degree View.

  PeopleSoft provides the ability to both add a new change request from the Employee view, and to view any requests already added by that employee.

• From Employee Self Service.

  You can add a change request from navigating to Employee Self Service, HelpDesk, Create a Change Request.

Understanding Change Request Management

This section discusses:

• Change Request Main page.

• Tasks page.

• Notes page.

• Related Changes page.

• Related Actions page.

• Interested Parties page.

Change Request Main Page

You can access the Change Request Main page by using any of the five available methods. There are six distinct sections on the Change Request page:

• Requestor Information section.

  The user must enter a change request Requestor. This person can be selected from any available employee record. Values for the requestor's Department, Location, Manager’s Name and Manager’s Telephone fields will default 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. Values for these fields are configured—you set these values up by navigating to Set Up CRM, Product Related, Change Management.

  See Setting Up Change Management.

• Product Information section.This section allows you to link a particular product to a change request.

  Users may not link impacted product groups, products and assets to a change request, but will automatically link any affected parties to the Change Request. Affected parties can be viewed by clicking on the ‘View Affected Parties’ icon, located in the Product grid.

  Users can link impacted Product Groups or Installed Products to the Change Request via the lookup options here. They can further refine the impacted product by linking the specific asset tag of the item affected. A 'View Affected Parties” icon will apear when the selected installed product has specific employees linked to it. Clicking on this icon will display all of the linked employees.

• Change Control section.

  This section can be used to record more specific information about the change request. The Impact, Category, Release and Resolution fields are informational only.

  The start dates and start and end times are not informational only—these duration fields are calculated fields. The 24/7 check box allows work to be scheduled beyond a normal Monday to Friday, 9 to 5 workweek.

  Values that are entered in the Schedule sub-section also serve as a guide for the phase and task start and end dates. All phase and task dates, whether built manually in the Phase Summary section on the main page, or auto-populated from the Phase Model setup option, will not be allowed to start prior to the start date indicated in the Schedule sub-section in the Change Control section. The End Date field will automatically default to the last date on the last task when the Phase/Task model was either build 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. Tasks and the phases they are associated with can be viewed from the Tasks tab. Each phase in the Phase Summary section consists of a task or set of tasks that need to be completed in order for change to be successful. Any required approvals should also be presented in the form of an approval task.

  See Task Page.

  Phases can be built manually in this grid. Alternatively, phases and tasks can be automatically populated if users load a phase template.

  See Setting Up Phase Templates.

  Any template can be loaded by choosing the appropriate template name in the Templatedrop down and clicking the Load button.

  If users click the Load button without first selecting a phase template from the Templatedrop down list box, all phase templates whose Type, Sub-Type and/or Priority fields that match the Type, Sub-Type and Priority fields of the change request, will appear. Users then select the desired phase template, thus populating the phases in the Phase Summary grid and tasks on the Task page. Phases can be manually built by clicking on the “Add Phase”.

• Audit History section.

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

Note. Upon opening the Change Request Main page, the Change Control, Phase Summary and Audit History sections will be collapsed by default.

See Accessing Change Requests.

Task Page

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

The Task Management application 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 auto added using the Phase Model or added manually.

See Also

Managing Tasks

Notes Page

Notes pages will follow the standard Notes and Attachments format that us used throughout CRM Enterprise 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. In order to identify these common documents within a specific note, PeopleSoft provides a Note Type field.

Before adding an attachment to the note , the note type can be identified via the drop down. Values in the Note Type drop down list box are user configurable.

See Also

Working with Notes and Attachments

Related Changes Page

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

Status updates cascade. 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 other Change Requests automatically. Cascading changes occur when a user manually changes the status, or an AAF rule executes unattended.

There are several conditions that must exist for cascading status changes to happen. First, the Change Request whose status is being changed must be related to another Change Request. Two characteristics define each relationship, a) the type and b) the hierarchical indication.

When Type is Global, and the hierarchy indicator is a parent of the change request whose status is changing, then a cascading status situation occurs. Further, if the status change is to a final type status (such as Closed, Completed, and Rejected) then any related Change Request with these two characteristics are displayed and offered to the user to allow the status to cascaded. This is for on-line manual status changes.

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

Related Actions Page

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 HelpDesk Case, those defects and cases can be linked directly to the Change Request.

Linking a defect or case to a change request allows the user to drill into these other objects directly from Change. It alos causes the change to be linked to the defect or case, and provide the ability to drill into the Change Request from either HelpDesk or Quality Management.

Conversely, change requests can be created and linked to defects from the Quality Management application and to Cases from HelpDesk. Linking from either of these two applications will also create the linkage in the Change application.

Linking cases and defects also causes status updates to be forwarded to the HelpDesk agent or the quality analyst. The type and frequency of the updates can be determined and configured using AAF.

You will not be able to create either a case or a defect from the Change Management application. Similarly, there is no cascading status functionality between cases, defects, and change requests.

Interested Parties Page

Interested parties— individuals not part of the change process via an assigned task or role—can receive notifications and updates on the Change status by inclusion on the Interested Parties page. Interested parties can be designated to receive updates only on specific phases, or on all phases.

Interested parties are limited to employees. The type and frequency of the updates can be determined and configured using AAF.

History Page

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

Whenever a change is processed on a change request, it is audited and displayed on the History Audit page. The records to be audited are configurable in CRM Set Up. History interactions displays when email was used to notify an assigned worker of a task action or status change.

Accessing Change Requests

This section discusses how to add new change requests and access existing change requests:

Pages Used to Access Change Requests

Accessing Existing Change Requests

Access the Change Request Search page.

Note. The Search Criteria section is collapsed by default.

General Information on Change Request Searches

When searching for an existing change requests, you can search based on change request fields. Values for the change request fields are defined by your organization and are based on the business unit that you enter.

All search criteria fields correspond to fields on the Change Request page. However, on the Change Request page, you must enter valid values, whereas on the Change Request Search page, you can enter part of the whole value in most fields (depending on what operators are set for a given search field).

There are a few exceptions:

• You must enter a complete value in these fields: Change RequestID andBusiness Unit.

• You can enter partial values in the Requester ID and Change Control ID fields, but only after you click the lookup button associated with the field. The system displays the appropriate lookup page, where you can search for and select a customer or contact before attempting the search again.

Basic Versus Advanced Searches

Users can perform Boolean searches using field-level search criteria. The system administrator defines the operators that appear on the Configurable Search Setup page. Users can further refine the list of operators for each field if they are granted permission to personalize their search settings.

The system displays a list of the searchable fields. For each field, you can enter a search operator and the search text.

This table lists the search operators that are available for field-level searching. The operators that appear depend on whether the field being searched is a string or a number.

Note. PeopleSoft does not deliver the contains operator because it may cause performance problems. To add it to the list of available operators, use the Configurable Search Setup page.

See Configuring Search Pages.

Searches

Depending on how your implementation team configures the search pages for your system, you may not be able to view all of these fields.

Note. In Change Management, the Basic and Advanced Searches are identical. If the field that you are looking for does not appear, click the Personalize Search link. The system displays the Personalize Search Settings page (if the system administrator has made this page available to you). You can use this page to select additional fields to display on the search page. If you still do not see the field that you are looking for, contact your system administrator.

Search Criteria Fields for PeopleSoft Change Management

Note. Remember that you can enter part of the whole value in most fields—depending on what operators are set for a given search field. Most of these values are also user defined; they are based on the needs of your organization.

Search Commands

Search Strategies

Here are some search tips:

• You can enter partial values in any field except Change Request ID and Business Unit.

  For example, if you select begins with as the operator and then enter Smi in the Name field, the search results include a list of all people whose last names start with Smi.

• You can enter the least amount of data that is needed to limit the search results.

  Entering extra information is time-consuming and increases the likelihood of a typographical error that prevents the system from finding any information.

• A change request ID uniquely identifies a change request; searching for existing change requests by change request ID displays the desired Change Request page (this involves the fewest keystrokes).

• The search is not case-sensitive.

See Also

Defining Change Management Preferences

Managing Basic Change Request Information

This section discusses how to:

• Manage basic change request information.

• Manage tasks.

Page Used to Manage Basic Change Request Information

Managing Tasks

This section discusses how to manage tasks.

Pages Used to Manage Tasks in Change Management

Managing Tasks in Change Management

Access the Tasks page.

Managing Notes

This section describes how to utilize notes in Change Management.

Pages Used to Manage Notes in Change Management

Managing Notes in Change Management

Access the Notes page:

Managing Related Changes

This section discusses how to manage related changes.

Pages Used to Manage Related Changes in Change Management

Managing Related Changes in Change Management

Access the Related Changes page:

Managing Related Actions

This section describes the Related Actions page.

Pages Used to Manage Related Actions in Change Management

Managing Related Actions in Change Management

Access the Related Actions page:

Managing Interested Parties

This section discusses how to manage interested parties for a case.

Pages Used to Manage Interested Parties in Change Management

Managing Interested Parties in Change Management

Access the Interested Parties page.

Reviewing Change Request History

This section provides an overview of change request history and explains how to:

• View the event history of a change request.

• View the audit trail for a change request.

Understanding Change Request History

The Change Request History page includes an Events subpage and an Audit subpage:

• Change request history provides a summary of the major events in the lifecycle of a change request.

• Change request auditing complements change request history processing by providing an automated mechanism for keeping a detailed change history without cluttering up the Change Request History page.

Some overlap is acceptable in the data that these pages capture.

Change Request History Page

This page displays information about major events in the life of the change request, including a description of the event and details of any field changes that are associated with the event. The following mechanisms insert data into the change request history table:

• Change request history Active Analytics Framework.

  At save time, the system evaluates record- and field-level conditions that you define. When the condition is true, the system adds a row of change request history data.

• Workflow Active Analytics Framework (including service-level workflow).

  The system triggers a workflow action under conditions that you define. The event processing definition includes a check box that you select if you want to create change request history when the workflow is triggered.

• Manual notifications.

  The system adds change request history whenever a user sends a manual notification from the change request.

  See Sending Manual Notifications.

Audit History Page

This page displays record-level changes to change request data. Your organization chooses which fields in the record to audit and the types of changes to capture (adding, updating, displaying, or deleting). However, there is no conditional logic to evaluate the before and after values of the field; the system captures all audited actions regardless of the field value.

See Also

Setting Up Auditing for Cases and Inbound Email

Working with Active Analytics Framework

Working with Interactions

Prerequisite

Your organization must define event sets that tell the system which events to capture in the change request history.

See Configuring Case History Actions.

Pages Used to Review Change Request History

See Also

Setting Up Auditing for Cases and Inbound Email

Configuring Case History Actions

Viewing the Event History of a Change Request

Access the change request History page.

Audit	Click to display the Audit History page.
Events button	If the entry was created by change history Active Analytics Framework, click the Events button to view details about the event. When you click this button, the system displays the appropriate page as determined by the event processing rules. For example, if the event is the addition of a new note, clicking the button displays the Notes and Attachments page. When the history item is from a notification, clicking the button takes you to that notification. This button does not appear for entries that were created through a mechanism other than case history Active Analytics Framework.
Date	The date that this action occurred.
Action Taken	The system populates this field with the description of the action from the Event Definition page.
Details	Describes the details of the action that was taken. For example, if a note was added, the system shows the first 30 characters (configurable). Or, if an agent adds an attachment to the change request, the system shows the name of the attachment. If a field value changes, the system could display the values before and after the change in the Details column. You must, however, use the History Event Handler page to configure both the field value changes and the information that appears in the Details column. To configure other events that you want to show up on the Change Request History page, use the History Event Handler page.
Visibility	The system displays either All or Internal to indicate who can view the details of the event.

Viewing the Audit Trail for a Change Request

Access the Change Management History page. Click the Audit link.

Your organization chooses which fields in the record to audit and the types of changes to capture (adding, updating, displaying, or deleting). However, there is no conditional logic to evaluate the before and after values of the field; the system captures all audited actions regardless of the field value.