<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Ivara</title>
	<atom:link href="http://www.ivara.com/index.php/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ivara.com</link>
	<description>All About Optimizing Plant and Equipment Performance</description>
	<lastBuildDate>Fri, 19 Feb 2010 14:59:36 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Defining Failures and Being Consistent by Paul Lanthier</title>
		<link>http://www.ivara.com/index.php/2010/02/17/defining-failures-and-being-consistent/comment-page-1/#comment-60</link>
		<dc:creator>Paul Lanthier</dc:creator>
		<pubDate>Fri, 19 Feb 2010 14:59:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/?p=2955#comment-60</guid>
		<description>I agree with everything the author said as this is pretty much right out of John Moubray’s book. One exception is the last point: “Once enough condition inspection data has been defined, you can calculate the PF Interval and plan maintenance activities.” 
If we look at the Resnikoff Conundrum (p252 in John’s book):
Many believe that it is not possible to develop a viable maintenance program without extensive data about failures but if we are collecting lots of data about failures it must be because we are not preventing them. Therefore large quantities of failure data must be evidence of the failure of our preventive maintenance programs; especially if the failures have significant consequences. So successful maintenance must be about preventing the collection of the information that some people think we need in order to decide what preventive maintenance we ought to be doing! 
The Resnikoff Corollary States:
Really successful physical asset management is much more about anticipating and/or preventing failures (which matter) than it is about counting them. Score cards only tell you what you did, not what you should be doing.
Therefore we need to define the P-F interval without data and refine as we get data, if we can. If we are very successful in developing our maintenance program we will not have enough data to refine the program. This is actually a good sign.
Paul Lanthier P.Eng.
Director, The Aladon Network</description>
		<content:encoded><![CDATA[<p>I agree with everything the author said as this is pretty much right out of John Moubray’s book. One exception is the last point: “Once enough condition inspection data has been defined, you can calculate the PF Interval and plan maintenance activities.”<br />
If we look at the Resnikoff Conundrum (p252 in John’s book):<br />
Many believe that it is not possible to develop a viable maintenance program without extensive data about failures but if we are collecting lots of data about failures it must be because we are not preventing them. Therefore large quantities of failure data must be evidence of the failure of our preventive maintenance programs; especially if the failures have significant consequences. So successful maintenance must be about preventing the collection of the information that some people think we need in order to decide what preventive maintenance we ought to be doing!<br />
The Resnikoff Corollary States:<br />
Really successful physical asset management is much more about anticipating and/or preventing failures (which matter) than it is about counting them. Score cards only tell you what you did, not what you should be doing.<br />
Therefore we need to define the P-F interval without data and refine as we get data, if we can. If we are very successful in developing our maintenance program we will not have enough data to refine the program. This is actually a good sign.<br />
Paul Lanthier P.Eng.<br />
Director, The Aladon Network</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Defining Failures and Being Consistent by Jim Becker</title>
		<link>http://www.ivara.com/index.php/2010/02/17/defining-failures-and-being-consistent/comment-page-1/#comment-59</link>
		<dc:creator>Jim Becker</dc:creator>
		<pubDate>Thu, 18 Feb 2010 22:34:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/?p=2955#comment-59</guid>
		<description>There are other considerations. If the flow is controlled, then the failure is when the process reading for the flow is not at the set point. Then the calculation of SP-PV results in the Delta, which should be compared to the limit. If the set point is low, like 105 gpm, then a Delta of 5 is not as indicative of a pump problem at when the set point is 130 and the Delta is 20. One can also develop a curve for the control valve position versus flow. When the valve position is much higher than normal for the same flow rate, that indicates a pump problem.</description>
		<content:encoded><![CDATA[<p>There are other considerations. If the flow is controlled, then the failure is when the process reading for the flow is not at the set point. Then the calculation of SP-PV results in the Delta, which should be compared to the limit. If the set point is low, like 105 gpm, then a Delta of 5 is not as indicative of a pump problem at when the set point is 130 and the Delta is 20. One can also develop a curve for the control valve position versus flow. When the valve position is much higher than normal for the same flow rate, that indicates a pump problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Implementing RCM&#8211;Tips for training trades on executing routes when they have no prior reliability experience or training by Julio Castro</title>
		<link>http://www.ivara.com/index.php/2009/06/30/implementing-rcm-tips-for-training-trades-on-executing-routes-when-they-have-no-prior-reliability-experience-or-training/comment-page-1/#comment-13</link>
		<dc:creator>Julio Castro</dc:creator>
		<pubDate>Wed, 12 Aug 2009 05:33:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=344#comment-13</guid>
		<description>At our site, we have tried the friendly approach as well as all of the other mentioned tips. Some however, seem to not use the system. For the most part, it is those with the 20 to 30 year expierence. Any other tips for the more stubborn??</description>
		<content:encoded><![CDATA[<p>At our site, we have tried the friendly approach as well as all of the other mentioned tips. Some however, seem to not use the system. For the most part, it is those with the 20 to 30 year expierence. Any other tips for the more stubborn??</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Implementing RCM&#8211;Tips for training trades on executing routes when they have no prior reliability experience or training by Brian Flett</title>
		<link>http://www.ivara.com/index.php/2009/06/30/implementing-rcm-tips-for-training-trades-on-executing-routes-when-they-have-no-prior-reliability-experience-or-training/comment-page-1/#comment-12</link>
		<dc:creator>Brian Flett</dc:creator>
		<pubDate>Thu, 23 Jul 2009 16:11:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=344#comment-12</guid>
		<description>While there may be some minor corrective work that can be done in real time, most repairs of any significance require operations to be stopped, parts to be staged, and potentially specialized trades or tools to be scheduled.  Many of the benefits of proactive maintenance come from identifying the need for corrective work early enough to properly plan and schedule the resources required to do the corrective work.</description>
		<content:encoded><![CDATA[<p>While there may be some minor corrective work that can be done in real time, most repairs of any significance require operations to be stopped, parts to be staged, and potentially specialized trades or tools to be scheduled.  Many of the benefits of proactive maintenance come from identifying the need for corrective work early enough to properly plan and schedule the resources required to do the corrective work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Teamwork-One of the keys to Reliability by Frank Snook</title>
		<link>http://www.ivara.com/index.php/2009/05/28/teamwork-one-of-the-keys-to-reliability/comment-page-1/#comment-9</link>
		<dc:creator>Frank Snook</dc:creator>
		<pubDate>Thu, 02 Jul 2009 01:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=320#comment-9</guid>
		<description>Al, I agree totally. I just wrote a comment on Mike&#039;s Blog about this very same subject. He was talking about doing route based maintenance (RCM) and my comment was that I prefer the team based approach (what you are stating is called TBM or Team Based Maintenance) in my world. I think you are right on and it is much more effective than any route based scheme or the old periodic maintenance where artisans showed up and the operator did not know they were coming. Excellent post!!!</description>
		<content:encoded><![CDATA[<p>Al, I agree totally. I just wrote a comment on Mike&#8217;s Blog about this very same subject. He was talking about doing route based maintenance (RCM) and my comment was that I prefer the team based approach (what you are stating is called TBM or Team Based Maintenance) in my world. I think you are right on and it is much more effective than any route based scheme or the old periodic maintenance where artisans showed up and the operator did not know they were coming. Excellent post!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Implementing RCM&#8211;Tips for training trades on executing routes when they have no prior reliability experience or training by Frank Snook</title>
		<link>http://www.ivara.com/index.php/2009/06/30/implementing-rcm-tips-for-training-trades-on-executing-routes-when-they-have-no-prior-reliability-experience-or-training/comment-page-1/#comment-11</link>
		<dc:creator>Frank Snook</dc:creator>
		<pubDate>Thu, 02 Jul 2009 01:31:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=344#comment-11</guid>
		<description>Mike,  I have to say this, there is one thing about RCM that I dislike. I dislike the routes. I feel they are a horrible way of taking in data. Most artisans are so worried about the route that they don&#039;t pay attention to what they are doing. I prefer a team based approach to maintenance where the team moves from machine to machine and repairs happen real time.</description>
		<content:encoded><![CDATA[<p>Mike,  I have to say this, there is one thing about RCM that I dislike. I dislike the routes. I feel they are a horrible way of taking in data. Most artisans are so worried about the route that they don&#8217;t pay attention to what they are doing. I prefer a team based approach to maintenance where the team moves from machine to machine and repairs happen real time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Sharing-It really can make a difference by Hughson P</title>
		<link>http://www.ivara.com/index.php/2009/06/11/sharing-it-really-can-make-a-difference/comment-page-1/#comment-10</link>
		<dc:creator>Hughson P</dc:creator>
		<pubDate>Wed, 17 Jun 2009 23:21:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=327#comment-10</guid>
		<description>Hi Al, Interesting content in the last three articles. Thanks. Please get someone to proof read it though: TRUELY should be TRULY, MANOR (is a house) should be MANNER, DEVELOPE should be DEVELOP, practioners should be practitioners.

Just SHARING some spelling tips!</description>
		<content:encoded><![CDATA[<p>Hi Al, Interesting content in the last three articles. Thanks. Please get someone to proof read it though: TRUELY should be TRULY, MANOR (is a house) should be MANNER, DEVELOPE should be DEVELOP, practioners should be practitioners.</p>
<p>Just SHARING some spelling tips!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Detective tasks (failure finding) &#8211;are these proactive? by Daryl Mather</title>
		<link>http://www.ivara.com/index.php/2009/04/08/detective-tasks-failure-finding-are-these-proactive/comment-page-1/#comment-6</link>
		<dc:creator>Daryl Mather</dc:creator>
		<pubDate>Fri, 08 May 2009 02:40:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=240#comment-6</guid>
		<description>Paul,

Thanks for this. I wasn&#039;t aware you had replied.

&quot;This said, from a strict definition point of view with detective tasks we are not predicting or preventing the failure we are seeing if the asset has failed. Therefore I can also respect an alternative conclusion.&quot;

We are still managing the consequences of failure... so it sticks for me.

Just as a side issue I find that a heck of a lot of the stuff I see published from the SMRP is significantly flawed. Sometimes even dead wrong.

I don&#039;t doubt their good intentions, but their information is just out of whack a lot of the time.

The statement that 85% of corrective should come from PM&#039;s is right out of whack for example.

First, does PM mean Preventive or planned first of all? It is a hang over from a simpler time when we were all time based junkies.

Second if 85% is supposedly coming from these then where does that leave RTF options? And what about a plant (such as many water plants) with oodles of redundancy? (Lots of RTF decisions normally)

The proactive versus planned issue and definitions I am okay with. I think we both understand that it is something we have taken a conscious decision to do a specific way... so call it Susan if you like - it makes sense.

Thanks for the discussion,

Daryl...</description>
		<content:encoded><![CDATA[<p>Paul,</p>
<p>Thanks for this. I wasn&#8217;t aware you had replied.</p>
<p>&#8220;This said, from a strict definition point of view with detective tasks we are not predicting or preventing the failure we are seeing if the asset has failed. Therefore I can also respect an alternative conclusion.&#8221;</p>
<p>We are still managing the consequences of failure&#8230; so it sticks for me.</p>
<p>Just as a side issue I find that a heck of a lot of the stuff I see published from the SMRP is significantly flawed. Sometimes even dead wrong.</p>
<p>I don&#8217;t doubt their good intentions, but their information is just out of whack a lot of the time.</p>
<p>The statement that 85% of corrective should come from PM&#8217;s is right out of whack for example.</p>
<p>First, does PM mean Preventive or planned first of all? It is a hang over from a simpler time when we were all time based junkies.</p>
<p>Second if 85% is supposedly coming from these then where does that leave RTF options? And what about a plant (such as many water plants) with oodles of redundancy? (Lots of RTF decisions normally)</p>
<p>The proactive versus planned issue and definitions I am okay with. I think we both understand that it is something we have taken a conscious decision to do a specific way&#8230; so call it Susan if you like &#8211; it makes sense.</p>
<p>Thanks for the discussion,</p>
<p>Daryl&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Detective tasks (failure finding) &#8211;are these proactive? by Paul Lanthier</title>
		<link>http://www.ivara.com/index.php/2009/04/08/detective-tasks-failure-finding-are-these-proactive/comment-page-1/#comment-8</link>
		<dc:creator>Paul Lanthier</dc:creator>
		<pubDate>Thu, 09 Apr 2009 15:25:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=240#comment-8</guid>
		<description>I understand your position with respect the detective tasks being proactive and I tend to think that way as well. This said, from a strict definition point of view with detective tasks we are not predicting or preventing the failure we are seeing if the asset has failed. Therefore I can also respect an alternative conclusion.



As for corrective tasks not being proactive, SMRP benchmark information states that roughly 20% of your manpower should be spent on PM (predictive, preventive and detective?) tasks and 80 to 85% of your corrective tasks should derive from these inspections. The reason we inspect is in order to reduce or mitigate the consequences of failures. The inspection on its own cannot do this unless one takes action in response to the inspection. That action is the corrective task and if taken before consequences are felt (F on the P-F curve) it is proactive.
If we do not consider this corrective work as proactive we may discount it in our performance evaluations. Doing corrective work that is planned, scheduled and executed before functional failure is what it&#039;s all about. This has to be counted on the plus side of the ledger when measuring results of our maintenance efforts and improvements.</description>
		<content:encoded><![CDATA[<p>I understand your position with respect the detective tasks being proactive and I tend to think that way as well. This said, from a strict definition point of view with detective tasks we are not predicting or preventing the failure we are seeing if the asset has failed. Therefore I can also respect an alternative conclusion.</p>
<p>As for corrective tasks not being proactive, SMRP benchmark information states that roughly 20% of your manpower should be spent on PM (predictive, preventive and detective?) tasks and 80 to 85% of your corrective tasks should derive from these inspections. The reason we inspect is in order to reduce or mitigate the consequences of failures. The inspection on its own cannot do this unless one takes action in response to the inspection. That action is the corrective task and if taken before consequences are felt (F on the P-F curve) it is proactive.<br />
If we do not consider this corrective work as proactive we may discount it in our performance evaluations. Doing corrective work that is planned, scheduled and executed before functional failure is what it&#8217;s all about. This has to be counted on the plus side of the ledger when measuring results of our maintenance efforts and improvements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Detective tasks (failure finding) &#8211;are these proactive? by Daryl Mather</title>
		<link>http://www.ivara.com/index.php/2009/04/08/detective-tasks-failure-finding-are-these-proactive/comment-page-1/#comment-7</link>
		<dc:creator>Daryl Mather</dc:creator>
		<pubDate>Thu, 09 Apr 2009 04:36:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.ivara.com/blog/?p=240#comment-7</guid>
		<description>Paul,

I have this blog plugged into our group (Reliability Success) on LinkedIn so it came to my attention. (Feel free to join by the way - a non commercial group)

I don&#039;t see this as being an argument at all. (Hard colour scheme to read by the way, or am I just getting old?)

At all times we are trying to manage the consequences of failure. Remember the three pumps analogy - we are aiming to mitigate, prevent or reduce the consequences of failure - not prevent the failure itself.

At all times - every time. It is only once we depart from these rigid definitions that we enter into the world of maybes and half truths.

So detective maintenance is very definitely proactive. It is calculated at a frequency designed to maintain tolerable levels of risk. Period.

Remembering that we have already determined that predictive and preventive tasks are not actually valid for this failure mode. (As per SAE JA1012 decision diagrams)

Not only that but I would suggest that corrective tasks are NOT proactive, but they are planned. We aren&#039;t doing anything proactively in the case of (say) predicTED tasks, we are doing something proactive with the PredicTIVE task however.

I think there is a need to separate proactive / reactive and planned / unplanned. It can easily get semantical if we take it too far though.</description>
		<content:encoded><![CDATA[<p>Paul,</p>
<p>I have this blog plugged into our group (Reliability Success) on LinkedIn so it came to my attention. (Feel free to join by the way &#8211; a non commercial group)</p>
<p>I don&#8217;t see this as being an argument at all. (Hard colour scheme to read by the way, or am I just getting old?)</p>
<p>At all times we are trying to manage the consequences of failure. Remember the three pumps analogy &#8211; we are aiming to mitigate, prevent or reduce the consequences of failure &#8211; not prevent the failure itself.</p>
<p>At all times &#8211; every time. It is only once we depart from these rigid definitions that we enter into the world of maybes and half truths.</p>
<p>So detective maintenance is very definitely proactive. It is calculated at a frequency designed to maintain tolerable levels of risk. Period.</p>
<p>Remembering that we have already determined that predictive and preventive tasks are not actually valid for this failure mode. (As per SAE JA1012 decision diagrams)</p>
<p>Not only that but I would suggest that corrective tasks are NOT proactive, but they are planned. We aren&#8217;t doing anything proactively in the case of (say) predicTED tasks, we are doing something proactive with the PredicTIVE task however.</p>
<p>I think there is a need to separate proactive / reactive and planned / unplanned. It can easily get semantical if we take it too far though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
