Some of the many capabilities inherent to Maximo are configuring and tailoring the application to be more friendly toward how you do business. These will be referenced explicitly because they are supported through upgrades, so you don’t need to make those changes again. This will become more important as you get Maximo into production and begin the process of patching and upgrading as you expand usage throughout your business.

Many of these capabilities, which are often seen in articles, videos, and similar media, focus on Work Management and several supporting modules (Assets, Planning, PM, etc.).

Here, we will focus on Inventory and Procurement, and screenshots will reflect MAS 9.0, although changes are applicable to 7.6.x. Most of these changes are for convenience, simplifying navigation, querying, and a little reporting. From a convention standpoint, you may see OOB (out-of-the-box) or COTS (commercial off-the-shelf) as references to how Maximo is delivered in its base configuration before you make edits.

Most of these will involve changes in database configuration and/or application designer, such as adding or modifying attributes (fields) and, in some cases, report object structures.

A general note before digging into the details. Maximo is delivered with tools that can make Maximo bigger. Consider using them to make Maximo smaller and easier to use. The first step in simplifying Maximo should be leveraging security so people will only get what they need, and what they don’t need won’t be in the way or a distraction. This is covered here: https://www.projetech.com/maximo-blog/maximo-security-simplifying-the-ui-and-creating-maintaining-roles.

Subsequently, List Tabs, Value Lists / Domains, Application Dialogs, and even Application Screens will allow for the addition of extra elements. Consider hiding some things in the same process, if they are not needed. Maximo is designed to be flexible and to accommodate different industries and use cases, but consider yours as you make changes, and you can declutter along the way.

Inventory

From a configuration standpoint, the inventory manufacturer’s model number field should be considered for expansion as it comes OOB as 8 characters, while the vendor’s catalog code is 30. You should consider making them the same (30), at minimum.

List tab – if you are not using any ‘Rotating’ inventory, consider hiding the field, since you are most likely going to add something there anyway.

Advanced Search will likely have the biggest change because the default search is for the Primary Vendor data area on the INVENTORY object. When you make a change in the Inventory Application to say the primary vendor and catalog code for a given item, upon saving the change you will notice a new row of that data in the ‘Vendors’ frame on the Reorder Details tab.

Previously printed (and some electronic) references will, however, still have the older data on vendor and catalog, and that will be what you need to search with.

Adding an INVVENDOR object search area to the advanced search will allow you to search both because the Primary Vendor area data will also be in the ‘Vendors’ frame, which is in the INVVENDOR object (Table) in Maximo.

More importantly, making this change simplifies the search dramatically for the user; when looking in MAXDEMO as an example, for vendor HELWIG catalog code 4302 using the INVVENDOR search area, the syntax Maximo writes for you is:

(status != 'OBSOLETE' and siteid = 'BEDFORD') and (exists (select 1 from dbo.invvendor where ((vendor like '%HELWIG%' and upper(catalogcode) like '%4302%')) and (itemnum = inventory.itemnum and itemsetid = inventory.itemsetid and orgid=inventory.orgid and (siteid is null or (siteid is not null and siteid=inventory.siteid)))))

Since the MAXDEMO Primary Vendor details would be ATI catalog code 123998, a search using the Primary Vendor area fields only would not find the record.

Note that this type of change is most often used/deployed for storerooms managed by an external vendor. This becomes more significant when that vendor changes, which changes a lot of that vendor/catalog code data.

Are you considering making a part obsolete, or just need to know the history of where and when it has been issued? The inventory application will show you the last issued date by storeroom, for any inventory item. Counts from the previous 3 years will also be easily available.

But if you need more, then you will need to dig into history and write a query statement to do your search or have the advanced search in, say Work Order Tracking, modified to allow the end user to utilize the existing search capability:

Your query would then be written for you by the Maximo search capability as:

((woclass = 'WORKORDER' or woclass = 'ACTIVITY') and istask = 0 and siteid = 'BEDFORD') and (exists (select 1 from dbo.matusetrans where ((itemnum like '%11453%')) and (refwo=workorder.wonum and tositeid=workorder.siteid and linetype not in (select value from synonymdomain where domainid='LINETYPE' and maxvalue='TOOL'))))

This is letting Maximo do the heavier lifting for your users who will not need to understand the intricacies of the data model or have to write the SQL statements directly.

Purchasing

For Purchase Orders and or Requisitions list tab, there are a couple changes to consider. Company codes are not always easy to understand, especially when your company data comes from another system via integration. Searching from the list tab via the company code therefore is not the easiest thing to do.

Adding the ‘PO_VENDOR.NAME’ attribute to the list tab can simplify the search for all users. Also, if you often need to toggle your history flag, as it is a narrow field, you can consider adding it to the list tab, again to simplify searching.

Note that they syntax for the companies.name field references the relationship, rather than the primary table name. For more info on displaying additional information through a relationship in Maximo, click here.

Purchase Order Advanced Search will likely still be delivered with the total cost in the ‘Line Details’ frame. The general preference would be to change the cost in the Line Details to reflect the POLINE.LINECOST and add a new field above the Line Details area for the PO.TOTALCOST, so you have the flexibility to use either or even both. More importantly, it is more consistent with

the object being searched (PO vs POLINE). The Purchase Requisition application does not have the same issue OOB, but the PR.TOTALCOST will need to be added if you want it there.

‍

Object Structures

The Integration Module contains Report Object Structures useful for:

· Start Center Results sets

· Query Based Reporting

· Work Centers / Role Based Applications (depending on your version)

More importantly, a number of these report object structures are available when Maximo is delivered, AND you can build them directly in Maximo via the Object Structures application. As you begin your implementation, you may want to keep the original object structures ‘as-delivered’ and create duplicates for deployment and that is fine if you choose to do so. Let’s take a look at a couple for Query Based Reporting:

· There is no Companies object structure, so if needed you should build it with both the COMPANY and COMPCONTACT objects, at minimum.

· The inventory object structure (REP_INVENTORY) does not have the ITEM object, so you will need to add it. This will allow query based reporting done from the Inventory application to be able to add the item description to those reports.

Maximo remains an extremely flexible application with tools built in to make changes to better support your organization, including the ability to make it smaller.

‍