Asset Maintenance Idea

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Asset Maintenance Idea

Adrian Crum
Now that it's clear to me that the ProductMaint entity is intended to be
used as a type of template for recurring fixed asset maintenances, I'd
like to add a data entry screen to the Asset Maintenance component for
ProductMaint.

I was thinking it would be more understandable for someone in the
maintenance role to call it a Fixed Asset Maintenance Template. In other
words, the ProductMaint entity would be used, but it would be called a
Fixed Asset Maintenance Template in the UI.

Also, to keep things simple for the users of Asset Maintenance, if the
fixed asset isn't already connected to a product and a ProductMaint is
created for it, would it be okay to create a Product record on the fly?

What do you think?

-Adrian
Reply | Threaded
Open this post in threaded view
|

Re: Asset Maintenance Idea

David E Jones

The more important and powerful concept is not that there is a  
template for maintenance, but that a FixedAsset is an instance of a  
Product.

If anything the usefulness of a FixedAsset being associated with a  
Product should be emphasized more in the UI. For example in the  
maintenance area if the FixedAsset is not associated with a Product  
that it is an instance of, then there should be a warning message  
about that, and that also makes it clear that there is no maintenance  
schedule because of it, etc.

In other words, I don't really like the idea of hiding these sorts of  
concepts in general. Making them more clear and easier to understand  
will ultimately make the power of the concepts clear and the patterns  
in the system, and reusing familiar things like a Product, will become  
empowering. The approach of hiding these sorts of things may make  
certain things easier, but overall makes the system more confusing and  
difficult to use, especially when a user gets out of the area you've  
tried to make easy and hide the complexity (unless you design an  
application for very specific tasks, then limit away to optimize it;  
the generic apps can be used if something comes up that wasn't planned  
for).

-David


On Jun 26, 2008, at 3:13 PM, Adrian Crum wrote:

> Now that it's clear to me that the ProductMaint entity is intended  
> to be used as a type of template for recurring fixed asset  
> maintenances, I'd like to add a data entry screen to the Asset  
> Maintenance component for ProductMaint.
>
> I was thinking it would be more understandable for someone in the  
> maintenance role to call it a Fixed Asset Maintenance Template. In  
> other words, the ProductMaint entity would be used, but it would be  
> called a Fixed Asset Maintenance Template in the UI.
>
> Also, to keep things simple for the users of Asset Maintenance, if  
> the fixed asset isn't already connected to a product and a  
> ProductMaint is created for it, would it be okay to create a Product  
> record on the fly?
>
> What do you think?
>
> -Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Asset Maintenance Idea

Adrian Crum-2
Good points, thanks!

-Adrian


--- On Sun, 6/29/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Asset Maintenance Idea
> To: [hidden email]
> Date: Sunday, June 29, 2008, 2:07 AM
> The more important and powerful concept is not that there is
> a  
> template for maintenance, but that a FixedAsset is an
> instance of a  
> Product.
>
> If anything the usefulness of a FixedAsset being associated
> with a  
> Product should be emphasized more in the UI. For example in
> the  
> maintenance area if the FixedAsset is not associated with a
> Product  
> that it is an instance of, then there should be a warning
> message  
> about that, and that also makes it clear that there is no
> maintenance  
> schedule because of it, etc.
>
> In other words, I don't really like the idea of hiding
> these sorts of  
> concepts in general. Making them more clear and easier to
> understand  
> will ultimately make the power of the concepts clear and
> the patterns  
> in the system, and reusing familiar things like a Product,
> will become  
> empowering. The approach of hiding these sorts of things
> may make  
> certain things easier, but overall makes the system more
> confusing and  
> difficult to use, especially when a user gets out of the
> area you've  
> tried to make easy and hide the complexity (unless you
> design an  
> application for very specific tasks, then limit away to
> optimize it;  
> the generic apps can be used if something comes up that
> wasn't planned  
> for).
>
> -David
>
>
> On Jun 26, 2008, at 3:13 PM, Adrian Crum wrote:
>
> > Now that it's clear to me that the ProductMaint
> entity is intended  
> > to be used as a type of template for recurring fixed
> asset  
> > maintenances, I'd like to add a data entry screen
> to the Asset  
> > Maintenance component for ProductMaint.
> >
> > I was thinking it would be more understandable for
> someone in the  
> > maintenance role to call it a Fixed Asset Maintenance
> Template. In  
> > other words, the ProductMaint entity would be used,
> but it would be  
> > called a Fixed Asset Maintenance Template in the UI.
> >
> > Also, to keep things simple for the users of Asset
> Maintenance, if  
> > the fixed asset isn't already connected to a
> product and a  
> > ProductMaint is created for it, would it be okay to
> create a Product  
> > record on the fly?
> >
> > What do you think?
> >
> > -Adrian


     
Reply | Threaded
Open this post in threaded view
|

Re: Asset Maintenance Idea

Adrian Crum-2
In reply to this post by David E Jones
So, should fixed asset maintenances in general be disabled when the fixed asset isn't related to a product?

-Adrian

--- On Sun, 6/29/08, David E Jones <[hidden email]> wrote:

> If anything the usefulness of a FixedAsset being associated
> with a  
> Product should be emphasized more in the UI. For example in
> the  
> maintenance area if the FixedAsset is not associated with a
> Product  
> that it is an instance of, then there should be a warning
> message  
> about that, and that also makes it clear that there is no
> maintenance  
> schedule because of it, etc.



     
Reply | Threaded
Open this post in threaded view
|

Re: Asset Maintenance Idea

Jacques Le Roux
Administrator
Adrian,

From: "Adrian Crum" <[hidden email]>
> So, should fixed asset maintenances in general be disabled when the fixed asset isn't related to a product?

At some point you have to relate a fixed asset to a product, so I'm not sure of the question...

Jacques

> -Adrian
>
> --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote:
>> If anything the usefulness of a FixedAsset being associated
>> with a  
>> Product should be emphasized more in the UI. For example in
>> the  
>> maintenance area if the FixedAsset is not associated with a
>> Product  
>> that it is an instance of, then there should be a warning
>> message  
>> about that, and that also makes it clear that there is no
>> maintenance  
>> schedule because of it, etc.
>
>
>
>      
>
Reply | Threaded
Open this post in threaded view
|

Re: Asset Maintenance Idea

David E Jones
In reply to this post by Adrian Crum-2

It's a good question... and I'm not sure if we need to go that far. It  
is conceivable that someone would want to track maintenance history  
without planning for future maintenance, and so they wouldn't need the  
Product and ProductMaint records.

-David


On Jun 29, 2008, at 9:15 AM, Adrian Crum wrote:

> So, should fixed asset maintenances in general be disabled when the  
> fixed asset isn't related to a product?
>
> -Adrian
>
> --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote:
>> If anything the usefulness of a FixedAsset being associated
>> with a
>> Product should be emphasized more in the UI. For example in
>> the
>> maintenance area if the FixedAsset is not associated with a
>> Product
>> that it is an instance of, then there should be a warning
>> message
>> about that, and that also makes it clear that there is no
>> maintenance
>> schedule because of it, etc.
>
>
>
>