This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
So let's talk about asset downtime.
We have a subset of staff that will take service requests, tickets, and that sort of stuff. Occassionally, a user in that role will get a report of equipment down. I want to allow that user to report downtime, and only report downtime, for an asset.
However, in looking at secGroups, I can allow READ access to assets but that is insufficient. Makes sense, I need to write to assetstatus and the Asset app controls this. I allow SAVE and yes, now I can allow users to report downtime.
And edit fields. Wait, I don't want that to happen. I just want to allow access to one "Select Action" entry.
Question to the group: how can I do this? I'll take all the possible methods the group can conceive.
-C
Do they have access to Work Order Tracking? You can also report downtime from there.
Sent from my wonderful BlackBerry Z30 smartphone!
Original Message
From: maximal@wanko.com [MAXIMO]
Sent: Friday, January 9, 2015 7:27 AM
To: MAXIMO@yahoogroups.com
Reply To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Very granular restriction requested
So let's talk about asset downtime.
We have a subset of staff that will take service requests, tickets, and that sort of stuff. Occassionally, a user in that role will get a report of equipment down. I want to allow that user to report downtime, and only report downtime, for an asset.
However, in looking at secGroups, I can allow READ access to assets but that is insufficient. Makes sense, I need to write to assetstatus and the Asset app controls this. I allow SAVE and yes, now I can allow users to report downtime.
And edit fields. Wait, I don't want that to happen. I just want to allow access to one "Select Action" entry.
Question to the group: how can I do this? I'll take all the possible methods the group can conceive.
-C
When we were working this out the issue quickly became a question of process. We use Maximo as more for maintenance tracking than production tracking and we quickly found the ~gray~ user looking to record asset downtime for non-maintenance issues. We are using this for determining the need to increase or replace assets that are incapable of maintaining current production levels.
Because of the inability to keep these users from recording non-production maintenance issues without requiring constant extensive data reviews, we left it as downtime recording is only completed in Work Order application linked to the SR or in asset application itself which is even under stricter restrictions.
Roy Cline
Phone: (203) 492-8189
Cell: (203) 640-9743
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Friday, January 09, 2015 10:28 AM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Very granular restriction requested
So let's talk about asset downtime.
We have a subset of staff that will take service requests, tickets, and that sort of stuff. Occassionally, a user in that role will get a report of equipment down. I want to allow that user to report downtime, and only report downtime, for an asset.
However, in looking at secGroups, I can allow READ access to assets but that is insufficient. Makes sense, I need to write to assetstatus and the Asset app controls this. I allow SAVE and yes, now I can allow users to report downtime.
And edit fields. Wait, I don't want that to happen. I just want to allow access to one "Select Action" entry.
Question to the group: how can I do this? I'll take all the possible methods the group can conceive.
-C
Create a security group and grant access to Assets. Use 'Data Restrictions > Attribute Restrictions' within the security application to restrict all fields to be 'Read-only'.Add users that you wish to be able to report downtime to this group. Pat Morrow
pmorrow8@yahoo.com
From: "maximal@wanko.com [MAXIMO]" <MAXIMO@yahoogroups.com>
To: MAXIMO@yahoogroups.com
Sent: Friday, January 9, 2015 8:27 AM
Subject: [MAXIMO List] Very granular restriction requested
So let's talk about asset downtime.
We have a subset of staff that will take service requests, tickets, and that sort of stuff. Occassionally, a user in that role will get a report of equipment down. I want to allow that user to report downtime, and only report downtime, for an asset.
However, in looking at secGroups, I can allow READ access to assets but that is insufficient. Makes sense, I need to write to assetstatus and the Asset app controls this. I allow SAVE and yes, now I can allow users to report downtime.
And edit fields. Wait, I don't want that to happen. I just want to allow access to one "Select Action" entry.
Question to the group: how can I do this? I'll take all the possible methods the group can conceive.
-C
#yiv6265477937 #yiv6265477937 -- #yiv6265477937ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6265477937 #yiv6265477937ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6265477937 #yiv6265477937ygrp-mkp #yiv6265477937hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6265477937 #yiv6265477937ygrp-mkp #yiv6265477937ads {margin-bottom:10px;}#yiv6265477937 #yiv6265477937ygrp-mkp .yiv6265477937ad {padding:0 0;}#yiv6265477937 #yiv6265477937ygrp-mkp .yiv6265477937ad p {margin:0;}#yiv6265477937 #yiv6265477937ygrp-mkp .yiv6265477937ad a {color:#0000ff;text-decoration:none;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ygrp-lc {font-family:Arial;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ygrp-lc #yiv6265477937hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ygrp-lc .yiv6265477937ad {margin-bottom:10px;padding:0 0;}#yiv6265477937 #yiv6265477937actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6265477937 #yiv6265477937activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6265477937 #yiv6265477937activity span {font-weight:700;}#yiv6265477937 #yiv6265477937activity span:first-child {text-transform:uppercase;}#yiv6265477937 #yiv6265477937activity span a {color:#5085b6;text-decoration:none;}#yiv6265477937 #yiv6265477937activity span span {color:#ff7900;}#yiv6265477937 #yiv6265477937activity span .yiv6265477937underline {text-decoration:underline;}#yiv6265477937 .yiv6265477937attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv6265477937 .yiv6265477937attach div a {text-decoration:none;}#yiv6265477937 .yiv6265477937attach img {border:none;padding-right:5px;}#yiv6265477937 .yiv6265477937attach label {display:block;margin-bottom:5px;}#yiv6265477937 .yiv6265477937attach label a {text-decoration:none;}#yiv6265477937 blockquote {margin:0 0 0 4px;}#yiv6265477937 .yiv6265477937bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv6265477937 .yiv6265477937bold a {text-decoration:none;}#yiv6265477937 dd.yiv6265477937last p a {font-family:Verdana;font-weight:700;}#yiv6265477937 dd.yiv6265477937last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6265477937 dd.yiv6265477937last p span.yiv6265477937yshortcuts {margin-right:0;}#yiv6265477937 div.yiv6265477937attach-table div div a {text-decoration:none;}#yiv6265477937 div.yiv6265477937attach-table {width:400px;}#yiv6265477937 div.yiv6265477937file-title a, #yiv6265477937 div.yiv6265477937file-title a:active, #yiv6265477937 div.yiv6265477937file-title a:hover, #yiv6265477937 div.yiv6265477937file-title a:visited {text-decoration:none;}#yiv6265477937 div.yiv6265477937photo-title a, #yiv6265477937 div.yiv6265477937photo-title a:active, #yiv6265477937 div.yiv6265477937photo-title a:hover, #yiv6265477937 div.yiv6265477937photo-title a:visited {text-decoration:none;}#yiv6265477937 div#yiv6265477937ygrp-mlmsg #yiv6265477937ygrp-msg p a span.yiv6265477937yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv6265477937 .yiv6265477937green {color:#628c2a;}#yiv6265477937 .yiv6265477937MsoNormal {margin:0 0 0 0;}#yiv6265477937 o {font-size:0;}#yiv6265477937 #yiv6265477937photos div {float:left;width:72px;}#yiv6265477937 #yiv6265477937photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv6265477937 #yiv6265477937photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv6265477937 #yiv6265477937reco-category {font-size:77%;}#yiv6265477937 #yiv6265477937reco-desc {font-size:77%;}#yiv6265477937 .yiv6265477937replbq {margin:4px;}#yiv6265477937 #yiv6265477937ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv6265477937 #yiv6265477937ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv6265477937 #yiv6265477937ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv6265477937 #yiv6265477937ygrp-mlmsg select, #yiv6265477937 input, #yiv6265477937 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv6265477937 #yiv6265477937ygrp-mlmsg pre, #yiv6265477937 code {font:115% monospace;}#yiv6265477937 #yiv6265477937ygrp-mlmsg * {line-height:1.22em;}#yiv6265477937 #yiv6265477937ygrp-mlmsg #yiv6265477937logo {padding-bottom:10px;}#yiv6265477937 #yiv6265477937ygrp-msg p a {font-family:Verdana;}#yiv6265477937 #yiv6265477937ygrp-msg p#yiv6265477937attach-count span {color:#1E66AE;font-weight:700;}#yiv6265477937 #yiv6265477937ygrp-reco #yiv6265477937reco-head {color:#ff7900;font-weight:700;}#yiv6265477937 #yiv6265477937ygrp-reco {margin-bottom:20px;padding:0px;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ov li a {font-size:130%;text-decoration:none;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv6265477937 #yiv6265477937ygrp-sponsor #yiv6265477937ov ul {margin:0;padding:0 0 0 8px;}#yiv6265477937 #yiv6265477937ygrp-text {font-family:Georgia;}#yiv6265477937 #yiv6265477937ygrp-text p {margin:0 0 1em 0;}#yiv6265477937 #yiv6265477937ygrp-text tt {font-size:120%;}#yiv6265477937 #yiv6265477937ygrp-vital ul li:last-child {border-right:none !important;}#yiv6265477937
First order of business: thank you for all the replies.
Next order of business: justification for the requirement.
I realize that my set of users can report downtime from workorders already, without any additional gyrations and yes, I agree completely that this is the best solution for most cases.
Here's the edge case. Suppose you have a piece of equipment, such as an escalator, that can be tripped "off" as a safety feature. Jam your sneaker at the top of an escalator briefly, and you can trip one yourself (as well as yourself!) Now, the escalator is down, and SCADA may even tell your operations desk this fact. Oops. Now what? Well, dispatch someone nearby on staff to perform a reset, after inspecting the escalator for any visible conditions that may prevent a reset. Say this user successfully resets the escalator, and reports it as such.
Did we need a workorder? No, we did not. Did we need a service request? Yes, we had an event that needed to be tracked. Did we have downtime? Oh yes, certainly. We know the start, and the finish.
That's my edge case.
I'll look at all of the provided options, including scripting (but that will be my last resort) and see what appears to fit. Any other ideas, please let me know!
-C
If asset linked in the SR then downtime could be associated simply from the timings of the SR. Created time, reported time, response time, resolution etc.
Asset management would then regularly see SR reports and can manually do actual asset downtime based on info from SR
Or bring the asset downtime in to the SR when you select the asset the SR handler can indicate downtime without needing to go to asset application
Sent from my iPad
> On 9 Jan 2015, at 18:59, maximal@wanko.com [MAXIMO] <MAXIMO@yahoogroups.com> wrote:
>
> First order of business: thank you for all the replies.
>
> Next order of business: justification for the requirement.
>
> I realize that my set of users can report downtime from workorders already, without any additional gyrations and yes, I agree completely that this is the best solution for most cases.
>
> Here's the edge case. Suppose you have a piece of equipment, such as an escalator, that can be tripped "off" as a safety feature. Jam your sneaker at the top of an escalator briefly, and you can trip one yourself (as well as yourself!) Now, the escalator is down, and SCADA may even tell your operations desk this fact. Oops. Now what? Well, dispatch someone nearby on staff to perform a reset, after inspecting the escalator for any visible conditions that may prevent a reset. Say this user successfully resets the escalator, and reports it as such.
>
> Did we need a workorder? No, we did not. Did we need a service request? Yes, we had an event that needed to be tracked. Did we have downtime? Oh yes, certainly. We know the start, and the finish.
>
> That's my edge case.
>
>
> I'll look at all of the provided options, including scripting (but that will be my last resort) and see what appears to fit. Any other ideas, please let me know!
>
> -C
>
>
>
>
Philosophically, I'd say that this use case does represent a work order,
with a non-relevant critical failure. You've got an asset that's down, and
that will remain down until it receives a maintenance touch. Your P/C/R
hierarchy should include entries for, say, in-op general/tripped
safety/performed reset. Even though that action requires no parts and
little time, it does require a technician, a dispatch, and some degree of
travel time, all of which have costs, and does represent an opportunity
cost as that technician is unavailable to perform other work. It's also
valuable to track trending data on this type of non-relevant critical
failure, as it may lead to better human factors design, adjusting signage,
access, or design to make an event that would trip the safety less likely
to occur.
I will say that I'm with John Reeve in that the only time I've ever gotten
consistent downtime reporting was when I scrapped the click-driven downtime
reporting, built downtime tracking fields into the workorder and asset
tables, and built workflow actions or automation scripts to automate
downtime reporting.
Chris McClinch
On Fri, Jan 9, 2015 at 1:59 PM, maximal@wanko.com [MAXIMO] <
MAXIMO@yahoogroups.com> wrote:
>
>
> First order of business: thank you for all the replies.
>
> Next order of business: justification for the requirement.
>
> I realize that my set of users can report downtime from workorders
> already, without any additional gyrations and yes, I agree completely that
> this is the best solution for most cases.
>
> Here's the edge case. Suppose you have a piece of equipment, such as an
> escalator, that can be tripped "off" as a safety feature. Jam your sneaker
> at the top of an escalator briefly, and you can trip one yourself (as well
> as yourself!) Now, the escalator is down, and SCADA may even tell your
> operations desk this fact. Oops. Now what? Well, dispatch someone nearby on
> staff to perform a reset, after inspecting the escalator for any visible
> conditions that may prevent a reset. Say this user successfully resets the
> escalator, and reports it as such.
>
> Did we need a workorder? No, we did not. Did we need a service request?
> Yes, we had an event that needed to be tracked. Did we have downtime? Oh
> yes, certainly. We know the start, and the finish.
>
> That's my edge case.
>
>
> I'll look at all of the provided options, including scripting (but that
> will be my last resort) and see what appears to fit. Any other ideas,
> please let me know!
>
> -C
>
>
>
>
>
---In MAXIMO@yahoogroups.com, <chris.mcclinch@gmail.com> wrote :
Philosophically, I'd say that this use case does represent a work order,
with a non-relevant critical failure. You've got an asset that's down, and
that will remain down until it receives a maintenance touch. Your P/C/R
hierarchy should include entries for, say, in-op general/tripped
safety/performed reset. Even though that action requires no parts and
little time, it does require a technician, a dispatch, and some degree of
travel time, all of which have costs, and does represent an opportunity
cost as that technician is unavailable to perform other work.
<snip>
You're shoving the use case into your workorder container, and not modeling the actual business case presented.
Calls come in, regardless of whether it results in rolling a truck or not. So, we always start with SRs. Next, we have an action to be tracked, performed by a non-technician entity. This entity is already on-site in a customer service capacity. Think, an extension of your service desk. Again, no truck is rolling, no technician, no tools. We're still not across the workorder threshold.
Customer service desk talks to customer service agent, and the agent can reset an escalator. I'm still not seeing a compelling reason to open a workorder, especially if the reset works. An SR captures the event, the downtime is reported correctly against the correct asset, so what's the workorder buying me? That on-site customer service agent gets paid the same to reset escalators or help old ladies across the street.
-C
You can add a Button (quick link) for 'Report Downtime' to the SR this would allow for recording the asset downtime from the SR application. I created a similar button on the work order application because the users were 'forgetting' to add the downtime if it was not right in their field of view.
Roy Cline
Phone: (203) 492-8189
Cell: (203) 640-9743
FAX: (203) 492-8462
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Friday, January 09, 2015 2:00 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Re: Very granular restriction requested
First order of business: thank you for all the replies.
Next order of business: justification for the requirement.
I realize that my set of users can report downtime from workorders already, without any additional gyrations and yes, I agree completely that this is the best solution for most cases.
Here's the edge case. Suppose you have a piece of equipment, such as an escalator, that can be tripped "off" as a safety feature. Jam your sneaker at the top of an escalator briefly, and you can trip one yourself (as well as yourself!) Now, the escalator is down, and SCADA may even tell your operations desk this fact. Oops. Now what? Well, dispatch someone nearby on staff to perform a reset, after inspecting the escalator for any visible conditions that may prevent a reset. Say this user successfully resets the escalator, and reports it as such.
Did we need a workorder? No, we did not. Did we need a service request? Yes, we had an event that needed to be tracked. Did we have downtime? Oh yes, certainly. We know the start, and the finish.
That's my edge case.
I'll look at all of the provided options, including scripting (but that will be my last resort) and see what appears to fit. Any other ideas, please let me know!
-C
> You can add a Button (quick link) for 'Report Downtime' to the SR this would allow for recording the asset downtime from the SR application. I created a similar button on the work order application because the users were 'forgetting' to add the downtime if it was not right in their field of view.
That's my inclination as well: I'd rather bring that "Report Downtime"
function to the SR and have it work same as Work Order Tracking. I
get everything.
-C