Maximo Dos and Don’ts: Tips to Live By From Two IBM Maximo Pros

IBM Maximo is one of the most powerful (and popular) CMMS solutions out there – and for good reason. It’s a great system. Many of us have built our careers around Maximo; administering it, working with it, and developing the right tools to simplify and enhance it.

And when you’ve worked with Maximo for so many years, you come to learn what works, what doesn’t, and what to think twice about. So, I sat down with Elliot Bonilla and Omar Rivera, two of our foremost Maximo experts, to get their takes on the Dos and Don’ts everyone needs to know about (or be reminded of).

Don’t: Use Out-of-the-Box Maximo Fields For Custom Data

Elliot Bonilla (EB): There are so many reasons not to use out-of-the-box fields for your custom data. That’s why I highly recommend that you create your own user-defined fields. Maximo’s out-of-the-box fields have been designed for a specific purpose – likely not the purpose you’re going to use them for if you’re putting custom data in there. And when how you’re using them versus how Maximo thinks you’re using them is out of sync, that spells trouble.

Omar Rivera (OR): I agree. During upgrades, integrations, or installs, some fields get obsoleted and might disappear. It completely depends on which field you’re using. That’s why you should create your own user-defined fields and use the out-of-the-box fields for their intended purpose.

Do: Make Configurations Stand Out

OR: When making configurations, make them unique and easy to see in comparison to the out-of-the-box fields. For instance, you might add a prefix that represents the company before the field name. So, for example, instead of adding a user-defined field called “MeterLocation”, you would name it “ACME_MeterLocation”. Now you can spot it from a mile away!

It can be whatever you wish, but I suggest that you implement it consistently across Maximo (and that includes all your environments!)

EB: I’ve said it before and I’ll say it again. What you can (and can’t) see quickly, easily, and clearly on screen directly impacts how happy and productive you are at work. So, make it easy on your eyes.

Don’t: Overcomplicate Your GL Accounts

EB: Simplify. It’s our motto and it should be yours too. Whenever a situation has got you bending over backwards or jumping through flaming hoops, stop. Rethink. Question everything. Confront the logic by which the decisions were made. I bet you a nickle and a pickle there’s a simpler way to meet your requirements.

Case in point; I’ve seen clients with far too many General Ledger (GL) accounts.

This happened to me in a past life; there were 100,000,000 possible combinations of GL accounts based on how the math was performed. That being said, in reality, each GL account was a full branch of a scope of work (SOW) document and there were limited items per SOW level to address making it a much smaller number of combinations than what complex math will tell you.

For instance, the first component had only one valid item. The second could have been eight, and so on and so forth. So, at the end, the possible combinations are not truly all of the unique numbers, it’s just how many real branches you can follow for charging purposes. If you’re facing a similar issue, ask yourself: Do you really need every single digit?  

In my example, we only needed the unique combinations that were valid on the SOW, which was narrowed down to less than 125,000 combinations. That’s a significant drop from 100,000,000!

Do: Question Whether or Not You Need Clustering

OR: Couldn’t agree more, Elliot. Question everything – that’s a great best practice. Of course, every business is unique and therefore the needs and requirements will be unique too. But it’s vital to dig deep, ask those tough questions, and think critically about what you think you need versus what you really need.

A common example of this is clustering. IBM defines a cluster as “sets of servers that are managed together and participate in workload management. Clusters enable enterprise applications to scale beyond the amount of throughput capable of being achieved with a single application server. …The servers that are members of a cluster can be on different host machines.”

But let’s say you’re not a giant, international enterprise. Maybe you don’t really need to cluster. I would say, if you have less than 25-50 people seriously consider whether or not you need to cluster. Servers these days are pretty reliable and can likely support an organization of 25 people.

Don’t: Take Backups For Granted – Or Worse, Forget Them Altogether

EB: If you don’t have a backup, what are you doing?! It should go without saying that you should always, always have a running current backup and a backup of the original implementation. (I have horror stories on this, including a site where it took five weeks to restore one database…only for them to discover it wasn’t the database they needed! Why? Because they didn’t have a current backup!)

Here are some tidbits on what to consider:

• What level of backup do you need?
• Database?
• Reports?
• Applications?
• WebSphere configuration?
• Server?
• How long will you keep those backups?
• Will you have backups of backups? (I have three backups of my laptop 😉)
• Do you trust your current backups and backup process? If not, why?

It goes without saying: keep backups of screen designs (original and custom ones), keep all reports outside (original and custom ones), and anything you do at the server level should be backed up somewhere else, other than on the server.

And just in case you ever feel complacent, remember this other horror story: We know an admin who deleted all of the out-of-the-box screens on an implementation. Later, when they tried to go back to add out-of-the-box functionality into the customized screens, there were no examples to go by. They had to request a separate implementation to get the data, just to be able to do what they needed to do.

Do: Update Maximo Frequently

OR: Make life easier on yourself – take advantage of small upgrades. It’s easier to go from 7.6.0.3 to 7.6.0.5 to 7.6.0.7 to 7.6.0.9 than to go from 7.6.0.3 to 7.6.0.9.  Yes, it might seem like more work, but doing minor upgrades lets you concentrate more of the testing time and details on the little bits that get fixed in between each package, rather than having to test the entirety of the package.

Don’t even get me started on huge upgrades. All of those small changes between versions are cumulative; to do a massive upgrade, you could be looking at thousands of fixes, and changes to test and new functionality to learn. If you update regularly, you’ll catch problems earlier.

Do: Reconsider How Many Environments You Need

OR: Too many times, you'll run into challenges because you have too few environments. A common challenge is that of promoting changes. It's difficult to promote individual changes, so you'll be faced with the choice of promoting all or none of your changes. Plus, it's difficult to remember just how many changes you need to promote.

Case in point: let's say you want to conditionally change the color of a field. There are several steps that need to be taken to achieve this. If you combine this with any other change that you promoted or have to promote, and you only have two environments, it can be a nightmare to manage.

If you had a third environment, you can promote everything worry-free without the need to separate out changes. Plus, with a third environment you would have practiced the promotion to work out any kinks before promoting to live.

The number of environments you'll need will depend on your organization, but I say at minimum you should have three if you're doing a lot of development work, customizations, and scenarios. You want the ability to experiment and mix it up in the development environment, promote to a test environment that has all of your stable changes (plus practice the promotion part...this can be complex in Maximo), and of course, have your live environment.

You can work with IBM Maximo for decades and there will always be something new to learn, or some fresh piece of advice to discover. Hopefully these Dos and Don’ts inspire you to review your processes, implement consistency, and most of all, question everything and aim to simplify.