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 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 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.
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.
| 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 |