Starting a Lab Automation Project
Before starting any lab automation project, or scheduling visits with automation vendors, it is essential to first meet internally with all stakeholders involved in the lab process to gather specifications and thoroughly identify any key challenges related to automating a scientific process. Stakeholders will include lab management, lab staff, and in-house engineers, as well as key lab clients. Though some may question the need for their involvement, lab clients should be considered essential to this initial discussion of lab processes because any changes to accommodate automation will potentially cause changes to upstream processes. For instance, automation decisions may impact how samples or specimens are obtained or which containers (labware) may be required. Therefore consider it a best practice to gather buy-in from key lab clients before implementing any drastic changes to upstream processes or allocating capital dollars.
The task of generating a list of specifications and key challenges for your automation project can be complicated by a wide array of requirements and topics. Your list of requirements might include specific instrument performance parameters as well as management and staff expectations. Although these expectations may vary between stakeholders, your requirements gathering process should attempt to separate absolute needs from desired needs and nice-to-haves. A thorough and detailed process will attempt to identify all variables and limitations such as throughput requirements, types of labware, volumes of fluids dispensed or pipetted, environmental needs of samples and reagents, types, and placement of barcodes, budget, (capital and operational), etc.
A process map should be generated if not already available. One goal of the specification gathering process is to identify the key ”Constraints” and any ”Pain Points” in the process. These ”Constraints” and identified ”Pain Points” will typically drive the automation design and end solution. Sometimes the points are obvious while at other times it takes some evaluation and research to identify them. Key constraints are often varied and unique to every process. Sometimes a process will have only one issue; sometimes multiple issues.
Take extra care when addressing current pain points in a process. When identifying pain points you may uncover steps that staff members do not like to perform, they may also be procedures difficult to automate or can inherently slow down the process. Automation may address some of these process pain points only to create new ones. Likewise, there may be situations when these pain points should be ignored, commonly when certain process steps are outliers or exceptions to the normal everyday process. Focus your automation solution on the common everyday process, take note of the exceptions and outliers, and then deal with them in a secondary project.
Gathering Requirements: Needs, Expectations & Constraints
Many research automation kickoff meetings start with lab management listing their needs, desires, and expectations (initial constraints) for their new automation system. Over time we’ve found that three key requirements and constraints are discussed for almost every project:
The problem with this type of expectation is that some requirements are mutually exclusive and can negatively affect one another. For instance, ultra-fast systems will typically cost more and flexibility will be limited, or an ultra-flexible system may also cost more but perform more slowly. And so on. Work done to prioritize these three requirements (Speed/Cost/Flexibility) will benefit the project and help deliver the best possible solution.
A few other requirements may be brought up from time to time such as the need for a reliable or robust system or the need for a system that will run unattended or overnight. Also keep in mind that there is a long list of common requirements and constraints that are rarely brought up during initial meetings, but are equally important to address early in the project. The following is a brief description of issues that always need to be discussed and defined.
|Throughput Needs||Do not use yearly throughput numbers for your throughput needs. Rather, plan your system on worst day throughput scenarios. There are often seasonal or peak periods that should be the focus of planning|
|Capital Budget||Most stakeholders will not wish to discuss how much capital funds they have available. They will prefer to discuss the ideal solution first and then make the funds fit the concept. It is best to know the expense limiters upfront. This is often the key constraint in automation system planning and will set expectations early in the process|
|Proper Solution Focus||Is this is a system built to run for hours, or overnight while no one is watching over its operation? Robustness, reliability, and system redundancy are going to be key factors when designing, integrating, and load testing this type of system.|
|Need for Unattended Operation||Are you addressing or automating the right processes in the lab? Are there other processes that are more easily automated, less expensive, and have a higher impact on the lab process overall?|
|Business Impact (ROI)||There are several benefits to automation: cost reduction, higher throughput, ergonomic, reduced staffing needs, and several others. One of the most critical mistakes that can happen in an organization is to spend major capital dollars on automation and get no identifiable benefit. This can be avoided by clearly defining and promoting the benefits and return on investment upfront.|
|Space Needs||Another major constraint for automated system design is that laboratory square footage is expensive, and automation can take up a good deal of real estate. Having a laboratory with an open floor plan is the most ideal situation, but there are times when automation may have to literally fit in a closet.|
|Utility Needs||Automation may have additional utility and environmental needs (power, air, DI water, room temperature, and humidity) that the lab may not have readily have available. Upgrades to utilities can be costly and put some project budgets out of reach.|
|Back-Up Plans (Plan B)||Be sure to develop plans to keep the lab functional even when the instrumentation/automation is down (maintenance, repairs). Instruments do not take days off, but they do get sick (malfunction). Having a plan to deal with the lab’s workflow while repairs are being made will go a long way in reducing stress with the lab staff.|
|Future Proof||Although a difficult topic, it is important to measure how well you’ve future-proofed your automation plan. There are constant changes in lab workflows and throughput needs. How far in advance are you looking? Technology is constantly being advanced, upgraded, and changed. Are you buying ten-year-old equipment or the latest and greatest technology? Will your system be antiquated and not supported in one, two, or five years?|
|Freedom to Operate (FTO)||This may come into play if you are developing a totally custom automation instrument or solution. If someone or some company has developed and patented an idea or instrument, you may not be free to proceed with your project. Getting legal advice on this issue is recommended|
|Cost of Service Contracts||Labs may have budgeted for the initial capital cost of owning automation but the continuing cost may put a strain on yearly budgets. Service contracts can range from 10% to 20% of the initial costs per year.|