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.
Hi guys: is anyone using Condition Codes for Rotating Assets? If so, what
is your process and setup? We've been having some challenges with our
rotating assets (to put it mildly!), and are looking for ideas. Up to this
point, we haven't utilized the condition codes, but we're thinking of doing
so.
Thanks in advance.
Shannon Rotz
IBM Certified Deployment Professional
IBM Certified Solution Advisor
Maximo Asset Management V7.1, 7.5
InComm Solutions Inc.
incomm@shaw.ca
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
--Hi guys: is anyone using Condition Codes for Rotating Assets? If so, what
--is your process and setup? We've been having some challenges with our
--rotating assets (to put it mildly!), and are looking for ideas. Up to this
--point, we haven't utilized the condition codes, but we're thinking of doing
--so.
What's the intention, to change a chargeback rate on condition, or trigger replacement? Just curious, as I'd like to know how you set it up when you get there.
-C
Subject: capture Condition of Asset via "condition codes".
This is my interpretation of question. If correct, why limit to only ROTABLE assets?
I would add new fields if necessary to capture numerical grade as observed by technician doing scheduled inspection. This data could be stored in meters and provide trending.
Does this idea make sense?
Sent from my iPhone
> On Dec 7, 2015, at 8:08 AM, maximal@wanko.com [MAXIMO] <MAXIMO@yahoogroups.com> wrote:
>
> ---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
> --Hi guys: is anyone using Condition Codes for Rotating Assets? If so, what
> --is your process and setup? We've been having some challenges with our
> --rotating assets (to put it mildly!), and are looking for ideas. Up to this
> --point, we haven't utilized the condition codes, but we're thinking of doing
> --so.
>
>
> What's the intention, to change a chargeback rate on condition, or trigger replacement? Just curious, as I'd like to know how you set it up when you get there.
>
>
> -C
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Have to think about that one, John – you came from an unexpected angle on it.
We’re using condition codes for other repairables, just not for rotables. The original reason for that was because we were finding the process complicated already, and didn’t want to add more complexity. However, I’m revisiting that decision since so far none of my attempts to streamline the process and make it easier for the users has worked.
Shannon
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Monday, December 7, 2015 8:09 AM
To: MAXIMO@yahoogroups.com
Subject: Re: [MAXIMO List] Re: Rotating Assets - Condition Codes
Subject: capture Condition of Asset via "condition codes".
This is my interpretation of question. If correct, why limit to only ROTABLE assets?
I would add new fields if necessary to capture numerical grade as observed by technician doing scheduled inspection. This data could be stored in meters and provide trending.
Does this idea make sense?
Sent from my iPhone
> On Dec 7, 2015, at 8:08 AM, maximal@wanko.com [MAXIMO] <MAXIMO@yahoogroups.com> wrote:
>
> ---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
> --Hi guys: is anyone using Condition Codes for Rotating Assets? If so, what
> --is your process and setup? We've been having some challenges with our
> --rotating assets (to put it mildly!), and are looking for ideas. Up to this
> --point, we haven't utilized the condition codes, but we're thinking of doing
> --so.
>
>
> What's the intention, to change a chargeback rate on condition, or trigger replacement? Just curious, as I'd like to know how you set it up when you get there.
>
>
> -C
>
>
>
>
>
>
>
>
>
>
>
>
>
>
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
--We’re using condition codes for other repairables, just not for rotables. The original reason for that was
--because we were finding the process complicated already, and didn’t want to add more complexity.
--However, I’m revisiting that decision since so far none of my attempts to streamline the process and make
--it easier for the users has worked.
What is your process? Can you bullet it out?
-C
OK – just remember, you asked :)
1. Create work order for initial swapout, preferably with reservation for replacement item/asset (Planner)
2. Issue replacement item/asset to swapout work order (Inventory)
3. Move broken asset to Repair location (asset technician)
4. Internal repair:
4a. Create second work order for asset at repair location, for repair (trade lead or repair shop foreman, depending on site) (“Charge to Store” flag is on, since it’s a repair location)
4b. Plan and approve second repair work order (planner, approver)
4c. Perform work (trades)
4d. Report labor hours (trade lead)
4e. Complete work order (trade lead, I think)
4f. Close work order (?? One of our remaining challenges, since this is usually automated)
4g. Inform asset technician that work order is closed (can be automated – currently a problem)
5. External repair:
5a. Create manual PR for service to send asset to vendor for repair. (No item number – service line is charged directly to the asset, which automatically puts the flag on “Charge to Store”) (Inventory)
5b. Create PO for service (Procurement)
5c. Receive repaired item/asset (Receiver)
5d. Wait for invoice to be received and processed (Notification of invoice processing will be automated – currently it’s a manual check)
5e. Close PO (Procurement)
5f. Inform asset technician that PO is closed (can be automated)
6. Move asset from repair location back to storeroom (asset technician)
Two main problems:
7. As you can see, there are a LOT of people involved, and a lot of steps. They all need to be done in the correct order for this to work. Since that only happens on a lucky day, I spend a lot of time troubleshooting.
8. Asset cannot be moved back to storeroom until the work order or PO is CLOSED, due to the way the accounting works. Without closure of the PO or work order BEFORE the move, the costs do not get transferred correctly to the storeroom.
This is based on the accounting requirement that the repair costs be charged to the storeroom. We’re currently reviewing that requirement, since it doesn’t capture core value anyway.
Shannon
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Wednesday, December 9, 2015 4:38 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Rotating Assets - Condition Codes
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
--We’re using condition codes for other repairables, just not for rotables. The original reason for that was
--because we were finding the process complicated already, and didn’t want to add more complexity.
--However, I’m revisiting that decision since so far none of my attempts to streamline the process and make
--it easier for the users has worked.
What is your process? Can you bullet it out?
-C
That's a pretty straightforward process.
I'm not sure there too many people in the process, seems appropriate to me.
1) WO creation is necessary;
2) issue is necessary (unless you have maintenance grabbing their own things);
3) returning broken assets is necessary;
4) 2nd WO is necessary ... follow-up work or children, or a true standalone? I would probably link it. Is there a reason why that wouldn't be the policy? Not sure why 4f and 4g are problems, sounds like a people issue.
5) PR, PO, invoicing, receipts all normal, not seeing bloat here either.
6) Asset move is necessary
For sure a workflow isn't going to keep track of the orchestration, or can it? I think for certain WOs you can "trip" a workflow flag to indicate special status, and keep the WO the primary linkage for all coordinated events.
Point 8), all true, but I wonder what circumstances reasonably prohibit POs from not closing. If you receive, but no invoice is available, do you just hold the goods at the dock? Would you return them? I don't think so, I think you have some latitude here.
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
OK – just remember, you asked :)
1. Create work order for initial swapout, preferably with reservation for replacement item/asset (Planner)
2. Issue replacement item/asset to swapout work order (Inventory)
3. Move broken asset to Repair location (asset technician)
4. Internal repair:
4a. Create second work order for asset at repair location, for repair (trade lead or repair shop foreman, depending on site) (“Charge to Store” flag is on, since it’s a repair location)
4b. Plan and approve second repair work order (planner, approver)
4c. Perform work (trades)
4d. Report labor hours (trade lead)
4e. Complete work order (trade lead, I think)
4f. Close work order (?? One of our remaining challenges, since this is usually automated)
4g. Inform asset technician that work order is closed (can be automated – currently a problem)
5. External repair:
5a. Create manual PR for service to send asset to vendor for repair. (No item number – service line is charged directly to the asset, which automatically puts the flag on “Charge to Store”) (Inventory)
5b. Create PO for service (Procurement)
5c. Receive repaired item/asset (Receiver)
5d. Wait for invoice to be received and processed (Notification of invoice processing will be automated – currently it’s a manual check)
5e. Close PO (Procurement)
5f. Inform asset technician that PO is closed (can be automated)
6. Move asset from repair location back to storeroom (asset technician)
Two main problems:
7. As you can see, there are a LOT of people involved, and a lot of steps. They all need to be done in the correct order for this to work. Since that only happens on a lucky day, I spend a lot of time troubleshooting.
8. Asset cannot be moved back to storeroom until the work order or PO is CLOSED, due to the way the accounting works. Without closure of the PO or work order BEFORE the move, the costs do not get transferred correctly to the storeroom.
This is based on the accounting requirement that the repair costs be charged to the storeroom. We’re currently reviewing that requirement, since it doesn’t capture core value anyway.
Good feedback on the process, Chris – my user keep telling me that it’s too cumbersome/complex, but if you’re seeing this otherwise from the outside, maybe we should be adjusting our mindset.
Most likely one of the core problems is that we have a role/responsibility breakdown which says that all Asset moves need to be done by the Asset technician, who is not involved in the physical process. So this adds a layer of communication that doesn’t necessarily need to be there if the Inventory Techs and/or the Planners did the asset moves. However, I’m intending to add some escalation notifications/workflow assignments that should help with that.
The problem with the PO is that Maximo won’t allow the invoice to be entered after it’s closed. So this actually does force us to wait for something that’s outside our control (the vendor sending the invoice). I understand why Maximo has that requirement, though, since the system doesn’t know what the final repair costs are until that PO (or work order) is closed.
I’m trying a couple of other ideas on how to do this, which should be interesting to spec out.
Shannon
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Thursday, December 10, 2015 9:14 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Rotating Assets - Condition Codes
That's a pretty straightforward process.
I'm not sure there too many people in the process, seems appropriate to me.
1) WO creation is necessary;
2) issue is necessary (unless you have maintenance grabbing their own things);
3) returning broken assets is necessary;
4) 2nd WO is necessary ... follow-up work or children, or a true standalone? I would probably link it. Is there a reason why that wouldn't be the policy? Not sure why 4f and 4g are problems, sounds like a people issue.
5) PR, PO, invoicing, receipts all normal, not seeing bloat here either.
6) Asset move is necessary
For sure a workflow isn't going to keep track of the orchestration, or can it? I think for certain WOs you can "trip" a workflow flag to indicate special status, and keep the WO the primary linkage for all coordinated events.
Point 8), all true, but I wonder what circumstances reasonably prohibit POs from not closing. If you receive, but no invoice is available, do you just hold the goods at the dock? Would you return them? I don't think so, I think you have some latitude here.
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
OK – just remember, you asked :)
1. Create work order for initial swapout, preferably with reservation for replacement item/asset (Planner)
2. Issue replacement item/asset to swapout work order (Inventory)
3. Move broken asset to Repair location (asset technician)
4. Internal repair:
4a. Create second work order for asset at repair location, for repair (trade lead or repair shop foreman, depending on site) (“Charge to Store” flag is on, since it’s a repair location)
4b. Plan and approve second repair work order (planner, approver)
4c. Perform work (trades)
4d. Report labor hours (trade lead)
4e. Complete work order (trade lead, I think)
4f. Close work order (?? One of our remaining challenges, since this is usually automated)
4g. Inform asset technician that work order is closed (can be automated – currently a problem)
5. External repair:
5a. Create manual PR for service to send asset to vendor for repair. (No item number – service line is charged directly to the asset, which automatically puts the flag on “Charge to Store”) (Inventory)
5b. Create PO for service (Procurement)
5c. Receive repaired item/asset (Receiver)
5d. Wait for invoice to be received and processed (Notification of invoice processing will be automated – currently it’s a manual check)
5e. Close PO (Procurement)
5f. Inform asset technician that PO is closed (can be automated)
6. Move asset from repair location back to storeroom (asset technician)
Two main problems:
7. As you can see, there are a LOT of people involved, and a lot of steps. They all need to be done in the correct order for this to work. Since that only happens on a lucky day, I spend a lot of time troubleshooting.
8. Asset cannot be moved back to storeroom until the work order or PO is CLOSED, due to the way the accounting works. Without closure of the PO or work order BEFORE the move, the costs do not get transferred correctly to the storeroom.
This is based on the accounting requirement that the repair costs be charged to the storeroom. We’re currently reviewing that requirement, since it doesn’t capture core value anyway.
>> Good feedback on the process, Chris – my user keep telling me that it’s too cumbersome/complex, but if
>> you’re seeing this otherwise from the outside, maybe we should be adjusting our mindset.
You're welcome. I always like to look at process.
>> Most likely one of the core problems is that we have a role/responsibility breakdown which says that all
>> Asset moves need to be done by the Asset technician, who is not involved in the physical process. So
>> this adds a layer of communication that doesn’t necessarily need to be there if the Inventory Techs and/or
>> the Planners did the asset moves. However, I’m intending to add some escalation notifications/workflow
>> assignments that should help with that.
The key issue with asset moves is just the "who moved my cheese?" scenario. If you are notifying people, you can keep the asset moves with the same person doing issues, transfers, and so on. They do this at Bombardier JFK with their storeroom attendants.
>> The problem with the PO is that Maximo won’t allow the invoice to be entered after it’s closed. So this
>> actually does force us to wait for something that’s outside our control (the vendor sending the invoice). I
>> understand why Maximo has that requirement, though, since the system doesn’t know what the final
>> repair costs are until that PO (or work order) is closed.
This reminded me of an article on this topic I once read about reducing this complexity, dramatically. In it, the author stated a policy by which they paid the PO amount, not the invoiced amount. Basically they said "you can invoice us all you want, we're tossing it in the trash. We negotiated to and agreed to a price, and that's what we're paying." They tried it for several months, and they had more success than they expected with it. It made paperwork easier. I don't remember how they handled shipping.
The point I'm making though is that invoicing is bullshit. What is needed is a mechanism to allow for PO closure and invoice tolerance. But, another day.
-C
Omigosh. Here, here!
This pay on receipt principle was demo’d at our first Ontario CanMUG meeting. Very sexy.
I checked with my people when I returned to learn how many of them ever adjusted an invoice. (Never.)
Can’t believe the invoicing process has been such a [almost] universal holdout.
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Friday, December 11, 2015 11:37 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Rotating Assets - Condition Codes
>> Good feedback on the process, Chris – my user keep telling me that it’s too cumbersome/complex, but if
>> you’re seeing this otherwise from the outside, maybe we should be adjusting our mindset.
You're welcome. I always like to look at process.
>> Most likely one of the core problems is that we have a role/responsibility breakdown which says that all
>> Asset moves need to be done by the Asset technician, who is not involved in the physical process. So
>> this adds a layer of communication that doesn’t necessarily need to be there if the Inventory Techs and/or
>> the Planners did the asset moves. However, I’m intending to add some escalation notifications/workflow
>> assignments that should help with that.
The key issue with asset moves is just the "who moved my cheese?" scenario. If you are notifying people, you can keep the asset moves with the same person doing issues, transfers, and so on. They do this at Bombardier JFK with their storeroom attendants.
>> The problem with the PO is that Maximo won’t allow the invoice to be entered after it’s closed. So this
>> actually does force us to wait for something that’s outside our control (the vendor sending the invoice). I
>> understand why Maximo has that requirement, though, since the system doesn’t know what the final
>> repair costs are until that PO (or work order) is closed.
This reminded me of an article on this topic I once read about reducing this complexity, dramatically. In it, the author stated a policy by which they paid the PO amount, not the invoiced amount. Basically they said "you can invoice us all you want, we're tossing it in the trash. We negotiated to and agreed to a price, and that's what we're paying." They tried it for several months, and they had more success than they expected with it. It made paperwork easier. I don't remember how they handled shipping.
The point I'm making though is that invoicing is bullshit. What is needed is a mechanism to allow for PO closure and invoice tolerance. But, another day.
-C
>>Omigosh. Here, here!
>>This pay on receipt principle was demo’d at our first Ontario CanMUG meeting. Very sexy.
>>I checked with my people when I returned to learn how many of them ever adjusted an invoice. (Never.)
>>Can’t believe the invoicing process has been such a [almost] universal holdout.
I think it's the Evaluated Receipt Settlement. I like it because it moves all of that ticky-tack fee garbage out of the everyday. You can probably settle shipping and other things outside of this with far less paperwork. It would also encourage suppliers to list a single price and have their shipping costs factored in.
-C