This week’s Pipeliners Podcast episode features Ross Adams of EnerSys Corporation explaining what natural compliance is in the pipeline control room.

In this episode, you will learn why pipeline operators should strive for natural compliance in the control room, the three systems required to achieve natural compliance (program management, process management, and task execution), why natural compliance is increasingly important during this current period of frequent and thorough PHMSA CRM inspections, how natural compliance is achieved in the context of Alarm Management, and more topics.

Natural Compliance in Pipeline Control Room: Show Notes, Links, and Insider Terms

• Ross Adams is the General Manager of EnerSys Corporation. Connect with Ross on LinkedIn.
  • Listen to Ross’ previous appearances on the Pipeliners Podcast.
  • EnerSys Corporation is a recent sponsor of the Pipeliners Podcast. Find out more about how EnerSys supports the pipeline control room through compliance, audit readiness, and control room management through the POEMS Control Room Management (CRM Suite) software suite.
• Natural Compliance in the context of pipeline control room operations is setting up systems where the records that are required to validate compliance with regulations are automatically created in the background as the work is being performed, eliminating a second “unnatural” step of creating compliance records. The compliance records become a natural output of the work that is being performed.
• PHMSA (Pipeline and Hazardous Materials Safety Administration) is responsible for providing pipeline safety oversight through regulatory rulemaking, NTSB recommendations, and other important functions to protect people and the environment through the safe transportation of energy and other hazardous materials.
• The CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
• The Operator Qualification Rule (OQ Rule) refers to the 49 CFR Parts 192 and 195 requirements for pipeline operators to develop a qualification program to evaluate an individual’s ability to react to abnormal operating conditions (AOCs) that may occur while performing tasks.
  • AOC (Abnormal Operating Condition) is defined by the 49 CFR Subpart 195.503 as a condition identified by a pipeline operator that may indicate a malfunction of a component or deviation from normal operations that may indicate a condition exceeding design limits or result in a hazard(s) to persons, property, or the environment.
• Alarm Management is the process of managing the alarming system in a pipeline operation by documenting the alarm rationalization process, assisting controller alarm response, and generating alarm reports that comply with the CRM Rule for control room management.
  • Alarm rationalization is a component of the Alarm Management process of analyzing configured alarms to determine causes and consequences so that alarm priorities can be determined to adhere to API 1167. Additionally, this information is documented and made available to the controller to improve responses to uncommon alarm conditions.
    • An Alarm Management program is a method to manage the alarm rationalization process in a pipeline control room.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at a remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
• MOCs (Management of Change procedures) are required in the PHMSA CRM Rule as part of the Change Management requirements (192.631(f)) and (195.446(f)) stating that each pipeline operator must assure that changes that could affect control room operations are coordinated with affected control room personnel.
• Process Safety Management (PSM) refers to a set of interrelated approaches to managing hazards associated with the process industries and is intended to reduce the frequency and severity of incidents resulting from releases of chemicals and other energy sources.
  • Pre-Startup Safety Review (PSSR) is an integral part of a Process Safety Management Program where safety and efficacy are reviewed before bringing a new process online.
  • Process Hazard Analysis (PHA) analyzes the potential causes and consequences of an incident involving natural gas, hazardous liquids, or other product in a pipeline system.
    • Listen to Stephen Swanson of Noble Energy discuss Process Safety Management and Alarm Management in Pipeliners Podcast Episode #96.

Natural Compliance in Pipeline Control Room: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 186, sponsored by P.I. Confluence, providing software and implementation expertise for pipeline program governance applied to operations, Pipeline Safety Management, and compliance, using process management software to connect program to implementation. Find out more about P.I. Confluence at piconfluence.com.

[background music]

Announcer:  The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now your host, Russel Treat.

Russel:  Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time. To show that appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is Ian Bowe at Aspire Energy. Congratulations, Ian, your YETI is on its way. To learn how you can win this signature prize, stick around till the end of the episode.

This week, Ross Adams of EnerSys Corporation returns to talk about natural compliance as it relates to Alarm Management in the control room. Ross, welcome back to the Pipeliners Podcast.

Ross Adams:  Thanks, Russel. It’s always a pleasure to be with you all. Feel like I might have been with you earlier in the year and blinked, and here we are. It’s June. I don’t know where the year went. I’m certainly pleased to be with you and all your listeners.

Russel:  It was about 30 episodes ago.

Ross:  Holy moly.

Russel:  I try to keep track of that. At this point, you are our most frequent guest.

Ross:  [laughs] That’s great. That’s great. I appreciate that honor.

Russel:  [laughs] Look, I brought you on. I want to talk about natural compliance because that’s something that you and I have been talking about and tossing back and forth for a while. I thought it’d be good to just capture our conversation because I thought other people might be interested in what this whole idea is and such.

Let me start. I want to just ask this question. What is natural compliance, and why should I care?

Ross:  The first time we started kicking around just that phrase, I said, “Gosh, this kind of sounds like a little bit of a marketing buzzword.” It might be. It is catchy.

When I started to think a lot about what we’re working to with our customers, what is our desired outcome in the relationships that we have, and the work that we’re doing both through our software and through our services trying to provide this holistic solution, I really kept landing in a place where I want our customers to — through the course of working with us and using the systems that we’re helping put them in place — they’re naturally complying with the rule.

They’re getting operationally a lift as it relates to operational effectiveness. In the course of their day to day, the things that they’re doing are, as a byproduct, putting them into compliance, things like documentation and recordkeeping are certainly areas that come to mind, where there’s a value in this concept of natural compliance. It’s really where we want to get to as an industry.

Russel:  What I would say is I do the work, and compliance happens. What that really means is whatever system I’m using to do my job, the records that are needed for compliance are being created automatically and retained by the system. I don’t have a second step to create my compliance records. The compliance records are just the natural output of the work I’m otherwise doing.

That sounds easy. It sounds straightforward, but how do you do that?

Ross:  You said it. The keyword here is systems. You have to have systems in place. Without systems, compliance doesn’t really come naturally. The industry, as it’s made a transition over the years, at first, I would venture to say it looked at compliance as one more thing we have to do. It was a stretch outside of ourselves.

When you go back and look at a lot of the early recommendations from the NTSB and others who did research, especially around the early days of the precursor to Control Room Management, what they were finding was that a lot of folks were doing things well. They weren’t doing them we’d say naturally.

There weren’t the systems in place to support the ongoing sustainability of doing things the right way or the structure to ensure complete buy in across multiple we’d call them safety programs, or multiple business units, or multiple operating areas.

Russel:  That’s probably right. The word you use, structure, everybody working under a common structure. Certainly, once you’re regulated, what you have is more structure and formality around that structure.

I’ve got to have plans. I’ve got to have procedures. Then I’ve got to follow those plans and procedures, which has implications related to OQ and training and so forth. Then I’ve got to create records that I’m doing that, that I’m doing the training and that I’m doing those tasks the way that the procedures are written.

What that infers is what are the nature of the systems or system that I need. One of the challenges is these are very different kinds of systems.

I want to throw something out there. I’ll ask you to comment on it. I think about these systems as three pieces. There’s a program management system. There’s a process management system. Then there’s systems for task execution.

Let me break that down a little bit. Program management would be whatever system I’m using to capture my policy and procedure and to perform my analysis to make sure that my policy and procedure properly addresses what I’m required to do given the Pipeline Safety Act. That’d be the program management aspect.

Then, there’s process management, which is “here’s all of these things that need to get accomplished.” I’ve got to do Alarm Management, I’ve got to do control room review, I’ve got to do fatigue analysis, all these things. I’m just talking about control room things. There’s lots of others within the entirety of the pipeline safety world.

Then lastly, I’ve got to have a system for doing my task. In the control room, I’ve got to do alarm analysis. I’ve got to do shift handover. I’ve got to do scheduling and fatigue management. I need tools for doing all those things.

One of the challenges to make what sounds easy and straightforward is all of a sudden it’s not so easy and straightforward when you start talking about all those different kinds of systems. What’s your take on that?

Ross:  [laughs] The model that you’re suggesting makes a lot of sense. I’m going to spit it back at you. I’m going to put it in Control Room Management sense just because that’s, at EnerSys, really where we work, but the same methodology applies, as you said, to all safety programs. From a program management standpoint, to me, that’s foundational.

That’s establishing my programs, establishing my policies and my philosophy, so a system for establishing my Control Room Management policy, my Control Room Management Plan [CRMP], and ensuring that that foundation — that policy — is in compliance, that I’m not writing something that’s going to wind up biting me later on as we get into an audit or as something unravels in my day-to-day.

Process is the next step. I’ve got my policy. Now, I need to actually implement some of this, some of the things that I’m saying. How is it that I’m planning to actually go about the execution?

Then, lastly, task execution, that’s doing the work itself and then making sure that, in doing the work, I’m adequately creating the records and communicating what needs to be communicated across multiple business units, and then, of course, having the records down the road as I need to look back at them, whether it’s in an audit or what have you.

There’s certainly a workflow to this that makes a whole lot of sense and provides that structure that we were talking about. At the end of the day, trying to do all of this, trying to implement a safety program, trying to operate a business unit without a structure, it’s a heck of a lot more work, right?

Russel:  Ultimately, it is, for sure, yeah. When I’m listening to you talk about this, I’m thinking about what are the systems people are currently using. For program management, typically what people are using is Microsoft Word and Excel spreadsheets.

Ross:  And a whole lot of tabs on your Internet browser, trying to jump back and forth and reference all kinds of documents all over the place.

Russel:  Then for process management, that is all over the place. I’ve seen people using SharePoint for that. I’ve seen them using any one of many, many, many process management tools that are out on the market.

Task execution, all of those tools are specific to the task. Somebody who’s doing an integrity management function is using a different tool than somebody who’s doing a shift handover. There’s a large number of these systems that are out there, for sure.

Ross:  I’ll tell you, there’s some drawbacks to that, to the current way of doing things, if you’ll allow me to speak to that a little bit. I think part of the challenge is…You just mentioned a bunch of different programs that are all over the place. Word, Excel, and what have you, they create these outputs, these documents that live in different places.

There’s not a lot of commonality that the user is going to wind up storing them where they’re going to store them. Being able to find those records down the road can be difficult certainly as there’s turnover within an organization, but also there’s not a lot of communication across the business units for that safety program areas or asset areas because that information is so segregated.

You wind up creating the silos within your organization as opposed to a more natural workflow where there’s a lot of involvement, crossover, and integration.

Russel:  Ross, that’s such a good point. I use the term a lot when I’m talking about things like this. I’ll say, “Where gravity will take you.” What I mean when I’m saying that is this is just where organizations will typically land if they’re not given a better alternative.

Where gravity takes you around the program stuff is Word to write the documents, Excel to analyze the documents, and SharePoint to store the documents. That’s how you tend to do the work, but the reality is the people who are actually using the documents to do the work, they’re grabbing something off of a file share because it’s handy.

The nature of those tools in that processes — over time — can become difficult to know, where is the current, most accurate version of the policy, procedure, or whatever? It can be quite challenging. Your point about siloing, the nature of pipelining I think is that we tend to silo around two things — technical disciplines and assets.

If I’m a pipeline operator, and I’ve got a gas pipeline, I’ve got a liquids pipeline, then I’m going to have silos around those two things and for some valid reasons.

But, the challenge with all of that is it’s not just about the systems I’m using. It’s also this. If I’m really going to get to natural compliance, then all of this data I create has got to be integrated in some way, so that I can pull it all together so that I can grab it when I need it, and I quickly and easily find the most current version of the thing I’m looking for — whether that’s a record, program, document, or whatever.

Ross:  That’s certainly true. Then, also, when you get into actually the task execution…Really, I guess to take a step back, it’s at all three levels.

From a task execution standpoint — and we see this in a control room management role — there are times in which the controller needs to be notified of certain things. The field work changes in SCADA or in the field, what have you, and where you’ve created a gravity-fueled system for approaching compliance, and you have those silos as an output of that, the things that we want to have happening to make sure that our operations are effective and that we’re complying with what the rule says around the MOCs or whatever it happens to be, those things aren’t happening.

Or, if they are happening, they’re happening infrequently, and they’re a big lift to make them happen.

Russel:  Again, Ross, it’s a really good point. I’ll say this a different way. Where you have these areas in order to implement an effective program, it cuts across technical disciplines within the company. Alarm Management is a good example of that from a control room perspective because I can’t do Alarm Management just in the control room.

Ross:  That’s right.

Russel:  That requires interaction with automation, maybe facilities management, SCADA. I’ve got to interact with multiple organizations to do Alarm Management effectively.

What tends to happen is these things that cut across multiple organizations, they’re cutting across multiple tools. You’ve got the issues of where these people work and other complexities that just make pulling all this together in a natural way really challenging.

Ross:  Let me see if I can run through that Alarm Management example and provide…

Russel:  Before you do that, if I might, I want to talk a little bit more about this integration because I want to talk about what does that mean. I think there’s two primary frames in terms of integrating, because we’re going to have silos or focus areas around technical disciplines, and we’re not going to get away from that.

The tools we use to do those tasks are going to be very different because the tasks we’re doing are very different. That leads to ways that we need to integrate things. I need to integrate things across assets.

Ideally, all of my oil pipelines, they would be very…All the information about that would be integrated, be centered around that asset, likewise with the gas pipeline, likewise with the gathering system, and so forth.

The other thing — and this is where the complexity comes in — is I want them to be integrated around the safety program. I want to know how each of these things that I’m doing and the records that I’m creating relate back to the safety program. It’s a two-dimensional integration that I need to accomplish. Does that make sense to you? Do you think I’m out in the weeds a bit?

Ross:  I think it makes sense. If I’m a listener, I’m wondering about my systems, what I’m doing. Do I have pain in this area around national compliance, or am I going where gravity leads me? It would come to mind, “Hey, I’ve got silos or struggles in integrating around assets, as well as around either the safety programs or the subject matter expertise.”

Certainly from my position, I see this and hear this from a lot of folks as we talk to different people in industry — in the control room and outside of it. You’re on point.

Russel:  You were going to walk us through an Alarm Management example. Why won’t you go ahead and do that? The best way to start is maybe talk us through that Alarm Management example in terms of what are people doing now?

Ross:  Sure. [laughs] I’m laughing because you might be the expert in that area.

Russel:  [laughs] I could walk us through it and let you comment on it if you’d rather do it that way.

Ross:  Yeah, go ahead.

Russel:  There’s three components to your Alarm Management program in my view. One is I’ve got to have an alarm philosophy, an Alarm Management plan, and I’ve got to review that once a year. That’s one aspect of the program.

Another aspect is I’ve got to do monthly alarm analysis. Then, coming out of that alarm analysis, I’ve also got to do workload analysis and then make sure I’ve got time enough to respond to alarms. I’ve got to do alarm analysis to make sure I’m getting the good alarms that are valid, accurate, and manageable, and so forth. Then, I’ve got corrective actions I have to do.

What you would find typically is the program documents are going to be in Word. The analysis around those documents to make sure they conform to the program is going to be in Excel. Those things might live in a SharePoint repository.

The tool I’m using to do my monthly alarm analysis is either going to be a third-party software for that purpose — and there’s a number of them out there — or it’s going to be something I’ve built into my SCADA system to do that analysis and reporting.

The tool I’m using to capture my corrective actions, that can get quite complicated because I could be using one thing in the control room, but what people are using in the field to do their maintenance, and work order, and MOC activity might be something different.

I’m going to have a number of different tools that I’m using, and oftentimes what’s going to happen is when you’re in an audit somebody’s going to say show me your corrective actions for the month of July, just picking a month.

Okay. Let’s look at this corrective action. Show me where it was implemented. Okay. Now, for that corrective action, show me where this was communicated back to the control room and the controllers who worked that area of responsibility all had an opportunity to review it before it was done and were educated when it happened.

That would be a very typical kind of train that an auditor might ask you about. I’m going to be looking in my email, I’m going to be looking in my filled work order system, I’m going to be looking in my SharePoint system. I’m going to be going multiple places to find this data for sure. Right?

Ross:  Yeah. That’s true. There’s a couple other breakdowns that can exist in the way that you set a lot of this up. There’s work that’s being done on the front-end by the engineering groups through PHAs and PSSRs. It could very easily — that information can go straight from engineering to SCADA and not pass through the control room.

Certainly there’s some regulatory guidance that suggests that when you’re talking about determining set points, determining alarm priorities, and all of that work, the control room’s got to be involved, and participating, and contributing.

Russel:  That’s a process management issue because that’s a process that’s cutting across multiple organizations.

Ross:  Certainly.

Russel:  Or multiple disciplines.

Ross:  Certainly. Two, as your system is in and as it needs to be continuously improved, you’ve got bad actors or what have you, that’s information that has to cross disciplines as well. You’re going from the control room to the field or the control room to SCADA and having to communicate.

If there aren’t systems in place that have that commonality, that integration, common places where everyone can look to see this work needing to be done and to making sure that the communication loops are closed, you’re going to struggle to resolve a lot of these issues.

One of the things that PHMSA is going to be looking at is, “Hey, do you have a standing list of all your alarm program deficiencies? Are you working those to resolution in a prompt manner?”

Russel:  That’s right. Run me through, in an ideal world, what would this look like.

Ross:  Start with program management. We want to establish, at the front-end, that foundation for natural compliance and operational effectiveness. For Alarm Management, if I’m developing an Alarm Management program, I might have a section of my Control Room Management Plan dealing with Alarm Management, setting up my policy.

I probably have an alarm philosophy document. Then, I’m probably also going to be setting up procedures. That’s where you start to go from program to process, is in the procedure space. Ultimately, I’m establishing this foundation for compliance and operations up front, checking to make sure that I’m not creating gaps for myself.

Then, once that policy and that philosophy are set, I’m developing the procedure, something that’s executable, that has owners, that can be scheduled and have a routine associated with it.

If there are individuals from multiple disciplines or multiple groups within your company that have to collaborate on this, then everyone should be on board. Everyone should understand the policy backing and the implementation side of things as it relates to the process. Then when it comes time for task and execution, we’re moving through this system, where there’s commonality and everyone has eyes on.

For example, you talk about tasks. If you’ve got a bad actor alarm and the controller needs to identify that. They need to identify that. They need to flag it and then put in a work order to have that corrected or form a callout task.

Do they have a system in place where they can do that just maybe from their logbook or from a place where they’d naturally go to and then have the communication; the integration with the field or the SCADA team to where that issue can be resolved? Then, the controller can then know that that issue’s been resolved.

Moving past that, as we’re taking a look — maybe on a monthly basis — at all of our AOCs or our bad actor summaries or even, on an annual basis, performing our annual reviews and we’re understanding where our issues are, we’re working to not only continuously improve our implementation, but go back to the beginning and improve our policies and our philosophies and then our processes as well.

It’s really a circular workflow. The goal is that by having — I would, obviously, always suggest software is a great place to start this conversation — anyone who needs to be involved in the conversation have eyes on what’s going on so that there’s great communication across the different groups and great support between the different groups as well.

Russel:  Again, I think that’s well said, Ross. The interesting thing in all of this is you’re talking about…People probably have a hard time visualizing how you do this. One of the key things is that all the records that are being created have to be stored in a way that I can pull those records up by asset and by safety program. That is one of the key elements to this.

There’s got to be a place to go to navigate to that data from the safety program, because that’s what you’re doing when you’re in an audit, right. I’ve got to navigate to the data from the safety program. Then, to do the work, I’m typically navigating to the data from the perspective of the asset.

Ross:  Yeah, that’s right. So, let’s say you were able to put this system into place however it winds up looking for you. There are really some wins that come out of this approach — this natural compliance approach. They are twofold.

One, I think when it comes down to it on a day-to-day basis, you’re going to be more effective. Your teams are going to be working better together. Your controller is going to have better situational awareness. Your issues are going to be resolved, your outages, your downtime. All that, that’s going to go down, which means your profitability goes up. That’s the practical side of things.

From a compliance standpoint, if all of what I just said was true is true, and all of your documentation is integrated, stored in one spot, and readily available in the event of an audit, your audit experience is a heck of a lot easier. To be honest, that’s super important more so now than it ever has been.

Not to make anybody nervous, but all the feedback we’re getting from folks across the industry is as they’re going through their audit experiences, it’s clear that PHMSA is getting more difficult. They’re getting more thorough. They’re asking tougher questions. They’re going off-script. They’re doing things that cause the operator work.

If you’re using that system where you got the Word documents, Excel documents, and SharePoints, and everything’s in different spots, that experience becomes a lot more painful.

Russel:  I’ve heard of people in control room putting a team together and spending six weeks getting ready for an audit, just pulling records together, right?

Ross:  Yeah, and still having to run up and down the stairs to pull records at the end of the day or during the audit. That’s not where you want to be. It’s a reality of where we’re at, and that’s okay.

What we’re discovering is, as we all lean into this future of Control Room Management or any of the other PHMSA-related safety programs, and we mature in those spaces, that there’s a better way to do it. I think natural compliance is it.

Russel:  I agree with you. That’s certainly the objective. As people are looking at alternatives for what they’re doing to execute and manage their safety programs, they’re going to be asking the questions around, “Well, tell me how this system works? How are those records going to be stored? How do I pull them up when I have an audit? What do I need to do to teach my people to use all of this? What’s available to management or to be able to supervise and make sure these processes are working holistically?”

Then, ultimately, if you do all that, one of the beauties is if I’m able to get all this data, put together, and store in a structured way, that supports the whole Pipeline SMS thing because it makes the “Check-Act” part of the program easier to accomplish.

Ross:  What you find is program, process, task, execution. It winds up looking a whole much like Plan-Do-Check-Act. It’s the same circular workflow.

Russel:  [laughs] It is. It’s the same thing. It’s exactly right. You know what? I think that’s a great place to end this conversation. This has been awesome, Ross. I appreciate you coming. Man, we’ll have you back, and we’ll continue to have the conversation.

Ross:  Absolutely, grateful to be here. Thanks for the opportunity and really enjoyed it as always.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Ross. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.

If you’d like to support the podcast, please leave us a review on Apple Podcast, Google Play, or on your smart device podcast app. You could find instructions at pipelinepodcastnetwork.com.

[music]

Russel:  If you have ideas, questions, or topics you’d be interested in, please let me know on the Contact Us page at pipelinepodcastnetwork.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords