It’s happened in more places and implementations than I can count. A client uses Maximo, and a user, we’ll call him Bob, comes up with some great and useful queries. The easiest way to share it? Make it PUBLIC! This is great that Bob can share the query with everyone that uses Maximo. And then comes the problem: Bob leaves the company. And his user account is locked or closed, and a change needs to be made.
So are there best practices that should be in place? How does this normally get handled? Is there a better way? Let’s continue…
IT doesn’t want to unlock the account. They also work in a validated environment, so they dread the paperwork of changing data through the database. (Which should never be the go to, but here is a way to do it)
So what is the best solution? Do it right the first time! My personal recommendation? Nobody gets access to public queries. (click here for how to do this). Not one regular user. The administrative team creates another administrative user for Maximo, which they have already had a few of for Maximo, added to the AD setup. One more wont hurt. We’ll call this user MaxQuery. Just like maxadmin this users access will be closely guarded.
Any time there is a need for a public query to be created one of the system administrators logs in as MaxQuery and adds the query.
This approach seems as though it could slow down the process, but administrators need to look at the bigger picture. A recent client of mine had over 180 public queries in one application alone, about half of which had specific users names in the title! (I will put out another blog post soon on simple parameterization of public queries). Imagine looking for the query you want in a list that large. The purpose is then lost.
It’s time we start looking ahead when we think of how to handle public queries.
Part 2: How to do public queries the right way.
On a different topic, are you using Maximo Work Centers yet? If not, take a look at this and let us know if we can help get you there!