Gestion des sites

AFFICHER TOUT LE CONTENU

Table des matières

Configurations

Articles reliés

Introduction

La gestion des sites est un aspect important de la manipulation quotidienne d'Octopus. Nous retrouvons les sites dans les requêtes, dans la fiche des utilisateurs, dans la fiche des CI; autrement dit, ils sont omniprésents et critiques à l'utilisation d'Octopus.

Nous décrivons dans cet article l'explication des différents champs et termes utilisés pour représenter chaque niveau de site et comment cette information se retrouve à travers l'application.

Configuration de base

La configuration de base se complète à partir de la Gestion des données de référence. Celle-ci se compose de plusieurs onglets. La partie de configuration des sites se trouve sous la section Général > Sites.

Voir en image

Onglet Informations générales

  • Abréviation : Une nomenclature plus courte pour identifier les sites. Peut être utilisé aussi dans les colonnes.
  • Adresse : Adresse physique du site. Peut également être utilisé comme colonne.
  • Fuseau horaire : Permet d'assigner un fuseau horaire différent de celui par défaut (ou principal) de l'application. Consulter l'article sur les fuseaux horaires pour plus d'informations.
  • Centre de services : Lorsqu'un centre de services précis doit recevoir par défaut toute requête d'un site en particulier, il est possible de le préciser à partir de cette option. Par exemple, le centre de services (groupe) Informatique-CA est responsable de toutes les requêtes provenant du Canada. Il serait donc possible dans la fiche du site d'y insérer directement le nom du groupe prenant ce site en charge.
  • Fusionner : Tel qu'on la retrouve à plusieurs endroits dans Octopus, la fonction de Fusionner permet de remplacer dans l'application une donnée par une autre. Dans le cas où deux sites se fusionnent, le premier sélectionné sera supprimé (y compris dans l'historique) et sera remplacé partout par le second. 
ATTENTION : En raison de l'impact d'une telle manipulation sur la base de données, une fusion de site ne doit se faire qu'en dehors des heures ouvrables pour éviter un risque de ralentissement sur l'environnement Octopus.
  • Note : Permet d'ajouter une note à un site qui pourra être utilisée dans les listes et comme critère de recherche.
  • OU associées au site dans Active Directory : Permet de lier de façon automatisée toute donnée provenant d'une importation d'une OU (Organizational Unit) d'Active Directory à un site Octopus. Plusieurs OU peuvent être précisées dans cette section; il faut cependant entrer une OU par ligne. L'icône Parcourir Active Directory tout juste à côté de la boîte permet de naviguer dans votre réseau pour aller chercher le nom exact de la OU sans devoir la saisir manuellement.
ATTENTION : Le nom long Windows d'une OU est ici requis. Il est suggéré d'utiliser l'icône Parcourir Active Directory pour faciliter la saisie du nom de la OU dans le bon format.

Onglet Requêtes disponibles

Cet onglet permet de limiter les requêtes disponibles à chaque site et sous-site afin de personnaliser les types de requêtes à chaque site.

Les choix sont :

  • Permettre tous les types de SR et gabarits d'incidents : Rend tous les gabarits et types disponibles pour ce site. C'est le choix par défaut lors de l'ajout d'un site.
  • Permettre les types de SR et gabarits d'incidents sélectionnés ci-dessous : Limite la disponibilité des types de SR et gabarits d'incidents à ceux qui sont cochés.

Pour en savoir plus sur la resctriction par site, voir la section Comment Octopus traite la restriction par site? plus loin. 

Onglet SLA

L'onglet SLA permet de préciser les ententes sur les niveaux de service en fonction du site.

Tout comme l'onglet de requêtes disponibles, les choix sont :

  • Utiliser les SLA globaux (définis dans "Options") : Applique les SLA par défaut, tels que définis dans la Gestion de données de référence ou dans les Options (tous deux à partir du menu Outils).
  • Utiliser les SLA spécifiques définis ci-dessous : Limite le site à de nouveaux SLA précisés directement dans cette fenêtre. Ne dépend donc plus des ententes principales de niveaux de service.
ATTENTION : La précision de SLA différent des ententes principales n'est possible qu'au premier niveau d'un site (racine). Les sous-sites ne permettent pas cette configuration. Il est donc important de prendre en considération cet aspect lors de la prise de décision du nombre de niveaux de sites désirés.

Explication et configuration avancée

Les niveaux réels de sites

Lors de la configuration d'Octopus, il faut fréquemment préciser plusieurs niveaux de sites pour documenter par exemple des provinces, villes, bâtiments et même les étages des endroits physiques, selon le contexte.

Voici les différents niveaux logiques de sites disponibles dans Octopus : 

  • Site racine (root) : Représente le site d'origine à partir duquel débute l'arborescence des sites. Il s'agit du plus haut niveau de site possible dans la structure.
  • Site parent : Représente les niveaux supérieurs du site ciblé, sans pour autant être la racine. C'est le plus haut niveau d'un point de vue structurel.
  • Sous-sites : Représente les sous-niveaux du site ciblé. C'est le plus bas niveau d'un point de vue structurel.
  • Site : Représente l'ensemble des sites d'un élément (CI, utilisateur, requête, etc.), incluant tous les niveaux, dont la racine, les parents et les sous-sites.

Mise en contexte

Prenons le contexte où les sites et sous-sites représentent le pays, la province ainsi que les villes sous cette province. Le client fait affaire partout au Canada et aux États-Unis et il doit gérer ses utilisateurs selon leur localisation précise.

Dans ce cas précis, un des sites principaux (site racine) serait Canada, suivi d'un sous-site (niveau second) de province tel que Québec, qui à son tour comprendrait plusieurs villes (niveau tiers des sous-sites) dont Montréal, Sherbrooke, Rimouski, etc.

Canada -> Québec -> Montréal, Sherbrooke ou Rimouski

Selon la logique établie dans le point précédent, un utilisateur faisant partie du site Montréal aurait la valeur suivante :

  • Site racine : Canada
  • Site parent : Canada, Québec
  • Sous-sites : Québec, Montréal

Comme on peut le constater, les valeurs que l'on retrouve dans Sous-sites ou encore dans Site parent seront toutes les valeurs correspondantes et non seulement le niveau immédiat.

Voir en image

Colonnes et champs principaux de recherche

Lors de l'utilisation des colonnes de sites dans une fiche Octopus, voici les 4 possibilités d'affichage de champs correspondants pour retrouver l'information principale de sites :

  • Pour afficher une colonne montrant seulement le site racine (Canada, dans ce cas-ci) :
    • Ajouter la colonne Site racine.
  • Pour afficher une colonne montrant les sites parents du site (Canada, Québec, dans ce cas-ci) :
    • Ajouter la colonne Site parent.
  • Pour afficher une colonne montrant le site même et les sous-niveaux au-dessus de lui (excluant le site racine) :
    • ​Ajouter la colonne Sous-sites.
  • Pour afficher l'ensemble des niveaux, incluant le site racine et tous les sous-sites :
    • Ajouter la colonne Site.
Ce qu'il faut savoir :

Ajouter le champ Nom complet affichera la même information que le champ Site. Il s'agit simplement d'une autre option pour retrouver l'information, selon le nom de champ le plus évocateur et selon le contexte client.

Champs supplémentaires d'information de sites

À noter qu'il est également possible de retrouver de l'information supplémentaire précisée dans les données de références, en lien aux sites.

  • Pour afficher l'abréviation du site :

    • Ajouter le champ Abréviation.

  • Pour afficher l'adresse physique du site :
    • Ajouter le champ Adresse.
  • Pour afficher seulement le dernier niveau de site dans lequel l'élément se trouve :
    • Ajouter le champ Nom.
Ce qu'il faut savoir : 

Noter que même si les explications données sont écrites en fonction des colonnes, la logique demeure la même si l'on désire plutôt retrouver l'information à partir d'une recherche avancée.

Comment Octopus traite la restriction par site?

Octopus permet de restreindre le type de requête pouvant être soumis par des gens en fonction du site inscrit dans leur fiche utilisateur. Cette restriction s'applique autant à l'intérieur du logiciel que sur le portail Web, mais elle a des règles bien précises.

Nous allons utiliser des scénarios dans les sections qui suivent pour illustrer ces règles. 

Dans Octopus avec création par un intervenant

Lors de la création de la requête, l'intervenant choisit le nom du demandeur et celui de l'utilisateur, si celui-ci est différent de la personne qui fait la demande. Par défaut, le site choisi dans Octopus sera celui de l'utilisateur, mais ce site peut être modifié par l'intervenant. 

Comme la restriction est en fonction du site de la requête, les gabarits d'incidents et types de SR présentés à l'intervenant seront ceux autorisés pour le site choisi. 

Note : Si la restriction par site s'applique, on recommande de mettre le site obligatoire au niveau des options. 

  Mise en scène pour mieux comprendre

  • Une requête pour une "Demande de stationnement intérieur" existe et a été restreinte au site de Montréal seulement. 
  • Carl Bernier est associé au site de Montréal. 
  • Vicky Dumont est associée au site de Chicoutimi.

Lorsque Carl ou Vicky font une demande au Centre de services, les requêtes disponibles diffèrent en fonction de la situation : 

Carl fait une demande :

  • Pour lui-même, la requête est disponible par défaut, car il est de Montréal. 
  • Pour Vicky, la requête n'est pas visible par défaut, car elle est de Chicoutimi; l'intervenant doit modifier le site de la requête pour compléter la requête.*

Vicky fait une demande :

  • Pour elle-même, la requête n'est pas visible par défaut, car elle est de Chicoutimi; l'intervenant doit modifier le site de la requête pour compléter la requête.* 
  • Pour Carl, la requête est disponible par défaut, car il est de Montréal. 
* ATTENTION : Lorsqu'il y a une restriction par site, l'intervenant doit obligatoirement demander plus d'information avant de soumettre la requête, puisqu'il y a des raisons à la restriction par site.

Dans le portail Web avec création par un demandeur

Lorsqu'une personne accède au portail Web et fait une requête, elle sera toujours le demandeur de la requête, mais certains types de requêtes permettent de choisir un utilisateur différent de soi-même.

Si le site est obligatoire dans les options, il sera visible lorsque la personne créera une nouvelle requête. Si le site n'est pas obligatoire, il sera en fonction du site de l'utilisateur de la requête et ne pourra pas être modifié sur le portail. 

Comme la restriction est en fonction du site de la requête, les gabarits d'incidents et types de SR présentés à la personne sur le portail seront ceux autorisés pour le site de l'utilisateur. 

  Mise en scène pour mieux comprendre

  • Une requête pour une "Demande de stationnement intérieur" existe et elle a été restreinte au site de Montréal seulement. 
  • Carl Bernier est associé au site de Montréal. 
  • Vicky Dumont est associée au site de Chicoutimi.

Nous allons voir les cas les plus fréquents lorsque Carl ou Vicky font une demande sur le portail Web, les requêtes disponibles diffèrent en fonction de la situation : 

  • Carl fait une demande pour lui-même, que le site soit visible ou non, la requête est disponible, car il est associé au site de Montréal. 
  • Vicky fait une demande pour elle-même, si le site est visible, elle modifie le site pour celui de Montréal, fait la sélection du type de demande et peut soumettre la requête. 
    • Si le site n'est pas visible, elle ne peut pas procéder.

Pour voir d'autres cas, plus complexe, voir la FAQ Cas spécifiques de restriction de requêtes par sites. 

Recommandations pour l'utilisation de la restriction par site

La restriction par site est subtile et les gens ne connaissent pas toujours les règles derrière le comportement d'Octopus. La première recommandation est de mettre le site obligatoire au niveau des options. 

Ensuite, on recommande d'ajouter une note dans le formulaire pour ceux qui auront à remplir la requête sur le portail Web expliquant la restriction de la requête et les raisons.

Pour les intervenants, une procédure peut les aider à mieux comprendre le moment où il est permis ou non de procéder à une requête restreinte par site.

Voir en image

 

 

X
Aidez-nous à améliorer l’article