Créer et gérer Labor, Crafts et Crews

Bonne réponse : B

Pourquoi cette question existe — STU §3.5 — la question vérifie le type d'enregistrement exact utilisable comme outil requis dans un Crew Type, parmi des variantes proches mais incorrectes (Rotating/Non-Rotating Tools n'étant pas les noms d'enregistrement réels). En pratique, mal identifier ce type bloque la création d'un Crew Type complet.

Le contexte théorique d'abord — Un Crew Type est composé des positions requises, qualifications et outils nécessaires à une intervention type. Les outils référencés comme Required Tools sont des enregistrements Tool Assets — des actifs de catégorie outil suivis individuellement, distincts des items consommables.

Ce que Maximo en fait — version opérationnelle — Dans Crews ou Crew Types, l'onglet des outils requis permet de rechercher et ajouter des Tool Assets existants ; lors de l'assignation graphique (Graphical Crew Management), les ressources outils disponibles correspondant au Crew Type s'affichent dans le tableau de ressources.

Exemple chiffré — Un Crew Type « Électricien Sénior » requérant 2 outils spécialisés (multimètre, caméra thermique) référence 2 Tool Assets précis sur les 15 disponibles au magasin, traçables individuellement sur chaque intervention.

Analogie quotidienne — C'est comme la liste d'équipement obligatoire d'une caisse à outils nominative : chaque outil (Tool Asset) est identifié individuellement, pas juste « un marteau » générique.

Pourquoi A est faux — Pattern D9 quasi-synonyme : « Non-Rotating Tools » n'est pas le nom d'un type d'enregistrement référencé dans les Required Tools d'un Crew.

Pourquoi C est faux — Pattern D5 champ-frère : les Leased Assets sont des actifs en location, une notion distincte des outils requis pour un Crew Type.

Pourquoi D est faux — Pattern D9 quasi-synonyme : « Rotating Tools » évoque les items rotatifs de l'inventaire, pas les Tool Assets référencés dans les Crew Types.

Bonne réponse : C

Pourquoi cette question existe — STU §3.5 — la question vérifie la terminologie exacte des types de taux disponibles pour les Premium Pay Codes d'un Craft, un vocabulaire technique précis facilement confondu avec des synonymes plausibles. En pratique, choisir le mauvais rate type fausse le calcul des heures supplémentaires/primes.

Le contexte théorique d'abord — Dans Crafts, chaque craft peut définir des niveaux de compétence, un taux standard, et des Premium Pay Codes représentant des majorations (heures de nuit, jours fériés, etc.). Le type de taux Increment permet d'exprimer la prime comme un incrément ajouté au taux de base, plutôt qu'un pourcentage ou un montant fixe.

Ce que Maximo en fait — version opérationnelle — Dans Crafts > sélectionner un craft > onglet des Premium Pay Codes > créer un code > champ Rate Type = Increment > définir la valeur d'incrément appliquée au taux standard du craft pour les heures concernées.

Exemple chiffré — Un craft avec un taux standard de 35 $/h et un Premium Pay Code de type Increment à +10 $/h facture 45 $/h pour les heures couvertes par ce code, contre 35 $/h en heures normales.

Analogie quotidienne — C'est comme une prime de nuit ajoutée en valeur fixe au salaire horaire de base, plutôt qu'un pourcentage variable du salaire.

Pourquoi A est faux — Pattern D9 quasi-synonyme : « Additional » n'est pas le nom officiel du rate type ; le terme technique réel est Increment.

Pourquoi B est faux — Pattern D5 champ-frère : « Holiday » décrit un contexte d'application de la prime, pas un type de taux.

Pourquoi D est faux — Pattern D9 quasi-synonyme : « Supplemental » est un terme proche en sens commun mais n'est pas la valeur officielle du champ Rate Type.

Bonne réponse : B

Pourquoi cette question existe — STU §3.5 — la question vérifie le lien entre Calendars/Shifts (configurés en module 3) et leur usage concret sur les enregistrements Labor. Les distracteurs proposent des effets plausibles mais erronés (taux horaire, segmentation de site, certification) qui appartiennent à d'autres champs du Labor record. En pratique, l'omission de calendrier/shift sur un labor fausse directement la disponibilité affichée en Scheduling.

Le contexte théorique d'abord — Un Calendar définit les jours/heures ouvrés, et un Shift précise la plage horaire applicable. Assignés à un enregistrement Labor, ils permettent à Maximo de déterminer quand cette ressource est disponible pour être affectée à du travail, exactement comme pour les enregistrements Person utilisés en Service Requests.

Ce que Maximo en fait — version opérationnelle — Dans Labor > onglet général, les champs Calendar et Shift sont renseignés par craft/crew. Le Graphical Scheduling et le Scheduler Data Manager consultent ensuite ces champs pour calculer les fenêtres de disponibilité avant d'assigner une tâche.

Exemple chiffré — Un labor sur un shift de jour (7h-15h, lundi-vendredi) apparaît disponible 40h/semaine dans le Graphical Scheduling, contre 0h le week-end, ce qui empêche toute assignation automatique un samedi.

Analogie quotidienne — C'est comme l'agenda partagé d'un collègue : sans ses heures de disponibilité renseignées, personne ne peut savoir quand le solliciter pour une réunion (ou une tâche).

Pourquoi A est faux — Pattern D5 champ-frère : le taux horaire est défini via les Craft Rates / Pay Codes, pas via le Calendar ou le Shift.

Pourquoi C est faux — Pattern D6 mauvaise-app : la segmentation par site d'un labor dépend du champ Site du Labor record, pas du calendrier assigné.

Pourquoi D est faux — Pattern D2 inventé : aucune fonctionnalité Maximo ne génère une certification de craft à partir d'un calendrier.