AFFICHER TOUT LE CONTENU

Table des matières

Articles reliés

Article résumant toutes les configurations du modèle de base Octopus :

Catégories / Sous-catégories des incidents

En premier lieu, il faut comprendre qu'il n'existe aucune catégorisation parfaite. L'objectif principal du développement d'une catégorisation adéquate est de représenter une compréhension claire des problématiques rapportées par les utilisateurs. Cette approche favorise une meilleure compréhension de l'utilisation de l'infrastructure informatique lorsque survient la présentation ou l'analyse des rapports.

Dans un contexte opérationnel simple, la catégorisation que nous proposons devrait couvrir la majorité des différents types d'incidents qui surviennent dans un département informatique, mais il se peut qu'elle ne représente pas totalement votre réalité. Vous remarquerez que la sous-catégorie Autre est présente dans toutes les catégories, de manière à offrir un choix lorsqu'aucune autre catégorisation ne convient.

Si plus tard, la catégorisation que vous utilisez ne convient plus, il est possible de fusionner des catégories semblables ou tout simplement de désactiver une catégorie ou une sous-catégorie avec la case Actif. Une fois désactivée, une catégorie ou sous-catégorie ne peut être sélectionnée dans un incident. Les incidents et rapports qui utilisent une catégorie qui n'est plus active garderont cette catégorie à moins qu'une personne ne la change manuellement.

Vous pouvez modifier les catégories en allant sur Outils > Gestion des données de référence... > Incident > Catégories / Sous-catégories.

Modèle de base de catégorisation des incidents :

Accès / Sécurité

Nous avons groupé ces deux catégories pour des raisons de simplification. Les groupes informatiques qui désirent traiter les incidents de sécurité de façon confidentielle pourraient le faire à travers une équipe séparée.

Les incidents relatifs aux accès représentent un accès qui était détenu par un utilisateur et qui fonctionnait, mais qui n'est plus disponible. Pour demander un accès ou des changements à des accès existants, l'utilisateur doit soumettre une demande de service de type accès en bonne et due forme.

Logiciel / Application d'affaires

Le terme Logiciel réfère à un logiciel acquis sur le marché, alors qu'une Application réfère à une application d'affaires utilisée à l'interne, qu'elle y soit développée ou non. Nous avons regroupé ces catégories pour des raisons de simplification, mais certaines organisations informatiques préfèrent qu'elles soient représentées séparément dans les rapports. Ceci est un choix strictement personnel.

Défectuosité / Message d'erreur
- Ceci représente un message d'erreur lors de l'utilisation d'une application ou d'un logiciel, mais ne représente pas une modification à une application (ajout / modification à un champ ou à une fonctionnalité d'une application) - dans ce cas, on parle d'un changement, non pas d'un incident.
Lenteur
- Ralentissement lors de l'utilisation d'un logiciel ou d'une application.
Configuration
- Correction à une configuration logicielle ou applicative afin de résoudre un incident.

Matériel

La catégorie Matériel inclut tout ce qui concerne le matériel informatique, autre que la téléphonie, qui a été adressé à part. La désignation d'un élément de l'infrastructure (CI en cause) permet une précision de la catégorisation, en ce sens qu'elle permet d'identifier quel type d'élément est impliqué dans l'incident.

Par exemple, l'identification d'une imprimante comme CI en cause ne nécessite pas une catégorisation spécifique aux imprimantes. Un rapport spécifique au type de CI Imprimante permettra d'obtenir toutes les informations reliées aux imprimantes.

Baisse de performance
- Ralentissement lors de l'utilisation du matériel.
Bris d'élément principal
- Un élément principal est un élément faisant partie de la CMDB et qui doit être gérée et suivi (exemple : imprimantes, postes de travail, portatifs, etc.).
Bris d'accessoire
- Un accessoire est un item qui ne fait pas partie de ce qui est géré et qui doit être suivi dans la CMDB; par exemple, clavier, souris. L'incident sera alors catégorisé Matériel / Bris d'accessoire et le CI en cause sera le poste de travail de l'utilisateur. (S'il vous est absolument nécessaire d'identifier les souris et les claviers défectueux dans les incidents, nous suggérons de créer un CI de type Accessoire et d'ajouter Clavier et Souris de manière tout à fait générique; ces items n'étant pas identifiés de façon unique dans la CMDB.).
Configuration
- La configuration matérielle pourrait toucher l'installation d'un pilote d'impression, par exemple. Cependant, un changement de configuration peut risquer parfois de compromettre la stabilité de l'environnement production et on doit alors procéder à un changement en bonne et due forme. Le Centre de services doit comprendre les limites de ses interventions à ce niveau.

Téléphonie

Les sous-catégories relatives à la téléphonie sont similaires à celles définies dans la catégorie Matériel.

Recommandations :

Lors de l'ajout, de la modification ou de l'utilisation d'une catégorie / sous-catégorie :

Intégrer dans les méthodes de travail la vérification systématique de la catégorie / sous-catégorie d'un incident lors de la résolution; la catégorisation initiale peut changer en cours de résolution et c'est au moment de la résolution qu'on est certain de la catégorisation finale. Ceci augmentera l'intégrité des rapports (dans cet objectif, Octopus a intégré une fonctionnalité automatisée qui fait que la catégorisation n'est pas obligatoire à la création, mais le devient lors de la résolution - cependant, ceci ne garantit pas l'exactitude d'une catégorisation qui aurait été inscrite à la création).
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 autres, 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.
Éviter de modifier la catégorisation trop souvent ou éviter de créer une catégorie qui adresse une situation temporaire; ceci rendra les analyses comparatives par période plus difficile.
Éviter de créer des catégories qui présentent 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.

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 portail Web à l'usage des utilisateurs - pour eux, il s'agit de problèmes.)

Comment ajouter un gabarit d'incident

Les gabarits d'incident permettent d'accélérer la saisie d'un incident par une saisie pré configurée de certains champs. Octopus permet aussi la création de gabarits de type Appel rapide; au moment de la création / sauvegarde de l'incident, ce dernier se fermera automatiquement.

Les gabarits d'incident peuvent être utilisés par les ressources Octopus ou par les utilisateurs à travers le portail Web, si les gabarits sont rendus visibles. Par défaut, Octopus contient déjà quelques gabarits d'incidents (Problème avec mon poste de travail, Problème avec mon téléphone, Problème d'accès, Problème logiciel).

Accéder aux gabarits d'incidents via Outils > Gestion des données de référence... > Incident > Gabarits.
Faire un clic droit sur la section Gabarits et sélectionner Ajouter.
Inscrire un sujet (champ obligatoire à la création du gabarit).
On peut :
- Associer une catégorie et une sous-catégorie.
- Assigner automatiquement un groupe et/ou un intervenant.
- Assigner une priorité par défaut.

Pour rendre visible ce gabarit d'incident dans le portail Web, vous devez cocher l'option dans l'onglet Portail Web. Un formulaire plus personnalisé peut être développé à partir de cet onglet. Nous vous référons à l'article Création de formulaires Web personnalisés pour plus de détails.

Restriction d'un gabarit

Il est possible de filtrer qui peut faire une demande pour un type de requête en particulier. L'option permet de restreindre de deux méthodes différentes :

Via un groupe d'utilisateurs.
Via un site.

Cette restriction s'applique au demandeur de la requête, elle fonctionne autant sur les requêtes remplies à partir du portail Web qu'à l'interne. Si le demandeur n'a pas le droit de soumettre ou demander un type de requête, il n'apparaîtra tout simplement pas dans la liste des choix.

Pour plus d'information, voir l'article Restrictiond'un gabarit.

Ce que vous devez savoir :

Lorsqu'une requête est restreinte, elle l'est sur le portail Web ainsi que dans l'application Octopus.

Pour qu'un intervenant Octopus soit en mesure de sélectionner le gabarit de requête, il doit d'abord associer un demandeur qui est membre du groupe ou du site dont fait partie le type de requête restreint.

Comment ajouter une procédure interne

Il est possible d'ajouter une procédure interne d'une requête. Cette option sert de soutien aux intervenants qui travaillent dans Octopus; on peut y mettre des étapes à suivre, des informations pour faire le dépannage, etc.

L'information affichée est en lien avec le gabarit d'incident sélectionné. L'action Consulter la procédure sera utilisée pour voir la procédure à partir de la requête.

Voici les étapes pour ajouter une procédure interne :

Accéder aux gabarits d'incidents via Outils > Gestion des données de référence... > Incident > Gabarits.
Faire la sélection de la requête à configurer et aller dans l'onglet Général.
Dans le bas de l'écran, documenter la procédure interne dans la ou les langues de vos intervenants.
Sauvegarder avec la disquette et Fermer pour terminer.

Pour supprimer un gabarit d'incident

Faire un clic droit sur le gabarit à supprimer et sélectionner Supprimer.

ATTENTION : Il est impossible de supprimer un gabarit qui a déjà été utilisé dans la création d'un incident. Deux choix s'offrent alors :
Décocher la case Actif pour désactiver le gabarit, ou Fusionner le gabarit avec un autre. La fusion enlève le lien entre les incidents créés et le gabarit source et crée un nouveau lien au gabarit de destination. Par la suite, le gabarit source est automatiquement supprimé.

Appel rapide

Un gabarit de type Appel rapide ne peut être disponible sur le portail Web. Cette fonctionnalité ne sert qu'au personnel du Centre de services pour accélérer la saisie de certains types d'incidents dont la résolution est connue et rapide. Par conséquent, l'option d'Appel rapide n'est disponible que si le gabarit est désigné comme non visible sur le portail Web.

Dans ce cas, on spécifie un effort moyen, car tout enregistrement nécessite un temps d'exécution minimal et l'effort ne pourra être entré manuellement. Une activité de résolution sera automatiquement créée.

Impacts / Urgences / Priorités

Les champs Impacts, Urgences et Priorités sont utilisés à divers endroits :

Impacts
- Dans les Incidents si visibles, peut aider au choix de la priorité de l'incident
- Représente la liste des Criticités des CI
Urgences
- Dans les Incidents si visibles, peut aider au choix de la priorité de l'incident
Priorités
- Dans les Incidents pour montrer la priorité de l'incident
- Dans les SR, si visible, pour montrer la priorité de la SR
- Sert de base pour les SLA des incidents lorsque ceux-ci sont actifs

Ce qu'il faut savoir :

La modification des Impacts affecte le champ Impact des incidents que le champ Criticité des CI. On recommande de bien analyser les besoins avant de faire des modifications.

Les configurations pour chaque section sont résumées dans le tableau suivant :

Comment modifier les listes et dérivations de la priorité

Octopus applique le concept ITIL de la priorité en fonction de la désignation de l'impact et de l'urgence. Vous pouvez vous référer à l'article ITIL Priorité des incidents et niveaux de service de base pour vous aider à comprendre ce concept.

En premier lieu, il n'est pas obligatoire d'identifier l'impact et l'urgence pour obtenir la priorité dans Octopus; si vous désirez utiliser seulement le champ Priorité, vous devez rendre invisibles les champs Impact et Urgence (voir la section Champs visibles et/ou obligatoires).

À la base, Octopus applique cette dérivation. Une liste d'éléments est configurée pour chacun des champs Priorité, Impact et Urgence et une matrice de dérivation est appliquée.

Pour modifier les listes, procédez de la façon suivante :
- À partir du menu Outils > Gestion des données de référence... > Incidents.
- Vous pourrez ajouter, modifier ou retirer les items pour chacune des trois listes (Impacts, Urgence et Priorités).
Pour ajuster la matrice de dérivation de priorités, procéder de la façon suivante :
- À partir du menu Outils > Options...
- Ajuster la matrice de choix disponibles dans la sous-section Dérivation de la priorité, de la section 3- Options générales importantes.

Voir en image

Priorité par défaut

Pour accélérer la saisie de vos incidents, vous pouvez choisir d'activer ou non la priorité qui apparaîtra par défaut à la création d'un incident. Si vous décidez d'activer cette option, vous pouvez inscrire, par exemple, une priorité par défaut 3 - Normale si la majorité de vos incidents sont de priorité 3.

Champs visibles et/ou obligatoires

À partir du menu Outils > Options... > Gestion des champs obligatoires.
Déterminer si les champs Impact, Urgence et Priorité doivent être visibles et/ou obligatoires, selon l'utilisation de la priorité que vous voulez utiliser pour l'ensemble de vos incidents.