SHOW ALL CONTENT

Incidents Categories / Subcategories

To start, it is important to understand that there are no perfect categories. The main objective of an adequate categorization system is to represent a clear comprehension of user reported problematic. This approach favors a better comprehension of the IT infrastructure use when the time comes to analyze and present reports.

In an simple operational context, the categorization that we propose should cover the majority of different incident types that occur in an IT department, but it is possible that it does not completely represent your reality. You will notice that the sub-category "Other" is present in all categories, to offer an ultimate choice when no other is applicable.

If at a later date, the categorization you are using does not correspond to your needs anymore, it is possible to merge or simply deactivate a category or subcategory with the Active checkbox. Once a category or subcategory has been deactivated, it cannot be selected in incidents anymore. Incidents and reports using a category that is no longer active will keep this category unless someone changes it manually.

You can modify the categories by going to Tools > Reference Data Management.. > Incident > Categories / Sub-categories.

Basic model for incident categorization:

Access / Security

We have grouped these two (2) categories together to simplify things. The IT groups wishing to handle security incidents in a confidential way could do it through a separated team.

Incidents related to access represent an access owned by user that is no longer available. To request a new access or changes to an existing access, the user must submit a service request of "access" type.

Hardware

The "Hardware" category includes all the hardware that is required for computers, but excludes telephony, that we have addressed in another section. Designating an element of the infrastructure (CI in cause) allows more "precision" on the categorization, in the sense that it allows to identify the element type related to the incident.

For example, identifying a printer as a CI in cause does not require a categorization specific to printers. A specific report on the "printer" CI type allows you to obtain all the information related to printers.

Poor Performance
- Slowdown when using the equipment
Main element broken
- A main element is an element that is part of the CMDB and that must be managed and followed (example: printers, workstations, laptops, etc.)
Broken accessory
- An accessory is an item that is not part of the CMDB and does not need to be managed - for example, keyboards, mice. The incident will be categorized as Hardware / Broken accessory and the CI in cause will be the user's workstation (If it is absolutely necessary to identify defective mice and keyboards in the incidents, we suggest that you create a CI type "Accessories" and to add "Keyboard" and "Mouse" in a generic way since these items haven't been uniquely identified in the CMDB.)
Configuration
- The hardware configuration could also include the installation of a printer driver, for example. Be careful: sometimes, a configuration change can compromise the stability of the production environment, we would then have to proceed to a formal change. The service center must understand the limit of its intervention at this level.

Software / Application

"Software" refers software acquired on the market, whereas "Application" refers to a business application used internally, developed or not by the company. We have regrouped these categories to simplify things, but some organizations may prefer to keep them separate in the reports. This is a personal choice, there is no good or bad way to do it.

Anomaly / Defect
- this represents an error message while using the application or the software, but does not represent a modification to an application (addition / modification to a field or an application feature) - in that case, it is a change, not an incident.
Performance drop
- slowdown when using a software or application
Configuration
- adjustment to a software or application configuration to resolve an incident

Telephony

Subcategories related to telephony are similar to the ones defined under the "Hardware" category.

Recommendations:

When adding, modifying or using a category / subcategory:

<Add the systematic verification of the category / sub-category to the working methods at the resolution of an incident; the initial categorization may change during troubleshooting, and it is at the resolution that we know the final categorization. This will increase the reports integrity (to this objective, Octopus has integrated an automated feature that makes the categorization mandatory at the resolution, not the creation of the request - however, this does not guarantee the accuracy of categorization that would have been selected at the creation)
The categorization has many objectives: pinpoint the incidents in regards to the infrastructure and identify the weaknesses of it's elements; guide the teams in the troubleshooting steps; allow reporting to represent different situations, depending on the audience being addressed (so there must be some flexibility in the representation of data)
The categorization must be easy to use and intuitive, and must not be confusing to the ones using it (like the IT resources)
The use of the "other" subcategory should be monitored, it could be that a category is missing or that the resource does not understand the categorization
Avoid changing the categorization too often or creating a category for a temporary situation; this makes the comparative analysis over periods more difficult
Avoid categories that represent incident solutions, otherwise you will soon end up with a categorization that is complex and hard to use, and reports that are too complex to mean anything

Incident Templates

The following are the preconfigured incident templates. Notice that identify the incident as a "problem"; this is intentional for incident templates designed for users on the Web Portal - for them, the situation is a "problem".

How to Add an Incident Template

Incident templates accelerate the capture of information with preconfigured fields. Octopus also allows the creation of "Quick call" incidents; at the creation / saving of the incident, it will automatically be closed.

Incident templates can be used by Octopus resources or by users via the Web Portal, if they were made visible. By default, Octopus already has some incident templates (Problems with my workstation, Problems with my phone, Access problems, software problems).

Access the incident templates via Tools > Reference data management... > Incident > Templates
Right click on Templates and select "Add"
Enter a description (Mandatory field at the template creation)
You can:
- Associate a category and subcategory
- Automatically assign to a group/Octopus user
- Designate a default priority

To render the incident template visible on the Web Portal, check the option from the "Web Portal" tag. A personalized Web form can be developed in this tab. To find out more, see the the Web Form Customization article.

Restrict a template

It is possible to filter who can make certain types of requests. The option restricts in two methods:

With a user group.
With a site.

The restriction applies to the requester, it works as well for requests created from the Web Portal as the ones opened internally. If the requester is not allowed to submit or ask for that request type, it will simply not come up in the list of choices.

See the Restrict a template article for more information.

What you need to know:

A request will be restricted on the Web Portal as well as in the Octopus application.

To allow an Octopus user to select a restricted request type, he must first choose a requester that is a member of the group or site allowed to use the restricted request.

How to add an internal procedure

It is possible to add an internal procedure to a request. This option helps users who work in Octopus, you can add steps to be taken, troubleshooting information, etc.

The information displayed is related to the selected incident template. The xxx action can be used to display the request procedure.

Here are the steps to add an internal procedure:

Access incident template via Tools > Reference data management... > Incident > Templates
Select the request to configure and go to the general tab
At the bottom of the screen, document the internal procedure in the language of the Octopus users
Save with the diskette and end with Close

How to Delete an Incident Template

Right click on the template you want to get rid of and select "Delete".

ATTENTION: It is not possible to delete a template that has been used to create an incident. You have two choices: uncheck the "Active" box to deactivate the template, or merge the template to another. Merging will remove the link from the incidents created with the source template and create a new link to with the destination template. Then the source template will be deleted.

Quick Call

"Quick call" templates cannot be made available on the Web Portal. This functionality is only used by the Service Center personnel, to accelerate data entry for certain incident types for which the resolution is known and quick. Consequently, the "Quick call" option is only available if the template is not designated as visible on the Web Portal.

In this case, specify the "Average Effort", since all recordings will require a minimum time of execution and the effort cannot be entered manually. A resolution activity will automatically be created.

Impacts / Urgencies / Priorities

The Impacts, Urgencies and Priorities fields are used in different places:

Impacts
- In the Incidents if visible can help choose the priority of the incident
- Represents the Criticality of the CIs
Urgencies
- In the Incidents if visible can help choose the priority of the incident
Priorities
- In the Incidents will show the priority of the incident
- In the SRs, if visible to show the priority of the SR
- Serves as the basis for incident SLAs when they are active

What you need to know:

Changing the Impacts will affect the Impact field of incidents as well as the Criticality field of CIs. We recommend that you analyze your needs carefully before making any changes.

Configurations for each section is described in the following table.

How to Modify the Lists and Priority Derivation

Octopus applies the ITIL concepts for the priority in designating the impact and urgency. You can refer to the Priority Definition and Basic Service Levels ITIL article for a better understanding of this concept.

First, it is not mandatory to identify the impact and urgency in order to get the priority in Octopus; if you want to use only the "Priority" field, you need to make the "Impact" and "Urgency" fields invisible (see the Visible/Mandatory Fields section).

Octopus applies this derivation at the base. The "Priories", "Impacts" and "Urgencies" lists are already configured with items and a derivation matrix is applied.

Proceed this way to modify these lists:
- From the Tools > Reference data management... > Incidents menu
- You can add, modify, or delete the items in each of the (3) lists ("Impacts", "Urgencies" et "Priorities)
Proceed this way to adjust the priority derivation matrix:
- From the Tools > Options... menu
- Adjust the matrix's available choices under the Priority derivation subsection, of the 3- Important general options section.

Visual explanation

Default Priority

To accelerate the data entry of incidents, you can choose to activate the default priority that will be designated at the incident creation. If you would like to use this option, you could for example, select a "3 - Normal" default priority, if the majority of your incident are of priority 3 - Normal.

Visible/Mandatory Fields

From the Tools > Options... > Visible and required fields
Determine if the "Impact", "Urgency" and "Priority" fields need to be visible and/or mandatory, depending on how you wish to use the priority in all your incidents.