What is our scope?

[rafehi]

Asset management means a lot of different things to different people. Let's agree on an initial scope for the asset management platform. What is within scope and what is outside of scope?

Things to consider (most of these are probably outside of scope):

• Lists of assets
• Hierarchy of assets
  • Group individual assets into larger hierarchies. e.g. multiple individuals assets might be combined to create a wind turbine.
• Reporting of asset status
  • Ability to raise a defect against an asset. e.g. wind turbine temperature is much higher than expected
• Schedule unplanned maintenance against an asset
  • Raise a job in response to an asset defect
• Schedule planned/regular maintenance against an asset
• Procurement and inventory management
• Asset performance management
• Asset lifecycle management
• Maintenance and work/job history

[rafehi]

Provisioning, maintenance and lifecycle seem to be a core tenant of any asset management platform. How heavily do we have to invest in each area, and what's the required functionality for it to be useful?

[rafehi]

From a use-case point of view, which of the following do we think are relevant to our asset management solution? Which can we do without, which can we expect another product to provide that functionality, and which is a requirement?

• Asset lifecycle/state management. What is the status of my asset? Is my asset currently operational? e.g. I run a mining operation, and I want to know if:

  • my new haul truck has been commissioned and is ready for operation
  • my haul truck is un-operational due to a scheduled maintenance
  • my haul truck is un-operational due to a defect
  • my haul truck has reached end-of-life, and is in the process of being decommissioned

• Scheduled maintenance. When is the next scheduled maintenance of my asset due? Am I able to create a maintenance schedule? e.g. I'm in charge of the service department in a mining operation, and I want to:

  • create a maintenance schedule to service my equipment every 3 months
  • be able to assign a person to perform the maintenance
  • specify what needs to happen as a part of the maintenance (e.g. tires need replacement)

• Unplanned maintenance. Can I create jobs in response to events? Am I am able to set a priority on these jobs? e.g. I'm in charge of operations in a water treatment plant, and I want to:

  • create a high priority job to fix a burst pipe in my plant

• Preventative maintenance. Can I leverage real time information from my asset to perform preventative maintenance. e.g. I'm in charge of operations at a wind power plant, and I want to:

  • create a job to power down a wind turbine in response to a high level of vibration, to limit damage to my equipment

[NRaf]

Looking at it, a lot of those points don't seem to be relevant to what we need at the current moment, and potentially overkill for who the target audience of the product (this point needs to be evaluated).

I think an important step is actually defining the goal of the product and using that as our guiding compass. If we start talking about maintenance and all these other stuff, it does seem to be taking us into the direction of a full-blown asset management solution, which isn't the market we want to be focusing on.

If we are talking about taking a modular approach, it's possible that things like maintenance will make sense as future modules, but again, until we put boundaries around our scope, it's hard to come away with anything concrete.

[rafehi]

I agree that it seems to be out of scope, but maintenance and lifecycle literally seem to be the "management" in asset management. Without those, you might have a useful product, but I'm not sure it's asset management any longer.

For some context, the more fully featured asset management products out there integrate with:

• asset tracking
• links to relevant documentation, such as user manuals, etc
• purchase orders, order history
• manufacturer and warranty information all of which, I agree would be out of scope.

On the other hand, data pipeline connecting to sensors certainly seems to be out of scope for an asset management platform.

It's essential that we frame the questions we're asking appropriately at this stage, with well-defined clear criteria. While asking "what is our scope?" is an important question, the more fundamental question is: what do we require from asset management? Building our own platform is one option, but perhaps not the only one.

[viztastic]

In terms of end game, I think all of that is in scope. We want to be an amazing opensource asset management platform.

It's not a matter of scope, I think it's a matter of prioritisation and roadmap. Might be worth agreeing on principles, e.g.:

1. We prioritise what we need in the short term for existing sponsors
2. We're designing with composeability in mind
3. Components that may not be crucial for us at the moment can be built out in satellite projects down the track by anyone else in the opensource community, including us.