Episode 15 - Getting a Good DMR (featuring Clay White)

We’re excited to welcome Clay White to the podcast!

In this episode, Clay shares personal experiences and incidents that fueled his dedication to improving industry safety standards. He reflects on historical events, including the polypropylene reactor leak, and how these shaped his approach to safety. The conversation explores challenges in data management, the critical role of Damage Mechanism Reviews (DMRs), and limitations of inspection technologies. Clay also highlights common industry hurdles, such as ineffective RBI implementation and the need for careful planning when transitioning IDMS platforms. Tune in for insights on best practices, emerging trends in inspection, and the ongoing evolution of Risk-Based Inspection programs.

If you missed Part 1 of our discussion with Clay White, catch up here or wherever you get your podcasts.

00:22 Motivation and Early Career

01:06 Significant Incident and Lessons Learned

05:21 Discussion on Industry Failures and Data Analysis

10:40 Best Practices for Mechanical Integrity

18:44 Challenges in Changing IDMS Programs

 ++++++++++

Episode Acronyms & Abbreviations

AFPM – National Petrochemical & Refiners Association (USA)

API RBI – Desktop RBI software available through Equity Software 

CCDs – Corrosion Control Documents

CML – Condition Monitoring Location

DMR – Damage Mechanism Review

EPRI – Electric Power Research Institute

HTHA – High-Temperature Hydrogen Attack

IDMS – Inspection Data Management System

IOW – Integrity Operating Windows

MI – Mechanical Integrity

MOC – Management of Change

PCMS – Mechanical Integrity Software available through MISTRAS

PRDs – Pressure Relief Devices

RBI – Risk-based Inspection

UT – Ultrasonic Testing 

Thank you for listening to Upon Further Inspection! If you enjoyed this episode, be sure to follow or subscribe so you don’t miss the next one. 

 We’d love to hear from you—connect with us on LinkedIn and share your thoughts on the episode. Have ideas for future topics or guests? Email us at inspectionpodcast@gmail.com.

Join us next time, wherever you get your podcasts. Until then, stay safe and stay informed.

Note:  The views and opinions expressed by the guest are their own and do not necessarily reflect those of the hosts or the Upon Further Inspection podcast. This podcast is for informational purposes only and does not constitute legal or professional advice. Listeners should seek their own qualified advisors for guidance.

Transcript

Nick 0:00

Hey, I'm Branden. Hey, and I'm Greg.

Branden 0:02

This is upon further inspection. We got Clay white with us today.

Clay 0:22

what motivates me, what always motivated me was to, you know, try to improve our industry and avoid the failures. Mm-hmm. I, I went to work every day telling myself, that lives matter based on decisions I tried to bring to, to Phillips, and from a corporate role and programs that we were basing on, how we choose to approach the problems. And, so I, to me it was, it was, I thought of it as life and death every, every day. And,

Greg 0:48

yeah. And it

Clay 0:48

is for some, fortunately it's not often. It can be. It certainly can be. And so you get, you gotta always have that in your, back of your brain when you're making these kind of calls.

Branden 0:58

where do you think that comes from? that thought process? was there an event, was there something that happened back in the day or an experience or something that has led you to that?

Clay 1:06

No, I, you know, I didn't have a, I didn't have, well, you know, I call it a, you know, a, you call it getting, getting religion or, you know, or, or having a Come to Jesus moment or whatever. I didn't really have one of those major type of events that affected me personally, although early on in my career, probably the one that shaped it the most, not having, coming out of the, my original foray was, defense industry stuff. So, so we weren't looking at massive failures that could affect a lot of people. we had a, a Sumitomo, process reactor for making polypropylene. And so it was a big stirred reactor, very large. I don't remember how many thousand gallons of it was, you know, it was 40 foot tall and 12 foot diameter, give or take, of liquid propane in it. Right? So, We had started, this is literally about two weeks after I started the job. A guy went up to adjust a, high level capacitance probe to, which told you when you were reaching or nearing the top of the drum for a liquid fill height, and he removed the cap. It's kind of, looked like a distributor cap, if you will. He removed the cap off of this thing and the, capacitance probe, which is a long tube that, goes down into the vessel, launched out. In fact, he got it partially unscrewed and the pressure, the 500 pounds of pressure blew it out of his hand. And, and we had a huge release of, of liquid propane turning, you know, to gas and I don't remember how big that lease was, eight, 8,000 pounds before they got it de inventoried and, and stuff. fortunately it was the top of the reactor, so, you know, we had wind on our side and there was not any kind of ignition source, so it never lit off. And, and there was only one guy near there. And, that, that probably impacted me more than, more than anything else in terms of thinking how dangerous this could be. Now that wasn't a mechanical integrity failure per se. What it turned out was that, the, the capacitance probe had a plate that held the held down. You had, they had machined a groove, so you had, you had these keepers, these little moon clip things that went around the, the, the probe and then it had a plate That screwed that down and tightened it down. But you were dependent upon those keepers and

Greg 3:23

like a distributor

Clay 3:24

cap, like kinda like a distributor cap. And what they had done is when they rebuilt those probes and they failed to put those keepers in. And so there was nothing literally, other than friction, a bit of a friction fit from that, from that collar around it that held, held it in place and it had launched out. And they were, they were talking about shutting down the whole plant. And, because they had, four more reactors with those exact two, two of those probes on each top of each of those reactors. And Hmm, and I, and I, I looked at it and I said, you know, I don't think you need to shut down, but we need to x-ray all of them immediately to see if those keepers are in place. Right. Because we had enough room around them to, to x-ray it. And, and we actually from x-raying it, we found. We found I think two others that were missing the, the keepers. Wow. So the rebuild shop, when it went out, whoever rebuilt it didn't have a right kind of level of quality control to do that. So I guess that's, that's as close as I've got Branden as a, as a incident, of course, I've, also been on fatality investigations and other, other, you know, incident investigations. So I've seen lots of them, you know, a couple burn throughs on hot tapping and other, other problems. So you, you know, there's been lots of little reminders obviously how serious our, industry can be. And I always, you know, I always said, you know, for, for when I was talking with the sites about, you know, you don't wanna have to have a religious experience to get religion. you wanna learn from the mistakes of others. And you know, as Greg knows,'cause he is seen lots of stuff I've talked about, you know, I often start. Presentations with the, the, you know, the big fireball picture. Like, you know, like Ren Reynolds does the same thing a lot, right? We show the, we, in fact, we did that whole series right for A FPM, um, uh, around, you know, what can happen. I don't remember what, I forgot what we called that one. But, uh, it was, uh, it was just a series of, of learnings from significant mistakes and stuff. So that's, that's, that's kind of what's always in my head when I'm, when I'm thinking about these programs.

Branden 5:21

You, you mentioned that, as in some of your different roles, you were doing a lot of looking at the, the data, the models, the failure reports, all of those. your conversation brings me to this. did you find that a lot of the, the failures that you have gone back and investigations you've looked at, have been failures on the part of data input and execution on the backend? Or have you seen that there actually have been lapses in the technologies that people are using, whether it's in inspection technologies, whether it's, MI related technology? Is it, have you seen that it's the technologies or have you seen that it's maybe more user error or constraints on the backend?

Clay 6:02

Well, I, I've seen all of those, but I guess if, if the question. Is more around, what do you see the most of, or what seems to be more of the problem or issues? I would say it's probably a lot of, it was more keyed to a failure to understand the limitations on the approach you were taking. So, in some cases, I think that applies to, you know, we weren't looking in the right location with the right technique. Right. for the damage or you didn't understand how the software was really working or really calculating the risk. And so they missed something that would've, would've adjusted or changed that, that risk assessment or like in cases that we've just talked about on CML reduction kind of efforts that they. They didn't realize that, they didn't have the right inspection data or they had too little of the inspection data, to actually formulate a statistical analysis around. And, and so it gave them, you know, a false sense of security and, and said you could reduce the CMLs down to, you know, one or two. Right. So it's almost inevitably kind of more of a human factors issue and failure to consider everything that needs to be done more than it is a specific technology issue. I think, you know, you can, if you understand the limitations on the software you're employing or the technology endpoint, I, then you always can come up with a way around it, right? I mean, no, no. RBI program for, for an example, no RBI program covers every type of damage mechanism. And certainly doesn't cover it well. Right. So we, we have damage mechanisms that are, that are very difficult to try to predict. so take HT HA for an example. Right? So is the, is the HTHA model not great in everybody's RBI? That's probably true, but you know, knowing that, you know, especially as an owner user, it's incumbent upon you to understand what those limitations are and Exactly. And come and, and overcome'em, however you have to do it. Exactly. Do I put a more, do I put a more comprehensive inspection plan in place? Because I know, I, I can't predict HTHA particularly. Well, absolutely. Should I be more conservative on operation? Absolutely. You know, all of those things apply. Right? But you have to understand it in order to come to those kind of conclusions and, and create a program that, that compensates for it.

Greg 8:24

Clay, I, I'll share a story and Branden, you may find this hard to believe, but I remember back in the late eighties, when I was advising consulting with owner operators on their inspection programs. I'd say, well, how, what are you gonna do about this? Well, they go, oh, we got UT examiners. They're gonna come and examine that. Well. And I said, well, do they understand what they're looking for? And they looked at me like, deer in the headlights. Yeah, they're looking for cracks. I'm like, well, are those cracks gonna be parallel to the weld or transverse to the, well, what kind of cracks are we talking about?'cause that makes a difference in how they inspect. They had no idea they were sending UT guys out there and they didn't know if they were pushing their probes in the right direction. And the other thing they didn't do is they'd have people come out and back then remember manually we were using EPRI floss sizing methods. Oh yeah. Yeah. We didn't have the time of flight to fraction yet. And Right. Some of this other stuff. And the owner operators, most of them were, like you said, they didn't understand the limitations. Right. And the things you need to do to do this. Right.

Clay 9:28

Well, you know, I don't, I don't know that we are Right. So like, your examples are great one, Greg, because you know, you think about how. You know, what we have to work with, and I'm, this is no comment on the current state of quality of people in, in our joining our industry or coming outta school or whatever, but, you know, if you're, if you're fairly fresh out of school as a mechanical engineer and they throw you at the MI department, right? What do you really know about the limitations on inspection technology? Nothing. They don't teach, they don't teach that in school. You know, maybe I, maybe they do now. I don't, I don't know. But I've never, a few

Greg 10:00

places.

Clay 10:01

Yeah. I've never, I've not come across, anybody, upfront that really understood the limitations on, on the inspection technology side. and having somebody that really understands that is critical, I think in your, in your company, right? Yeah. So, you know, instead of just saying. You know, I need you to go look for corrosion here, or I need you to inspect. I mean, you go up even a higher level, I need you to inspect this vessel, you know? Well, yeah. What am I looking for? Where am I looking for? What type of damage am I looking for? You know, so the inspector, they're, they're dependent upon the inspector to try to ask those questions if they don't know, or if it's not detailed out on a specific equipment inspection plan. Right. that's a very true, statement for today, even I think.

Branden 10:40

if you were in charge of operating and, and running clay White's refinery, then what three high level best practices would you make sure that, your team's implemented?

Clay 10:50

Well, you know, to me, just because of my background, I think, you know, from a corrosion standpoint, you have to understand the problem to find it, right? and compensate for it. So, doing a really good damage mechanism review on the, on the equipment in the unit or the plant, I think is critical. Everything kind of stems from that, if you think about it, right? It's the, it's the starting point for doing I oovs it's the starting point for doing good CML reviews and optimizations. The starting point for RBI, so, so much is dependent upon doing that or, or developing your CCDs. All four of those things have in common, have the DMR as your starting point.

Branden 11:27

So that's, that's key. let me ask for one more clarification on that one for you. A really good DMR includes what?

Clay 11:34

well number one, you've got to understand the design. The, in the operation and, and some of the history, right? So you need to go back at least as, in the, in history to, to review kind of what's happened in the past. You don't want to ignore that piece of it. because whoever's running or inspecting the unit today doesn't necessarily know that he may not have refreshed his, his view of it, you know, from, from previous rbis or previous dmr or from failures that have occurred way in the past. So I try to get as much history as I can out of that. you basically write a summary. I used to have my inspectors go back and pull all the history they could and write that. So it was, it ended up being about a page of history. From, you know, from operational considerations when those changed, repairs, modifications, whether or not it's postal heat treated after they did the mods, all of that kind of stuff. And if they had coercion failures or cracking related failures and how they've inspected it, what were they looking for, right? So that's really, I think, a, a, a key. So that's understanding the, and getting a good DMR, which would include not only the damage mechanism, but the strategy really of where do I need to be inspecting and why. Do I need to be inspecting this equipment and, and to, I think, you know, how often I need to inspect that's, that needs to be tied to other things, but, not, not just rate, but how you're operating too. So you need to fold in the, IOW side of that equation to make sure that you're adjusting when you see kind of changes there as well on the, on the timing, either updating your RBI or approach or you just, go back out and reinspect it preventatively if you see a significant change or another related event. Mm-hmm. Mm-hmm. that's the start of a good DMR is identifying those factors. You know, I'm not talking about an overall CCD approach, you know, but each, once you get through the DMR, now you're looking at my strategy. Where am I going to inspect? What tools am I gonna use? Where, you know, how often do I need to do it again? And that's tied to a couple of things. that's the key aligning your strategy to what your DMR is telling you if you think about historically, right. So back in the day we had typically a fixed intervals, right? For inspection. So you look at early versions of our inspection codes document, they were essentially fixed, interval type inspections. and then we went to more of a, of a condition based inspection. So we would calculate a half-life and we would reinspect on what the anticipated condition of the equipment is. Then we've gone to risk-based in inspection, right? So now we're looking at multiple factors and deciding how much and when to inspect the equipment. What, what level of inspection, quality do I need to apply to that? So we, you know, that evolution, is continuing, right?'cause, you know, we, it based inspection goes back to 93. So what's our next level of evolution? is it an AI approach? May probably, that's, that's coming. But if you think about what we've changed in that timeframe, you know, we didn't talk about doing dmr, you know, back, back when we first started RBI, not to the degree that we do now. We didn't have iws, or, you know, CCDs. you know, now that those things have continued to push us from a much more prescriptive than reactive. Right then predictive, we're now continuing to push forward in the predictive modeling of damage in order to, make sure we apply the right inspection. That's kind of the evolution as I see it for the MI world.

Branden 15:04

what are the next two then best practices beyond the, the DMRB,

Clay 15:07

beyond the DMR? So the, then, you know, obviously I think the, the key after the DMR is doing the alignment with your inspection strategy, right? You've got to

Branden 15:15

take step

Clay 15:16

and that's, that's, to me, that's something that's, that's being missed a lot more often than I would like to see, right? So lots of audits that I've done, you know, they never really Relocated or adjusted their CMLs or the, essentially the, the inspection techniques or strategy for it, right? So I think that's the second next step after that. And then of course, I think you, you want to plug it into, you know, I'm a huge believer in RBI, but again, you've gotta be mindful of the things that it doesn't do particularly well. You know, external corrosion's an issue, right? So HDHA, all some different types of damage have to be compensated for in different ways. And then ultimately you have to tie this all together to, and, and make sure that your MI program is dependent upon how the unit's being currently operated and changes that are being anticipated in operation. Right. And so that ties you back to understanding, you know, when the process engineer puts in an MOC to make a change, right. You need to be tied into that MOC process, and you certainly need to be tracking and monitoring any kind of the, integrity operating windows, changes. When you, when you trigger one of those, you've gotta make sure that you're, you're appropriately responding with your inspection plan. That may, that may not change your inspection plan, but a lot of times it might because, because of changes that you've, documented through either an MOC or an or an IOW that are coming.

Branden 16:41

Yeah. Yeah. And I'm glad you said that. The, the IOW integrity operating windows, the, the CCD, the corrosion control document, and then MOC, your management of change process. So

Clay 16:52

having those work together is critical. The other thing I will tell you that I'm a huge believer in that's part of this is, kind of tracking your failures and understanding your failures. one of my favorite ways to do audits is I'll pull up plants past two years of failures, and you do kind of a reverse engineering approach and look at how did you miss this, right? those are the often the most telling in terms of where you have gaps in your program and what you're not, what you're not doing well at a given site, right? So you, you may see, you know, when you start to see repeated, failures or the repeated kind of a common theme on how things were missed. So, you know, running metrics, making sure the metrics mean something right. understanding. You gotta catch enough data on a leak metric to make sure that you can actually use it to help you design a program. To understand what you missed and improve the program. Right? So you've gotta be intentional about the leak metric, not that it just leaked. Yeah. You know, what, what was the damage metric? What'd you learn from it? How did you miss it? Why'd you, why'd you miss this? How'd you fail to predict this? Every, every leak is an opportunity right? to improve in terms of what you missed. And so that's kind of the approach I took I think our leak metric had about 30 different things that we, we captured on a, a given leak metric. You know, was it, was it localized? Was it generalized? Where did it occur? Specifically what, you know, what was the closest inspection location? You know, what was our inspection strategy? how did we miss that? Right. That kind of thing. and then analyzing that data, you know, annually at least, right. Looking back and saying, okay, what. What else new happened that I, that I need to respond to or maybe need to consider a change in our program. So, doing that resulted in modifications of the Phillips, standards that we had. So, going back and looking, we, we, we retooled our external corrosion program completely after, you know, seeing kind of the preponderance of, of data showing that we were not capturing,

Branden 18:44

With your, with your consulting hat on, with all of the audits that you have done, have you seen some systemic misses, throughout, not just one company, but across everything that you've been looking at? Is there anything systemic in industry that you're seeing people are missing? Yeah. Yeah. The

Clay 19:01

one, the one I've missed, I've got two key ones. I think the one I, the one I've already mentioned is that people are, are not. Rethinking their strategy after doing A DMR. There's no follow on to A DMR in a lot of cases. Or they didn't particularly do a good DMR cause they still were missing kind of key damage and hadn't really created the right inspection strategy relative to that damage, mechanism. I've seen that at a lot of sites in a lot of different companies. it seems to be fairly universal and, I can't predict why other than the fact that it, it still takes some corrosion materials, engineering help and it's tedious. You gotta go back through all and all your individual circuits and on piping and, and detailed look at where you're inspecting less of an issue, obviously on vessels because you're getting in the vessel periodically, typically. So you, you'll find, you'll see or find the damage internally and so you can adjust your inspection program. it's a big issue on pipe. So that's certainly one of'em. The other one I wanna mention is Maybe not directly related to your question, I guess it is, but there have been a lot of sites, that through a change or an acquisition or maybe they get a new lead and MI come in, they wanna make a systemic change in their IDMS program. And I've gotta tell you from audits that I've done that, that is probably by far the most detrimental thing you can do to a plant system. it almost doesn't even matter nearly as much what program, it's just the fact that you're making a change and then you're gonna have to, map all this data over into a new program, and how you'd map that data and it's gonna ask for new data that you don't have or you change your risk basis for how you're doing your calculations. it throws everything into a blender, essentially, right? And, and causes all kinds of problems. I'll give you an example. I came across here fairly recently. a site had just changed over. they were using A-P-I-R-B-I and, I think it was PCMS for their, their standard IDMS program. But, so what they, what they did is they, is they changed a couple of the sites were on a different IDMS program and they wanted everybody to be on the same program. So they, they said everybody's gonna change, I think, to PCMS and we're going to, and we're gonna use P-C-M-S-R-B-I, not A-P-I-R-B-I. So what they did is they froze. They took the, they took the previous RBI assessment that was done three to five years ago, and they, they carried over those dates as a fixed date. In the new program. So they wanted to make use of the RBI analysis that they'd previously done, even though it was on a different RBI basis. They brought that over as a fixed date. But when they plugged it into the way they plugged it into PCMS as a fixed date, it actually invalidated or it, it failed to consider any of the other data that would be related to corrosion rate or risk since you turned on a fixed date, that was a user override.

Greg 21:55

Yep. So they

Clay 21:55

continued to inspect for three, three plus years after that conversion. But they weren't due to do an internal on this tower for another two years at their next turnaround interval, I think is the way it went. But they actually corroded through and failed that tower and had a pretty substantial leak from that. But the data was showing them that they had increased the corrosion rate to 17 mils a year, but because they had overridden. User override on the inspection date. It wasn't actually calculating or considering any of the new corrosion date. And they did that for every vessel in the plant that had an RBI study. So that was just happened to be the first failure that that occurred from it.

Branden 22:37

That's a really standard practice that I've seen is grandfathering. Yeah. Me too. grandfathering in that old date. Right. And then, okay, once we get to that, then we'll move forward with the new Yeah.

Clay 22:46

Then we'll restart the clock and do it the new way and rerun the risk or whatever. Huge mistake. Huge mistake on that.

Branden 22:53

Wow. Well, that plays into what you said, right? Understanding the limitations of the program, the process, procedure, whatever, understanding those limitations and Right. when you completely switch your IDMS or your methodology of rbi Yeah. I mean. it compounds. It's huge. It's,

Clay 23:08

it's huge. If you think about, you've gotta move every piece of data in there, you know, not notwithstanding the millions of CML readings that you've got as a historical archive just in RBI alone, I think back in the day, 35 sticks in my head, but I know it's more now, but we had 35 pieces of discreet data to run an A-P-I-R-B-I calculation for risk. it's more now, right? you think about all of that data for each piece of equipment that's gotta be mapped over into the right location, you know, from, from that update understanding that if I do overrides, that may invalidate other things. I mean, there's so, so many nuances to, to doing this well,

Branden 23:43

and, and it may not be a one-to-one. Right. Exactly. It may not be a perfect one-to-one, especially going from like A-P-I-R-B-I to the PCM SRBI, right. there's fields that don't match up. So what do you do that. Do you keep it, do you keep it as a record and you put it into a different field and everybody just knows this field means this.

Clay 24:01

what'd you do for a quality control when you map the data from one location to the other in a backend dump? That was some computer guy did it for you, right? I mean, you've gotta check all that data. So this

Greg 24:10

is for Clay, for you and Branden both.'cause I, I know you've both been in this, but this is your interview. But here's the question is how do you think the industry can do a better job when they're evaluating whether or not they should change platforms and that if they decide, yep, the juice is worth the squeeze, they do a good job of it, that they anticipate things, that they roll it out, that they set themselves up for success and sustainability. what does the industry have to do to improve that? Because I don't think they do it well either. No, it's, it's

Branden 24:44

disastrous. Branden, I'll let you go first. It seems to me that they make sure they call clay white. That seems straightforward there.

Clay 24:53

I have no pc MS or data mapping expert. I've lived through this multiple times personally, of course, but

Branden 24:59

yeah, yeah, my knee jerk is, you know, make sure that you have people that understand what they're doing, participating in the process, whether it's somebody that you have internally or externally, like, don't be too proud to go and get help and have somebody there available. Greg, you mentioned before if you have, techies doing things that maybe they shouldn't be doing, and, and Clay, you said you got, you got, programmers moving data over, but what you're missing there is that context of all the data that understanding that, that MI piece. So I think one of the big pieces, and, and by the way, I can't tell you how many times we get phone calls of, Hey, we're gonna do RBI. Oh, cool. Okay, so you're gonna do vessels? Oh yeah, we're gonna do everything. Vessels, circuits, piping, PRDs tanks, whole thing. Yeah. Yeah. Right. And you're like, oh, okay. Have you guys, have you circuited? Do you have circuits? What do we need those for? Mm-hmm. Okay. Yeah, understood. I get that. Right. So like, and, and so these are the conversations where you kinda have to work your way through it and, oh, we wanna do PRDs. Okay, cool. Do you understand what happens when you do PRDs? That you're gonna have some that you're gonna be able to extend and the ones that you don't want to extend, or the ones that you do want to extend that are the hardest ones to get to, they're not gonna extend out. Those are the ones that are always gonna be high risk, and that plan's gonna backfire on you. And so for me, it's having people who understand the technology that you wanna bring in, the concepts, the ideas, having that MI person, again, internal or external available to be able to help support your journey. I think that's one of the most important things you can do.

Clay 26:36

Yeah, I, my first advice is don't do it, don't change. My second advice is, is the same as my first, if you, and then my third piece would be if you absolutely have to do it, you know, develop a plan. And the plan needs to be detailed enough that you've considered all of those things, checks. What am I giving up if I go this route? how do I migrate all this data and how am I gonna quality check it? And how am I gonna fill in the gaps that are existing? You know, what are the gaps that are existing? what are the advantages, disadvantages of my new program? What am I gonna have to compensate for? Right. I honestly, I've never seen anybody develop a plan to do this. Yeah, yeah. at, at Phillips, when I started the job, I inherited three different IDMS programs. and so, I think it was Credo Soft, maybe. and then we had the old Berwanger. a program. and then we had, well, I said it was probably pre Ultra Pipe. It was Ultra Pipe before, before Burger Winger bought it later, I think. But, and then we had PCMS, so we decided we're gonna put everybody on the same platform, we evaluated the pros and cons of each of the programs and then kind of decided to go forward with PCMS. We weren't doing RBI at the time. a couple select sites were doing was doing RBI at the time. but they were kind of standalone, I think mostly E two G programs. the way I approached it was I knew I wanted everything to map into PCMS. So I, I went straight to PCMS and said, I need a guy with a lot of corrosion or inspection experience in PCMS, I want him to do it. That's how I met, Joe Sch. And so Joe and I spent lots of time talking about it. We didn't actually develop a map. but you know, I, I kind of catted on Joe to know the, the ins and outs and the problems and so, so I mean, the contractor's there to help you and they'll help you in any way they can, but you gotta make sure they understand that software and program and, and the issues. You know, I think nobody anticipated that at Case I, I showed you where they, they nobody was thinking through what happens. They didn't understand PCMS well enough to understand that when they migrated that data, the RBI data and used a fixed date, that it was going to invalidate all kinds of other considerations that, that PCMS normally would do. for, for when you were seeing high corrosion rate. it's gonna only go to that default, whatever you said was a user override date.

Greg 28:52

Well,

Clay 28:52

and there's lots of ways to mess up P-C-M-S-I, trust me, I've done it multiple times.

Greg 28:57

Yeah. Well, I agree with you totally. Clay and Branden. one bit of advice I would give listeners is to make sure they engage someone who understands all those, I think nuances between the two and what adjustments need to be made prior to making that transfer. It's not just as easy as hiring some body with a background in that, programming and that software to do some massive data swap.'cause I'll guarantee you, they don't know where all those tech nuanced technical areas are that are gonna jack up the data.

Clay 29:32

the worst example on this that I came across recently was, there was a company, I'm not, I'm, I don't wanna get in trouble with the naming names, but they, there was a company that had a corporate homegrown IDMS program. There's not many of those, so you probably have a good idea who that might be. that site changed hands. And so it was incumbent upon them to switch over to, to PCMS, but they were never successful in mapping the data from the homegrown version of IDMS into PCMS. So when I, I actually did an audit of the plant, so I did an audit of the plant in, in two years after they pulled the plug on their old software, they were still using a one-off version of the old software to try to continue to manage the plant, but it was a stagnant version of that, of that, of that software. And they still had not transferred any of the data or mu much of the data at all. It was only, it was only a little bit of the data had, were they able to migrate and they'd kind of given up and thought they were just gonna have to go back through and redo everything by hand. Which you think about that, They just added 10 years to their conversion process. Right. So

Greg 30:43

yeah, it subtracted 10 years from their lives. Yeah,

Clay 30:46

exactly. Exactly. Yeah. So, and there were several other findings resulting from that on stuff that they had not been inspecting or not considered for updating.

Branden 30:55

switching gears completely. Uh, have you been, have you had a chance to do any type of, uh, brewing or, or distilling lately?

Clay 31:05

I, I, I haven't started distilling, but I brew kind of constantly. I always have something going, so, uh, yeah. the one I I just finished was a, a batch of, Belgian Triple Ale. I like the stronger Belgians Yeah. Ales. Yeah. Triples and quads or Belgian strong, dark, strong ales. That's, that's what it is actually. So, yeah, I, I really enjoyed doing it. I've been doing it now for a couple of years, so, and of course, the engineer in me always wants to track everything, so I've got a whole spreadsheet that runs all my gravities and, you know, it'll. It'll keep, keep track of all of it. And I keep notes on it and stuff, so it's, yeah, it's been, been, uh, kind of an enjoyable fast time.

Branden 31:45

Alright. Have you done some brewing,

Clay 31:46

Branden,

Branden 31:47

back in the day? Back in, way back in the day? I think every, I think every, uh. Uh, male American at some point. Probably thought about it. Tried it. Tried it, yeah. Has done some version, whether it was in a bathtub or in a, uh, an actual, in an actual glass jar. Well, if

Clay 32:03

you, if you've ever been to a distillery, man, you know, the, it's, you look at how they do those VAs to start, bathtub isn't any different, so, uh, yep. Yeah. I never, I didn't, I never started in a bathtub, but thank God I didn't develop this, uh, this habit until late in life because I was telling somebody the other day that if I knew how easy it was to brew, uh, stuff I, in, in college, I'd have been in real trouble.

Branden 32:23

Yeah. Yeah. Exactly. All right, Greg, anything else?

Greg 32:28

A, a million things, but we only have so much time and I'm about worn out this point. Yeah. That, that was,

Clay 32:34

that was about two hours worth you. I, if you, yeah. About five minutes of meaningful, uh, conversation. But the rest of it was, the rest of it was interesting to me.

Branden 32:43

Thank you for listening to Upon Further Inspection, a Mechanical Integrity podcast. This episode was co-created by Inspectioneering, and CorrSolutions. Our producers are Nick Schmoyer, Jocelyn Christie and Jeremiah Wooten. This podcast is for informational purposes only and does not constitute legal or professional's advice. Listeners should seek their own qualified advisors for guidance. If you enjoyed this episode. Please join us next time wherever you listen to your podcasts. Until then, stay safe and stay informed.