The golden rule I have employed on all my Maximo implementations is that we intend to use Maximo as it is: ‘out of the box’. Therefore, configuration is OK, but we should avoid Maximo customization.
As I soon approach my 30th year of Maximo implementations, I have realized that my golden rule still holds true, but nearly every Maximo system I know of has a customization of some description.
I attended a user group in Canada last year (CanMUG) and every user who presented their system implementation stated the golden rule – customization is a cuss word – and then went on to describe the one or two things where they had to customize Maximo in order to deliver their business process!

I wonder, is customization really that bad?

My initial concern was, and is, the ongoing maintenance of the code that has been built. The average IT department typically do not have Java developers or Report developers on hand to fix or maintain the customization. So, tying your organization to a system that needs this skillset sounds expensive? Or, what if you decide you are not going to maintain your Maximo system and put it in the cloud, how could the Maximo cloud provider undertake to warrant those customizations? So, on the face of it the golden rule still feels pretty healthy.
When the above is explained to the client during the Design Phase, they totally agree with the above sentiment, and yet the customizations still occur. Given that Maximo generally solves 80% of your maintenance problem out of the box and has configuration tools for the other 15-19%, why can’t we settle for vanilla Maximo with 1% deficiency of functionality and change our business process? Is this tiny percentage really that important to our business? The Maximo world has obviously said “yes, it is”! They want their process and Maximo, with its flexible toolset, can give it to them.
Is it a leap of faith to argue, then, that because it has this flexibility, and you can never paint yourself into a corner with the tool, it is the world’s leading EAM according to Independent Analysts? Whilst I think there are many reasons why Maximo is the leading toolset in this marketplace, the customization ability must be up there as one of the significant reasons it stays ahead of the pack.
Its evolution has been driven by its user base; they have said where the product needs to be changed and rather than sit and wait for the author to build it for them, they have built their own relatively cost-effective system until such a time that core functionality is available to be used.
Many companies, who do not have this flexibility in their chosen “none Maximo” EAM systems, compromise their process and work around functionality deficiencies with a view to one day getting their product right – by which time the world changes and they fall even further behind. I have replaced many systems that had reached their limits with Maximo in my time, so this seems to be the case.
IBM will tell you how valuable it is to have those customizations explained so that they can build a more functional standard product. Think how much easier it is to see something working rather than trying to explain a function. So, the contra argument to the golden rule, in my opinion, also has some merit.
If you do choose to customize, what is best? In my experience, Report customization is OK. No one can pre-package every piece of data and report on it, so giving the ability to change the reports must be acceptable (although I know this causes a lot of companies a headache). All the systems have their own flavour of reporting and getting an in-house team with the skillset to maintain reports in any reporting package, as well as keeping up with the business demand for new information, is an issue. Choosing the right Business Intelligence tool for the business for all systems is a big help. However, many of the essential reports such as Work Order Print and PO Print (which most companies change) use native Maximo BIRT reporting. Therefore, they still need someone to maintain them, so BIRT is a key skillset companies need to invest in.
Functionality customization can be delivered in two ways: Automation Scripting or Java extensions. Both will achieve the same goal, and both require a knowledge of Java. Java extensions have no limits to what they can change and the toolsets for development have better debugging tools. Automation Scripting will upgrade automatically and can be deployed without outage of the system. Both methods require testing once upgraded because neither guarantee that they are future proof and will work with new releases of Maximo.
IBM typically promotes Automation Scripting over Java extensions. The technicians I work with, who can do both, would always go with Java extensions. The limitation of the Automation Scripting is one factor, but the poor debugging tools is the key factor in their choice.  The analogy they give is that it is like painting a fence with your eyes closed. You know you are painting but there is no real way of knowing if the fence is fully painted!
In conclusion, if you are going to customize in this way, you will need to have a Java skillset in your maintenance team. The choice of whether you customize with Automation Script or Java extension is a business choice as it would appear to be the same headache either way.
I hope I have left in you no doubt that customization, except for report changes or additions, should be carefully considered. The golden rule still holds firm. Don’t do it if you don’t have to, but if you do, make sure you can support it for the years to come.

Come with BPD Zenith to the future of Asset Management

Listen to your assets!

Most companies are aware of waste in their preventative maintenance efforts, but aren’t quite sure how to eliminate it.