Tableau de bord/Chapter 3/1.1 — Configurer les options Organization (niveau Org)
Chapter 3 · leçon 1 sur 12
CertaviaSystem (global), Set (Item Set + Company Set), Organization (entité légale), Site (unité opérationnelle).Base Currency 1), catalogues items distincts, listes vendors séparées, règles GL radicalement différentes. Une Org = quasi-entité légale autonome.Base Currency 1, Item Set, Company Set. Sans ces 3, le bouton Save reste grisé.Item Set (catalogue Item Master partagé) et Company Set (vendors / manufacturers partagés). Pas d'Asset Set, pas de Location Set.ASSETNUM + SITEID).Le modèle Maximo applique un principe rigoureux : chaque entité métier est rangée à un niveau précis qui détermine sa portée de partage. Ce choix est structurel et ne peut pas être contourné — il découle directement du data model relationnel (présence ou absence de SITEID et ORGID sur la table).
Concrètement, plus on descend dans la hiérarchie, plus la portée se restreint : une donnée System est visible par tout l'enterprise ; une donnée Set est partagée par les Orgs qui y sont liées ; une donnée Organization reste cloisonnée à cette seule Org ; une donnée Site n'existe que pour ce Site précis.
| Niveau | Clé composite | Exemples d'entités | Partage entre Orgs |
|---|---|---|---|
System |
(aucune) | Classifications · Domains · Persons · Currencies | Total |
Set |
ITEMSETID · COMPANYSETID |
Item Master · Companies (vendors) | Sélectif (1 Set partagé par N Orgs) |
Organization |
ORGID |
Hazards · Chart of Accounts · Autonumbering · GL | Aucun (cloisonné par Org) |
Site |
ORGID + SITEID |
Assets · Locations · Work Orders · Inventory · PO | Aucun (cloisonné par Site) |
SITEID et ORGID sur la table sous-jacente.Maximo n'autorise qu'une seule forme de partage entre Organizations : les Sets. Le modèle est volontairement fermé à 2 types stricts, qu'aucune customisation ne peut étendre :
Item Master (codes items, descriptions, specifications, rotating items, item assembly structures). Une Organization référence exactement 1 Item Set ; un Item Set peut être référencé par N Organizations.Companies (vendors, manufacturers, contacts, contracts source). Même cardinalité : 1 Org → 1 Company Set ; 1 Company Set → N Orgs.Ce design force une gouvernance claire : on peut centraliser « quoi est acheté » (items + vendors) tout en isolant « où ni comment » (assets, opérations, comptabilité). C'est le contrat IBM Docs : « You must associate each organization with only one company set... only one item set. »
Conséquence pratique : avant de créer la première Organization de votre déploiement, vous devez créer au moins 1 Item Set et 1 Company Set vides. La validation Maximo bloque sinon le save initial.
La séquence Save → Activate suit un chemin strict imposé par les validations ORM Maximo. Les transitions ne sont pas négociables — c'est une porte verrouillée pour éviter les transactions orphelines (WO sans contexte, MR sans destination, Inventory sans Storeroom).
Exemple 1 — Utilities + Fleet partageant les vendors (référence IBM Docs Planning for Multiple Sites) : entreprise avec opérations utilités et flotte de véhicules basées à Denver. Les vendors sont communs (mêmes fournisseurs pour les deux), mais les items sont radicalement différents (transformateurs vs. pneus).
UTIL et FLEETUTIL-DENVER, UTIL-LARAMIE, FLT-DENVERExemple 2 — Production US + RSA partageant items et vendors : production manufacturing identique aux États-Unis et en Afrique du Sud, mêmes pièces, mêmes fournisseurs, mais entités légales et devises distinctes.
USORG (Base Currency = USD) et RSAORG (Base Currency = ZAR)Les 5 confusions les plus fréquentes sur les Organizations / Sites / Sets à l'examen :
Currency additionnelle dans la même Org peut suffire (Base Currency 2).SITEID. Pas de Location partagée entre Sites.Q. Quels sont les 3 champs obligatoires pour sauver une Organization pour la première fois ?
Afficher la réponseBase Currency 1, Item Set, Company Set. Sans ces 3 valeurs, le bouton Save reste grisé. Default Site, Clearing Account et structures GL se configurent ensuite, après le save initial.
Q. Quelle est la séquence lifecycle complète d'une Organization, du nouveau record jusqu'à l'activation ?
Afficher la réponse1. Populer les 3 prérequis (Base Currency 1 + Item Set + Company Set) → 2. Save (insert dans MAXORG, statut Inactive) → 3. Créer au moins 1 Site avec Default Storeroom → 4. Cocher le flag Active. Ordre inverse impossible : les validations ORM bloquent toute désynchronisation.
Q. À quel niveau de stockage résident les Assets et les Locations ?
Afficher la réponseNiveau Site. Clé composite ASSETNUM + SITEID pour les Assets, LOCATION + SITEID pour les Locations. Deux Sites différents peuvent porter un Asset PUMP-001 sans collision — chaque Site a son propre namespace opérationnel.
Questions d’examen de style IBM. Cliquez une option, puis « Vérifier ma réponse ». Progression enregistrée localement.
Bonne réponse : D
Pourquoi cette question existe — STU §3.1 — la question vérifie où, au niveau Organisation, se pilote la modifiabilité des champs Asset et Location selon le statut du Work Order. Les distracteurs combinent des noms plausibles (Site Options, Other Organization Options) avec une mauvaise app (Asset Options). En pratique, mal localiser cette configuration empêche de comprendre pourquoi un champ devient soudainement non-modifiable après approbation.
Le contexte théorique d'abord — Dans Organizations, les Work Order Options regroupent plusieurs sous-sections, dont Edit Rules, qui spécifie les propriétés de work order modifiables pour un statut donné. Par exemple, on peut interdire la modification d'Asset et Location une fois le WO en statut APPR.
Ce que Maximo en fait — version opérationnelle — Dans Organizations > sélectionner l'organisation > action Work Order Options > onglet Edit Rules, cocher les statuts (ex. APPR, INPRG) pour lesquels Asset/Location doivent devenir read-only.
Exemple chiffré — Sur 3 statuts cochés (APPR, INPRG, WMATL), un work order approuvé ne peut plus voir son Asset modifié, contre 100% de modifiabilité en statut WAPPR (avant approbation), sur un total de 8 statuts de cycle de vie possibles.
Analogie quotidienne — C'est comme verrouiller l'adresse de livraison d'une commande une fois qu'elle est expédiée : avant expédition tout est modifiable, après, certains champs deviennent figés par règle.
Pourquoi A est faux — Pattern D5 champ-frère : Other Organization Options regroupe des paramètres divers, pas la règle d'édition par statut.
Pourquoi B est faux — Pattern D6 mauvaise-app : il n'existe pas d'« Asset Options » portant des Edit Rules de Work Order ; ces règles vivent dans Work Order Options.
Pourquoi C est faux — Pattern D5 champ-frère : Site Options configure des paramètres propres au site, pas les règles d'édition de champs sur WO.
Bonne réponse : B
Pourquoi cette question existe — STU §3.1 — variante de reformulation (options réordonnées) testant la même connaissance que la question jumelle de cette leçon : l'emplacement exact où configurer le verrouillage en lecture seule d'Asset/Location selon le statut du work order, à savoir Work Order Options - Edit Rules, dans l'application Organizations. Les distracteurs reprennent des libellés plausibles d'onglets/sections de configuration réels mais sans ce rôle précis.
Le contexte théorique d'abord — Dans Organizations, la section Work Order Options - Edit Rules permet de définir, pour chaque statut de work order, quels champs (dont Asset et Location) deviennent en lecture seule. Cette règle s'applique au niveau organisation, garantissant qu'un WO avancé dans son cycle de vie ne voit plus son asset/location modifié par erreur.
Ce que Maximo en fait — version opérationnelle — Dans Organizations > sélectionner l'organisation > action Work Order Options > onglet Edit Rules > pour un statut donné (ex. INPRG), cocher Asset et Location comme read-only > dès que le WO atteint ce statut, ces champs ne sont plus modifiables.
Exemple chiffré — Sur 1 règle configurée pour le statut INPRG verrouillant 2 champs (Asset, Location), un work order parmi 40 actifs ayant atteint ce statut verra ces 2 champs immédiatement protégés contre toute modification.
Analogie quotidienne — C'est comme verrouiller l'adresse de livraison d'une commande une fois qu'elle est passée en préparation : modifier ce champ trop tard créerait une incohérence opérationnelle.
Pourquoi A est faux — Pattern D9 quasi-synonyme : « Other Organization Options » est un regroupement distinct de paramètres généraux, pas la section Edit Rules portant ce verrouillage par statut.
Pourquoi C est faux — Pattern D9 quasi-synonyme : « Site Options » configure des paramètres au niveau site, pas la règle d'édition par statut de WO.
Pourquoi D est faux — Pattern D6 mauvaise-app : « Asset Options » n'est pas la bonne section ; ce sont les Work Order Options qui portent les Edit Rules.