Upgrading (or updating) instrument calibration programs
Significantly improve your calibration program efficiency and compliance with a CCMS upgrade
By Mike Cable
A calibration program upgrade can mean something different depending on who you ask. It could mean the current way you manage your calibration program has become cumbersome and inefficient, or the software program you use to manage calibrations is outdated or no longer supported by the supplier. It could mean you do not have a calibration program in place at all, or it could mean something else entirely. While trying to address some of each in this article, mostly we will discuss upgrading the Computerized Calibration Management System (CCMS) software used to manage your instrument calibrations. This article will also focus on process calibrations. I personally consider metrology and process calibration to be two different worlds. Metrology deals more with calibration of test standards and instruments calibrated in a controlled environment to better accuracies, and uses uncertainty. Process calibrations are performed in the field or the shop to calibration tolerances that are (should be) based on process requirements as opposed to manufacturer specified accuracies—and typically uncertainty is not determined. The same calibration program principles apply, but the regulatory requirements, calibration methods, and controls may differ. That said, the software program can be the same for both disciplines, but some different functionality fields will be needed.
Any basic calibration program consists of an inventory of the instruments, calibration schedules, and history of calibrations (scheduled and unscheduled) and repairs performed on the instruments. The calibration program might also include spare parts inventory. For this article, the calibration program does not include mechanical equipment and maintenance, although many of the same principles apply.
Instrument inventory: The instrument inventory includes all the information you want to track about the specific instrument asset. At minimum, this should include a unique identifier for each instrument along with a description, location, manufacturer, model, serial number, P&ID tag number, calibration range, and calibration tolerance (limits). Other data to consider might include instrument type, instrument owner, department, range and accuracy specified by manufacturer, parent system, parent equipment, criticality classification, etc. When establishing a new calibration program, serious consideration should be given to the unique identifier. If the P&ID tag is used, remember instruments will be replaced, and many instruments will not have a P&ID tag. The more projects I do, the more I am convinced the unique identifier simply should be a sequential number such as INST-XXXXX, unless you are going to consistently assign a unique identifier to everything, including lab, admin, portable, and test equipment.
Calibration schedules: The calibration schedule establishes the initial due date and the frequency at which the calibration(s) for the instrument is performed. The calibration procedure and nominal test points are typically associated with the schedule as well.
Calibration history: The history for each completed calibration and repair performed on a specific instrument must be maintained. Each calibration performed must include a record of the date completed, technician, As-Found measurement data at each test point for the test standard and instrument with the corresponding error, As-Left measurement data, and a listing of all calibration standards used with corresponding expiration date. When scheduled calibrations are completed, the next due date is updated based on the calibration schedule.
The most important thing about doing any calibration upgrade is to have a champion and get the commitment of everyone involved. It is going to take involvement from management, IT, quality, system users, and the supplier during implementation. It is going to take a dedicated person to champion the project through all the inevitable obstacles. Obtaining agreement on responsibilities and expectations upfront to ensure project success is critical. It is important to clearly document quality expectations for documentation and testing. These costs can add significantly to your project, particularly if outsourcing is required.
The project champion for a calibration program improvement is likely to be a senior person in the calibration department (but not always).
The first steps:
a. Determine drivers—for example, system outdated and no longer supported, quality initiative, improve efficiency/reduce operating costs
b. Check with other departments: Should we integrate asset management for maintenance, validation, training needs?
c. Check your options—what systems are available that might meet our needs; network (online discussion groups, professional organizations, professional associates) to see what other similar companies are using, what they like and do not like
d. Develop a Draft User Requirement Specification. Major cost differentiators:
• Paperless or paper-based
• Web-based, stand-alone, network/client
• Number of concurrent users (license fees can be significant)
• Interface with process calibrators
• Use same system for maintenance and calibration
• Enterprise, site, or departmental scope
• Regulatory compliance for electronic records, electronic signatures
e. Obtain quotes for software, hardware, data migration, and implementation costs. Apply some common sense to the costs, and likely increase the estimate based on experience with projects at your facility. Utilize a project manager for assistance to help account for the additional costs that may occur due to schedule delays and additional quality requirements. Document the cost additions so the financial group understands what, if any, fudge factors have already been added.
My suggestion for the champion would be to get a partner in the IT department to help do an initial review to make sure any system selected will comply with the network infrastructure. For example, are the wireless/network drops in the locations that will be needed for calibrations? Also, Structured Query Language systems are a tough sell in an Oracle-based IT department. Some suppliers have not kept pace with technology advances, which could lead to frequent system crashes or total inoperability with your network infrastructure. IT will be able to help with that determination. This is the beginning of a beautiful alliance and team building, one that will pay huge dividends during implementation. The champion should also begin to discuss quality requirements to get an idea of the resources that will be needed (people and costs). The more detail here, the better. Do not overlook this very important alliance.
I would also recommend getting with the maintenance manager. For many years, I have seen companies use two different systems—one for equipment maintenance and one for instrument calibration—and for good reason. The CMMS that does a great job for maintenance was not good for calibrations, and vice versa. Maintenance systems need to do a good job of spare parts management, inventory control, craft planning, meter-based and calendar-based scheduling, and incorporate preventive, predictive, and corrective maintenance strategies. Calibration systems, on the other hand, need to provide pre-defined test points and tolerances, track as-found and as-left measurement data, automatically calculate error, track test standards used, and provide reverse traceability in the event test standards are found out of tolerance. Some of the more popular systems today are doing a good job for both. The maintenance department typically has a much bigger budget than calibration. Given these two factors and that it just makes sense to have all your assets in one system, it is a no-brainer the two departments team up for any upgrades. Even if the systems have to remain separate near term, the system can be implemented for use in calibration and then later add maintenance once the system has proven itself.
Funding for the project is going to take management’s approval. To obtain approval, management is going to want to know what is in it for them. Unless there is a quality mandate, a Return on Investment (ROI) will be the ticket to justify the project expense. Remember, if the money is not already in the budget for this year, your efforts are now to get the project in next year’s budget.
a. Identify and quantify productivity improvements
b. Identify and quantify quality improvements
c. Identify and quantify tangible benefits
d. Document current system support (if any)
e. Add it all up and make your case
Once the funding is approved its time to select a solution, but not so fast.
3. Product selection
a. Round up the troops (stakeholders)
b. Finalize and approve the User Requirements Specification
c. Issue requests for proposals and have vendors include Functional Requirements Specification
d. Make a preliminary selection of the product/supplier
e. Conduct a comprehensive quality audit of the supplier
(leverage results in test requirements and risk assessment)
f. If supplier is acceptable, issue a purchase order.
Now the real work begins. We bought it, now we have to make it work for us. I have included a typical implementation sequence below and a description of the documentation/testing in the table. Implementation may vary depending on the system complexity, quality requirements, and leveraging of other activities. Some activities can be performed in parallel and some eliminated if systems are installed on multiple servers such as a testing/development environment and a production environment.
a. Purchase and install hardware
b. Develop required documentation
c. Installation of software
d. Configuration (may be installed pre-configured, depending on system)
e. Perform installation verification
f. Test migration #1 (if necessary): Perform data migration verification and document any issues that need to be corrected for final migration. Note a final migration will be required even if no errors occurred to update the system with any changes made up to the source system
g. Informal use testing (Important!): Use this period to put the system through all possible use scenarios. Communicate with supplier on any additional functionality desired, even the ones not yet possible, and update documents with any additional requirements that will be implemented. Use this time to develop procedures and dry run testing.
h. Perform operational verification testing
i. Approve procedures/work instructions and complete training requirements—typically procedures to support operation are required prior to final system testing and user training should be completed.
j. Optional data migration #2: If there were any issues during migration #1 or additional configuration, you want to make sure final system testing is performed on the data and configuration that will be used once system goes live.
k. Perform performance qualification
l. Final data migration
m. Go live!
All done, right? Absolutely not … plan for problems once system goes live. Even with all the proper planning and implementation, things will not go smoothly. Training likely did not cover every scenario, and there is a learning curve for the users for every software implementation that anyone has ever done. Make sure your system experts and key players during configuration and testing are available for post-“go live” support.
I hope I have shed a little light on the requirements of a calibration program, CCMS, and some helpful hints for implementation. I want to emphasize the importance of obtaining consensus with all stakeholders, including IT, quality, users, suppliers, and maintenance, even before making the final purchasing decision. On every CCMS system I have implemented, the IT support and ever-changing quality requirements have led to project delays and increased costs. The main problem I have seen is we do not know what we want until we see what we have. So the key is to provide visual clarity to what the end products will be ahead of time, obtain buy-in from stakeholders, and obtain approval from management that these are the requirements that if changed will significantly delay and add cost to the project. There is a lot of detail and specific lessons learned from experience that have been left out of this article due to the variables involved. However, feel free to contact me for any additional suggestions, recommendations, or details on this topic.
ABOUT THE AUTHOR
Mike Cable (firstname.lastname@example.org) is Sr. Consultant with PCI in Raleigh, N.C., providing instrumentation compliance solutions to the life science industry. He is author of ISA’s Calibration: A Technicians Guide (www.isa.org/link/Cable_bk) and contributing author to ISA’s A Guide to the Automation Body of Knowledge, 2nd Edition.