Exécution et file de travail

Comment le travail est mené — propriété opérationnelle, file de travail à classement dynamique, opérations en masse, affectation tenant compte de la capacité et exécution mobile sur le terrain.

Operational Health Matrix aborde la résolution des problèmes d’exploitation comme un processus géré, et non comme un ensemble de tâches indépendantes.

Après la création d’une Operational Issue, le système construit automatiquement le contexte de travail, détermine la zone d’exploitation responsable, applique la politique SLA correspondante et place l’objet dans la file d’exécution.

Cela garantit un cycle continu de gestion des travaux, depuis la détection du problème jusqu’au rétablissement confirmé de l’état normal de l’équipement.

Modèle d’exécution

Chaque Operational Issue suit un cycle d’exécution unique.

flowchart TD
  A["Détection"] --> B["Operational Issue"]
  B --> C["Propriété opérationnelle"]
  C --> D["Planification"]
  D --> E["Exécution"]
  E --> F["Vérification"]
  F --> G["Clôture"]
  G --> H["Amélioration continue"]

À chaque étape, le système enregistre :

  • le responsable ;
  • les échéances ;
  • l’état ;
  • le journal des modifications ;
  • les Evidence ;
  • les tâches liées ;
  • les articles de la Knowledge Base appliqués ;
  • les résultats de la vérification.

Propriété opérationnelle

La responsabilité est déterminée par la zone d’exploitation, et non par un utilisateur.

Par exemple :

CanonPropriétaire par défaut
no_hourly_archiveIntégration backend
stale_communicationÉquipe communication
battery_lowService terrain
pressure_sensor_stuckMétrologie
firmware_regressionÉquipe firmware
registry_duplicateAdministration du registre

Une fois la zone déterminée, le système affecte un ingénieur précis en fonction :

  • de ses compétences ;
  • de sa charge de travail ;
  • de sa région ;
  • de son planning de travail ;
  • de son backlog courant ;
  • de son niveau d’habilitation.

Si nécessaire, un responsable peut modifier l’affectation manuellement.

File de travail

La file de travail est une vue dynamique des Operational Issues actives.

À la différence d’une liste de tâches classique, la file est construite à partir d’un ensemble de facteurs :

  • la priorité (Priority) ;
  • la gravité (Severity) ;
  • la confiance opérationnelle (Operational Confidence) ;
  • le temps SLA restant ;
  • l’impact métier (Business Impact) ;
  • le nombre d’Assets affectés ;
  • le nombre de réouvertures (Reopen Count) ;
  • le niveau de confiance dans la Root Cause.

Par défaut, les objets les plus critiques remontent automatiquement en tête, quelle que soit leur date de création.

Écran de la file de travail personnelle : les problèmes opérationnels y sont regroupés par état, les éléments en retard étant classés en tête. Écran de la file de travail personnelle : les problèmes opérationnels y sont regroupés par état, les éléments en retard étant classés en tête.
Ma file : d'abord les éléments en retard, puis à prendre / en cours / en attente de confirmation par les données

Catégories de files

OHM prend en charge plusieurs files spécialisées.

Entrantes (Incoming)

Nouveaux problèmes en attente de triage.

Affectées (Assigned)

Problèmes affectés à un ingénieur.

En cours (In Progress)

Travaux actuellement en cours.

En attente de vérification (Awaiting Verification)

Travaux terminés, en attente de confirmation.

En retard (Overdue)

Les exigences SLA sont violées.

Escaladées (Escalated)

Problèmes escaladés automatiquement.

Rouvertes (Reopened)

Problèmes réapparus après la clôture.

Incidents massifs (Massive Incidents)

Incidents d’exploitation systémiques.

Priorisation de la file

Pour le classement, le système utilise une priorité intégrale.

Par exemple :

PriorityScore=wpP+wsS+wbB+wcC+wtTPriorityScore = w_p P + w_s S + w_b B + w_c C + w_t T

  • P — Priority (priorité) ;
  • S — Severity (gravité) ;
  • B — Business Impact (impact métier) ;
  • C — Operational Confidence ;
  • T — temps SLA restant.

Le score obtenu sert exclusivement à trier la file et ne modifie pas la Priority officielle de l’objet.

Opérations en masse

OHM prend en charge les opérations en masse sur un groupe d’Operational Issues.

Par exemple :

  • changer le propriétaire ;
  • changer la zone ;
  • changer le SLA ;
  • affecter une Root Cause commune ;
  • fusionner en un Massive Incident ;
  • appliquer un Knowledge Article ;
  • changer la priorité ;
  • exporter.

Toutes les actions en masse sont consignées dans l’Audit Trail.

Prise en compte de la capacité

L’affectation des travaux tient compte de la charge réelle des services.

Chaque ingénieur est caractérisé par :

  • Active Issues ;
  • Verification Queue ;
  • Planned Work ;
  • Availability ;
  • Current Capacity.

Si la charge dépasse la limite définie, le système recommande une redistribution des travaux.

Répartition de la charge

Le système recourt à un équilibrage pour prévenir la surcharge.

La répartition prend en compte :

  • le nombre d’Issues ouvertes ;
  • la criticité totale ;
  • le temps moyen de résolution ;
  • les compétences ;
  • le rattachement territorial ;
  • l’historique de réalisation de travaux similaires.

Exécution mobile

La version terrain d’OHM fournit à l’ingénieur :

  • la fiche de l’Asset ;
  • l’itinéraire ;
  • l’historique ;
  • les dernières Evidence ;
  • les photographies associées ;
  • les instructions ;
  • les Knowledge Articles ;
  • la possibilité de joindre de nouveaux éléments ;
  • une signature électronique ;
  • la confirmation de réalisation.
Vue du tableau de bord de l'Operations Center au format téléphone, avec la file de l'ingénieur de terrain et le détail de l'Asset. Vue du tableau de bord de l'Operations Center au format téléphone, avec la file de l'ingénieur de terrain et le détail de l'Asset.
Mise en page adaptative : le même Operations Center sur un téléphone

Après synchronisation, l’information devient immédiatement accessible au dispatcheur.

Sujets connexes

Dernière mise à jour le

Cette page vous a-t-elle été utile ?