Maximo Configuration
Meet the requirement without leaving anything behind to maintain.
Most requests priced as development are configuration once the rule underneath them is written down. We work the configuration surfaces in order, build the answer where IBM Maximo already supports it, and write code where a requirement genuinely needs it. The difference shows at the next upgrade and at every support handover in between.
The situation in the programme
Why the configuration question turns up late
Three patterns we are most often called into, described by the people who inherited them.
The request arrives already shaped as an answer
Add a field, change a button, make it behave like the system it replaced. The rule underneath, who decides what and when, is rarely written down.
Code was quicker on the day
Under a deadline, writing something bespoke beats working out which configuration surface owns the behaviour. Each decision was defensible alone. The tenth one, five years later, sets the upgrade bill.
Every upgrade pays for it again
Configuration is carried forward on the supported path. Written code is revalidated, retested and sometimes rebuilt at every upgrade, for as long as it exists.
A requirement met with code that configuration would have carried is paid for twice: once to build it, then again at every upgrade and every support handover.
Two routes to the same behaviour
What configuration carries, and what customisation commits you to
Configuration
Behaviour shaped through the tools Maximo provides for it: security groups and signature options, workflow, escalations, conditional expressions, domains, application layout, start centres, KPIs and reporting.
Customisation
Behaviour that had to be written: an automation script, or on an older estate a Java extension. Sometimes the right answer, and always an asset somebody owns.
Where the behaviour lives
In the application, visible to an administrator who can see what it does and which records it applies to.
In a script or a class, visible to whoever can read it and knows where to look.
Who changes it in two years
A trained functional administrator, working in the same tools it was built with.
A developer, who first has to establish what the code was for.
At the next upgrade
Carried forward on the supported path and tested in the normal regression pass.
Revalidated, retested and occasionally rebuilt, every time.
At a support handover
The configuration is the documentation, and it can be walked through in the application.
The code is the documentation, unless the intent was written down separately.
The procedure
How a requirement is met, in five stages
Most arguments about configuration against customisation are arguments about stage one having been skipped.
- 01
Write the rule
The request becomes a rule with a scope: the decision it supports, the role that owns that decision, the records or asset classes it applies to, and what happens when the rule is not met.
Owner MaxIron functional lead with your process owner Typically 1 to 3 days per requirement group
- 02
Locate the surface
We work the configuration surfaces in the order below and name the one that already owns the behaviour. Where none does, we say so at this point rather than at build.
Owner MaxIron functional lead Typically half a day
- 03
Build it in a lower environment
Configured against representative data, including the awkward cases: the authorised person on leave, the out of hours job, the record that arrives from an integration rather than from a person.
Owner MaxIron configuration analyst Typically 2 to 10 days
- 04
Prove it with the people who asked
They walk their own work through it before promotion. This is where a rule that sounded complete in a workshop turns out to need a deputy, a second branch or a different scope.
Owner Your process owner and named users Typically one session per rule
- 05
Record it and promote it
Requirement, rule and the configuration that carries it are recorded together, then promoted through the same controlled route as any other change, with Change Control holding the production gate.
Owner Your change manager Typically one release window
The arithmetic
Testing costs the same on either route. Configuration-first changes the size of the estate you are still carrying in three years.
Workshops, testing, data quality, training and change governance cost what they cost on both routes, and they earn their place in the plan. What stops accumulating is revalidating bespoke code at every upgrade, reverse engineering a behaviour nobody can explain before daring to change it, and developer time spent on rules a functional administrator could own.
The configuration surfaces
The surfaces we work through, in this order
Named so a technical reader can check the route before we take it. Requirements are tested against each in turn, and the first surface that owns the behaviour carries it.
Security groups, signature options and conditional access
Workflow, escalations and communication templates
Conditional expressions, domains and classifications
Application layout, start centres, KPIs and reporting
Boundaries
Three boundaries on a configuration uplift
Each is worth settling before delivery rather than halfway through it.
An unresolved process decision comes back to you as a decision
Configuration enforces a rule precisely once the rule exists. Where two departments want different rules for the same record, we hand it back for a decision rather than building both versions and leaving the estate to carry the disagreement. That belongs in business process optimisation before it belongs in a delivery backlog.
Some requirements are genuinely code, and we name which
A value derived from several records under conditions that change by asset class is a script. We write it, review it and put a named owner against it rather than assembling it from six conditional expressions that only make sense together. Anything that has to reach another system belongs in the integration framework, under Maximo integrations.
Existing customisation is assessed as separate scope
Defaulting to configuration protects the estate from here on. Code already in place is assessed item by item under customisation modernisation, which carries its own budget and timeline.
Where this sits
Configuration runs the length of the programme
- Service IBM Maximo implementation
Configuration decides how much of a first implementation is left behind as something to maintain.
- Service Maximo to MAS upgrade
The upgrade bill is set by how much has to be revalidated, more than by the version gap crossed.
- Service Customisation modernisation
Reviews the scripts and Java already in place and moves back what should have been configuration.
- Case study Standards held inside Maximo
An ISO 14224 taxonomy, API RP 14C safety-critical flagging and a corrective action workflow, all built as configuration.
Maximo configuration, frequently asked questions
- What does configuration cover in IBM Maximo?
- Applications, security groups and signature options, domains, workflow, escalations, communication templates, KPIs, start centres, conditional expressions, classifications, item assemblies, scheduling and reporting. On a properly configured estate this route carries the large majority of requirements.
- How do you decide whether a requirement is configuration or customisation?
- From the decision the requirement supports, not from the screen the requester was looking at. Once the rule has a scope, a role and a record type attached, we work the configuration surfaces in order. If the requirement is met on that route it is configuration and it is recorded as configuration. If it is not, we name what has to be written and get that decision made by someone accountable for supporting it later.
- What does a configuration uplift on an existing estate involve?
- An audit first: what has been configured, what has drifted between environments, what has been solved twice in two places, and what capability the estate owns but does not use. Then a prioritised backlog with the requirement each item serves written beside it, delivered through the same controlled promotion route as any other change.
- Is Application Designer still the right tool for screen work?
- Yes. Application Designer has been part of Maximo since Maximo 6 and configures screens for both the Classic and the Graphite UI. Work done there is supported, visible in the application, and carried forward on the supported upgrade path.
Bring the three requirements you have been quoted development for.
Send three backlog items that carry a development estimate. We work each one back to the rule underneath it and name the configuration surface that carries it, the one that genuinely needs a script, and the one that is a decision your business has not taken yet.
Bring this to the first call
- Three backlog items that have been priced as development work
- The role that is meant to own each rule
- Your last upgrade or release regression pack, if one exists
- A count of the automation scripts and custom classes live in production today