Maximo List Archive

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.



Meter-Based PMs - Average Units per Day

From: incomm (2015-02-12 15:48)


HI guys: anyone using the Average Units per Day for their Meter-based PMs? If so, what version are you on and is it working? We're finding that it's broken in 7.5.

TIA



Shannon Rotz


From: swkim (2015-02-16 09:10)

Can you explain what you mean by broken? How are you calculating Avg per Day. I believe there are at least 3 different methods in Maximo 7.5. What are you expecting the results to be and what are you seeing instead? What you already tried to understand or fix the issue?


From: Incomm Solutions Inc. (2015-02-17 08:24)

When we upgraded to 7.5, the Average Units per Day just didn't work, period.
Even with the "Do Not Estimate" flag off, it behaved as if the flag was on.
(BTW: use Target Start Date is off as well; we use a floating PM schedule).
We opened a PMR, and after a while IBM said that yes, we were correct, the
Average Units per Day wasn't working, and said it would be fixed in 7.5.0.6.

Well, after moving from 7.5.0.4 to 7.5.0.6, when we took the "Do Not
Estimate" flag off, all our PM work orders started coming out early. From
what I can tell, Maximo is now using the following calculation:

- {Life to Date Meter Reading at Last Work Order Completion} +
Frequency = {Life to Date Meter Reading at Next Work Order}

- {Life to Date Meter Reading at Next Work Order} - {Current Meter
Reading} = {Units to Go}

The above calculations are fine, but:

- {Last Completion Date} + {Units to Go}/{Average Units per Day} =
{Estimated Next Due Date}

The problem with the last calculation is that by definition, the Units to Go
at the Last Completion Date are equal to the full frequency.(!)

I'm just confirming my diagnosis with IBM now, but the work orders that came
out early were totally consistent with this formula.

I figured we couldn't be the only ones still trying to use Average Units per
Day for our PMs - hence the question on the newsgroup.



Shannon Rotz



From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: February-16-15 9:10 AM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Re: Meter-Based PMs - Average Units per Day


Can you explain what you mean by broken? How are you calculating Avg per
Day. I believe there are at least 3 different methods in Maximo 7.5. What
are you expecting the results to be and what are you seeing instead? What
you already tried to understand or fix the issue?


From: swkim (2015-02-18 08:57)

In Assets, I can configure Average Per Day: http://i.imgur.com/BVCozUd.png http://i.imgur.com/BVCozUd.png

http://i.imgur.com/BVCozUd.png

http://i.imgur.com/BVCozUd.png http://i.imgur.com/BVCozUd.png


View on i.imgur.com http://i.imgur.com/BVCozUd.png
Preview by Yahoo




The average is what gets passed to the PM module.

http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png

http://i.imgur.com/vqrsuu4.png

http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png


View on i.imgur.com http://i.imgur.com/vqrsuu4.png
Preview by Yahoo



This is strange that it is not working for you.

I know we ran into a bug where if we duplicated assets the meters types associated would clone as well, but the actual asset number it was associated to would not change. So, the PM triggers behaved oddly. It would generate PMs early because the asset number for the meter was wrong so it triggered on another asset's due date. (Hope that makes sense).



From: Basant M Kumar (2015-02-18 19:21)

Call me as I do not have specific set of questions? I can tell you on how to work aroun  workflow.
Thanks,
 Basant M Kumar

From: "swkim@getty.edu [MAXIMO]" <MAXIMO@yahoogroups.com>
To: MAXIMO@yahoogroups.com
Sent: Wednesday, February 18, 2015 10:57 AM
Subject: RE: [MAXIMO List] Re: Meter-Based PMs - Average Units per Day

  In Assets, I can configure Average Per Day: http://i.imgur.com/BVCozUd.png http://i.imgur.com/BVCozUd.png

http://i.imgur.com/BVCozUd.png

http://i.imgur.com/BVCozUd.png http://i.imgur.com/BVCozUd.png


View on i.imgur.com http://i.imgur.com/BVCozUd.png
Preview by Yahoo




The average is what gets passed to the PM module.

http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png

http://i.imgur.com/vqrsuu4.png

http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png


View on i.imgur.com http://i.imgur.com/vqrsuu4.png
Preview by Yahoo



This is strange that it is not working for you.

I know we ran into a bug where if we duplicated assets the meters types associated would clone as well, but the actual asset number it was associated to would not change. So, the PM triggers behaved oddly. It would generate PMs early because the asset number for the meter was wrong so it triggered on another asset's due date. (Hope that makes sense).


#yiv3052580932 #yiv3052580932 -- #yiv3052580932ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3052580932 #yiv3052580932ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3052580932 #yiv3052580932ygrp-mkp #yiv3052580932hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3052580932 #yiv3052580932ygrp-mkp #yiv3052580932ads {margin-bottom:10px;}#yiv3052580932 #yiv3052580932ygrp-mkp .yiv3052580932ad {padding:0 0;}#yiv3052580932 #yiv3052580932ygrp-mkp .yiv3052580932ad p {margin:0;}#yiv3052580932 #yiv3052580932ygrp-mkp .yiv3052580932ad a {color:#0000ff;text-decoration:none;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ygrp-lc {font-family:Arial;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ygrp-lc #yiv3052580932hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ygrp-lc .yiv3052580932ad {margin-bottom:10px;padding:0 0;}#yiv3052580932 #yiv3052580932actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3052580932 #yiv3052580932activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3052580932 #yiv3052580932activity span {font-weight:700;}#yiv3052580932 #yiv3052580932activity span:first-child {text-transform:uppercase;}#yiv3052580932 #yiv3052580932activity span a {color:#5085b6;text-decoration:none;}#yiv3052580932 #yiv3052580932activity span span {color:#ff7900;}#yiv3052580932 #yiv3052580932activity span .yiv3052580932underline {text-decoration:underline;}#yiv3052580932 .yiv3052580932attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3052580932 .yiv3052580932attach div a {text-decoration:none;}#yiv3052580932 .yiv3052580932attach img {border:none;padding-right:5px;}#yiv3052580932 .yiv3052580932attach label {display:block;margin-bottom:5px;}#yiv3052580932 .yiv3052580932attach label a {text-decoration:none;}#yiv3052580932 blockquote {margin:0 0 0 4px;}#yiv3052580932 .yiv3052580932bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3052580932 .yiv3052580932bold a {text-decoration:none;}#yiv3052580932 dd.yiv3052580932last p a {font-family:Verdana;font-weight:700;}#yiv3052580932 dd.yiv3052580932last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3052580932 dd.yiv3052580932last p span.yiv3052580932yshortcuts {margin-right:0;}#yiv3052580932 div.yiv3052580932attach-table div div a {text-decoration:none;}#yiv3052580932 div.yiv3052580932attach-table {width:400px;}#yiv3052580932 div.yiv3052580932file-title a, #yiv3052580932 div.yiv3052580932file-title a:active, #yiv3052580932 div.yiv3052580932file-title a:hover, #yiv3052580932 div.yiv3052580932file-title a:visited {text-decoration:none;}#yiv3052580932 div.yiv3052580932photo-title a, #yiv3052580932 div.yiv3052580932photo-title a:active, #yiv3052580932 div.yiv3052580932photo-title a:hover, #yiv3052580932 div.yiv3052580932photo-title a:visited {text-decoration:none;}#yiv3052580932 div#yiv3052580932ygrp-mlmsg #yiv3052580932ygrp-msg p a span.yiv3052580932yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3052580932 .yiv3052580932green {color:#628c2a;}#yiv3052580932 .yiv3052580932MsoNormal {margin:0 0 0 0;}#yiv3052580932 o {font-size:0;}#yiv3052580932 #yiv3052580932photos div {float:left;width:72px;}#yiv3052580932 #yiv3052580932photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv3052580932 #yiv3052580932photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3052580932 #yiv3052580932reco-category {font-size:77%;}#yiv3052580932 #yiv3052580932reco-desc {font-size:77%;}#yiv3052580932 .yiv3052580932replbq {margin:4px;}#yiv3052580932 #yiv3052580932ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv3052580932 #yiv3052580932ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3052580932 #yiv3052580932ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3052580932 #yiv3052580932ygrp-mlmsg select, #yiv3052580932 input, #yiv3052580932 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv3052580932 #yiv3052580932ygrp-mlmsg pre, #yiv3052580932 code {font:115% monospace;}#yiv3052580932 #yiv3052580932ygrp-mlmsg * {line-height:1.22em;}#yiv3052580932 #yiv3052580932ygrp-mlmsg #yiv3052580932logo {padding-bottom:10px;}#yiv3052580932 #yiv3052580932ygrp-msg p a {font-family:Verdana;}#yiv3052580932 #yiv3052580932ygrp-msg p#yiv3052580932attach-count span {color:#1E66AE;font-weight:700;}#yiv3052580932 #yiv3052580932ygrp-reco #yiv3052580932reco-head {color:#ff7900;font-weight:700;}#yiv3052580932 #yiv3052580932ygrp-reco {margin-bottom:20px;padding:0px;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ov li a {font-size:130%;text-decoration:none;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv3052580932 #yiv3052580932ygrp-sponsor #yiv3052580932ov ul {margin:0;padding:0 0 0 8px;}#yiv3052580932 #yiv3052580932ygrp-text {font-family:Georgia;}#yiv3052580932 #yiv3052580932ygrp-text p {margin:0 0 1em 0;}#yiv3052580932 #yiv3052580932ygrp-text tt {font-size:120%;}#yiv3052580932 #yiv3052580932ygrp-vital ul li:last-child {border-right:none !important;}#yiv3052580932


From: Incomm Solutions Inc. (2015-02-18 12:05)

Sorry - I wasn't clear, I guess.

The average units per day calculation on the Asset record is calculating
fine. However, if you have a PM record set to use the Average Units per Day
to calculate the PM's due Date (i.e. the "Generate Work Orders Using Meter
Readings Only (Do Not Estimate)" flag is OFF), then Maximo is not doing it
correctly.
1. In 7.5.0.4, it behaves as if the "Do Not Estimate" flag is on,
even when it's off - essentially it won't use the Average Units Per Day to
calculate the Estimated Next Due Date no matter what you have set on the PM
record.
2. In 7.5.0.6, if the "Do Not Estimate" flag is off, it uses the
Average Units per Day, but it seems to be using the formula:

{Last Completion Date} + {Units To Go}/{Average Units per Day} = {Estimated
Next Due Date}

If my diagnosis is true, Maximo is incorrect. By definition, the Units to
Go at the Last Completion Date are equal to the full frequency! It should
be using:

{Last Meter Reading Date} + {Units To Go}/{Average Units per Day} =
{Estimated Next Due Date}

I'm waiting for IBM to confirm my diagnosis for the 7.5.0.6 version (they
have already confirmed the problem with 7.5.0.4, which is why we went to
7.5.0.6). But it would helpful if anyone else could confirm as well.



Shannon Rotz


From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: February-18-15 8:58 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Meter-Based PMs - Average Units per Day


In Assets, I can configure Average Per Day: http://i.imgur.com/BVCozUd.png
http://i.imgur.com/BVCozUd.png
http://i.imgur.com/BVCozUd.png
http://i.imgur.com/BVCozUd.png http://i.imgur.com/BVCozUd.png
View on i.imgur.com http://i.imgur.com/BVCozUd.png
Preview by Yahoo
The average is what gets passed to the PM module.
http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png
http://i.imgur.com/vqrsuu4.png
http://i.imgur.com/vqrsuu4.png http://i.imgur.com/vqrsuu4.png
View on i.imgur.com http://i.imgur.com/vqrsuu4.png
Preview by Yahoo
This is strange that it is not working for you.
I know we ran into a bug where if we duplicated assets the meters types
associated would clone as well, but the actual asset number it was
associated to would not change. So, the PM triggers behaved oddly. It would
generate PMs early because the asset number for the meter was wrong so it
triggered on another asset's due date. (Hope that makes sense).


From: swkim (2015-02-19 09:00)

I'm using 7.5.0.5. If I check or uncheck "Generate Work Orders Using Meter
Readings Only (Do Not Estimate)" flag -- the next due date in time based or meter based stay the same. I would think that should change, but I'm not seeing it. Does that help you at all?


From: Incomm Solutions Inc. (2015-02-20 08:04)

Yeah, that's consistent with what we found - thanks!



Shannon

From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: February-19-15 9:00 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Meter-Based PMs - Average Units per Day


I'm using 7.5.0.5. If I check or uncheck "Generate Work Orders Using Meter
Readings Only (Do Not Estimate)" flag -- the next due date in time based or
meter based stay the same. I would think that should change, but I'm not
seeing it. Does that help you at all?