Maximo Data Nightmares: Beware These Productivity-Sucking Ghouls

Trick or treat?

With the right tools for IBM Maximo, enterprise maintenance professionals can accurately forecast, organize, prioritize, and assign maintenance work to optimize operations and increase wrench time. That’s a full-sized Snickers in your treat bag. But tricks abound, your Maximo data can become a nightmare… and having bad data is like being haunted by a vampire ready to suck the lifeblood out of your time and resources.

Remember, there is more than one way to slay a vampire — just like there is more than one way to avoid these data pitfalls while using IBM Maximo.

They say forewarned is forearmed. So, that’s what Keith Schramm, Richard Almendarez and Elliot Bonilla, three leading Maximo experts have set out to do. We’ll arm you with a wooden stake, garlic, and a dash of holy water to help you keep the Maximo data monsters at bay.

Here are several common data malpractices to watch out for:
‍

IBM Maximo Data Nightmare #1: Special Characters

% - + = “ &

They don’t look that scary. But using special characters can be tricky and may yield unexpected results.  Let’s say you’re looking to find all of your Locations that have Inlet- Office identified in the Locations. Description column. This seems like it’s a pretty straightforward task, right?

After entering Inlet- Office in the Description field and hitting enter, the results returned aren’t what’s expected. One would typically expect to have the five Locations above returned in the result set, but what is actually returned is one Location – with a Description of Supply Duct Inlet- Conf. Room #100.

The reason this occurs is that the minus sign translates into two portions of a SQL statement.  E.g. return any Location that contains Inlet, but does not contain Office.

Different special characters can have varying results based on several factors, and it’s important to understand how these items can change the results returned.  When configuring your system and training your users, keep the following considerations in mind:

• Does the query include wildcards ‘%’?
• What’s the search type of the column in Maximo? (Exact, None, Text or Wildcard)
• Understand how using special characters in query can yield different results

Names with apostrophes (e.g. O’Keefe, O’Neal) can also throw a wrench into the works. In this case, the easiest solution is to eliminate the ‘, since single quotes are used to find literal strings in a query.

Maximo data best practice: Avoid using special characters whenever possible. Are there situations in which it makes sense to throw one in? Sure, but in general, sticking with alphanumeric characters will help you find and manipulate the data you need efficiently and effectively.

IBM Maximo Data Nightmare #2: Smart Numbers

Friends don’t let friends create smart numbers. As soon as you try to embed any kind of smartness into a set of characters, you end up running the risk of making your querying much more complex, and this sometimes defeats the goal in the first place. The rules that “never change” when making smart numbers can also end up miraculously changing, causing pain and suffering moving forward.

Image Credit: Bright/Kauffman/Crane Productions & Warner Bros. Television via GIPHY

For example: Let’s say you have a PM (Preventive Maintenance) to perform a quarterly service on a condensate pump.  The PM # gets created as: 3M-BR430.  3M indicates the frequency and frequency unit in which the PM is performed and BR430 is the Asset Number.  These two components are separated by a ‘-‘ hyphen (see IBM Maximo Data Nightmare #1 above).

After an analysis of your PM program, it’s determined that this PM only needs to occur every 6 months instead of every 3 months. So, what do you do now?  Do you simply update the frequency and frequency unit, creating a mismatch between the PM # and the other data elements on the PM record itself?  Do you create new PMs creating a disconnect between the history of the previous PMs and the new PMs?  If you go this route, I’m hoping you won’t be embedding the new frequency and frequency unit in the PM identifier.  Or perhaps you perform a back-end update to change the identifier, hopefully not missing any database records, thus compromising the integrity of your system.

Now this is just one example. We’re not saying, don’t ever use smart numbers.

Sometimes using a smart number does make sense. Location hierarchy is a prime example. If you use auto numbering for all your locations, data becomes extremely difficult to work with if you’re trying to traverse it through the Maximo Location Drilldown.

If you’re careful, you can group parts of your plant or units by a prefix. Use a like statement: for example, BR1%. Then you’ll get all the BR1s - the 100s, the 110s, the 120s, etc. That’s helpful when it comes to groupings. Some of the best location hierarchies utilize smart numbers, and then start to auto-number when it gets to the point that the location hierarchy is no longer needed.

Maximo data best practice: Be smart about smart numbers. Using them sparingly, and only when they facilitate fast access to your data is critical.

IBM Maximo Data Nightmare #3: Case Sensitivity

It’s OK to be sensitive. Or insensitive. Where you can run into trouble is when you use case sensitivity in an inconsistent way. We see this on certain database platforms like Oracle. For instance, the database may be configured such that Keith is not the same as keith or KEITH.

So, if you were writing a query where name is like keith, you have the same letters but perhaps not the same case. It can come back as a false instead of a true.

As you can see above, there are no matches for RAIL or rail in a case sensitive environment, without taking the proper approach in your querying.

Maximo data best practice: Should you turn off case sensitivity so your queries will return all results regardless of capitalization? No! We’ve never seen this and we don’t recommend it. But you should be mindful of the issue, especially when configuring and defining your user experience. Make these decisions consciously, record them, and make sure your team follows the documented process.

And definitely do not create mixed case data directly into database columns that are defined as Upper data type.  Technically, you should create data in Maximo using one of the many different methods provided by the MIF (Maximo Integrated Framework), as this data scenario can create a real nightmare.
‍

IBM Maximo Data Nightmare #4: Non-Standardized Names/Definitions

What’s a 2x4? Is it a 2 x 4? 2” x 4”? 2in x 4in? 2 inch x 4 inch? Give this one simple inventory item to ten different people, and you’ll get 10 different naming variations. How do you find what you need?

Non-standardized names and/or definitions are a common issue in IBM Maximo implementations. Another example: a client may track their software licenses inside of Maximo, some records are identified as “MS Office” and others “Microsoft Office”.  Sometimes abbreviations or the spelling is different as well: “MS” or “Microsoft”.

It can be difficult to find your records if you’re searching across inconsistent data. There are other ways to search of course, but using data best practices keeps you from having to waste time finding all data variations.

Non-standard names and definitions cost you untold time, money, and aggravation. You may see an increase in inventory costs, duplication of items, inefficient asset management, and even unexpected downtime. It's enough to make you want to run and hide.

Image Credit: 20th Century Fox via GIPHY

Maximo data best practice: A standard naming convention is essential to ensure consistency and accuracy. You can build this manually using common nomenclature. That’s OK. Better is using commodity and commodity groups (which are also referred to as “known qualifiers”).

Best is leveraging Maximo’s classification and classification hierarchy and possibly using specs to build out the most important attributes in the descriptions. If you have your classifications set, all of your inventory, all of your assets, will be properly named. Another potential data monster vanquished.
‍

IBM Maximo Data Nightmare #5: Tracking Data Outside Your System of Record

Let us tell you a dark and spooky data tale. We pulled a PM forecast for a client. They were all bi-annual PMs, and we were showing them how the virtual PMs (PMs due to generate in the future) would appear every two years. The client said, “That’s wrong. They’re actually annual PMs.”

We told them it was pulling directly from Maximo, and the Maximo data said they were supposed to do these PMs every two years.

Their answer?

“Yeah, but we have a spreadsheet, and we keep track of when they’re done every year.  Maximo just never got updated.”

‍

Image Credit: Illumination entertainment & Universal Pictures via GIPHY

Tracking data in a source other than your system of record is problematic, for so many reasons. For one, how can you validate that you’ve truly completed your PMs based on the frequency and date constraints if you’ve got data silos outside your system of record?

We’ll often bring up all the labor records that reside under a supervisor, and the customer will say, “This person retired. That person’s not with the company anymore.” We’ve even heard, “This person’s dead.”

But their records are all still active in Maximo and they have missing or out of date data elements. That costs time and money! You have this system for a reason. The more these inaccuracies and inconsistencies build up, the harder it is to manage later. Your value lists, data selections — everything — continually grows and become infinitely harder to manage.

Maximo data best practice: We know. For a lot of people, the thought of cleaning up the Maximo data is terrifying; they think it’s going to be a difficult, long, unpleasant job. Well, it will be if you don’t have the right tools. Prometheus Routine Maintenance can help you clean up your data and ensure it is accurate and up-to-date. When Maximo is your system of record, use it. And don’t stray.  It’ll make it easier to find, manage, and manipulate the data you need when you need it.

Bad data can make your life a nightmare. It breaks queries and grinds searches to a halt. It prevents WOs from appearing when they should and interferes with your ability to schedule the right jobs at the right times. It makes metrics and reporting nearly impossible.

Of course, there are many theories out there about the best ways to keep your data “clean” — this is just our advice based on what we’ve seen over the year