IBM C1000-183
Maximo Manage v9.0 Functional Deployment — Professional
How to use this plan
- Click any lesson in the sidebar — each lesson = 1 screen
- Each lesson has 2 tabs: 📚 Lesson (theory) and 🎯 Exam scenarios (real cases)
- Toggle "Mark as studied" to track progress (saved in local browser storage)
- Use ← Previous / Next → to move linearly
- Recommended order: Section 3 (26%) first → Section 6 (16%) → Section 4 (15%) → etc.
Quick access by priority
Database Config + Admin Mode
Domains
Automation Scripts
AI Broker
Failure Codes + Reliability
Maximo Optimizer
8-week study strategy
- W1-2 — Full Section 3 (12 lessons) + Section 6 (7 lessons)
- W3-4 — Section 4 (8 lessons) + Section 7 (4 lessons) + hands-on MAS Trial
- W5-6 — Sections 1, 2, 5, 8, 9 (13 lessons) + Anki review
- W7 — Timed mock exams + official IBM Assessment Test ($30)
- W8 — Consolidation only, no new content
Describe the Maximo Application Suite
📋 IBM Objectives
- Describe deployment options for MAS
- Discuss high level features: Manage, Monitor, Predict, MVI / MVI Edge, Assist, Health
- Health: Scoring, Scoring Groups, Contributors, Ranges, generate WO/SR
- Discuss the role of MAS Core UI app
💡 Key Points
- Manage = EAM core (WO, PM, Inventory)
- Monitor = real-time IoT data
- Predict = forecast degradation / failure (historical + real-time)
- MVI = visual inspection (images/videos) · MVI Edge = local camera
- Assist = conversational AI
- Health = health score + criticality, 3 bricks Scoring Groups + Contributors + Ranges, generates WOs and SRs
- MAS Core UI = unified navigation, app switcher, SSO across apps
- Deployment: OpenShift on-prem, IBM Cloud, AWS ROSA, Azure ARO, SaaS
⚠️ IBM Trap
Predict vs Health vs Monitor — all three sound similar. The differentiator:
- "forecast" / "correlate performance factors" → Predict
- "score + criticality" → Health
- "real-time IoT data" → Monitor
🎯 Flashcard
Q. Which MAS product leverages historical and real-time data to forecast asset degradation or failure?
Show answer
Predict — "forecast" is the keyword.
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: D
Why D — MAS v9.0 est déployé exclusivement sur Red Hat OpenShift Container Platform (OCP) : self-managed on-prem, ROSA (Red Hat OpenShift on AWS), ARO (Azure Red Hat OpenShift), ou IBM Cloud OpenShift (ROKS). Le Suite Manager, Manage, Monitor, Predict, Health et Visual Inspection tournent tous comme OpenShift Operators, orchestrés par le mas-suite-operator. Cert-manager gère les certificats TLS ; MongoDB héberge les metadata Suite.
Why A wrong — D7 non-existent : MAS v9 ne ship plus de EAR file ; seuls les container images sur OCP.
Why B wrong — D2 invented : Docker Swarm + Portainer n'est pas un déploiement MAS supporté.
Why C wrong — D1 legacy : ICP + WebSphere ND était le pattern Maximo 7.6 EAM, remplacé depuis MAS 8+ par OCP Operators.
- IBM Docs — MAS system requirements : OCP target
- Maximo Secrets — MAS architecture : Suite platform
Correct: D
Why D — Le MAS Suite Administrator est le rôle cross-Suite qui gère l'infrastructure MAS : licensing + AppPoints allocation (combien de Base/Limited/Premium users par composante), install/upgrade des apps Suite (Manage, Monitor, Health, Predict, VI), et gestion des users cross-app via la Suite Manager UI. Il n'a PAS de pouvoir métier opérationnel dans Manage (pas de WO, pas de PO) ; il est focus platform-ops.
Why A wrong — D4 adjacent : dispatching WO est une fonction Manage (Work Supervisor), pas Suite Admin.
Why B wrong — D2 invented : BIRT reports sont un artefact Manage-level, hors responsabilité Suite Admin.
Why C wrong — D3 wrong scope : PR approval est défini par les tolerances Manage (Organizations), pas Suite.
- IBM Docs — Suite Administrator : Role scope
- IBM Docs — AppPoints admin : Entitlement mgmt
Correct: C
Why C — En MAS 8/9, Manage s'enregistre comme une Suite component. Les services Suite-level (identity/SSO, AppPoints licensing, workspaces bootstrap) sont shared ; Manage conserve sa business logic propriétaire, sa base de données relationnelle (Db2/Oracle/SQL Server, au choix du client), et sa couche MBO (Maximo Business Objects) historique. Cette architecture permet à Manage de bénéficier des services cross-Suite tout en préservant son investissement fonctionnel.
Why A wrong — D5 inverted : la direction est inversée — Manage CONSOMME le SSO Suite, ne l'embed pas.
Why B wrong — D1 legacy : standalone Manage était le pattern 7.6 ; v9 est Suite-only.
Why D wrong — D2 invented : aucun « Shared MBO Broker » n'existe dans MAS ; chaque Manage workspace a sa propre couche MBO.
- IBM Docs — Manage architecture : Suite-component model
- Maximo Secrets — Suite overview : Manage placement
Correct: D
Why D — AppPoints est l'unité d'entitlement cross-Suite. Un user type (Base/Limited/Premium) consomme un nombre fixe d'AppPoints selon la composante accédée (Manage Base ≠ Manage Premium ≠ Monitor). Le pool total est négocié au contract level IBM ; le Suite Admin alloue les points via AppPoints admin UI et peut voir consumption en temps réel. Ce modèle permet flexibilité : acheter N points puis les distribuer selon l'usage réel vs named-user rigide.
Why A wrong — D1 legacy : named-user licensing (AU/LU) était le modèle Maximo 7.6 EAM, remplacé.
Why B wrong — D3 wrong scope : licensing n'est JAMAIS per-Site ; AppPoints sont Suite-level global.
Why C wrong — D2 invented : aucun modèle per-node CPU-core dans MAS — les AppPoints sont user-centric (consommation par utilisateur unique actif selon le rôle), pas infrastructure-centric. Confusion possible avec le modèle de licensing OpenShift lui-même, mais MAS a sa propre métrique AppPoint indépendante.
- IBM Docs — AppPoints administration : Pool + user types
- IBM Docs — User types : Base/Limited/Premium
Correct: B
Why B — Base est le user type par défaut dans MAS. Quand un user arrive dans Suite Manager (via IdP SSO first login ou manual create), il est automatiquement Base. L'upgrade vers Limited (accès étendu) ou Premium (full access) se fait par assignment explicite du Suite Admin qui alloue des AppPoints supplémentaires. Le multiplicateur d'AppPoints augmente avec le tier.
Why A wrong — D6 cardinality : Premium est le top tier qui consomme le plus d'AppPoints (multiplicateur x5 environ), jamais le default assigné automatiquement — il exige un Suite Admin allocation explicite pour contrôler les coûts de licensing.
Why C wrong — D2 invented : « Unrestricted Admin » n'existe pas dans la taxonomie MAS — confusion possible avec le rôle Suite Admin qui a un accès étendu mais n'est pas un user type dans le sens AppPoints. Les types officiels sont Base/Limited/Premium.
Why D wrong — D1 legacy : « Install user » était l'installer concept 7.6, pas un MAS user type.
- IBM Docs — MAS User types : Base default + upgrades
- IBM Docs — AppPoints : Tier multipliers
Explain MAS User Administration Concepts
📋 IBM Objectives
- Identify various methods MAS provides to control authentication
- Describe different application entitlement types
- Describe different levels of administration entitlement
- Identify methods of user synchronization — SCIM and LDAP Sync
💡 Key Points
- Authentication: Local, LDAP, SAML 2.0, OIDC, API Keys
- AppPoints types: Authorized (fixed user, login independent of balance) · Concurrent (shared pool, consumes at login) · Limited Use (occasional) · Base (minimum)
- User sync: SCIM (modern, push REST) · LDAP Sync (cron, legacy)
- Admin levels: IBM Entitled Admin > Workspace Admin > App Admin
⚠️ IBM Trap
🎯 Flashcard
Q. Which Access Type ensures the user can login independent of the current AppPoint balance?
Show answer
Authorized
Correct: D
Why D — Après SSO login sur MAS, l'utilisateur arrive sur la Suite Navigator (tile view des apps auxquelles il a droit). Un clic sur le tile Manage lance l'app avec le SSO context propagé automatiquement (pas de second login). Cette centralisation remplace le pattern historique de bookmarks par-app ; permet aussi aux Suite Admins de contrôler visually ce qu'un user voit selon son entitlement.
Why A wrong — D4 adjacent : OCP console est un outil infra/ops, pas le entry point end-user.
Why B wrong — D7 non-existent : le path /maximo/ui/maximo.jsp appartient à l'ancien Maximo 7.x servi via WebSphere et n'existe plus dans MAS — la launch URL officielle passe par Suite Navigator qui oriente vers les apps containerisées sur OCP.
Why C wrong — D1 legacy : standalone URL externalisé était le pattern 7.6 ; MAS v9 impose Suite Navigator.
- IBM Docs — Starting Manage : Suite Navigator tile
- IBM Docs — Navigating Suite Navigator : App launcher
Correct: D
Why D — Suite Navigator est le app switcher SSO-aware de MAS : liste les apps auxquelles l'utilisateur courant a droit (Manage, Monitor, Health, Predict, VI), filtré par ses entitlements. Un clic sur un tile propage l'identité SSO — pas de deuxième authentication. Il est l'équivalent d'un launchpad cross-app, distinct des dashboards métiers (qui vivent dans chaque app).
Why A wrong — D4 adjacent : dashboards KPI vivent dans Health / Monitor, pas Suite Navigator.
Why B wrong — D2 invented : aucun workflow designer cross-app n'existe au Suite-level ; workflow est per-product (Manage Workflow app).
Why C wrong — D1 legacy : la migration de données Maximo 7.6 → MAS Manage utilise les outils mxloader, upgrade scripts officiels IBM et SQL migration paths — jamais Suite Navigator qui est simplement le portal de navigation runtime entre apps, sans capacité data transform.
- IBM Docs — Suite Navigator : App switcher
- Maximo Secrets — Suite architecture : Navigator role
Correct: D
Why D — Un Manage workspace représente UNE instance déployée de Manage sur la Suite (avec sa DB, ses pods, sa config). Un cluster OCP peut héberger plusieurs workspaces (prod + dev par ex.). À l'intérieur d'un workspace, la hiérarchie Organizations → Sites → Sets reste identique au pattern Maximo classique — workspace est une boundary d'installation, pas de données métier.
Why A wrong — D6 cardinality : un cluster peut héberger plusieurs Manage workspaces (ex: prod + staging séparés).
Why B wrong — D5 inverted : Organizations restent la business boundary DANS Manage ; workspaces sont au-dessus (Suite install-level).
Why C wrong — D1 legacy : « Tenant » était le naming cloud-SaaS plus ancien ; MAS v9 utilise workspaces.
- IBM Docs — Manage workspaces : Workspace concept
- IBM Docs — Architecture : Workspace vs Org
Correct: A
Why A — MAS délègue l'authentication à une identity layer (IBM Security Verify par défaut, ou IdP customer : Azure AD, Okta, Ping, etc.) via les standards OIDC ou SAML federation. Une fois authentifié au Suite level, le user navigue dans Manage, Monitor, Health sans second login — le token SSO suit le user. Cette architecture remplace les patterns Maximo 7.6 (Liberty basicAuth, LDAP sync local).
Why B wrong — D4 adjacent : Manage LDAP sync existe encore mais c'est une option legacy, pas le SSO Suite.
Why C wrong — D7 non-existent : aucun mécanisme SSO basé sur cookie proprietary dans MAS.
Why D wrong — D1 legacy : Liberty basicAuth + .properties files était le modèle 7.6.
- IBM Docs — MAS single sign-on : OIDC/SAML
- IBM Security Verify docs : Default IdP
Maximo Manage Add-ons and Industry Solutions
📋 IBM Objectives
- Industry Solutions: Transportation (meter change-out, serial change, warranty recovery)
- Add-ons: ACM, SAP/Oracle/Workday/Envizi/TRIRIGA Connectors, Service Provider
- Spatial, Maximo IT, Reliability Strategies
- HSE: Certificates, Training Requirements, Permits for Work
- Scheduler and Calibration
💡 Key Points
- Transportation: meter change-out, serial number changes, warranty recovery (rail, aviation)
- Service Provider: multi-tenant (multiple clients on 1 instance)
- Spatial: ESRI GIS integration
- HSE advanced: Certificates + Training Requirements + Permits for Work (memorize the 3)
- Connectors: SAP, Oracle, Workday, Envizi (ESG), TRIRIGA (real estate)
Correct: A, C
Why A, C — MAS v9 ne tourne QUE sur OpenShift. Deux options principales : Self-managed OCP (OpenShift sur hardware client on-prem, ou ROSA sur AWS, ou ARO sur Azure — tous des OpenShift flavors) et IBM Cloud OpenShift (ROKS) managed. Aucune autre base (vanilla k8s, Docker Swarm, WebSphere standalone) n'est supportée. Le customer choisit selon sa stratégie cloud.
Why B wrong — D1 legacy : 7.6 in-place upgrade est une migration path, pas un target de déploiement.
Why D wrong — D2 invented : « Microsoft Dynamics Maximo Cloud » est un terme totalement fabriqué — aucun partenariat IBM-Microsoft n'offre de Maximo rebranded Dynamics. Piège qui mélange l'écosystème Microsoft Dynamics ERP avec la suite IBM MAS.
Why E wrong — D7 non-existent : vanilla Kubernetes sans OCP Operators n'est pas une plateforme supportée — MAS exige spécifiquement OpenShift Container Platform pour ses Operator-based deploys (IBM Operator Catalog), les primitives Kubernetes natives ne suffisent pas pour orchestrer Manage/Monitor/Health.
- IBM Docs — MAS system requirements : OCP variants
- IBM Cloud ROKS docs : Managed OpenShift
Correct: D
Why D — Le MAS Installer (mas.cli — wrapper interactive CLI, ou le bundle Ansible équivalent) orchestre le déploiement initial sur OpenShift : installe le mas-suite-operator, cert-manager (pour TLS auto), MongoDB (pour Suite metadata), puis chaque application operator (Manage, Monitor, Health, Predict, VI) dans l'ordre adéquat. Il configure aussi les routes OCP et les catalogs. Après install, les upgrades passent par le Suite UI ou des re-runs du CLI.
Why A wrong — D2 invented : migration DB (Db2→PostgreSQL ou autre) utilise mxloader/dbconfig, pas mas.cli.
Why B wrong — D3 wrong scope : ongoing AppPoints management se fait dans Suite Admin UI, pas installer.
Why C wrong — D4 adjacent : BIRT est le reporting engine de Manage, hors scope installer.
- IBM Docs — MAS CLI installer : Ansible bundle
- ibm-mas/cli GitHub : Install guides
Correct: A
Why A — Manage v9.0 supporte trois moteurs DB pour son OLTP (transactions) : IBM Db2, Oracle Database, Microsoft SQL Server — chacun dans leurs versions minimums documentées. Le customer provisionne la DB hors cluster OCP et fournit la connection string au Manage workspace. MongoDB (bundled par la Suite pour metadata ops) n'est PAS la DB Manage.
Why B wrong — D1 legacy : l'idée qu'Oracle/SQL Server auraient été retirés est un faux rumor. Les 3 restent supportés en v9.
Why C wrong — D5 inverted : Manage ne ship PAS de DB pod bundled ; le customer fournit la DB externe.
Why D wrong — D2 invented : MongoDB est utilisé dans MAS pour les metadata de la Suite (config runtime, logs Suite Manager) mais jamais comme OLTP backend pour Manage — l'application business (WOs, Assets, POs) s'appuie exclusivement sur Db2 ou Oracle ou PostgreSQL selon le customer choice.
- IBM Docs — Database requirements : Db2/Oracle/SQL Server
- IBM Docs — System requirements : DB versions
Correct: B
Why B — Toute la configuration Manage (tables MAXATTRIBUTE, SIGOPTION, MAXAPP, DOMAIN, etc.) est persistée dans la base de données transactionnelle externe (Db2/Oracle/SQL Server). Les pods Manage sur OCP sont stateless — ils rechargent la config depuis la DB au démarrage. Ce design permet scale horizontal (multiples pods en replica set) sans perte de config ; pod restart ou re-deploy ne perd rien.
Why A wrong — D1 legacy : persistence sur /opt/IBM/SMP était le modèle 7.6 on-VM. Containers = stateless.
Why C wrong — D3 wrong scope : config Manage vit dans sa DB relationnelle, pas MongoDB (qui est Suite metadata).
Why D wrong — D2 invented : ConfigMaps OCP portent le wiring Suite (URLs, secrets), pas le schéma de config Manage.
- IBM Docs — Manage architecture : Stateless pods
- IBM Docs — Database requirements : DB-centric config
Correct: D
Why D — Le défaut v9 : TLS / HTTPS end-to-end enforced via les OpenShift routes exposant les Suite URLs, avec certificats auto-issués et rotés par cert-manager (Operator standard OCP). Cette configuration est mandatory par défaut — pas d'option HTTP pour production. Les certificats peuvent être self-signed (dev) ou issued par une CA publique (Let's Encrypt, DigiCert). Le Suite Admin ne configure pas le TLS manuellement ; cert-manager s'en charge.
Why A wrong — D1 legacy : plain HTTP par défaut était une option 7.6, retirée en v9.
Why B wrong — D9 near-synonym : « SSL encryption » est le terme deprecated ; v9 nomme TLS/HTTPS avec cert-manager.
Why C wrong — D5 inverted : external traffic DOIT être TLS ; mTLS pod-to-pod est un détail interne additionnel.
- IBM Docs — MAS TLS certificates : cert-manager + routes
- OpenShift routes + cert-manager : Auto-issuance
Correct: A, B, C
Why A, B, C — Maximo stratifie ses records en 3 boundaries business, du plus large au plus étroit : Set (Item Set + Company Set — mutualisés entre Orgs), Organization (GL, Base Currency, tolérances financières), Site (Assets, Locations, WOs, Inventory — le niveau opérationnel transactionnel). Cette hiérarchie permet data sharing et data separation selon le besoin : items communs à plusieurs Orgs via Set, autonomie par Org, opérations isolées par Site.
Why D wrong — D2 invented : « MAS Tenant » n'est pas une record boundary visible dans Manage.
Why E wrong — D4 adjacent : les namespaces OpenShift sont des artefacts infrastructure (isolation réseau + quotas cluster) gérés par les ops team, sans sémantique business — jamais utilisés comme unité de segmentation organisationnelle Maximo (qui relève d'Organizations/Sites).
Why F wrong — D3 wrong scope : Ledger Book existe (grouping GL sous une Org) mais n'est pas une boundary de structure data.
- IBM Docs — Sets, Organizations, Sites : 3 boundaries
- Maximo Secrets — Organizations and Sites (Portaluri, 2016) : Hierarchy
Correct: A
Why A — Default Insert Site est l'attribut sur le User record qui pré-remplit le Site ID à chaque création d'un nouveau record (WO, Asset, Location, PR...). C'est une aide ergonomique — un technicien basé sur Site USNORTH peut ouvrir un WO sans avoir à sélectionner son Site manuellement. L'attribut seed aussi le Session Site context (le header de la session). La visibilité des records reste gouvernée par les Security Groups, pas cet attribut.
Why B wrong — D5 inverted : la visibilité des records est filtrée par Security Groups, pas par Default Insert Site.
Why C wrong — D4 adjacent : le routing OpenShift (Ingress / Route CRD) est configuré au niveau cluster ou namespace, jamais par Site Maximo — il régit le trafic HTTP vers les pods, aucune notion de Site dans sa config. Confusion entre infra réseau et data segmentation Maximo.
Why D wrong — D3 wrong scope : Base Currency vit au niveau Organization, pas User.
- IBM Docs — Default Insert Site : User attribute
- IBM Docs — Users and User Templates : Session context
Correct: B
Why B — Les Security Groups restent le mécanisme d'authorization dans Manage v9, même avec MAS SSO actif. Séparation claire : MAS SSO = authentication (« qui est cet user »), Manage Security Groups = authorization (« que peut-il faire »). Les deux couches coexistent. Les Security Groups définissent l'accès aux apps, Sites, Orgs, records, et aux actions (sigoptions). MAS Suite a aussi ses Suite Roles pour le cross-app mais ils ne remplacent pas les Security Groups internes à Manage.
Why A wrong — D1 legacy : MAS Suite Roles sont pour cross-app access, pas un remplacement des Manage Security Groups.
Why C wrong — D3 wrong scope : les Security Groups sont cross-Organization dans Maximo Manage (Site et Org listés dans l'onglet Sites du group), mais jamais Set-level — les Sets (Item Set, Company Set) partagent des référentiels de données, pas des permissions. Scope sécurité complètement découplé du scope Sets.
Why D wrong — D2 invented : aucun mécanisme per-page ACL natif dans Manage v9 — les permissions UI s'expriment via Application Access (app visible/pas visible) et Application Options (sigoptions par app), pas page-par-page. Granularité app-level uniquement, pas URL-level.
- IBM Docs — Security Groups : Authz mechanism
- IBM Docs — MAS SSO + Manage : Authn layer
Correct: C
Why C — Au premier SSO login d'un user Suite, Manage applique son mécanisme de JIT provisioning (Just-In-Time) : il crée automatiquement un record MAXUSER avec l'email Suite comme clé de mapping, et applique le default User Template configuré (qui définit Default Insert Site, Security Groups, Status Out tableau). Ce pattern élimine le besoin de pre-provisioning manuel et garantit que chaque user authentifié par la Suite peut immédiatement utiliser Manage avec le bon setup.
Why A wrong — D1 legacy : pre-provisioning manuel était le pattern Maximo 7.6 (sync LDAP batch).
Why B wrong — D2 invented : aucun button « Sync Manage users » dans Suite Admin.
Why D wrong — D7 non-existent : Manage utilise TOUJOURS l'email Suite comme mapping key, pas un loginID random.
- IBM Docs — JIT user provisioning : MAXUSER auto-create
- IBM Docs — User Templates : Default template
Correct: B, C
Why B, C — Le Suite Administrator assigne explicitement Limited ou Premium à un nouveau user MAS via la Suite Manager. Chacun consomme plus d'AppPoints que Base (multiplicateur d'entitlement). Sans grant explicite, le user reste Base — ce qui limite les apps accessibles et les fonctionnalités IBM Cloud.
Why A wrong — D9 : Base est le default, appliqué automatiquement au premier SSO login. Aucun grant admin requis.
Why D wrong — D1 legacy : « Install user » était un concept de l'installer Maximo 7.6 ; inexistant en MAS v9.
Why E wrong — D2 invented : pas de type « Auto-Provisioned » dans MAS. Distracteur fabriqué.
- IBM Docs — MAS User types : Base / Limited / Premium
- IBM Docs — AppPoints administration : Entitlement model
Correct: A, B
Why A, B — IBM commercialise Maximo Application Suite 9.0 en 2 modes de déploiement officiels : (1) MAS SaaS Flex — offre cloud managed by IBM, hébergée sur IBM Cloud (régions multi-continents), abonnement annuel à l'AppPoint, zéro ops infra, (2) MAS On-Premises — déploiement sur OpenShift Container Platform (OCP 4.12+) on-premise ou cloud privé, client gère OCP/storage/upgrades. Choix basé sur data residency, coût TCO, contrôle infra.
Why C wrong — D1 legacy : Maximo EAM 7.6 (WebSphere) est retired, pas de "MAS Legacy WebSphere Edition".
Why D wrong — D2 invented : "Serverless Edge" n'existe pas — MAS tourne en containers OCP stateful.
Why E wrong — D7 non-existent : aucun Maximo Desktop Client n'a jamais existé — l'UI est historiquement web-based (Java applet dans Maximo 5-7, JSP puis React en MAS). Distracteur qui invente une modalité de delivery absente du produit.
- IBM Docs — MAS deployment options : SaaS Flex vs On-Premises
- IBM Docs — MAS SaaS Flex : Cloud subscription model
Correct: A, B
Why A, B — Le modèle AppPoint MAS définit 2 user types : (1) Authorized User — accès complet (create/update/delete/approve), tarif plein (~10 AppPoints/user/an pour Manage), (2) Limited User — read-only + quelques transactions restreintes (Service Requests, log labor), ~1 AppPoint. Orgs optimisent 90% Limited + 10% Authorized. Distinction configurée via Security Groups.
Why C wrong — D2 invented : "Shadow User" n'existe pas dans la taxonomie MAS — terme fabriqué qui ne correspond à aucun user type ni rôle technique Maximo. Les user types sont strictement Authorized + Limited (AppPoints model), rien d'autre.
Why D wrong — D9 near-synonym : "Bulk User" n'est pas un tier — service accounts = Limited standards.
Why E wrong — D1 legacy : "Named" = modèle Maximo 7.6, remplacé par AppPoint en MAS.
- IBM Docs — MAS AppPoint licensing : Authorized vs Limited
- IBM Redbook — MAS deployment guide : User types
Correct: A, B, C
Why A, B, C — MAS 9.0 ship avec 5 core products sur le catalog OpenShift Operator : (1) Manage — successor de Maximo EAM 7.6 (WOs, Assets, Inventory, PO), (2) Health — asset health scoring basé rules + ML, (3) Monitor — IoT data ingestion + anomaly detection. Les 2 autres (non listés) : Predict (ML predictive) et Visual Inspection (computer vision). Tous via MAS Core + Operators, consommant AppPoints.
Why D wrong — D2 invented : IBM Planning Analytics (ex-TM1) est un produit planification budget séparé, intégrable via API mais pas bundled MAS.
Why E wrong — D9 near-synonym : WatsonX Assistant = IBM AI conversational séparé — MAS utilise AI Broker comme abstraction LLM (Granite).
Why F wrong — D1 legacy : Maximo Mobile Classic = ère 7.6 (Work Manager offline), retired dans MAS au profit de MAS Mobile React Native.
- IBM Docs — MAS product catalog : Core apps
- IBM Docs — MAS 9.0 overview : Bundled products
Configure Chart of Accounts
📋 IBM Objectives
- Configure Organization-specific GL Component Structure
- Deactivate GL Account codes
- Requirements of a GL Account Code
💡 Key Points
- Configured per Organization (GL Component Structure)
- Up to 20 components in the structure
- GL codes: deactivated (never deleted) if already used
- Requirements: all components valid, delimiter defined, format respected
⚠️ IBM Trap
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: A
Why A — La structure des GL account segments (longueur de chaque segment, delimiter, flag required, validation list) se configure en deux étapes : Database Configuration → GL Account Configuration définit l'architecture des segments (nombre, longueurs, types), puis Chart of Accounts maintient les valeurs valides par Organization. Chaque Org peut avoir sa propre Chart of Accounts mais l'architecture globale reste System-level.
Why B wrong — D2 invented : « Financial Account Setup » n'est pas une app Maximo. Distracteur au nom générique plausible.
Why C wrong — D4 adjacent : Storerooms porte un GL tab pour les defaults de comptes par storeroom, mais ne définit pas la structure.
Why D wrong — D1 legacy : « General Ledger Cost Control » est un nom de l'ère Maximo 4.x, remplacé depuis.
- IBM Docs — Configuring Chart of Accounts : Segment config
- Maximo Secrets — Financial map : Chart of Accounts
Correct: B
Why B — Le flag Mandatory sur un segment GL impose qu'une valeur valide (ou un placeholder ?) soit saisie avant que Maximo n'accepte la sauvegarde d'une chaîne GL. Validé partout où un GL Account est input : WOs, PRs, Invoices, Transactions. Sans valeur sur un segment mandatory, la chaîne reste incomplète et le posting est bloqué.
Why A wrong — D5 inverted : « mandatory » contrôle l'input, pas l'editabilité post-go-live. Locking est un concept séparé.
Why C wrong — D2 invented : Maximo ne populate pas auto les segments depuis Asset Location. Distracteur fabriqué.
Why D wrong — D1 legacy : « Exclude from reporting » est un concept BIRT/Cognos, pas un flag GL segment.
- IBM Docs — Chart of Accounts : Segment mandatory flag
- Maximo Secrets — Financial map : GL validation
Correct: C
Why C — Chaque Organization choisit son mode de validation GL via Chart of Accounts options : No validation (aucun check, rarement utilisé), Validate individual segments (chaque segment doit être une valeur valide du domain), Fully validate against existing combinations (la combinaison complète doit exister dans CHARTOFACCOUNTS — le plus strict, recommandé en production).
Why A wrong — D1 legacy : per-segment validation est un mode standard en v9, pas exclusif à la longueur.
Why B wrong — D5 inverted direction : le mode multi-site n'a aucune influence sur le mode de validation GL (Full vs Pre-validated vs No Validation) — les deux dimensions sont indépendantes. Multi-site concerne data segmentation Org/Site, GL validation concerne finance integrity rules.
Why D wrong — D2 invented : la validation est locale (Manage MBO). L'intégration ERP est asynchrone via MIF.
- IBM Docs — Chart of Accounts validation options : 3 modes
- Maximo Secrets — Financial Processes : GL validation practice
Correct: D
Why D — Le GL Debit d'un Work Order est calculé via une cascade de sources mergées dans l'ordre défini sur Organizations → GL Account Mapping. Sources typiques : Work Type, Asset, Location, Failure Class, WO Priority. Maximo prend le premier segment non-null rencontré et continue avec les segments suivants. Ce merge multi-sources permet d'avoir un GL final complet même si aucune source ne fournit tous les segments. Configurable par Organization.
Why A wrong — D5 inverted : le WO header value est seed-value, pas seule source. Le cascade merge avec Asset/Location/etc.
Why B wrong — D1 legacy : le pattern single global Debit account appartenait à Maximo pré-7.0 (Maximo 5.x / 6.x) — obsolète depuis l'introduction du modèle double-entry GL complet (Debit + Credit per transaction) et du Chart of Accounts multi-segments en Maximo 7.x+.
Why C wrong — D2 invented : GL computation est locale (MBO). ERP REST call est async post-posting.
- IBM Docs — GL Account Merge Rules : Cascade config
- Maximo Secrets — Financial map (Portaluri, 2024) : GL defaulting cascade
Correct: B
Why B — Maximo utilise le caractère ? (point d'interrogation) pour marquer un segment mandatory non encore renseigné dans une chaîne GL partiellement construite. Exemple : XX-????-1234 signifie que le 2ᵉ segment reste à compléter. La chaîne ne peut pas être posted tant qu'il reste un ? sur un segment mandatory. Sert d'aide visuelle au planificateur qui fournit des GL partiels en attendant le segment final issu d'un lookup.
Why A wrong — D7 non-existent : l'astérisque * n'est pas le placeholder GL. Distracteur par analogie wildcard.
Why C wrong — D9 near-synonym : le hyphen - est le delimiter entre segments (configurable), pas un placeholder de valeur manquante.
Why D wrong — D2 invented : le character underscore _ n'a aucun rôle fonctionnel dans la GL account structure Maximo — le séparateur officiel est toujours le hyphen - (ou configuré autre via Organizations → GL Component Delimiter). Piège pour candidat qui confond avec des conventions de naming SQL.
- IBM Docs — Chart of Accounts placeholder : Question mark character
- Maximo Secrets — Financial (Portaluri, 2024) : GL string building
Configure Budget Monitoring & Cost Management
📋 IBM Objectives
- Describe the Budget Monitoring application
- Identify where budget amounts are specified and compared to actuals
- Describe how focal points are defined
💡 Key Points
- Budget Monitoring app: budgets defined per Organization
- Compared to actuals (real costs from WOs, PRs, POs)
- Focal Point = GL segment at which the budget is tracked
- Cost Management app is designed to interface with Oracle Projects ⭐
⚠️ IBM Trap — memorize
🎯 Flashcard
Q. What system was the Cost Management application designed to be interfaced with?
Show answer
Oracle Projects
Correct: B
Why B — Maximo maintient les devises dans Currency Codes (table CURRENCY : code + symbol + description) et les taux de change dans Exchange Rates. Chaque taux porte une Active Date — Maximo prend le dernier taux ≤ date de transaction. Le stockage est per-Organization (une Org peut avoir ses propres taux USD→EUR différents d'une autre Org). Un WO planifié en USD avec Base Currency CAD utilise le taux actif à sa plan date.
Why A wrong — D3 wrong scope : Base Currency tab déclare la devise primaire, pas les taux de conversion.
Why C wrong — D4 adjacent : Chart of Accounts gère la structure GL, pas les FX.
Why D wrong — D2 invented : « Financial Rate Book » n'est pas une app Maximo.
- IBM Docs — Financial Exchange Rates : Currency + rates
- Maximo Secrets — Financial map : FX anatomy
Correct: C
Why C — Base Currency 1 est la devise locale primaire (ex: CAD pour une Org canadienne) ; Base Currency 2 est typiquement la reporting currency du groupe (ex: USD pour consolidation corporate). Maximo stocke chaque transaction dans les deux devises en parallèle, en utilisant le taux actif à la transaction date. Permet de produire à la fois des reports locaux (en CAD) et des reports consolidés (en USD) sans recalcul.
Why A wrong — D3 wrong scope : currency est Org-wide, pas per-Site. Tous les Sites d'une Org partagent les mêmes Base Currencies.
Why B wrong — D2 invented : Maximo n'auto-switch pas la currency selon la locale browser.
Why D wrong — D4 adjacent : les Security Groups gèrent les permissions applicatives et object-level CRUD, pas les currency settings — celles-ci sont sur Organization (Base Currency 1/2) et Currency Codes, domaine financier totalement distinct du domaine sécurité.
- IBM Docs — Organizations Base Currencies : 2 currencies
- Maximo Secrets — Financial map : Multi-currency pattern
Correct: B, C
Why B, C — Chaque row de la table Exchange Rates porte une Active Date. Maximo lit la ligne la plus récente dont Active Date ≤ transaction date. Les taux expirés restent en table pour (1) audit trail, (2) revaluation jobs batchés, (3) reprocessing de vieilles transactions. Aucune purge automatique — c'est au DBA de décider une retention policy si besoin.
Why A wrong — D2 invented : pas de pull live FX externe natif dans Maximo. Intégration possible via MIF custom, mais hors OOTB.
Why D wrong — D5 inverted direction : les exchange rates sont stockées par Organization (Currency Codes app scopée Org, chaque Org définit ses propres taux) — jamais au niveau System global. Cette segmentation permet à deux Orgs d'avoir des taux différents pour la même devise à la même date (ex: taux contract vs taux spot).
Why E wrong — D7 non-existent : triangulation (via USD) n'est pas la règle par défaut ; Maximo utilise direct pairs.
- IBM Docs — Financial Exchange Rates : Active Date logic
- Maximo Secrets — Financial map : Rate history
Correct: A
Why A — Quand le taux de change change, Maximo ne revalorise PAS automatiquement les stocks on-hand existants. Les historical costs restent tels quels (principe de conservation du coût). Seuls les new receipts (après le changement de taux) utilisent le nouveau taux. Pour revaloriser l'existant, il faut une action explicite Adjust Standard Cost ou Adjust Average Cost dans Inventory Adjustments. Ce design préserve la traçabilité comptable historique.
Why B wrong — D2 invented : « Reprice All Storerooms » n'existe pas dans Maximo.
Why C wrong — D5 inverted : POs existants ne sont jamais annulés automatiquement sur un rate change.
Why D wrong — D4 adjacent : COA reload concerne la structure GL, pas la valorisation stock.
- IBM Docs — Inventory Cost Adjustment : Adjust action
- Maximo Secrets — Financial Processes in Inventory : Revaluation pattern
Correct: C
Why C — Average Cost (Moving Average) est la méthode de costing par défaut quand un nouveau Item Set est créé dans Maximo. L'average se recalcule à chaque receipt : new_avg = (old_qty × old_avg + receipt_qty × receipt_price) / (old_qty + receipt_qty). FIFO et Standard Cost sont supportés mais doivent être sélectionnés explicitement par Item ou par Storeroom. LIFO n'est PAS supporté en v9.
Why A wrong — D9 near-synonym : FIFO (First-In-First-Out) est bien supporté comme méthode de costing dans Maximo Manage mais n'est pas le default — l'admin doit explicitement le choisir par storeroom dans Inventory Options. Average Cost est le default out-of-box.
Why B wrong — D1 legacy : LIFO était historiquement listé dans les options de costing Maximo antérieures mais est aujourd'hui restreint par les réglementations comptables IFRS qui l'interdisent (GAAP US le permet encore) — IBM a déprécié LIFO comme option par défaut supportée sans raison métier stricte.
Why D wrong — D2 invented : « Weighted Standard Cost » ne figure pas dans le dropdown Maximo.
- IBM Docs — Inventory Item Costing Method : 4 methods
- Maximo Secrets — Financial Processes in Inventory 7/8 : Costing methods
Correct: B
Why B — La configuration du nombre de Tax Types actifs et de la Tax Code Hierarchy se fait depuis l'application Organizations, via l'action More Actions → Purchasing Options → Tax Options. OOTB, Maximo active un seul Tax Type (Tax 1) avec possibilité d'en activer jusqu'à 5 (colonnes TAX1..TAX5 sur PRLINE / POLINE / INVOICELINE) ; pour aller jusqu'à 27 Tax Types il faut étendre le schéma via Database Configuration. La Tax Code Hierarchy définit l'ordre de recherche du code par défaut (ex: Vendor → Item → Company → Storeroom). Cette configuration est scopée à l'Organization — chaque Org peut avoir sa propre politique fiscale.
Why A wrong — D9 near-synonym : l'application Tax Codes existe bien (table TAXCODE) mais sert uniquement à créer et maintenir les codes individuels (nom, rate, description, flag exempt). Elle ne contrôle ni le nombre de Tax Types activés, ni la hiérarchie de défaut. Piège classique pour un candidat qui assimile « configurer les taxes » à l'app Tax Codes.
Why C wrong — D3 wrong scope : Chart of Accounts structure les GL Account segments (length, delimiter, validation lists) — c'est une configuration comptable orthogonale à la logique fiscale d'achat. Aucune option Tax Types dans COA.
Why D wrong — D2 invented : « Tax Setup tab » sur Item Master n'existe pas. Un item porte un flag Tax Exempt et peut référencer un code de taxe par défaut via le champ Tax Code, mais aucun onglet dédié « Tax Setup ». Distracteur fabriqué.
- Maximo Secrets — Tax Code Defaulting (Portaluri, 2020) : Hiérarchie de défaut + Organizations menu
- IBM Support — Setting Maximo Up For Multiple Tax Types : 5 Tax Types OOTB + extension 27
- Certus Solutions — Tax Code Defaulting Hierarchy : Ordre Vendor→Item→Company→Storeroom
Correct: B
Why B — Les Companies (records vendor dans la table COMPANIES) sont stockés au niveau Company Set (COMPANYSETID). Le Company Set est une catégorie spéciale entre System et Organization qui permet à plusieurs Orgs de partager le même catalogue vendor — utile pour une holding où l'achat est centralisé. Chaque Organization assigne UN Company Set (et UN Item Set) dans Organizations → Sites → Set fields. Les POs, PRs et Invoices référencent les Companies du Company Set de leur Org. Changer le Company Set d'une Org déjà active est fortement déconseillé car il rompt les FK des documents existants.
Why A wrong — D9 near-synonym : les Organizations utilisent un Company Set (et un Item Set) mais n'hébergent pas les vendors eux-mêmes. Piège pour candidat qui assimile "lié à Org" à "stocké au niveau Org".
Why C wrong — D3 wrong scope : les vendors sont partagés entre Sites d'une même Org (et potentiellement entre Orgs via le Company Set). Aucun stockage Site-level pour les vendors — un vendor XYZ est le même pour tous les sites qui y recourent.
Why D wrong — D6 wrong cardinality : System level (purement global) est réservé aux objets qui n'ont aucune segmentation par tenant métier (Classifications, Domains, Currencies). Les Companies ont besoin d'une segmentation mutualisable (Set) pour permettre qu'une holding multinationale puisse avoir un Company Set USA et un Company Set EMEA distincts.
- IBM Docs — Sets and Organizations architecture : Item Set + Company Set concept
- Maximo Secrets — Organizations and Sites (Portaluri, 2016) : Set architecture
- IBM Docs — Data storage levels (MAM SaaS) : System / Set / Org / Site
Correct: A, B
Why A, B — L'Organization record porte 2 slots pour currencies : Base Currency 1 (obligatoire au save initial, devise principale pour transactions internes, immuable) et Base Currency 2 (optionnelle pour reporting dual-currency corporate). Quand BC2 active, Maximo maintient auto les montants convertis via Exchange Rates. Critique pour multinationales consolidant dans une devise ≠ opérationnelle.
Why C wrong — D9 near-synonym : Transaction Currency se définit par record (PO, Invoice), pas sur Organization header.
Why D wrong — D2 invented : "Foreign Exchange Index" n'existe pas — taux vivent dans Exchange Rates.
Why E wrong — D7 non-existent : "Subsidiary Currency Mapping" est un terme fabriqué sans aucune référence Maximo — ni field sur Organization, ni concept documenté IBM. Les subsidiaries mappent via Base Currency 1/2 et Company Set, pas via une feature ad-hoc nommée.
- IBM Docs — Organization base currencies : Currency 1 and 2
- Maximo Secrets — Multi-currency setup : Dual reporting
Correct: A, B, C
Why A, B, C — 3 transactions génèrent auto GL postings : (1) Inventory Issue — WO material consumption, crédit storeroom source + débit WO/asset via resource codes × Org GL settings, (2) Invoice Approval — AP recognition, crédit AP + débit expense/asset selon PO, (3) Tool Usage — tool time charged, débit WO + crédit tool account. Tous dans table GLTRANS, consommables interface AP/GL externe.
Why D wrong — D5 inverted direction : Asset creation ne génère aucun posting GL — c'est la depreciation schedule qui produit les entries, pas la création initiale.
Why E wrong — D4 adjacent : workflow task completion = event process (routing/approval/signoff), aucun impact comptable direct.
Why F wrong — D3 wrong scope : Person records = HR/identity (nom, email, craft), aucun lien comptabilité.
- IBM Docs — GL transaction types : GLTRANS postings
- Maximo Secrets — Financial processes : GL generation flows
Configure Asset Depreciation Schedules
📋 IBM Objectives
- Identify where depreciation can be configured for Assets
- Describe how depreciation schedules are configured
💡 Key Points
- Configured in the Assets app (action Manage Depreciation Schedule)
- Schedule types: straight-line, declining balance, custom
- An asset can have multiple parallel schedules (e.g. IFRS + US GAAP)
🏢 Real-World Case
Show solution
In the Assets application, select the asset → Action Depreciation Schedules. Create a schedule with Method = Straight Line, Purchase Cost = 450,000, Salvage Value = 30,000, Useful Life = 240 months. Maximo computes monthly depreciation: (450,000 − 30,000) / 240 = €1,750/month.
Depreciation Schedules live in the Assets app (not Chart of Accounts, not a separate financial module). Supported methods: Straight Line and Declining Balance. Result can be exported to the finance ERP.
Configure organizational options (Org level)
📋 IBM Objectives
- Define when multiple organizations are required in a MAS Manage database
- Identify the required fields on an Organization record
- Describe the purpose of Sets
- Identify the data requirement for saving vs activating an organization
💡 Key Points
- Multi-Org when: different currencies, distinct financial/purchasing rules, separate item sets
- Required Org fields: name, base currency, item set, company set, default site
- Sets (Item Set, Company Set) = shared references across Orgs
- Save = base fields | Activate = at least 1 site with default storeroom
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: A
Why A — La création d'une nouvelle Organization dans Maximo Manage est une décision architecturale majeure qui ne doit jamais être prise à la légère. Les vrais business drivers qui requièrent une Organization séparée sont : (1) Base Currency 1 différente — l'Organization est liée à une currency de base unique, donc deux entités avec USD et EUR exigent deux Orgs, (2) Item Set distinct — si chaque subsidiary a son propre catalogue d'items avec numérotations et descriptions indépendantes, (3) Company Set distinct — si les vendors ne sont pas partagés, (4) règles comptables et GL structures radicalement différentes. Une Organization = une entité légale quasi-autonome dans Maximo. Les multi-sites d'une même company partagent une Organization commune — on crée des Sites pas des Organizations.
Why B wrong — D4 adjacent : les Crews appartiennent au domaine Labor (Labor records, Calendars), entièrement orthogonal à l'Organization. On gère plusieurs crews dans un même Site sans besoin de nouvelle Org.
Why C wrong — D1 legacy term : la structure des GL segments est une option configurable au sein d'une Organization (Chart of Accounts), mais n'exige pas à elle seule une nouvelle Org — deux subsidiaries avec GL distincts peuvent toujours cohabiter dans la même Org si currency et item set sont identiques.
Why D wrong — D3 wrong scope : les Security Groups opèrent cross-Organization par construction — c'est un mécanisme Security System-wide. Ils ne dictent jamais la création d'une nouvelle Org ; confusion de niveaux.
- IBM Docs — Creating organizations : Org business drivers
- Maximo Secrets — Organizations and Sites : Multi-Org decision tree
Correct: A, C
Why A, C — Pour sauver un nouveau record Organization dans Maximo Manage, 3 champs sont strictement obligatoires : Base Currency 1, Item Set, Company Set. Parmi les options proposées, les 2 correctes sont Base Currency 1 et Item Set (Company Set non listé). Base Currency 1 fixe la devise principale dans laquelle toutes les transactions (WO costs, PO totals, inventory valuation) seront capturées en natif. Item Set définit le catalogue de référence Item Master partagé par cette Organization — on peut réutiliser un Set existant ou en créer un nouveau. Company Set (non listé ici) fixe le référentiel vendors. Sans ces 3 champs, le save est bloqué par validation UI/ORM. D'autres champs (Default Site, Clearing Account, GL structures, Default Storeroom) se configurent après pour activer l'Org ou raffiner son comportement, mais pas pour le save initial.
Why B wrong — D3 wrong scope : Default Storeroom est requis au niveau Site pour pouvoir activer le Site (transacter des WOs, MR, inventory), pas au niveau Organization save initial.
Why D wrong — D9 near-synonym : Clearing Account fait partie des GL configurations (Chart of Accounts) et se définit dans l'Org après save initial ; distracteur crédible pour qui confond le modèle financier.
Why E wrong — D7 non-existent : aucun champ Tax Code Rate n'est demandé à la création d'une Organization ; Tax Type et Tax Rate se configurent ensuite dans Taxes (Org-level après save).
- IBM Docs — Creating organizations : Mandatory fields
- Maximo Secrets — Organization setup : Base Currency + Sets
Correct: C
Why C — Dans Maximo Manage, Sets sont un niveau de stockage au-dessus des Organizations, conçu exclusivement pour partager 2 types de référentiels : (1) Item Set — le catalogue Item Master (items, rotating items, specifications) peut être partagé par N Organizations, évitant la duplication des codes items entre subsidiaries, (2) Company Set — le référentiel vendors/manufacturers (Companies) partagé entre Orgs pour uniformiser la base fournisseurs du groupe. Ces 2 Set types sont les seuls qui existent dans l'architecture Maximo — le modèle est fermé. Toutes les autres entités (Assets, Locations, Work Orders, PMs, Classifications, Hazards, Chart of Accounts…) sont scopées Organization ou Site, jamais en Set. Cette contrainte force la gouvernance : on peut partager "quoi est acheté" (items + vendors) mais pas "où ni comment" (assets, operations).
Why A wrong — D9 near-synonym : Chart of Accounts est une GL configuration Organization-level, pas un Set ; les structures comptables sont indépendantes par Org, pas partagées en Set.
Why B wrong — D3 wrong scope : Locations sont maintenues per Site — elles portent obligatoirement un SITEID et ne peuvent pas exister au niveau Set.
Why D wrong — D7 non-existent : il n'existe pas d'Asset Set dans Maximo. Les Assets sont Site-scoped. Distracteur tentant pour qui extrapole à tort depuis l'existence d'Item Set.
- IBM Docs — Creating Sets : Item Set + Company Set only
- Maximo Secrets — Sets and Organizations : Data sharing architecture
Correct order: 1 → 2 → 3 → 4
Why this order — La séquence lifecycle d'une Organization dans Maximo Manage suit un chemin strict imposé par les validations ORM : Étape 1 — Populer les 3 prérequis (Base Currency 1, Item Set, Company Set) — sans ces valeurs, le bouton Save reste grisé. Étape 2 — Sauver l'Org (INSERT dans MAXORG) avec status Inactive par défaut. Étape 3 — Créer au minimum un Site enfant avec Default Storeroom assigné — une Org sans Site activé ne peut transacter aucun WO ou inventory. Étape 4 — Cocher le flag Active sur l'Org (champ ACTIVE) qui la rend disponible pour les users et les transactions. Ordre inverse impossible : on ne peut pas activer une Org qui n'a pas été sauvée, et l'activation validée nécessite au moins un Site avec Default Storeroom. Logique d'intégrité data pour éviter les transactions orphelines.
- IBM Docs — Activating an organization : Lifecycle sequence
- Maximo Secrets — Organization activation : Save + activate mechanics
Correct: A
Why A — L'architecture Maximo définit quatre niveaux de stockage : System (table sans ORGID ni SITEID), Set (ITEMSETID ou COMPANYSETID), Organization (ORGID), Site (ORGID + SITEID). Les Assets, Locations, Work Orders, Inventory et Purchasing sont tous stockés au niveau Site — leur unicité est enforced par la clé composite (ASSETNUM + SITEID). Deux sites d'une même Organization peuvent donc avoir un asset PUMP-001 indépendant sans collision. Cette séparation par Site est le cœur de la data separation Maximo (vs Sets + Org qui font du data sharing). IBM Docs : « Assets and Locations must be unique within a Site ».
Why B wrong — D3 wrong scope : les Sets sont une catégorie spéciale au-dessus de l'Organization mais existent uniquement pour Item (partage du catalogue d'items) et Company (partage vendor). Aucun Asset Set ni Location Set dans Maximo — les Assets/Locations ne sont jamais partagés entre Organizations.
Why C wrong — D9 near-synonym : certaines tables SONT à Organization level (Hazards, Vendors, GL segments, PRS workflow). Un candidat peu attentif applique le même raisonnement aux Assets. Mais la règle Maximo est claire : tout ce qui est opérationnel transactionnel (WO, Asset, Location, Inventory) est Site-level ; tout ce qui est référentiel partagé (Hazard, Vendor) est Org-level.
Why D wrong — D6 wrong cardinality : System level existe bien (Classifications, Domains, Persons avant assignation) mais place les records à portée globale. Un Asset au niveau System signifierait un même pump partagé par toutes les Orgs — contraire aux besoins métier (chaque plant a ses propres assets physiques distincts). System est trop large pour Asset/Location.
- IBM Docs — Data storage levels for sites (MAM SaaS) : Asset/Location = Site level
- Maximo Secrets — Organizations and Sites (Portaluri, 2016) : Data separation architecture
- TRM — Establishing Organizations, Sites, and Sets (2023) : Multi-site deployment guide
- Giovani Pereira — Maximo Multisite Architecture Basics : System / Set / Org / Site levels
Configure organizational options (Site level)
📋 IBM Objectives
- Describe where application options are configured
- Identify where autonumbering is set up
- Identify Site-level Organization options
- Identify where shipment requirements can be configured
- Identify where reservations can be automatically created for approved WOs
💡 Key Points
- Autonumbering → Organizations app (Action → Autonumber Setup) ⭐
- Disable site = action "Make inactive" ⭐
- Shipment requirements → Organizations → Purchasing Options
- Auto-create reservations on approved WO → Organizations → Work Order Options → Reservation Requirements
🎯 Flashcard
Q. How can a site be disabled?
Show answer
Make the site inactive (not Delete, not Change status to decommissioned, not Move).
Correct: B
Why B — L'autonumbering (seeds + prefixes pour WONUM, PONUM, ASSETNUM, etc.) se configure dans l'application Organizations via 3 actions hiérarchiques du menu Select Action : (1) System Level Autonumber Setup — définit les seeds globaux (System scope), (2) Organization Level Autonumber Setup — override par Org, (3) Site Level Autonumber Setup — override par Site. Pour chaque objet numéroté (WORKORDER, PO, PR, ASSET, INVENTORY…), l'admin saisit : le seed (valeur de départ, ex: 10000), le prefix optionnel (ex: "WO-"), et l'increment (par défaut 1). Quand un nouveau WO est créé, Maximo cherche d'abord un seed au Site, puis Org, puis System. Cette hiérarchie permet de différencier visuellement les numéros par site (ex: WO-NYC-00001 vs WO-LA-00001).
Why A wrong — D1 legacy term : System Properties stocke les paramètres globaux (mxe.*) mais pas les autonumber seeds ; confusion historique avec Maximo 5-6.
Why C wrong — D3 wrong scope : Database Configuration définit les attributs de table (types, longueurs, persistence) mais pas les valeurs de sequence ; niveau structurel, pas runtime.
Why D wrong — D4 adjacent : Application Designer contrôle les layouts UI (onglets, fields visibility) ; aucun rapport avec la numérotation des records.
- IBM Docs — Autonumbering : System/Org/Site setup
- Maximo Secrets — Autonumber configuration : 3-level hierarchy
Correct: D
Why D — Pour retirer un Site opérationnel tout en conservant l'historique, la méthode IBM-supportée est de décocher le flag Active sur le Site (champ ACTIVE dans MAXSITE). Effets immédiats : (1) les users ne peuvent plus sélectionner ce Site dans leur dropdown Select Insert Site, (2) aucun nouveau WO, PM, PO, Inventory transaction ne peut être créé pour ce Site, (3) les records existants (WOs historiques, assets décommissionnés, labor transactions passées) restent intacts et consultables via searches Site = "retired plant". Cette approche "make inactive" préserve l'audit trail, la comptabilité (cost history), et les métriques pluriannuelles (MTBF historique). Supprimer un Site est interdit par Maximo dès qu'il existe des transactions — l'ORM bloque le DELETE pour intégrité référentielle.
Why A wrong — D9 near-synonym : les Sites ne portent pas de status RETIRED — le seul mécanisme est le flag booléen Active/Inactive ; distracteur crédible pour qui extrapole depuis les statuts Asset (ACTIVE/DECOMMISSIONED).
Why B wrong — D2 invented : l'application Domains gère les listes de valeurs (ALN, Numeric, Synonym, Crossover, Table domains) mais n'a aucune fonction "Archive Site" ; totalement fabriqué.
Why C wrong — D5 inversée : les Sites ne peuvent pas être détachés de leur Organization parent — la FK SITE.ORGID → ORGANIZATION.ORGID est immuable après création ; impossibilité architecturale.
- IBM Docs — Creating Sites : Deactivation via Active flag
- Maximo Secrets — Site lifecycle : Make inactive vs delete
Correct: B, C
Why B, C — L'application Organizations héberge des dizaines d'options, certaines scopées Organization, d'autres Site. Parmi les Site-level application options configurés dans Organizations, 2 exemples classiques IBM : (1) Automatically create reservations for approved work orders — dans Select Action → Work Order Options → Edit Rules, flag par Site qui déclenche la création automatique de reservations inventory dès qu'un WO passe à APPR, (2) Require shipment receiving for internal transfers — dans Select Action → Inventory Options, force la création d'un Shipment record lors d'un Site-to-Site transfer et oblige le receiving physique côté destination avant que le stock soit on-hand. Ces options sont par Site pour permettre des politiques différentes (ex: Site NYC applique reservations auto, Site LA non). La granularité Site permet de coller aux process locaux sans forcer une uniformité.
Why A wrong — D3 wrong scope : tax code defaults se configurent au niveau Organization (Taxes application, Org-scoped) pour assurer la cohérence comptable ; pas Site-level.
Why D wrong — D4 adjacent : Domains (ALN, Numeric, Synonym) est une application propre qui gère les value lists, indépendante des Work Order Options ; hors scope.
Why E wrong — D7 non-existent : API Keys est une application séparée pour gérer les credentials d'intégration externe ; n'a rien à voir avec les Site-level options dans Organizations.
- IBM Docs — Organizations Work Order Options : Site-level options list
- Maximo Secrets — Organizations settings : Org vs Site scopes
Correct: A
Why A — Le flag Automatically create reservations for approved work orders agit au moment exact où le WO transite vers status APPR (Approved) : Maximo scanne les items planifiés dans le Plans tab du WO et crée automatiquement des inventory reservations (records dans INVRESERVE) pour chaque item avec quantity prévue. Effet : le stock earmarked devient visible comme Committed dans l'inventory balance, le disponible baisse d'autant, les autres WOs ne peuvent plus réserver ces items (premier arrivé, premier servi). Si le stock est insuffisant, Maximo peut optionnellement auto-générer un PR (avec un autre flag). Sans ce flag, les reservations ne se créent qu'au premier Issue Items manuel. Cette automation évite les stockouts de WOs importants avalés par des WOs ad-hoc.
Why B wrong — D5 inversée : WAPPR = "Waiting for Approval", status antérieur à la validation hiérarchique ; pas de reservations car le WO n'est pas encore approuvé.
Why C wrong — D9 near-synonym : issuing consomme réellement le stock (décrémente CURBAL) ; reservation ne fait qu'earmarker sans toucher au balance. Confusion classique entre les 2 opérations inventory.
Why D wrong — D3 wrong scope : la génération de PR est un mécanisme direct issue / stockout séparé, déclenché quand un item WO n'est pas stocké — rien à voir avec l'auto-reservation.
- IBM Docs — Work Order Options auto-reserve : Reservations on APPR
- Maximo Secrets — Inventory reservations : Lifecycle reserve → issue
Correct: C
Why C — Activer Shipment Required pour les inter-site transfers transforme un transfer "one-shot" en workflow 3 étapes auditable : (1) Issue depuis le Site source — le stock quitte le source storeroom (Current Balance diminue) et crée un Shipment record avec status IN-TRANSIT, (2) Transit — physiquement, les items voyagent du Site source au Site destination, Maximo voit ce stock comme "en transit" mais pas on-hand, (3) Receive au Site destination — le receveur confirme réception via Shipment Receiving, le stock devient on-hand sur le destination storeroom (Current Balance augmente). Sans Shipment Required, le transfer est instantané (issue + receive simultané). L'option Shipment Required est critique pour la traçabilité, la gestion des écarts de livraison (damaged/missing), et la conformité comptable (valorisation en transit).
Why A wrong — D5 inversée : l'option introduit explicitement une étape de receiving, elle ne la bypasse pas — confusion sur le sens du flag.
Why B wrong — D9 near-synonym : le return-on-reject est un workflow distinct (Returns app) pour les réceptions de POs vendors défectueuses — sémantiquement adjacent mais pas lié à Shipment Required inter-site.
Why D wrong — D3 wrong scope : les inter-site transfers sont internes à une Organization — aucun vendor externe impliqué ; le distracteur confond avec les PO receipts.
- IBM Docs — Inventory Options Shipment Required : Issue-Transit-Receive
- Maximo Secrets — Inter-site transfers : Shipment workflow
Create & manage Security Groups
📋 IBM Objectives
- How user and person records get created · users must be linked to person records
- Where default security groups can be configured
- Permissions needed to add users to security groups
- How start centers are assigned to users
- How access is granted to applications · 4 default permissions
- 3 types of Object Data restrictions
- How multi-site access can be granted
💡 Key Points
- Chain: Person → User → Security Group → Start Center
- 4 app permissions: READ, INSERT, SAVE, DELETE ⭐
- 3 Object Data Restrictions: Qualified (WHERE), Conditional (expression), Hidden (invisible field) ⭐
- Multi-site access = always via security group
⚠️ IBM Trap
Correct order: Person → User → Security Group → Start Center
Why this order — La chaîne de security enablement Maximo est strictement hiérarchique : Étape 1 — Créer le Person record (People application) qui porte les données identité (nom, email, phone, locale, supervisor). Un Person est une entité business autonome, existe même sans accès Maximo (ex: craftworkers externes sur WOs). Étape 2 — Créer le User record (Users application) lié au Person via PERSONID. Le User porte le login (USERID), password, authentication method (local ou LDAP/SAML), et le lien au Person parent. Étape 3 — Assigner le User à ≥1 Security Group (Security Groups application) qui définit les permissions object-level (Read/Insert/Save/Delete), application-level (apps autorisées), Sites accessibles, ODRs (Optional Data Restrictions). Étape 4 — Associer un Start Center template au Security Group qui devient automatiquement le Start Center par défaut du User. Ordre inverse impossible : User sans Person = violation FK.
- IBM Docs — Security Groups : Enablement chain
- Maximo Secrets — Users, Persons, Groups : Creation sequence
Correct: A, B, C
Why A, B, C — Les 4 permissions object-level default dans Security Groups sont : READ (consulter les records), INSERT (créer un nouveau record), SAVE (modifier un record existant), DELETE (supprimer un record). Ces 4 primitives forment le CRUD basique de Maximo, accordées ou refusées indépendamment sur chaque business object (WORKORDER, ASSET, LOCATION, PO, etc.). 3 d'entre elles sont listées ici (READ, INSERT, DELETE — SAVE non listé). Granularité : on peut autoriser READ+SAVE sans INSERT (un user qui modifie mais ne crée pas), ou READ+INSERT sans DELETE (user qui ajoute mais ne supprime jamais). Au-delà des 4 default, certains objets exposent des sigoption spécifiques (ex: APPR sur WORKORDER pour l'approbation workflow) — ce sont des signature options, pas des permissions object-level standard.
Why D wrong — D2 invented : EXECUTE n'existe pas comme permission object-level Maximo ; confusion possible avec les OS/DB permissions.
Why E wrong — D9 near-synonym : APPROVE est une signature option (sigoption) attachée au workflow WORKORDER/PO, pas une permission object générique.
Why F wrong — D1 legacy : PUBLISH est un terme legacy issu de MIF (Maximo Integration Framework) pour publisher des messages vers external systems ; aucun lien avec object security.
Correct: A, B, C
Why A, B, C — Les Optional Data Restrictions (ODR) se configurent par Security Group et offrent exactement 3 types : (1) Qualified — restreint les rows visibles via une clause SQL WHERE (ex: "STATUS IN ('WAPPR','APPR')" sur WORKORDER), évite au group de voir les WOs terminés, (2) Conditional — restreint un champ basé sur une condition expression évaluée au runtime (ex: rendre un champ read-only si STATUS != 'WAPPR'), utilise le Conditional Expression Manager, (3) Hidden — retire un attribut de l'UI pour ce group (ex: cacher SALARY pour non-HR). Les ODRs se cumulent : un même group peut avoir une Qualified sur le table, une Conditional sur un field, un Hidden sur un autre field. Mécanisme : les ODRs filtrent dynamiquement les résultats de requête et les droits UI sans modifier le schéma sous-jacent ; les autres groups voient toujours les données complètes.
Why D wrong — D2 invented : "Read-only override" ne correspond à aucune catégorie ODR ; confusion possible avec Conditional qui peut rendre read-only.
Why E wrong — D9 near-synonym : le masking (afficher ***) est une feature data privacy portée par Database Configuration ou Automation Scripts, pas un ODR type.
Why F wrong — D7 non-existent : l'encryption est une feature Database niveau (TDE, column-level encryption) gérée hors du domaine ODR ; jamais une ODR category.
- IBM Docs — Data restrictions on Security Groups : Qualified / Conditional / Hidden
- Maximo Secrets — ODR configuration : 3 ODR types
Correct: B
Why B — L'accès multi-Sites se gère exclusivement via l'onglet Sites d'un Security Group. L'admin sélectionne le group, ouvre l'onglet Sites, ajoute chaque Site autorisé (BEDFORD, NASHUA) et coche éventuellement Authorize All Sites si l'accès doit être global. Chaque user assigné à ce group hérite automatiquement de l'accès à tous les Sites listés — aucune config per-user requise. Cette approche scalable permet de gérer 1000 users / 50 Sites avec une dizaine de Security Groups métier ("Technicien Multi-Site East", "Planner NYC+LA", etc.). Avantage majeur : quand un Site s'ajoute ou se retire, on modifie le group une fois au lieu de mettre à jour 200 users. Plus simple qu'une ODR Qualified sur SITEID, et IBM-idiomatique pour cette surface d'autorisation.
Why A wrong — D8 verbe imprécis : dupliquer les users par Site est un anti-pattern Maximo — multiplie les logins à gérer, brise l'audit trail, confond l'utilisateur. Explicitement déconseillé par IBM.
Why C wrong — D4 adjacent : le Person record porte email/phone/supervisor/locale mais ne contrôle aucun accès Site ; confusion de couche (Person = identité, Group = autorisation).
Why D wrong — D3 wrong scope : les ODRs se définissent exclusivement sur les Security Groups, pas sur les Users individuels — architecture de groupe, pas individuelle.
- IBM Docs — Sites for Security Group : Sites tab
- Maximo Secrets — Multi-site security : Sites granting patterns
Correct: D
Why D — Le modèle de sécurité Maximo sépare strictement 2 niveaux d'autorisation : (1) Application-level — autorise l'accès à l'UI d'une application (le user voit l'app dans le menu, peut l'ouvrir), (2) Object-level — autorise le CRUD sur les business objects manipulés par l'application. Ces 2 grants sont indépendants. Si un group a uniquement l'Application access à Work Order Tracking sans permission object sur WORKORDER, le runtime Maximo : ouvre l'app, affiche le layout, mais toute tentative de search retourne 0 rows (pas de READ), le bouton New Work Order est grisé (pas d'INSERT), Save échoue (pas de SAVE). L'user voit une coquille vide. Cette double barrière empêche les accès accidentels et force une autorisation explicite des données. Design voulu pour audit SOC2/ISO 27001.
Why A wrong — D5 inversée : l'héritage ne confère jamais de CRUD automatique — chaque permission doit être explicitement grantée ; principle of least privilege.
Why B wrong — D9 near-synonym : aucun READ implicite n'est accordé par le seul accès application ; distracteur tentant pour qui pense "au moins voir".
Why C wrong — D3 wrong scope : masquer l'app du Start Center exigerait de retirer le grant application-level, pas l'absence d'object-level permission — mécanismes distincts.
- IBM Docs — Application vs Object Security : Separate grants
- Maximo Secrets — Security layers : App + Object model
Correct: A, B
Why A, B — 3 types ODR, 2 filtrent row-level : Qualified (ajoute systematiquement WHERE à toutes queries, ex: STATUS IN ('WAPPR','APPR')), Conditional (expression runtime-évaluée, ex: row visible si :user = assignedto). Hidden ODR retire un attribut de l'UI (column-level).
Why C wrong — D3 wrong scope : Hidden ODR opère au niveau attribute/column (retire un field spécifique de l'UI pour le Security Group) — pas au niveau row. Scope de filtrage complètement différent des 2 row-level types (Qualified + Conditional).
Why D wrong — D9 near-synonym : Read-only = outcome d'un Conditional, pas type d'ODR distinct.
Why E wrong — D7 non-existent : il n'existe pas de "Masked ODR" type dans Maximo — le data masking est une feature séparée gérée par Database Configuration ou Automation Scripts (column-level privacy), indépendante du mécanisme ODR des Security Groups.
- IBM Docs — Data restrictions : Qualified / Conditional / Hidden
- Maximo Secrets — ODR patterns : Row vs column filtering
Create and manage Calendars and Shifts
📋 IBM Objectives
- Identify where calendars can be used
- Identify where availability can be modified
💡 Key Points
- Calendars used by: Labor, SLA, PM, Escalation, Scheduler
- Availability modified in the Calendars app (non-working time, holidays)
- Shifts: working hours within the day
Correct: C, D
Why C, D — Les Calendars dans Maximo Manage sont des records centraux (Calendars app) qui définissent les shifts, working hours et non-working days. Ils sont consommés comme input scheduling logic par plusieurs modules : (1) Preventive Maintenance (PM) — quand le PMWoGenCronTask calcule la prochaine génération, il saute les non-working days définis sur le calendar associé à l'asset/location pour éviter des WOs un jour férié ; frequency extended mode tient compte uniquement des working days, (2) SLA (Service Level Agreements) — l'elapsed time countdown (response/resolution) exclut les non-working hours si le SLA est configuré "Applies To Calendar" sur un calendar business hours (ex: 8h-17h Mon-Fri), un ticket créé vendredi 16h50 expirant "dans 2h" se résout en fait lundi 9h50. D'autres consumers : Labor availability, Escalations, Scheduler.
Why A wrong — D1 legacy : Database Configuration gère les attributs de table (types, longueurs, validation ALN), aucun lien avec les calendars.
Why B wrong — D4 adjacent : Application Designer gère les signature options UI, pas les calendars.
Why E wrong — D9 near-synonym : Domains valide les value lists (ALN, Numeric), jamais les dates calendar.
- IBM Docs — Calendars overview : PM + SLA consumers
- Maximo Secrets — Calendars in Maximo : Scheduling consumers
Correct: A
Why A — Marquer une date non-working (comme 25 décembre) se fait exclusivement dans l'application Calendars, via l'action Define/Apply Shifts ou Non-working Time du menu Select Action. Étapes : ouvrir le calendar concerné (ex: "Maintenance Crew Main Calendar"), Select Action → Non-working Time, ajouter une entrée avec date 2024-12-25, cocher "Entire day non-working", sauvegarder. À partir de ce moment, tous les consumers du calendar (PMs, SLAs, Labor availability, Scheduler) respectent automatiquement cette journée fermée. Les PMs scheduleés le 25 décembre seront repoussés au jour working suivant, les labor assignments ne prévoient personne, les SLAs excluent cette journée de leur countdown. Principe Maximo : centralisation — un seul point de mise à jour pour tout le calendar-aware logic.
Why B wrong — D4 adjacent : l'app Labor consomme les calendars (via Labor → Calendar assignment) mais ne permet pas d'éditer les non-working days ; lecture seule sur ce champ.
Why C wrong — D2 invented : aucune action "Seasonal Dates" n'existe dans PM — distracteur fabriqué pour piéger les candidats qui imaginent du per-PM tuning.
Why D wrong — D3 wrong scope : les non-working days vivent sur le Calendar record, pas au niveau Organization — une Org peut avoir N calendars différents (ops, admin, security 24/7) avec des non-working days distincts.
- IBM Docs — Defining shifts and non-working : Calendars app
- Maximo Secrets — Non-working days : Centralized calendar edit
Create and manage Labor, Crafts, and Crews
📋 IBM Objectives
- Purpose of Labor records · usage of Craft records
- Where premium pay codes can be configured on a Craft
- 3 types of premium pay codes
- Components of a Crew · how crew hourly rate overrides craft
- Required components on a Required Craft in a Crew
- Positions in a Crew · where new Crew Positions are created
- Where Crew Work Groups are created
💡 Key Points
- Labor = a person's work capacity | Craft = trade + rate (Electrician, Welder)
- 3 premium pay types: Percent, Amount, Rate ⭐
- Crew = Craft + Tools + Labor combination
- Flag "Use Crew Hourly Rate" overrides craft rate
- Crew positions: Craft, Tool, Labor
- Crew Types app → new positions | Crew Work Groups dedicated app
Correct: A, B, C
Why A, B, C — Les 3 seuls types de Premium Pay codes configurables sur un Labor record dans Maximo Manage sont : (1) Percent — multiplicateur appliqué au base rate (ex: 150% pour heures de nuit → si base $20/h, premium $30/h), (2) Amount — flat add-on en monnaie ajouté au base rate (ex: +$5/h pour shift de nuit → base $20/h devient $25/h), (3) Rate — replacement rate qui remplace complètement le base rate (ex: $35/h flat pour weekend → ignore le base $20/h). Ces 3 types couvrent les scénarios classiques de rémunération dérogatoire : majoration proportionnelle (Percent), prime forfaitaire (Amount), tarif spécial (Rate). Chaque premium pay code est attaché à une Skill ou craft combo et activé via un trigger condition (shift, holiday, emergency call-out). Piège IBM classique : nombre (3) et non-existence de "4e type" comme shift differential index fabriqué.
Why D wrong — D1 legacy : "Shift differential index" sonne familier mais n'est pas un type Maximo ; distracteur pour candidats pensant Oracle HR/SAP.
Why E wrong — D4 adjacent : Overtime code est une transaction payroll (tracked sur Labor Transactions) mais pas un type de Premium Pay — confusion de niveaux.
Why F wrong — D7 non-existent : « Hourly stipend » est une invention sans aucune correspondance Maximo — les 3 seuls Premium Pay types officiels sont Percent, Amount, Rate. Distracteur piège importé du vocabulaire HR/payroll générique qui ne s'applique pas au modèle de labor costing Maximo.
- IBM Docs — Premium Pay codes : Percent/Amount/Rate
- Maximo Secrets — Labor premium pay : 3 types model
Correct: A, B, C
Why A, B, C — Les Crew Types définissent des templates de crew avec 3 types de positions : (1) Craft — compétence métier requise (ex: Electrician Class A, Welder Level 2), une position Craft définit quantité + qualification level, le Craft est assigné sans user spécifique au niveau Crew Type, (2) Tool — équipement requis pour le travail du crew (ex: "2 crane 50T", "1 generator 100kW"), position Tool définit item + quantité, (3) Labor — position nominative pour un Labor spécifique si identifié au niveau template (rare mais permet de pré-assigner). Ces 3 types modélisent le qui + quoi d'un crew réutilisable. Quand une instance concrète de Crew est créée (Crews app), elle hérite des positions et les fills avec des Labor records spécifiques et des Tools réservés. Architecture type/instance classique : Crew Types = template, Crews = instance runtime.
Why D wrong — D1 legacy : Asset était une position dans Maximo 6-7 legacy mais retirée pour cohérence ; aujourd'hui un Asset est la cible du WO, pas la position du crew.
Why E wrong — D2 invented : Storeroom ne peut pas être position sur Crew Type — c'est un container inventory, pas une compétence.
Why F wrong — D3 wrong scope : Location est un référentiel topographique, pas une position de crew — sémantiquement incompatible.
Correct: C
Why C — Les définitions de positions (ex: nouvelle position "Rigger" avec 2 slots requis) se font exclusivement dans l'application Crew Types. Étapes : ouvrir le Crew Type concerné, onglet Positions, New Row, Position Type = Craft (ou Labor/Tool), Position = "Rigger", Required Quantity = 2, Craft = "Rigger Level II", Save. Cette définition devient template pour toutes les instances futures de crews qui héritent du Crew Type. Quand une instance de crew est créée dans Crews, elle affiche automatiquement les 2 positions Rigger à filler avec des Labor records spécifiques. Séparation stricte template/instance : Crew Types définit les positions (quoi est requis), Crews les fills (qui est affecté). Cette architecture permet de modifier le template (ajouter position Rigger) et propager aux futures instances sans toucher aux crews existants.
Why A wrong — D5 inversée : l'app Crews consomme le template Crew Type et ne définit pas les positions — sens renversé.
Why B wrong — D4 adjacent : l'app Labor gère les Person+Craft individuels mais ne crée pas les positions structurelles des crews ; hors scope.
Why D wrong — D2 invented : aucune "Crew Options" n'existe dans Organizations — totalement fabriqué.
- IBM Docs — Crew Types Positions : Adding positions
- Maximo Secrets — Crew templates : Positions workflow
Correct: D
Why D — Le flag Use Crew Labor Rate (aussi nommé "Crew Hourly Rate Override") se configure sur le Crew record individuel (Crews app). Quand activé, le costing engine utilise le crew hourly rate négocié plutôt que de sommer les rates individuels des Labor members. Cas d'usage : un crew de 4 techniciens avec rates variés (20+25+30+22 = $97/h théorique) mais le client a négocié un forfait de $85/h crew — le flag force l'utilisation de $85/h sur tous les labor transactions du crew, harmonisant la facturation. Sans ce flag, chaque Labor member est valué à son rate individuel, créant des incohérences entre charges client et coûts réels. Cette override est critique pour les contrats forfaitaires et permet une facturation prédictible indépendamment du mix exact de labor présent le jour J.
Why A wrong — D2 invented : "Calculated Crew Rate" est fabriqué — aucun tel flag sur Crew Types ; distracteur crédible.
Why B wrong — D4 adjacent : l'app Labor gère les rates individuels par Person, mais ne peut pas override au niveau crew ; ce flag est sur la table CREW, pas LABOR.
Why C wrong — D3 wrong scope : Premium Pay est par-Labor (majoration horaire individuelle) et ne remplace pas le costing crew — mécanisme différent, calculé en aval.
- IBM Docs — Creating crews : Use Crew Labor Rate flag
- Maximo Secrets — Crew costing : Rate override mechanics
Create and manage Domains
📋 IBM Objectives
- Domain types — decide which type fits a given scenario
- Add, modify, delete domains
- Org/Site-level restrictions for domains
- Conditions for domain values
- Where clauses for Table domains
- Source/target fields and conditions for Crossover domains
- Applying ALN domain to an attribute
💡 Key Points — 6 domain types
- ALN — alphanumeric list
- Numeric — discrete numeric list
- Numeric Range — min/max interval
- Table — SQL
where clauseagainst another table - Crossover — copies values from source to target on user selection
- Synonym — alternate values for same meaning (e.g. WO statuses)
⚠️ IBM Trap — Crossover vs Lookup
Correct: A, B, C
Why A, B, C — Maximo Manage supporte exactement 6 Domain types : (1) ALN — liste de valeurs alphanumériques fixes (ex: OPERATING, STANDBY), (2) Numeric — liste de valeurs numériques fixes (ex: 1, 2, 3, 5), (3) Numeric Range — intervalles numériques validés (ex: priority entre 1 et 9), (4) Table — valeurs pulled dynamiquement depuis une table Maximo avec Where Clause (ex: pick une Location active du Site courant), (5) Crossover — copy fields depuis un source table vers un target (ex: copy specs Item → WO), (6) Synonym — map des internal status codes vers external labels (ex: WAPPR ↔ "Waiting Approval" ou ↔ "En Attente"). 3 de ces 6 (Numeric Range, Crossover, Synonym) sont listés comme correct. Ces types couvrent tous les besoins de validation d'input : fixed lists, ranges, dynamic lookup, field propagation, code translation.
Why D wrong — D9 near-synonym : Lookup est un UI widget (le popup de sélection) qui peut consommer un domain Table, pas un domain type en soi ; confusion de couches.
Why E wrong — D2 invented : aucun "Boolean" domain — Maximo utilise l'attribute type YORN (Yes/No) au niveau Database Configuration, pas un domain.
Why F wrong — D1 legacy : Hierarchy n'est pas un domain type — c'est le modèle des Classifications (parent/child), application distincte.
- IBM Docs — Domains overview : 6 domain types
- Maximo Secrets — Domains in Maximo : Types catalog
Correct: C
Why C — Pour filtrer dynamiquement les records ASSET (status=OPERATING AND SITEID=current Site), il faut un Table domain avec Where Clause utilisant des bind variables. Configuration : Domain Type = TABLE, Object = ASSET, List Where Clause = status = 'OPERATING' AND siteid = :siteid, Value = ASSETNUM. Les bind variables supportées incluent :siteid (Site courant), :userid (user connecté), :app (app en cours), :orgid, et même :&owner;.fieldname pour référencer un champ de l'objet parent. Au runtime, Maximo substitue ces placeholders par les valeurs context. Résultat : le lookup n'affiche que les assets opérationnels du site courant, changeant automatiquement selon le Site de l'user. Cette dynamicité est impossible avec ALN (valeurs statiques) ou Synonym (mapping). La Where Clause est la clé de la flexibilité Table domains.
Why A wrong — D3 wrong scope : ALN domains ne gèrent que des listes fixes de strings — aucune filtration dynamique possible, le contenu est statique.
Why B wrong — D4 adjacent : Synonym domains translate des internal codes (ex: WAPPR) en external labels ("Waiting Approval") pour l'affichage multilingue, mais ne filtrent pas des rows — sémantique complètement différente.
Why D wrong — D9 near-synonym : un Table domain sans Where Clause renverrait toute la table — aucun filtrage de rows, inadapté à la exigence Site+status.
- IBM Docs — Table Domains : Where Clause + bind vars
- Maximo Secrets — Table domain examples : :siteid bind variable
Correct: D
Why D — Distinction fondamentale : un Lookup (widget UI) affiche un popup de sélection et copie une seule valeur dans un field unique quand l'user choisit un record (ex: pick un ItemNum → le field item_num se remplit). Un Crossover domain est un mécanisme de propagation multi-fields : quand une valeur source est sélectionnée, le Crossover copie automatiquement N fields additionnels depuis le source record vers le target record (ex: pick un Asset → copy classstructureid + location + priority + vendor simultanément). Chaque ligne du Crossover définit source_field → target_field. Optionnellement, une Copy Condition (expression booléenne) gate la copy : ne copier que si WO.worktype='CM'. Le Crossover est infiniment plus puissant pour la propagation de données cohérentes et pré-remplit tout un form en un seul pick. Maximo utilise des Crossovers extensifs (ex: picking un Asset sur un WO pré-remplit 10+ fields).
Why A wrong — D2 invented : Admin Mode n'est requis pour aucun des 2 ; les domains se modifient en runtime sans mise en Admin Mode.
Why B wrong — D6 cardinalité : Crossovers fonctionnent à tous les niveaux (Site, Org, System) comme les autres domains ; aucune restriction de scope.
Why C wrong — D5 inversée : c'est Crossover (pas Lookup) qui copie plusieurs fields — sens inversé.
Correct: A
Why A — Créer un domain (ALN, Table, Crossover, etc.) dans l'application Domains est seulement la première étape — le domain existe mais n'est attaché à aucun field. Pour le rendre effectif, il faut l'appliquer à l'attribute cible via Database Configuration : ouvrir Database Configuration → sélectionner l'objet (ASSET) → onglet Attributes → sélectionner l'attribute (CRITICALITY) → field Domain = "CRIT_LEVEL" → Save. Selon l'impact, Maximo peut exiger un passage en Admin Mode + Configure Database pour appliquer les changements structurels. Après binding, le CRITICALITY field expose un Select Value widget avec les valeurs du domain CRIT_LEVEL. Sans cette étape de binding, le domain existe en DB mais aucun field ne le consomme — erreur classique de l'admin qui oublie Database Configuration. Principe Maximo : création du domain ≠ activation, le binding explicite est obligatoire.
Why B wrong — D3 wrong scope : un Crossover copie entre objets, il ne peut pas appliquer un ALN list à un field ; mécanisme différent.
Why C wrong — D2 invented : aucune system property "refresh domain cache" n'existe — Maximo cache les domains au startup ou via l'app Domains directement.
Why D wrong — D4 adjacent : Security Groups gère les permissions, pas les domain bindings ; confusion de rôles applicatifs.
- IBM Docs — Modifying attributes : Domain binding
- Maximo Secrets — Domain binding workflow : Database Configuration step
Correct: C
Why C — Chaque ligne d'un Crossover domain supporte une Copy Condition (champ optionnel) qui porte une expression booléenne. Quand la condition évalue TRUE au moment où Maximo tenterait la copy, le field target est rempli avec le value du source ; quand FALSE, la copy est skippée et le field target conserve sa valeur existante. Syntaxe de l'expression : utilise le Conditional Expression Manager ou du code inline (ex: :worktype = 'CM', :status in ('WAPPR','APPR')). Dans notre cas : copy condition :worktype = 'CM' sur la ligne CLASSSTRUCTUREID → la classstructureid sera copiée depuis ASSET vers WORKORDER uniquement quand le WO est de type CM, ignorée pour EM/PM/INS. Ce mécanisme fin permet de modéliser des règles business complexes sans escalations ni scripts. Copy Condition est disponible sur chaque field row du Crossover, donc on peut avoir des règles différentes par field.
Why A wrong — D4 adjacent : ODR restreint la visibilité des rows par Security Group, pas l'exécution d'un Crossover — mécanismes orthogonaux.
Why B wrong — D3 wrong scope : Synonym domains mappent des codes (ex: WAPPR ↔ "Waiting"), ne gatent pas de copies — hors scope.
Why D wrong — D5 inversée : une Escalation réagit après la transition (post-event), elle ne peut pas empêcher une copy qui a déjà eu lieu ; directionnellement incompatible.
- IBM Docs — Crossover Copy Conditions : Conditional propagation
- Maximo Secrets — Crossover patterns : Copy Condition expressions
Correct: A, B
Why A, B — 2 domain types supportent Where Clause + bind vars : Table domain (ex: SELECT assetnum FROM ASSET WHERE status='OPERATING' AND siteid=:siteid), Crossover domain (lookup source Where Clause filtrée + Copy Condition par ligne). Bind vars: :siteid, :orgid, :userid, :app, :&owner;.fieldname. Ces 2 = data-driven (vs ALN/Numeric fixed lists, Synonym code mapping).
Why C wrong — D3 wrong scope : ALN = listes fixes strings, aucune Where Clause.
Why D wrong — D4 adjacent : Synonym domains mappent des internal codes vers external labels i18n (ex: WAPPR ↔ "Waiting Approval") — mécanisme de translation UI, pas de row filtering via WHERE clause. Scope fonctionnel distinct des Table/Crossover.
Why E wrong — D9 near-synonym : Numeric Range valide des intervalles numériques (ex: priority entre 1 et 9) via bornes min/max, sans capacity SQL ni Where Clause — validation statique pure, aucune dimension dynamique contextuelle.
- IBM Docs — Table Domains : Where Clause + bind vars
- IBM Docs — Crossover Domains : Lookup conditions
Database Configuration application
📋 IBM Objectives
- DB Config app functionality · attribute types · SAMEAS
- Persistent vs non-persistent objects/attributes
- Impact of enabling Admin Mode
- Object levels: system, org, site, sysorgsite
- E-Audit · E-Signature (synchronized user passwords as e-signature key)
- Multi-language · search types · relationships · lookup maps
💡 Key Points — Admin Mode
NOT REQUIRED for: Relationships, Domains, Automation Scripts, Workflows.
💡 Key Points — Other
- Object levels: SYSTEM, ORG, SITE, SYSORGSITE (most flexible)
- Persistent = DB column | non-persistent = runtime transient
- Attribute types: ALN, UPPER, LOWER, INTEGER, DECIMAL, DATETIME, YORN, BLOB, CLOB, AMOUNT
- Search types: EXACT, WILDCARD, NONE, TEXT
- E-Signature: uses synchronized password as signature key
⚠️ IBM Trap
"New Relationships require Admin Mode" = FALSE.
Correct: B, C, D
Why B, C, D — Maximo Database Configuration propose un catalogue fixe d'attribute data types, dont : (1) ALN — alphanumérique case-sensitive, (2) UPPER — string forcé en majuscules (ex: WONUM, ASSETNUM), case-insensitive, (3) LOWER — forcé en minuscules, (4) INTEGER — entier, (5) DECIMAL / AMOUNT — nombre décimal avec précision/scale configurable, (6) YORN — booléen représenté comme Y/N (1 char), (7) DATETIME / DATE / TIME, (8) CLOB — Character Large Object pour long text (descriptions, notes), (9) BLOB — Binary Large Object pour fichiers binaires attachés, (10) GL — special type pour General Ledger account composite. 3 des valides listés ici : YORN, UPPER, CLOB. Chaque type influence la validation, le storage, les index et les widgets UI disponibles.
Why A wrong — D1 legacy : ENUM est un concept SQL standard (PostgreSQL, MySQL) mais pas un type Maximo — les listes de valeurs passent par Domains (ALN + domain binding).
Why E wrong — D2 invented : aucun type JSONB dans Maximo Database Configuration — les structured data se gèrent via relations ou CLOB avec parsing applicatif.
Why F wrong — D9 near-synonym : "STRING" est le terme générique mais le type Maximo est spécifiquement nommé ALN (ou UPPER/LOWER selon case handling).
- IBM Docs — Attribute data types : Full type catalog
- Maximo Secrets — Database Configuration : Attribute types
Correct: D
Why D — La propriété SAMEAS dans Database Configuration établit un inheritance pointer (pointeur d'héritage) vers un autre attribute source. Quand un admin configure WORKORDER_NEW.REFERENCEID = SAMEAS(WORKORDER.WONUM), le nouvel attribute hérite dynamiquement de : (1) le data type, (2) la longueur, (3) le domain, (4) le default value, (5) les flags required/persistent. Si l'attribute source change (ex: WONUM passe de 8 chars à 15 chars), tous les attributes SAMEAS(WORKORDER.WONUM) héritent automatiquement de la nouvelle longueur — c'est le principe core de SAMEAS. Ce mécanisme est utilisé massivement dans Maximo pour les foreign keys : WORKORDER.ASSETNUM = SAMEAS(ASSET.ASSETNUM) garantit la cohérence de schéma entre parent et child. Sans SAMEAS, un changement de ASSET.ASSETNUM casserait les FK silencieusement. Principe DRY (Don't Repeat Yourself) appliqué au schema.
Why A wrong — D5 inversée : SAMEAS est inheritance live, pas un snapshot — les changements se propagent dynamiquement, l'inverse d'une copy one-time.
Why B wrong — D3 wrong scope : Crossover copie des valeurs entre records au runtime, pas des définitions d'attribute au niveau métadonnées ; domaines complètement différents.
Why C wrong — D9 near-synonym : Synonym est un domain type pour mapper code ↔ label, pas un attribute inheritance mechanism.
- IBM Docs — SAMEAS attributes : Inheritance pointer
- Maximo Secrets — Database Configuration : SAMEAS mechanics
Correct: A, B
Why A, B — L'Admin Mode est un état global de Maximo (toggled via Configure Admin Mode app) où tous les users sont déconnectés et les applications business sont verrouillées, permettant l'exécution de DDL sur les tables et indexes — opérations qui nécessitent des locks exclusifs incompatibles avec le runtime normal. Admin Mode est obligatoire pour : (1) Ajouter un nouveau persistent attribute à un objet existant — DDL ALTER TABLE ADD COLUMN, (2) Changer la longueur d'un attribute (ex: 20 → 40 chars) — DDL ALTER TABLE ALTER COLUMN. Aussi : créer un nouveau persistent object, dropper un attribute, changer le type de données. PAS besoin d'Admin Mode pour : Relationships (metadata-only, pas de DDL), Automation Scripts (runtime code), Domains (runtime lookups), Workflow processes (runtime metadata), Application Designer layouts (UI-only). Best practice : batcher tous les changements de schema dans une seule fenêtre Admin Mode.
Why C wrong — D1 legacy : les Relationships sont des metadata définissant des joins ORM — aucun DDL généré, pas d'Admin Mode requis.
Why D wrong — D3 wrong scope : Automation Scripts s'exécutent en Jython/Python au runtime, ne touchent jamais au schema DB — pas besoin d'Admin Mode.
Why E wrong — D4 adjacent : les Workflow processes sont stored comme metadata runtime dans WFPROCESS — aucun impact schema, aucun Admin Mode.
- IBM Docs — Configure Database : Admin Mode requirements
- Maximo Secrets — Admin Mode best practices : When required
Correct: A, B, C
Why A, B, C — Quand on crée un nouveau business object dans Database Configuration, Maximo demande de choisir un Object Level qui définit la granularité de scoping : (1) SYSTEM — l'objet est global, shared par toutes les Orgs et Sites (ex: Classifications, Domains, Persons), pas de ORGID ni SITEID colonnes, (2) ORG — scopé par Organization via colonne ORGID (ex: Vendors, Hazards, Chart of Accounts), (3) SITE — scopé par Site via ORGID + SITEID (ex: Assets, Work Orders, Inventory), (4) SYSORGSITE — objet hybride qui peut être System-level, Org-level ou Site-level selon le record (ex: certains Classifications ou Domains peuvent être system-wide ou org-scoped selon la config). 3 des 4 listés ici. Ce choix détermine les colonnes persistent auto-générées, les RLS virtuels, et comment les records sont filtrés par les Security Groups. Choix crucial et irréversible de design.
Why D wrong — D9 near-synonym : COMPANY n'est pas un object-level scope — c'est une entité métier (Company Set pour vendors), pas un niveau de stockage.
Why E wrong — D1 legacy : les Sets existent comme concept (Item Set, Company Set) mais ne sont pas un choix dans le picker Object Level — ils sont implicitement gérés pour Item et Company seulement.
Why F wrong — D2 invented : « GROUP » n'existe pas comme Object Level dans Database Configuration — la taxonomie officielle se limite à SYSTEM, ORG, SITE, SYSORGSITE. Confusion possible avec Security Groups (mécanisme de permissions, totalement différent des niveaux de stockage structurel).
- IBM Docs — Adding business objects : Object levels
- IBM Docs — Data storage levels : System/Org/Site/SysOrgSite
Correct: D
Why D — L'Electronic Audit (E-Audit) est la feature Maximo dédiée au logging chronologique complet des changements sur un object. Activation : Database Configuration → sélectionner ASSET → onglet Attributes → cocher E-Audit sur chaque attribute à tracker → Save + Configure Database (requires Admin Mode). Résultat : Maximo crée automatiquement une shadow table préfixée A_ (ici A_ASSET) avec mêmes colonnes + metadata audit (USERNAME, DATESTAMP, EAUDITCOLNAME, OLDVALUE, NEWVALUE, ROWSTAMP). Chaque UPDATE/INSERT/DELETE sur ASSET insère un row dans A_ASSET avec snapshot avant/après. Cette shadow table est interrogeable en SQL standard : un auditeur peut écrire SELECT * FROM A_ASSET WHERE ASSETNUM='PUMP-01' ORDER BY DATESTAMP pour voir tous les changements chronologiquement. Compatible SOX, ISO 27001, FDA 21 CFR Part 11. Coût : storage additionnel (~2x la table source selon la fréquence des changes).
Why A wrong — D9 near-synonym : E-Signature force une re-auth password au save (compliance) mais ne crée pas de log SQL-queryable — c'est un mécanisme d'authentification forte, pas d'audit trail.
Why B wrong — D4 adjacent : Workflow Administration history couvre uniquement les workflow nodes traversés, pas les field changes arbitraires sur ASSET.
Why C wrong — D5 inversée : HISTORYCLEANUP cron supprime l'historique (purge) plutôt que de le créer — direction opposée.
- IBM Docs — Electronic Audit : A_* shadow tables
- Maximo Secrets — E-Audit setup : Audit trail config
Correct: A
Why A — Chaque attribute dans Database Configuration porte un Search Type qui détermine comment l'UI traite les user inputs dans la search bar : (1) EXACT — equality seulement, aucun wildcard accepté (ex: input "PUMP" matche uniquement "PUMP", pas "PUMP-01"), (2) WILDCARD — le user peut taper "%PUMP%" ou "PUMP*" pour pattern matching, Maximo ajoute auto les % si absents, (3) TEXT — full-text search via index database (Oracle Text, PG tsvector) sur les colonnes CLOB ou long-descriptions, supporte stemming et phrase matching, (4) NONE — l'attribute est exclu du champ de recherche UI, pas queryable depuis la search bar. EXACT est utilisé pour les colonnes indexées avec équalité fréquente (WONUM, ASSETNUM, PONUM) pour performance — un wildcard sur 10M rows tue la query. WILDCARD pour description libre. TEXT pour notes longues. NONE pour colonnes internes (rowstamp, checksum).
Why B wrong — D3 wrong scope : TEXT est un vrai search type mais scope full-text sur CLOB/long-descriptions, pas un enforcement d'equality exacte — les 2 sont distincts.
Why C wrong — D9 near-synonym : NONE désactive complètement la search UI sur l'attribute — ne force pas exact match, retire juste la possibilité de chercher.
Why D wrong — D5 inversée : WILDCARD autorise les patterns % — c'est l'opposé de exact match.
- IBM Docs — Search types : EXACT/WILDCARD/TEXT/NONE
- Maximo Secrets — Search performance : Type selection guide
Correct: A, B
Why A, B — DB Config génère colonnes de scoping selon Object Level : SITE (ORGID + SITEID NOT NULL, uniqueness composite), SYSORGSITE (hybride : ORGID + SITEID nullable, permet existence à System/Org/Site). 2 des 4 niveaux ont SITEID. Choix irréversible, impacte RLS, queries, indexes.
Why C wrong — D3 wrong scope : SYSTEM level génère des objects globaux sans colonnes ORGID ni SITEID — aucun scoping par Organization ou Site. Records partagés entre tous les tenants, scope le plus large possible.
Why D wrong — D9 near-synonym : Object Level ORG génère une colonne ORGID seule (scoping par Organization), sans SITEID — distracteur tentant pour qui extrapole que tout objet Org-scoped aurait aussi SITEID. Faux : ORG = strictement ORGID, SITEID apparaît uniquement pour SITE et SYSORGSITE.
Why E wrong — D7 non-existent : SET n'est pas un Object Level user-selectable dans Database Configuration — les Sets (Item Set, Company Set) existent comme concept de partage de données mais sont implicites et limités aux objets Item et Company seulement, jamais choisis via le picker DBConfig.
- IBM Docs — Object levels : SITEID generation
- IBM Docs — Data storage levels : Column mapping
Correct: A, B, C
Why A, B, C — 4 Object Levels DB Config : SYSTEM (global), ORG (ORGID), SITE (ORGID+SITEID), SYSORGSITE (hybride nullable). 3 listés : SYSTEM, ORG, SITE. Choix crucial, irréversible. SITE = commun pour transactionnels (WO, Asset, Inventory).
Why D wrong — D1 legacy : les Sets (Item Set, Company Set) existent dans Maximo comme concept legacy de partage de référentiels entre Organizations, mais ne sont PAS user-selectable dans le picker Object Level de Database Configuration — implicites et limités à 2 objets spécifiques.
Why E wrong — D2 invented : GROUP n'est pas un Object Level Maximo — la taxonomie du picker Database Configuration se limite à SYSTEM/ORG/SITE/SYSORGSITE. Confusion possible avec Security Groups, appartenant à un domaine différent (permissions, pas stockage).
Why F wrong — D7 non-existent : DOMAIN n'est pas un Object Level Maximo — les Domains (ALN, Table, Crossover, etc.) sont des artefacts séparés de validation/lookup attachés aux attributes, pas un niveau de stockage structurel. Domaine fonctionnel complètement différent du scoping des objects.
- IBM Docs — Adding business objects : Object Level picker
- Maximo Secrets — Data architecture : 4 storage levels
Automation Scripts
📋 IBM Objectives
- Architecture and benefits of Automation Scripting
- Role of launch points and variables
- Usage for integration
- Implicit launch points: objects, appbeans, databeans
- Warning framework · automatic cleanup feature
💡 Launch Points (scenario → type)
- Validate a field on entry → Attribute
- Compute at save → Object
- Custom button on a menu → Action
- External JSON/XML data to manipulate → Integration ⭐
- Condition on a sig option → Custom Condition
- Pre/post-process publication → Publish Channel
- Implicit: Object, App Bean, Data Bean
⚠️ IBM Trap
Correct: A, B, C
Why A, B, C — Le Scripting Engine Maximo supporte 8 launch points, chacun correspondant à un event lifecycle distinct : (1) Object launch point — s'attache à un business object (ASSET, WORKORDER) et fire sur events save/init/delete (ex: valider un WO avant save), (2) Attribute launch point — fire quand une valeur de field spécifique change (ex: recalculer un total quand QTY change), (3) Action launch point — lance le script depuis un menu button UI (ex: custom report export), (4) Integration launch point — transform les payloads in/out (Enterprise Service inbound ou Publish Channel outbound), (5) Publish Channel launch point, (6) Custom Condition launch point, (7) App Bean launch point, (8) Data Bean launch point. Les 3 listés ici (Object, Attribute, Integration) couvrent les use cases les plus fréquents en extension Maximo.
Why D wrong — D1 legacy : Enterprise Service est un object MIF (inbound integration) sur lequel un script Integration launch point peut s'attacher — c'est le target, pas le launch point type.
Why E wrong — D4 adjacent : Escalations s'exécutent dans leur propre engine (Escalation cron), pas via le Scripting Engine ; engines distincts.
Why F wrong — D7 non-existent : aucun "Workflow Transition" launch point — les workflow events se gèrent via Condition nodes du workflow process, pas via scripts.
- IBM Docs — Script launch points : 8 types catalog
- Maximo Secrets — Automation Scripts : Launch point taxonomy
Correct: A
Why A — Pour transformer un payload JSON inbound avant que Maximo le parse, il faut un script avec Integration launch point attaché à l'Enterprise Service. L'Enterprise Service (ES) est le endpoint inbound du MIF (Maximo Integration Framework) qui reçoit les messages des systèmes externes (JSON via REST, XML via MEA, etc.). Le script Integration fire tôt dans la pipeline, AVANT le mapping vers les business objects : il peut parser le JSON brut, transformer/enrichir/valider les fields, renommer des keys, appliquer des lookups externes, avant que Maximo ne tente l'INSERT/UPDATE. Au contraire, un Publish Channel launch point gère le outbound (Maximo → système externe). La symétrie est volontaire : ES = inbound, Publish Channel = outbound, Integration launch point = les 2 selon attachement. Cette architecture découple le format externe du format interne Maximo.
Why B wrong — D3 wrong scope : Object launch point on Save fire après que l'integration a déjà parsé et mappé les données — trop tard pour transformer le payload brut.
Why C wrong — D9 near-synonym : Action launch point est triggered par un click user sur un button UI — aucun rapport avec un flux d'integration automatique.
Why D wrong — D5 inversée : Publish Channels sont outbound (Maximo publie vers externe), pas inbound.
- IBM Docs — Integration launch points : Inbound/Outbound scripts
- Maximo Secrets — MIF + Scripts : Enterprise Service hooks
Correct: B
Why B — Le Maximo Scripting Engine (basé sur JSR-223 Java Scripting API) supporte 3 langages out-of-the-box : (1) Jython — Python 2.7 syntax running sur la JVM (pas Python 3 natif) — le plus populaire dans la communauté Maximo pour sa syntaxe claire, (2) JavaScript (Nashorn) — moteur JS embarqué dans la JVM (déprécié en Java 11+ mais toujours supporté dans Maximo), (3) Groovy — langage dynamique type-safe qui offre la meilleure performance et la syntaxe la plus moderne. Tous 3 partagent la même Automation Script API (mbo, service, variables, MXException). Jython reste le choix par défaut IBM dans les exemples officiels mais Groovy gagne du terrain pour les scripts de production. Python 3 pur, Kotlin, Bash ne sont pas supportés — nécessiteraient une JAR custom (rarement fait).
Why A wrong — D2 invented : Python 3 natif n'est pas supporté ; Jython fournit la syntaxe Python 2.7 mais pas 3.x.
Why C wrong — D7 non-existent : les shells (Bash, PowerShell) ne sont pas supported — le Scripting Engine s'exécute dans la JVM, pas dans un shell OS.
Why D wrong — D9 near-synonym : Kotlin est un langage JVM moderne mais pas intégré au Scripting Engine par défaut ; distracteur plausible pour qui connait Kotlin.
- IBM Docs — Automation Scripts overview : Supported languages
- Maximo Secrets — Jython vs Groovy : Language comparison
Correct: C
Why C — Le Warning framework (méthodes mbo.addWarning() ou service.warning()) permet à un Automation Script de signaler un problème à l'user sans bloquer la transaction. L'user voit un message warning dans l'UI (icône jaune avec détails), peut réviser les données, puis décider de continuer (Save passes) ou corriger. Syntaxe Jython : service.warning("WARN-GROUP", "warningkey", ["param1", "param2"]) — le message est extrait du MAXMESSAGES par groupe/key, supportant l'i18n. Use case typique : valider qu'une due date est dans le futur et alerter si non, mais laisser l'admin override si légitime. Ce framework est l'alternative non-fatale au MXException classique qui rollback la transaction. Essentiel pour les règles soft (suggestions, recommendations) vs hard (contraintes métier dures).
Why A wrong — D5 inversée : raise MXException provoque un rollback complet de la transaction — fatal, l'user est bloqué ; l'inverse de "let them save".
Why B wrong — D8 verbe imprécis : service.error() est fatal (équivalent d'MXException) — bloque le save, incompatible avec "still let them save".
Why D wrong — D4 adjacent destination : le server log (System.out.println ou logger) écrit côté serveur, invisible à l'user final ; pas un mécanisme UI-level.
- IBM Docs — Script warnings : addWarning / service.warning
- Maximo Secrets — Warning vs Error : Non-fatal messaging
Correct: A, B
Why A, B — Les Automation Scripts exposent un système de variable bindings pour déclarer explicitement quelles données le script lit/écrit contre le Maximo context. 4 directions sont supportées : (1) IN — le script lit une valeur du context (ex: IN variable CURRENT_STATUS bound to WORKORDER.STATUS → le script peut lire status = CURRENT_STATUS), (2) OUT — le script écrit une valeur dans le context (ex: OUT variable NEW_PRIORITY bound to WORKORDER.WOPRIORITY → assigner NEW_PRIORITY = 1 met à jour le field), (3) INOUT — bidirectional read+write, (4) RETURN — capture la valeur de retour d'une Custom Condition. Le binding se déclare dans la config de l'Automation Script (pas dans le code), rendant les variables explicites et documentées. Bonus : le moteur nettoie automatiquement les variables implicites entre runs.
Why C wrong — D8 verbe imprécis : RETURN capture 1 valeur de retour (ex: true/false pour Custom Condition), pas tout le body — interprétation fausse.
Why D wrong — D6 cardinalité : INOUT variables sont disponibles sur plusieurs launch points (Object, Attribute, Integration), pas seulement Integration.
Why E wrong — D5 inversée : le Scripting Engine nettoie automatiquement les variables entre runs — pas de cleanup manuel nécessaire.
- IBM Docs — Script variables : IN/OUT/INOUT/RETURN
- Maximo Secrets — Variable bindings : Context + flow
Workflow Capabilities
📋 IBM Objectives
- Customize an existing Workflow Process · create new
- Elements of workflow process · how managed
- Configure (auto-initiate) · administer
- Sub-processes · node types
- Add workflow support to applications
- Workflow Assignment Role-Based app
💡 Node types
- Task = human assignment
- Manual Input = user decision (approve/reject)
- Subprocess = reusable workflow
💡 Config
- Configured: Workflow Designer | Administered: Workflow Administration
- Auto-initiate: workflow starts on record save
- Add workflow to app: Application Designer → Select Action → Add Workflow Support
⚠️ IBM Trap
Correct: A, B, C
Why A, B, C — Le Maximo Workflow Designer expose exactement 8 node types pour construire un process : (1) Start — point d'entrée obligatoire, unique par process, (2) Stop — point de fin, au moins un requis, peut y en avoir plusieurs, (3) Condition — évalue une expression booléenne et route sur 2 branches (positive/negative), (4) Task — assigne du travail asynchrone à un user/role (inbox notification), (5) Manual Input — prompte l'user courant inline pour une décision, synchrone, (6) Subprocess — invoke un workflow enfant réutilisable, (7) Wait — met le process en pause jusqu'à qu'une condition soit remplie (ex: attendre qu'un field change), (8) Interaction — guide l'user via une séquence UI. 3 des 8 listés ici (Condition, Task, Wait). Ensemble ils permettent de modéliser tous les workflows métier : approval chains, escalations, validations, intégrations.
Why D wrong — D4 adjacent : Escalations est un engine séparé (Escalation cron) qui monitore et agit sur des records selon des critères temporels ; pas un node type workflow.
Why E wrong — D1 legacy : Publish est un concept MIF (Publish Channel outbound integration), pas un workflow node.
Why F wrong — D9 near-synonym : "Approval" décrit un business concept implémenté via Task nodes avec completion codes POSITIVE/NEGATIVE — pas un type de node en soi ; confusion d'usage.
- IBM Docs — Workflow nodes : 8 node types
- Maximo Secrets — Workflow Designer : Node taxonomy
Correct: B
Why B — Distinction clé : Task node = asynchronous — quand le workflow atteint un Task node, il assigne une tâche à un autre user (via Role → Person/PersonGroup/Email), envoie une notification dans son inbox (application Workflow Inbox ou email), puis le process attend que l'assignee complete la task (click "Accept Approval" ou "Reject"). Le user initiateur n'est plus bloqué. Manual Input node = synchronous — prompte immédiatement l'user courant (celui qui a routed le workflow) avec une boîte de dialogue demandant une input (ex: "Enter the problem code"). Le process bloque en attente de la réponse dans la même session. Cas d'usage : Task = approval chain hiérarchique (plusieurs approvers séquentiels), Manual Input = collecte d'info manquante au fil de l'eau (moins lourd qu'une task routée). Les Task nodes implementent la logique d'assignation + escalation + delegation.
Why A wrong — D5 inversée : Task nodes ne sont pas integration-only — ils fonctionnent pour tous les user-facing scénarios, pas seulement intégrations.
Why C wrong — D2 invented : Task nodes enregistrent normalement les completion codes (POSITIVE, NEGATIVE, custom) — le contraire est faux.
Why D wrong — D6 cardinalité : Task nodes peuvent être assignés à tout Role résolvant vers Person, Person Group ou Email — même flexibilité que Manual Input.
- IBM Docs — Task nodes : Async vs sync
- Maximo Secrets — Task vs Manual Input : Node comparison
Correct: C
Why C — Maximo expose 2 applications complémentaires pour les workflows : (1) Workflow Designer — design-time authoring only, permet de créer/modifier les process, drag nodes, valider, activer ; pas de visibilité sur les instances runtime, (2) Workflow Administration — runtime monitor qui liste toutes les workflow instances actives (running, stopped, error), permet à l'admin de : reassigner une task à un autre user, arrêter manuellement une instance stuck, viewer l'historique complet des nodes traversés, diagnostiquer les erreurs (email failures, escalation misconfig). C'est l'outil de production indispensable quand un workflow se bloque (assignee parti en vacances, role vide, erreur de routing). Accessible aux admins via sigoption spécifique. Sans Workflow Administration, l'admin serait aveugle sur ce qui se passe en runtime — seule ressource : SQL direct sur WFINSTANCE/WFASSIGNMENT (non recommandé, pas d'UI d'action).
Why A wrong — D9 near-synonym : Workflow Designer peut créer/modifier les process mais ne peut PAS stopper les instances running ou reassigner les tasks — design-time seulement.
Why B wrong — D4 adjacent : Escalations est un engine distinct (temporal triggers), pas le runtime monitor des workflows.
Why D wrong — D2 invented : aucune application nommée "Workflow Instance Monitor" dans Maximo Manage — la console runtime s'appelle Workflow Administration. Distracteur construit par extrapolation d'un nom logique mais inexistant dans le catalogue d'apps IBM.
- IBM Docs — Workflow Administration : Runtime monitor
- Maximo Secrets — Workflow apps : Designer vs Admin
Correct: D
Why D — Le flag Auto-Initiate sur un Workflow process (cochable uniquement si le process est Active) provoque le déclenchement automatique du workflow à chaque création d'un nouveau record du target object. Ex: si le process ASSET-APPROVAL est Auto-Initiate, tout nouveau record ASSET inséré (via UI, import, API) déclenche immédiatement le workflow sans action user. Sans ce flag, l'user doit cliquer explicitement Route Workflow dans le menu Select Action pour lancer le process. Auto-Initiate est utile pour les workflows de validation systématiques (toutes les nouvelles Assets doivent passer une review) mais risqué s'il y a du noise dans la création (imports en masse qui lanceraient 1000 workflows simultanés). Best practice : combiner Auto-Initiate avec une Start Condition sur le workflow pour filtrer (ex: seuls les ASSETs avec PRIORITY=1 sont auto-initiated).
Why A wrong — D5 inversée : le trigger est la création du record, pas son approval — confusion temporelle.
Why B wrong — D7 non-existent : aucun artefact "Auto-Initiate Queue" dans Workflow Designer — totalement fabriqué.
Why C wrong — D8 verbe imprécis : Auto-Initiate ne boucle pas — il démarre le workflow une fois par création de record, rien de plus.
- IBM Docs — Auto-Initiate workflows : Creation trigger
- Maximo Secrets — Auto-Initiate patterns : Start conditions
Correct order: Create → Validate → Enable → Activate
Why this order — Un Workflow process doit passer par 4 phases strictes avant d'être consommable par les users : Phase 1 — Create : dans Workflow Designer, drag-drop des nodes (Start, Condition, Task, Stop), tirer les connections, configurer les roles et conditions. Le process est en status DRAFT. Phase 2 — Validate : clicking Validate Process, Maximo vérifie la cohérence structurelle (1 Start, au moins 1 Stop, tous nodes connectés, Conditions avec 2 branches, Task nodes avec Role assigné, etc.). Retourne errors/warnings si problèmes. Phase 3 — Enable : action Enable Process, le process devient disponible dans le system mais pas encore actif pour les users — permet le testing en mode test (initiated manuellement par admins). Phase 4 — Activate : action Activate Process, le process devient visible dans le Route Workflow dropdown pour les end users, avec optionnellement Auto-Initiate. Un process non-validated ne peut pas être enabled ; non-enabled ne peut pas être activated. Protection contre les workflows cassés en production.
- IBM Docs — Enabling workflow processes : Create/Validate/Enable/Activate
- Maximo Secrets — Workflow lifecycle : 4-phase authoring
Correct: B
Why B — La documentation officielle IBM Workflow Implementation Guide l'énonce littéralement : « Workflow assignments are made to Roles, and all roles resolve to a person, to a person group, or to an e-mail address ». Sur le Task node dans le Workflow Designer, le champ d'assignation pointe vers un record Role (application Roles). Au runtime, Maximo résout dynamiquement ce Role vers son destinataire final : une Person nommée, un Person Group (broadcast ou search logic), ou une adresse email externe. Cette indirection Role→Resolution est volontaire — elle permet de maintenir le workflow stable quand les effectifs changent (on met à jour le Person Group, pas le workflow). C'est aussi pourquoi la v7.5 a introduit les Assignee Relationships : plusieurs Assignment rows par Task node, chacun avec son propre Role.
Why A wrong — D9 near-synonym : Person est l'un des trois types de résolution possibles d'un Role (les deux autres étant Person Group et Email). Ce n'est pas ce que le Task node référence directement. Un candidat qui assimile « assignment » à « assigned person » choisira cette option par raccourci.
Why C wrong — D4 adjacent app : User (MAXUSER record) appartient au domaine de l'authentification / autorisation (login, password, security groups). Aucun rapport avec Workflow — on ne route pas un task à un User, on le route à un Role (qui résoudra vers une Person).
Why D wrong — D3 wrong scope : Person Group vit dans la hiérarchie de résolution du Role (niveau aval — une des 3 Resolution Types avec Person et Email), pas dans la hiérarchie d'assignation du Task node (niveau amont — occupée par Role). Avec broadcast=Y, chaque membre reçoit l'assignation ; sans broadcast, une search logic détermine qui reçoit. Mais le Task node ne pointe PAS directement vers un Person Group — il pointe vers un Role qui peut résoudre vers ce Person Group.
- IBM Workflow Implementation Guide (Maximo 7.6.1.2) : Role → Person / PersonGroup / Email resolution
- IBM Docs — Person Groups in Workflow Assignments : Broadcast vs search logic
- Maximo Secrets — Person Groups (Portaluri, 2017) : Person Group created to support Workflow
- Maximo Secrets — Roles (Portaluri, 2021) : Roles anatomy
- IBM APAR IJ31129 — Workflow PersonGroup default/alternates : Edge cases de résolution
Correct: A, C
Why A, C — Task et Manual Input sont les deux node types qui créent une assignation à un user dans un Workflow Maximo. Le Task est asynchrone (assigné via Role → Person/Person Group dans l'inbox de l'user), tandis que Manual Input est synchrone (requête immédiate de l'user courant, dans sa session). Les autres nodes (Start, Stop, Condition, Subprocess, Wait, Interaction) ne créent pas d'assignement.
Why B wrong — D3 : Condition node est un routing node avec branches positive/negative, pas un assignement.
Why D wrong — D7 non-existent as user-assigning nodes : Start et Stop sont des control-flow nodes terminaux (entrée et sortie du process graph) qui ne routent JAMAIS à un user — ils n'ont ni Role assignment ni user prompt. La question vise les nodes qui assignent une task à un user, ce que Start/Stop ne font par nature.
Why E wrong — D9 : Connection est la ligne entre deux nodes, pas un node.
- IBM Workflow Implementation Guide : Node types anatomy
- Maximo Secrets — Workflow category : Portaluri workflow tag
Correct: A, B
Why A, B — 2 nodes permettent branching : Condition node (évalue expression booléenne, 2 sorties pos/neg, ex: :priority=1 → Fast Track vs Standard), Task node (completion code choisi après action routing vers outgoing connection différente, jusqu'à N paths selon codes POSITIVE/NEGATIVE/custom). Condition = automatique, Task = user-driven.
Why C wrong — D3 wrong scope : Wait node met le workflow en pause jusqu'à qu'une condition soit remplie — une seule outgoing connection de sortie, aucun branching multi-path. Fonction de wait/hold, pas de routing.
Why D wrong — D9 near-synonym : Stop est le node terminal qui close le workflow instance — par définition il n'a aucune outgoing connection, donc incapable de router le process sur plusieurs paths (il ne route nulle part). Opposé fonctionnel de Condition qui branche.
Why E wrong — D4 adjacent : Subprocess invoke child workflow, 1 sortie retour, pas branching.
- IBM Docs — Workflow nodes : Condition + Task branching
- Maximo Secrets — Workflow design : Completion codes routing
Integration Framework
📋 IBM Objectives
- API Keys for Manage
- Object Structures: aliasing, include/exclude, security, flat structure, pagination
- Queries for object structures
- Create and manage object structure for integration and migration
- Configure JMS and KAFKA based queues
- Publish channels and Invocation channels
- Import and export data using MIF
💡 Key Points
- Object Structures: flatten, pagination, aliasing, include/exclude, security
- Queues: JMS (legacy) and Kafka (modern MAS)
- API Keys for MAS Manage auth
- Publish Channel = outbound | Invocation Channel = Maximo calls an external service
- MIF = Migration Integration Framework (XML/CSV import/export)
Correct: B
Why B — Dans Maximo Manage 9.0, l'authentification moderne des intégrations REST passe par les API Keys. Workflow : l'admin ouvre l'application API Keys, crée une nouvelle key associée à un User existant (User on behalf), définit l'expiration date (optional), save — Maximo génère un token opaque 32+ chars qu'il affiche UNE seule fois (l'admin doit le copier immédiatement, pas re-affichable). Le système externe utilise ce token dans le header apikey: {token} sur chaque requête REST. Maximo valide le token, récupère le User associé, applique ses Security Groups/ODRs. Avantages vs maxauth legacy : (1) pas de credentials en clair, (2) révocation sans changer le password user, (3) audit séparé par key, (4) expiration granulaire. Pour usage inter-systèmes, le recommandé IBM est 1 API Key par système intégré pour isolation.
Why A wrong — D1 legacy : maxauth header = Base64(user:password), mécanisme deprecated depuis MAS 8.0 pour la faiblesse sécurité (credentials en clair après décode).
Why C wrong — D3 wrong scope : mTLS ajoute une couche transport (certificats clients) mais ne remplace pas l'auth applicative ; les 2 sont complémentaires, pas alternatifs.
Why D wrong — D9 near-synonym : LDAP Bind authentifie les logins interactifs humains, pas les intégrations machine-to-machine ; hors scope intégration REST.
- IBM Docs — API Keys : REST authentication
- Maximo Secrets — API Keys setup : Token lifecycle
Correct: A, B
Why A, B — Les Object Structures (OS) sont le concept central du MIF pour définir les contrats de données échangés avec les systèmes externes. Features fournies : (1) Aliasing — permet de renommer les attributes pour le payload externe (ex: ASSET.ASSETNUM exposé comme assetId) sans changer le schema interne, (2) Flatten hierarchy — transforme la structure multi-level (MBO parent + child relations) en JSON plat, plus simple à consommer côté client externe, avec pagination configurable pour REST queries (page size, cursor), (3) Restrict Persistent/Non-persistent fields, (4) Include/Exclude Attributes, (5) Include children via Relations, (6) Inclusion de downline objects. Ces capabilities rendent les Object Structures très flexibles pour découpler le schema Maximo interne du contrat externe. Utilisés massivement pour MEA (Maximo Enterprise Adapter), REST APIs, et OSLC.
Why C wrong — D4 adjacent : OAuth 2.0 token generation relève de Security/API Keys apps, pas des Object Structures — couches différentes (auth vs data shape).
Why D wrong — D3 wrong scope : les scripts Jython s'attachent via Integration launch points séparés, pas inhérents aux Object Structures.
Why E wrong — D2 invented : aucune "Payload Rate Throttle" sur Object Structures — throttling est géré par le Web Server/Gateway, pas par l'OS.
- IBM Docs — Object Structures : Aliasing + flattening
- Maximo Secrets — MIF Object Structures : REST contract
Correct: D
Why D — Le Maximo Integration Framework (MIF) expose 3 artefacts principaux avec des directions distinctes : (1) Publish Channel = outbound events — quand un event Maximo se produit (ex: WO closed, Asset status changed), le Publish Channel sérialise les données et les envoie vers un external endpoint (queue Kafka/JMS ou REST endpoint). Mode push event-driven, (2) Invocation Channel = outbound REST calls — Maximo appelle activement un API externe pour get/post des données (ex: lookup address validation, sync customer data). Mode pull on-demand, (3) Enterprise Service = inbound — reçoit des données venant d'external systems via queue ou REST inbound endpoint, les parse, et met à jour Maximo (ex: recevoir des IoT readings, external WO requests). Ces 3 artefacts couvrent tous les patterns classiques : event streaming sortant, API calls sortants, data ingestion entrant. Kafka remplace JMS en MAS 9 et supporte les 2 directions.
Why A wrong — D5 inversée : exactement l'inverse — Publish est outbound, Enterprise Service est inbound.
Why B wrong — D2 invented : aucun "Bidirectional Bus" artefact dans le MIF — Publish et Invocation sont 2 channels outbound distincts.
Why C wrong — D6 cardinalité : Kafka n'est pas limité à inbound XML — supporte inbound/outbound, JSON/XML ; restriction fabriquée.
- IBM Docs — Integration channels : Publish/Invocation/Enterprise Service
- Maximo Secrets — MIF architecture : Direction mapping
Configuring Role-based Applications
📋 IBM Objectives
- Security configured for role-based applications
- Usage of Security Templates
- 3 access areas: Application Access · Object Security · Application Options
💡 3 access zones
- Application Access — who can open the app
- Object Security — data restrictions (Qualified/Conditional/Hidden)
- Application Options — visible/disabled menu items
Correct: A, B, C
Why A, B, C — L'application Role-Based Security (introduite en MAS 8+, modernisation des Security Groups classiques) gère 3 surfaces d'accès par role : (1) Application Access — quelles applications (Work Order Tracking, Assets, PO…) sont visibles/utilisables par le role, (2) Object Security — permissions CRUD (READ/INSERT/SAVE/DELETE) sur chaque business object manipulé, (3) Application Options — quelles sigoption spécifiques (APPR, RESERVE, CHGSTATUS) sont autorisées à l'intérieur d'une app. Ces 3 areas peuvent être packagées via Security Templates (bundles réutilisables) pour éviter la duplication entre roles similaires. C'est une vision plus role-centric que l'ancien Security Groups, alignée sur les RBAC modernes et plus lisible pour auditeurs SOC2/ISO 27001.
Why D wrong — D1 legacy : Workflow Administration est une app séparée pour le runtime monitoring des workflows, pas une access area du role-based security.
Why E wrong — D4 adjacent : Cron Task schedules sont configurés dans l'app Cron Task Setup, indépendamment de la security par role.
Why F wrong — D7 non-existent : "Integration API Keys" n'est pas une area du Role-Based Security — les API Keys sont scopées par User, pas par Role.
- IBM Docs — Role-Based Security : 3 access areas
- Maximo Secrets — Role-Based model : RBAC migration
Correct: D
Why D — Les Security Templates (Role-Based Security application) sont des bundles réutilisables de permissions qu'on configure une fois et qu'on applique à N Security Groups. Structure d'un Template : (1) set de Application Access entries (apps visibles), (2) set d'Object Security grants (CRUD permissions), (3) set d'Application Options (sigoptions autorisées). Use case : une organisation multi-sites avec 10 Security Groups "Technicien Site X" (un par site) peut créer un seul template "Tech Standard" avec toutes les permissions métier, puis l'appliquer aux 10 groups — si on ajoute une permission, on modifie le template et tous les groups héritent. Évite le drift de permissions, simplifie l'audit SOC2 (une source de vérité pour le role métier), réduit 10x le temps de maintenance. Best practice : templates par job family (Planner, Supervisor, Tech), puis Security Groups par Site/Org héritant du template.
Why A wrong — D3 wrong scope : Synonym domains mappent des status codes vers labels (ex: WAPPR ↔ "Waiting Approval"), aucun rapport avec les permissions.
Why B wrong — D4 adjacent : Workflow Assignments gère le routing des tasks workflow vers les users, pas les permissions applicatives.
Why C wrong — D2 invented : aucun Crossover "GROUP → APPAUTH" n'existe — totalement fabriqué, les Crossovers ne sont pas des security mechanisms.
- IBM Docs — Security Templates : Reusable permission bundles
- Maximo Secrets — Security Template patterns : DRY for permissions
Configure Operational Dashboards
📋 IBM Objectives
- Card types: Quick Actions · Favorites · KPI value · Table · External content · KPI Chart · KPI Comparison · Work Queues
- Related apps: Work Queue Manager · Workflow Assignments
- Create additional dashboards
💡 8 cards (memorize)
- Quick Actions
- Favorites
- KPI value
- Table
- External content
- KPI Chart
- KPI Comparison
- Work Queues ← list of records to act on ⭐
⚠️ IBM Trap
Correct: A, B, C
Why A, B, C — Les Operational Dashboards de Maximo Manage (nouvelle UX MAS) supportent exactement 8 card types pour composer des tableaux de bord opérationnels : (1) Quick Actions — boutons de raccourci pour initier des actions fréquentes (créer WO, log time), (2) Favorites — bookmarks personnalisés vers records/recherches, (3) KPI value — metric unique (nombre de WOs overdue), (4) Table — grille paramétrable (assets sous responsabilité), (5) External content — iframe vers URL externe (Grafana, SharePoint), (6) KPI Chart — visualisation graphique d'une KPI au fil du temps, (7) KPI Comparison — comparaison multi-KPIs ou multi-périodes, (8) Work Queues — listes actionnables de tâches assignées au user (queues métier configurées dans Work Queue Manager). 3 des 8 listés ici. Ces 8 primitives permettent de composer des dashboards role-based adaptés (Tech, Planner, Supervisor, Reliability Engineer).
Why D wrong — D2 invented : Classification Tree est une feature de l'app Classifications pour naviguer les hiérarchies UNSPSC/UniFormat, pas un dashboard card.
Why E wrong — D4 adjacent : Report Scheduler est une autre app Maximo (BIRT reports scheduling), pas un card dashboard.
Why F wrong — D9 near-synonym : "Escalation Console" sonne familier mais n'est pas un card type ; distracteur construit par extrapolation.
- IBM Docs — Dashboard card types : 8 card catalog
- Maximo Secrets — Operational Dashboards : Card composition
Correct: A
Why A — La combinaison Work Queues card + Workflow Assignments card sur un Operational Dashboard atteint exactement l'objectif : les techniciens voient leurs tâches assignées et peuvent agir sans naviguer. Work Queues (configurées via l'app Work Queue Manager) sont des listes métier actionnables de WOs/tickets filtrés selon des critères (assigné à moi, my site, priority high) avec des actions directes (assign, start, complete). Workflow Assignments card surface spécifiquement les workflow tasks en attente d'action par le user courant (approvals, manual inputs, reviews) — click une row pour compléter la task sans ouvrir Workflow Inbox. Ensemble, ces 2 cards transforment le dashboard en cockpit opérationnel : le tech ouvre Maximo le matin, voit "5 WOs à démarrer + 2 approvals en attente", action en 2 clicks. Réduit le time-to-action de 30s à 5s comparé à naviguer vers Work Order Tracking + Workflow Inbox séparément.
Why B wrong — D5 inversée : Workflow Designer est un outil design-time pour auteurs workflow, pas une surface actionable pour end users ; inapproprié comme External content.
Why C wrong — D6 cardinalité : une Table card seule sur ASSIGNMENT affiche les données mais n'a pas les action routing intégrées — Work Queues wrappent les actions métier.
Why D wrong — D3 wrong scope : KPI value card montre un count (ex: "5 WOs overdue") mais pas une liste actionable ; informatif seulement.
- IBM Docs — Work Queues on dashboards : Actionable lists
- Maximo Secrets — Dashboard composition : Work Queues + Assignments
Create and Manage Assets
📋 IBM Objectives
- Purpose of Asset application
- Linkable info: parent, location, vendor, status, custodian, maintenance cost
- Consequence of linking a Rotating Item to an Asset
- Asset Hierarchy
- Normal lifecycle: received, issued, returned, downtime, decommissioned
💡 Status transitions
- Receive → NOT READY
- Issue → OPERATING
- Return → NOT READY
- Downtime reported → DOWN
- Decommission → DECOMMISSIONED
🎯 Flashcard
Q. Initial status of a received asset (rotating item from PO)?
Show answer
NOT READY (OPERATING only after issue).
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: A
Why A — L'Asset record expose directement : Parent Asset (hiérarchie), Location (contexte spatial), Vendor (fournisseur d'origine), Status (lifecycle : NOT READY, OPERATING, DOWN, DECOMMISSIONED), Custodian (responsable de l'accountability), Maintenance Cost (coûts rollés depuis WOs). Ces attributs sont au header de l'Asset record, visibles dans le Main tab et exploitables en reports. Pas besoin de jointures tierces pour les récupérer.
Why B wrong — D9 near-synonym : Work Type et Crew sont des attributs du Work Order, pas de l'Asset.
Why C wrong — D3 wrong scope : Storeroom Bin s'applique aux Inventory items (par Storeroom + Bin) ; Contract Line Number est sur PO/PR lines.
Why D wrong — D4 adjacent : Priority/Failure Class/Job Plan/Safety Plan sont des attributs du Work Order Tracking / Failure Codes apps.
- IBM Docs — Assets overview : Asset attributes
- Maximo Secrets — Asset Management : App map
Correct: D
Why D — Les Rotating Items dans Maximo ont la particularité d'avoir un seul Item Master (ex: pump model P100) mais plusieurs Asset records individuels sérialisés (chaque pompe physique P100-001, P100-002...). Quand un rotating item est lié à un Asset, ce lien établit la traçabilité unique : Maximo suit chaque unité à travers les cycles issue → operating location → return to stock (reçu reconditionné) → re-issue. Critique pour les rotables (pompes, moteurs) qui alternent entre inventory et opérations multiples fois.
Why A wrong — D5 inverted : issue d'un rotating item passe l'Asset en OPERATING, pas DECOMMISSIONED.
Why B wrong — D2 invented : reorder point s'applique à l'Item record (stocké), pas à chaque Asset individuel.
Why C wrong — D3 wrong scope : costing method est sur l'Item/Storeroom, pas forcée par le rotating flag.
- IBM Docs — Rotating items : Serialized Assets
- Maximo Secrets — Rotating Items (Portaluri, 2020) : Lifecycle
Correct order: A → B → C → D
Why this order — Le cycle de vie standard d'un Asset rotating : OPERATING (mis en service dans sa location) → DOWN (reported downtime via action Report Downtime sur le WO) → NOT READY (retour en stock après downtime, en attente de décision repair/decommission) → DECOMMISSIONED (retirement définitif). IBM Docs codifie ces 4 statuses comme les transitions principales.
Why other orderings wrong — D5 inverted : DECOMMISSIONED ne peut précéder DOWN. D1 legacy : Maximo 4.x utilisait ACTIVE/INACTIVE.
⚠ VERIFY: Rotating initial status depends on Org-level "Enable Rotating NOT READY" toggle. This answer assumes default configuration (start = OPERATING).
- IBM Docs — Asset status : Lifecycle statuses
- Maximo Secrets — Asset : Status transitions
Correct: D
Why D — L'Asset Hierarchy matérialise les relations parent-child physiques ou logiques (ex: pump station → pump → motor → bearing). Elle permet les roll-ups : maintenance costs, failure history, WO counts agrégés du children vers le parent. Un reliability engineer peut ainsi voir le coût annuel d'un système complet sans recalculer manuellement. Le Rollup Maintenance Cost action (cf. S6.6) exploite cette hiérarchie.
Why A wrong — D4 adjacent : RBAC est géré par Security Groups, pas l'Asset Hierarchy.
Why B wrong — D3 wrong scope : reorder sequence est un concept Inventory Storeroom, pas Asset.
Why C wrong — D5 inverted : les coûts roulent UP (children → parent), pas DOWN.
- IBM Docs — Asset hierarchies : Parent/child structure
- Maximo Secrets — Asset management : Roll-up behavior
Correct: A, B
Why A, B — Lifecycle Asset : NOT READY (init) → OPERATING → DOWN, puis retirement via NOT READY (temporaire, remontable en OPERATING) ou DECOMMISSIONED (terminal, audit préservé, Historical pour queries). Progression soft permet réversibilité avant commit final.
Why C wrong — D9 near-synonym : INACTIVE est un flag booléen sur Locations, Sites, Persons — pas un status Asset. Asset utilise DECOMMISSIONED comme terminal status. Distracteur qui reutilise un nom similaire mais pour le mauvais type de record.
Why D wrong — D2 invented : OBSOLETE est un status reserved pour les Item records dans Inventory (item déprécié, plus commandable) — pas un status Asset. Asset utilise DECOMMISSIONED pour marquer fin de vie, scope différent.
Why E wrong — D7 non-existent : pas de DELETED — soft-delete via DECOMMISSIONED + Historical.
- IBM Docs — Asset statuses : Lifecycle statuses
- Maximo Secrets — Asset lifecycle : Retirement path
Create Meters and Meter Groups
📋 IBM Objectives
- Different Meter types
- Relation between Meters and Meter Groups
- Usage of different Meters
- Records a meter can be associated with: Asset, Locations, Condition Monitoring, Inspections
💡 3 meter types
- CONTINUOUS — cumulative (running hours, kilometers)
- GAUGE — instantaneous reading (pressure, temperature)
- CHARACTERISTIC — qualitative (oil color, noise level)
🎯 Flashcard
Q. Which meter type for running hours on a motor?
Show answer
CONTINUOUS
Correct: D
Why D — Maximo v9 supporte trois types de meters : Continuous (valeur cumulative strictement croissante — ex: run hours, km roulés), Gauge (lecture point-in-time pouvant monter/descendre — ex: pressure, temperature, voltage), Characteristic (valeur qualitative discrète — ex: color green/yellow/red, vibration low/medium/high). Chaque type a son comportement dans PM et Condition Monitoring.
Why A wrong — D2 invented : « Delta » et « Boolean » ne sont pas des Maximo meter types.
Why B wrong — D1 legacy : « Counter » est un terme générique non-Maximo ; Maximo utilise Continuous.
Why C wrong — D9 near-synonym : Analog/Digital décrivent les sensors hardware, pas les meter classes Maximo.
- IBM Docs — Meters overview : 3 meter types
- Maximo Secrets — Meters (Portaluri, 2022) : Meter anatomy
Correct: C
Why C — Les Meter Groups sont des templates réutilisables qui bundle plusieurs meter definitions ensemble (ex: « Pump Standard Meters » = Run Hours + Vibration + Flow Rate + Temperature). Quand l'admin ajoute ce Meter Group à un Asset ou Location, les 4 meters sont attachés en une seule action. Évite la répétition pour déploiements à grande échelle où des centaines d'assets partagent le même meter set.
Why A wrong — D8 imprecise : Meter Groups ne aggrègent pas des readings ; ils groupent des definitions.
Why B wrong — D4 adjacent : failure history vit dans Failure Reporting, pas Meter Groups.
Why D wrong — D3 wrong scope : security est gérée par Security Groups, pas Meter Groups.
- IBM Docs — Meter Groups : Template definition
- Maximo Secrets — Meters + Groups : Group usage
Correct: B, D
Why B, D — Les meters dans Maximo s'attachent directement à Assets et Locations pour la capture des readings (run hours d'une pompe, température d'une location de process). Ils sont ensuite consommés par Condition Monitoring (measurement points avec limits → WO trigger) et Inspections (inspection forms qui incluent meter reading fields pour structure des rounds). Les meters ne s'attachent PAS à PO/PR/SR.
Why A wrong — D3 wrong scope : POs portent lines et terms, pas meter readings.
Why C wrong — D4 adjacent : Desktop Requisitions sont pour item ordering, pas meter linkage.
Why E wrong — D9 near-synonym : Service Address est voisin de Location dans taxonomy mais n'est jamais un meter target.
- IBM Docs — Associating meters : Asset/Location targets
- Maximo Secrets — Meters + Condition Monitoring : Consumers
Correct: A, B
Why A, B — Rotating Items (ROTATING=Y) : (1) Serialisation unique — chaque unité physique a son Asset record avec ASSETNUM distinct (ex: Item PUMP-P100 + 50 assets P100-001 à P100-050), (2) Lifecycle cyclique issue/return — rotable peut cycler entre stock et operating (pompes, moteurs). Permet tracking MTBF par serial, lifecycle cost, reliability analytics.
Why C wrong — D3 wrong scope : cost posting sur issue = tous items, pas spécifique rotating.
Why D wrong — D2 invented : les rotating items participent normalement aux reorder rules (min/max, economic order quantity) comme tout item stocké — aucune exception au flag ROTATING=Y. La sérialisation par Asset n'enlève pas la dimension inventory classique.
Why E wrong — D9 near-synonym : aucune storeroom type "Rotating" dédiée dans Maximo — les rotating items peuvent vivre dans n'importe quelle storeroom standard. Le flag ROTATING=Y est sur Item Master, pas sur Storeroom.
- IBM Docs — Rotating Items : Serialized lifecycle
- Maximo Secrets — Rotating assets : Asset + item model
Failure Codes & Reliability Strategies
📋 IBM Objectives — Failure Codes
- Use of Failure Codes · information to create · hierarchies
- Records where Failure Code can be applied
- Failure Analysis using Failure Codes
📋 IBM Objectives — Reliability Strategies (v9)
- Reliability Strategies functionality
- Configure access: End Point + API route
- Review Reliability Strategy for an Asset class
- Create new strategies: Failure Modes, review process
- Assess effectiveness
💡 Key Points
- Failure Class hierarchy = Problems + Causes + Remedies (exact order) ⭐
- Duplicate Failure Code = copy entire hierarchy ⭐
- Reliability Strategies: industry-specific library (Centrifugal Pump API 610, etc.)
- Configuration: End Point + API route in System Properties
- Action types: PM, inspection, CBM, training, spare parts, redesign
⚠️ IBM Trap
Copy hierarchy = Duplicate Failure Code. NOT "Copy Failure Hierarchy".
Correct: C
Why C — Une Failure Class dans Maximo contient trois niveaux hiérarchiques : Problems (symptômes — quoi s'est-il passé, ex: « pump vibration »), Causes (cause racine — pourquoi, ex: « bearing wear »), Remedies (action corrective — comment réparé, ex: « replace bearing »). Le technicien sélectionne dans cette arborescence en closing de WO, ce qui alimente la RCA et le KPI reliability. Basé sur ISO 14224 pattern.
Why A wrong — D2 invented : Severity / Downtime / Resolution sont des attributs réels de WO (champs individuels) mais pas les niveaux hiérarchiques du Failure Code — la hiérarchie Maximo est strictement Failure Class → Problem → Cause → Remedy (modèle ISO 14224).
Why B wrong — D9 near-synonym : Symptom/Mitigation est proche conceptuellement mais pas la terminologie Maximo.
Why D wrong — D3 wrong scope : Asset et WO sont des objets liés, pas des niveaux internes à la Class.
- IBM Docs — Failure code hierarchies : Problem/Cause/Remedy
- ISO 14224 reliability standard : Failure taxonomy
Correct: D
Why D — L'action Duplicate Failure Code copie la Failure Class complète avec TOUTES ses Problems, Causes, Remedies dans une nouvelle Failure Class. Permet de cloner une library existante (ex: pour un nouveau site qui démarre, ou pour un variant de Asset class). Évite de re-saisir les 30-50 codes manuellement. Les liens vers les Assets/Locations et les WOs historiques NE sont PAS copiés — ce sont des relations transactionnelles.
Why A wrong — D6 cardinality : copier seulement le header rendrait la duplication inutile — le point-clé d'une Failure Class duplication est de reproduire la cascade Problem/Cause/Remedy complète (arborescence entière), pas juste l'enveloppe header vide.
Why B wrong — D2 invented : les liens Assets/Locations ne sont pas inclus dans la duplication.
Why C wrong — D3 wrong scope : les WOs historiques sont des records transactionnels immuables (audit trail) — Maximo n'offre aucun mécanisme de "cloning" pour alimenter un moteur Reliability. Les Reliability Strategies utilisent les failure codes agrégés, pas les WOs individuels dupliqués.
- IBM Docs — Duplicating failure codes : Duplicate action
- IBM Docs — Failure codes : Code management
Correct: A
Why A — Dans Maximo Manage 9.0, l'application Reliability Strategies est provisionée comme une containerized workspace via MAS Admin (Suite Administration). IBM documente que aucune configuration End Point / API route additionnelle n'est requise en v9 (c'était obligatoire en Manage 8.11 via End Point + Object Structure). Cette simplification rend le setup plus léger — le Suite Admin enable l'app et elle est immédiatement disponible aux Reliability Engineers.
Why B wrong — D2 invented : aucun cron task nommé « RELIABLECRON » n'existe dans Maximo — le cron Reliability effective s'appelle RELIABILITYSTRATEGY (ou similaire selon version). Piège sur la nomenclature exacte : les cron tasks Maximo ont des noms standardisés auxquels les admins sont tenus de se référer.
Why C wrong — D7 non-existent : MXINTEGRATION n'est pas le channel par défaut pour Reliability Strategies.
Why D wrong — D1 legacy : les CSV imports via RCM Planner legacy appartenaient au tooling Maximo pre-v9 (Maximo 7.6 + add-on RCM Navigator), retiré dans MAS 9.0 qui utilise maintenant Reliability Strategies natif avec d'autres chemins d'import (REST API, MIF Object Structure).
- IBM Docs — Reliability Strategies overview : Suite Admin deployment
- IBM Docs — What's New v9 : Integration simplification
Correct: B
Why B — Les Failure Modes capturent les modes de défaillance spécifiques d'un Asset : ex: « bearing seizure », « seal leak », « impeller cavitation » pour une pompe. Ils sont le socle de FMEA/RCM et drivent la conception de la reliability strategy (quelles tasks préventives pour empêcher chaque mode, à quelle fréquence). Un Asset peut avoir N Failure Modes, chacun avec sa severity et sa consequence métier.
Why A wrong — D9 near-synonym : Failure Reports sont des observations historiques, pas les mode definitions.
Why C wrong — D4 adjacent : WO templates créent du travail, pas la taxonomy failure.
Why D wrong — D2 invented : « Condition Rules » n'est pas un concept Reliability Strategies.
- IBM Docs — Failure Modes : Mode definition
- ISO 14224 — Reliability data collection : Failure mode standard
Correct order: A → B → C → D
Why this order — You first scope the review to an Asset or class, study its failure history and modes, apply changes, then track whether the revision improves reliability metrics.
Correct: A, C
Why A, C — Maximo définit trois types de meters (GAUGE, CHARACTERISTIC, CONTINUOUS). Le module Condition Monitoring crée des Measurement Points basés sur Gauge (numeric reading ex: pressure, temperature, vibration) ou Characteristic (discrete observation ex: color green/yellow/red). Les deux supportent upper/lower warning + action limits, et peuvent déclencher un WO auto via MeasurePointWoGenCronTask.
Why B wrong — D7 non-existent : « Analog » n'existe tout simplement pas dans l'enum Maximo des meter types (GAUGE / CHARACTERISTIC / CONTINUOUS seulement) — terme importé de la taxonomie electronics signals (analog/digital) qui ne s'applique pas au référentiel Maximo.
Why D wrong — D9 : Continuous est un type de meter réel (pour runhours / usage-based PM), mais PAS utilisé dans Condition Monitoring. Piège IBM classique — le candidat sait que Continuous existe, mais confond son usage.
Why E wrong — D2 invented : « Binary » n'existe pas comme meter type dans Maximo — l'enum Maximo est strictement GAUGE, CHARACTERISTIC, CONTINUOUS. Distracteur construit sur le vocabulaire binary/digital venu de l'électronique, étranger au référentiel Maximo.
- Maximo Secrets — Meters, Meter Groups and Condition Monitoring (Portaluri, 2022) : 3 meter types
- IBM Docs — Meter types : Gauge / Characteristic / Continuous
Correct: A, B, C
Why A, B, C — 3 transaction types impactent ON-HAND balance (INVBALANCES.CURBAL) : Issue (décrémente on consumption WO/location), Receipt (incrémente on PO reception ou return to stock), Transfer (source-destination storerooms net-zero global, balances per-storeroom changent). Reservations affectent AVAILBAL seulement (commit logique), pas CURBAL.
Why D wrong — D9 near-synonym : Reservation earmarke le stock (ajoute à Committed, décrémente Available) sans toucher le Current Balance on-hand — pas une transaction qui update ON-HAND balance, juste un commit logique sur AVAILBAL.
Why E wrong — D2 invented : "Cycle Count Freeze" n'existe pas comme inventory transaction type — confusion avec l'action de freeze pendant un count (verrou logique temporary), mais ce n'est pas une transaction qui update le balance.
Why F wrong — D4 adjacent : Lot Number Assignment est une feature de metadata tracking (traceability par lot/batch) attachée à des transactions existantes — pas une transaction indépendante qui modifie le balance inventory.
- IBM Docs — Inventory transactions : Issue/Receipt/Transfer
- Maximo Secrets — Inventory balance mechanics : On-hand vs reserved
Create and manage Item Master records
📋 IBM Objectives
- Item Master functionality · Rotating Item flag
- IAS (Item Assembly Structure)
- Add Item(s) to a storeroom · Purchasing options on Item Master
- What an Item Kit is
💡 Key Points
- Rotating flag = serialization + asset link (spare pump = unique asset)
- IAS = Item Assembly Structure = hierarchical BOM
- Item Kit = bundle issued together under one item ID
Correct: D
Why D — Le flag Rotating sur un Item Master déclenche un comportement crucial : à chaque receipt d'une unité physique, Maximo auto-génère un Asset record sérialisé (ASSETNUM unique). Permet de suivre chaque unité individuellement à travers maintenance, refurbishment, re-use. Inverse du stocked item (balance quantitative simple). Critique pour rotables qui boucle entre inventory ↔ operations (moteurs, pompes, instruments).
Why A wrong — D5 inverted : rotating items peuvent tout à fait être reordered ; le flag ne les exclut pas de reorder.
Why B wrong — D6 cardinality : les canaux d'issue (direct, reservation-based, WO-driven) restent inchangés par le Rotating flag — ils s'appliquent à tous les items. Seule la dimension sérialisation (unique Asset record) différencie les rotables.
Why C wrong — D2 invented : warranty auto-inheritance depuis Contracts n'est pas un side-effect du rotating flag.
- IBM Docs — Rotating items : Flag behavior
- Maximo Secrets — Rotating Items (Portaluri, 2020) : Full lifecycle
Correct: A
Why A — L'Item Assembly Structure (IAS) est le Bill-of-Materials Maximo : une hiérarchie parent-child d'items définissant les components d'un Asset ou d'un item top-level. Exemple : pump IAS = body + impeller + seal + bearing + gasket. Sert de template pour configurer spares sur Asset, propager warranty terms, et construire les preventive maintenance tasks qui nécessitent ces components. Distinct d'Item Kit (un bundle physique issued comme un tout).
Why B wrong — D2 invented : aucun cron task d'aggregation automatique pour Item Assembly Structure (IAS) — l'IAS définit la structure parent/child d'item mais ne déclenche pas de cost rollup via cron. Le costing des IAS est calculé à la demande ou via actions manuelles, pas de background job dédié.
Why C wrong — D9 near-synonym : IAS ≠ Item Kit. IAS est un BOM (hierarchie), Kit est un bundle physique.
Why D wrong — D3 wrong scope : la security access au inventory est gérée via Security Groups (Application Access + Object Security sur INVENTORY), pas via un mécanisme flag item-level. Couches orthogonales : flag = behavior, Security Groups = permissions.
- IBM Docs — Item Assembly Structures : IAS BOM
- Maximo Secrets — Items : Item anatomy
Correct: B
Why B — Un Item Kit est un bundle de components pre-assemblés, issued ensemble comme une seule unité. Exemple : « Pump Gasket Repair Kit » = 1 gasket + 4 bolts + 1 tube sealant — un seul item_num visible dans l'UI, mais décomposé en sub-items pour inventory tracking. Utile pour simplifier planning (le WO demande le Kit, pas les 3 components séparés) et issue (une seule transaction au storeroom).
Why A wrong — D3 wrong scope : price comparison est RFQ concern, pas Kit définition.
Why C wrong — D9 near-synonym : Kits ne sont pas des rotating hierarchies (pas de serial unique).
Why D wrong — D2 invented : Kits ont un vrai physical count, pas des virtuals.
- IBM Docs — Item Kits : Kit definition
- Maximo Secrets — Items : Kit vs IAS
Configure Inventory Settings and Processes
📋 IBM Objectives
- Inventory functionality · Reorder process · Reorder Lock
- Reservations process · reservation types
- Adjustment options · cost methods
- Org-level settings: Negative Balance, Count Books options
💡 Key Points
- Reorder Lock = prevents concurrent reorder runs (avoids duplicate PRs)
- Reservations: HARD (stock blocked immediately), SOFT (planned), AUTOMATIC (auto on WO approved)
- Cost methods: LIFO, FIFO, AVERAGE, STANDARD
- Adjustments: Physical Count, Current Balance, Reconcile Balances
- Org settings: allow/prohibit Negative Balance, Count Books options
Correct: A
Why A — Le Reorder Lock sérialise les exécutions de reorder sur un storeroom — prévient qu'un run manuel et le cron PIRE (Inventory Reorder) ne créent des PRs dupliquées pour le même item. Quand un user lance le reorder, le lock est acquis sur le storeroom ; toute autre tentative (manuelle ou cron) attend la fin. À la completion, le lock se libère. C'est un mutex applicatif, pas un lock DB.
Why B wrong — D3 wrong scope : cost methods sont contrôlées au niveau Organization, pas via Reorder Lock.
Why C wrong — D8 imprecise : le lock ne fige pas le reorder point ; il prévient le concurrent processing.
Why D wrong — D2 invented : la fermeture de storeroom (flag DISABLED sur Storerooms) n'a aucun lien avec ce lock mechanism — ce sont 2 mécanismes distincts. Confusion possible entre lock de transaction et soft-delete d'une storeroom entière.
- IBM Docs — Reordering items : Reorder Lock
- Maximo Secrets — Inventory : Reorder flow
Correct: B
Why B — Les trois reservation types Maximo : HARD (commit immédiat de la quantity — bloque les autres consumers, garantit disponibilité), SOFT (placeholder réservant l'intention sans décrémenter available), AUTOMATIC (système détermine selon WO status + item settings, typiquement HARD à partir de APPR). Cette distinction permet au planner de choisir entre engagement ferme (HARD) et intention légère (SOFT) selon la maturité du WO.
Why A wrong — D2 invented : FIXED / FLOATING / DEFERRED sonne technique mais n'appartient à aucune taxonomie Maximo — les reservation types officiels sont HARD, SOFT, AUTOMATIC. Distracteur construit sur vocabulaire imaginé générique ERP.
Why C wrong — D4 adjacent : STAGED / SHIPPED / COMPLETED sont des Inventory Usage statuses (pipeline d'un Usage document) — app adjacente mais concept différent des reservation types qui eux classifient le type de commit sur le stock.
Why D wrong — D9 near-synonym : Primary/Secondary est un concept de storeroom bin, pas reservation.
- IBM Docs — Inventory reservations : HARD/SOFT/AUTOMATIC
- Maximo Secrets — Inventory Reservations (Portaluri, 2021) : Reservation types
Correct: A, B, D (STANDARD is also valid but not offered)
Why A, B, D — Les 4 inventory cost methods supportés par Maximo : LIFO (Last-In First-Out — nouveau coût sur issue), FIFO (First-In First-Out — plus ancien coût issued d'abord), AVERAGE (moving average recalculé à chaque receipt), STANDARD (coût fixé, variances postées séparément). Sélection au niveau Item ou Storeroom selon le modèle finance choisi par l'Org. NB : Average est default sur nouveaux Item Sets (cf S2.2 Q10).
Why C wrong — D2 invented : « Weighted Periodic » n'est pas un Maximo option.
Why E wrong — D9 near-synonym : MARGINAL est un concept d'economics, pas une cost method Maximo.
Why F wrong — D7 non-existent : EXPONENTIAL n'est pas un type de dépréciation offert par Maximo — les méthodes supportées standardement sont Straight Line (linéaire), Declining Balance (dégressive), Sum-of-Years-Digits, Units-of-Production. La courbe exponentielle n'a aucun modèle fiscal largement adopté qui la justifie comme option.
Correct: D
Why D — Les options Negative Balance (autoriser les balances négatives temporairement) et Count Books (enable le workflow count book pour inventory counting) sont configurées au niveau Organization via Organizations → More Actions → Inventory Options. Policy uniforme à tous les sites de l'Org. Cette centralisation évite les incohérences de policy inter-sites qui affecteraient la consolidation financière.
Why A wrong — D3 wrong scope : Storerooms consomment ces settings mais ne les définissent pas.
Why B wrong — D6 cardinality : appliquer ce flag au niveau item serait trop granulaire pour une policy organisationnelle — l'admin doit configurer des milliers d'items un par un, anti-productif. La policy vit au niveau Organization (uniforme pour tous les items).
Why C wrong — D4 adjacent : System Properties héberge des flags techniques, pas des policies inventory.
- IBM Docs — Organizations Inventory Options : Org-level policies
- Maximo Secrets — Inventory : Settings map
Inventory Usage application
📋 IBM Objectives
- Inventory Usage functionality · types · statuses
- Split Usage quantity feature · Auto-Split feature
💡 Key Points
- Types: ISSUE, RETURN, TRANSFER
- Statuses: ENTERED → STAGED → SHIPPED → COMPLETE (or CANCELLED)
- Split Usage: split a line into multiple (e.g. 10 items → 7+3)
- Auto-Split: automatic by available storeroom/bin
Correct: B
Why B — L'application Inventory Usage (table MATUSETRANS) gère trois types : ISSUE (matériel sort du storeroom vers un WO/user), RETURN (matériel revient au stock depuis un WO non-consommé), TRANSFER (mouvement entre storerooms — peut transiter par SHIPPED statut pour transferts inter-site). Ces trois types couvrent le cycle opérationnel du stock en usage quotidien.
Why A wrong — D4 adjacent : Receipt / Inspection / Put-Away sont les phases du flux Receiving (table MATRECTRANS) — app adjacente au Inventory Usage, mais sémantique distincte. Usage concerne consommation sur WO, Receiving concerne réception PO.
Why C wrong — D3 wrong scope : Issue est valide mais Receipt + Count sont dans autres apps (Receiving, Physical Count).
Why D wrong — D9 near-synonym : Reserve / Stage / Ship sont des statuses d'inventory Usage documents (pipeline de l'Usage), pas des Usage types (qui classifient la nature : Issue, Return, Transfer). Confusion entre status et type.
- IBM Docs — Inventory Usage : 3 types
- Maximo Secrets — Inventory Usage overview (Portaluri, 2020) : Usage flow
Correct: C
Why C — Le status flow d'un Inventory Usage record : ENTERED (drafté par l'opérateur, modifiable) → STAGED (items mis de côté physiquement, soustraits de l'available balance) → SHIPPED (pour transfers inter-storeroom, in-transit) → COMPLETE (transaction posted au GL, balance finale actualisée, audit trail gelé). Chaque transition peut déclencher des automations (alerts, réservations) configurées par l'Organization.
Why A wrong — D1 legacy : DRAFT / APPROVED / ISSUED / CLOSED sont des statuses Work Order classiques (pipeline de production du WO), pas des Usage statuses. Confusion probable avec les Tool Usage records qui ont leur propre enum status : ENTERED, APPROVED, COMPLETE.
Why B wrong — D9 near-synonym : OPEN / RESERVED / PICKED est une séquence familière de Warehouse Management Systems (WMS comme SAP EWM, Manhattan) — pas la taxonomie Maximo Inventory Usage (ENTERED, APPROVED, COMPLETE). Import d'un autre produit.
Why D wrong — D2 invented : NEW / PENDING / POSTED / ARCHIVED est une séquence générique ERP/CRM qui ne correspond à aucune taxonomie Maximo — les Usage statuses standards sont ENTERED, APPROVED, COMPLETE. Distracteur tentant pour candidat importing conventions d'autres systèmes comptables.
- IBM Docs — Inventory Usage statuses : Status flow
- Maximo Secrets — Inventory Usage overview (Portaluri, 2020) : Status transitions
Inventory Mobile Applications
📋 IBM Objectives
- 3 mobile apps: Inventory Counting · Issues and Transfers · Inventory Receiving
- Inventory Counting: Ad-hoc Count · Count Books
- Issues and Transfers: features, reservations, ad-hoc additions
- Inventory Receiving: POs, Shipments
💡 Key Points
- Ad-hoc Count: unplanned, does NOT support rotating items
- Count Books: planned, supports rotating items, reconciliation on server
- Issues and Transfers: feature Issue for planned materials ⭐
- Transfers can create shipment records
- Reservations: planned material OR desktop requisition
- Receiving: POs (inspection supported), Shipments
⚠️ IBM Trap
Correct: C
Why C — La Mobile Inventory suite de v9 comprend trois apps distinctes : Inventory Counting (physical counts ad-hoc + count books), Issues and Transfers (issues planifiées sur WOs + transferts inter-storeroom), Inventory Receiving (réception PO + inspection + put-away). Ces apps s'exécutent sur Maximo Mobile (iOS/Android) et sync offline — essentielles pour les storerooms éloignés ou les field crews qui ne peuvent pas accéder à l'UI desktop.
Why A wrong — D7 non-existent : Mobile Storeroom / Mobile Requisitions / Mobile RFQ ne sont pas des apps livrées.
Why B wrong — D4 adjacent : Mobile Assets/Meters/CM appartiennent à la Mobile Technician suite, pas Inventory.
Why D wrong — D3 wrong scope : Mobile WO/PM/Safety sont dans la Mobile Maintenance suite, pas Inventory.
- IBM Docs — Mobile Inventory : 3 apps suite
- Maximo Secrets — Mobile Inventory Receiving : Mobile apps
Correct: D
Why D — L'Ad-hoc Count dans Mobile Inventory Counting est volontairement limité aux items non-rotating (stocked standard). Les rotating items nécessitent une validation de chaque serial number, qui requiert Count Books avec serveur-side reconciliation. Ad-hoc est pensé pour des counts rapides de consommables (boulons, gaskets) où la quantity suffit ; les rotables (pompes sérialisées) passent obligatoirement par Count Books structurés.
Why A wrong — D5 inverted : ad-hoc NE supporte PAS les rotating items, c'est précisément la limitation testée.
Why B wrong — D7 non-existent : aucun record « Temporary Count Sheet » n'est créé ; les ad-hoc counts écrivent les adjustments directement sur l'item record.
Why C wrong — D2 invented : ad-hoc fonctionne aussi offline sur mobile (sync au retour).
- IBM Docs — Ad-hoc counting : Limitations
- Maximo Secrets — Inventory Counting : Mobile counting
Correct: A
Why A — Les Count Books supportent bien les rotating items : le mobile capture les serial numbers physiques scannés (barcode/NFC), et le serveur reconcilie ces serials contre les Asset records enregistrés en DB (match + detection des discrepancies : serial présent mais attendu ailleurs, serial manquant, serial inconnu). Cette reconciliation server-side est critique car elle exploite la relational logic et l'audit trail complet, impossibles à faire côté mobile offline.
Why B wrong — D5 inverted : seuls les ad-hoc counts excluent les rotating, pas les Count Books.
Why C wrong — D6 cardinality : tous les serials sont comptés, pas seulement le premier.
Why D wrong — D3 wrong scope : la cost recalculation (rollups, averaging, FX conversion) est pilotée côté serveur par les routines Maximo internes, pas exposée à l'utilisateur final via un bouton UI. L'user ne touche jamais aux recalculs comptables directement — il modifie les données sources.
- IBM Docs — Count Books : Rotating support
- Maximo Secrets — Inventory Counting : Reconciliation
Correct: B
Why B — La feature Issue for Planned Materials dans Mobile Issues and Transfers permet aux techniciens / storeroom staff d'issue directement les items déjà réservés (planned) sur un WO, depuis leur mobile. La transaction lie automatiquement l'issue au WO d'origine, décrémente la reservation, et post les usage costs au WO. Gain : pas besoin de revenir à un desktop pour issue un item déjà prévu ; accélère le flow terrain.
Why A wrong — D8 imprecise : cost posting est un side-effect automatique, pas le purpose de la feature.
Why C wrong — D9 near-synonym : PR creation est dans Desktop Requisitions / Inventory Reorder, pas Issue feature.
Why D wrong — D6 cardinality : stocked ET rotating items peuvent être issued via cette feature.
- IBM Docs — Mobile Issues and Transfers : Planned materials issue
- Maximo Secrets — Mobile Inventory : Mobile workflow
Correct: B
Why B — Reconcile Balances exécute le calcul officiel documenté par IBM : Current (Expected) Balance = Physical Count + Transfers In + Returns − Transfers Out − Issues (toutes les transactions survenues APRÈS la Physical Count date). Cette formule garantit que les transactions intermédiaires (entre le moment où le technicien enregistre le count et le moment où le superviseur reconcile) ne sont pas perdues. La différence entre ce Current Balance calculé et l'ancien BALCUR est écrite au compte Shrinkage Account ou Currency Variance (configuré sur le Storeroom + Organization). Le dialogue Reconcile Balances permet de modifier le Control GL Account et le Shrinkage GL Account avant commit.
Why A wrong — D5 inverted : Maximo n'ignore pas les transactions intermédiaires ; il les INCLUT dans le calcul. C'est précisément le rôle de Reconcile Balances vs un simple « Apply Count ».
Why C wrong — D8 imprecise verb : Maximo ne bloque jamais Reconcile Balances. Il accepte l'action à tout moment et applique la formule — ce qui garantit la continuité opérationnelle (on ne veut pas figer un storeroom entre un count et son reconcile).
Why D wrong — D6 wrong cardinality : Shrinkage Account est PAR DÉFAUT le compte de variance sur Physical Count. Currency Variance intervient dans d'autres cas (ex: revaluation de devise). Dire « Shrinkage Account is never used » est factuellement faux.
- IBM Docs — Reconciling inventory balances : Formule officielle
- Maximo Secrets — Financial Processes in Inventory 2/8 (Portaluri, 2020) : Reconcile + Shrinkage
- Vietmaximo — ABC Analysis and Physical Count : Implementation perspective
- IBM Support — Current balance adjustment physical count : Edge case behavior
Count Books application
📋 IBM Objectives
- Selection type criteria: All · Bin · Count Frequency · Inventory Counting Group · Item · Rotating · Tools
- Inventory tolerances configuration
- Post-count process: Items Counted, Accuracy (global + individual), Reconciliation
💡 7 selection types (memorize)
- All
- Bin
- Count Frequency
- Inventory Counting Group
- Item
- Rotating
- Tools
Correct: A, B, C (the full seven are All, Bin, Count Frequency, Inventory Counting Group, Item, Rotating, Tools)
Why A, B, C — Les 7 Count Book selection types Maximo : All, Bin (limite à un bin spécifique d'un storeroom), Count Frequency (pull les items selon leur count cycle défini — ex: tous les items à fréquence mensuelle), Inventory Counting Group (groupe réutilisable d'items défini en amont), Item, Rotating, Tools. Les 3 du Q correct (Bin, Count Frequency, Inventory Counting Group) sont les plus utilisés pour la sélection ciblée.
Why D wrong — D9 near-synonym : ABC Classification est un concept d'inventory (priority items) mais pas un Count Book selection type Maximo.
Why E wrong — D3 wrong scope : Vendor est un champ Item/PO (relation fournisseur) mais pas un critère de sélection pour un Count Book — les Count Books filtrent sur storeroom, ABC class, location, issue frequency. Vendor est hors scope du cycle count logic.
Why F wrong — D2 invented : « Storeroom Zone » n'est pas un type Maximo.
- IBM Docs — Count Book selection types : 7 types
- Maximo Secrets — Inventory Counting : Selection criteria
Correct: A
Why A — Post-Count Book completion, Maximo expose 3 métriques + actions clés : Items Counted (volume d'items traités vs sélectionnés), Accuracy (% correspondance physical vs expected balance, calculé en global et par count-book-line), Reconciliation (action qui post les variances comme Inventory Adjustments au compte Shrinkage). Ces 3 outputs permettent au storeroom supervisor de juger la qualité du count, corriger les écarts, et documenter l'audit trail.
Why B wrong — D3 wrong scope : Reorder Point / Safety Stock / Turnover sont des item planning metrics, pas count review outputs.
Why C wrong — D4 adjacent : Audit Trail / Digital Signature / Approval Workflow sont des constructs workflow/security.
Why D wrong — D7 non-existent : « Count Variance Sign-off », « Variance Ledger », « Auto-Reconciliation Log » ne sont pas des artefacts Maximo.
- IBM Docs — Reconciling Count Books : Post-count review
- Maximo Secrets — Inventory Counting : Metrics + reconciliation
Setup Contracts
📋 IBM Objectives
- Contract types and when to use them
- Warranty/Maintenance contracts for Assets · impact on assets
- Purchase and Lease contracts for PR/PO
- Terms and Conditions · where T&Cs are associated with contract types
- How changes to an approved contract can be made
- Lease Rental contracts configuration
💡 Types
- Purchase Contract types = Price + Blanket ⭐
- Global types: Purchase, Blanket, Warranty, Master, Lease, Labor Rate, Software
- Revise Contract = action to modify an approved contract (creates a revision)
- T&Cs applied via Terms and Conditions app
- Contract properties in Contract Types app
⚠️ IBM Trap
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: A
Why A — Le Purchase Contract de Maximo v9 unifie deux patterns antérieurs : Price Contract (pricing négocié) + Blanket Contract (volume committed sur période). Le Purchase Contract porte à la fois les prix par item, les quantités totales engagées, et les dates de validité. Les POs émis contre ce contrat décrémentent la quantité committed ; à expiration, le contrat se ferme et tout PO résiduel passe en prix normal.
Why B wrong — D4 adjacent : Lease/Rental Contracts est une application distincte du module Contracts, pour les leasings d'assets ; Purchase Contracts a son app propre.
Why C wrong — D5 inverted : warranty tracking est le rôle de Warranty Contracts, pas Purchase.
Why D wrong — D9 near-synonym : Software Contracts gèrent les licences ; Purchase Contract est focalisé procurement matériel/services.
- IBM Docs — Purchase Contracts : Unified contract type
- Maximo Secrets — Procurement map : Contract types
Correct: A, B, C
Why A, B, C — Les 7 contract types standards de Maximo : Purchase, Blanket, Warranty, Master, Lease/Rental, Software, Labor Rate. Warranty tracke la couverture sous garantie d'un Asset, Master regroupe des child contracts sous T&Cs communs (ex: vendor stratégique avec plusieurs POs types), Labor Rate fixe les prix horaires par craft/skill pour les services externes.
Why D wrong — D2 invented : « Currency Hedge Contract » n'existe pas dans Maximo (domaine finance, pas procurement).
Why E wrong — D7 non-existent : « Delivery Forecast Contract » n'est pas un type Maximo.
Why F wrong — D4 adjacent : capacity reservation relève du module APS / Scheduler, pas Contracts.
- IBM Docs — Contracts overview : 7 contract types
- Maximo Secrets — Procurement map : Contract module
Correct: C
Why C — Quand un WO est créé sur un Asset couvert par un Warranty Contract actif (date du WO dans la fenêtre de coverage), Maximo affiche un flag de warning sur le WO pour alerter le planificateur. Objectif : éviter que le coût soit facturé interne alors que le vendor doit couvrir. Le flag est informatif — Maximo ne refuse jamais le WO, n'applique pas de charge-back automatique, laisse le choix au planner.
Why A wrong — D5 inverted direction : Maximo n'auto-close jamais un Work Order sur un événement warranty — au contraire, c'est le user (planner ou supervisor) qui décide manuellement de fermer le WO après réception de la warranty claim. L'automation Maximo s'arrête à la notification (email escalation) et à l'affichage du flag warranty, pas à la fermeture.
Why B wrong — D8 imprecise : « validates/rejects » est plus fort que le vrai comportement — warranty ne flag que, ne reject pas.
Why D wrong — D4 adjacent : Service Requests sont un point d'entrée séparé, pas une transformation auto depuis WO.
- IBM Docs — Warranty Contracts : Coverage flag behavior
- Maximo Secrets — Warranties : Warranty in procurement map
Correct: D
Why D — L'action Revise Contract est la voie supportée par Maximo pour modifier un contrat approuvé. Elle crée une nouvelle revision (le numéro de revision s'incrémente : v1, v2, v3...) tout en préservant le record précédent pour l'audit trail. Les child records (POs existants) restent liés à la revision qui les a créés ; les nouveaux POs s'associent à la dernière revision active. Cette immutabilité des versions anciennes est critique pour la traçabilité finance/légal.
Why A wrong — D3 wrong scope : les contrats approved ne peuvent pas être simplement supprimés (audit constraints).
Why B wrong — D9 near-synonym : Cancel est drastique, utilisé pour terminer le contrat définitivement, pas pour une révision.
Why C wrong — D2 invented : « Close Contract + Change Order » n'existe pas dans Maximo.
- IBM Docs — Revising Contracts : Revise action
- Maximo Secrets — Contracts : Revision pattern
Correct: B
Why B — Le Lease/Rental Contract génère des periodic payments (mensuel, trimestriel, annuel — configurable par contrat) sur toute la vie du leased Asset. Il track aussi les end-of-lease terms : option d'achat (buyout), retour au vendor, renouvellement, pénalités de sortie anticipée. Utilisé pour équipements lourds loués (forklifts, génératrices) ou véhicules de flotte. Les paiements sont posted automatiquement via le contract schedule.
Why A wrong — D6 cardinality : la fréquence est configurable par contrat (pas forcée monthly).
Why C wrong — D9 near-synonym : Blanket Contract est distinct (commitment volume d'achat, pas leasing).
Why D wrong — D3 wrong scope : Lease s'applique à tout Asset loué (stocked, rotating, fleet), pas uniquement rotating.
- IBM Docs — Lease/Rental Contracts : Periodic payments
- Maximo Secrets — Contracts : Lease terms
Correct: A, B
Why A, B — PR lifecycle : WAPPR → APPR → INPRG → CLOSE. 2 statuses permettent Create PO : APPR (pleinement approuvée, toutes lignes éligibles) et INPRG (partiellement POed, lignes restantes convertibles). WAPPR bloque (pas approuvé), CAN/CLOSE terminaux bloquent.
Why C wrong — D5 inversée : WAPPR = Waiting Approval, workflow enforcement bloque Create PO.
Why D wrong — D9 near-synonym : CAN (Cancelled) est un status terminal sur PR — une fois cancelled, la PR ne peut plus être utilisée pour Create PO (ni aucune autre action), le workflow est mort. Similaire en comportement au CLOSE mais raison différente.
Why E wrong — D2 invented : aucun status DRAFT sur PR — initial = WAPPR.
- IBM Docs — PR statuses : PR lifecycle
- IBM Docs — Create PO from PR : Eligible statuses
Create and manage MR / PR / PO / RFQ
📋 IBM Objectives
- Desktop Requisition: Create, View, Templates, Mobile Request Materials, approval limits, workflow
- PR: lines linked to contracts/DR, auto via Inventory Reorder, approval, Create PO, worklog
- RFQ: multi-vendor quotes, copy lines from PR
💡 Key Points
- Desktop Req = self-service, Templates, Mobile Request Materials
- PR auto via Inventory Reorder: replenishment + direct issue
- RFQ: quotes for SOW → copy lines from PR → create PO from winning quote
- Multi-level approval limits via Workflow
Correct: B
Why B — Desktop Requisitions est l'application self-service qui permet aux end users (non-buyers) de commander des items via des templates pré-configurés. Elle est mobile-enabled (accessible depuis le browser mobile) et intègre le Workflow pour les approbations avant conversion en PR puis PO. Usage typique : un technicien commande des consommables courants sans passer par le buyer.
Why A wrong — D3 wrong scope : la consolidation de PRs en PO est un travail buyer-side dans l'app Purchase Requisitions, pas Desktop Requisitions.
Why C wrong — D4 adjacent : la réapprovision nocturne est gérée par le cron PIRE (Inventory Reorder), pas Desktop Requisitions.
Why D wrong — D1 legacy : Desktop Requisitions est toujours présent dans MAS Manage v9.0 comme application self-service pour que les users non-procurement demandent des items — il n'a pas été retiré. Distracteur basé sur la rumeur fausse d'un "replacement" par l'UI mobile, qui en réalité co-existe.
- IBM Docs — Desktop Requisitions : Self-service app
- Maximo Secrets — Procurement map : App landscape
Correct: C
Why C — Le cron task Inventory Reorder (PIRE ou ReorderCronTask) scanne les storerooms et génère automatiquement des Purchase Requisitions pour les items ayant franchi leur reorder point. Optionnellement, il peut aussi créer des direct-issue PRs liés aux reservations de WOs ouverts (pour les items non-stockés livrés direct au WO). Le cron utilise les settings Reorder Point + Max Level + Safety Stock de chaque Item/Storeroom.
Why A wrong — D3 wrong scope : reorder ne génère pas de WO. Les WOs viennent de PM ou manual creation.
Why B wrong — D5 inverted : les Invoices arrivent en fin de cycle P2P (post-receipt), pas depuis le reorder cron.
Why D wrong — D9 near-synonym : Desktop Requisitions est une application self-service où les users saisissent manuellement leurs demandes — output des users, pas d'un cron task automatisé. Direction du flux inverse à ce que suggère le distracteur.
- IBM Docs — Inventory Reorder Cron Task : PIRE behavior
- Maximo Secrets — Inventory : Reorder flow
Correct: D
Why D — La Request for Quotation (RFQ) est l'étape optionnelle de solicitation compétitive : le buyer inscrit plusieurs vendors, envoie la RFQ, capture les quotes reçues (prix + lead time + conditions), compare, puis sélectionne le meilleur bid. Le vendor gagnant est ensuite transformé en PO avec les termes négociés. RFQ est typiquement utilisé pour achats stratégiques ou au-dessus d'un seuil de valeur configuré par l'Org.
Why A wrong — D5 inverted direction : un RFQ (Request For Quotation) est le document amont qui précède le PO pour collecter les quotations de plusieurs vendors — jamais un binding post-PO. Confusion direction PO → RFQ vs RFQ → PO (ordre chronologique correct).
Why B wrong — D3 wrong scope : warranty extensions se gèrent dans Warranty Contracts, pas RFQ.
Why C wrong — D4 adjacent app : la reconciliation receipt ↔ invoice (3-way match PO/Receipt/Invoice) est fonctionnalité des applications Receiving et Invoices, pas du Blanket PO qui est un mécanisme d'agreement prix-volume amont. Confusion de couches procurement.
- IBM Docs — Request for Quotations : RFQ workflow
- Maximo Secrets — Procurement map : RFQ in P2P
Correct: A
Why A — Le flux canonique P2P (Procure-to-Pay) de Maximo : MR/PR (Material/Purchase Requisition demande) → RFQ (optionnel, si multi-vendor sourcing) → PO (Purchase Order engagement avec vendor sélectionné) → Receipt (réception physique dans Receiving) → Invoice (facture vendor matchée PO+Receipts et payée). Chaque étape génère des GL transactions et alimente l'audit trail. Les contracts peuvent pricer les items mais ne remplacent pas une étape.
Why B wrong — D5 inverted : PO ne peut pas exister avant PR (sauf émission directe PO, cas spécial hors canonique).
Why C wrong — D3 wrong scope : contracts supportent le flow mais ne sont pas une étape mandatory ; Inventory Usage est un flux parallèle d'issue stock.
Why D wrong — D2 invented : « Quote Comparison Matrix » n'est pas une étape Maximo ; la comparaison se fait dans l'app RFQ elle-même.
- IBM Docs — Purchasing overview : Canonical P2P flow
- Maximo Secrets — Procurement map : End-to-end
Correct: D
Why D — Une PR Internal dans Maximo désigne un transfert inter-magasin (inter-storeroom transfer) au sein de la même Organization — pas un achat auprès d'un vendor externe. Dans ce cas, le champ Storeroom (alias technique storeloc) devient obligatoire : il identifie le storeroom source qui fournira l'item. La contrainte MBO rejette la sauvegarde avec une exception si Internal=Y et storeloc=null (IBM Support documente ce comportement). La checkbox « Use in PO/PR » du Storeroom détermine en amont quels storerooms sont éligibles comme source sur une PR interne. Cette logique préserve l'intégrité du flux : une PR interne sans source est absurde, puisqu'il n'y a rien à transférer.
Why A wrong — D3 wrong scope : Work Order peut être optionnellement référencé sur une ligne de PR (via WO Link pour traçabilité coût) mais n'est jamais rendu obligatoire par le flag Internal. Un planificateur peut très bien créer une PR interne sans WO source (ex: réapprovisionnement périodique d'un storeroom).
Why B wrong — D9 near-synonym : Ship Via identifie le transporteur / mode d'expédition (carrier, trucking) pour une livraison externe. Pour un transfert interne entre storerooms d'un même site, Ship Via n'a pas de sens — le déplacement est géré par la logistique interne (chariot, forklift). Ship Via reste optionnel même sur une PR externe.
Why C wrong — D4 adjacent app + logique inversée : Company (Vendor) est requis pour une PR externe (achat auprès d'un fournisseur), pas pour une PR interne. Le piège IBM : Internal=Y exclut Company (pas de vendor), et impose Storeroom. Un candidat qui confond les deux flows choisira Company.
- IBM Support — Creating a Purchase Requisition : Vendor vs internal storeroom required
- IBM Docs — How to set required date for PR/PO replenishment : PR replenishment flow
- Maximo Secrets — Maximo Manage Procurement map (Portaluri, 2018) : Full P2P cycle
- Portaluri — PR MBO Javadoc (Maximo 7.6) : Exception when internal & storeloc null
Correct order: A → B → C → D (PR → RFQ → PO → Invoice)
Why this order — Le flux canonique externe commence par une Purchase Requisition (demande d'achat émise par le business / storeroom). Si la valeur / politique l'exige, une Request for Quotation (RFQ) est émise auprès de plusieurs vendors pour comparer les prix ; la Best Bid est sélectionnée et transformée en Purchase Order (PO) engageant l'Org auprès du vendor. Après réception (Receiving — step non inclus dans ce drag-drop), le vendor envoie une Invoice qui est matchée contre le PO + les receipts dans Maximo pour payment. RFQ est optionnel (skippé pour achats de faible valeur ou catalog) ; pour un test drag-drop, IBM l'inclut systématiquement en position 2.
- Maximo Secrets — Maximo Manage Procurement (Portaluri, 2018) : End-to-end P2P flow
- IBM Docs — Purchasing overview : Canonical flow
- IBM Docs — Creating POs from PRs : Step-by-step conversion
Receiving process, PO creation, Invoicing
📋 IBM Objectives
- Receiving application usage · transfer rotating/non-rotating between orgs
- Inspection when receiving · serialization for rotating items
- Shipments usage
- 5 invoice types
- Impact on inventory balances · HOLDING location during receiving
💡 5 invoice types
- Invoice related to a single PO
- Invoice related to multiple POs for a single vendor
- Invoice NOT related to a PO for a single vendor
- Invoice with different PO sites vs invoice site
- Invoice for consignment items
💡 HOLDING location
🎯 Flashcard
Q. Temporary location before the final storeroom during receiving?
Show answer
HOLDING (not STAGING, not RECEIVING, not TRANSIT).
Correct: C
Why C — L'application Invoices supporte 5 types : Single-PO (invoice contre un seul PO), Multi-PO single vendor (une invoice couvrant plusieurs POs du même vendor), No-PO (invoice sans PO référencé, ex: services non-planifiés), Multi-site (invoice couvrant plusieurs sites d'une même Org), Consignment (items vendor-owned dans un storeroom interne, payés à la consommation).
Why A wrong — D9 near-synonym : Proforma / Commercial / Customs sont des termes issus de l'international trade-finance (invoice Proforma pour quotation, Commercial pour transaction finale, Customs pour douane) — pas des types de contract Maximo qui relèvent d'un autre domaine fonctionnel.
Why B wrong — D2 invented : Standard / Recurring / Prepaid ne sont pas des catégories Maximo Contract — les 6 types officiels sont Blanket, Labor Rate, Lease/Rental, Master, Purchase, Warranty. Distracteur construit sur des catégories de contract management génériques (billing/AP) qui ne s'appliquent pas au modèle Maximo.
Why D wrong — D4 adjacent : Draft / Approved / Paid sont des statuses d'invoice (lifecycle pipeline d'une facture) — app adjacente à Contracts mais niveau différent. Les types classifient la nature du document (Blanket, Purchase...), les statuses son état.
- IBM Docs — Invoice types : 5 types
- Maximo Secrets — Procurement : Invoice anatomy
Correct: D
Why D — HOLDING est une location spéciale dans un storeroom où les items réceptionnés restent en attente d'inspection qualité. Quand Inspection on Receipt est activé sur l'item, le receipt place automatiquement l'item en HOLDING ; l'inspection (pass/fail) le libère vers le regular bin (disponible à l'issue) ou déclenche un Return to Vendor. Ce staging préserve l'intégrité du stock « disponible » : seuls les items validés y figurent.
Why A wrong — D5 inverted : HOLDING est pre-inspection (attente), pas rejection. Le rejet se traduit par un Return to Vendor post-inspection.
Why B wrong — D3 wrong scope : HOLDING est receipt staging, pas un decommission bin.
Why C wrong — D4 adjacent : l'aggregation invoices se fait dans Invoices app, pas HOLDING.
- IBM Docs — Inspection holding locations : HOLDING staging
- Maximo Secrets — Inventory Receiving : Receipt flow
Correct: A
Why A — Quand un Rotating Item est reçu sur un PO, Maximo matérialise chaque unité physique comme un Asset record individuel sérialisé (ASSETNUM unique) et l'assigne en status NOT READY (pending issue à une Location). Chaque Asset hérite de l'Item Master (classification, specifications) mais devient traçable individuellement — critique pour les rotables (moteurs, pompes, instruments) qui subissent overhaul et retourneront en inventory.
Why B wrong — D8 imprecise : receipt ne fait pas d'auto-issue au WO. Issue est une étape ultérieure.
Why C wrong — D5 inverted direction : les rotating items SONT sérialisés par définition (1 Asset unique par unité physique) — l'inverse de quantity-only serait le modèle standard stocké. Distracteur qui renverse la propriété fondamentale du rotating flag.
Why D wrong — D1 legacy : création manuelle d'Asset post-receipt était un pattern Maximo 7.1 ; modern Manage auto-génère à la réception.
- IBM Docs — Receiving rotating items : Auto-Asset creation
- Maximo Secrets — Rotating Items (Portaluri, 2020) : Rotating item lifecycle
Correct: B
Why B — SHIPTRANSFER est le code ISSUETYPE écrit dans MATRECTRANS quand un transfer PO (inter-site ou inter-storeroom) est shippé depuis la source. Il tracke le mouvement entre source et destination storerooms. Au receiving destination, un autre enregistrement MATRECTRANS avec type TRANSFER est créé, complétant le double-side du transfer. Cette dualité préserve la balance comptable des deux storerooms.
Why A wrong — D9 near-synonym : RECEIPT est écrit à la réception finale, pas à l'expédition.
Why C wrong — D3 wrong scope : ADJUSTMENT est un type de transaction inventory utilisé pour la reconciliation post-count (corriger les écarts physical vs system) — scope différent des transfers qui eux déplacent du stock entre storerooms sans ajustement comptable.
Why D wrong — D4 adjacent : ISSUE est stocké dans la table MATUSETRANS (Inventory Usage transactions) — table adjacente mais distincte de MATRECTRANS (Receipt transactions). Confusion classique entre les 2 tables transactions inventory.
- IBM Docs — MATRECTRANS table : Transaction types
- Maximo Secrets — Transfers in Inventory Usage (Portaluri, 2020) : SHIPTRANSFER behavior
Correct: D
Why D — L'étape Inspection on Receipt permet au receiver de valider la qualité des items stagés en HOLDING avant leur libération vers le regular storeroom bin. L'inspector peut ACCEPT (move to storeroom, item disponible à l'issue) ou REJECT (déclenche typiquement un Return to Vendor). Activé via le flag Inspection Required sur l'Item Master ou via la PO Line. Sans inspection activée, les items vont directement au bin à la réception.
Why A wrong — D8 imprecise : Void Receipt reverse la transaction de réception (audit), ce n'est pas un contrôle qualité.
Why B wrong — D5 inverted : Return to Vendor intervient APRÈS l'inspection qui rejette l'item, pas à la place de l'inspection.
Why C wrong — D4 adjacent : Invoice Match se fait dans l'app Invoices (reconciliation financière), pas Receiving.
- IBM Docs — Inspecting received items : Inspection on Receipt
- Maximo Secrets — Inventory Receiving : Receipt + inspection flow
Correct: B
Why B — Le retour au vendor est enregistré dans la table MATRECTRANS comme un record avec ISSUETYPE = RETURN et une quantité négative (confirmé par Portaluri's Maximo Secrets - « Inventory Receiving »). Cette mécanique d'inverse-quantity permet à Maximo de maintenir l'intégrité comptable : le total du PO line reste cohérent (quantity received - quantity returned), et le GL reverse l'écriture de réception initiale. Le RETURN transaction peut être créé soit depuis l'action Return Items dans Receiving, soit automatiquement après un rejet en Inspection on Receipt.
Why A wrong — D5 inverted : RECEIPT est réservé aux entrées (incoming) avec quantité positive. Maximo n'accepte JAMAIS de négatif sur RECEIPT ; un ajustement ou retour passe par un autre type (RETURN).
Why C wrong — D3 wrong scope : ADJUSTMENT est un type de transaction d'Inventory Adjustments (MATUSETRANS), utilisé pour réconcilier un Physical Count. Aucun lien avec le retour vendor qui passe par MATRECTRANS.
Why D wrong — D2 invented : « VENDOR VOID » n'existe pas dans les enums Maximo (domaine ISSUETYPE). Distracteur fabriqué pour sonner comme un concept légitime.
- Maximo Secrets — Inventory Receiving (Portaluri, 2023) : RECEIPT / RETURN / TRANSFER types
- IBM Docs — MATRECTRANS table : Structure officielle
- Portaluri — MatRecTrans MBO Javadoc (7.6) : API signature
Correct: A
Why A — L'Invoice Matching de Maximo utilise les tolérances définies sur Organizations → More Actions → Purchasing Options → Invoice Options (tolérances sur prix ET quantité, en % ou en valeur absolue). Dans les tolérances, l'invoice s'approuve et l'écart est posté sur le compte Invoice Variance (configuré dans Chart of Accounts). Une fois approuvée, le PO reste ouvert pour les receipts restants ; quand ceux-ci arrivent, Maximo réconcilie automatiquement le Invoice Variance. Hors tolérances, l'approval échoue et exige une override manuelle par un utilisateur avec la signature correspondante.
Why B wrong — D9 near-synonym : c'est le comportement SANS tolérance configurée (ou au-delà des tolérances). Dans le scénario, les 20% de tolérance couvrent largement l'écart — donc l'approval réussit, mais avec variance posting.
Why C wrong — D2 invented : Maximo ne fabrique jamais silencieusement de receipts. Chaque receipt est un événement physique tracé dans MATRECTRANS ; auto-créer des receipts fantômes casserait l'audit trail et les implications fiscales.
Why D wrong — D5 inverted : les Purchase Requisitions précèdent les Purchase Orders dans le flux (PR → PO → Receipt → Invoice). Maximo ne remonte pas en arrière depuis une Invoice pour créer une PR. Aucun auto-split de ce type.
- Maximo Secrets — Financial Processes in Inventory (Portaluri, 2020) : Invoice variance posting
- IBM Docs — Invoice tolerances : Organizations tolerance setup
- Naviam — Organization Options Purchasing : PO / Invoice tolerance config
Create and manage Job Plans and Routes
📋 IBM Objectives
- Job plans · Dynamic job plans (Calculation Methods, Resources)
- Qualifications on job plan/tasks (copy to WO, restrict assignment)
- Flow Control (predecessor rules)
- Nested job plans
- Org settings & sys properties: Job Plan Revisioning, Job Plan Conditions
💡 Key Points
- Revision Control Job Plans → Organizations app ⭐
- Dynamic Job Plan Calculation Methods: Formula, Meter Based
- Resources supported: Labor, Craft, Material, Tool
- Qualifications → copied to WO → restrict assignment
- Flow Control = predecessor rules on tasks
- Nested = embed another job plan
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: D
Why D — Les Dynamic Job Plans introduits en v9 supportent deux méthodes de calcul de tasks : Formula Based (expressions sur asset attributes/specifications produisent des tasks conditionnelles) et Meter Based (meter readings à un seuil déclenchent tasks spécifiques). Le calcul se fait au moment de la génération WO ; chaque WO peut ainsi recevoir un set de tasks customisé selon l'état réel de l'asset. Feature clé pour PM prédictif vs basé sur calendar fixe.
Why A wrong — D9 near-synonym : Routes et nested plans existent mais ne font pas de calcul formula/meter.
Why B wrong — D1 legacy : les Standard Job Plans classiques (pre-v9) ont des tasks statiques figées au template — pour obtenir du dynamisme (tasks variables selon l'asset), il faut Dynamic Job Plans introduits en Manage v9.0 qui substituent les tasks à la génération WO.
Why C wrong — D2 invented : « Job Plan Sequence » n'est pas un nom de feature Maximo.
- IBM Docs — Dynamic Job Plans : Formula + Meter Based
- Maximo Secrets — Job Plans (Portaluri, 2022) : JP features
Correct: A
Why A — Le Revision Control pour Job Plans est activé au niveau Organization, via Organizations → More Actions → Work Order Options → Job Plan settings. Une fois activé, chaque modification d'un JP approuvé crée une nouvelle révision (v1, v2, v3...) au lieu d'écraser — les WOs existants conservent leur lien vers la revision d'origine, les nouveaux WOs pointent vers la dernière. Préserve l'audit trail des changements PM + le tracing règlementaire.
Why B wrong — D4 adjacent : Job Plans app est où on UTILISE revision control, pas où on l'active.
Why C wrong — D2 invented : aucune system property mxe.jobplan.revisioncontrol n'existe dans Maximo — le revision control sur Job Plans est une feature intégrée (Revision Control button dans Select Action), pas gated par une property. Piège classique pour candidat qui imagine que toute feature est toggled par une property.
Why D wrong — D3 wrong scope : Application Designer change l'UI, pas les business rules.
- IBM Docs — Enable Revision Control Job Plans : Org-level setting
- Maximo Secrets — Job Plans : Revision pattern
Correct: B
Why B — Quand une Qualification (craft + skill level, ou certification) est définie sur une Job Plan task, elle est copiée sur la WO task à l'application du JP. Maximo enforce alors le restriction : seul un labor/person qui détient cette qualification (enregistrée dans Labor > Qualifications tab) peut être assigné. Critique pour les travaux réglementés (HSE, électrique haute tension, travail en hauteur) où la compliance exige qualifications documentées.
Why A wrong — D5 inverted direction : les qualifications sur Job Plans sont enforcing par conception — Maximo bloque l'assignment d'un Labor sans la qualification requise (ou affiche warning selon config), jamais purement informational. L'inversion "informational only" affaiblirait la raison d'être du mécanisme.
Why C wrong — D8 verbe imprécis : « logged » sous-estime le comportement — Maximo restreint activement (warning/block explicit) selon la config, pas juste un log passif. Le flag de qualification est enforcing, pas observationnel.
Why D wrong — D2 invented : aucune notification email native liée aux qualifications — Maximo peut envoyer des emails via Communications/Escalations/Workflows mais pas un trigger automatique "qualification expiring" out-of-box. L'admin doit construire une Escalation custom pour obtenir ce comportement, pas un feature par défaut.
- IBM Docs — Job Plan qualifications : Task qualifications
- IBM Docs — Labor Qualifications : Craft + skill
Correct: C
Why C — Le Flow Control dans Maximo exige deux conditions combinées : (1) le WO ou sa task doit être marqué Under Flow Control (flag explicite sur le record), (2) des Predecessor relationships doivent être définies entre tasks (task 2 predecessor = task 1). Maximo bloque alors le status change de la successor tant que la predecessor n'est pas COMP. Permet d'orchestrer les dépendances techniques (ex: lockout avant intervention, test avant commissioning).
Why A wrong — D2 invented : « Apply Sequence Logic » n'est pas un flag Maximo réel — trap classique.
Why B wrong — D8 imprecise : les sequence numbers ordonnent l'affichage seulement, ne forcent pas l'exécution.
Why D wrong — D3 wrong scope : le standard Workflow (Workflow Designer, Task/Condition nodes) est un mécanisme distinct du Flow Control sur WO — ils peuvent co-exister sur le même WO mais opèrent sur des layers différents (workflow = routing de decisions, Flow Control = sequencing tasks execution).
- IBM Docs — Work Order Flow Control : Flow Control mechanics
- Maximo Secrets — Work Management : Flow Control usage
Correct: A
Why A — Quand un parent Job Plan contenant des references vers des nested JPs est appliqué à un WO, Maximo matérialise la hiérarchie complète de tasks : les tasks du parent JP deviennent les WO tasks de premier niveau ; pour chaque task pointant vers un nested JP, les tasks de ce nested JP deviennent des child tasks sous la parent task, préservant la structure multi-niveaux. Cette matérialisation en arbre permet d'exécuter et tracer chaque sous-task indépendamment tout en gardant le lien logique avec le parent.
Why B wrong — D5 inverted : le but même du nesting est d'inclure les children, pas les ignorer.
Why C wrong — D6 cardinality : les nested plans restent dans la même WO hierarchy, pas des WOs séparés (sauf config avancée).
Why D wrong — D3 wrong scope : nesting fonctionne sur tout WO utilisant le parent JP, pas seulement les PMs.
- IBM Docs — Nested Job Plans : Behavior on WO
- IBM Support — Using Nested Job Plans : Hierarchy flow
Correct: D
Why D — Dans l'application Job Plans de Maximo Manage, les Nested Job Plans se définissent sur l'onglet Job Plan Tasks. Chaque task row expose un champ Nested Job Plan (accessible directement ou via Detail Menu) permettant de référencer un autre Job Plan qui peut lui-même contenir ses propres tasks avec d'éventuels nested plans — créant ainsi une hiérarchie récursive. Quand le parent Job Plan est appliqué à un Work Order, Maximo matérialise cette hiérarchie en parent WO + child WOs : chaque task pointant vers un nested JP génère un child WO qui hérite des tasks du JP imbriqué. IBM recommande de ne pas dépasser 3 niveaux en production (parent WO → child WOs → tasks). Les nested JPs sont donc des composants réutilisables.
Why A wrong — D9 near-synonym : Dynamic Job Plans est une feature distincte, introduite en v9, qui permet de générer tasks + durées automatiquement via formulas ou meter readings au moment de la génération WO. Ce n'est pas un onglet pour la hiérarchie ; c'est un flag sur le Job Plan activant le calcul dynamique. Piège IBM : deux features « Job Plan » évoluées, mais l'une est hiérarchique (nested), l'autre computationnelle (dynamic).
Why B wrong — D2 invented : « Flow Action Tab » n'existe pas dans l'application Job Plans. Le concept voisin s'appelle Flow Control (predecessor sequencing entre tasks), mais aucun onglet « Flow Action » n'est livré dans Maximo. Distracteur fabriqué à sonorité plausible.
Why C wrong — D3 wrong scope : Planned Labor est bien un onglet de Job Plans, mais son rôle est de spécifier les requirements main-d'œuvre (crafts, skill levels, heures, quantités) — pas la hiérarchie. Les nested Job Plans ne se manipulent pas depuis cet onglet ; il sert uniquement au cost estimate et au labor scheduling.
- IBM Support — Using Nested Job Plans to Build Job Plan Hierarchies : Nested JP hierarchy
- IBM Support — Adding Nested Job Plan to a Task : Job Plan Tasks tab procedure
- Maximo Secrets — Job Plans (Portaluri, 2022) : Full Job Plan anatomy + nested field
- IBM Docs — Adding nested job plan tasks : Procédure officielle
Correct: A, B
Why A, B — Job Plan = template réutilisable. Copiés vers WO généré : Tasks (sequence, description, est. duration, est. hours, craft) comme child rows, Planned Materials (items + quantités + direct issue flags + storeroom) dans Plans → Materials. Aussi copiés : Planned Labor, Tools, Services. JP porte le planned, WO capture le actual.
Why C wrong — D5 inverted direction : l'Asset est l'entité qui porte le PM ou le WO (target équipement), pas un élément du Job Plan. Le JP est un template générique, agnostique d'asset ; c'est la liaison PM→Asset+JP qui produit un WO concret.
Why D wrong — D9 near-synonym : Safety Plan attaché via PM ou Asset, pas JP.
Why E wrong — D2 invented : les Actual Labor Transactions ne peuvent exister que post-exécution (quand des techs ont effectivement loggé leurs heures) — jamais sur un Job Plan template puisque le JP n'est pas un WO. Actuals attachés à WO records uniquement.
- IBM Docs — Job Plans overview : Tasks + Materials
- Maximo Secrets — Job Plans : Template propagation
Condition Monitoring
📋 IBM Objectives
- Condition monitoring functionality
- Create CM points · Warning Limits · Upper and Lower Limits
- Measurement Points functionality
- Methods to generate WO from CM point
- MeasurePointWoGenCronTask
💡 Key Points
- Warning Limits = advisory (no auto-action)
- Upper/Lower Limits = action trigger (generate WO)
- WO generation: manual action OR cron MeasurePointWoGenCronTask
- Measurement Points = locations where the meter is read
Correct: A
Why A — Un Measurement Point dans Condition Monitoring porte 4 bornes configurables : Upper/Lower Warning Limits (bornes d'alerte) et Upper/Lower Action Limits (bornes d'action). Quand une Measurement est saisie : si la valeur franchit une Warning Limit, Maximo émet seulement un flag visuel/notification — aucune action automatique. Si la valeur franchit une Action Limit (appelée Upper/Lower Limit dans l'UI), le cron MeasurePointWoGenCronTask déclenche la création d'un Work Order avec le Job Plan ou PM pré-configuré sur le point. Cette séparation permet un modèle à 2 niveaux : alerter avant d'agir, puis agir seulement si la dérive persiste.
Why B wrong — D8 verbe imprécis : "raise an advisory" minimise l'Upper/Lower qui déclenche réellement un WO ; la couleur sur le gauge n'est qu'un symptôme, pas la différence fonctionnelle.
Why C wrong — D5 rôles inversés : c'est l'inverse — Warning = alerte seule, Upper/Lower = déclenche le WO via cron.
Why D wrong — D2 invented : les deux types de limites s'appliquent indifféremment aux meters gauge et characteristic ; aucun split par type de meter.
- IBM Docs — Measurement point limits and warnings : Warning vs Action Limits
- Maximo Secrets — Meters, Meter Groups and Condition Monitoring : Gauge meter thresholds
Correct: B
Why B — MeasurePointWoGenCronTask est le cron task dédié à la génération de Work Orders depuis Condition Monitoring. Activé via Cron Task Setup, il scanne à intervalle régulier (par défaut 60 min, configurable) tous les Measurement Points actifs et compare la dernière Measurement enregistrée aux Action Limits. Si un franchissement est détecté, le cron génère automatiquement un WO lié au Job Plan ou au PM configuré sur le point, puis marque le Measurement comme traité pour ne pas doubler le WO. C'est un pattern classique Maximo : la saisie est synchrone (via Meter Reading app ou intégration IoT) mais l'action est différée au cron pour éviter de bloquer la transaction utilisateur.
Why A wrong — D4 adjacent : PMWoGenCronTask génère les WOs depuis les PM records (frequency ou meter-based), pas depuis les Measurement Points de Condition Monitoring. Cron différent, app différente.
Why C wrong — D5 direction inversée : le Measurement Point crée le WO via le cron, jamais l'inverse — le WO n'engendre pas de Measurement Point.
Why D wrong — D2 invented : l'application Meter Reading persiste la valeur mais ne déclenche aucun WO ; la génération est toujours portée par le cron, jamais par un trigger sur save.
- IBM Docs — Cron Task Setup : Cron tasks overview
- IBM Support — Generating a Work Order from Condition Monitoring : MeasurePointWoGenCronTask
Correct: C
Why C — Les Measurement Points sont définis exclusivement dans l'application Condition Monitoring. Chaque point associe : (1) un Asset OU Location cible, (2) un meter existant (type GAUGE pour valeurs continues ou CHARACTERISTIC pour valeurs discrètes), (3) les Upper/Lower Warning + Action Limits, (4) un Job Plan ou PM déclenché par franchissement. Les Measurement Points créés ici sont ensuite visibles en read-only depuis les onglets Meters de l'Asset ou Location, mais la création et maintenance reste exclusivement dans Condition Monitoring. Cette centralisation garantit que la logique de surveillance (limits, WO trigger) vit dans une seule app auditable.
Why A wrong — D4 adjacent app : Assets → onglet Meters affiche les meters et readings mais ne permet pas de créer un Measurement Point ; création dans Condition Monitoring uniquement.
Why B wrong — D3 wrong scope : Locations ne propose pas de "Measurement Setup" — on peut associer une Location à un Measurement Point mais la création se fait dans Condition Monitoring.
Why D wrong — D2 invented : l'application Preventive Maintenance n'a aucun onglet "Measurement" pour définir des points ; piège classique pour un candidat qui confond PM meter-based et Condition Monitoring.
- IBM Docs — Condition Monitoring overview : Application scope
- Maximo Secrets — Measure Point : Definition + attachment
Correct: A
Why A — L'application Condition Monitoring surveille les Measurement records enregistrés sur les Measurement Points attachés à un Asset ou une Location. Chaque Measurement Point porte un meter (GAUGE ou CHARACTERISTIC) avec Upper/Lower Warning Limits + Upper/Lower Action Limits. Dès qu'un Measurement est saisi (manuellement ou via intégration IoT) et que sa valeur dépasse un Action Limit, Maximo est capable de déclencher automatiquement la création d'un Work Order avec le Job Plan ou le PM pré-configuré sur le point. Le cron task MeasurePointWoGenCronTask doit être activé pour la génération automatique — à fréquence configurable (quotidien, bi-quotidien). La Warning Limit génère une alerte mais PAS de WO ; seul l'Action Limit déclenche un WO.
Why B wrong — D9 near-synonym : Runhour Meter Readings est un sous-type (continuous meter) mais ce n'est pas le record que Condition Monitoring surveille. Les runhour readings alimentent surtout les PM basés sur usage (ex: service oil change toutes les 250h moteur). Condition Monitoring lit des Measurements saisis sur un Measurement Point dédié.
Why C wrong — D4 adjacent app : Asset Downtime est un record tracking les outages pour calculer availability/MTBF. Il est rempli via l'application Assets ou Work Order (Report Downtime action), jamais par Condition Monitoring. Aucun lien déclenchant un WO via CM.
Why D wrong — D2 invented : Asset Health Score est un concept issu du module Maximo Health (composante séparée de MAS) qui agrège des signaux de santé — pas un record type dans Condition Monitoring standard. Distracteur construit pour séduire un candidat qui mélange Health et Condition Monitoring.
- IBM Support — Generating a Work Order from Condition Monitoring : WO generation via Measurements
- Maximo Secrets — Meters, Meter Groups and Condition Monitoring (Portaluri, 2022) : Gauge meter + Action Limits
- Maximo Secrets — Measure Point : Definition + WO trigger
- IBM APAR IJ13183 — CM Lower warning+action limits : Edge cases sur limits
Preventive Maintenance
📋 IBM Objectives
- Records associable with a PM
- Modify PMs associated with Master PMs
- Earliest Next Due Date (location + usage)
- Generate WOs from PM · Associate Job Plans
- Prevent future updates to PM (break from master)
💡 Key Points
- Associated records: asset, location, job plan, route, safety plan
- Master PM → children auto-inherit changes
- Earliest Next Due Date: prevents over-generation
- Break from master: flag to stop propagation
Correct: B
Why B — Un enregistrement PM dans Maximo Manage admet 5 associations directes : (1) Asset OU Location (exclusif : un PM cible un asset ou une location, pas les deux), (2) Job Plan qui définit les tâches, matériels, outils et labor estimés copiés sur le WO généré, (3) Route pour les PMs multi-assets (inspection ronde sur plusieurs équipements avec un seul WO parent + child WOs par stop), (4) Safety Plan propagé aux WOs générés pour afficher hazards et precautions. On peut aussi associer un Master PM en parent (propagation hiérarchique). Toutes ces associations sont accessibles depuis les onglets du PM record.
Why A wrong — D6 cardinalité : Purchase Orders ne sont pas des associations PM — ils résultent éventuellement de WOs générés ; et la liste oublie Route et Safety Plan.
Why C wrong — D3 wrong scope : Items s'associent via le Job Plan (Materials tab) et SLAs via leur propre application ; aucun des deux n'est une association directe sur le PM.
Why D wrong — D4 adjacent : Contracts vivent dans l'app Contracts (rattachés à POs ou Assets) et Failure Classes dans Failure Codes ; aucun des deux n'a de lien direct avec un PM.
- IBM Docs — Preventive Maintenance overview : PM record associations
- Maximo Secrets — Preventive Maintenance : Routes and Safety Plans on PMs
Correct: C
Why C — Un Master PM est un modèle qui regroupe plusieurs PM records "associated" partageant un même Job Plan, une même fréquence et des mêmes caractéristiques. La propagation des changements du Master vers ses PMs fils n'est jamais automatique : elle se déclenche via l'action Update Associated PMs (menu Select Action). L'administrateur choisit quels champs sont propagés (frequency, job plan, lead time, priority…). Les PMs qui ont subi l'action Break from Master sont exclus de toutes les propagations futures — leur relation est coupée. Ce modèle permet la standardisation à grande échelle (ex: 200 pompes avec le même PM trimestriel) tout en autorisant des exceptions locales.
Why A wrong — D8 verbe imprécis : la propagation n'est jamais auto-on-save — elle exige l'action explicite ; confusion classique avec les Job Plan revisions.
Why B wrong — D2 invented : aucune réplication "real time" ; les next-due dates restent calculées individuellement par PM selon son dernier WO généré et sa fréquence locale.
Why D wrong — D5 inversée : les PMs associés sont mis à jour, pas recréés — l'historique (last generated date, counter) est préservé.
- IBM Docs — Master PM propagation : Update Associated PMs action
- Maximo Secrets — Master PM : Break from Master lifecycle
Correct: D
Why D — Le champ Earliest Next Due Date agit comme un floor (seuil plancher) : le PM generator (PMWoGenCronTask) refuse de produire un WO avant cette date, même si la fréquence ou les meter readings le suggèrent. Cas d'usage typique : une pompe vient de subir une inspection majeure — on veut retarder la prochaine PM de 30 jours sans casser la fréquence standard. L'ingénieur saisit la date cible dans Earliest Next Due Date et le cron skippe la pompe jusqu'à cette date. Aussi utile quand les meter readings spike (ex: pompe tournant 24/7 suite à un arrêt voisin) : la Earliest Next Due Date empêche la sur-génération de WOs prématurés qui brûleraient les ressources maintenance.
Why A wrong — D5 rôle inversé : ce n'est pas une date forcée mais un minimum ; la PM peut se déclencher après mais jamais avant.
Why B wrong — D8 verbe imprécis : le champ est activement appliqué par le cron, pas cosmétique — une mauvaise valeur bloque réellement la génération.
Why C wrong — D3 wrong scope : les SLA response deadlines sont gérées dans l'application SLA via Applies To + Escalations ; aucun lien avec Earliest Next Due Date.
- IBM Docs — PM frequency and next due : Earliest Next Due Date field
- Maximo Secrets — PM generation algorithms : Frequency floor behavior
Correct: A
Why A — L'action Break from Master (accessible depuis Select Action sur un PM associated) détache définitivement le PM de son Master. Après break : (1) le PM conserve toutes ses valeurs courantes (Job Plan, frequency, lead time…), (2) il devient autonome et les futures Update Associated PMs du Master l'ignorent, (3) le flag ISMASTER passe à N et MASTERPMNUM est nullé. Cette opération est irréversible via l'UI standard (on peut recréer l'association via un script ou intégration mais pas via menu). Elle permet exactement ce cas : customiser localement un PM issu d'un modèle standard, sans casser le Master pour les 199 autres pompes du parc.
Why B wrong — D6 cardinalité : désactiver le Master stoppe toutes les générations des PMs associés, pas seulement celui qu'on veut customiser — impact massif inacceptable.
Why C wrong — D8 verbe imprécis : cloner+retirer est un workaround désordonné qui casse l'historique ; Break from Master est la méthode supportée et auditable.
Why D wrong — D2 invented : la manipulation directe en base contourne les garde-fous Maximo (audit, security, RLS) et viole toute pratique supportée par IBM ; jamais la bonne réponse en certification.
- IBM Docs — Master PM : Break from Master action
- Maximo Secrets — Master PM lifecycle : Detachment mechanics
Correct: A, B
Why A, B — PM triggers : (1) Time-based — Fixed/Floating frequency days/weeks/months ; Fixed calcule next due depuis target date précédente, Floating depuis completion date dernier WO (2) Meter-based — déclenche quand meter franchit threshold delta (ex: oil change tous 250h moteur, inspection tous 10 000 km). Compatible continuous/cumulative meters. Time + Meter peuvent être combinés sur un même PM (first trigger wins). PMWoGenCronTask évalue les PMs actifs.
Why C wrong — D2 invented : aucun trigger weather-based natif ; external integration + script possible mais pas standard.
Why D wrong — D4 adjacent : CM génère des WOs directement (MeasurePointWoGenCronTask), pas des PMs.
Why E wrong — D7 non-existent : aucun trigger PM basé sur un seuil de coût dans Maximo — scenario utile théoriquement (ex: "relancer PM si cost annuel > $10K") mais absent du produit. Les triggers sont Time-based ou Meter-based uniquement.
- IBM Docs — PM frequency options : Time + Meter
- Maximo Secrets — PM generation : Trigger modes
Create and manage Work Orders
📋 IBM Objectives
- WO creation sources: PM, CM point, manual
- Failure reporting · Asset Downtime reporting
- Maximo Route · assignments
- 3 Priority fields · Target Finish date calculation
💡 Key Points
- WO created from: PM, Condition Monitoring, manual
- 3 priorities: Asset Priority, WO Priority, CALCPRIORITY (calculated)
- CALCPRIORITY formula configured in Assignment Manager ⭐
- Work process flows → flag "Under Flow Control" on WO ⭐
- Route = sequence of assets/locations to inspect
⚠️ IBM Trap
CALCPRIORITY formula in Assignment Manager, not Formulas (doesn't exist), not Work Order Tracking.
Correct: C
Why C — Les 3 sources standard de création de WOs dans Maximo Manage sont : (1) Preventive Maintenance via le cron PMWoGenCronTask (planifié par fréquence temps ou meter), (2) Condition Monitoring via MeasurePointWoGenCronTask déclenché au franchissement d'Action Limits, (3) Création manuelle dans Work Order Tracking (formulaire complet) ou via l'application Service Requests qui peut "Create Work Order" pour transformer un ticket en WO. Un SR est une source manuelle indirecte — l'utilisateur clique explicitement sur Create WO. D'autres sources additionnelles existent (Scheduler, Mobile Technician, API REST pour intégrations) mais les 3 cœurs restent PM + CM + manuel.
Why A wrong — D3 wrong scope : les SLAs produisent des Escalations (notifications, actions sur tickets) mais ne créent pas de WOs directement ; un SLA peut déclencher une Escalation qui crée un WO, mais c'est de la configuration, pas une source standard.
Why B wrong — D4 adjacent : les Purchase Orders génèrent des Receipts, pas des maintenance WOs ; confusion classique avec les Direct Issue POs qui consomment du stock sur un WO existant.
Why D wrong — D2 invented : Job Plans et Routes sont appliqués à un WO (fournissent les tâches et la liste des assets) mais ne sont jamais la source ; Asset templates n'existe pas comme concept générateur de WO.
- IBM Docs — Work Order Tracking : WO creation sources
- Maximo Secrets — Work Order generation paths : PM, CM, manual
Correct: D
Why D — La hiérarchie canonique de failure reporting sur un WO est : Failure Class → Problem → Cause → Remedy. Elle se configure dans l'application Failure Codes et suit un modèle arborescent : le Failure Class (ex: "Pump") regroupe les Problems possibles (ex: "Leak", "Vibration"), chaque Problem liste ses Causes probables (ex: "Worn seal", "Cavitation"), chaque Cause ses Remedies (ex: "Replace seal", "Check suction"). Sur un WO, le technicien pick le Failure Class (souvent dérivé de l'Asset Class), puis Problem/Cause/Remedy par cascade. Cette structure alimente MTBF, Pareto de defaillance et RCA. IBM aligne cette taxonomie sur ISO 14224 (asset failure coding standard).
Why A wrong — D2 invented : "Problem → Class" inverse la hiérarchie — Class est racine, Problem est enfant ; piège classique parce que l'utilisateur pense spontanément "symptôme d'abord".
Why B wrong — D5 inversée : mettre Cause en premier casse complètement le modèle arborescent — la Cause est spécifique à un Problem, pas autonome.
Why C wrong — D9 near-synonym : mettre Remedy avant Problem inverse temporellement la séquence analytique — on diagnostique avant de traiter.
- IBM Docs — Failure Codes : Class/Problem/Cause/Remedy hierarchy
- Maximo Secrets — Failure Codes structure : Cascade on WO
Correct: A
Why A — CALCPRIORITY est le champ calculé sur le WO qui combine Asset Priority et Work Order Priority via une matrice configurable. Cette matrice se configure dans l'application Assignment Manager, section Priority Matrix : l'administrateur définit pour chaque couple (asset priority, WO priority) la CALCPRIORITY résultante (ex: asset critical 1 + WO priority 1 = CALCPRIORITY 1, la plus urgente). Une fois configurée, chaque nouveau WO voit sa CALCPRIORITY remplie automatiquement, et ce champ sert au tri/dispatch dans Assignment Manager et Scheduler. Piège IBM classique : les candidats cherchent CALCPRIORITY dans WO Tracking ou Organizations, mais c'est bien l'Assignment Manager qui porte la configuration de la matrice.
Why B wrong — D2 invented : aucune system property mxe.wo.calcpriority ne gouverne la matrice ; distracteur très plausible pour un candidat familier des system properties mais inexistant.
Why C wrong — D3 wrong scope : Application Designer édite l'UI (layouts, fields visibility) mais ne configure pas de logique de calcul ; il permettrait de cacher le champ, pas de le computer.
Why D wrong — D4 adjacent : Organizations → Work Order Options porte des dizaines de réglages (auto-numbering, downtime rules) mais pas la Priority Matrix ; confusion avec Organizations car beaucoup de réglages WO y sont.
- IBM Docs — Assignment Manager : Priority Matrix configuration
- Maximo Secrets — CALCPRIORITY logic : Matrix computation
Correct: B
Why B — Le flag Under Flow Control (case à cocher sur le WO parent et ses tasks) active l'enforcement des relations prédécesseur/successeur définies sur les tasks. Concrètement : si la task T2 a T1 en prédécesseur, Maximo empêche le démarrage (status INPRG) de T2 tant que T1 n'est pas COMP. Sans Under Flow Control, les relations sont documentaires seulement — un technicien peut passer T2 en INPRG même si T1 n'est pas finie. Ce flag est indispensable pour les scénarios complexes (turnaround d'usine, mise en service d'équipement, procédures avec permits). Le flag active aussi les transitions auto-status : T1 COMP peut automatiquement démarrer T2 si configuré. Piège classique IBM : tester si le candidat reconnaît la bonne terminologie Maximo vs synonymes fabriqués.
Why A wrong — D2 invented : "Apply Sequence Logic" sonne Maximo mais n'existe pas ; piège bien connu IBM repéré dans plusieurs practice tests.
Why C wrong — D2 invented : "Enforce Predecessors" décrit l'intention correcte mais n'est pas le nom Maximo officiel du champ.
Why D wrong — D2 invented : "Task Ordering Enabled" est une paraphrase fabriquée, pas un champ réel.
- IBM Docs — Work Order Flow Control : Under Flow Control flag
- Maximo Secrets — Work Order Flow : Predecessor/Successor mechanics
Correct: A, C
Why A/C — La formule CALCPRIORITY utilise exclusivement 2 inputs : Asset Priority (champ PRIORITY sur Asset, typiquement rempli via l'analyse de criticité) et Work Order Priority (champ WOPRIORITY saisi à la création du WO). L'Assignment Manager héberge la Priority Matrix qui croise ces 2 valeurs pour produire CALCPRIORITY. Chaque organisation peut définir sa propre matrice (ex: une matrice agressive pour une usine pétrochimique, plus conservatrice pour un site tertiaire). Si Asset Priority est null, Maximo utilise WO Priority seule. Ce système double permet de distinguer un WO "vite fait mais sur asset critique" (CALCPRIORITY haut) d'un "urgent sur asset mineur" (CALCPRIORITY moyen). Le champ sert au tri dans Assignment Manager et Scheduler.
Why B wrong — D2 invented : Job Plans portent des fields standards (description, tasks, est. hours) mais pas de priority field qui alimente CALCPRIORITY ; confusion possible avec WO priority qui peut être copié du Job Plan.
Why D wrong — D9 near-synonym : Location priority semble plausible mais la matrice standard Maximo utilise Asset priority, pas Location ; distracteur très tentant.
Why E wrong — D4 adjacent : Routes existent dans l'app Routes mais exposent stops + asset list, pas de priority field qui alimente CALCPRIORITY.
- IBM Docs — Assignment Manager priority matrix : Asset × WO priority
- Maximo Secrets — CALCPRIORITY : Formula inputs
Correct: A, B
Why A, B — Maintenance Cost Rollup agrège sur Asset les actuals des WOs de worktype maintenance : CM (corrective suite à panne), PM (planifié préventif). Aussi inclus par défaut : EM, INS, RELIAB, SAFETY. Exclus : CAPITAL (tracking GL project séparé), RELOC, RE-ARRANGE. Configurable par Organization (WO Options).
Why C wrong — D3 wrong scope : CAPITAL projects = GL project accounting, exclus du MCR.
Why D wrong — D2 invented : RETURN est un inventory transaction type (item returned to stock from WO or user) — pas un WO worktype. Confusion entre taxonomies : WO worktype classifie la nature du travail, RETURN classifie un flux item inventory.
Why E wrong — D9 near-synonym : "INVENTORY" n'est pas un worktype Work Order standard — confusion avec les inventory transactions (Issue, Receipt, Transfer) ou les cost categories. Les worktypes Maximo sont CM, PM, EM, INS, CAP, etc., jamais "INVENTORY".
- IBM Docs — WO worktypes : Standard types
- IBM Docs — Maintenance Cost Rollup : Worktype inclusion
Correct: A, B, C
Why A, B, C — Depuis APPR, transitions valides : INPRG (work starts), CAN (avant work, avec reason), WMATL (waiting materials si items short). Aussi : WPLAN, WSCH, HOLD selon config. Invalides : COMP (exige INPRG préalable), CLOSED (exige COMP), WAPPR (nécessite re-route workflow explicite). Statecycle Maximo configurable par Org.
Why D wrong — D5 inverted direction : la transition APPR → COMP est invalide dans le statecycle standard — le work doit started (INPRG) avant d'être completed (COMP). Sauter INPRG viole la logique lifecycle Maximo.
Why E wrong — D9 near-synonym : revenir d'APPR à WAPPR exige une action Select Action → Route Workflow explicite (nouvelle ronde d'approval) — pas une transition directe du statecycle. Distracteur qui assume une symétrie qui n'existe pas.
Why F wrong — D7 non-existent transition : aucun chemin direct APPR → CLOSED dans le statecycle — CLOSED atteignable uniquement après COMP (ou CAN), la transition proposée saute l'étape obligatoire, donc n'existe pas dans le state machine.
- IBM Docs — WO statuses : Statecycle transitions
- Maximo Secrets — WO lifecycle : APPR branches
Work Order Intelligence features (AI Broker)
📋 IBM Objectives
- System Properties configuration of AI Broker
- Identify and configure AI Cron Tasks
- Integration Framework apps enabling AI Broker
- Load training data · Train the model
- Accept AI Broker recommendations
- Improve Problem Code recommendations (Watson)
💡 3 System Properties
mxe.int.aibrokerapikey
mxe.int.aibrokerapiurl
mxe.int.aibrokertenantid
- Model: pcc (problem code classification)
- Base: Granite 3.0 8B Instruct (IBM watsonx)
- App: AI Configuration (Administration module)
- Publish Channel: WOPROBLEMCODE
💡 2 crucial facts
- Source field of the model = Work Order Description ⭐
- Improving accuracy = sufficient Description detail in training WOs ⭐
⚠️ IBM Trap
To improve the model: enrich the Descriptions, not "add more PMs" nor "add more Problem Codes".
Correct: D
Why D — Pour câbler Maximo Manage v9.0 au service AI Broker (inference LLM IBM Granite délivré avec MAS), l'administrateur configure exactement 3 System Properties dans l'application System Properties : (1) mxe.int.aibrokerapikey = la clé d'API secrète émise par le service AI Broker (stockée chiffrée), (2) mxe.int.aibrokerapiurl = l'URL du endpoint inference (typiquement https://aibroker.{cluster}/api/v1), (3) mxe.int.aibrokertenantid = l'identifiant du tenant MAS qui isole les prédictions par organisation. Le préfixe mxe.int. indique les propriétés d'intégration externes, distinctes de mxe.db., mxe.email., etc. Une fois configurées et sauvegardées (avec Live Refresh), l'AI Broker devient disponible dans l'app AI Configuration pour activer les use cases (Work Order Intelligence, Classification).
Why A wrong — D2 invented : mxe.ai.apikey sonne logique mais n'existe pas ; les propriétés réelles utilisent le préfixe mxe.int.aibroker pour marquer l'intégration inter-services.
Why B wrong — D9 near-synonym : la racine mxe.aibroker. omet le préfixe mxe.int. obligatoire ; erreur de noun structure que des practice tests médiocres propagent.
Why C wrong — D3 wrong scope : mxe.watsonx. référencerait un câblage direct watsonx.ai — mais en v9.0 c'est l'AI Broker (abstraction IBM) qui porte la connexion, pas watsonx.ai directement ; distracteur qui piège les candidats familiers de watsonx.
- IBM Docs — Configuring AI Broker : System properties exact names
- Maximo Secrets — AI Broker setup : mxe.int.aibroker* config
Correct: A
Why A — Le champ Work Order Description (texte en langage naturel, typiquement saisi par le requester ou le planner) est le primary input que le LLM IBM Granite, via l'AI Broker, analyse pour prédire : Failure Class, Problem Code, suggested Asset (si non rempli), Classification ID, Priority. Le modèle est entraîné sur des millions de WOs historiques : il extrait l'intent ("fuite hydraulique sur pompe centrifuge") et match avec la taxonomie du tenant. Plus la Description est détaillée et consistante (mêmes termes techniques, mêmes abréviations), plus les predictions sont fiables. D'autres champs comme Location ou Reported By alimentent le contexte, mais la Description reste le signal sémantique dominant. C'est pourquoi IBM recommande aux admins de former les techniciens à écrire des descriptions complètes plutôt que "voir ticket".
Why B wrong — D4 adjacent : Asset ID peut être une cible de prédiction (si non rempli) mais pas l'input principal — le Work Order Description est consommé pour produire l'Asset ID, pas l'inverse.
Why C wrong — D8 verbe imprécis : Reported By est un identifiant utilisateur (metadata) sans contenu sémantique métier ; aucune utilité pour l'inférence LLM.
Why D wrong — D3 wrong scope : le Work Order Number est un identifiant technique sans aucun contenu sémantique — confusion possible pour un candidat qui imagine que "tout est analysé".
- IBM Docs — Work Order Intelligence : Description as primary input
- Maximo Secrets — AI Broker predictions : Data quality impact
Correct: B
Why B — Puisque la Description est le primary input du LLM, améliorer sa qualité est le levier #1 pour monter la précision. Leviers concrets : (1) former les techniciens à écrire ≥20 mots avec termes techniques précis (ex: "fuite hydraulique 50 L/h sur joint spi primaire côté moteur" vs "fuite"), (2) standardiser le vocabulaire via une taxonomie interne (utiliser "bearing" systématiquement au lieu de "palier/roulement/coussinet"), (3) auto-complétion via dropdowns sur Failure Class pour pré-contraindre, (4) feedback loop : quand l'AI se trompe, corriger le WO complètement — le modèle apprend via re-training périodique. IBM publie les guidelines "Data quality for AI Broker" : garbage in, garbage out. Sans Description riche, aucun tuning ou upgrade de modèle ne compense.
Why A wrong — D8 verbe imprécis : augmenter la fréquence du cron accélère les predictions mais n'améliore pas leur qualité — la fréquence concerne la latence, pas l'accuracy.
Why C wrong — D2 invented : aucun toggle "watsonx.ai fallback" dans le produit ; les candidats habitués à multi-cloud cherchent ce genre d'option par réflexe mais elle n'existe pas.
Why D wrong — D3 wrong scope : le modèle Granite est fixé par IBM dans la delivery officielle ; l'admin client ne peut pas swap vers un autre modèle — cela exigerait une custom AI Broker (hors scope exam).
- IBM Docs — Data quality for AI Broker : Description quality
- Maximo Secrets — AI Broker tuning : Levers for accuracy
Correct: C
Why C — Dans Maximo Manage v9.0, l'AI Broker embarque des modèles de la famille IBM Granite (Granite-13B, Granite-20B selon les fix packs). Granite est la suite LLM open-source développée par IBM Research, positionnée comme alternative enterprise aux LLMs propriétaires (GPT, Claude) et communautaires (Llama, Mistral). Spécificités Granite utilisées dans AI Broker : (1) fine-tuning sur corpus industriel MRO/EAM, (2) support on-prem + cloud pour respecter la data residency, (3) audit trail complet des prompts/completions pour conformité SOC2/ISO 27001. Le client n'a pas besoin de choisir le modèle — IBM livre un binding pré-configuré et met à jour Granite par fix pack. Piège IBM : tester si le candidat reconnaît Granite comme famille IBM vs autres LLMs populaires.
Why A wrong — D2 invented : Llama 3 70B est un LLM Meta, pas celui livré par IBM ; confusion classique pour candidats familiers de la scène open-source.
Why B wrong — D3 wrong scope : GPT-4 Turbo est un modèle OpenAI, jamais livré par IBM nativement ; IBM reste souverain sur sa stack LLM via Granite.
Why D wrong — D9 near-synonym : Mistral Large 2 est une vraie famille LLM (adjacent taxonomy, EU-based) mais pas le modèle IBM-delivered ; distracteur très plausible pour un candidat qui suit la scène LLM européenne.
- IBM Docs — AI Broker Granite models : Granite family default
- IBM Research — Granite foundation models : Enterprise LLMs
Correct order: A → B → C → D
Why this order — La séquence IBM officielle pour activer l'AI Broker suit une logique bottom-up : on câble d'abord la plomberie technique, puis l'abstraction métier, puis on active le use case spécifique, puis on valide avec données réelles. Étape 1 — Configurer les 3 System Properties (mxe.int.aibrokerapikey, -apiurl, -tenantid) : sans cette connectivité, rien en aval ne fonctionne. Étape 2 — Ouvrir l'application AI Configuration et enregistrer le endpoint AI Broker : Maximo teste la connexion et expose les use cases disponibles côté broker. Étape 3 — Activer le use case Work Order Intelligence : le cron task WoAIBrokerPredictor est enrôlé pour scanner les nouveaux WOs et appeler l'API inference. Étape 4 — Créer un WO test avec description riche pour valider que les predictions remontent dans les champs cibles (Failure Class, Classification, Asset). Sans cette séquence, on risque des erreurs silencieuses (cron actif mais API down, predictions vides mais jamais diagnostiquées). Ordre inverse (valider avant config) = impossible.
- IBM Docs — AI Configuration app : Setup sequence
- Maximo Secrets — AI Broker end-to-end : Activation workflow
Configure Asset Maintenance Cost Rollup
📋 IBM Objectives
- Costs included in calculated maintenance cost
- Enable automatic cost Rollup
💡 Key Points
- Costs included: labor, material, tool, service
- Auto rollup activated via Organizations settings
- Roll-up = child costs → parent in asset hierarchy
Correct: A
Why A — Le Maintenance Cost Rollup agrège sur l'asset 4 catégories de coûts provenant des actual transactions du WO (label court IBM, mais en détail 6 sous-catégories) : (1) Labor = labor transactions (internal + external), heures × rate, (2) Material = matitem transactions, stock issues from inventory + direct POs, (3) Tool = tool transactions (internal + external), usage hours × rate, (4) Service = service transactions, services externalisés facturés. Ces 4 buckets sont visibles sur l'Asset dans l'onglet Maintenance (champs LABCOST, MATCOST, TOOLCOST, SERVCOST) + un total TOTALCOST. Agrégation ascendante via la hiérarchie parent asset. Base : actuals seulement (pas de Planned/Budgeted).
Why B wrong — D2 invented : Overhead et Depreciation ne sont pas des catégories Maximo Cost Rollup ; elles existent en comptabilité analytique mais ne remontent pas via le mécanisme Cost Rollup standard.
Why C wrong — D9 near-synonym : le split Internal/External Labor est réel au niveau transaction, mais Maximo agrège en 1 bucket Labor pour le Cost Rollup final ; le split se retrouve ailleurs (labor transactions report).
Why D wrong — D3 wrong scope : Planned/Actual/Budgeted/Variance sont des états de coût (phases du lifecycle budget), pas des types. Confusion classique avec Budget Monitoring.
- IBM Docs — Maintenance Cost Rollup : 4 cost categories
- Naviam — Maintenance Cost Accumulation with MAS : Labor/Material/Tool/Service
Correct: B
Why B — L'activation globale du Maintenance Cost Rollup se fait dans l'application Organizations, via More Actions → Work Order Options → Maintenance Cost Rollup Settings. L'administrateur par organisation choisit : (1) si le rollup est actif (on/off par org — multi-org peut diverger), (2) quelles catégories sont rollées (Labor, Material, Tool, Service — souvent toutes les 4), (3) timing du rollup (automatique au status CLOSE du WO vs manual only via action Assets). L'opt-in par organisation permet aux groupes avec GL distinctes d'adopter le rollup indépendamment. Une fois activé, le système déclenche le rollup dans la même transaction que le WO close (ACID-safe). Cette configuration est distincte de mxe.workorder.rollupMaintenanceCosts qui porte plus précisément le timing auto vs manuel.
Why A wrong — D4 adjacent : Assets affiche les résultats du rollup (TOTALCOST, LABCOST…) et expose l'action manuelle "Roll Up Maintenance Costs" — mais c'est Organizations qui porte le switch global d'activation.
Why C wrong — D2 invented : aucune system property mxe.cost.rollup n'existe ; la vraie property related est mxe.workorder.rollupMaintenanceCosts mais elle ne contrôle pas l'activation globale, juste le mode auto.
Why D wrong — D3 wrong scope : Chart of Accounts gère les GL codes (imputations comptables) mais pas la mécanique de rollup technique entre WO et Asset.
- IBM Docs — Organizations Work Order Options : Maintenance Cost Rollup settings
- Projetech — Maintenance dollar rollup : Org-level configuration
Correct: A
Why A — La politique d'auto-rollup des coûts de maintenance au close d'un Work Order est configurée dans l'application Organizations, via l'action More Actions → Work Order Options → Edit Rules et la propriété système mxe.workorder.rollupMaintenanceCosts (qui, à 1, active le rollup automatique au status CLOSE). Les 6 catégories de coût (Internal Labor, External Labor, Internal Tool, External Tool, Material, Service) sont agrégées sur l'Asset lié au WO, remontant la hiérarchie parent. Avant d'activer ce flag, IBM recommande de faire un rollup manuel initial (Assets → Roll Up Maintenance Costs) pour purger les coûts existants non-rollés, sinon ils restent orphelins.
Why B wrong — D9 near-synonym : l'application System Properties héberge techniquement la prop mxe.workorder.rollupMaintenanceCosts, mais la réponse IBM-canonique pour le C1000-183 est Organizations car c'est le point d'entrée fonctionnel (Work Order Options) — System Properties n'a pas d'UI dédiée à ce réglage métier.
Why C wrong — D4 adjacent app : Work Order Tracking est l'application où on gère individuellement un WO (création, approbation, close) ; elle n'héberge aucune policy d'auto-rollup. Confondre « où les coûts sont collectés » avec « où la policy est définie ».
Why D wrong — D3 wrong scope : Assets opère au niveau record individuel (un asset à la fois) et expose l'action manuelle Roll Up Maintenance Costs pour rattraper des coûts non-rollés ; c'est un one-shot per-asset. La config de la policy automatique vit un niveau au-dessus sur Organizations (scope Org, pas asset). Piège subtil — candidat qui sait que « Rollup se voit sur Asset » mais ignore où la policy est définie.
- IBM Docs — Rolling up maintenance costs via automation script : mxe.workorder.rollupMaintenanceCosts
- Naviam — Understanding Maintenance Cost Accumulation with MAS : 6 cost categories
- IBM Support — Roll up maintenance costs after upgrade : Pre-requisite manual rollup
- Projetech — Where does the maintenance dollar go : Cost hierarchy model
Usage of Inspections
📋 IBM Objectives
- Types of questions available on inspection forms
- Conditional questions
- Record types associable with inspection forms
- Follow-up work: Require Action, Automation Script
- MVI integration with Inspection Forms
💡 Question types
- Conditional questions: show/hide based on previous answer
- Associated with: WO, Ticket, PM
- Follow-up: Require Action OR Automation Script
- MVI: image question → auto damage analysis via watsonx
Correct: B
Why B — L'application Inspections de Maximo Manage v9.0 supporte nativement une large panoplie de response types, sans script ni customization. Liste officielle IBM : Date only, Date and time, File upload, Meter readings, Multiple choice, Multiple choice domain, Single numeric entry, Single choice, Single choice domain, Signature, Time only, Text response (environ 12 types). Chaque question peut porter : (1) un response type, (2) un domain (pour single/multiple choice avec valeurs contraintes), (3) une response action (requires follow-up if answer matches a condition), (4) une conditional display (show/hide selon réponses précédentes). Cette richesse permet de digitaliser checklists ISO, safety tours, round sheets, quality checks avec un seul moteur. Distracteurs IBM classiques : nombre minimisé (juste 2 types) ou type inventé (Inspection Response Router).
Why A wrong — D6 cardinalité : limiter à Yes/No et Numeric ignore 10 autres types natifs ; sous-estimation grossière.
Why C wrong — D2 invented : Signature est bien un type natif mais il est un parmi 12, pas le seul ; limitation fabriquée.
Why D wrong — D7 non-existent : aucun composant "Inspection Response Router" n'existe — les responses sont stockées directement sur le record Inspection result via l'ORM Maximo.
- IBM Docs — Inspection question types : 12 native response types
- Maximo Secrets — Inspections overview : Response mechanics
Correct: C
Why C — Le Inspection Form Designer supporte nativement les conditional display rules : on définit sur chaque question une condition qui référence les réponses à des questions antérieures pour montrer/cacher des questions suivantes. Exemple : "Si Q1 'Equipment is running' = No, alors montrer Q5 'Describe downtime reason'". Configuration : section Conditions sur la question cible, choisir operator (=, ≠, >, <), valeur référence. Pas de script, pas d'App Designer, pas de workflow. Supporte aussi le chaining (Q5 visible si Q1=No AND Q2=Critical). Cette capacité évite de créer plusieurs formulaires pour des variantes et garde la checklist lisible (questions non pertinentes masquées). Best practice : ne pas abuser — trop de conditions nuit à la lisibilité et à la testability.
Why A wrong — D5 direction inversée : les scripts sont possibles pour des actions avancées (post-submit) mais pas requis pour le conditional display standard qui est natif.
Why B wrong — D3 wrong scope : Application Designer édite l'UI des applications Maximo, pas le contenu des Inspection Forms ; confusion de niveaux.
Why D wrong — D8 verbe imprécis : chaîner plusieurs formulaires fonctionne techniquement mais c'est un workaround laid, pas le mécanisme IBM-supported — les conditions natives sont exactement faites pour ça.
- IBM Docs — Conditional questions in Inspections : Native conditional display
- Maximo Secrets — Inspection designer : Conditional rules
Correct: D
Why D — Les Inspection Forms s'associent à 3 types de records transactionnels : (1) Work Orders — le cas le plus fréquent, l'inspection fait partie d'une task (ex: "check 5 safety points before starting the WO"), (2) Tickets (Service Requests, Incidents, Problems) — inspection documentaire lors de la qualification d'un ticket, (3) PMs — l'inspection est intégrée au modèle PM, copiée sur chaque WO généré. Cette triade couvre les 3 flux métier où une checklist rigide ajoute de la valeur : curatif (WO), déclaratif (Ticket), préventif (PM). L'association se fait soit au niveau du record parent (WO → 1 inspection form globale), soit au niveau de la task dans un Job Plan (chaque task peut avoir sa propre inspection). Les responses sont stockées avec l'inspection result record, horodatées et signées (si type Signature activé).
Why A wrong — D2 invented : limiter à WO seul ignore Tickets et PMs qui sont explicitement documentés ; sous-estimation courante.
Why B wrong — D4 adjacent : Assets ne sont pas la cible d'association directe d'une Inspection Form — l'inspection s'ancre sur un WO qui référence un asset, ou sur un PM qui vise un asset.
Why C wrong — D3 wrong scope : les Purchase Orders ne sont pas une cible Inspections ; ils peuvent avoir leurs propres validations (Receipts, Inspection on Receipt) mais c'est un mécanisme distinct géré dans Inventory.
- IBM Docs — Associating Inspection Forms : WO, Ticket, PM
- Maximo Secrets — Inspection targets : Record type associations
Correct: A, C
Why A/C — Les follow-up actions depuis une Inspection se déclenchent via 2 mécanismes documentés IBM : (1) Require Action option — cochée directement sur la question ou sur une response value spécifique. Quand l'inspecteur saisit cette response (ex: "Pipe corrosion = Severe"), le flag Require Action déclenche automatiquement la création d'un follow-up WO (configurable : Job Plan, priority, target date) attaché au WO parent ou à l'asset. Approche low-code, sans programmation. (2) Automation Script bound to Inspection save/update event : script Jython ou Python qui s'exécute sur le beforesave ou aftersave de l'objet Inspection. Permet logique complexe (ex: "si 3 Yes/No à Poor, créer WO Critical + email superviseur"). Ces 2 mécanismes couvrent 95% des besoins follow-up : Require Action pour les règles simples, Automation Scripts pour la logique métier.
Why B wrong — D4 adjacent : les Escalations fonctionnent sur la détection de conditions temporelles (tickets non traités depuis X heures), pas sur les Inspection responses ; mécanisme différent.
Why D wrong — D3 wrong scope : les SLAs ciblent response time / compliance sur Tickets et WOs, pas l'analyse de contenu d'une Inspection response ; hors scope.
Why E wrong — D2 invented : Maximo Visual Inspection (MVI) enrichit les inspections via image AI (détection de rouille, fissures) mais c'est un enrichment de la response elle-même, pas un trigger de follow-up — sémantique différente.
- IBM Docs — Inspection follow-up actions : Require Action + Scripts
- Maximo Secrets — Inspections automation : Follow-up patterns
Planning and Scheduling applications
📋 IBM Objectives
- Graphical Work Week
- Graphical Scheduling
- Graphical Assignment
- Scheduling Dashboard
- Dispatching Dashboard
💡 Role of each app
- Graphical Work Week — weekly crew view
- Graphical Scheduling — WO Gantt scheduling (projects/TAR)
- Graphical Assignment — labor/craft assignment
- Scheduling Dashboard — schedule supervision (utilization, leveling, issues)
- Dispatching Dashboard — real-time dispatch (Gantt + emergency)
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: C
Why C — Graphical Work Week est l'app Maximo Scheduler dédiée au long-horizon capacity planning : vue week-by-week sur plusieurs mois, au niveau crew (groupe de labor). Permet de vérifier si la charge prévue est compatible avec la capacity disponible avant d'engager des WOs fermes. Complément stratégique aux apps tactiques (Graphical Scheduling pour dates jour-par-jour, Dispatching pour intraday).
Why A wrong — D4 adjacent : Scheduling Dashboard agrège utilization + issues, mais ne fait pas de week-planning actif.
Why B wrong — D9 near-synonym : Graphical Scheduling est tactical (jour/semaine) pour WOs individuels, pas long-horizon crew capacity.
Why D wrong — D7 non-existent : « Graphical Horizon Planner » n'est pas une app Maximo.
- IBM Docs — Graphical Work Week : Long-horizon planning
- Maximo Secrets — Scheduler apps : App map
Correct: D
Why D — Graphical Assignment est l'app dédiée à l'assignation de labor resources individuels aux tasks WO. Vue Gantt montrant les techniciens en lignes et les assignments en bars horizontales. Honore : availability calendars (shift/vacances), qualifications (craft + skill level required vs owned), assigned capacity. C'est l'étape après scheduling (dates fixées) et avant dispatching (execution).
Why A wrong — D4 adjacent : Scheduling Dashboard est un KPI aggregator (taux utilisation crews, WOs scheduled vs unscheduled, compliance rate) — app adjacente du Scheduler suite mais pas une surface d'assignment. Les assignments se font dans Graphical Assignment.
Why B wrong — D9 near-synonym : Graphical Scheduling pose les DATES des WOs, pas les labor assignments.
Why C wrong — D3 wrong scope : Graphical Work Week est weekly crew capacity, granularité différente.
- IBM Docs — Graphical Assignment : Labor assignment Gantt
- Maximo Secrets — Scheduler overview : App portfolio
Correct: A
Why A — Dispatching Dashboard est l'app temps-réel pour la journée d'exécution : Gantt montrant les techniciens en action, leurs assignments courants, et les issues (retards, re-assignments d'urgence, qualification gap). Le dispatcher peut cliquer-glisser pour réaffecter un WO à un autre technicien qualifié en milieu de shift. Distinct des apps planification (Scheduling, Assignment) qui préparent le schedule avant le jour J.
Why B wrong — D1 legacy : Graphical Scheduling est pour pose de dates, pas dispatching temps-réel.
Why C wrong — D9 near-synonym : Scheduling Dashboard est un KPI aggregator au niveau direction (utilization rates, issues count), pas une Gantt d'exécution comme Graphical Scheduling ou Dispatching Dashboard. Layers différents : strategic vs tactical vs execution.
Why D wrong — D4 adjacent : Graphical Work Week est une app dédiée au long-horizon capacity planning hebdomadaire (crews vs workload forecast) — pas une app d'exécution tactique intraday. Use case différent dans la suite Scheduler.
- IBM Docs — Dispatching Dashboard : Day-of-execution
- Maximo Secrets — Scheduler apps : App map
Correct: A, B, D
Why A, B, D — Maximo Scheduler v9 livre 5 apps : Graphical Scheduling (pose dates WOs), Graphical Assignment (labor assignments), Scheduling Dashboard (KPIs aggregator), Graphical Work Week (long-horizon weekly capacity), Dispatching Dashboard (execution Gantt). Les trois Q-correct en couvrent 3 ; les deux autres (Work Week, Dispatching) sont les options cachées.
Why C wrong — D1 legacy : « Scheduling Planner » est un nom générique, pas une app Maximo.
Why E wrong — D2 invented : capacity planning est couvert par Work Week, pas une app dédiée.
Why F wrong — D3 wrong scope : « Graphical Routing » n'existe pas en Scheduler v9 (optimization de routes se fait via modèle Minimum Travel dans l'Optimizer).
- IBM Docs — Scheduler applications : 5 apps
- Maximo Secrets — Scheduler map : App portfolio
Correct: D
Why D — Scheduling Dashboard est une vue d'agrégation non-Gantt affichant les KPIs de schedule : Resource Utilization (% de capacity allocated), Workload Leveling (distribution sur la période), Scheduling Issues (WOs sans dates, durées manquantes, conflits). Sert de « control tower » au planner pour détecter les anomalies avant execution. N'édite pas directement les WOs ; renvoie vers Graphical Scheduling pour action corrective.
Why A wrong — D4 adjacent : Graphical Scheduling EST le Gantt editor, pas un aggregator KPI.
Why B wrong — D9 near-synonym : Dispatching Dashboard est une app d'exécution Gantt temps-réel (Tech assignments, statut INPRG, réaffectation à la volée) — pas une vue KPI de planning stratégique. Layer operations, pas analytics.
Why C wrong — D3 wrong scope : Graphical Assignment est l'app d'assignation individuelle de Labor aux WO tasks (swimlanes par tech) — action tactique, pas une vue d'agrégation. Les vues KPI appartiennent au Scheduling Dashboard, layer différent.
- IBM Docs — Scheduling Dashboard : KPI views
- Maximo Secrets — Scheduler overview : Dashboard role
Correct: A, B
Why A, B — Graphical Scheduling expose 2 modes de visualisation : Gantt view (chronogramme time-scaled, barre par WO/task avec dependencies predecessor/successor) et Resource view (swimlanes par Labor/Crew pour visualiser la charge et détecter overbookings). Data partagée (WPLABOR, ASSIGNMENT), angles complémentaires : Gantt = quoi+quand, Resource = qui+quand.
Why C wrong — D4 adjacent : les pivot tables sont des features reporting (générées via BIRT ou Report Scheduler) — app adjacente dans MAS, mais hors du Scheduler core qui reste focalisé sur les views temps-planning (Gantt + Resource).
Why D wrong — D2 invented : aucune visualisation "heatmap calendar" native dans Graphical Scheduling — la heatmap est un pattern data-viz populaire dans Grafana/Tableau mais pas offert dans les views Maximo Scheduler qui restent Gantt + Resource swimlanes.
Why E wrong — D3 wrong scope : geographic mapping dans Spatial apps séparées, pas Graphical Scheduling.
- IBM Docs — Graphical Scheduling : Gantt + Resource views
- Maximo Secrets — Scheduler apps : Views overview
Prepare records with Scheduler Data Manager
📋 IBM Objectives
- Scheduler Data Manager · validations performed
💡 Key Points
- Scheduler Data Manager validates records before Scheduler use
- Validations: consistent dates, positive durations, valid job plans, schedulable fields filled
- Without it, Optimizer returns sub-optimal or failing results
Correct: D
Why D — Le Scheduler Data Manager est un validator pre-flight pour le Scheduler Optimizer. Avant de passer un batch de WOs à l'Optimizer (CPLEX), Data Manager vérifie que chaque record a les données requises : target/scheduled dates, task durations, Job Plan référencé, flag is schedulable, resources assignées. Les records incomplets sont flagged et exclus du run optimizer. Évite que CPLEX plante sur des inputs incohérents et donne un rapport d'erreurs actionable.
Why A wrong — D3 wrong scope : l'export vers watsonx.ai depuis Scheduler Data Manager n'existe pas — watsonx.ai est un service ML/LLM externe, et Scheduler Data Manager ne dispose d'aucun connecteur direct. Les intégrations ML dans MAS passent par AI Broker, pas par Scheduler.
Why B wrong — D4 adjacent : archiving est géré par Database Configuration / archive utilities, pas Data Manager.
Why C wrong — D2 invented : aucun mécanisme natif "merge calendars cross-Organization" dans Maximo Scheduler — chaque calendar est scopé Org, et consolider plusieurs Orgs nécessite soit une duplication manuelle, soit un export/import CSV, soit un script custom. Pas de fonctionnalité out-of-box pour merger.
- IBM Docs — Scheduler Data Manager : Pre-flight validator
- IBM Docs — Optimizer workflow : Data Manager → Optimizer
Correct: A
Why A — Scheduler Data Manager valide les fields nécessaires à l'optimisation : Target Start / Target Finish (fenêtre d'exécution), Scheduled Start / Scheduled Finish (dates calculées), Duration (task durations par WOACTIVITY), Job Plan reference (source des tasks + labor reqs), Schedulable flag (WO.ISSCHEDULABLE = 1). Ces champs sont les inputs obligatoires au solver CPLEX ; sans eux, l'Optimizer échoue ou produit un schedule incomplet.
Why B wrong — D6 cardinality : Status + Priority seuls sont insuffisants — le scheduler a besoin de dates/durées.
Why C wrong — D3 wrong scope : Failure Class + Problem codes concernent reliability reporting, pas scheduling pre-flight.
Why D wrong — D9 near-synonym : Reported By + Reported Date sont metadata de ticket, pas scheduling inputs.
- IBM Docs — Data Manager validation : Required fields
- IBM Docs — Scheduler Optimizer : CPLEX inputs
Correct order: A → B → C → D
Why this order — Le workflow canonique Scheduler : (1) Load WOs — le planner sélectionne les WOs candidats à l'optimisation dans le Schedule record (via query saved ou filter) ; (2) Data Manager validate — pre-flight check pour éliminer les WOs aux données incomplètes ; (3) Optimizer execute — CPLEX calcule le schedule optimal selon le modèle choisi (Date-based, Priority, Resource-leveled, Minimum Travel) ; (4) Review results — le planner valide le schedule dans Graphical Scheduling ou Scheduling Dashboard, ajuste manuellement si besoin.
- IBM Docs — Scheduler optimization workflow : 4 steps
- Maximo Secrets — Scheduler : End-to-end flow
Configure Maximo Optimizer
📋 IBM Objectives
- Deploy and activate Maximo Optimizer
- Optimization models
- Maximo Optimizer Administration
💡 Embedded technology
Models: resource leveling, schedule optimization, qualification matching, travel minimization.
Deployed via MAS Admin → Activate Optimizer component.
⚠️ IBM Trap
🎯 Flashcard
Q. What technology does Maximo Optimizer embed?
Show answer
IBM ILOG CPLEX Optimization Studio
Correct: D
Why D — Le moteur d'optimisation embarqué dans Maximo Scheduler Optimizer est IBM ILOG CPLEX Optimization Studio — le solver industriel de IBM pour programmation linéaire mixte-entière (MILP). IBM cite CPLEX nommément dans la doc Scheduler. Ce choix historique (CPLEX acquis par IBM en 2009) donne un solver proven-grade capable de résoudre des schedules complexes avec des centaines de WOs + contraintes de ressources, qualifications, calendars, travel.
Why A wrong — D2 invented : watsonx.ai Optimizer n'existe pas sous ce nom pour Scheduler.
Why B wrong — D3 wrong scope : Cloud Pak for Data est une plateforme analytique, pas le moteur Scheduler.
Why C wrong — D9 near-synonym : Gurobi est un solver concurrent réel mais pas bundled dans Maximo.
- IBM Docs — Scheduler Optimizer engine : CPLEX bundled
- IBM ILOG CPLEX Optimization Studio : Solver details
Correct: B
Why B — Les 4 modèles Optimizer standards de Maximo Scheduler : Date-based (honore les target dates), Priority-based (exécute les high-priority first), Resource-leveled (aplatit workload), Minimum Travel (minimise déplacements géo). « Cost-minimization » n'est PAS un modèle livré — la cost optimization passe par Cost Management ailleurs dans Manage.
Why A wrong — D9 near-synonym : Date-based est un vrai modèle de scheduling livré avec Maximo Scheduler, mais ce n'est pas la réponse exacte attendue par la question qui vise un autre modèle spécifique. Distracteur inclus comme "vrai mais pas le demandé".
Why C wrong — D9 near-synonym : Resource-leveled est un vrai modèle livré (workload flattening sur labor availability) mais répond à un use case différent de ce que demande la question. Distracteur "vrai ailleurs" classique.
Why D wrong — D9 near-synonym : Priority-based est un vrai modèle scheduling livré qui ordonne par CALCPRIORITY, mais pas celui demandé ici. Distracteur piège pour candidat qui connaît l'existence mais confond les use cases.
- IBM Docs — Optimization models : 4 models
- Maximo Secrets — Scheduler Optimizer : Model types
Correct: C
Why C — En v9, l'Optimizer est déployé comme une containerized workload via MAS Admin (Suite Administration workspace). Cette approche remplace l'installation manuelle legacy. Le solver embarqué reste IBM ILOG CPLEX (consistent avec Q9). L'architecture containerisée permet : scale-out horizontal, ressource limits par pod (CPU/memory budget), lifecycle géré par OCP operator. Le Suite Admin configure les optimization jobs via l'UI, pas de scripts bash direct.
Why A wrong — D1 legacy : install manuel par script était le pattern 7.6 ; v9 est containerisé.
Why B wrong — D5 inverted direction : Scheduler Optimization supporte les 2 deployment modes MAS (On-Premises OCP + SaaS Flex) — pas restreint à SaaS. Distracteur qui inverse artificiellement la portée du feature.
Why D wrong — D2 invented : « Scheduler Optimizer Agent helm chart » n'existe pas — c'est un Suite-managed workload.
- IBM Docs — Optimizer deployment : Containerized
- IBM Docs — MAS Admin : Deployment mgmt
Correct: D
Why D — Le modèle Resource-leveled Optimization aplatit la charge des resources en redistribuant les WOs sur l'horizon pour éviter les pics d'overload. L'objective function minimise la variance de l'utilization. Utile quand une small équipe de techniciens doit absorber un backlog — le modèle lisse sur 2-3 semaines au lieu de tout concentrer au début. Compromis : certains WOs seront planifiés après leur target date optimal.
Why A wrong — D1 legacy : Date-based honore les due dates sans niveler la charge.
Why B wrong — D4 adjacent : Priority-based ordonne les WOs par CALCPRIORITY descendante (urgent en premier) — critère d'ordonnancement différent du load balancing demandé par la question. Confusion classique entre "prioriser" et "lisser la charge", 2 objectifs orthogonaux.
Why C wrong — D9 near-synonym : Minimum Travel minimise les déplacements géo, pas le workload.
- IBM Docs — Resource-leveled model : Workload flattening
- IBM Docs — Optimization models overview : 4 models
Correct: B
Why B — Le modèle Minimum Travel Optimization regroupe géographiquement les WOs pour minimiser le travel time total des techniciens. Utilise les coordonnées des Locations et des shape files ou distances entre Sites. Idéal pour field services dispersés (utility, telecom, property management) où le travel peut représenter 20-40% du temps tech. Le modèle intègre aussi les shifts et break constraints pour produire un routing réaliste.
Why A wrong — D2 invented : Date-based est un vrai modèle mais adresse les dates, pas le travel.
Why C wrong — D4 adjacent : Resource-leveled est un modèle orienté workload flattening (lisser la charge labor/crew sur la période) — use case adjacent mais distinct de ce que vise la question. Confusion classique entre modèles optimization objectifs.
Why D wrong — D7 non-existent coverage : Priority-based est un vrai modèle Scheduler mais ne couvre pas la problématique travel time minimization — il ordonne uniquement par CALCPRIORITY descendant, sans logique géo. Piège "vrai modèle mais mauvais scope".
- IBM Docs — Minimum Travel : Routing optimization
- IBM Docs — Optimization models : 4 models
Scheduling and Dispatching Dashboards
📋 IBM Objectives
- Prepare schedules and work lists for dashboards
- Optimize schedules including matching qualifications
- Review resource utilization and leveling in Scheduling Dashboard
- Gantt chart in Dispatching Dashboard
- Scheduling issues (Scheduling) vs assignment issues (Dispatching)
- Assign emergency work in Dispatching Dashboard
💡 Key Points
- Scheduling Dashboard review = utilization + leveling + scheduling issues ⭐
- Dispatching Dashboard = Gantt + assignment issues + assign emergency work
⚠️ IBM Trap
🎯 Flashcard
Q. What is reviewed on the Scheduling Dashboard?
Show answer
Resource utilization, resource leveling, scheduling issues.
Correct: B
Why B — Le Scheduling Dashboard expose trois vues agrégées clés au planner : Resource Utilization (% de capacity allouée par crew/craft), Workload Leveling (distribution du workload sur l'horizon), Scheduling Issues (WOs mal-formed, conflits de resources, dates manquantes). C'est la « tour de contrôle » du planificateur — il y repère les anomalies avant execution et redirige vers les apps tactiques (Scheduling, Assignment) pour remédier.
Why A wrong — D1 legacy : les cost/budget dashboards relèvent de l'app Cost Management et des Budget Monitoring tools (Financial suite) — pas du Scheduler qui reste time-centric (dates, durations, capacities). Taxonomie d'apps MAS claire sur ce point.
Why C wrong — D3 wrong scope : SLA monitoring, Inspection tracking et Inventory analytics vivent chacun dans leurs propres dashboards/apps dédiés (SLA Administration, Inspections, Inventory) — pas dans le Scheduling Issues Dashboard qui reste focalisé sur les problèmes de placement/capacity/dates des WOs.
Why D wrong — D4 adjacent : reliability analytics (failure codes, MTBF) sont dans Health / reliability.
- IBM Docs — Scheduling Dashboard : 3 views
- Maximo Secrets — Scheduler map : Dashboard role
Correct: C
Why C — Le Dispatching Dashboard affiche un Gantt chart temps-réel des techniciens (lignes) et de leurs assignments courants (bars), avec visualization des issues : qualification gaps, overlapping shifts, travel issues, delays. Le dispatcher voit en un coup d'œil qui est disponible, qui est engagé, et où les problèmes se manifestent. Les issues sont highlighted en rouge et drill-down permet re-assignment drag-drop.
Why A wrong — D3 wrong scope : calendar heatmap SLA breaches relève du SLA dashboard.
Why B wrong — D4 adjacent : cost variance charts vivent dans Cost Management / reporting apps.
Why D wrong — D8 imprecise : pie chart est trop simpliste pour le Dispatching réel.
- IBM Docs — Dispatching Dashboard : Gantt + issues
- Maximo Secrets — Scheduler : Dashboard anatomy
Correct: D
Why D — Le Dispatching Dashboard est conçu pour le re-assignment temps-réel intraday. Scenario typique : WO urgent (leak, outage) doit être assigné au plus proche technicien qualifié. Le dispatcher sélectionne le WO, filtre les techniciens actuellement disponibles + qualifiés (match craft + skill + proximité géographique). Un clic réassigne ; le technicien courant reçoit une notification push sur mobile (Maximo Mobile) pour redirection immédiate.
Why A wrong — D1 legacy : Graphical Work Week est dédié au long-horizon capacity planning (semaines/mois forward-looking) — pas adapté pour l'exécution mid-shift (intraday re-dispatching) qui relève plutôt du Dispatching Dashboard.
Why B wrong — D2 invented usage : Scheduling Dashboard est un KPI aggregator strategic (taux, compliance, alerts) — jamais utilisé comme assignment UI où l'on picks individually le labor. Confusion functionnelle classique.
Why C wrong — D4 adjacent : Graphical Scheduling est orienté planification (poser les dates futures sur un Gantt time-scaled) — pas temps-réel comme Dispatching Dashboard qui tracke l'exécution in-progress. Layers adjacents dans la Scheduler suite.
- IBM Docs — Dispatching assignment : Mid-shift reassignment
- Maximo Secrets — Scheduler : Real-time dispatching
Correct: D
Why D — Le critère d'assignation principal du Dispatching Dashboard est le qualification match entre labor (craft + skill level détenu) et WO (craft + skill required). Un technicien sans la bonne qualification ne peut pas être assigné — Maximo bloque ou flag l'assignment. Autres critères secondaires : availability (shift actif), proximité géographique, labor rate, priority inversée (pas plusieurs high-priority au même tech).
Why A wrong — D3 wrong scope : cost minimization est un objectif Optimizer (Minimum Travel, etc.), pas Dispatching.
Why B wrong — D8 imprecise : maximiser le nombre de WOs closés n'est pas l'objectif Dispatching.
Why C wrong — D4 adjacent : inventory balancing est géré par Inventory / Storerooms, pas Dispatching.
- IBM Docs — Dispatching criteria : Qualification matching
- IBM Docs — Qualifications : Craft + skill
Correct: A, C
Why A, C — Les deux dashboards ont des rôles complémentaires : Scheduling Dashboard = planning-side aggregator (utilization, leveling, scheduling issues au niveau planner), Dispatching Dashboard = execution-side Gantt (assignments live, assignment issues au niveau dispatcher). La distinction horloge : Scheduling regarde vers le futur (prochaine semaine), Dispatching regarde maintenant (aujourd'hui, cette heure).
Why B wrong — D5 inverted : les rôles sont flipped — Scheduling n'est pas un Gantt.
Why D wrong — D8 verbe imprécis : « naming difference » sous-estime — les 2 apps diffèrent fondamentalement par contenu, data sources, use cases et workflows. Ce n'est pas juste une question de label, c'est une distinction architecturale réelle.
Why E wrong — D6 cardinality : les deux dashboards n'ont PAS 3 panels identiques ; leurs panneaux diffèrent par purpose.
- IBM Docs — Scheduler dashboards : Planning vs execution
- Maximo Secrets — Scheduler : Dashboard comparison
Correct: D
Why D — Failure Class est un attribut de reliability reporting (catégorise les failures d'un asset pour RCA), PAS un attribut de scheduling. Les Scheduling Issues détectées par le dashboard portent sur des problèmes temporels/resources : dates manquantes (target/scheduled), durations invalides, over-allocated resources, conflicts de calendar, absences non prévues. Le Failure Class intervient bien APRÈS le scheduling, au moment du WO completion/reporting.
Why A wrong — D9 near-synonym : Missing target dates est une issue scheduling réelle rapportée dans le Scheduling Issues Dashboard — distracteur "vrai ailleurs" qui n'est simplement pas ce que demande la question spécifique.
Why B wrong — D9 near-synonym : Missing durations est aussi une issue scheduling réelle rapportée (WO sans estimated duration empêche placement Gantt) — vrai mais pas la réponse de la question.
Why C wrong — D9 near-synonym : Over-allocated resources est une issue scheduling réelle (labor booked > capacity) — vrai, listée comme scheduling issue standard, mais pas la réponse attendue.
- IBM Docs — Scheduling issues : Issue categories
- IBM Docs — Failure Class : Reliability attribute
Correct: D
Why D — Sur un highlighted assignment issue du Dispatching Dashboard, le dispatcher peut réassigner la task à un autre technicien qualifié directement depuis le dashboard (drag-drop ou dialog). C'est l'action la plus fréquente pour résoudre : absence imprévue, conflit, qualification missing. Maximo re-filtre les candidats selon qualifications/availability/proximité et applique le re-assignment en transaction atomique.
Why A wrong — D7 non-existent : « Rebuild Assignment Cache » n'est pas une action Dispatching Dashboard.
Why B wrong — D4 adjacent : Job Plan revisions se font dans Job Plans app, pas Dispatching.
Why C wrong — D3 wrong scope : financial reports relèvent de Cost Management / BIRT.
- IBM Docs — Dispatching actions : Reassign action
- IBM Docs — Dispatching Dashboard : Issue resolution
Create Service Requests
📋 IBM Objectives
- Use of Work View application
- Use Ticket Templates
- Service Request ownership
- Edit a history SR
💡 Key Points
- Work View app = centralized SR triage (queue view)
- Ticket Templates: recurring SRs (AC broken, leaks) → auto-assign by trade
- Ownership: Owner (person) / Owner Group (team)
- Edit History SR = action to modify a closed SR
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: C
Why C — L'application Work View de Maximo Manage fournit une vue unifiée aux agents du service desk : elle combine Service Requests, Incidents, Problems et Work Orders associés dans une queue unique. Les records y sont groupés par Owner / Owner Group, et l'agent peut trier, assigner, changer le statut et même appliquer un Ticket Template sans quitter l'app. Elle a été introduite (et renforcée en v9) pour réduire le context-switching entre les apps Tickets, Service Requests, Incidents et Problems. C'est une role-based app : les queries sauvegardées diffèrent pour les agents de front-line vs les techniciens L2.
Why A wrong — D4 adjacent app : l'application Incidents existe bien et est un des types de tickets, mais elle n'affiche QUE les Incident records (mode ITIL : événement impactant un service). Pas de vue multi-types unifiée.
Why B wrong — D6 wrong cardinality : l'application Service Request liste uniquement les SRs. Elle est le point d'entrée du ticketing user mais pas la vue agrégée pour un agent qui doit trier Incident + Problem + SR en parallèle.
Why D wrong — D2 invented : « Ticket Central » ne correspond à aucune app Maximo livrée. Distracteur fabriqué avec un nom générique qui sonne plausible.
- IBM Docs — Work View application : Agent unified queue
- Maximo Secrets — Service Management application map (Portaluri, 2018) : Full ticketing stack
- Maximo Secrets — Service Requests (Portaluri, 2022) : SR anatomy + relationship Incident/Problem
Correct: D
Why D — Les Ticket Templates pré-remplissent les champs récurrents d'un Service Request : description, classification, reported priority, owner / owner group, internal priority, classification structure, et — cas avancé — une liste d'Activities, chacune référençant potentiellement un Job Plan avec ses tasks. Utiles pour les scenarios répétitifs (« redémarrage imprimante », « mot de passe oublié », « incident AC bureau »). Appliqués via l'action Apply Service Request Template de la SR app. Portaluri (2022) décrit comment les templates accélèrent le service desk tout en garantissant la standardisation des fields requis par l'organisation.
Why A wrong — D2 invented : « SLA Templates » n'existent pas dans Maximo. Les SLAs sont définis un par un dans l'application Service Level Agreements ; aucun mécanisme de templating pour SLAs. Distracteur séduisant pour qui confond SLA et ticket.
Why B wrong — D3 wrong scope : les Automation Scripts automatisent la logique métier (validation, transformation, enrichissement sur launchpoints). Ils peuvent être attachés à un template pour ajouter de la logique conditionnelle, mais c'est le template qui standardise la création — le script est un complément optionnel.
Why C wrong — D4 adjacent app : Workflow Designer route les records entre assignees (via Task nodes vers des Roles) ; il ne crée pas de tickets pré-remplis. Workflow est l'orchestration post-création, pas la standardisation de création.
- IBM Docs — Ticket Templates : Template overview
- Maximo Secrets — Ticket Templates (Portaluri, 2022) : Template anatomy
- Maximo Secrets — Applying Ticket Templates (Portaluri, 2021) : Application action
Correct: D
Why D — Un Service Request dans Maximo Manage expose deux champs d'ownership complémentaires : Owner (une Person individuelle) et Owner Group (un Person Group). L'un ou l'autre peut être renseigné selon la stratégie de triage : Person Group pour répartition team-based (premier disponible prend), Person pour suivi nommé. L'action Take Ownership permet à un membre du Person Group de s'auto-assigner en Owner individuel.
Why A wrong — D2 invented : « Department » n'est pas un field d'ownership ticket dans Maximo.
Why B wrong — D6 cardinality : Person seul est incomplet — Owner Group (Person Group) est aussi supporté pour le triage team-based.
Why C wrong — D3 wrong scope : les Crews sont un artefact des Work Orders (field labor resources), pas de l'ownership ticket.
- IBM Docs — Ticket Ownership : Owner / Owner Group
- Maximo Secrets — Person Groups (Portaluri, 2017) : Usage
Correct: A
Why A — Quand un Ticket Template porteur d'activities est appliqué via l'action Apply Service Request Template, Maximo exécute une cascade déterministe : (1) les fields du Details section du template copient sur le SR ; (2) pour chaque activity du template, un record ACTIVITY est créé (stocké techniquement dans la table WORKORDER avec WORKTYPE = ACTIVITY et une FK vers le SR parent) ; (3) si l'activity référence un Job Plan, celui-ci est appliqué sur l'activity — ce qui matérialise ses tasks, planned labor, planned materials, planned services et planned tools sur l'activity. La hiérarchie finale est SR → Activities → Tasks, visible depuis l'application Activities and Tasks onglet Plans. C'est exactement ce que décrit la documentation IBM et la fonctionnalité « Related WO Activities for Service Requests created by Ticket Templates ».
Why B wrong — D5 inverted : la cascade crée des Activities, pas des Work Orders directs. Techniquement les Activities sont stockées dans la table WORKORDER (source de confusion pour les dev) mais leur CLASS les distingue (ACTIVITY vs WORKORDER). L'abstraction métier reste : un SR peut avoir des Activities enfants ; elles ne sont pas des WOs au sens applicatif.
Why C wrong — D7 non-existent : aucun mécanisme Maximo ne « ignore » silencieusement un Job Plan référencé. Si le Ticket Template activity pointe vers un JP, la cascade l'applique systématiquement. Distracteur construit pour séduire un candidat qui doute de l'enchaînement complet.
Why D wrong — D8 imprecise verb : « applied but no tasks created » est auto-contradictoire. Appliquer un Job Plan sur un record WORKORDER-type matérialise TOUJOURS ses enfants : tasks, planned labor, materials, services, tools. Si le JP porte des tasks, ces tasks apparaîtront sur l'Activity dans le Plans tab. Pas de JP-apply à moitié.
- Maximo Secrets — Ticket Templates (Portaluri, 2022) : Template anatomy + activities cascade
- Maximo Secrets — Applying Ticket Templates (Portaluri, 2021) : Apply action behavior
- IBM Support — Finding related WO activities for SRs created by Ticket templates : WORKORDER table storage
- IBM Docs — Ticket template activities : Structure officielle
Configure Service Level Agreements
📋 IBM Objectives
- Types of SLAs · objects with SLAs · apply to ORG or SITE
- Services and Service Groups · SLA rankings
- Dates and Calendars · apply-to vs Calculation calendars
- Define Commitments · SLAs to Purchase Contracts
- SLA options in Organization application
💡 Apply-to vs Calculation
- Apply-to calendar: when the SLA is active (business hours)
- Calculation calendar: how time is counted (excludes weekends)
- Commitments: Response, Resolution, Delivery, Contact, Other
- Commitment OTHER → action Select/Deselect SLAs ⭐
- Types: Vendor (to), Customer (from), Internal
- SLA Rankings to prioritize when multiple match
💡 Applies To = ASSET
⚠️ IBM Trap
Correct: D
Why D — Les trois SLA types dans Maximo Manage sont Vendor (accord avec un fournisseur externe, ex: uptime datacenter), Customer (accord avec un client externe), Internal (accord entre deux groupes internes, ex: IT ↔ Maintenance). Choix sur le header du SLA record ; oriente la logique de matching et les reports. Distinct des Commitment types (Response, Resolution, Contact, Delivery, Other) qui définissent les engagements chiffrés.
Why A wrong — D4 adjacent : Operational / Strategic / Contractual sont des classifications ITIL adjacentes au service management, pas les SLA types de Maximo.
Why B wrong — D2 invented : « Tier1/2/3 » sont des labels de support, pas des SLA types.
Why C wrong — D9 near-synonym : Response/Resolution/Delivery sont des Commitment types (onglet Commitments), pas des SLA types. Piège fréquent.
- IBM Docs — SLA types : Vendor / Customer / Internal
- Maximo Secrets — Applying SLAs (Portaluri, 2022) : SLA anatomy
Correct: D
Why D — Quand Applies To = ASSET, l'onglet Assets and Locations apparaît sur le SLA pour restreindre son périmètre. On y liste des Asset IDs précis, des Location IDs, ou des Asset Types (catégories via Type domain). Chaque ligne = un scope partiel ; plusieurs lignes = union (OR logique). Permet par exemple un SLA dédié aux assets critiques classés C1 uniquement.
Why A wrong — D9 : Classifications tab apparaît pour les SLAs basés sur CLASSSTRUCTURE (Applies To différent), pas pour ASSET.
Why B wrong — D2 invented : l'application SLA n'a pas d'onglet "Attributes" — les commitments se configurent via l'onglet Commitments et la target dates via Applies To. Nom d'onglet fabriqué par extrapolation Attributes (DBConfig) vs SLA app.
Why C wrong — D4 adjacent : Services and Service Groups tab apparaît pour les service-based SLAs, pas ASSET.
- IBM Docs — SLA Applies To : Scope tabs
- Maximo Secrets — Applying SLAs (Portaluri, 2022) : Applies To scoping
Correct: B
Why B — Quand plusieurs SLAs matchent le même record, Maximo consulte les SLA Rankings définis via l'action Set SLA Rankings de l'app SLA. Le SLA avec le plus haut ranking number (ou le premier dans l'ordre selon la config) wins et s'applique. Ce mécanisme est explicite et déterministe — aucune logique de merge, aucun fallback automatique. Sans Ranking défini, le comportement est non-déterministe.
Why A wrong — D2 invented : la date de création n'est pas le tiebreaker Maximo.
Why C wrong — D5 inverted : les SLAs ne sont jamais mergés ; un seul s'applique à la fois.
Why D wrong — D9 near-synonym : « most specific » est intuitif mais Maximo utilise Rankings explicites, pas un score de spécificité automatique.
- IBM Docs — SLA Rankings : Ranking mechanism
- Maximo Secrets — Applying a Single SLA (Portaluri, 2021) : Conflict resolution
Correct: C
Why C — Un SLA Maximo expose deux calendars distincts configurables séparément : Applies To Calendar (détermine si le SLA match en comparant la Reported Date du record avec les work periods du calendar+shift) et Calculation Calendar (utilisé pour calculer les target dates Response/Resolution/Delivery une fois le SLA appliqué). Optionnellement, First/Second/Third Choice calendars offrent une cascade de fallback pour le calcul.
Why A wrong — D6 cardinalité : un SLA réel a deux calendars distincts configurables (Commitment Calendar pour la countdown SLA, Applies To Calendar pour la time validity) — pas un seul unifié. Distracteur qui sous-compte les slots de config.
Why B wrong — D8 imprecise : les org defaults existent mais peuvent être overridés au niveau SLA individuel.
Why D wrong — D5 inverted : les SLAs utilisent bien des calendars, pas que des date deltas.
- IBM Docs — SLA calendars : Two calendars
- Maximo Secrets — Applying SLAs (Portaluri, 2022) : Calendar precedence
Correct: D
Why D — Les Commitment types documentés sur un SLA sont Response, Resolution, Delivery, Contact, et Other (plus Availability / Capacity / Downtime / Reliability sur objets non-ticket). « Escalation » est une application séparée (Escalations) qui déclenche des actions basées sur des conditions temporelles — complète un SLA mais ne figure PAS dans l'enum Commitment Type.
Why A wrong — D9 near-synonym : Response est bien un commitment type réel dans les SLAs Maximo (Target Response Date, ex: "1er contact agent < 2h") — distracteur "vrai ailleurs" qui n'est simplement pas la bonne réponse ici.
Why B wrong — D9 near-synonym : Resolution est aussi un commitment type SLA valide (Target Resolution Date, ex: "issue résolue < 8h working"). Vrai dans le catalogue SLA, mais pas la réponse attendue par la question.
Why C wrong — Contact est un vrai commitment type (Target Contact Date, applicable aux Tickets).
- IBM Docs — SLA Commitments : 5 commitment types
- Maximo Secrets — SLA Commitments : Commitment enum
Correct: B
Why B — Pour un commitment type OTHER, l'action documentée IBM est Select/Deselect SLAs. Elle évalue manuellement quels SLAs s'appliquent au record cible et les associe. Contrairement à Response/Resolution/Contact qui sont évaluées automatiquement, OTHER nécessite une action explicite — piège classique IBM : « Apply Other SLAs » n'existe pas (D7 trap bien connu dans la banque 84-Q IBM).
Why A wrong — D4 adjacent : Send Email est un side-effect possible, pas le driver d'un commitment OTHER.
Why C wrong — D9 near-synonym : Create Follow-up est une action valide mais elle crée un follow-up record, pas l'évaluation SLA. Confusion possible.
Why D wrong — D3 wrong scope : Change Status modifie le statut du record (Ticket/WO), pas l'évaluation SLA.
- IBM Docs — SLA OTHER commitment : Select/Deselect SLAs action
- Maximo Secrets — Applying SLAs : Action mechanisms
Correct: C
Why C — Le commitment type Contact n'est PAS disponible quand Applies To = WORKORDER. Raison : un Work Order ne possède pas de Target Contact Date (ce champ existe seulement sur les Tickets — SR/Incident/Problem). Exclusion explicitement documentée par IBM : « The Contact commitment type will not show if the Applies to object is WORKORDER ». Les 3 autres commitments (Response, Resolution, Delivery) et Other restent disponibles sur un WORKORDER SLA.
Why A wrong — D9 near-synonym : Response EST bien disponible comme commitment type sur les WORKORDER SLAs (Target Response Date, ex: "technicien accepte WO < 30 min"). Vrai mais pas la réponse attendue — piège "vrai ailleurs".
Why B wrong — D9 near-synonym : Resolution est bien disponible sur WORKORDER SLAs (Target Resolution Date, ex: "WO statut COMP < 24h working"). Commitment réel, mais pas celui demandé ici.
Why D wrong — D9 near-synonym : Delivery est disponible comme commitment sur WORKORDER SLAs dans certains workflows (Target Delivery Date si livrable physique attaché). Vrai mais pas la bonne réponse — distracteur "réel ailleurs".
- IBM Docs — SLA Commitments (WORKORDER exclusion) : Contact exclusion documented
- Maximo Secrets — SLA Commitments : Applies To implications
Correct: D
Why D — Le champ Applies To Calendar de l'application Service Level Agreements détermine si un SLA s'applique à un record cible (Ticket ou WO). Le matching compare la Reported Date du record avec les shifts / work periods définis dans le Calendar + Shift spécifiés. Si la Reported Date tombe en dehors (ex: ticket ouvert un dimanche alors que l'Applies To Calendar ne couvre que lun-ven 8h-17h), le SLA ne match pas et n'est pas appliqué. Trois champs doivent être renseignés ensemble : Organization, Calendar et Shift (IBM Docs). Distinction cruciale avec le Calculation Calendar qui, lui, sert à calculer les target dates (Response, Resolution) une fois le SLA déjà matché et appliqué.
Why A wrong — D3 wrong scope : Person Calendar n'est pas un champ de l'application SLA. Les Person Calendars existent sur Labor / Person pour définir les heures de travail d'un technicien (shifts personnels, jours fériés, vacances). Ils sont consommés par Assignment Manager et PM scheduling, mais ne participent pas au matching d'un SLA.
Why B wrong — D2 invented : « Ticket WO Calendar » n'est pas un champ existant dans Maximo. Les SLAs portent des calendars distincts (Applies To, First Choice, Second Choice, Third Choice, Calculation) mais aucun nommé « Ticket WO Calendar ». Distracteur fabriqué parce que SLA s'applique aux tickets ET aux WOs.
Why C wrong — D9 near-synonym : Calculation Calendar existe bien dans SLA, mais son rôle est le CALCUL des target dates (commitment calculation — Response Date, Resolution Date), pas le matching. Il est utilisé APRÈS que le SLA ait été matché. Très près de la bonne réponse mais taxonomie adjacente — piège IBM classique pour candidats qui confondent les deux calendars.
- IBM Docs — Applying SLAs in different time zones : Applies To Calendar filter role
- Maximo Secrets — Applying Service Level Agreements (Portaluri, 2022) : Calendar precedence order
- Maximo Secrets — Applying a Single SLA (Portaluri, 2021) : Matching vs Calculation calendars
- IBM APAR IZ91282 — SLA server / client time mismatch : Calendar / time zone edge cases
Safety Plans
📋 IBM Objectives
- Create Safety Plans — IBM Note: Safety Plans are at the SITE level (like Tag Outs and Precautions)
- Work Assets — IBM Note: NOT required, can be Assets OR Locations
- Hazards and Precautions · Hazardous materials · Hazard associations
- Lockout/Tagout process
💡 Key IBM facts
- Safety Plans = SITE level ⭐
- Same level: Tag Outs, Precautions
- Work Assets NOT required on Safety Plan ⭐
- Work Assets can be Assets OR Locations
Interactive IBM-style exam questions. Click an option, then "Check my answer". Progress saved locally.
Correct: C
Why C — L'application Hazards est le catalogue maître des dangers dans le module Safety de Maximo Manage v9.0. Chaque enregistrement porte un code Hazard, un type (domaine HAZTYPE — Mechanical, Electrical, Health, Property selon la config standard), le flag Can Have Precautions, et un onglet Hazardous Materials avec notes NFPA (Health/Flammability/Reactivity/Contact sur 0–4). Les Assets, Locations, Precautions et Tag Outs référencent ensuite ce master ; les Safety Plans ne font qu'en assembler des sous-ensembles pour un Job Plan ou un Work Order. Stockage au niveau Organization — donc partagé entre tous les Sites d'une Org (confirmé par Maximo Secrets / Portaluri).
Why A wrong — D2 invented : « Health & Safety Master » n'existe pas dans Maximo. Le module Safety officiel ne comporte que quatre applications : Hazards, Precautions, Lock Out / Tag Out et Safety Plans (IBM Docs Manage 9.0 + « Safety Module Overview » de Portaluri). Distracteur fabriqué pour séduire un candidat qui chercherait un pseudo-module « central » générique.
Why B wrong — D4 adjacent app : Safety Plans appartient bien au même module mais consomme les hazards, elle ne les définit pas. Un Safety Plan regroupe Hazards + Precautions + Hazardous Materials + LOTO pour pousser tout le paquet d'un clic sur un WO ou un Job Plan. Le champ Hazard y est une simple lookup vers le master, pas un champ de saisie.
Why D wrong — D1 legacy : Incidents enregistre des événements post-fait (accident, near-miss, injury, OSHA reporting) — c'est curatif, pas préventif. La confusion vient du fait que dans les déploiements HSE étendus (Oil & Gas 7.6+), Incidents et Hazards coexistent mais aux deux extrêmes du cycle : identification (Hazards) vs enregistrement (Incidents).
- IBM Docs — Hazards application (Maximo Manage CD) : Hazards application
- Maximo Secrets — Hazards, Precautions and Lock Out/Tag Out (Portaluri, 2022) : HAZTYPE domain + Org/Site storage
- Maximo Secrets — Safety Module Overview (Portaluri, 2021) : Four safety apps described
- BPD Zenith — Maximo HSE Overview : Safety module anatomy
Correct: D
Why D — Le Safety Plan est un patron de sécurité pré-assemblé : il regroupe les Hazards applicables, leurs Precautions associées, les Hazardous Materials, et les procédures Lock Out / Tag Out pour un type de travail donné. Quand un Job Plan référence ce Safety Plan, l'application sur un Work Order copie automatiquement ces infos vers la Safety Plan tab du WO (IBM Docs Manage 9.0). Trois modes d'application existent (Maximo Secrets, 2021) : sélection directe dans le champ Safety Plan, héritage depuis un Job Plan associé, ou propagation générique à tous les WOs d'un site. Objectif : éviter que le planificateur ait à re-saisir les mêmes hazards pour chaque WO récurrent.
Why A wrong — D4 adjacent app : le suivi post-incident est géré par l'application Incidents couplée à CAPA / Investigations (analyse de cause racine structurée). Un Safety Plan est préventif (avant le travail), un Incident est curatif (après événement). Piège classique pour le candidat qui confond les deux versants du cycle HSE.
Why C wrong — D2 invented : le manifest d'expédition HAZMAT est un artefact de la chaîne Shipping / Receiving, généré à partir des contrats de transport et des dangerous goods codes UN. Il n'a rien à voir avec le module Safety de Maximo ; aucun Safety Plan ne produit de manifest réglementaire.
Why B wrong — D3 wrong scope : le Classification Dictionary est une taxonomie générique Asset/Item (attributs, valeurs, hiérarchie) applicable à n'importe quel objet Maximo. Un Safety Plan n'utilise pas les classifications pour son fonctionnement ; il référence directement les records Hazard, Precaution, LOTO et Hazmat par leur clé.
- IBM Docs — Safety Plans application (Maximo Manage CD) : Safety Plans
- Maximo Secrets — Applying Safety Plans (Portaluri, 2021) : Three application modes + Job Plan inheritance
- IBM Maximo EAM SaaS — Safety Plans application : Data grouped by Safety Plans
Correct: A
Why A — La procédure officielle IBM (Maximo Manage CD — « Associating precautions with hazards ») impose deux pré-requis : créer le Hazard avec le flag Can Have Precautions coché, puis créer les Precautions séparément. Sur l'onglet Precautions du Hazard, on ajoute N rows pour lier plusieurs Precautions à un même Hazard. Quand ce Hazard est attaché à un WO ou un Job Plan (directement ou via Safety Plan), les Precautions associées suivent automatiquement et apparaissent sur la Safety Plan tab du WO. Ce pattern 1-Hazard-vers-N-Precautions est le cœur du modèle relationnel Safety de Maximo.
Why B wrong — D5 inverted : Precautions et Hazards coexistent — Precautions ne remplacent jamais les Hazards. Le modèle est additif, pas substitutif. Sur un WO, le Hazard décrit le danger (ex: « tension résiduelle condensateur ») et la Precaution décrit la contre-mesure (ex: « port d'EPI isolant classe 00 + décharge avec perche de mise à la terre »).
Why C wrong — D1 legacy : aucun mécanisme dans Maximo v9 ne fait hériter automatiquement les Precautions depuis la Failure Class de l'Asset. La Failure Class sert à coder les modes de défaillance (pour RCA / failure reporting), pas à piloter les mesures de sécurité préventives. C'est un faux-ami — deux taxonomies parallèles sans lien direct.
Why D wrong — D3 wrong scope : Precautions sont effectivement stockées au niveau Site (confirmé Portaluri 2022), donc la première partie de l'option est exacte. Mais « cannot be shared » est faux : la Precaution est réutilisable par n'importe quel Hazard, sur n'importe quel WO du Site, et le pattern Precaution réutilisable (PPE standard, verrouillage, permis) est explicitement encouragé par IBM. C'est la seconde clause qui rend l'option entière fausse.
- IBM Docs — Associating precautions with hazards : Procédure officielle (Can Have Precautions flag)
- Maximo Secrets — Hazards, Precautions and Lock Out/Tag Out : Storage Org (Hazards) vs Site (Precautions)
- Softacus — IBM Maximo Health, Safety and Environment Manager : Relation 1:N Hazard → Precautions
Correct: B
Why B — Sur la Safety Plan tab du Work Order, Maximo expose la liste des Hazards, Precautions, Hazmats et Tag Outs copiés depuis le Safety Plan. La case d'acquittement « Has the Safety Plan been reviewed? » est le mécanisme déclaratif du technicien pour marquer qu'il a lu le plan avant d'exécuter la tâche. Par défaut, Manage ne bloque pas le changement de statut sur cette case (elle est informative + audit-trail), mais elle reste exigée par la plupart des politiques HSE et peut être rendue bloquante via un workflow ou une escalation custom. NB : Maximo Secrets (Portaluri) documente surtout la restriction de modification au statut WAPPR, l'existence précise du flag « reviewed » dépend du fix pack et peut nécessiter vérification sur l'environnement cible.
Why A wrong — D1 legacy : le statut HAZACK est un custom status que certains déploiements on-prem Maximo 7.x ont ajouté via le WOSTATUS synonym-domain. MAS Manage v9 ne livre pas de statut dédié à l'acquittement hazard dans son workflow standard — ce rôle revient à la case sur la Safety Plan tab. Ajouter HAZACK resterait possible en customisation, mais hors configuration out-of-the-box.
Why D wrong — D7 non-existent : aucun mécanisme d'email-clearance n'est natif dans Manage. Les notifications email existent (communication templates, escalations, workflow), mais aucune n'implémente un « go / no-go » hazard. La sécurité repose sur la case d'acquittement, éventuellement couplée à un workflow.
Why C wrong — D2 invented : « SMS Compliance module » n'existe pas dans Manage. Le candidat peut être tenté parce que « SMS » sonne comme un acronyme Maximo plausible (Safety Management System), mais aucun module porte ce nom et aucune auto-tick-on-plan-start n'est documentée. Distracteur fabriqué de toutes pièces.
- IBM Docs — Work Order Tracking Safety Plan tab : Safety Plan tab content
- Maximo Secrets — Applying Safety Plans (Portaluri, 2021) : Three subtabs + WAPPR edit rule
- IBM Support — Display Tag Out and Hazard Info on PM WO : Hazard/Tag Out flow to WO
Correct: B
Why B — Le record Hazard de Maximo expose trois Available Associations : Precautions, Hazardous Materials, Tag Out. Ces trois ne sont pas combinables librement — Tag Out est mutuellement exclusive avec Precautions et Hazardous Materials (confirmé par Portaluri 2022 : « Tag Out Association prevents precaution or hazardous material linkage »). Dès qu'au moins une Precaution est enregistrée sur le Hazard (row saved dans l'onglet Precautions), l'onglet Tag Out bascule en read-only et empêche toute nouvelle association. La logique inverse s'applique : un Hazard avec Tag Out déjà lié voit ses onglets Precautions et Hazardous Materials devenir read-only. Cette contrainte traduit le modèle HSE : Tag Out = isolation physique totale, incompatible sémantiquement avec precautions opératoires ou handling HAZMAT qui supposent une interaction active avec l'asset.
Why A wrong — D7 non-existent : « Qualifications » n'est pas une Available Association du Hazard record. C'est une application séparée attachée aux Labor / Person (certifications, permis de conduire, habilitations électriques). Confusion possible car les qualifications conditionnent souvent qui peut intervenir sur un hazard donné, mais elles n'apparaissent pas comme tab du Hazard.
Why C wrong — D3 wrong scope : Hazardous Materials COEXISTE avec Precautions sur un Hazard. Les deux tabs restent éditables en parallèle — un Hazard chimique peut légitimement avoir des Precautions (port d'EPI) ET des Hazardous Materials (notes NFPA Health/Flammability/Reactivity). Seul Tag Out est bloqué par la présence de Precautions ou HAZMAT.
Why D wrong — D2 invented : « Risk Assessment » n'est pas une Available Association du Hazard record dans Maximo out-of-the-box. C'est une discipline métier (ISO 31000, FMEA) que certains déploiements implémentent via Classifications ou custom apps, mais il n'existe pas d'onglet natif Risk Assessment sur Hazards. Distracteur fabriqué parce que « risk » et « hazard » sont quasi-synonymes en langage courant.
- Maximo Secrets — Hazards, Precautions and Lock Out/Tag Out (Portaluri, 2022) : Mutual exclusivity Tag Out / Precautions
- IBM Docs — Hazards application : Available Associations
- IBM Docs — Associating precautions with hazards : Can Have Precautions prerequisite
Apply Safety Plans
📋 IBM Objectives
- Where Safety Plans can be applied
- Associate Safety information with Asset
- Remove work plan from a Work Order
💡 Key Points
- Applied to: WO (via job plan or manually) and Asset
- Remove Work Plan on a WO = dedicated action (does not remove the Safety Plan, only the work components)
- Safety info can be associated directly to an Asset for auto-propagation to all its WOs
Correct: A, B
Why A, B — La documentation IBM Maximo Manage définit explicitement la procédure LOTO comme un Tag Out (« how to take work assets out of service and place them back in service ») constitué d'une séquence de lock out operations. Le Tag Out identifie ce qui est isolé (Asset OU Location — champs mutuellement exclusifs per Maximo Secrets) et décrit les étapes ; chaque Lock Out trace un cadenas physique appliqué à une source d'énergie (électrique, hydraulique, pneumatique…). Le Type d'un Tag Out peut être Electrical, Mechanical, Alarm Override ou Process. Stockage au niveau Site. Une fois le LOTO créé, il est référencé depuis un Hazard, puis propagé aux Work Orders via le Safety Plan.
Why C wrong — D2 invented : « LOTO Incident Form » n'est pas un record de Manage core. Les incidents LOTO (cadenas forcé, oubli de remise en service) sont tracés dans l'application Incidents générale ou via un Investigation record ; aucune entité dédiée « LOTO Incident Form » n'existe dans le schéma Safety v9.
Why D wrong — D4 adjacent app : Hazmat Route Card relève du module Shipping / Transportation (Dangerous Goods Manifest), pas de LOTO. La confusion possible vient de la co-présence HAZMAT + LOTO dans les déploiements Oil & Gas, mais les route cards sont des artefacts de logistique de matières dangereuses, pas d'isolation d'énergie.
Why E wrong — D1 legacy : le décommissionnement d'asset (changement de statut vers DECOMMISSIONED) relève du lifecycle IBM ISO 55000 / retirement phase. LOTO adresse une isolation temporaire pour travaux ; le décommission est permanent. Ces deux concepts touchent l'asset mais à des niveaux orthogonaux — piège pour le candidat qui mélange « mise hors service » au sens sécurité et au sens lifecycle.
- IBM Docs — Lock Out / Tag Out application : Tag out procedures + lock out operations
- Maximo Secrets — Lock Out / Tag Out (Portaluri, 2021) : Type values (Electrical/Mechanical/Alarm/Process) + Asset|Location mutual exclusivity
- Interloc — Managing Isolations in Maximo Oil & Gas : LOTO vs Permit To Work distinction
- Maximo Secrets — HSE Application Maps (2018) : Data model Safety module
Correct: A
Why A — L'application Work Permit (Permit to Work / PTW) gère l'émission, l'approbation et la traçabilité des autorisations formelles requises pour les tâches à risque : hot work (soudage, découpe), confined space (espace confiné), electrical work (HT/BT), chemical handling, excavation, working at heights. Chaque permit porte un type, une fenêtre de validité (start / end), un issuer, un list de travailleurs autorisés, les hazards associés et un statut (Draft → Active → Closed). Originalement livré dans Maximo for Oil & Gas 7.5, l'app a été intégrée au produit Manage v9.0 et peut bloquer la transition APPR d'un WO si le permit lié n'est pas actif, via un workflow ou une validation. Référence : IBM APAR IJ22577 documente même que Manage n'accepte la création de PTW qu'aux statuts d'approbation équivalents (APPR, WSCH, WMATL).
Why B wrong — D4 adjacent app : les droits d'issue dans un Storeroom sont contrôlés via les Security Groups + Site authorization + le champ Default Storeroom sur le Labor/Person, pas via un Work Permit. La confusion vient du fait que « permit » en anglais peut évoquer une autorisation générique, mais Maximo réserve ce terme aux permits de sécurité, pas aux permissions d'inventaire.
Why C wrong — D2 invented : les documents « Installation Qualification » (IQ, OQ, PQ) viennent de l'univers réglementaire pharma / medical device (GxP, FDA CFR 21 Part 11). Ils ne sont pas des artefacts natifs de Maximo Manage ; un déploiement pharma pourrait les stocker dans Doclinks mais aucune application ne les génère out-of-the-box.
Why D wrong — D1 legacy : le sign-off d'un changement de fréquence PM relève du PM record approval + workflow + éventuellement un Change Management process. Aucun lien fonctionnel avec Work Permit ; le WO généré par le PM peut requérir un permit, mais le permit ne sert pas à approuver le PM lui-même.
- IBM APAR IJ22577 — PTW creation at APPR/WSCH/WMATL : APAR référence
- IBM Docs — Work Permits in Maximo Oil & Gas add-on : Work Permit application topic
- IntelliPermit — LOTO & Permit To Work unified approach : Types de permits (hot work, confined space, electrical, chemical)
- LinkedIn — PTW and LOTO (Meneses Freites) : Définition PTW
Correct: A, B, C
Why A, B, C — Le champ Hazard Type d'un Hazard record est piloté par le domaine synonymes HAZTYPE, configurable par le client via Domains. Out-of-the-box, Maximo Manage livre des valeurs techniques (Mechanical, Electrical, Health, Property — voir Portaluri 2022), mais la majorité des déploiements HSE industriels étendent ce domaine selon le standard Industrial Hygiene / OSHA : Physical (mécanique, électrique, thermique, vibration, bruit), Chemical (substances HAZMAT, gaz, fumées), Biological (pathogènes, bactéries, virus), avec souvent en ajout Ergonomic et Radiological. Ces trois catégories (Physical, Chemical, Biological) constituent la trilogie de base reconnue universellement par les safety managers ; ce sont les « standard hazard types » dans la littérature HSE, référencés par Safety Plans et Incident records. Attention verif user : la formulation exacte des valeurs dépend du HAZTYPE du tenant — à confirmer sur l'environnement cible.
Why D wrong — D4 adjacent app : Financial Risk relève du domaine ERM (Enterprise Risk Management) — SAP GRC, IBM OpenPages, RSA Archer. Aucun workflow Maximo Safety ne le référence. Pour un auditeur qui vient du monde ERP, la tentation est de mettre « tout risque » sous le même chapeau, mais le module Safety de Maximo se limite aux dangers opérationnels pour personnes et biens.
Why E wrong — D2 invented : « Reputational » n'a aucun record dans Safety domain. Le risque réputationnel est purement ERM / Communication, il ne génère ni Precaution, ni LOTO, ni permis. Distracteur construit pour séduire un candidat qui assimile « Hazard » au sens générique du mot anglais (toute menace) plutôt qu'au sens technique Maximo.
Why F wrong — D1 legacy : Schedule Risk est un concept de Project Management (PMBOK, critical path), adressé dans les outils Portfolio (Primavera, MS Project) ou via l'application Scheduler de Maximo (conflits de ressources, glissements). Il ne fait pas partie du module Safety et n'a pas d'entrée dans HAZTYPE.
- Maximo Secrets — Hazards, Precautions and Lock Out/Tag Out (Portaluri, 2022) : HAZTYPE default values (Mechanical/Electrical/Health/Property)
- OSHA — Hazard Classification Guidance : OSHA 3844 (17 physical + 10 health hazards)
- NASP Web — Types of Workplace Hazards : Industrial Hygiene taxonomy (Physical/Chemical/Biological/Ergonomic)
- IBM Docs — Hazards application (Maximo Manage CD) : Hazard Type field + HAZTYPE domain
Correct: C
Why C — L'enforcement d'un Work Permit avant approbation de WO est déclaratif via le moteur Workflow / Escalation de Maximo Manage. En pratique, on crée un Workflow Process sur l'objet WORKORDER (ou une Escalation sur WORKPERMIT.STATUS) qui, avant le node Task d'approbation, évalue via une Condition si le permit lié est ACTIVE + APPROVED + dans sa fenêtre de validité. Si non, le workflow route vers une Negative branch (rejet + message). Cette approche repose sur les MBOs Maximo (WORKORDER, WORKPERMIT, PMWORKPERMIT) et non sur du SQL trigger-level — c'est l'architecture historique Maximo depuis la 7.x, conservée en v9. L'APAR IBM IJ22577 confirme même que par défaut, la création de PTW est liée aux statuts d'approbation équivalents (APPR, WSCH, WMATL).
Why A wrong — D1 legacy : Maximo n'utilise pas de trigger PL/SQL / DB2 pour la validation métier. Toute la logique passe par la couche MBO / Business Rules / Automation Scripts / Workflow — respectée aussi bien par l'UI que par les intégrations MIF. Un DB trigger bypasserait la couche audit + RLS par tenant et n'est explicitement pas recommandé par IBM (« DB triggers are not supported for business validation »).
Why B wrong — D2 invented : aucune auto-création de permit au moment de l'approbation WO n'existe dans v9. Le flow correct est inverse — le planificateur (ou le demandeur) crée le permit avant l'approbation du WO, puis le WO vérifie son existence lors de la transition APPR. Un permit est un acte administratif formel avec issuer nommé ; il ne peut pas être généré par défaut sans violer le process HSE.
Why D wrong — D5 inverted : la baseline sans workflow ou escalation active est effectivement advisory (le permit apparaît dans la liste mais ne bloque rien). Mais la question porte sur l'enforcement actif par défaut — et c'est précisément le rôle du workflow OOTB livré avec le module Safety / Oil & Gas. L'option inverse la direction : elle nie l'enforcement, alors qu'il est le comportement attendu après activation du process fourni.
- IBM APAR IJ22577 — Permit creation constraint (APPR/WSCH/WMATL) : APAR référence
- IBM Docs — Workflow in Maximo Manage : Workflow processes + condition nodes
- GitHub ibm-maximo-dev — makeWorkFlow scripting sample : AS02 workflow automation sample
- MaximoMastery — Work Order Status transitions : Workflow-driven status changes
Next step: take the official IBM Assessment Test ($30). If score >75%, book the real exam on Pearson VUE ($200).