In DEPTH Cause Analysis for Equipment Problems
Equipment degrades, malfunctions, or fails outright... hopefully not too frequently, but every breakdown can be painful. So, of course, you will want to figure out exactly what happened, how it happened, and why (in hardware/software terms). You may want to dig a little deeper, though; every equipment malfunction or failure that you have is a valuable datapoint for gauging the health of your overall equipment program. That's why I've started creating a tool that should be able to help find programmatic causes underneath the more easily observable equipment performance issues. Since it is intended to be a Diagnostic for Equipment Programs, and uses Tabulated Heuristics, I call it DEPTH.
An early alpha release of the DEPTH tool is linked below, and you are free to download it and review it, try it out, share it, etc. However, I've got a couple of important notes and requests I'd like you to read before downloading the tool.
- This is an early alpha release, and it is incomplete. For instance, definitions or explanations for the "codes" are not provided. (You'll know exactly what I mean when you open the file.) Your use of this tool is at your own risk.(And mind the disclaimer!)
- While I'm giving this away, I'm not releasing it to the public domain, or even distributing it as open source yet. Treat it like an article published in an industry journal; you wouldn't just go and claim something like that as your own, but you could share it, use it, reference it, etc.
- Please Please PLEASE give me feedback. The URL for this article is provided on the tool itself... please leave comments here and tell me what you think about the tool, what you would like to see changed, etc. I'll keep trying to improve the tool on my own, but your feedback is extremely valuable.
Alright... here it is. Download, review, use, and then COMMENT. (Note: I found a stupid error on the first version I posted; the error has been fixed and a new version uploaded.)
Finally, remember the wise words of George E. P. Box: "All models are wrong, but some are useful."
 by Bill Wilson |
Loading Quotes...
|
I was asked about a manual via email. Here’s how I replied (this has been improved a bit):
There’s no manual, and I’m hoping there won’t be one. What I’m envisioning is one page of simple instructions, definitions, tips, etc. Thus, the entire tool … flowchart plus user guide … is one sheet of paper. I’ve done this once before with a similar tool and I think the one-sheet model works well for this.
For now, though, I think that if you print the flow chart, start at the top in box 11, and work your way down through the chart, it will make sense. Even the transfers (numbers in triangles) are easy once you know what they’re for.
Here’s a simple example. You’ve had a component fail due to water chemistry problems. The problem was unexpected (11), could be characterized as a failure (22), is the first instance you’ve seen (32), middle of component life (42), and definitely involves a chemistry issue (51). Just considering chemistry for the moment, you see transfers to (52) and (53).
Considering design/configuration (52), you don’t see anything obvious until you remember that the facility started injecting a new anti-corrosion chemical into the service water supply a few months ago; that could have had some unrecognized impacts, so that gives you two new transfers to (55) and (58). (You still have a previous transfer to (53) to consider, but put that aside for now.)
You consider all the items under performance monitoring & testing (55), but none seem to be relevant to the issue of unrecognized impacts from a change to system chemistry. Then you consider the items under tech knowledge & info systems (58)… you feel that there’s something relevant, but you can’t put your finger on it, so you start calling people and find out that there had been industry reports of some facilities experiencing larger than usual oxide releases from service-water piping after using the same chemical… and that the oxide releases had caused secondary chemical impacts on other equipment similar to yours.
You mark down “available technical info not used effectively” as something to discuss with the project leader of the team that installed the chemical injection system. You then also realize that an item under (55) might be applicable (inadequate performance monitoring, relative to the changes that could have been expected due to introduction of a new chemical injection system), but you put that aside for a moment to go have a heart-to-heart discussion with that project leader…
I hope that is enough to demonstrate usage for now. Maybe it’s not, but it’s all I have at the moment. I should have the next version of the tool available in a few days (maybe next week), and it will include the user guide material I mentioned above.
Looks pretty good. Why specify only “critical” equipment in the top box? And what’s the purpose of box 21?
Are you still working on this?
Hi Annal, thanks for the comment. I plan to complete this and release a beta version sometime soon, certainly before the year is out. That version will not include “critical” in box 11, and box 21 will be removed. If you have any other comments, I’d be glad to see them!