Maximo Customisation: Remove, Consolidate, Simplify

Why customisation?

IBM Maximo is a leading enterprise asset management (EAM) solution used by organisations across a wide range of industries. It is a comprehensive and feature-rich application, but it rarely meets all the specific needs of a customer out of the box. There are always unique business rules and automation that each customer wants to implement. These requirements can be addressed using many different Maximo features, including:

System/Organisation/Site settings
Domains
Formulas
Workflow Designer
Application Designer
Security Restrictions
Conditional Expressions
Integration Framework
Database Configurations
Java Extensions
Automation Scripts

Implementing specific business logic using any of the above can be considered customisation. However, writing business logic by extending Java code is complex and time-consuming. This slows down an organisation’s ability to adapt and implement new changes quickly.

Comparing the levels of complexity and deployment time & effort of various Maximo customisation features

In the past, before Maximo version 7.5, most customised logic was implemented by extending standard Java classes. This was often referred to as “customisation”, as opposed to logic implemented using other methods available via the Maximo front-end – such as cross-over domains, Database Configuration, or Application Designer – which were often called “configuration.”

Java Customisation vs. Automation Script

Java customisation isn’t inherently bad. For extremely large Maximo systems with complex business processes, if the company has a dedicated team of experienced Java developers, customising by extending Java code can be the right choice.

From version 7.5 onwards, Maximo introduced Automation Scripts, which have since matured into a powerful alternative. Custom logic can now be implemented directly from the Maximo front-end using the Automation Scripts application. These scripts can be written in JavaScript or Python—both of which are far simpler and easier to read and maintain than Java. Changes to scripts can be made live and take effect immediately, with no disruption to users. Simple changes can be implemented by Maximo Administrators or Business Analysts.

In contrast, Java customisation typically requires experienced developers and often a full development and deployment process.

Over the last 7–8 years, with only one exception, I haven’t had to write a new custom Java class for any customer. All requirements were implemented using configuration tools, including Automation Scripts. The one exception was due to the customer still using an older version of Maximo.

Problems with Customisation

When properly implemented and well maintained, customisation can automate repetitive tasks and streamline business processes. However, over time and under constant change, a system can become overly complex for several reasons, such as:

Poor customisation due to unclear requirements or inexperienced implementers
Obsolete logic due to organisational changes (e.g. business consolidation, spin-offs)
Overlapping or redundant logic due to staff turnover

An over-customised system often exhibits the following symptoms:

Every project or task feels like it takes too much time and effort while delivering minimal results
A new requirement or issue takes excessive time to analyse / troubleshoot
A seemingly simple change takes weeks or months to implement, or isn’t implemented at all
Changes deployed to production frequently break other functionality, requiring further fixes

Decustomising Maximo

Decustomising Maximo isn’t just about porting Java code to Automation Scripts – although that may be a major part. It’s about refactoring, consolidation, and rewriting logic in the simplest, most elegant way possible.

The goals are to:

Keep the system simple and easy to maintain
Enable continuous improvement with DevOps
Improve performance
Reduce the cost of future work (e.g. upgrades to MAS)

A decustomisation effort may include:

Removing unused or ineffective configurations
Replacing legacy customisations with out-of-the-box functionality
Consolidating overlapping logic
Removing unreachable logic branches (due to organisational or process changes)
Porting Java code to Automation Scripts and other configuration tools

Relia’s Decustomisation Service

The key to effective decustomisation is understanding business requirements and translating them into simple, maintainable technical solutions. This requires a consultant who is technically strong and understands how the business operates.

I have extensive experience helping both large and small organisations remove or simplify their Maximo customisations. This often results in a leaner, more maintainable system that can be supported by the average Maximo consultant.

My approach involves two steps:

1. Preliminary Review

An assessment of the system to identify the level of customisation and opportunities for optimisation. This may include:

Identification and initial assessment of all Java customisations
Assessment of all Automation Scripts
Initial review of key configurations, including security settings, conditional expressions, formulas, cross-over domains, and system/org/site settings
Gaining a high-level understanding of key business processes and workflows

Deliverable: A report outlining all customisations found in the system, with recommendations for change, including priority, impact, and complexity.

2. Decustomisation

Depending on the complexity of the work and the resources available, this can be done in one of two ways:

Single Big-Bang Task: For systems with medium to low complexity, the work can be delivered as a single task over a few weeks.
- Example: For a seaport operator in Sydney, removing 98 Java classes and consolidating 65% of over 60 Automation Scripts took just under 3 weeks.
Phased Approach: For larger, more complex systems, the work may take several months. In this case, we apply the 80/20 rule—focusing on the top 20% of customisations that will yield the most benefit. After each stage, we review the remaining work and plan the next. It’s not always practical or advisable to remove 100% of Java customisations—well-built and stable ones may be left in place.
- Example: For a metro operator in Australia, we conducted a quick review and clean-up of their Maximo system. The goal wasn’t to eliminate 100% of redundancies or overlapping functions, but rather to focus on the low-hanging fruits. In just a few weeks, we managed to remove and consolidate:
  - 50% of Security Groups
  - 50% of Automation Scripts
  - 75% of Person Groups
  - 100% of custom Java classes
- With a much smaller number of automation scripts, the system became much more manageable. This allowed us to dig deeper, simplifying and refactoring complex logic. As a result, not only was the SR-to-WO process streamlined, but we also resolved several long-standing performance issues along the way.