The challenge of a single site when there are valid business entities which are in fact funded separately, managed separately, have unique assets, locations etc. is that when it is all piled into a single entity your location hierarchy become overly complex and difficult to manage. The storerooms now have to be logically separated on a business contract you create (as opposed to already in the system, Yes you can do additional work in your security groups but it is just that, additional work.)
What you have done is not wrong by any stretch. But is now a bit more complex that perhaps otherwise would be. I will say this: If it is working for you and you have the tools in place to properly manage your data and operations, do NOT attempt to split the single site into multiple. I did this recently for a customer and it was a royal PITA. The work is still not complete. There were VERY good reasons for doing so in the case I cite: There were a million (okay 970,000 plus) assets that users in the Fleet operations had to contend with when they actually only had about 5,000. Also the locations were configured in such a way that every physical location ( in this case schools) had "logical" locations which did not in fact exist in reality. (Think pools.... ugh!)
So to sum up, if you can separate the assets, locations, job plans etc. that are "site" based on your division attribute (hopefully you are using automation scripts and conditional expressions,) then you are at least able to manage the situation. Thanks for sharing.
------------------------------
Bradley K. Downing , MBA
Solutions Engineer
IBM
Bakersfield CA
------------------------------
Original Message:
Sent: Tue September 14, 2021 04:44 PM
From: User1971
Subject: Alternative to Maximo Sites
I thought I'd share my organization's experience with Sites and the alternative approach we used. I'm not the main person who manages this stuff, but I'll do my best to describe what has been done anyway.
My organization was guided to, and chose to not to use sites. Or should I say, all of our divisions use a single site.
Reason: As far as we could tell, sites didn't offer the flexibility we needed.
- We need to share many, if not all Maximo objects between all divisions. Examples:
- Work Orders and SRs
- Purchasing
- Assets & Locations
- Tools & Rotating Items
- Inventory, Items, Storerooms, & Companies
Pretty much everything. And I don't really remember the limitations that come with sites (the docs seem a bit light when I look back at them). I'm accustomed to our setup by now...and it's working well, so I don't actually need to think about this stuff very often.
- Like most organizations, we use security groups (aligned with licensing to a degree) to manage who can access what: applications, actions, etc..
Security isn't usually based on divisions (departments), it's based on the kind of position a user has:- Examples:
- INTERNALRES (workers)
- SACOORDINATORS (service area coordinators)
- SELFSR
- SRPROCESSORS
- SUPER_USERS
- SUPERVISORS
- BUSINESSSUP
- Other than the inherent hiding functionality that comes with security groups, we don't need to hide any parts of Maximo from anyone (i.e. hiding one division's records from another division). It's ok if all users can see all parts of Maximo.
- We only need to restrict editing records for certain key Maximo objects. This restriction is based on divisions (departments).
- We did this by creating custom DIVISION fields in many Maximo objects, including adding a DIVISION field to the PERSON table.
- And we created global data restrictions for restricting who can edit records.
DATA RESTRICTIONS
Work Orders
You can edit a Work Order (WO) if:
- Your Security Group(s) allow you to edit WOs
AND - At least 1 of the following is true:
- The WO Status is WAPPR ("Waiting for Approval")
- This allows cross-divisional WO creation, but restricts editing after the WO progresses beyond WAPPR
- Your Person record's Division matches the WO Division
- Your Labor or Crew has an assignment on the WO, or on a task of the WO
- You are in a Person Group that currently owns, or ever owned, the WO (Owner Group)
- You are in one of these Security Groups (MAX__, Business Support)
Assets
You can edit an Asset if:- Your Security Group(s) allow you to edit Assets
AND - Your Division matches the Asset Division
AND - The Asset's source is not GIS (all GIS Assets are read-only -- their system of record is a separate system; integrated to Maximo)
Locations
You can edit a Location if:
Your Security Group(s) allow you to edit Locations
AND
Your Division matches the Location Division
AND
The Location's source is not GIS (all GIS Locations are read-only -- their system of record is a separate system; integrated to Maximo)
(We've got a couple more global data restrictions based on division that are in the works too -- like PMs.)
It can get pretty interesting: staff can end up working in multiple divisions, on assets and locations from multiple divisions, as required. Example, the guy that maintains the pools for the recreation center division also drives snow plows for the roads division during snow storms. And a mechanic in the fleet division can work on fire trucks in the fire division. Or even on vehicles from outside companies/agencies. And those agencies buy our inventory items from us too. Also, WOs and SRs can get passed around between divisions.
I've exaggerated some of those examples a bit, and haven't totally covered them in the above documentation. But I think it gives you an idea of the kind of flexibility that we needed.
It's entirely possible that we misinterpreted site functionality/limitations. We fumbled through some of Maximo's complexities at first. If we did mix something up, it's far too late to go back now! :)
In summary, we use division fields and global data restrictions instead of sites. And it seems to be working well for us. Hopefully someone finds this interesting or helpful. Or maybe it's a somewhat common approach?
#AssetandFacilitiesManagement
#Maximo