Content for incident management

This topic describes the extended function provided by the best practices content for the Incidents 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, PMINCADMUSR is the predefined user name for the PMINCADM security group. Each user is created with a password that is set/chosen by the Administrator.

The PMINCADMUSR user occupies the role of Incident Administrator. The Incident 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 Incident Management Service Desk roles defined in the IBM® Tivoli® Unified Process (ITUP). Besides the ITUP user roles, the package includes an Incident Administrator security group (named PMINCADM) that is authorized to access all applications.

The following table lists the security groups for incident management. A start center is generated for each group.

Security group name Description Start center template
PMINCADM Incident Administrator group. These users have rights to every action and every application. PMINCADM
PMINCMGR Incident Manager group. These users create the activities and policies for an incident management organization. The Incident Manager monitors how well the incident process is implemented for the entire site, organization, or Maximo installation. PMINCMGR
PMINCOWN Incident Owner group. These users oversee the handling of an incident, bringing in analysts and specialists as needed. The Incident Owner is responsible for bringing the incident to closure. PMINCOWN
PMINCANAL Incident Analyst group. These users are subject matter experts in one or more areas. The Incident Analyst is responsible for analyzing an incident or solution in order to restore a service as soon as possible. PMINCANAL

Queries

The following table shows the queries that have been added for incident management. These queries provide quick access to information about current and historical incidents.

See Record Statuses for definitions of the statuses referred to in this table (new, queued, in progress, pending, resolved, and closed). An open incident is defined as an incident in any status except RESOLVED or CLOSED.

Clause name Query description
PMINCOPEN All open incidents
PMINCMYOPEN My open incidents
PMINCLATE All open incidents that are late or at risk of being late.
  • Late refers to an open incident record in which the date/time shown in the Target Finish field is earlier than the current date/time, and the Actual Finish field is empty.
  • At risk of being late refers to an open incident record in which the actual start date/time is later than the target start date/time, or the Actual Start field is empty and the target start date/time is earlier than the current date/time.

Note that a target finish date is not required. An incident with no target finish date is not considered late or at risk of being late because the expected completion date is unknown.

PMINCMYLATE My open incidents that are late or at risk of being late.

See the PMINCLATE query description for definitions of late and at risk of being late.

PMINCREPURG All open incidents with Urgent Reported Priority
PMINCINTURG All open incidents with Urgent Internal Priority

Key Performance Indicators

The following table shows the Key Performance Indicators (KPIs) that have been added for incident management.

KPI name KPI description
PMINCLATEA Number of late activities or activities at risk of being late from all open incidents.

See the PMINCLATE query description for definitions of late and at risk of being late.

PMINCAVGTI Average process time per incident in hours
PMINCOPEN Incidents that are currently open
PMINCWAPP Open incidents that have activities that are waiting for approval
PMINCURG Open incidents marked Urgent Priority (internally)
PMINCHIGH Open incidents 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 an incident record when certain conditions occur, such as a change in the status of the incident.

The following table lists the predefined communication templates provided for the Incidents 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 ESCINCCLS10 escalation, which triggers a notification 10 days after an incident 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.

Table 1. Predefined communication templates and automatic notifications for the Incidents application
Template name Template title Template description Automatic notification Escalation
CTINCNEW Incident has been created Notifies the recipients that an incident record has been created. The e-mail message includes the current status of the incident and the internal priority. This communication is automatically sent to the Reported By and Affected Person users within one day after an incident is opened. ESCINCNEW
CTINCRES Incident is resolved Notifies the recipients that the incident has been resolved. The e-mail message includes the reported date of the incident, classification, description, and solution details. This communication is automatically sent to the Reported By and Affected Person users within one day after the incident status changes to RESOLVED. ESCINCRES
CTINCCLS Incident is closed Notifies the recipients that the incident has been closed. The e-mail message includes the reported date of the incident, classification, description, and solution details. This communication is automatically sent to the Reported By and Affected Person users within one day after the incident status changes to CLOSED. ESCINCLS
CTINCCLS10 Incident is closed This template is the same as the CTINCCLS template, but the conditions for automatic notification are different. After an incident has been in RESOLVED status for 10 or more days, the incident is automatically changed to CLOSED status and this communication is sent to the Reported By and Affected Person users within one day after the incident is closed.

The ESCINCCLS and ESCINCCLS10 escalations are coordinated so that only one notification is sent in case of a conflict.

ESCINCCLS10
CTINCASN Incident is assigned Notifies all members of an owner group that a new incident has been assigned to the group and encourages anyone in the group to take ownership. The e-mail message includes the incident 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