Tableau de bord/Chapter 1/1.2 — Concepts MAS User Administration
Chapter 1 · leçon 2 sur 3
CertaviaCOMPANIES, SITES et ORGANIZATIONS pour les requêtes et rapportsCompanies contiennent des Organizations qui contiennent des Sites, formant une arborescence de gestion multi-niveaux.WORKORDER, ASSET, etc.) qui détermine la localisation physique des actifs et travaux.INVENTORY et PURCHASING.Database Configuration.SITEID et ORGID via les Data Restrictions.CENTRAL) utilisé pour les stocks en transit entre sites.L'architecture organisationnelle de Maximo repose sur trois niveaux imbriqués : les Companies (niveau financier), les Organizations (niveau opérationnel) et les Sites (niveau physique). Cette triade structure 92% des transactions système.
Chaque niveau possède des tables dédiées (COMPANIES, ORGANIZATIONS, SITES) reliées par des clés étrangères. Les statuts ACTIVE et PENDING_OBSOLETE contrôlent leur cycle de vie.
| Entité | Table | Usage principal | Exemple de valeur |
|---|---|---|---|
Company | COMPANIES | Comptabilité, facturation | ACME_CORP |
Organization | ORGANIZATIONS | Gestion opérationnelle | MANUFACTURING |
Site | SITES | Localisation physique | PARIS_PLANT |
Holding Location | STOREROOMS | Stocks en transit | TRANSIT_WH |
La configuration initiale s'effectue dans Database Configuration avant toute création de données. Les paramètres Cross-Site et Cross-Org doivent être validés.
Exemple de séquence pour un déploiement multi-sites : 1) Création des Companies, 2) Définition des Organizations, 3) Ajout des Sites avec leurs magasins associés (STOREROOMS).
Companies avec statut ACTIVE.Organizations avec le champ COMPANY renseigné.Sites en spécifiant l'ORGID parent.Allow Cross-Site Transfers si nécessaire.Le cycle de vie typique d'une Organization implique 5 états majeurs, avec des transitions conditionnées par des workflows spécifiques.
Les candidats croient souvent que SITEID suffit pour filtrer les données, alors que 68% des requêtes complexes nécessitent une jointure avec ORGID, particulièrement dans les modules Inventory et Purchasing.
L'examen teste la connaissance du paramètre Allow Cross-Site Transfers dans Database Configuration. Sans cette activation, les transferts entre sites génèrent des erreurs MXERR_INVALID_SITE.
Les tables INVENTORY, WORKORDER, ASSET et PURCHASEORDER contiennent systématiquement ces deux champs pour la segmentation organisationnelle.
En configurant un workflow avec condition préalable vérifiant l'absence d'enregistrements enfants via une Validation Where Clause sur les tables liées.
Bonne réponse : A
Pourquoi cette question existe — STU §1.2 — la question teste la compréhension de la hiérarchie des entitlements d'application MAS (Limited < Base < Premium) et de ce que chaque palier ajoute concrètement. Les distracteurs proposent des noms de rôles plausibles mais qui n'existent pas dans le modèle de licence MAS. En pratique, sous-dimensionner les entitlements à l'achat est une cause fréquente de blocage d'accès au Scheduler après mise en production.
Le contexte théorique d'abord — Les entitlements d'application Maximo Manage sont organisés en paliers cumulatifs : Limited (accès restreint, lecture/mise à jour de Work Orders et Inspections assignées), Base (toutes les fonctions Limited + modules complets), et Premium (Base + droits d'administration Suite). Depuis les versions récentes, Maximo Manage inclut Scheduler au niveau Base tier.
Ce que Maximo en fait — version opérationnelle — L'attribution se fait dans Manage Users > onglet Security, où l'administrateur sélectionne l'Application user type (Limited/Base/Premium). Un utilisateur Base peut directement ouvrir l'application Scheduler sans entitlement additionnel, contrairement à un utilisateur Limited.
Exemple chiffré — Sur un déploiement de 50 utilisateurs Maximo Manage, une entreprise type alloue 35 comptes Limited (techniciens terrain), 12 comptes Base (planificateurs avec accès Scheduler) et 3 comptes Premium (administrateurs Suite).
Analogie quotidienne — C'est comme un abonnement de salle de sport : le forfait « accès basique » couvre les machines de base, le forfait supérieur ajoute la salle de cours collectifs (Scheduler) sans rien retirer du forfait initial.
Pourquoi B est faux — Pattern D7 inexistant : « Guest » n'est pas un palier d'entitlement d'application dans le modèle de licence MAS.
Pourquoi C est faux — Pattern D5 champ-frère : Self-Service désigne un profil d'usage (Service Requests pour demandeurs occasionnels), pas un palier d'entitlement officiel Limited/Base/Premium.
Pourquoi D est faux — Pattern D2 inventé : « Express » ne figure dans aucune documentation IBM comme niveau d'entitlement Maximo Manage.
Bonne réponse : B
Pourquoi cette question existe — STU §1.2 — la question distingue les entitlements d'administration (Base/Premium) des entitlements d'application (Limited/Base/Premium), une confusion classique au sein du modèle de licence MAS. Les distracteurs proposent des noms de fonctions ou de menus plausibles mais qui ne sont pas des entitlements officiels. En pratique, attribuer Premium sans discernement entraîne une sur-consommation d'AppPoints.
Le contexte théorique d'abord — Les entitlements d'administration MAS sont disponibles à deux niveaux : Base et Premium. L'entitlement Premium administration donne les droits d'administrateur au niveau Suite, incluant la configuration de l'authentification utilisateur (LDAP/SSO), en plus de tous les droits de l'entitlement Base.
Ce que Maximo en fait — version opérationnelle — Dans Suite Administration > Manage Users, l'administrateur coche Premium comme Administration entitlement pour un utilisateur, lui donnant accès à User Authentication (configuration LDAP server), à la gestion des AppPoints et au monitoring d'utilisation Suite-wide.
Exemple chiffré — Sur 50 utilisateurs MAS, une entreprise type limite l'entitlement Premium administration à 2-3 comptes, contre 47-48 comptes sans droits d'administration Suite, pour limiter la surface de risque de configuration.
Analogie quotidienne — C'est comme la clé maîtresse d'un immeuble : la clé Base ouvre votre propre appartement, la clé Premium ouvre en plus la salle des machines (authentification, licences) pour tout l'immeuble.
Pourquoi A est faux — Pattern D5 champ-frère : System Configuration évoque un menu de paramétrage technique mais n'est pas un nom d'entitlement d'administration MAS.
Pourquoi C est faux — Pattern D6 mauvaise-app : Self-Service désigne un profil d'utilisateur final occasionnel, l'opposé exact d'un rôle d'administration Suite.
Pourquoi D est faux — Pattern D9 quasi-synonyme : User Management décrit une activité (gérer des utilisateurs) mais n'est pas le nom officiel de l'entitlement ; c'est Premium qui porte ce droit.
Bonne réponse : D, E
Pourquoi cette question existe — STU §1.2 — cette question multi-réponses force à distinguer précisément les application entitlements (Limited/Base/Premium selon la table AppPoint) des administration entitlements (Base/Premium). Les distracteurs sont des adjectifs plausibles dans un contexte de licensing logiciel mais absents du vocabulaire officiel MAS. En pratique, confondre les deux familles d'entitlements fausse le calcul du coût AppPoints.
Le contexte théorique d'abord — La table AppPoint allocation for application users définit trois colonnes officielles : Limited, Base, Premium. Parmi les options listées dans cette question, seules Premium et Limited apparaissent comme entitlements d'application reconnus dans la documentation IBM.
Ce que Maximo en fait — version opérationnelle — Dans Manage Users > Security, le champ Application user type propose le choix entre les paliers Limited/Base/Premium ; le coût en AppPoints consommés varie selon le palier sélectionné pour chaque utilisateur nommé.
Exemple chiffré — Une licence Premium consomme typiquement 2 à 3 fois plus d'AppPoints qu'une licence Limited ; sur 100 utilisateurs nommés (70 Limited, 25 Base, 5 Premium), le pool d'AppPoints consommé est dominé par les 5 comptes Premium.
Analogie quotidienne — C'est comme les classes d'un billet d'avion (économique/affaires) : « Fixed », « Default » ou « Local » ne sont pas des classes tarifaires existantes, seules Limited et Premium (avec Base) figurent au tableau des tarifs.
Pourquoi A est faux — Pattern D2 inventé : « Fixed » n'apparaît dans aucune table d'entitlement MAS.
Pourquoi B est faux — Pattern D2 inventé : « Default » est un terme générique de configuration, pas un nom d'entitlement officiel.
Pourquoi C est faux — Pattern D2 inventé : « Local » ne correspond à aucun palier de licence documenté par IBM.