Digital Doers Podcast with Lindsey Inc.

00:23 – Casey

Welcome back to the show. Today, we’re getting into the realities of IT and OT in the oil and gas with Lindsey Inc. Brought to you by Ericsson, driving oil and gas forward with seamless connectivity from private 5G networks to real time data and automation. Ericsson is helping operators improve safety, efficiency, and decision making across the energy value chain. I’m gonna go ahead and kick off. I’m with David at Lindsey Inc, and I’ll let him introduce himself, introduce the company, and go through some questions, and we’ll see what fun topics we can get into today. Glad you’re joining me, David. 

00:58 – David

Thanks, Casey. Thanks for inviting us on the show. As Casey mentioned, my name is David Panthagani. I’m currently the director of operations and one of the managing partners here at Lindsey Inc. Lindsey Inc is a systems integrator. We play on the IT-OT side, in between that space for primarily pipeline operations companies, primarily at the moment in midstream. And we’ve got pretty diverse team of engineers, consultants, application developers, communications folks that can support a really turnkey build out of field communications, infrastructure, SCADA applications, compliance products, and leak detection, any kind of bolt on application that would help streamline safety, efficiency, operational awareness for pipeline control centers and oil and gas operators.

01:43 – Casey

Okay. So y’all have been in the industry for a little bit. I like to ask people before we go into everything y’all do well, and you do a lot of things well, in your time with Lindsey, what were some of your challenges that you faced and some things that maybe y’all had to look back at and say, hey, that wasn’t the best way to approach helping our customers. Is there anything that y’all have learned from?

02:03 – David

We have. Yeah. We’ve been doing this… the team here has been working in various industries for twenty or so years. So over that time frame, of course, like, you’ll run into projects or solutions that you’ve delivered that you might could have done better. One thing that comes to mind is we deployed a communications infrastructure in the Bakken, actually. And as you mentioned, this switch off or hand off between IT and OT. OT systems typically are low throughput. Like, they just high uptime, but you typically don’t pass a lot of data through that. So the comms gear that we deployed out there was rock solid, but it wasn’t high throughput. And so then as some of the field operations team started using that equipment, it just it slowed down that network to a point where it’s not usable for field operations. Come to find out, there are maybe high higher data throughput devices that are being utilized on the network nowadays. Even the PLC controllers and the flow computers out there, you need to push down applications through that pipe for firmware updates and, like, downloading programs and so forth. So it’s just a matter of understanding fully the use case for what the customers intend to, long term, use those systems that we’re deploying and then making sure that they’re fit for that purpose. So we ended up swapping out to a higher throughput radio a couple years later while we were supporting that customer. So it’s that we can find the right technology, and the lesson learned for us at that point is just to understand fully. And this was fifteen years ago or so. So nowadays, bandwidth and throughput is six or seven times what it was back then. But, yeah, people aren’t watching and streaming YouTube content in the field. That’s not the case. It’s just it’s still on the OT side, but even nowadays, like, the controllers require sometimes a heavy pipe or a large pipe to push data down.

03:59 – Casey

You’d be surprised. I’ve actually I’ve talked to people that…

04:01 – David

No. You’re right. On the OT side, we lock all that down so no one’s Yeah. You need to On the IT side, sure. Yeah. Nowadays, you got Starlink and you’ve got all these the guys just throw stuff up on their truck and they’re out there.

04:15 – Casey

Yeah. That’s what I was gonna say. I was with a company and they were having to upgrade their plan, like, frequently, and it turned out the folks that were on-site were taking advantage of the YouTube and what have you, and it was consuming. So they had the Starlink out there just so they could actually monitor stuff and turned into a whole thing. So, yeah, locking it down is ideal.

04:29 – David

There’s a story once, like, exactly at the right time of day of 5PM or so. One of our customers would lose signal to one of their locations. Couldn’t figure out why. Come to find out there was a guy who had a cell phone hotspot, and he could get signal right in this one spot. So he’d pull his truck up and be watching the afternoon news or something, and it was right in the line of sight where this comms link was getting back to that facility. So, yeah, it’s just field operations. You always have to make sure you work around whatever it is that you find happening out there.

05:01 – Casey

Yeah. So this is interesting to me with my background being, like, pipeline midstream. I don’t know if you can get into it. Is there specific examples of from start to finish, a customer comes to you and they’re trying to achieve this… What’s the most common problem that they’ll come to you with and walk me through that briefly just to give a better understanding of what it is you do? Because I’m curious just having been in that world of how exactly it applies to the more common operator in a pipeline midstream sector.

05:25 – David

The typical, I would say, the sweet spot of customer that we have is either they’re in an acquisition or they’re building a new segment to their asset, or they’re standing up a brand new asset. In either of those three scenarios, you’ve gotta understand what their end goal is. What are they trying to get to? Are they building their own control room to operate the system? Are they expanding their existing control room to operate the system? And what do they wanna do long term? Or are they simply just building up the control system and letting someone else’s system operate that asset for them? We will, from start to finish, walk down the pipeline with that customer, figure out communications. We can, if it’s fiber runs or copper or fixed wireless cellular, whatever it might be now, Starlink nowadays, like we talked about. We can figure out how to get data to the different pump stations or valve sites or whatever it might be on that pipeline. We can work with their IT teams and if they’ve got it, their OT operations teams to help solve the problem between IT and OT. So nowadays, once you’ve got your control systems built out back to SCADA, there’s still a stream of data that the corporate team wants to see. So that could be cash register information, volumes, throughput, things like that. So we can work with IT to make sure that link exists securely… data’s just being ported out one way; we can set up in a Purdue model multiple DMZ layers that allow secure data flow out to corporate. And then we can ultimately help set up control rooms, redundant data centers to host that infrastructure, and build out really whatever SCADA product that operator might be familiar with. Or if it’s something that they already have running, then we can just build out, expand on what they already have. We’ve got a team of developers. We’ve worked together for fifteen or so years. They can do really anything. Any product, any top tier product in SCADA controls. So, like, Enterprise SCADA, Ignition, GeoSCADA, System Platform, Wonderware… we’ve got guys and gals that can work with all of that technology, and they’ve used it for a long time. And, of course, on the infrastructure side, I always say that your SCADA product, whatever it is, the application is only as good as the underlying infrastructure that it runs on. You’ve gotta build up the systems and networks very well to be fault tolerant, especially if it’s a critical asset in an environmentally sensitive area that you cannot afford downtime. Our teams, my other managing partner, Timmy Huynh, architects systems that are bulletproof from a redundancy standpoint, and then we layer the applications on top of it.

So that comes all the way down to, like, Ethernet handoffs to the controllers (PLCs) in the field and then all the way back to displays in the control center that the controllers (console operators) are sitting in front of.

08:10 – Casey

I’ve never been at the high level of this, but I’ve seen a lot of issues with control rooms, SCADA systems, having comms down in the field, having to send personnel out to physically make phone calls at what they’re seeing on their screen back to the control room because they’re not able to see that for whatever reason. So having those breaks in the link that’s tying everything together. I’ve also seen it with all these acquisitions, I’m sure there’s a lot of companies that are consolidating control rooms into one location. I know there’s a regulatory component behind it. The more control rooms you have, the more spots you can get audited. So sometimes they got a control room or also what they classify to be a control room. Right? They wanna make sure they have the minimal amount of control rooms and have all their resources pushed into one spot so they can protect themselves from a regulatory component too. We did that with a previous employer where we had a bunch of them spaced out, and we had places that we didn’t really deem a control room. But per the definition, it was a control room. We had to make changes. So, yeah, that’s interesting. With that, I guess, you get these corporate plans that get put into play. Say there’s an acquisition and they’re wanting to consolidate. What’s the typical area that y’all see the most breakdown between the plan and the end result whenever let’s say somebody acquires a new company, they put the plan together, they go and they try to connect the IT and the OT, you kick off the project. Where does that typically break down from what you’ve seen?

09:19 – David

A lot of it is just legacy infrastructure or the infrastructure that’s out there that is part of the asset that’s being acquired may not work seamlessly or might not be plug and play with the current system that the company that’s doing the acquisition already runs. So you might have legacy technology. You might have just a different brand or make model of a controller that doesn’t work cleanly with the product that you already have deployed, especially when it comes to getting data into getting data out of OT, into the IT side, making sure that all the pieces and parts in between work well and then they don’t break or they’re compatible. But more importantly, that you can still maintain that cybersecurity layer when you’re picking up other assets. If it might if it’s another location that’s in a different part of the country, you might have a different type of carrier or network that’s that you’re tying back into. So just thinking through or having a broad view of that holistic picture at the get go. But then once you start getting into the weeds, you talked about breaking down between IT and OT. You start getting into the weeds and you’ve got oh, okay… they’ve actually got serial connections all the way back and they’ve got plain old POTS lines out there bringing data back. Those are the challenges that you’ll run into during these acquisitions. And I’m thinking about it. We did a project a few years ago where they had dial up out to a field asset. They didn’t know that because the customers had a proper meter out there, like a 2000’s meter polling Modbus data. And we’ve got perfect measurement, but they’ve got dial up Internet to that site. So we helped them solve… this was in 2018, believe it or not. So we built them a dial up modem connection out to that site. We landed… we found a piece of equipment… we had to learn AT commands on these modems, but we got it to work. It was slow, but sure enough, we got all the meter data into their system. So it’s things like that. It’s a matter of just getting a broad view, getting a full view of what’s out there. Especially during acquisitions, the documentation might be lagging. What they have on paper doesn’t match what they have in the field. It’s a matter of problem solving between square peg, round hole. But that’s really where our shop comes in. We seem to do a good job there because we have a diverse set of engineers on our team. So we can look at the problem from multiple different avenues and, like, this POTS line solution was that. We had the network engineer saying we could do this, we could do that. We still had to convert to Modbus after that plain old telephone system. So it’s that we had a few products that we bench tested in the lab, ran it for a couple months. It seemed to work, and then took it out to the field, plugged it in, solved that problem.

12:16 – Casey

Yeah. And although the end result is probably great for y’all’s customer, I’m sure y’all get to be the bearer of bad news as y’all are working through that process of what they think they’re gonna have to do to get to where they need to be to what ends up that they have to do because y’all are finding stuff left and right. I guess your customers, are they typically easy on adapting to that? Or does the budget change all that much for findings like that? I guess there’s obviously gonna be some research and development to come up with a solution to that problem. But typically, is it a huge change on the overall budget for them?

12:47 – David

No. Not necessarily. I’m sure in some instances, can be. Or if it’s a totally redesign of that existing infrastructure that’s out there to make it work with the system that the customers have or vice versa. Or we’ve seen stuff where, like, the company doing the acquisition, the party that’s being acquired has got end of life equipment that you need to spend money to get that up to current before doing the integration. So those are, of course, like, large unknown costs that you find hopefully, you find it on the front end before as you’re doing your due diligence. But the things that we’re talking about just impact the timeline. Might not be big dollars to solve, but it might push you out a couple weeks while we’re figuring out how to get that thing back get that thing back working. But, yeah, legacy systems, especially on the OT side, like I mentioned, those things are just built to run and they’re still out there and they still work, But it’s a matter of making them work in the current landscape where there’s a large push to get some of the data into the IT side of the shop.

13:4 – Casey

I didn’t plan on asking this one, but just thinking it through. Do you ever get customers that have stuff globally as well as The United States where they’re having to have those systems talk, but the security requirements are probably different. And in some cases, I was reading an article not that long ago about forget if it was China or somewhere, but, basically, they had to have access to if you were to fly in with a computer, you had to give them your login information if they asked. Some of these places, they’re more than willing to tap into your data. Have you ever had to mess with that and get around that? Do you have to set up two separate systems to be able to not see certain data, or how does that end up?

14:25 – David

You can. Yeah. And it really depends on the policy for that customer. We work with a customer that’s got presence in Europe and here in The US. It’s like the data retention laws and all the data privacy laws. The one side has to pay attention to, but some of those, we need to pay attention to on this side if there’s like I mentioned, that data going across to the corporate network. We can set up independent, like, air gap systems so there’s no connectivity out. Truly, it just depends on what the customer’s requirement is. We’ve built systems out that probably if you look at it from a cybersecurity best practice standpoint, it still meets mettle. But could it be done better? Sure. But the customer’s requirement made it such that we had to accommodate some request to keep by either OT or IT functional. But, yeah, if it’s fully redundant, if there’s a totally separate set of hardware on the OT side and the IT side, typically, that’s what we prefer seeing. But there’s technologies nowadays that you can with virtualization, I’m sure you’ve heard some of that those terminologies. And you can still solve Purdue model architecture virtually. Yeah. And we had to do that for other operators as well.

15:35 – Casey

Yeah. I’m guessing it’s not extremely common, but with the cybersecurity stories I’ve seen in the recent past, something to think about. Okay. We’ll move subjects a little bit. So in oil and gas uptime and safety are nonnegotiable, but how do y’all evaluate new technology without introducing operational risk?

15:49 – David

Yeah. That’s a good question. Yeah. Safety and uptime, those are absolutely front of mind always. You cannot deploy anything that’s untested. That’s the bottom line. So maybe on the IT side, it’s easier to throw a patch out there or land a piece of hardware and test it. On the OT side, you cannot have downtime. So you mentioned uptime being front of mind. If there’s something that’s deployed that is untested oh, let’s go back to this… CrowdStrike was the most recent one that I can think of. So it was an update to their system that someone deployed without testing it thoroughly. And these end devices in the field accepted that update, and it bricked a lot of OT networks. We don’t on our side, we typically do not take the latest and greatest patches of anything because of this specific issue. We wanna make sure that the vendors have tested it, and it’s got a rev one or rev two behind it before then we load that as part of a change management program into any customer facing or customer system. You can’t deploy technology without it being tested even if it’s a semantic antivirus update. We, on our side, our standard is to not deploy the latest unless there’s a vulnerability that comes out that…  Fortinet is telling you, hey, China’s gonna get in if you don’t land this patch, then we evaluate from an emergency standpoint. But, yeah, typical patches, hardware hardware is a easier thing to deploy because you can test it on the bench in a lab, make sure that it works well. Production software is something that will always be one or two revs behind unless there’s something urgent that we need to jump in there and resolve.

17:28 – Casey

Yeah. I agree with the sentiment on that. I’ve been in a position where we were asked to basically bring in a new software. It was more on the OT side, but we were essentially going to be the guinea pig for this because there was no known like, I tried looking into it to see what other people were saying. I couldn’t find any studies or any kind of data around it because it was so new. It concerned me greatly, and I ended up not doing it initially. And then some of the folks in our industry did, and I got to talk with them as they experienced issues. And after they got it all sorted out, we went and did it. So I like that approach better.

16:01 – David

Yeah. You learn from, unfortunately, the mistakes that you see others make. Right? Yeah. On the OT side, your point is valid. Downtime is… oil and gas can’t stop, right? The energy markets expect and they predict a certain availability. So when that is interrupted, and especially if it’s interrupted by something that you can plan around, like these updates are landing new pieces of hardware. On the OT side, it’s a more methodical kinda thought through, but not deploying anything that’s untested.

18:25 – Casey

Yeah. I guess there’s times where people can be seen as courageous for taking that leap and then it working out, but it is a risk. So I guess with that, have you seen innovation slow down because of risk concerns where they waited and didn’t do the proper testing? Or rather, they chose not to do something because there was not the proper testing and then it somehow slowed them down, or does that ever come up? Or is it I would imagine there’s typically more upside to waiting, but I’m guessing SpaceX worlds. If you’re doing, like, NASA level stuff, sometimes, I guess, they don’t have that as an option possibly, but in our world…

19:04 – David

Well, mean, I think your point on SpaceX, how many rocket ships have they lost to controlled what do they call them? Departures or something. (Rapid Unscheduled Disassembly’s)

So, yeah, you can’t have those, certainly, on the pipeline oil and gas control side. Has innovation slowed down? Probably. But to your point, it was a risk aversion tactic so that it’s done methodically. You can make sure that it’s done safely in the long term. But the technology nowadays, like, even in the last fifteen years has expanded quite a bit. You’ve got lots more. We’ve talked about data throughput. We’ve got lots more visibility out to field assets. Everything is Ethernet now. In the past, it used to be serial. So, like, those improvements are still happening, and they’re happening fairly readily even in the on the OT side of the space. Nowadays, Starlink is out there for comms. It used to be all geosynchronous satellites now it’s low earth. Those technologies are being deployed securely. So the OT side is not, I wouldn’t say slow, but is may maybe more methodical on how new technologies are adopted and deployed.

20:04 – Casey

Yeah. I don’t know about you said you’re in Connecticut now. Right? But in Texas, it’s every fifth truck I see has a Starlink dish on its roof out here, especially where I’m at. It’s very remote, so it was a lifesaver. I’m on Starlink now. Previously, I was limited to 12 megabytes per second through a wired Uverse plan, so it was a lifesaver.

20:23 – David

Like I was mentioning, I grew up in Houston. I grew up in Texas thirty five, thirty seven years, something like that. We moved up here in 2022, and, yeah, there’s only one provider for Internet, and it was copper at the time. Now that same provider has fiber, but I had the same thing. I had a Starlink up on the roof to get some redundant connections because that thing would get choppy here and there all the time. But even that technology is not immune to compromising or whatnot, but you can certainly secure it. But, yeah, you gotta move with the industry or move with the technology as it changes.

20:59 – Casey

Yeah. And I may know the answer to this myself, this next question, but there’s always a cultural gap between the IT teams and operations teams. And when I say operations, more so on the field ops as I define it. But how does that show up in the oil and gas industry, and what have you seen actually work to bridge that?

21:20 – David

We see it all the time. I think one of the places that our company shines is that we can translate between those two skill sets or those two departments. So, like, the IT governance side always is up against the OT, make it work side. And you can achieve both goals. It might not happen as quickly as you want, and it certainly might not be as inexpensive as you want it to happen. But you can meet both needs on the IT and the OT side with the right either design or technology or whatever it might be convention that you’re dropping in. It’s I think from the IT side, understanding where field operations is coming from, this focus on safety and uptime, right, not deploying anything quickly. Things change very fast on the IT side with especially now, like, AI technologies. You can deploy software quickly. That’s something that even myself, I’m hesitant to make any quick changes on the OT side because, again, you don’t wanna incur downtime do something that’s gonna potentially cause the environment or people harm. Just understanding the long term and near-term requirements on both sides is helpful. And we’ve been in between IT and OT for so long that we can translate those, that level of communication between both and long term meet the needs that the operators have while also doing it to the policy that IT is requiring.

22:46 – Casey

So I’m guessing, like, the stakeholder that would reach out to you from an operations company would most likely be on more so on the IT side initially. But do y’all work with the operational leadership from companies to especially if you’re dealing with anything SCADA or control room based, you’re probably gonna have to. But who’s the primary driver from these companies that y’all tend to deal with? IT is always gonna be a big one. But as far as the final sign off on, yes, this is good, is it gonna be IT or is it operations, or is it like a mixture?

23:20 – David

It’s a mix of both. We report sometimes directly to the IT, the CIO, or the IT Director. In some cases, we’re reporting to the COO or the field operations manager. It just depends on the customer, really. That company might have both. Of course, they’ve got both IT and OT represented, but we will work with either side. And we play in between both of those groups because the it’s a technology driven company. So nowadays, of the technology is somehow connected on the OT side. There’s some connection back to IT. So our group, we receive direct (if were bidding something out) it could be the request coming from the operations group on the process control side or field operation side…. it might be like, communications is a good example. We need to get x and y communicating back to our pump station. It’s at this location. There’s no comms out there. How do we do it? So that’s an operations ask because they need to get data or whatever, they need to get something out to control some a valve or whatever that’s not currently part of their network, new construction. And on the IT side, it might be the same request, but someone on the IT side might be chasing it down. We’ve gotten pinged, and we’re currently doing thinking of two customers where one was an operations boss that came and asked, and one was an IT boss that came and asked.

24:39 – Casey

Yeah. I think, like I said, I haven’t been the driver of these discussions. But in a previous role, I got to deal with the folks that were over the control room as well as some of the IT personnel. And not to say that this is true across every company, but the IT personnel know what they need to achieve. They don’t always know what ops is trying to achieve and what’s supposed to talk to each other and what’s going to benefit us from a safety perspective. They basically just make sure that there’s no red across the screen. Everything’s up. Everything’s working. But whether or not it’s useful information for the field or if it’s the right information is a lot of times gonna be driven by operations. So I think there’s gotta be a collaboration there. I just didn’t know if it starts because I was thinking to myself, maybe the initial request would start with the guys from IT, but by the end of it, you got all these ops guys butting their head on, hey. You know, they do this because they felt like they would be driving that end result because in a way, there is obviously more ownership for the OT side for them. Not that IT wants to see anyone get hurt, but that’s their front line duty as a ops personnel. Just thought I’d throw that out there. I guess looking forward for oil and gas leaders just starting to modernize their IT-OT environments, where should they focus first, and what should they avoid?

25:53 – David

I would start with my experience is just updating documentation to actually what you have out there. If you make a decision, we’re gonna deploy x product and secure off this portion of the network, it may not work with what you’ve got out in the field. So having a solid understanding of protocols, whatever it might be, hardware, network layers, personnel, operations, get all that fully understood. It’s a big ask, but having a solid understanding for what’s actually going to be impacted by this change that you’re deploying is first. And then selecting the product that can keep the operations uptime or keep the status quo as much as possible. If there is going to be a change in the status quo, especially for the operators out in the field, making sure that they are aware, they’re they have buy in and they have training prior to any of those changes being made is key. And that’s all before any of these products are actually deployed out.

26:53 – Casey

Yeah. Now I had a not the same but similar question on a group that I talked to previously, and we were talking about sometimes people, the way they store data within a company is not consolidated. So you have all these different groups that are working separate… they’re in their own little silo, and people will store critical information on their, like, personal computer hard drive rather than, like, on a shared source. And you’re trying to tap into all this to you know, let’s say you acquire a new company. You gotta go figure out where’s all this data. Does it exist? Do we have to have a recollection effort where we’re coming in and trying to find everything and make sure that all of their equipment has the right numbers assigned and yada… There’s also elements where we use some stuff for cathodic protection monitoring. And every once in a while, a company would just say, hey. We’re not gonna support that anymore. So then you have to figure out some kind of workaround or switch all of your monitoring devices because they just decide that they’re gonna switch to a new product and they’re not gonna support the old product, then you gotta get with the time. So I’m sure y’all run into that and trying to address how to get around that or to get them up to speed.

28:00 – David

We do. Yeah. It can be tough. You just get a tombstone on a piece of equipment and did exactly what you needed it to do. And now…

28:08 – Casey

Yeah. Everything’s great until it wasn’t. Yeah.

28:13 – David

So those migrations are they can take time, but it’s doable. It’s all a matter of, again, finding the right product and making sure that it keeps it meets the needs on both operations and if it’s measurement, you know, that’s out of the shop as well.

28:23 – Casey

I’ll leave with one question here. What is something every operator should be asking themselves right now if they’re thinking about modernizing their ITOT systems or if they’re about to possibly call somebody like you or your company? What kind of questions should they ask themselves to make them come to that decision?

28:40 – David

Yeah. Lots of that. It can start on both IT and OT. It’s a matter of what are they trying to improve. If it’s, like, you talked about reduced man hours in the field for callouts to this and that location. If it’s an improvement of that person’s efficiency doing their function, start out with that objective. And if it’s decreasing downtime, increasing safety, increasing visibility, and then how to go about doing that, you can do it. Have you heard this good, fast, cheap scenario? They say you could you could do it good, you could do it fast, you could do it cheap. Pick two. You can’t have you all three. So on the Lindsey’s side, we if it’s good and fast, it’s going to be expensive. If it’s cheap and fast, it’s gonna be poor quality. And then if it’s good and cheap, it’s gonna take a long time. We won’t ever do poor quality work here at Lindsey. So we’re not gonna be the cheapest. We know that. If you want it fast, it’s gonna cost some amount. It’s gonna be more expensive. So you’ve gotta ask that question too for if it’s some safety improvement, if it’s awareness improvement, if it’s a staff efficiency objective, how would you wanna go about achieving that? How quickly do you wanna have it done? And then what’s the budget for you to achieve? And then you can start there. There’s lots of players in this space. You can

There’s lots of players in the space. you can certainly find people who are willing to solve those problems, but how they go about doing that also is something that those operators need to pay attention to, track record matters as well, right? We talked about deploying Hardware without being tested. I would ensure that the people that you’re employing to deploy some of these technologies have the track record, right. Call up references, things like that. And I’m always weary of the fast and cheap players in the space.

Casey – 30:28

Yeah it’s always unfortunate because I’m trying to come to a close and you hit on a topic that I can talk about for quite a long time. So you mentioned safety you mentioned  the work hours… We started to get into that with a previous employer where when people look at safety, where I’m at in West Texas, there’s a lot of vehicle incidents. So the work hours component with safety, we were all about trying to reduce windshield time. So if we can do things without sending a human out there to just be on a daily route for the sake of it, where you’re driving a couple hundred miles to do a route, that may be you wouldn’t need to if we had the right systems in place that would specifically send us to the places we needed to be, and not just have this nonchalant… Hey we’re going to check it out just in case. Once you modernize your system, you were able to really hone in with Where You Are resources are at instead of putting them at risk for maybe no reason. So I think that there’s a huge upside in that perspective.

David – 31:23

It’s true, I’m thinking, i’m smiling, because I’m thinking of a guy we work with in the Bakken. He’s a pump mechanic, very good pump mechanic, but part of his job function was to go pull meter tickets. Part of while he’s maintaining equipment, field LACTs, whatever it might be, pipeline pumps, he’s pulling meter tickets and; colorful dude, love the guy, still work with him. We deployed out this comms system to centralize ticket warehousing. And it saved that guy hours of drive time and it centralized collection. Got better data acquisition, more frequent collection, and freed up his time to go do what is more meaningful for pipeline up time… Maintaining equipment. Sure, it costs some amount of money to do that. But, personnel safety is important, so he’s not spending near as much time doing what he’s doing. He’s focusing more on his core job function to keep the pipeline operations more resilient and with higher up time. And it helped on the IT side like we talked about, it helped IT get better visibility to cash register data on the accounting side that that group needed.

Casey – 32:31

Yeah that’s the initial thought that people have. ‘They’re trying to reduce our Workforce.’ Figuring out how to free your folks up to do things that matter, prioritization of their hours, it’s not so much about trying to reduce the staff, necessarily. There’s a component of that, don’t get me wrong, but I think there’s so much that pipeline operators could get done if they had the hours freed up from doing all these redundant tasks that would help. No it’s great talking with you, I’m sure we could keep going like I said, before we started recording, we could go for hours, but, is there anything that we didn’t touch on that you’d like to discuss before we come to a close?

David – 33: 11

No, I think we hit it well. I’ll finish off by saying, you mentioned safety and uptime; yeah, every system, every operator that we’ve worked with, that we still work with, they are highly aware of safety to the environment and safety to their people and we love working in this industry. And it’s always impressive to look back and see how far, even on the OT side how far it’s come, with always keeping up-time and safety front of mind. Yeah, happy to be involved, thanks for inviting us out.

Casey – 33:41

Yeah well I may invite you again. We’ve got enough for round two possibly in the future so.

David – 33:44

Yeah, set it up.

Casey – 33:45

I appreciate it. I appreciate your time today, thank you for coming by call I know it took some time for us to get this set up but here we are.

David – 34:04 

Thanks again Casey. We’ll talk soon.