Priorités, SLA et escalade

Priorité, gravité et impact métier

Gravité (Severity)

La Severity traduit la gravité technique de l’état courant.

Priorité (Priority)

La Priority traduit l’ordre d’exécution des travaux.

Severity et Priority ne se confondent pas.

Par exemple, une Issue peut porter Severity = High avec Priority = P3.

Ce cas est possible lorsque le problème est techniquement grave mais concerne un Asset de secours, sans impact actuel sur l’exploitation.

Score d’impact (Impact Score)

Un score global peut être utilisé pour le classement :

où :

• $S$ — la gravité ;
• $B$ — l’impact métier ;
• $A$ — le nombre ou la criticité des Assets affectés ;
• $R$ — le risque de sécurité ou réglementaire ;
• $D$ — la durée.

Impact métier (Business Impact)

OHM prend en charge des champs d’impact structurés :

• le nombre d’appareils affectés ;
• le nombre de consommateurs ou de sites ;
• le volume de gaz exposé au risque ;
• la durée de la dégradation ;
• la perte de données potentielle ;
• le risque de comptage commercial erroné ;
• le risque d’une intervention sur site ;
• le risque de non-respect du SLA ;
• le risque de sécurité de l’information ;
• le coût de l’indisponibilité ;
• le niveau d’impact réputationnel.

Gestion du niveau de service (SLA)

OHM met en œuvre un modèle complet de gestion des SLA.

Le contrôle ne porte pas seulement sur la résolution d’un problème, mais sur l’ensemble de son cycle de traitement.

flowchart TD
  A["Issue créée"] --> B["Response SLA"]
  B --> C["Acknowledgement SLA"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]

Chaque étape possède ses propres règles de calcul.

Politique SLA

La politique SLA définit :

• le temps de réponse admissible ;
• le délai de prise en compte ;
• le délai de résolution ;
• le délai de vérification ;
• les règles d’escalade ;
• le calendrier de travail ;
• les exceptions.

Le SLA est attribué automatiquement en fonction du Canon, de la criticité et de la catégorie de l’objet.

Calendriers de travail

Le système prend en charge :

• 24×7 ;
• 12×7 ;
• les jours ouvrés ;
• les calendriers régionaux ;
• les jours fériés ;
• les horaires propres à chaque service.

Le temps situé hors du calendrier de travail n’est pas comptabilisé, sauf si la politique SLA exige une réponse en continu.

Compteurs SLA

Pour chaque Issue, le système calcule simultanément plusieurs compteurs indépendants.

Par exemple :

• Time To Response ;
• Time To Acknowledge ;
• Time To Resolve ;
• Time To Verify ;
• Time To Close.

Chaque compteur peut avoir ses propres règles d’arrêt.

Conditions de mise en pause

Le décompte du SLA peut être suspendu.

Par exemple :

• attente d’un fournisseur ;
• attente d’un accès ;
• attente d’une autorisation ;
• restrictions saisonnières ;
• force majeure.

Le motif de la mise en pause est obligatoirement consigné.

Violation du SLA

En cas de violation du SLA, le système effectue automatiquement les actions suivantes :

• modification de l’état ;
• augmentation du niveau de risque ;
• déclenchement de l’Escalation Engine ;
• création d’une entrée d’audit ;
• répercussion de la violation sur les KPI.

Mécanisme d’escalade (Escalation Engine)

L’Escalation Engine transmet automatiquement un problème à un niveau de responsabilité supérieur lorsque les conditions définies ne sont plus respectées.

L’escalade ne dépend pas des actions de l’utilisateur et s’exécute automatiquement.

Niveaux d’escalade

Scénario type :

flowchart TD
  P1["P1"] -->|"15 minutes"| L1["Chef de quart"]
  L1 -->|"1 heure"| L2["Responsable régional"]
  L2 -->|"4 heures"| L3["Directeur de l'exploitation"]

Les intervalles précis sont définis par la politique de l’organisation.

Déclencheurs d’escalade

L’escalade peut être déclenchée par :

• une violation du Response SLA ;
• une violation du Resolution SLA ;
• l’absence d’intervenant affecté ;
• l’absence de prise en compte ;
• une réouverture ;
• une ampleur massive ;
• un Business Impact élevé.

Actions d’escalade

Lorsqu’une condition est remplie, le système peut :

• avertir le responsable ;
• changer le propriétaire ;
• relever la Priority ;
• créer un Massive Incident ;
• créer un ticket externe ;
• avertir la direction générale ;
• lancer une analyse complémentaire.

Toutes les actions sont intégralement journalisées.

Historique des escalades

La fiche de l’Issue contient un journal complet :

L’historique n’est jamais supprimé et entre dans le calcul des KPI opérationnels.