Tableau de bord/Chapter 8/1.1 — Créer les Service Requests
Chapter 8 · leçon 1 sur 2
CertaviaASSET ou un LOCATION.Service Requests application — Utilisée par les agents de service pour créer et gérer les demandes de service, offrant une vue complète et des outils de traitement.Create Service Request application — Conçue pour les utilisateurs en libre-service afin de soumettre leurs propres demandes, sans intervention directe d'un agent.Self Service module — Contient les applications permettant aux utilisateurs finaux de créer et de suivre leurs demandes de service, comme Create Service Request et View Service Request.View Service Request application — Permet aux utilisateurs en libre-service de suivre le statut de leurs demandes jusqu'à leur achèvement.La gestion des demandes de service dans IBM Maximo Manage 9.x repose sur une architecture flexible qui permet à différents types d'utilisateurs d'interagir avec le système de manière appropriée. Cette architecture distingue clairement les interfaces pour les agents de service et les utilisateurs en libre-service, tout en assurant une intégration fluide des données.
Au cœur de cette architecture se trouve la capacité de Maximo à capturer des informations détaillées sur le service requis, incluant le type de service, le moment où il est nécessaire et la raison de la demande. Cette approche garantit que toutes les parties prenantes ont accès aux informations pertinentes pour une résolution efficace.
Maximo Manage offre plusieurs voies pour initier une demande de service, chacune adaptée à un profil d'utilisateur ou à un scénario d'intégration spécifique. Comprendre ces distinctions est crucial pour optimiser les processus de support et de maintenance.
La flexibilité des méthodes de création permet aux entreprises de s'adapter à diverses exigences opérationnelles, qu'il s'agisse de permettre aux employés de soumettre facilement des problèmes ou d'automatiser la création de tickets à partir de systèmes de surveillance.
| Méthode de création | Application utilisée | Description du rôle de l'utilisateur | Exemple d'utilisation |
|---|---|---|---|
| Manuelle par agent | Service Requests | Utilisée par les agents de service ou des rôles similaires, autorisés à créer et gérer des demandes. | Un agent du service d'assistance enregistre un problème signalé par téléphone. |
| Manuelle par utilisateur en libre-service | Create Service Request | Utilisée par les utilisateurs en libre-service qui peuvent s'enregistrer et créer une demande. | Un employé soumet une demande de réparation pour son ordinateur de bureau. |
| Suivi par utilisateur en libre-service | View Service Request | Permet aux utilisateurs en libre-service de consulter le statut de leurs demandes. | Un employé vérifie l'avancement de la réparation de son équipement. |
| Automatique | Configuration système | Le système est configuré par l'administrateur pour créer des demandes à partir de sources externes. | Une demande de service est générée automatiquement suite à la réception d'un e-mail à une adresse dédiée. |
Le processus de gestion des demandes de service dans Maximo Manage est conçu pour être à la fois efficace et traçable, depuis la soumission initiale jusqu'à la résolution finale. Il implique une série d'étapes qui peuvent varier légèrement en fonction de la méthode de création.
Que la demande soit initiée par un utilisateur en libre-service ou par un agent, l'objectif est de s'assurer que toutes les informations nécessaires sont capturées et que la demande est acheminée vers la bonne équipe pour traitement. L'utilisation de modèles de demande de service peut grandement simplifier cette phase initiale.
ASSET ou un LOCATION.Create Service Request (libre-service), l'application Service Requests (agent), ou automatiquement. L'utilisateur peut choisir un modèle pertinent.ASSET ou du LOCATION sont saisies.COMPLETE ou CLOSED.View Service Request.Par exemple, un utilisateur en libre-service soumet une demande pour une imprimante défectueuse via l'application Create Service Request. Il sélectionne un modèle "Problème Imprimante", renseigne l'ASSETNUM de l'imprimante et une brève description. Cette demande est ensuite acheminée vers un agent du service d'assistance qui la prend en charge via l'application Service Requests, diagnostique le problème, et crée potentiellement un WORKORDER pour un technicien. Une fois le WORKORDER terminé, la demande de service est résolue.
Le cycle de vie d'une demande de service dans Maximo Manage est un processus structuré qui garantit que chaque requête est traitée de manière cohérente et efficace, depuis sa soumission initiale jusqu'à sa clôture. Ce cycle est jalonné de statuts qui reflètent l'état d'avancement de la demande.
La transition entre les statuts est souvent régie par des règles de workflow configurables, permettant une automatisation et une standardisation des processus. La visibilité sur ce cycle de vie est essentielle pour les utilisateurs et les agents afin de suivre la progression et d'assurer la satisfaction du service.
Les candidats peuvent confondre les rôles des applications Service Requests et Create Service Request. Le piège est de croire que l'application Service Requests est destinée aux utilisateurs finaux pour créer leurs propres demandes. En réalité, Service Requests est l'outil principal des agents de service pour gérer et traiter les demandes, tandis que Create Service Request est spécifiquement conçue pour les utilisateurs en libre-service.
Un autre piège courant est de penser que les utilisateurs en libre-service n'ont aucun moyen de suivre l'avancement de leurs demandes une fois soumises. Maximo Manage fournit l'application View Service Request dans le module Self Service, permettant aux utilisateurs de consulter le statut de leurs demandes, de la création à la résolution. Ignorer cette fonctionnalité peut conduire à des réponses incorrectes concernant l'autonomie des utilisateurs finaux.
Il est facile de sous-estimer l'importance des modèles de demande de service. Les candidats pourraient penser qu'ils sont optionnels ou n'apportent qu'un bénéfice marginal. Cependant, les modèles sont cruciaux pour standardiser la collecte d'informations, accélérer la soumission des demandes et améliorer la qualité des données, ce qui facilite grandement le traitement par les agents de service et réduit les erreurs.
Service Requests et l'application Create Service Request dans Maximo Manage ?
L'application Service Requests est utilisée par les agents de service pour gérer et traiter les demandes, tandis que l'application Create Service Request est destinée aux utilisateurs en libre-service pour soumettre leurs propres demandes.
Les utilisateurs en libre-service peuvent suivre le statut de leurs demandes de service en utilisant l'application View Service Request, qui fait partie du module Self Service de Maximo Manage.
Les modèles de demande de service permettent de standardiser les informations collectées, d'accélérer le processus de soumission pour les utilisateurs et de garantir que toutes les données nécessaires sont fournies, ce qui facilite le traitement et la résolution par les agents.
Oui, le système Maximo Manage peut être configuré par un administrateur pour créer automatiquement des demandes de service à partir de sources externes, comme des e-mails ou des alertes de systèmes de surveillance.
Questions d’examen de style IBM. Cliquez une option, puis « Vérifier ma réponse ». Progression enregistrée localement.
Bonne réponse : B
Pourquoi cette question existe — STU §8.1 — la question vérifie que l'association d'un calendrier et d'un shift à un gestionnaire de Service Requests sert à déterminer sa disponibilité future (pour l'assignation ou la planification), et non une condition générique imposée à tous les utilisateurs ou labors. En pratique, ignorer cette finalité fait sous-estimer l'importance de bien renseigner ces champs pour les gestionnaires de tickets.
Le contexte théorique d'abord — Un calendrier et un shift associés à une personne définissent ses plages horaires de travail. Pour un utilisateur gérant des Service Requests, cette information permet à Maximo de déterminer sa disponibilité à une date et heure futures — par exemple pour savoir qui sera présent pour traiter ou se voir assigner un ticket à un moment donné.
Ce que Maximo en fait — version opérationnelle — Dans People ou Person > renseigner le champ Calendar et Shift > lors de l'utilisation du Select Owner dialog ou d'une logique d'assignation automatique de tickets, Maximo consulte ce calendrier/shift pour déterminer si la personne est disponible à la date/heure cible.
Exemple chiffré — Un utilisateur avec un shift de 8h00 à 16h00 apparaîtra disponible pour une assignation prévue à 10h00, mais pas pour une assignation prévue à 19h00, sur les 24 heures de la journée.
Analogie quotidienne — C'est comme consulter les horaires d'ouverture d'un magasin avant de prévoir un rendez-vous : le calendrier/shift indique quand la personne est réellement disponible, pas seulement si elle existe dans le système.
Pourquoi A est faux — Pattern D5 champ-frère : les actions Start Timer/Stop Timer permettent de chronométrer un travail, sans rapport avec le calendrier/shift de disponibilité future.
Pourquoi C est faux — Pattern D4 demi-vérité : tous les utilisateurs n'ont pas nécessairement besoin d'un calendrier/shift ; cette information est surtout pertinente pour ceux dont la disponibilité doit être déterminée pour une assignation.
Pourquoi D est faux — Pattern D4 demi-vérité : si les labors ont effectivement un calendrier/shift, l'affirmation générale « tous » et le contexte (labor vs utilisateur SR) ne correspondent pas à la raison précise demandée par la question.
Bonne réponse : A
Pourquoi cette question existe — STU §8.1 — la question vérifie l'étendue exacte du calcul de la colonne Open Work : elle combine tickets non résolus ET work orders incomplets dont la personne est propriétaire, contrairement à des définitions partielles plausibles (uniquement tickets, ou restriction au work group). En pratique, sous-estimer cette étendue fait mal interpréter la charge réelle affichée pour un propriétaire potentiel lors du choix dans le dialogue.
Le contexte théorique d'abord — La colonne Open Work du dialogue Select Owner agrège, pour chaque personne candidate, le nombre total de tickets non résolus (Service Requests, Incidents, Problems) et de work orders incomplets dont elle est l'owner, donnant ainsi une vue rapide de sa charge de travail actuelle avant de lui assigner un nouveau ticket.
Ce que Maximo en fait — version opérationnelle — Dans Service Requests > action Select Owner > la liste de personnes candidates affiche la colonne Open Work > Maximo calcule le total des tickets non résolus + work orders incomplets où la personne est owner > aide à choisir un propriétaire moins chargé.
Exemple chiffré — Une personne avec 3 tickets non résolus et 5 work orders incomplets affichera un Open Work de 8, contre une autre personne avec seulement 2 work orders incomplets et aucun ticket, affichant un Open Work de 2.
Analogie quotidienne — C'est comme consulter le nombre total de dossiers en cours d'un avocat (dossiers civils + dossiers pénaux confondus) avant de lui confier une nouvelle affaire, plutôt que de ne regarder qu'une seule catégorie de dossiers.
Pourquoi B est faux — Pattern D4 demi-vérité : se limiter aux tickets ignore les work orders incomplets, qui font également partie du calcul de l'Open Work.
Pourquoi C est faux — Pattern D9 quasi-synonyme : restreindre aux work orders et à l'appartenance au work group ne correspond pas à la définition réelle, plus large, incluant les tickets.
Pourquoi D est faux — Pattern D9 quasi-synonyme : élargir aux membres du owner group (pas seulement le propriétaire direct) ne correspond pas non plus à la définition exacte basée sur l'owner individuel et les 2 types de records.
Bonne réponse : A
Pourquoi cette question existe — STU §8.1 — la question vérifie que l'application d'un Ticket Template multi-activités génère des enregistrements de type ACTIVITY (pas des WORKORDER), chacun recevant correctement son Job Plan associé avec ses tâches, par opposition à des comportements plausibles mais erronés (création de WO, ignorance du job plan, perte des tâches). En pratique, mal anticiper ce comportement fait chercher des work orders qui ne sont jamais créés à ce stade.
Le contexte théorique d'abord — Un Ticket Template permet de pré-remplir des informations répétitives sur un ticket. Lorsqu'il référence plusieurs activités, chacune associée à un Job Plan comportant des tâches, l'application du template sur une Service Request génère un ACTIVITY record pour chaque activité, et le Job Plan correspondant (avec ses tâches) est appliqué à cet enregistrement d'activité — sans pour autant créer de Work Order à ce stade.
Ce que Maximo en fait — version opérationnelle — Dans Ticket Templates > définir plusieurs activités, chacune référençant un Job Plan > appliquer le template à une Service Request > Maximo crée un ACTIVITY par activité du template, avec le Job Plan et ses tâches appliqués à chacune.
Exemple chiffré — Un Ticket Template comportant 4 activités, chacune référençant un Job Plan à 3 tâches, génère 4 enregistrements ACTIVITY lors de son application, chacun recevant ses 3 tâches issues du Job Plan correspondant.
Analogie quotidienne — C'est comme cocher plusieurs cases d'un formulaire de demande type qui génère automatiquement une fiche de suivi détaillée pour chaque case cochée, sans pour autant déclencher un bon de commande à ce stade.
Pourquoi B est faux — Pattern D6 mauvaise-app : aucun Work Order n'est créé à l'application du template ; ce sont des ACTIVITY records qui sont générés.
Pourquoi C est faux — Pattern D3 inverse : le Job Plan n'est pas ignoré ; il est bien appliqué à chaque ACTIVITY créée.
Pourquoi D est faux — Pattern D4 demi-vérité : le Job Plan est appliqué avec ses tâches, qui ne sont donc pas omises contrairement à ce que cette option affirme.
Bonne réponse : B
Pourquoi cette question existe — STU §8.1 — la question vérifie la cause exacte d'une apparition multiple d'une même personne dans le dialogue Select Owner : son appartenance à plusieurs Person Groups, par opposition à des facteurs réels (multi-organisation, multi-site, rotation de shift) qui n'entraînent pas cette duplication dans ce dialogue spécifique. En pratique, confondre ces causes fait mal diagnostiquer une liste de propriétaires potentiels qui semble redondante.
Le contexte théorique d'abord — Une personne peut être ajoutée à plusieurs Person Groups distincts (même au sein du même site/organisation). Le dialogue Select Owner liste les candidats par appartenance à un Person Group pertinent ; si une personne appartient à 2 ou 3 Person Groups éligibles, elle apparaît une fois par groupe, créant des entrées dupliquées dans la liste.
Ce que Maximo en fait — version opérationnelle — Dans People > Person Groups > ajouter une même personne à plusieurs groupes (table window People, possible plusieurs fois au même niveau) > lors de l'utilisation de Select Owner sur une Service Request, chaque appartenance à un groupe éligible génère une ligne distincte pour cette même personne.
Exemple chiffré — Une personne appartenant à 3 Person Groups éligibles pour un ticket donné apparaîtra 3 fois dans le dialogue Select Owner, sur une liste totale pouvant compter 15 lignes pour 10 personnes distinctes.
Analogie quotidienne — C'est comme un annuaire qui liste un employé sous chacune des équipes auxquelles il est rattaché : s'il appartient à 3 équipes, son nom apparaît 3 fois, une fois par équipe.
Pourquoi A est faux — Pattern D5 champ-frère : travailler dans plusieurs organisations est une réalité possible, mais ce n'est pas la cause documentée de duplication dans ce dialogue précis.
Pourquoi C est faux — Pattern D5 champ-frère : être autorisé sur plusieurs sites concerne l'accès aux données, sans causer de duplication dans la liste des propriétaires potentiels.
Pourquoi D est faux — Pattern D5 champ-frère : la rotation de shift modifie la disponibilité dans le temps, mais ne génère pas plusieurs lignes pour la même personne dans Select Owner.