Content for service request management
This section describes the extended function that is included in the best practices content for the Service Requests application.
Predefined user names
Each security group included in the best practices content is provided with a predefined user name and password. The user name is the same as the group name with USR appended. For example, PMUSRADMUSR is the predefined user name for the PMUSRADM security group. Each user is created with a password that is set/chosen by the Maximo or Websphere Administrator. If LDAP based authentication is used (refer to: LDAP authentication), then the password is set to the WebSphere Administrator password. If Non-LDAP based authentication is used (refer to: Non LDAP authentication), then the password is set to the Maximo Administrator password. (See the following section for a full listing of the security groups that are provided.)
The PMUSRADMUSR user occupies the role of User Contact Administrator. The User Contact Administrator can create additional users for any security group.
Security groups and start centers
The best practices content package includes security groups for each of the User Contact Service Desk roles defined in the IBM® Tivoli® Unified Process (ITUP). Besides the ITUP user roles, the package includes a User Contact Administrator security group (named PMUSRADM) that is authorized to access all applications.
The following table lists the security groups for service request management. A start center is generated for each group.
| Security group name | Description | Start center template |
|---|---|---|
| PMUSRADM | User Contact Administrator group. These users have rights to every action and every application. | PMUSRADM |
| PMUSRMGR | User Contact Manager group. These users are responsible for the quality and integrity of the user contact management process. They interface with other process managers. | PMUSRMGR |
| PMUSRANAL | User Contact Analyst group. These users are the primary contact for customers, functioning as a hub between the customer organization and the IT organization. The User Contact Analyst typically creates incident tickets and coordinates their resolution. | PMUSRANAL |
Queries
The following table shows the queries that have been added for service request management. These queries provide quick access to information about current and historical service requests.
See Record Statuses for definitions of the statuses referred to in this table (new, queued, in progress, pending, resolved, and closed). An open service request is defined as a service request in any status except RESOLVED or CLOSED.
| Clause name | Query description |
|---|---|
| PMSROPEN | All open service requests |
| PMSRMYOPEN | My open service requests |
| PMSRLATE | All open service requests that are late or at
risk of being late.
Note that a target finish date is not required. A service request with no target finish date is not considered late or at risk of being late because the expected completion date is unknown. |
| PMSRMYLATE | My open service requests that are late or at
risk of being late. See the PMSRLATE query description for definitions of late and at risk of being late. |
| PMSRREPURG | All open service requests with Urgent Reported Priority |
| PMSRINTURG | All open service requests with Urgent Internal Priority |
Key Performance Indicators
The following table shows the Key Performance Indicators (KPIs) that have been added for user contact management.
| KPI name | KPI description |
|---|---|
| PMSRLATEWO | Number of late work orders or work orders at
risk of being late from all open service requests. See the PMSRLATE query description for definitions of late and at risk of being late. |
| PMSRAVGTI | Average process time per service request in hours |
| PMSROPEN | Service requests that are currently in progress |
| PMSRWAPP | Open service requests that have work orders that are waiting for approval |
| PMSRURG | Open service requests marked Urgent Priority (internally) |
| PMSRHIGH | Open service requests marked High Priority (internally) |
Communication templates and escalations
The best practices content includes predefined communication templates that the service desk analyst can use to send a communication to other users. Communications that use predefined templates are automatically sent to the Reported By and Affected Person users shown on the service request record when certain conditions occur, such as a change in the status of the service request.
The following table lists the predefined communication templates provided for the Service Requests application. Each template is identified by a template name and title. The names and titles of the predefined communication templates are displayed in the list of available templates when a service desk analyst manually creates a communication using a template.
If a template is used in an automatic communication, the Automatic Notification column describes the condition under which the notification is sent. The Escalation column lists the predefined escalation that triggers the notification. The predefined escalations are run once a day. An administrator can make changes to the automatic notification behavior provided with the product by modifying or removing the associated escalations. For example, the ESCSRCLS10 escalation, which triggers a notification 10 days after a service request is resolved, can be re-configured to a different number of days.
The predefined templates that are used in automatic notifications include the primary email addresses of the Reported By and Affected Person users in the To: field of the template. When manually creating a communication using one of these templates, the service desk analyst can change these addresses to specify a different recipient or recipients.
| Template name | Template title | Template description | Automatic notification | Escalation |
|---|---|---|---|---|
| CTSRNEW | Service request has been created | Notifies the recipients that a service request record has been created. The e-mail message includes the current status of the service request and the internal priority. | This communication is automatically sent to the Reported By and Affected Person users within one day after a service request is opened. | ESCSRNEW |
| CTSRRES | Service request is resolved | Notifies the recipients that the service request has been resolved. The e-mail message includes the reported date of the service request, classification, and description. | This communication is automatically sent to the Reported By and Affected Person users within one day after the service request status changes to RESOLVED. | ESCSRRES |
| CTSRCLS | Service request is closed | Notifies the recipients that the service request has been closed. The e-mail message includes the reported date of the service request, classification, and description. | This communication is automatically sent to the Reported By and Affected Person users within one day after the service request status changes to CLOSED. | ESCSRCLS |
| CTSRCLS10 | Service request is closed | This template is the same as the CTSRCLS template, but the conditions for automatic notification are different. | After a service request has been in RESOLVED
status for 10 or more days, the service request is automatically changed
to CLOSED status and this communication is sent to the Reported By
and Affected Person users within one day after the service request
is closed. The ESCSRCLS and ESCSRCLS10 escalations are coordinated so that only one notification is sent in case of a conflict. |
ESCSRCLS10 |
| CTSRASN | Service request is assigned | Notifies all members of an owner group that a new service request has been assigned to the group and encourages anyone in the group to take ownership. The e-mail message includes the service request name, description, internal priority, affected person, and reported date. | The logged-in user must create a communication to send this e-mail notification. It is not automatic. | none |