I dream of LDAR Software

In the beginning we called it fugitive emission monitoring. Gradually, the nomenclature evolved and we began calling it leak detection and repair or LDAR. Regardless of what we call it, the key to any successful program has been the technician: the man or woman charged with the duty of finding the fugitive emissions if they are there. The “detection” part of leak detection and repair is, for the most part, the result of the efforts and work practices of the technician.
THAT is where the value in an LDAR program is built.

The single most important factor that LDAR managers can implement in improving the performance of their fugitive emission program is generating feedback loops for the technicians. And, when it comes to LDAR, the shorter the feedback loop the better.

Assume that the technician is able to get to his first component within the site’s first component index (such as within 60 minutes of his payroll start time). Does he get feedback? Does anyone notice? Does anyone care? After the briefest of time, does even the best technician stop caring himself if he or she decides that no one else cares?

On the other hand, assume that the technician takes 10 minutes longer than the 60 minute index (because he drank an extra cup of coffee, visited a little longer about the controversial play in the Super Bowl, or decided to stop for a pastry at the vendor’s truck on the way to the unit). He took 70 minutes instead of 60 minutes. The same questions erupt: does he get feedback? Does anyone notice? Does anyone care?

Lunch time is another opportunity for excellence, mediocrity or downright neglect. If the site allots 60 minutes (from the morning’s last component to the afternoon’s first component), what happens if the technician takes 65, 70, 90 or 120 minutes? (Don’t kid yourself, it happens!)

The answer is: what happens is a function of whether or not the technician is getting feedback and, if so, what kind of feedback it is.

Here is where the software comes in. You know what a good, productive day looks like: first component in less than x minutes, morning and afternoon breaks in less than y minutes, lunch in less than z minutes and last component no later than 4:30 (fill in the right time for your site).

Now, your LDAR database knows which technicians achieved that level of productivity. Virtually every fugitive emissions program has been collecting that data for more than a decade. Your computer knows- do you? And do your technicians know that you know?
Not only does it know at the end of the day, that LDAR datalogger “knew” how effective your LDAR program was at the instant that each of these moments occurred. It “knew” if your technician was successful in getting to that first component. What did your software do if he failed? Did it ignore it? Or did it inform the technician that he had missed this important benchmark (that’s called feedback) and did it ask him (or her) to give a brief explanation for what had happened so that your site’s management team could learn from the experience and improve the process (that’s the best part of feedback).

The ideal fugitive emissions program would have a clear definition of success and an automated process for instantaneously generating feedback at each critical moment. That is the best way to ensure that your leak detection and repair program is constantly improving.
And then an automated, daily email to each person who cares about what happened that day.
Imagine that.