There are several considerations to bear in mind when defining whether Maximo should have multiple OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More or multiple Sites. Bear in mind that one organization and one site is the simplest data model to follow, multiple organizations and sites will add complexity and you should be aware of what you can and can’t do in Maximo with these more complex data models.

Does your enterprise have one or multiple chart of accounts?

If there is one chart of accounts and a single base currency which is shared by all businesses in the enterprise then your first thoughts should be to implement one Maximo Organization. Otherwise your first thought will be to match one Maximo Organizations to each financial chart of accounts.

Will your Maximo system be used by multiple divisions of your enterprise?

If Maximo is to be used by multiple divisions that share the same chart of accounts and base currency then you may consider multiple Maximo Organizations. If the business functions performed by each division are diverse with little commonality then multiple Maximo Organizations is probably correct. If the business functions performed by multiple divisions are similar then only consider multiple Maximo Organizations if the divisions are different legal entities.

Do you wish to duplicate organization level data?

There are over 100 tables at the Organization level. If you have multiple Maximo Organizations and the business functions performed by each division are similar then you will be duplicating data and you will probably want to keep the data synchronised. There are no functions provided by Maximo which will keep records in multiple Organizations synchronised. The need to duplicate data at the Organization level should be viewed as a warning and you should ask yourself whether one Organization will suffice. The following tables exist at the Organization level.

• Financial – Chart of Accounts, Companies, Exchange Rates, Tax Codes, Financial Periods
• Resources – Crafts, Labor, Crew Types, Crews, Qualifications, Labor Work Zones
• Assets – Asset Templates, Failure Codes
• Contracts – Master, Purchase, Labor Rate, Lease/Rental, Warranty, Terms and Conditions
• Miscellaneous – Work Types, Hazards, Work Zones, Service Addresses, Calendars and Shifts

Consider the following:

• If you have contracts that need to be shared by multiple business units then those business units should not be in different Maximo Organizations.
• If you want your business units to share the same failure hierarchy or share the same set of asset templates then they should be sharing the same Maximo Organization
• If inspectors/engineers/technicians (labor) can work across several business units then those business units might share the same Maximo Organization.
• If you want to simplify an integration with a finance system then consider whether one organization will suffice. 

Are you using Organizations and Sites to represent a part of your organization?

Data separation is provided at the SiteA structural element of a Maximo database that is used for data separation. More level. Locations, Assets and Workorders are all Site level objects. You cannot:

• Link one asset to a location of another site
• Link one location to a parent location of a different site
• Create a work package of work orders from different sites
• Mix work on locationsA physical place where assets exist and where work can be performed. More and assets from different sites on the same work order.

Think of Maximo Sites as islands where locations and assets exist and where work is performed, but there are no bridges between these islands. If you have infrastructure assets (electricity, water, gas, roads, telecoms) then using a Site to represent an area, region or business unit is likely to be incorrect. A road doesn’t stop at a county or state boundary, therefore representing a county or state as a Site will make it difficult to map the physical asset structures into Maximo and is likely to create issues when you integrate your assets to other systems that do not understand these boundaries.

Is the meaning of a Maximo Organization or Site going to change over time?

One issue with representing a region, business unit or division with an Organization or Site is that you cannot change this in Maximo without a lot of backend SQL work (which should be avoided). This is because the ORGID and SITEID are part of the keys to the Maximo Organization and Site level objects (often part of the unique key) and you cannot change these keys. If your assets or locations can potentially change to a different region, business unit or organisation then do not use these to represent a Maximo Organization or Site.

Is hard security required between the members of one part of your organisation and another?

Data separation is provided at the Site level in Maximo and is the natural place where you can restrict a user or group of users to the data of one or more Sites. But Maximo has other ways of separating data using Object Data Restrictions. For example, if regions and areas are represented in your location hierarchy then you can restrict users to one or more regions or areas quite simply. Then again, is security always hard (as if the data from another site does not exist) or is it hard most of the time but there are occasions when a user can work on the assets or locations of another Site (soft security)? If there are exceptions then don’t be tempted to use the Maximo Site as providing the hard security as there are other techniques that can be deployed just as easily.

Bear in mind that keeping it simple is often the best policy.