Pour les flux de travail liés à l’exécution des commandes, Gridsz utilise un moteur de flux de travail et un modèle d’état dédiés, partagés par tous les propriétaires de réseaux. Cela permet à toutes les parties connectées à Gridsz de communiquer entre elles de manière standardisée. Toutefois, certaines fonctionnalités peuvent être activées ou désactivées par chaque propriétaire de réseau et, dans certains cas, même par chaque partie. Outre les choix effectués par les propriétaires de réseaux, le modèle d’état variera en détail selon le type de tâche concerné. La description de toutes les variantes n’entre pas dans le cadre du présent document.

InTask, OutTaskSrt et OutTasks

Le cœur du moteur de workflow réside dans la communication et la synchronisation entre la demande émanant de l'opérateur (passif ou actif) (l'InTask) et la ou les tâches (OutTasks) qu'un prestataire doit accomplir pour répondre à cette demande. L'OutTaskSet reflète l'état d'une ou de plusieurs OutTasks. Les transitions d'état disponibles du côté de l'InTask ou de l'OutTask varient ; elles sont décrites et illustrées ci-dessous.

Statut InTask

Une InTask est toujours le point de départ du flux de commandes. Une InTask est créée par l'opérateur actif et contient des ordres de travail pour l'entrepreneur. L'InTask est la seule tâche visible qu'un opérateur actif peut ouvrir à partir de l'aperçu des tâches, tandis que l'opérateur passif peut ouvrir à la fois des InTasks et des OutTasks. L'entrepreneur ne peut ouvrir que les tâches OutTask à partir de la vue d'ensemble des tâches.

Cependant, toutes les parties peuvent voir les statuts InTask et OutTask correspondants lorsqu'elles ouvrent une tâche à partir de la vue d'ensemble.

Nouveau

Il s'agit du statut initial d'une tâche, qui ne peut être vu que par l'opérateur actif lors de la création d'une tâche via l'API.

Contrôle du réseau

Une fois que l'opérateur actif a envoyé une commande, Gridsz recueille toutes les données nécessaires auprès du vérificateur de disponibilité et de l'opérateur actif pour vérifier si la tâche répond aux exigences standard. Si aucun problème n'est détecté, une OutTask est créée et envoyée au contractant.

Reçu

La tâche est acceptée par la plateforme après avoir passé avec succès le contrôle préalable de la propreté de la tâche et reçoit un identifiant unique. La tâche est désormais visible à la fois pour l'opérateur actif (en tant que InTask) et pour le contractant (en tant que OutTask). Le statut Reçu ne sera attribué qu'à l'OutTask, tandis que l'InTask recevra le statut Confirmé.

Confirmé

La contrepartie équivalente de reçu, visible par l'opérateur actif. Ainsi, après avoir passé avec succès le contrôle de propreté de la tâche, l'état de l'InTask sera confirmé, tandis que l'état de l'OutTask sera reçu.

La vérification du réseau a été effectuée avec succès et la date du plan est remplie avec succès. Gridsz vérifie que la tâche peut être exécutée avant de créer une OutTask correspondante, puis envoie une synchronisation pour indiquer que la nouvelle tâche a été reçue avec succès. L'opérateur actif peut maintenant être sûr que la tâche sera exécutée.

Préparé

Le statut Préparé n'est visible que par l'opérateur actif. Il sera activé sur une InTask lorsque toutes les OutTasks auront été confirmées (synchro reçue).

WIP (Work In Progress)

La tâche a été planifiée et est en cours d'exécution par le contractant. Le changement de statut de Reçu à En cours est une mise à jour manuelle. Les accords de niveau de service sont en vigueur.

Livré

Le contractant place l'InTask sur Delivered chaque fois qu'il achève une WIP Task. Dans le cas des incidents de réseau et de connexion, le contractant doit également sélectionner une raison.

Fourni

Le contractant a terminé le travail de la tâche et change le statut de la tâche en Delivered. Le statut de l'InTask apparaîtra comme PROVIDED pour l'AO, jusqu'à ce qu'il soit accepté manuellement. Le statut de la OutTask apparaîtra comme Delivered.

Administration

Pour certains types de tâches, l'administration du réseau doit être mise à jour. Après avoir envoyé (DELIVERED) à l'opérateur actif, et avant d'envoyer la mise à jour au vérificateur de disponibilité, le statut de l'InTask apparaîtra comme Administration pour l'opérateur actif. Pour le contractant, le statut OutTask restera sur Delivered.

A annuler

La demande d'arrêt de la tâche est envoyée par l'opérateur actif. L'opérateur actif doit expliquer pourquoi la tâche doit être annulée. Ce statut permet à l'entrepreneur de déterminer si le travail a déjà été effectué.

Annulé

La demande d'arrêt de la tâche est confirmée par le contractant. La OutTask n'est plus disponible pour l'exécution par le contractant, et l'InTask et la OutTask ont toutes deux le statut "Annulé". L'ANS est également arrêté.

Terminé

Une tâche est refusée par le contractant. Le contractant doit toujours donner une raison pour la tâche terminée, voir les codes de raison dans la liste OutTask ci-dessous. L'InTask et l'OutTask recevront toutes deux le statut Terminé.

Refusé

Le contrôle du réseau propre, tel qu'exécuté par GRIDSZ pour chaque nouvelle commande, a échoué et la nouvelle InTask est réglée sur Denied pour que l'opérateur actif vérifie les données et le raisonnement. En conséquence, GRIDSZ ne créera pas de OutTask, et le contractant ne recevra donc rien.

Statut de la tâche

Les statuts suivants sont utilisés pour les tâches de sortie :

Reçu

L'opérateur actif a créé une nouvelle InTask. L'InTask est disponible pour le contractant et le travail qui doit être effectué pour cette InTask est visible comme une ou plusieurs OutTask pour le contractant, initialement avec le statut Reçu.

Accepté

Il s'agit d'un statut facultatif, disponible uniquement sur demande du propriétaire du réseau, visant à obliger le prestataire à accepter, par exemple, un incident de raccordement. Au lieu d'accepter, le prestataire peut mettre la tâche « en attente » à l'aide d'un code d'attente, indiquant ainsi à l'opérateur la raison pour laquelle la tâche ne peut pas être acceptée. Une fois le statut « Accepté » atteint, la tâche peut être planifiée, c'est-à-dire passer au statut « En cours ». Si le statut « En attente » n'est plus nécessaire, la tâche peut repasser au statut « Accepté » (elle ne repassera pas au statut « Reçue »).

WIP (Work In Progress)

Avant qu'une OutTask puisse être définie comme WIP, la date du plan doit être définie. Après avoir mis une OutTask en WIP, l'ensemble de tâches et l'InTask seront mis à jour en WIP. Dans le cas de plusieurs OutTasks, l'OutTask restante restera en réception jusqu'à ce qu'elle soit placée manuellement en WIP. Le WIP indique à l'opérateur actif que le contractant travaille sur la TASK.

En attente

Dans certains scénarios, une tâche ne peut pas être achevée dans la date de planification spécifiée, pour plusieurs raisons potentielles parmi lesquelles : le client n'est pas chez lui, le PoP / DP est inaccessible ou le chemin technique n'a pas été trouvé. Dans ces cas, le contractant peut définir le statut d'une OutTask comme étant en attente, après quoi le statut de toutes les tâches connexes est défini comme étant en attente (sauf si une tâche a déjà été livrée).

Lorsqu'un ensemble de tâches est mis en attente, l'accord de niveau de service est suspendu et le restera jusqu'à ce que la tâche reprenne son statut précédent, soit reçu, soit en cours. Si nécessaire, le contractant doit mettre à jour la date du plan lorsqu'il reprend la tâche.

Livré

La tâche est exécutée avec succès par le contractant et passe au statut Livré. Ceci n'est valable que pour la OutTask à laquelle le contractant attribue ce statut. Dans le cas d'une OutTask unique, l'ensemble de tâches et l'InTask sont également définis comme étant livrés. Le calcul du SLA s'arrête lorsqu'une OutTask est définie comme livrée.

Résolu

Pour les tâches FTU, le modèle de statut propose un statut « Résolu » facultatif. Le statut « Résolu » est défini par le prestataire pour indiquer que la FTU a été physiquement mise en place (ou remplacée/déplacée/retirée). Un processus automatisé vérifie si la modification a également été correctement mise à jour sur le plan administratif et fait passer le statut de l’OutTask à « Livré ». (Entre-temps, l’OutTaskSet et l’InTask sont déjà mis à l’état « Livré », afin d’informer le client (final) de la nouvelle situation, tandis que les données administratives sont mises à jour.)

Terminer

Le contractant a toujours la possibilité de mettre fin à une tâche. Cependant, il est obligatoire d'en donner la raison. Lorsqu'une tâche OutTask est définie comme Terminée, toutes les tâches connexes sont également définies comme Terminées, à l'exception des tâches qui ont déjà atteint le statut Livré.

À annuler

Le statut "A annuler" ne peut être sélectionné que par l'opérateur actif, lorsqu'une tâche est déjà mise en attente par le contractant.

Ce statut indique au contractant qu'il doit annuler complètement la tâche (Annulée), mais il lui permet également de déterminer si des travaux ont déjà été effectués et doivent être facturés ou enregistrés.

Annulé

Le statut "Annulé" suit toujours le statut "A annuler" et constitue un statut final définitif. Cela signifie qu'une fois qu'un entrepreneur a placé une tâche dans le statut Annulé, toutes les tâches connexes qui doivent encore être achevées suivront le même chemin.

Tâche de filtrage

Dans le portail, il est possible de filtrer les OutTasks et de créer un filtre personnalisé en ajoutant une requête. Le filtrage est possible sur la base de :

• PRIORITÉS
• STATUTS
• TYPES

Débit

Il existe différents statuts possibles pour OutTask. Les plus courants sont les suivants :

• REÇU → TEC → LIVRÉ (Happy flow)
• REÇU → WIP → EN ATTENTE → WIP → LIVRÉ
• REÇU → WIP → TERMINÉ
• REÇU → TERMINÉ
• REÇU → TO_BE_CANCELLED → ANNULÉ
• REÇU → WIP → ON_HOLD → TO_BE_CANCELLED→ ANNULÉ
• REÇU → EN ATTENTE → REÇU → EN COURS DE TRAITEMENT → LIVRÉ

Modèle de statut

Le modèle de statut utilisé pour l'exécution des commandes est présenté ci-dessous.