In this episode, Weldon Wright speaks with Brian Sowell, Group Product Manager for Measurement at Quorum Software, about the evolution of gas measurement systems over the past two decades. The conversation explores Brian’s extensive experience with multiple systems—including Quorum Measurement, PGAS, and FLOWCAL—and how industry demands have shaped the capabilities of modern measurement software. The episode highlights how measurement systems have grown from basic data collectors to sophisticated tools supporting data validation, regulatory compliance, and seamless integration with broader operational and accounting systems.

Measurement System Trends Show Notes, Links, and Insider Terms

• Measurement System is the software platform responsible for collecting, validating, editing, calculating, and distributing oil and gas measurement data to downstream systems such as accounting, reporting, and regulatory compliance.
• FLOWCAL is a widely used commercial measurement data management system developed by Quorum Software, designed to process gas and liquid measurement data in compliance with industry standards.
• PGAS is a legacy measurement system acquired by Quorum that historically served gas measurement needs and contributed functionality to later platforms like FLOWCAL.
• Quorum Measurement (VAST) refers to Quorum’s early internally developed measurement application, originally called Volume Acquisition System Tool (VAST), which evolved into Quorum’s measurement offerings.
• Field Applications are software tools used by technicians in the field to collect, validate, and manage measurement-related activities such as proving, testing, and calibration.
• TESTit is a Quorum field application used to schedule, execute, and document field measurement activities, such as meter tests and maintenance.
• PROVEit is a field application focused on prover-based meter validation, particularly for liquid measurement systems.
• CALCit is a Quorum application used to calculate and validate meter calibration results.
• PYCit is a Quorum field application associated with pressure, volume, and temperature-related measurement data handling.
• ANALYZEit is a Quorum application added to support enhanced data analysis and insight generation from measurement data.
• Flow Computer is an electronic device installed at a meter site that calculates flow rates and volumes using sensor inputs such as pressure, temperature, and differential pressure.
• SCADA (Supervisory Control and Data Acquisition) is a system used to collect real-time operational data, including measurement values, from remote pipeline and facility assets.
• Hourly Data refers to measurement values recorded and processed at an hourly resolution, reflecting the increased granularity required by modern measurement systems.
• Laboratory Samples are gas or liquid composition analyses provided by labs and used by measurement systems to calculate heating value, density, and energy content.
• Field Data Capture Systems are digital tools that collect measurement and operational data directly from technicians working in the field.
• Data Consolidation is the process of aggregating measurement data from multiple sources—SCADA, labs, field tools—into a centralized system for validation and processing.
• Anomaly Detection is the automated identification of unusual or suspect measurement data, such as missing values or readings that fall outside historical norms.
• Validation Routines are system rules and checks used to determine whether incoming measurement data is complete, reasonable, and consistent with expectations.
• Exceptions are flagged data points or time periods that require analyst review due to validation failures or anomalies.
• Data Editing is the controlled process of correcting measurement inputs (pressure, temperature, DP, etc.) and recalculating volumes using approved industry standards.
• Audit Trail is the recorded history of data changes, including who made edits, when they were made, and why, supporting regulatory compliance and accountability.
• Orifice Meter is a common gas measurement device that calculates flow based on differential pressure across an orifice plate.
• Turbine Meter is a flow meter that measures volumetric flow rate based on the rotational speed of a turbine placed in the fluid stream.
• Ultrasonic Meter is a modern flow measurement device that uses sound waves to calculate gas velocity and volume.
• AGA (American Gas Association) is an industry body that publishes standardized gas measurement calculation methods widely used in custody transfer.
• AGA 3 is the AGA standard governing orifice meter gas flow calculations, frequently referenced in gas measurement systems.
• API (American Petroleum Institute) is a major industry organization that publishes standards related to oil and gas measurement, operations, and safety.
• GPA (Gas Processors Association) is an industry organization that develops standards related to gas composition, heating value, and physical properties.
• Liquid Measurement refers to measurement activities associated with crude oil and refined products, typically governed by API standards rather than AGA standards.
• Integration is the automated exchange of data between measurement systems and other enterprise applications such as accounting, pipeline, or work management systems.
• API Integration refers to the use of application programming interfaces to enable real-time, event-driven data sharing between systems.
• Event-Driven Integration is a model where data is transmitted automatically when changes occur, rather than on a fixed batch schedule.
• TIPS is Quorum’s plant and pipeline accounting system that receives validated measurement data for financial and operational reporting.
• Pipeline Accounting is the process of allocating volumes, energy, and value across pipeline systems based on measurement data.
• On-Prem Deployment refers to software hosted and maintained on a customer’s internal servers and IT infrastructure.
• Hosted Environment is a vendor-managed deployment model where the software is hosted externally but not necessarily fully SaaS.
• SaaS (Software as a Service) is a cloud-based deployment model where the vendor hosts, maintains, secures, and updates the software.
• Infrastructure refers to the servers, databases, networks, and IT resources required to operate large-scale measurement systems.
• SOC 2 Type 2 is a third-party security certification that evaluates a vendor’s ongoing controls related to data security, availability, and confidentiality.
• Cybersecurity is the practice of protecting measurement and operational data from unauthorized access, breaches, and cyber threats.
• Return on Investment (ROI) is the financial benefit gained from adopting a SaaS or modern measurement system relative to its cost.
• Round Table is a structured customer feedback session used by vendors to gather input on future product direction and priorities.
• Product Roadmap is the planned sequence of software enhancements driven by regulatory requirements, customer feedback, and innovation goals.
• Table Stakes are baseline capabilities that a measurement system must support, such as current industry calculations and regulatory compliance.
• BLM (Bureau of Land Management) is a U.S. federal agency whose measurement-related regulations affect certain oil and gas operations on federal lands.
• Directive 17 is a Canadian regulatory directive governing measurement and reporting requirements for oil and gas production.
• Usability Improvements are enhancements focused on making measurement systems easier and more efficient for analysts and technicians to use.
• M&A (Mergers and Acquisitions) refers to corporate activity that often drives rapid growth in assets, meters, and data volumes within measurement systems.
• Expert System is a software capability designed to replicate expert-level decision-making by automating routine judgments and validations.
• AI (Artificial Intelligence) is used to assist analysts by reducing noise, guiding investigations, and supporting decision-making in measurement workflows.
• Machine Learning is a subset of AI focused on pattern recognition and predictive insights, such as identifying likely sources of imbalance or missing data.
• Digital Assistant is an AI-powered interface that allows users to interact with the system using natural language to get guidance, training, or answers.
• Natural Language Interface enables users to ask questions in plain language rather than navigating complex menus or documentation.
• Balance refers to the comparison of measured inputs and outputs across a system to identify losses, gains, or data issues.
• Cross-Platform Reporting is the ability to analyze and report data across multiple integrated systems, such as FLOWCAL, TIPS, and TESTit.
• Public APIs are externally accessible interfaces that allow customers and third-party systems to securely access measurement data.
• Trending is the analysis of historical measurement data to identify patterns, anomalies, or operational insights over time.

Measurement System Trends Full Episode Transcript

Weldon Wright:

Welcome to Episode 45 of the “Oil & Gas Measurement Podcast,” sponsored by EnerSys Corporation, provider of Muddy Boots Field Operations Software, assisting oil and gas operators to implement accurate and repeatable measurement activities across their entire operation, while also simplifying data collection from the field.

Find out more about Muddy Boots at intersyscorp.com/software/muddyboots.

[background music]

Announcer: Welcome to the Oil & Gas Measurement Podcast, where measurement professionals, bubba geeks, and gurus share their knowledge, experience, and likely a tall tale or two on measurement topics for the oil and gas industry. And now your host, Weldon Wright.

Weldon:

Hello, I’m Weldon Wright with FpvPrime Measurement Consulting. I have with me, today, an old friend, Brian Sowell, that is kind of the ingrained guy who’s been around measurement for a long time also. Brian is the Group Product Manager, Measurement, over at Quorum Software.

Brian, I’m glad to have you here today. I feel honored to get some of your busy time off your schedule. Tell us a little bit about yourself and what you do over there at Quorum.

Brian Sowell:

Sure. Thanks, Weldon. I’m happy to be here. As you said, my name is Brian Sowell. My current role right now is Group Product Manager. What that means is I help drive the direction of our measurement systems, take them wherever they need to go from our current customers’ expectations as well as potential new markets and potential customers.

I’ve got a couple of people helping me on the product management side of the product manager for our FLOWCAL system and a product manager for our field applications as well. A little bit about my background with Quorum, I actually have been with Quorum for 25 years. I started in 2000, first job right out of college.

I almost immediately went right into a project in Denver to develop a new measurement system. There’s this company up there that had some requirements and some needs. They wanted to develop something alongside Quorum, and that got me kick-started on my next 25 years.

That system was developed around 2001, originally called VAST. That stood for Volume Acquisition System Tool or something like that. It was quickly renamed to Quorum Measurement. That was the first application from a measurement perspective I was involved with, and I was on the development side of things. I’ll take you down a path, if that’s OK.

Weldon: Sure.

Brian:

Where I’ve gone since then, what roles I have performed, and also what different measurement systems I’ve been exposed to. With Quorum Measurement, I got the opportunity to move into the implementation side of things.

Got an opportunity to work with a handful of different customers. That was a little bit before we met. It was right before, actually. Then around 2004, 2005, we had an acquisition at Quorum of the PGAS and TechTools Measurement System. That’s where I started to get plugged in with you on some of your projects.

Weldon: I believe so.

Brian:

Working with PGAS, I got an opportunity to serve different roles in support and solution architecture, eventually moving into the product management side. That’s been the majority of my history with measurement, is on the product management side.

We took PGAS and TechTools forward from 2005 all the way up until about 2019, and that’s when Quorum had their next big acquisition of FLOWCAL and the related field applications, all of its TESTit, PROVEit, PYCit, CALCit, and we’ve added ANALYZEit since then as well. That’s pretty much been my history.

I got the opportunity to learn how different measurement systems tackle the same requirements and the same problems. I thought it was pretty interesting to see how three different systems built by different companies all work in a similar way, and maybe it’s not surprising, but it was an easy thing for us to make these acquisitions and merge the best functionality of each one into the next one.

That’s what we’ve done along the way with even FLOWCAL, taking some of the better features of PGAS, and putting them into FLOWCAL and the field applications as well, and moving forward with that as our solution.

Weldon:

As you say that, Brian, the products didn’t really develop independently. We’re all trying to get the same piece. Over the years, I have been a user of FLOWCAL, I’ve been a user of PGAS. I never was a user of Quorum Measurement, but I’ve done transitions from MIPS to PGAS, MIPS to FLOWCAL, FLOWCAL to PGAS, PGAS to FLOWCAL, back and forth over the many years.

I probably saw FLOWCAL the first time in late ’93 or early ’94, but as we went along, the customer base out there was all looking for the same functionality. I don’t think it’s surprising that much of the functionality grew in these major systems. I’d like to talk a little bit more about what requirements were overall.

Before you do that, take a step back and give us a quick plug for what all Quorum does, the scope of Quorum’s expertise and services.

Brian:

Sure. Quorum is quite vast in what it tackles from a coverage perspective. It covers everything from solutions on an operation side and the upstream world all the way to our accounting side of things from a pipeline and up, like a plant perspective.

We are organized in a way where we have products that meet upstream and land requirements. We have a midstream focused. That’s where our measurement system resides, although measurement covers the majority of these areas. We have an international aspect of it.

Quorum is quite large when it comes to serving the whole world, so we have lots of different offices across the globe. We have — I’m going to probably be wrong — but 25 to 30 unique applications serving different aspects of the energy industry.

Weldon: I know it’s got scary big since I was with Quorum.

Brian: Yeah.

Weldon:

Part of what goes on there is both…I never heard the acronym VAST before, but when you started working on Quorum Measurement, that was a small company still with a fairly small focus. FLOWCAL started out with Coastal Flow, strictly in the measurement world, strictly processing data. PGAS launched the same way. It was a standalone product.

What we found out is the measurement data is a piece of the puzzle, and it needs to integrate well. That’s where a lot of Quorum’s power comes from these days, is that closer integration to all the pieces before we get to the measurement data and where measurement needs to feed the rest of the operations.

Brian:

I like going all the way back to how those companies started. Going back to Quorum and how we started, it started with an application called TIPS, which is a plant accounting application. Since then, there was a contract management application that was created that complemented the needs of that tool.

The next logical thing was what you just said, measurement is a big piece of this, and the integration of those two systems. It made a lot of sense for us to go there and develop our own measurement applications.

It’s all about collecting the physically measured information in the field, consolidating it, and the measurement system is tasked with making sure it’s two things, complete and correct best you can before it moves on to the accounting system. That methodology through all of these different systems has held true.

One of the big things that we have now is tight integration between FLOWCAL and our accounting systems, not just TIPS but our pipeline system and some others as well.

Where it’s real-time integration, event-driven integration, utilizing APIs, moving this information from measurement as soon as it changes, getting it to the applications that want to know about it as soon as they want to know about it, and moving forward there.

That’s something that’s evolved over time, and that’s where the current iteration is. Started back in 2000 with TIPS and has grown. TIPS and FLOWCAL work so well together. TIPS and pipeline, it works so well together.

Weldon:

Thanks, Brian. I don’t want to imply that FLOWCAL is the only thing out there for my listeners. It’s by far the prevalent system out there on the market today, and that’s largely because measurement data processing has become so complex and so big.

There are other systems out there that fill very specific niches, and they are probably very right for specific companies. If you need the wide amount of configurability and all that stuff, there’s really not much out there left that can compete. I’d like you to talk a little bit, and I’m going to set this up with a statement.

That when I started with my first exposure to what’s now FLOWCAL — again, late ’93, early ’94 maybe — what was being asked of a measurement system was to simply be able to take data from these newfangled flow computers that we had out there…

To take data from those newfangled flow computers, bring that data in, and be able to add it up into a single monthly total so we could feed it to what our accounting systems were at that point in time, which were originally set up to just take that one chart volume at the end of the month.

Those demands, those requirements, of course, gotten huge. Where I’d like for us to spend our time talking about now is how those requirements have changed and where they’re headed going forward.

Brian:

That takes me down the path of how I explain at different industry events what the measurement system is meant to tackle. I talked about the key requirement being to take all of this information and make sure it’s complete and correct. Those two things have a lot of requirements behind them.

We started with charts. We started with maybe monthly or daily information coming in. You mentioned rolling up the flow computer information, so now we’re getting into an hourly-level set of information.

You’ve got laboratories out there sending in samples. You’ve got field data capture systems that eventually came along that need to be consolidating their information as well to the central office.

One of the key things from a requirement perspective is the consolidation of measurement data from all of these disparate sources into a centralized location so you can start to take a look at things.

Then as that data comes in, the first key thing that happens, is we need to be alerted if there’s anything that looks unusual about it, so anomaly detection, best we can do. That speaks to what most of these measurement systems out there have — validation routines, capabilities, and rules.

As this data comes in through the filter, alerting, creating exceptions of, “Hey, you need to take a look at this hour for this meter. Its pressure is too high compared to its history, or it’s missing some information that we should have had by now.” Those are some of the requirements on getting the data in and identifying if it’s complete, and then the correct aspect of it.

If you do identify an anomaly, then comes the editing capabilities that are required of these systems, and factor in the need to be compliant with regulatory and industry standards. That’s where you start getting into the need to support different industry calculations.

If you are going to go edit an orifice meter, then you need a system that’s going to tackle the AGA3 calculation completely and correctly. Factor in turbines and ultrasonics — all these different meter types out there — you’re adding more and more of the requirements needed on the system from an industry-standard calculation perspective.

That’s just from AGA. Then you add in API requirements, some on the liquid side there, GPA requirements. The requirements continue to grow into what most of our customers expect from a measurement system. All about getting it complete and correct.

Once you’ve got there and you’ve edited the data, the next big step of requirement of a measurement system is to get it on down the road where it needs to go through reporting or integration. I talked a little bit about how we integrate here at Quorum a second ago.

Weldon:

I’d like to loop back just a moment. When we talk about measurement systems, there’s not many folks around that still remember that in the early days of our measurement systems, what editing really was. Editing was the ability to go in and maybe, at a daily level, say, “I don’t like that volume. I’m going to type in a new number.”

The early measurement systems didn’t even do the volume calculation. They could apply a new analysis via the old-school specific gravity correction, and they could multiply MCF by heating value.

The ability to do the kind of editing that we’re talking about today, about detecting a incorrect pressure or DP numbers that don’t make sense or a temperature that went off crazy.

To be able to detect that automatically in the software, assist the user manually in making a correction to that pressure, temperature, DP, and then recalculating the volumes correctly according to AGA or API, that’s not something that was in those earlier systems, right?

Brian:

That’s right. That got folded in over time. For the two main systems I have experience with, PGAS and FLOWCAL, it evolved the same way.

There was a focus-in on gas measurements to start. Like you said, maybe apply heating value, get a new energy if you needed to, bringing in a sample from a laboratory after the fact, to the need for us to recalculate the most common meter out there, which would probably be an orifice at the time.

Then that evolved to newer technologies from a meter-type perspective, adding in those additional calculations, and then again, PGAS and FLOWCAL evolved in a way that there is a need to go into the liquid side of the business, and that starts bringing in API calculations as well.

Weldon:

We’ve also, though, Brian, seen, I was going to say a shift, but it’s actually a swing back and forth. Almost like a pendulum.

When we started off early on, we had mainframes sucking in SCADA information that included volumes with some of our bigger pipeline companies. Early on, originally, FLOWCAL was a little PC application. [laughs] Ran on a Paradox database, I think, right?

It was a little PC-based application, really limited, maybe a thousand meters for two or three months’ worth of data was its limit for you to spawn off information. We moved from that to bigger PC applications. We moved to server-based. Talk to us about that move and how we ended up pointing toward software as a service, also.

Brian:

That’s great. That’s definitely a focus area for us right now. Like you said, desktop application, moved to needing these servers dedicated. We talked about the massive amount of data that’s coming in, the need for servers dedicated just for bringing the data into the system.

A lot of that put additional needs on customers to have pretty robust IT departments to set these systems up, to perform it when they’re talking about…Back in the day when I was with PGAS, I was thinking 5,000 meters was a pretty large system. Now we’ve got customers with 20,000, 30,000, 40,000, 50,000 meters. It’s a lot of information that comes in every hour.

That has evolved now. It’s a shift that’s going on. We’re seeing more and more of our new customers come to us with the expectation that they don’t want to tackle that part of it.

They want a vendor to have a hosted offering and take a SaaS deployment model. The benefits to the customer with a SaaS deployment model — SaaS stands for software as a service — is that they don’t have to tackle that infrastructure side of things. That’s benefit number one. The vendor takes care of that.

There is the capability through the deployment model for them to pick up the benefits of the innovation that are occurring in the software by the vendor as soon as it gets released. The on-prem model requires planning of upgrades, taking that out, doing the testing as that company’s ready to upgrade that system.

From a SaaS deployment model, all that happens very quickly. The return on investment for the customer is a lot faster, and the feedback loop to us, the vendor, of how we are doing with our innovation and our new features will speed up as well.

That’s definitely a focus for us. We’ve historically had a couple different ways of deployment on-prem and our hosted environment. Both of those will continue moving forward, but we are putting in quite a bit of effort on the SaaS deployment model right now.

Weldon:

Thanks, Brian. I’m going to ask you a question, if you don’t want to answer it or don’t know the answer, feel free to say that, but I don’t mean to catch you off guard with this. I know the move is strongly towards software as a service.

Do you have customer concerns that are leading customers to move back away from software as a service back to in-house hosting, or is this pretty much consistently a move to software as a service?

Brian:

We’re seeing it more and more. If we were to look at new customer’s perspective, I would say a very high percentage go to our hosted platform. Very high. There are expectations nowadays of what’s expected if you’re going to use a vendor’s hosted solution.

One of them is to — it’s a security focus — making sure that that vendor is doing everything that’s required of them to keep the customer’s data protected. There are certifications out there, SOC 2 Type 2 specifically.

That’s something that you go through as a vendor to get certified that says, “On an ongoing basis, we are doing everything right to make sure that customer’s data is in a secure system. We’re scanning. If we find some new issue that we need to resolve, we resolve it very quickly. We have all the right processes in place to maintain that certification.”

That’s something else that we are, across Quorum, tackling right now as well. A lot of our systems have already received that certification.

Weldon:

That becomes a massive task. Just a massive task. It’s such a change, too. When I got into this business, data transfer and data security was the technicians brought floppy disks into the measurement office where they downloaded flow computers locally.

At the end, measurement copied everything over to floppy and they carried it down to accounting. [laughs] That was the early days.

The IT perspective of what we’re talking about, the things you’ve touched about, the massive size of the servers, the almost incomprehensible amount of data we move, the security requirements both within your organization and doubly or triply so if you’re going to provide software as a solution.

Those security requirements have become so massive that that alone is more than one person or one group can keep track of, right?

Brian: That’s right.

Weldon: Specialization, and being large enough, like Quorum is, where they have a department that can specialize on that, lets folks like you be more concerned about getting the measurement job done, doesn’t it?

Brian: That’s exactly right. That’s what is the trend right now, and maybe one of the big drivers as to why we’re seeing so many people come towards the hosted offering as their approach.

Weldon:

Enough of that housekeeping stuff, although it’s very important what we do. What started this whole podcast is talking about, Quorum — it’s been several months ago now — got some customers together and had another one of, I don’t know if y’all still call it round tables, but talked with customers about what future needs were, where they’d like to see the product go.

I know a large part of your job is planning that roadmap. What I’d like to hear, and what I’ve had several requests from podcast listeners about, is to see if y’all can talk to us a little bit about where measurement data processing is headed in general, and specifically, if you can, where Quorum is heading with it.

What’s on the horizon? What are customers asking for? What do y’all have in the works?

Brian:

Sure. I can talk to, from a consistent request perspective, like you said, what are customers asking for measurement systems generally to tackle for them moving forward.

I think, also, individual systems have different paths forward depending on where they started. Some systems are very robust in their functionality and have opportunities to focus more on the technical side to improve efficiencies for those customers.

Other systems might be advanced in that area but need to grow into the liquid side of things or grow into new areas like that. When I think about our roadmap, I’ve always taken this approach to how we think about the next cycle, the next release, and then the future roadmap after that. I see it as three areas that have inputs into that.

The first one being the table stakes. Measurement systems have all those expectations I mentioned earlier around staying current with calculations, industry standards, and regulatory needs. You’re thinking about AGA, GPA, API, and staying current with all the changes and revisions to those standards.

Then, from a regulatory standpoint, staying in tune with BLM here in the States, then Directive 17 up in Canada. Those are the two different things that we’re very plugged into and understanding what needs to go into the software to evolve that to just meet the basic needs of what customers are expecting.

Then the next of my three areas would be customer feedback. We have a pretty large customer base, and they have expectations and ideas — great ideas — of what needs to evolve in the system.

Within the customer base, you get different ideas from different departments. You’ve got end users and their ideas of how their life could be made easier in the system if this worked a certain way, or that did something, or we add some new bit of functionality that saves them overall time.

A lot of the feedback that comes in that direction is from a usability improvement perspective, and we factor that in.

Then you’ve got the IT departments or the system support folks. They’re looking at it through a different lens. They’re wanting to make support of the system better.

They’re talking about increased performance here, scale it up because we’re about to have an M&A activity and we’re going to bring on more assets. They feed back information that way. It’s a little bit more technical from their direction.

That feeds into the roadmap. Then the last one is just from a potential customer, new market, forward-looking perspective from my side of the fence on the vendor side.

The innovation that Quorum would put into the roadmap and the product to continue to grow, that’s what we want to do. That’s evaluating new markets, new commodities.

That’s something that’s come up a little bit, getting a little bit out of the traditional hydrocarbons and focusing on what the system can do to be purpose-built for non-hydrocarbons. That’s an area that we’re looking at right now.

A lot of the innovation for us — now I’m getting more specific to us — is focusing in on ways to make our customers be more efficient and to do more with less. That’s probably where I would talk a little bit more is, you mentioned that round table. We got that feedback there. We got a few things I’ll talk about here in a second.

We also just had our user event in Las Vegas where we had another round table. There was a gentleman that they said it very clear in front of everybody when we asked, “Where do you want to see the system move from here?” They basically said, “We need to be more efficient and do more with less, so throw as much technology at this as possible.”

That’s where we are at right now, where we’re headed, is seeing what we can do through technology to help customers as they have more assets through M&A activities, individuals are asked to do or take on more. Basically, make them efficient through improved workflows, use the technology to identify anomalies faster, and give them the tools that they need.

Weldon:

We’re very much moving from a world of, I want a software tool to manage all of the big incoming data. I want a software tool that can recalculate if I tell it to. I want a software tool that can just merge an analysis to a volume.

We’ve gone from that world, and in that world, we still wanted decisions to be made by people. We wanted that analyst with 8, 10, 15 years’ worth of experience, we wanted them looking at every one of those flags that popped up and making a decision on it. That has shifted tremendously. As you say, throw technology at it and do more with less.

The reality of it is the analyst in the average measurement department, the years of experience has gone down over time. What we’re very much looking for these days, at least this is what I hear, is we’re looking for expert system. You mentioned AI factor, how does that factor into the equation, but that’s what I hear a lot of people looking for also.

We’ve gone from that, “I want to make all of the decisions,” to, “I want a decision system that makes the easy black-and-white stuff for me and only requires us to look at the more complicated or the more complex questions.” Is that true from what you’re hearing?

Brian:

Yeah, that’s exactly right. I will say things are moving very fast in this area. If we listen to this podcast back in a year, maybe some of the stuff we’re talking about now or what I’m about to say has changed. I do think that the human interaction, and making edits, and tracking the audit trail, and giving the reasons of why you’re changing things still plays right now.

Making it a more efficient process, reducing some of the noise, putting in front of the analyst, clearly, things that they need to take action on, and overall just increasing the efficiency of them in their job is where we’re thinking things will move forward.

A year from now, maybe we are getting into that automatic edits area and realm of things, but I’m not quite sure we’re there just yet. Some things have to continue to change from a process and industry-standard perspective to get the guidelines around that.

You touched on a couple of different things I want to circle back to. You mentioned the experience level of people now could be reducing, newer people are coming into this area, and these systems are pretty robust and have a lot of capabilities to educate these new people of how to use the system, and they are complex.

There’s a lot of different things going on, and it takes some training to ramp them up. That’s a specific area that we know that we can use AI, you mentioned it, to help quite a bit.

With FLOWCAL specifically, we’ve got a pretty robust online help mechanism. We have training courses. We have knowledge bases. We have our support system that has cases in there with lots of good information of us educating customers of, “Turn this configuration on, do this action, that solves this problem.”

That’s great. All of this information is out there to help a new analyst coming in, but how are they going to navigate all of these different systems? It’s overwhelming, and we really can’t expect that.

A focus area for us right now is to develop a tool that helps consolidate all of these sources of information, and then gives the analyst or the user a very natural language interaction where they can ask questions and get results that tell them the path forward on what they’re trying to solve for. That’s not groundbreaking in concept.

I do this in my daily jobs. I open up an AI tool, ask it questions of how to generate a Power BI script, and pull from a different system. I did this yesterday, and it walked me right through that step by step.

That’s where we want to get to, with questions like, “What is this report intended to do?” Or, “I’m having a hard time getting this report to get scheduled and sent to my end customer. How do I solve that?” Then this natural language digital assistant would walk me right through that.

That’s a very specific area that we’re focused on. It’s actually already been released in some of our other products at Quorum, and over time, we’re all going to start deploying something like that, and then evolve it over time as well to see what more it could do.

Weldon: Help that really helps?

Brian: Yes, exactly.

Weldon: That’s almost a sore subject. That was almost mean to say that, wasn’t it? [laughs] You’re exactly right. There’s several different areas where there’s so much potential for. I agree with you, I don’t know that we’re yet ready to full scale, wholeheartedly let AI go in, find problems, make edits, make changes, and pass them off without people looking at it, right?

Brian: Right.

Weldon:

I can also tell you, it wasn’t long ago in my career that I was sitting there beating my hands on the table saying, “There’s no way I’ll turn on fully automatic PPAs and let a system make edits to it and apply appropriate adjustments.” That was an absolute to me at one point in my career when I was managing and directing measurement groups.

I have changed that opinion dramatically. There’s a place for it within certain limits. We’re at the point where the intelligent validation and getting the noise out of the way, and then…Getting the noise out of the way is really making a decision. We’re letting the computer decide to take some of the noise away from us. Those things are there.

I agree with you, there needs to be changes in some of our standards and in some of our industry-accepted practices to get us to fully cruise control. I don’t know that that will ever be true for every problem that can pop up.

Brian:

That’s right. The interaction will be there for a little while. For a while, I should say. I talked a little bit about a digital assistant and support or help that really helps. There are a lot of other areas AI can help as well.

I look forward to the day where you can look at a balance, for example, and see that it’s out by 1.5, 2 percent, and instead of manually diving into every sub-segment, going into every meter and trying to find the problem, you can just ask the system for its insights.

It can do whatever it needs to do to see, “This meter has got some missing data. Take a look at that.” Or, “That sub-segment is out of balance in a similar way. Maybe that problem isn’t there.” Or, “This meter has a lot of exceptions that are unresolved, probably that’s your place to look at.”

That starts stepping into machine learning, which is a different form of AI, and that’s an area of interest and exploration for us as well. There’s lots of going back to that round table, throw as much technology at it as possible. That’s what we’re looking at right now and what we have been looking at for a while.

Weldon:

I know that there’s a lot of things that excite me that we’re seeing today along the realm. Some of the stuff you’re talking about there, reviewing, being able to identify problems, point you in the right direction of where to look. That’s all some exciting stuff.

I would have loved to have those kind of tools 10 years ago. Where else would you like to take us before we wrap this up, Brian?

Brian:

I think that pretty much covers everything I was going to mention. A couple of other topics that were brought up at our round table, and, again, things we’re working on, there’s an interest in the industry for more openness. I talked a little bit about that earlier. The need to integrate the measurement applications either in the field or the office to different systems.

One very clear example is a field application, specifically ours is TESTit. It’s scheduling work for a technician, but you also have work order management systems that are also putting work on the technician’s plate.

Integration of those systems and getting a customer of ours a more holistic view of what’s in front of the technician. That’s a need that’s come up quite a bit. The way that’s solved is through API development, public APIs. That’s a focus a lot of these systems are already looking into, and what we’ve been working on for a while as well.

Also, the last thing I’ll mention is an increased desire to have as much access to data as possible. Now, going back to the shift to SaaS and software as a service, that becomes even more important, is the capabilities for customers to get to that data and do what they need to do on it.

Measurement systems would be great if they could solve every single thing that every unique customer has from a trending need, but that’s probably unrealistic for that functionality to be in the system for every single customer’s need.

Getting to that data and letting them do their trending needs on top of that, that’s what I’m talking about there. Then to open that data reporting across products.

That really starts to give customers some good capabilities of researching problems, when you can ask questions across, going back to our software, FLOWCAL and TIPS or FLOWCAL and TESTit. Cross-product platform reporting is something else.

Those are the main things that have been coming up from our customers, what we’re seeing out there, and where we feel measurement systems are headed.

Weldon:

Brian, thanks for sharing all that with our listeners. I know that I’m hearing stuff here that I like. There’s going to be things here that surprise some other people. I also hope that some of our younger listeners or newer-to-the-profession listeners…

[background music]

Weldon: …take a little bit of grain from how much we’ve changed over the years. Congratulations on that recent 20-year anniversary, Brian.

Brian: Thank you, Weldon.

Weldon: Thank you for being on the podcast, sir.

Brian: Thank you.

Weldon:

I hope you’ve enjoyed this episode. I hope you take away a little bit of knowledge about the complexity in all the parts involved in our back-office measurement systems. We’ll have Brian’s contact information, along with a full transcript of this episode, in the show notes on our website, pipelinepodcastnetwork.com.

If you have comments or questions about this episode, suggestions for future topics, or if you’d like to offer yourself up to the podcast mic as a guest, send me a message on LinkedIn or, shoot me an email at weldon.wright@fpvprime.com.

[music]