Home page | Pages by category | Page index

Quick search

Basic Configuration - Incidents

RSS

Modified: 2011/09/09 17:44 by pnarbonne - Uncategorized

This page is in the process of being edited, it may be incomplete or contain errors.

Table of Contents [Hide/Show]

Edit

Configurations - Octopus standard model
Article resuming the whole Octopus basic configuration. Edit

Incidents Categories / Sub-categories

At first, it is important to understand that there exists no perfect category. The principal objective of an adequate categorization system is to represent a clear comprehension of user reported problematics. This approach favors a better comprehension of the IT infrastructure use when comes the time to present reports.

In an simple operational context, the categorization that we propose should cover the majority of different incident types that occur in a computer department, but it is possible that it does not completely represent your reality. You will notice that the sub-category "Other" is presented in all categories, so that it can offer a last choice when none others are applicable.

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

Basic model for incident categorization :

Edit

Access / Security

We have grouped these two (2) categories for simplification reasons. The computer groups wishing to treat security incidents in a confidential way must could do it through a separated team.

Incidents related to access represents an access owned by users that is not available anymore. In the opposite case, the user must submit a formal service request of "access" type.

Edit

Hardware

The "Hardware" category includes everything about computer hardware, other than telephony, that we have addressed apart. The designation of an infrastructure (CI in cause) allows an "extension" of the categorization, in a sense that it permits the identification of the element type of the incident.

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

Poor Performance

slowdown when using the equipment

Main element broken

a main element is an element 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 very generic way since these items haven't been precisely identified in the CMDB.)

Configuration

the hardware configuration could also include an installation of a printer driver, for example. Beware: 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.

Edit

Software / Application

"Software" refers to a software acquired on the market, whereas "Application" refers to a business application used internally, developed or not inside the company. We have regrouped these categories for simplification reasons, 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

Edit

Telephony

Sub-categories related to telephony are similar to the ones defined under the category "Hardware".

Recommandations :

When adding, modifying or using a category / sub-category:

integrate into the working methods the systematic verification of the category / sub-category of an incident at the resolution; the initial categorization may change during resolution, and it's at the resolution that we know the final categorization. This will increase the reports integrity (in this objective, Octopus has integrated an automated feature that makes that the categorization is not mandatory at the creation of the request, but is at the resolution - however, this does not guarantee the accuracy of categorization that would have been placed at the creation)

la catégorisation a plusieurs objectifs: situer les incidents dans l'infrastructure et identifier les faiblesses de ses éléments; guider les équipes dans les étapes de résolution des incidents; permettre l'établissement de rapports permettant de représenter différentes situations, selon l'audience à laquelle on s'adresse (il faut donc avoir une certaine flexibilité dans la représentation des données)

la catégorisation doit être simple d'utilisation et intuitive, exempte de confusion de la part de ceux qui l'utilisent (entre autre, les ressources informatiques);

l'utilisation de la sous-catégorie "autre" doit être surveillée, peut-être y a-t-il un manquement, ou peut-être que la ressource ne comprend pas bien l'utilisation de la catégorisation

évitez de modifier la catégorisation trop souvent, ou évitez de créer une catégorie qui adresse une situation temporaire; ceci rendra les analyses comparatives par période plus difficiles

éviter de créer des catégories qui présente la solution des incidents, sinon vous vous retrouverez rapidement avec une catégorisation complexe et ardue à utiliser, sans oublier la complexité des rapports que cela créera

Edit

Gabarits d'incidents

Les gabarits d'incidents pré configurés dans Octopus sont les suivants. Vous noterez que nous suggérons une nomenclature qui identifie un incident comme un "problème"; ceci est intentionnel pour les gabarits destinés au Web libre-service à l'usage exclusif des utilisateurs - pour eux, il s'agit de "problèmes".