Maximo Open Forum

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Some guidelines I've typically used:

• (I'd say this one is by far the most important) if you want to make Work Orders against the "thing" (the physical object) so that you can track costs, see a history of repairs, list spare parts that would be used to repair it, etc. then it's an Asset; 
• if that thing broke and you would simply, almost always, replace it instead of repair it, then it is not an Asset, it is an Item;
• if it has a serial number, then it probably is an Asset, quite possibly a Rotating Asset (with a notable exception for us being small electric motors, which we would simply replace when they fail, therefore we treat them as consumable spare part/Items);
• if you have more than one of that thing, and you need to be able to track each one individually (such as where it was deployed/installed, or who checked it out from a tool crib), you'll want to make Rotating Assets

That said, about 4 years ago, we were considering moving to a certain rival system.  In their product demo they used a window crank as an example of an Asset.  I was astounded and it made me question my beliefs. . .and I still haven't fully decided if it makes me want to change my philosophy, but I do still have the question lingering in my mind like the OP here.  Why would a window crank be an Asset?  We don't even have the windows as Assets, much less a window crank!  Ultimately, I think that (at least for my org's needs) I wouldn't ever need to track repairs against a specific window, therefore the window should simply be an Item record -- with a proper Classification, with proper Attributes, so that I can track its Height, Width, Thickness, etc.; Vendors that we can buy it from and the cost of it; and associate that window to the room (which, for us, our Facilities/Buildings are our greatest Asset, so for every Location I have a matching/corresponding Asset, so I can associate spare parts to an Asset-Location) and the quantity thereof.

But we are looking at a few use-cases of tracking non-serial-numbered things as Assets, such as residential roofs, so we can specifically tie Work Orders to the roof Asset rather than more generally to the Location where it would be mixed in among all other repairs at that Location; we could track expected life, repair history, and plan for replacement; track Attributes specific to the roof; and simply track when it was replaced.

The obvious drawback is the more things that are Assets, that's more data that needs to be managed.  More lifecycles to deal with, more things to have to make sure that when the thing is physically replaced in real life then someone needs to make sure it is replaced digitally as well, more PMs and Routes to have to adjust to make sure you don't end up trying to make Work Orders against Assets that were replaced and scrapped, etc.

For your use-case, I would want to know what you use for procurement (if not Maximo) and accounting, and how tightly those systems are integrated to Maximo.  If you ask your accounting team, they will probably have a strong opinion of what should (and what should not) be an asset.  If you expand your definition too wide, start making lots of Asset records in Maximo, and an integration starts adding things to their system(s) that messes up their workflows and reports, . . .well, I'd advise just avoiding that conflict.

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Suwichak,

I'd like to clarify that I am not an implementation expert. However, based on what I am reading here I would likely move towards a setup where the RMU is an asset - which is in a location. Then components within the RMU would be listed as items. You could then add the components, like a fuse, as a spare part to the RMU asset. You can also have multiple assets within 1 location, so a 1 Asset = 1 Location does not fully make sense to me. However, that can be a business decision. here is a screenshot from Demo Data:

Inventory items would be place within a Storeroom in Maximo. Which is similar to a location, but has a different purpose. Storerooms are specialized Locations used specifically to manage inventory, tracking balances, and financial costs for items. Conversely, Locations (typically Operating) represent functional areas where assets reside, perform work, or are repaired.

I hope this helps continue to clear up the path you and your business are working on.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

I absolutely love this question.  I've been wrestling with it a lot lately as I consider adding more Systems.  Here's one I've been pondering:

We've got a guy who is on the cusp of retirement that has this 3" (maybe thicker!) book full of pictures showing where all the components of the fire sprinkler systems are in each building.  I'll just use the building I'm in as an example.  There's a room downstairs that we simply call "the fire pump room."  So there's a Location (AD1FIREPUMP), which is part of the Primary Location hierarchy under MAIN (Main Campus) --> AD (Administration Building) --> AD1 (Administration Building First Floor).  That part seems easily understood.

In that Fire Pump Room, there are several Assets, not just the Fire Pump.  There are electrical panels, a transformer, the fire pump, its motor, controller, jockey pump and its motor, and a backup generator.

So if I wanted to include this in a new FIRESPRINKLER Location System, I'd surely include MAIN, AD, AD1, and AD1FIREPUMP.  But then I'd want to include which Assets belong in the System.  For example, the transformer in that room isn't really directly a component of the sprinkler system; I'd want my System to just include the locations of the pump, the standpipes, the shutoff valves, etc.

Look back to that Naviam article that Allan linked to above.  In it, it has this example:

When I look at that, my initial reaction is, "Why would you have something like TRANS40 as a Location?  That's an Asset!  And what are you going to do if, say, you updated your electrical grid and that transformer changes, like it's not 12000V to 440V anymore?"

I suspect what's going on there is that while the Location SUBSTN seems like an actual, physical place, the Locations like TRANS40, ECC210, BRK431, and BR430 are more like logical placeholders for Assets.  So you'd have an Asset record for the 12000V--440V Transformer, with its serial number, etc., and you'd assign it to Location = TRANS40.

The downside to that is if I go to look at all the Assets in a physical Location, such as SUBSTN in this example, I wouldn't (directly) see it there.

I really wish that Assets had Systems the way Locations do.  It seems more logical to me that you'd want to get to a physical place (Location), observe the Assets there (electrical panel, transformer, pump, motor, etc.), and understand why those Assets are there (e.g. the electrical panel and transformer are part of the ELECTRICAL system, the fire pump is part of the SPRINKLER system, etc.).  

Alternatively, Assets do have the ability to create custom RELATIONSHIPS -- and this is a relatively new feature, I think introduced in 7.6.x. I haven't done this yet IRL, so maybe this is a dumb example, but maybe I'd have a flow switch on the 4th floor mechanical room (Location = AD4MECH, and the flow switch is an Asset in that Location), a custom relationship called ACTIVATES, and connect my two Assets as 

the flow switch Asset (which is in Location=AD4MECH)   ACTIVATES    the fire pump (which is in Location=AD1FIREPUMP).

This is done in the Assets application, Relationship tab.  In this way, it's at least kind of like creating Asset Systems.  I think this is going to end up being a better approach than the one in the picture above, at least for my use case.  Would love to hear others' input and advice!

Suwichak, I know this doesn't directly answer your question, but I think you could take this concept and apply it to your use case.

>>Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

I'd say no.  If that were the case, IBM probably would have automated creating a Location every time you make an Asset and vice versa.

I'm not sure how SAP works, but I will add that in the last few years I've been through a few dozen product demos as we consider whether or not our org is going to keep Maximo.  In several of these CMMS, EAM, or IWMS systems, there was no distinction between Locations and Assets.  Everything was simply an Asset, and everything connected into one hierarchy.  Maximo offers a lot more flexibility. . .which can also mean complexity and confusion.  It's definitely good that you're asking questions and planning first before implementing!

Suwichak,

I'd like to clarify that I am not an implementation expert. However, based on what I am reading here I would likely move towards a setup where the RMU is an asset - which is in a location. Then components within the RMU would be listed as items. You could then add the components, like a fuse, as a spare part to the RMU asset. You can also have multiple assets within 1 location, so a 1 Asset = 1 Location does not fully make sense to me. However, that can be a business decision. here is a screenshot from Demo Data:

Inventory items would be place within a Storeroom in Maximo. Which is similar to a location, but has a different purpose. Storerooms are specialized Locations used specifically to manage inventory, tracking balances, and financial costs for items. Conversely, Locations (typically Operating) represent functional areas where assets reside, perform work, or are repaired.

I hope this helps continue to clear up the path you and your business are working on.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Suwichak,

I'd like to clarify that I am not an implementation expert. However, based on what I am reading here I would likely move towards a setup where the RMU is an asset - which is in a location. Then components within the RMU would be listed as items. You could then add the components, like a fuse, as a spare part to the RMU asset. You can also have multiple assets within 1 location, so a 1 Asset = 1 Location does not fully make sense to me. However, that can be a business decision. here is a screenshot from Demo Data:

Inventory items would be place within a Storeroom in Maximo. Which is similar to a location, but has a different purpose. Storerooms are specialized Locations used specifically to manage inventory, tracking balances, and financial costs for items. Conversely, Locations (typically Operating) represent functional areas where assets reside, perform work, or are repaired.

I hope this helps continue to clear up the path you and your business are working on.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.

We have ended up in exactly this position following the recommendation of 1:1 Location/Assets. I'm keen to rethink this more along the SAP lines where MAS Location = SAP FLOC, MAS Asset and Children Assets = SAP Equipment, and MAS Asset Item = SAP BOM. I would see a location hierarchy for a generator possibly for something like Building>Generation Floor>Generator Unit >Generator, then into the Asset hierarchy, Generator>Slip ring>Brush gear into the Items list>Brushgear holder, Springs, Brushes, etc.

Hi Allan,

Thank you very much for your explanations so far - they've been very helpful. I'd like to ask a follow-up question based on a real implementation challenge I'm currently facing, to make sure I'm applying Maximo's design intent correctly.

Previously, I was responsible for CM/PM using our client's SAP system. This year, the client decided to migrate to IBM Maximo, and a system integrator was engaged to support the implementation. However, I was asked to define and build the Location, Asset, and Work Management data model, because the integrator does not have detailed knowledge of the actual field equipment and layout.

From my understanding, Assets in Maximo are typically equipment or components that we intend to maintain, repair, track lifecycle history, and potentially relocate.

In our case, we have 24kV Ring Main Units (RMU). Inside a single RMU cabinet, there are components such as:

• LBS

• Power fuses / PT fuses

• Protection relays

• CTs / VTs

The client's expectation (based on guidance from the integrator) is that:

• Every internal component should be created as an Asset, and

• Each Asset should have its own 1:1 Location, even for items physically installed inside the RMU cabinet.

For example:

• RMU cabinet Location: PP01-CONN-PSY-MVD-RMU1-HR11

• Fuse Location (inside the same cabinet): PP01-CONN-PSY-MVD-RMU1-HR11F

This is where I'm struggling conceptually.

My concerns are:

• Consumable items such as power fuses and PT fuses are typically replaced rather than repaired. Should these really be modeled as Assets?

• When a fuse fails, the RMU itself is unavailable, so operationally the downtime is attributed to the RMU, not to the fuse as an independent entity.

• Since these components are physically installed inside the cabinet and do not have a separate physical location, creating a separate Location for each internal component feels artificial and adds significant complexity.

• I also struggle with the idea that Asset Numbers must strictly mirror Location codes. In practice, technicians find assets by Location, not by memorizing hundreds or thousands of Asset Numbers.

This leads to a larger question:

Is it truly a Maximo best practice that every Asset must have a 1:1 Location, even for internal components of a cabinet?

Or would it be more aligned with Maximo's design intent to:

• Use a single Location for the RMU cabinet, and

• Model maintainable internal equipment as child Assets, while treating consumables (such as fuses) as Items and recording downtime at the RMU level?

I'm concerned that enforcing a strict "1 Asset = 1 Location" rule will lead to over-assetization, excessive hierarchy growth, increased PM/CM overhead, and long-term data quality issues.

I would really appreciate your perspective on how you would model this in real-world utility or infrastructure environments.

Thank you again for sharing your experience.

Hi Suwichak,

Naviam had a blog written about Assets or Locations and why you need them both. There is an explanation of what each are, Give it a read and see if this helps.

https://www.naviam.io/resources/blog/locations-or-assets---why-you-need-them-both?redirected&brand=projetech

Hello everyone,

I am relatively new to IBM Maximo, and I would like to seek clarification on a topic where there seems to be different interpretations within our team regarding the definition of an "Asset."

In our current discussion, there is a proposal to model almost everything as an Asset and LRU, including very small components such as auxiliary relays, fuses, and similar minor devices.

My understanding, however, is that not everything installed in the system should necessarily be modeled as an Asset, and that Maximo has a specific design intent behind the Asset concept.

With that in mind, I would like to ask the following questions:

1. From a Maximo best-practice perspective, what is the formal definition of an "Asset"?

   • Is an Asset primarily defined by factors such as cost, criticality, maintainability, downtime impact, or lifecycle tracking?

2. What types of equipment or components should be modeled as Assets, and which ones are better modeled as:

   • Locations

   • Components or subcomponents

   • Reference or non-maintainable records

3. In real-world implementations, especially in infrastructure, utilities, or railway systems, what criteria do you typically use to decide:

   • "This should be an Asset"

   • versus "This should not be an Asset"

4. What are the potential consequences of modeling everything as an Asset or LRU?

   • Impact on CM and PM workload

   • Failure reporting and data quality

   • System usability and performance

   • Asset lifecycle management, replacement strategy, and KPI reporting

We are concerned that over-assetization may lead to long-term challenges in maintenance strategy, failure analysis, and overall data quality.

I would greatly appreciate insights from IBM experts, consultants, and experienced Maximo users.

Thank you very much.