By: Erin Warren, Customer Success Manager @ Metquay Inc.
Imagine that your lab has a completely different - even unpredictable - process for each and every calibration you do. Each time you pick up a piece of equipment, whether or not it’s the same piece of equipment you just calibrated 5 minutes ago, you have no idea what to expect.
What an absurd idea!
It’s common practice in all scientific fields that there is a high bar for standardization and procedure. It’s probably second nature to most of us in the field; we don’t even realize we are doing it. But if you stop to think through it, there is a procedure for everything, and everything has a procedure.
Need to send a caliper for recheck? There’s a procedure for that.
Need to calibrate a multimeter? There’s a procedure for that.
Need to become accredited? There’s a procedure for that.
And that.
And that.
And that.
But one thing that we have noticed, even in working with our software, is that it doesn’t feel intuitive to have a procedure in the way we name sections and variables in worksheets. (You may call them data sheets, depending on which program you use to manage calibration.) With each worksheet you open, are you having to spend time figuring out how it’s put together and how things are named? If how it’s put together is not completely predictable, you’re reinventing the wheel every time, wasting valuable time and effort.
In not standardizing your naming convention and general worksheet flow, you may also be missing out on some automation options - some of which exist now, and some of which are likely coming as artificial intelligence and machine learning become more prevalent in both our day-to-day lives and in our businesses.
New Auditor Nightmare
Now imagine that, this year, you get a new auditor. This auditor has a different interpretation of what’s required to maintain your accreditation, and you’re going to have to edit most of your data sheets to meet the requirement. Did your heart rate just quicken? Mine, too.
If you’re a typical calibration lab, you have hundreds - possibly even thousands - of worksheets. You’d have to set aside a substantial amount of time (and, therefore, money) to dedicate to this endeavor. Let’s also not forget that not just anyone can do this job; it’s going to be someone with a strong working knowledge of the worksheets themselves: likely a lab or QA manager.
This is the stuff of a lab manager’s nightmares.
Now, let’s rewind to the point of getting that heart-quickening news from your auditor that you’ll have to edit all of your data sheets. Imagine that when you started your processes, you began as you meant to continue. You fought the urge to go live with your software as quickly as possible, and you thought ahead to when you may have hundreds or thousands of worksheets. You knew that if you gave standardized names to each field, anyone coming in could make sense of the way you’ve organized things, whether or not you explain it to them.
Because of this, you may have automated options for making these big changes, like Robotic Process Automation software.
No, Seriously, This is a Real Thing
We recently had a similar situation with a customer. There was a change that needed to be made in their worksheets - nearly all of them - and it was going to take literal weeks of work for one of their highest-level technical personnel (the worksheet architect) to complete.
This employee, though, had a brilliant and out-of-the-box idea: RPA software. Because she had followed an identical template with standardized naming conventions during her worksheet creation, she was able to teach the RPA software to do all of this tedious work for her with a quick screen recording. The software was then able to edit expressions and move variables around to exactly where they needed to go without human intervention.
Our team was so excited to see how well this worked and we knew we needed to share the outcome of this process with our other customers. Had she not created highly standardized worksheets, this would not have been possible. And now, not only does this company have the option of using such software, but anyone who looks at their worksheets can easily tell how they work. Any technician or auditor can open Metquay and understand the procedure for each calibration with little to no explanation from someone else.
When we start to think ahead with the possibilities of machine learning and the way that it can make our lives and jobs easier, there is huge potential in these kinds of technologies if we also understand their limitations. In the end, AI is still a computer. It can’t [yet] think the way we can or use critical thinking skills to decipher what a human was thinking when they created a worksheet. What AI can do is see patterns, and we can create that.
Another Real World Example: Except it’s How Not to Do This
I was recently helping a customer do some worksheet imports using a certificate and a spec sheet. The spec sheet import concept is a new feature that we at Metquay developed for this particular customer (ask us about it!) and it’s changing the way we are building worksheets and procedures. At its most basic, it’s an API that allows the user to build a basic worksheet and then have all of the potential values (think: tested values, range, tolerances, etc) imported so that they don’t have to be manually inputted. We are excited about it.
Anyway, that’s what I was working on.
On the certificate, a field was called “AC Volts.” That makes sense; it’s a multimeter. So I created the worksheet field with that name. Then, I’m trying to pair that field with which reference equipment is used to calibrate it, but there is no field for AC Volts in the pairing document. Here, it was called “AC Volts - Input.” So I manually connected those two fields. When I went to import it via the spec sheet, again, it was nowhere to be found. (I’m not making this up!) I had to go digging around, and then I was able to find the field that was its equivalent: “AC Voltage.”
These names are all so, so painfully similar that anyone would think that I’m just being persnickety. However, these small differences completely change the ability to seamlessly import the specifications, which in turn automates and streamlines the calibration process. Instead of our program being able to pull the correct field and its values automatically, someone has to spend time and effort creating connections that could already be there.
The great news is that this particular customer is at the beginning of their journey with our software, and they’re aware of the need to standardize. We will make these changes before they go live, and they will be set up wonderfully. They will start as they mean to continue. Their worksheets will be perfectly editable and fantastically scalable.
This is what I mean when I ask if you are using standardized naming or just similar names. Choose one name. Use it everywhere. No exceptions.
How Do You Eat an Elephant?
Think about your data sheets. Are your naming conventions standard, or just similar? When you created them, were you in a rush to get live with your software, and therefore you cut corners and just did whatever would get you from Point A to Point B most quickly? It’s understandable; many labs have done the same. But it’s worth the time and effort to make these changes now.
It may feel like a daunting task, but sit down and look through them all. Decide on standard naming conventions for every part of your work - worksheet title, functions, result fields, everything. Write them all down. Then, as my mama always said:
There’s only one way to eat an elephant: one bite at a time.
One bite. Choose one worksheet to start with. Choose one that you can copy easily for many instruments to have the biggest impact. You should be able to create one standard worksheet for each of your instrument categories (multimeters, thermometers, calipers) and then make small changes to each copy as needed, remembering to follow your new, standard template and names. Next week, do another. Another small bite.
Going about this change, even in small amounts, could have big long-term impacts on the way your lab is run - and on the possibilities for scaling in the future.
Comments