Le module Service & incidents permet de gérer différents types de tâches. Les types de tâches disponibles pour un utilisateur dépendent des paramètres de son rôle. Les principaux types de tâches sont décrits sur cette page, mais le rapport d'avarie, par exemple, fait l'objet d'une page spécifique.

Un incident ou un problème (potentiel) peut être attribué à une personne de votre organisation ou d'une autre organisation. Si vous assignez une tâche à une autre organisation, vous ne pouvez pas spécifier l'utilisateur - c'est l'organisation assignée qui doit le faire (si elle le souhaite). Une fois qu'un assigné est rempli et que la tâche est sauvegardée, l'assigné recevra un courriel indiquant la création de la tâche et que l'attention pour traiter cette tâche est requise.

Incident

Un incident est un problème unique dans le réseau passif qui affecte plus d'une connexion. Cela signifie qu'un incident a un impact sur un nombre N de connexions. Il peut s'agir d'un incident de réseau (câbles, point de distribution) ou d'un incident de PoP. Un incident PoP qui a un impact direct sur le réseau passif et qui a donc un impact (direct) sur le service est un incident PoP orienté telco. Un incident PoP non telco ne concerne aucun des composants du réseau dans le PoP mais couvre tout ce qui se trouve autour, sur ou dans le PoP et qui est nécessaire au fonctionnement du PoP, comme l'alimentation de secours (batterie), l'air conditionné ou un extincteur. Le fait de ne pas être un opérateur de télécommunications n'a pas nécessairement d'incidence directe sur les services de réseau, mais peut en avoir une au fil du temps.

Sous-types d'incidents et codes de raison

Lors de la création d'incidents dans Gridsz, l'utilisateur peut attribuer un sous-type et un code de raison afin de fournir les détails nécessaires. Les sous-types actuellement disponibles sont les suivants :

• Réseau
  L'incident est lié au réseau passif à l'extérieur d'un point de contact. Il peut s'agir d'un câble ou d'un point de distribution.
• PoP
  Incident dans ou sur le PoP où des détails supplémentaires peuvent être ajoutés en attribuant un code de raison (s'il est connu) pour préciser s'il s'agit d'un incident telco ou non-telco.

Les codes de raison sont configurés par le PO et peuvent être utilisés pour ouvrir, maintenir ou clôturer un incident. Pour configurer les codes, le PO doit ajouter le lieu d'utilisation du code (ouverture/maintien/clôture), le code alphanumérique réel (unique), une description, le(s) type(s) de tâche attribué(s) et si le code est actif ou inactif. Les codes configurés sont communiqués par l'intermédiaire de l'API de l'AO et du contractant.

Relations d'incidents

Gridsz peut relier des tâches de service qui ont des relations de cause à effet ou qui doivent être reliées afin de traiter efficacement ces tâches en masse. Les incidents de connexion (1 connexion), les incidents (N>1 connexions) et les problèmes sont les tâches que Gridsz peut relier. Si des incidents de connexion sont à l'origine d'un incident, ces incidents de connexion peuvent être liés à l'incident. Une fois l'incident résolu, tous les incidents de connexion liés peuvent être clôturés en bloc si nécessaire. Lors de la clôture de l'incident, l'utilisateur est invité à indiquer si tous les incidents de connexion liés doivent également être clôturés ou s'il peut désélectionner tous les incidents de connexion ou un sous-ensemble d'entre eux. Les incidents qui se reproduisent et qui présentent des caractéristiques similaires peuvent être capturés dans un problème afin d'en rechercher les causes profondes et de fournir des tâches pour résoudre un problème et sa ou ses cause(s) profonde(s).

Acheminement des incidents

Gridsz peut acheminer les incidents et les problèmes vers les organisations contractantes au sein d'un groupe d'OP. Cela permet au PO ou à son NOC de diriger les tâches vers une partie spécifique de la solution. Le CNO peut choisir l'acheminement de l'entrepreneur pour un incident ou un problème individuel lors de la création de l'incident ou après la création de l'incident. Lors de la création de l'incident, la valeur de l'intervenant est vide. Dans le cas où un contractant se trouve en dehors de votre cluster dans Gridsz, le PO/NOC laisse le champ solution party vide et aucune tâche de contractant n'est créée. Cela permet d'éviter la création de tâches inutiles dans Gridsz , qui ne peuvent pas être reçues et traitées par la partie responsable de la solution. Le CNO devra communiquer et recevoir des mises à jour de la part de la partie responsable de la solution par téléphone et/ou par courrier électronique et les introduire dans l'incident. Assurer un suivi et une clôture appropriés de l'incident ou des incidents.

Problème

Une tâche problématique découle de deux incidents ou plus qui ont été évalués, qui partagent une relation de cause à effet et qui nécessitent une enquête plus approfondie sur la cause première afin d'éviter qu'un incident similaire ne se reproduise à l'avenir. Le CNO est en mesure de compiler des fiches de problème avec des incidents ouverts ou fermés. Comme les problèmes sont axés sur la prévention des incidents et la réduction de leur impact et que les incidents sont traités en temps réel, il faut s'attendre à ce que les tickets de problème comportent principalement des incidents liés qui sont clôturés. La possibilité de lier les incidents permettra d'alimenter le problème en informations cruciales pour déterminer les impacts et les causes profondes.

Problème, statut Potentiel

Gridsz peut déterminer s'il existe un problème potentiel. Le NOC est en mesure de compiler les problèmes potentiels à partir des incidents (ou v.v.) et d'évaluer s'il s'agit réellement d'un problème ou d'un incident unique ou non lié. Les problèmes potentiels peuvent être acceptés ; une fois acceptés, ils reçoivent le statut qui leur est attribué conformément au flux de transition de statut.

Notification d'impact (informer l'opérateur actif de l'impact sur le client)

Lorsqu'un incident est créé, Gridsz fournira (en fonction des informations réseau saisies) une liste de searchcodes et de DHid's pour chaque AO impacté. Pour communiquer cet impact potentiel à chaque AO, Gridsz crée des tâches impact_notification qui peuvent être communiquées via l'API AO ou par e-mail. La notification d'impact informera l'AO des détails de base de l'incident, tels que :

• ID
• Type
• Sous-type
• Priorité
• Code motif
• Temps de solution escompté
• Informations sur le réseau
• Impact potentiel
  • Codes de recherche
  • DHids
• Commentaires
• Pièces jointes

L'impact potentiel est communiqué par l'intermédiaire de l'API de l'AO et peut également être consulté en récupérant la pièce jointe (.csv) par l'intermédiaire de l'API de l'AO ou en recevant le fichier par notification électronique.

En cas de changement ou de mise à jour des informations sur le réseau, Gridsz fournira une nouvelle évaluation des codes de recherche et des DHid potentiellement affectés, qui seront ensuite communiqués aux AO par leur méthode de communication préférée.

Les notifications d'impact sont en lecture seule pour les AO, c'est-à-dire qu'aucune modification ne peut être apportée à ses éléments d'information tels que le sous-type, la priorité, le statut, les informations sur le réseau, les dates, etc. L'AO est autorisé à insérer des commentaires et/ou des pièces jointes dans la notification d'impact afin de fournir des informations ou de communiquer avec le CNO de l'OP.

L'impact_notification suit les statuts et les informations de sa tâche parente - l'incident. Si le statut de l'incident change (par exemple : l'incident est clôturé), les tâches de notification d'impact seront également clôturées. Si une information change, par exemple la priorité, elle sera également mise à jour dans les tâches de notification d'impact.

Changement de FTU

Un changement FTU est un ordre HAS permettant de modifier les FTU et leur emplacement (état de connexion). Cela permet aux opérateurs actifs de demander des changements que l'opérateur passif peut autoriser en créant la tâche de changement FTU. En fonction du changement requis, il est possible de choisir le sous-type correspondant, qui est expliqué ci-dessous. Le changement FTU est uniquement axé sur les informations HAS, ce qui signifie qu'aucun correctif n'est impliqué.

FTU Sous-types de changement

Lors de la création d'un changement FTU dans Gridsz, l'utilisateur a la possibilité d'attribuer un sous-type permettant d'effectuer les changements appropriés. Les sous-types disponibles sont expliqués ci-dessous :

• Construire
  Le Changement de FTU - Constituer permet de créer une tâche FTU_CONSTRUCT pour le contractant. Comme aucun PATCH_INSTALL n'est émis, ce type de tâche peut typiquement être utilisé lorsqu'un PO connecte activement des adresses avec de la fibre, mais ne souhaite pas patcher cette connexion.
  • La valeur de l'UFP planifiée est utilisée pour déterminer le type d'UFP que le contractant doit placer.
• Déplacer
  Le FTU Change - Move permet de créer une tâche FTU_MOVE pour le contractant. Si une adresse dispose d'une connexion active mais que, par exemple, l'emplacement de l'UFP ne répond pas aux exigences (techniques) du PO, la tâche FTU_MOVE permet au PO de définir un nouvel emplacement pour l'UFP.
  • L'emplacement actuel de l'UFP est extrait de Gridsz AC (s'il est disponible).
  • Lors de la création de la tâche, un nouveau statut de connexion (emplacement) peut être sélectionné pour la FTU.
  • Lorsque le contractant livre la tâche FTU_MOVE, il peut éventuellement être invité à confirmer le nouvel état de connexion (planifié). Ou, si pour une raison (technique) l'état de connexion initial planifié n'est pas possible, de sélectionner et de définir l'état de connexion réel de la FTU avant de livrer la tâche. Ces informations sont mises à jour dans la tâche mère. (cette information n'est actuellement pas mise à jour par AC)
• Remplacer
  Le FTU Change - Replace permet de créer une tâche FTU_RECONSTRUCT pour le contractant. Par exemple, dans le cas où le PO souhaite mettre à jour le FTU pour un modèle plus récent.
  • Le type de FTU actuel est extrait de Gridsz AC.
  • Le type de FTU planifié est extrait de Gridsz AC (nécessaire pour FTU_RECONSTRUCT).
• Remove
  La tâche FTU Change - Remove permet de créer une tâche FTU_REMOVE pour le contractant. Par exemple, si des bâtiments sont démolis ou rénovés et que la FTU doit être enlevée et le câble de fibre ramené à la limite de la propriété, le PO peut utiliser cette tâche.