Tableau de bord/Chapter 8/1.2 — Configurer les Service Level Agreements (SLA)
Chapter 8 · leçon 2 sur 2
L'architecture des Service Level Agreements dans Maximo Manage est conçue pour structurer et formaliser les engagements de service entre les parties prenantes. Au cœur de cette architecture se trouve l'application `Service Level Agreements`, qui permet de définir les paramètres, les services et les engagements spécifiques à chaque accord. Ces SLA sont ensuite intégrés aux processus opérationnels via leur application aux `tickets` et aux `work orders`.
La flexibilité du système permet également d'établir des relations hiérarchiques entre les SLA, avec des SLA `parent` et `child`. Cette structure assure une gestion cohérente des dépendances et des interconnexions entre différents niveaux de service, garantissant que la conformité d'un SLA principal est supportée par la conformité de ses SLA subordonnés.
Les Service Level Agreements dans Maximo Manage sont composés de plusieurs éléments fondamentaux qui définissent leur portée, leurs exigences et leur mode de fonctionnement. Ce tableau récapitule les principaux composants et leur rôle.
| Composant | Description | Rôle dans le SLA |
|---|---|---|
Service Level Agreements | L'accord formel entre fournisseur et client. | Documente les attentes et les obligations de service. |
| Services | Les tâches ou prestations que le fournisseur s'engage à réaliser. | Définissent l'étendue fonctionnelle du SLA. |
Commitments | Les responsabilités et les niveaux de performance que le fournisseur doit respecter. | Spécifient les métriques et les objectifs de qualité/temps. |
| SLA `Parent` | Un SLA principal dont la conformité dépend d'autres SLA. | Gère la conformité globale en fonction de SLA subordonnés. |
| SLA `Child` | Un SLA de support qui contribue à la conformité d'un SLA `parent`. | Assure le respect des exigences spécifiques nécessaires au SLA principal. |
| `Tickets` | Enregistrements de demandes de service ou d'incidents. | Cible d'application des SLA pour garantir les délais de réponse/résolution. |
| `Work Orders` | Ordres de travail pour la maintenance ou d'autres opérations. | Cible d'application des SLA pour garantir les délais d'exécution. |
La configuration des Service Level Agreements est une étape cruciale pour l'efficacité de la gestion des services dans Maximo Manage. Elle s'effectue principalement via le module `Service Level` et l'application `Service Level Agreements`. Cette application est le point central pour définir les termes de l'accord, les services inclus et les engagements associés.
Lors de la création d'un SLA, il est possible de spécifier une description détaillée, ce qui est essentiel pour la clarté et la compréhension de l'accord. Une fois défini, un SLA peut être appliqué à divers enregistrements opérationnels, tels que les `tickets` et les `work orders`, afin d'assurer que les opérations quotidiennes respectent les niveaux de service convenus. La configuration des options de SLA au niveau du site permet également d'adapter la manière dont les SLA sont mis en correspondance avec les enregistrements, offrant une flexibilité pour les organisations multi-sites.
Certaviacommitments) que le fournisseur doit respecter, comme les temps de réponse ou de résolution.Le cycle de vie d'un Service Level Agreement dans Maximo Manage débute par sa création et sa définition, passe par son activation et son application aux processus opérationnels, et se termine par sa révision ou son obsolescence. Chaque étape est cruciale pour maintenir la pertinence et l'efficacité des accords de service.
La gestion des SLA est un processus continu qui implique la surveillance des performances par rapport aux engagements, l'ajustement des termes si nécessaire, et la gestion des relations hiérarchiques entre les SLA. La capacité de Maximo à valider les engagements lors de l'association des SLA est fondamentale pour prévenir les incohérences et assurer la cohérence des niveaux de service.
Les candidats peuvent sous-estimer l'importance de la validation des engagements lors de l'association de SLA, notamment dans les structures `parent`/`child`. Maximo vérifie les engagements des SLA que vous tentez d'associer et vous notifie en cas de conflits. Un piège courant serait de croire que le système résout automatiquement les conflits ou qu'il suffit d'associer les SLA sans vérification. En réalité, une attention particulière doit être portée à la cohérence des engagements pour éviter des attentes irréalistes ou des non-conformités.
Un piège fréquent est de créer des SLA détaillés et bien définis, mais d'omettre de les appliquer explicitement aux `tickets` et `work orders` pertinents. Un SLA n'a d'impact opérationnel que s'il est lié à un enregistrement. L'examen peut présenter un scénario où un SLA est configuré mais les performances ne sont pas mesurées, la cause étant l'absence d'application du SLA à l'enregistrement cible. Il est impératif d'ouvrir l'application appropriée, d'afficher l'enregistrement, puis d'appliquer le SLA pour qu'il prenne effet.
Les termes "Services" et "Engagements" (`Commitments`) sont distincts dans le contexte des SLA Maximo. Les "Services" décrivent les tâches que les fournisseurs accomplissent pour répondre aux besoins des clients. Les "Engagements" sont les responsabilités que les fournisseurs doivent respecter pour satisfaire les SLA. Un piège serait de les considérer comme interchangeables ou de ne pas comprendre leur rôle spécifique. Par exemple, un service pourrait être "Réparation d'équipement", tandis qu'un engagement serait "Temps de réponse de 4 heures pour les réparations critiques".
Le module `Service Level` est utilisé pour créer et gérer les Service Level Agreements (SLA), qui documentent les engagements entre les fournisseurs de services et les clients. Il permet également de créer des groupes de services pour organiser les types de services fournis ou acquis.
Un SLA `parent` est un SLA spécifique dont la conformité dépend de la conformité d'autres SLA, appelés SLA `child`. Les SLA `child` sont des SLA de support nécessaires pour maintenir le SLA `parent` en conformité. Lors de l'association, Maximo valide les engagements pour détecter les conflits.
Les Service Level Agreements peuvent être appliqués aux `tickets` (demandes de service, incidents) et aux `work orders` (ordres de travail). Pour ce faire, il faut ouvrir l'application concernée, afficher l'enregistrement cible, puis appliquer le SLA.
Bonne réponse : B, D
Pourquoi cette question existe — STU §8.2 — la question vérifie les 2 finalités exactes des champs Service Group et Service sur la page principale de SLA : supporter le reporting de Service Management et matcher contre le ticket/work order, par opposition à des usages plausibles mais relevant d'autres mécanismes (Promised Delivery Date sur PR/PO, auto-application via Associate Services, contrats VENDOR). En pratique, confondre ces finalités fait chercher la logique de matching SLA dans le mauvais module.
Le contexte théorique d'abord — Les champs Service Group et Service sur la page principale d'une SLA servent à deux fins : (1) supporter le reporting de Service Management, en catégorisant les SLA selon le type de service couvert ; (2) servir de critère de matching contre les valeurs équivalentes du ticket ou du work order auquel la SLA pourrait s'appliquer — le Service Group/Service du ticket doit correspondre à celui de la SLA pour qu'elle soit applicable.
Ce que Maximo en fait — version opérationnelle — Dans Service Level Agreements > renseigner Service Group et Service sur la SLA > lors de l'application automatique ou manuelle d'une SLA à un ticket/WO, Maximo compare ces valeurs à celles du record cible > en cas de correspondance (ou valeur null compatible), la SLA est jugée applicable.
Exemple chiffré — Sur 50 SLA actives classées par Service Group, un rapport de Service Management peut filtrer et afficher les 12 SLA appartenant au Service Group « Réseau », tout en utilisant ce même champ pour valider la correspondance avec 200 tickets entrants.
Analogie quotidienne — C'est comme étiqueter des contrats d'assurance par catégorie de risque : l'étiquette sert à la fois à produire des rapports par catégorie et à vérifier qu'un sinistre déclaré correspond bien à la catégorie couverte par le contrat.
Pourquoi A est faux — Pattern D5 champ-frère : le calcul de la Promised Delivery Date sur une ligne PR/PO relève des commodity codes de service, un mécanisme distinct des champs Service Group/Service de la SLA elle-même.
Pourquoi C est faux — Pattern D5 champ-frère : l'auto-application via Associate Services dans Asset/Locations est un mécanisme d'association distinct, pas la finalité des champs Service Group/Service sur la page principale SLA.
Pourquoi E est faux — Pattern D5 champ-frère : l'usage avec les SLA de type VENDOR et Associate Contracts concerne la recherche de contrats par commodity codes, un cas d'usage distinct du matching ticket/WO.
Bonne réponse : B
Pourquoi cette question existe — STU §8.2 — la question vérifie la terminologie exacte des 3 types de commitment SLA qui déclenchent un calcul de date : CONTACT, RESPONSE, RESOLUTION, par opposition à des champs cibles réels (TARGSTART, TARGCOMP) qui sont le résultat du calcul plutôt que le type de commitment, et à des libellés inventés ou des catégories de priorité sans rapport. En pratique, confondre le type de commitment et le champ de date résultant fait mal paramétrer une SLA.
Le contexte théorique d'abord — Une SLA peut inclure des commitments de type CONTACT, RESPONSE et RESOLUTION. Chacun de ces types, lorsqu'il est appliqué à un ticket ou work order, calcule une date : le commitment RESPONSE alimente le champ Target Start du record, et le commitment RESOLUTION alimente le champ Target Finish.
Ce que Maximo en fait — version opérationnelle — Dans Service Level Agreements > onglet Commitments > ajouter un commitment de type RESPONSE ou RESOLUTION avec sa durée > lors de l'application de la SLA à un ticket > Maximo calcule et renseigne automatiquement Target Start (depuis RESPONSE) et Target Finish (depuis RESOLUTION) sur le record.
Exemple chiffré — Une SLA avec un commitment RESPONSE de 2 heures et un commitment RESOLUTION de 24 heures, appliquée à un ticket signalé à 9h00, calcule un Target Start à 11h00 et un Target Finish au lendemain à 9h00, soit 2 dates calculées distinctement sur les 3 types de commitment possibles.
Analogie quotidienne — C'est comme un contrat de service de réparation qui promet un premier contact en 2 heures et une résolution complète en 24 heures : ces 2 engagements génèrent chacun une échéance calculée dans l'agenda.
Pourquoi A est faux — Pattern D9 quasi-synonyme : TARGSTART et TARGCOMP sont les champs de date résultants (les cibles calculées), pas les types de commitment qui déclenchent le calcul.
Pourquoi C est faux — Pattern D2 inventé : « DELIVERY, RESPOND, RESOLVE » ne sont pas les libellés officiels des types de commitment dans Maximo.
Pourquoi D est faux — Pattern D5 champ-frère : CRITICAL, URGENT, ROUTINE, BACKLOG sont des niveaux de priorité, pas des types de commitment SLA calculant une date.
Bonne réponse : D
Pourquoi cette question existe — STU §8.2 — la question vérifie le nom exact du calendrier utilisé dans le processus de matching/application d'une SLA à un ticket/work order : l'Applies To Calendar, par opposition à des libellés plausibles mais inventés (Person Calendar, Ticket WO Calendar, Calculation Calendar). En pratique, ce calendrier détermine si la SLA est même applicable selon l'heure de signalement du record.
Le contexte théorique d'abord — L'Applies To Calendar est le calendrier (avec son shift) défini sur la SLA qui détermine si la date de signalement (reported date) du ticket ou work order tombe dans les heures couvertes par la SLA. Si la date signalée ne correspond pas aux heures de l'Applies To Calendar, la SLA n'est tout simplement pas applicable au record.
Ce que Maximo en fait — version opérationnelle — Dans Service Level Agreements > configurer l'Applies To Calendar et son shift > lors de l'application de la SLA (manuelle ou automatique) sur un ticket/WO > Maximo compare la date signalée du record aux heures définies dans ce calendrier > en dehors de ces heures, la SLA n'est pas considérée applicable.
Exemple chiffré — Pour un Applies To Calendar couvrant 8h00 à 17h00, un ticket signalé à 16h50 sera dans la plage et la SLA s'appliquera, alors qu'un ticket signalé à 17h10, soit 20 minutes après la fermeture des 9 heures couvertes par jour, ne verra pas la SLA s'appliquer.
Analogie quotidienne — C'est comme un service d'assistance téléphonique qui ne prend en compte une demande pour le calcul de son engagement de réponse que si elle est reçue pendant les heures d'ouverture affichées.
Pourquoi A est faux — Pattern D2 inventé : « Person Calendar » n'est pas le nom du calendrier utilisé dans ce processus de matching SLA.
Pourquoi B est faux — Pattern D2 inventé : « Ticket WO Calendar » n'est pas une terminologie Maximo officielle pour ce mécanisme.
Pourquoi C est faux — Pattern D2 inventé : « Calculation Calendar » n'existe pas en tant que tel dans la configuration des SLA.
Bonne réponse : A, C
Pourquoi cette question existe — STU §8.2 — variante de reformulation (options réordonnées) de la question jumelle de cette leçon, testant la même paire de finalités des champs Service Group/Service : reporting et matching contre le ticket/work order, par opposition aux mécanismes distincts évoqués dans les distracteurs (Associate Services, Promised Delivery Date, contrats VENDOR).
Le contexte théorique d'abord — Les champs Service Group et Service sur la page principale d'une SLA servent à supporter le reporting de Service Management (catégorisation des SLA) et à servir de critère de matching contre les valeurs équivalentes du ticket/work order cible, déterminant l'applicabilité de la SLA.
Ce que Maximo en fait — version opérationnelle — Dans Service Level Agreements > renseigner Service Group et Service > lors de l'application d'une SLA à un ticket/WO, Maximo compare ces valeurs à celles du record cible > en cas de correspondance, la SLA est jugée applicable et peut alimenter des rapports filtrés par ces mêmes champs.
Exemple chiffré — Sur 50 SLA actives classées par Service Group, un rapport de Service Management peut filtrer et afficher les 12 SLA appartenant au Service Group « Réseau », tout en utilisant ce même champ pour valider la correspondance avec 200 tickets entrants.
Analogie quotidienne — C'est comme étiqueter des contrats d'assurance par catégorie de risque : l'étiquette sert à la fois à produire des rapports par catégorie et à vérifier qu'un sinistre déclaré correspond bien à la catégorie couverte.
Pourquoi B est faux — Pattern D5 champ-frère : l'auto-application via Associate Services dans Assets/Locations est un mécanisme d'association distinct, pas la finalité de ces champs sur la page principale SLA.
Pourquoi D est faux — Pattern D5 champ-frère : le calcul de la Promised Delivery Date sur une ligne PR/PO relève des commodity codes de service, un mécanisme distinct.
Pourquoi E est faux — Pattern D5 champ-frère : l'usage avec les SLA VENDOR et Associate Contracts concerne la recherche de contrats par commodity codes, un cas d'usage distinct du matching ticket/WO.