Table of contents
Article resuming the whole Octopus basic configuration
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.
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.)
- 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
- adjustment to a software or application configuration to resolve an incident
Subcategories related to telephony are similar to the ones defined under the "Hardware" category.
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.
Restrict a request by user group
- Open an existing request from the reference data management.
- Go to the Advanced tab.
- Check the Restrict the access according to user groups option.
- Still in the reference data management.
- Go to the General > User groups section.
- Select a group or create a new one.
- Go to the Available Requests tab.
- Select the requests that are allowed for the group.
Restrict a request by site
- Open an existing request from the reference data management.
Go to the Advanced tab.
Check the Restrict the access according to user groups option.
Still in the reference data management.
- Go to the General > Site section.
- Select the site.
- Go to the Available Requests tab and check the Request types visible for this site option.
Select the requests that are allowed for the site from this list.
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".
"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
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.
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.
- 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.
Reasons for Cancelling, Pending and Suspension
Thank you, your message has been sent.