Make your new Smart Lab really deliver: Variety or routine

You might not expect it, but there is routine as well as variety to be found in research labs.  Research is all about novelty, and looking for the next new thing, but there is also standard practice: the routine analysis that tests the stability of a new product formulation, or confirms the structure of a new compound.  This interplay between variety and routine is the third topic covered in our recent paper Five Factors of Smart Laboratory Success.

In large R&D organisations, we have seen a trend towards specialisation and centralisation to bring costs down.  Labs are reorganised so that there are centres of excellence offering a service to the rest of the business, so that expensive equipment or scarce skills are used efficiently.  These reorganisations also focus on the software systems supporting the work in the lab.  Depending on where the lab work sits on a continuum from business services laboratories to pure innovation-driven research, the degree of flexibility needed from a software solution can vary from low to high.  For labs that provide a routine service, the focus is on delivering a reliable service with a reducing budget, and meeting KPIs for performance and quality.  For research labs exploring new technologies, there are different challenges including securing IP, improving data sharing across the organization, and controlling resources and costs. In these labs especially, detailed needs will change, so solutions must be flexible, and you must be able to resource the changes needed on the fly.

Have you ever come across a vendor that doesn’t claim ‘flexibility’ for their product?  All too often this means that they can build anything you want to your specification – but it will be a painful and expensive process to change this afterwards.  As part of your requirements analysis, work out typical examples of flex you will need and make sure that the suppliers can demonstrate these against detailed use cases.  Agree in advance how you will resource or pay for change.  Is it as simple as a superuser making configuration change or updating templates, or will your IT support team need to be involved?  Is their time, or time of IT support, secured within the funding for change?

Looking at the balance between variety and routine was a very effective discriminator in an ELN selection exercise we ran for a global pharmaceutical company.  Working with them, we conducted a requirements analysis both their small molecule and biologics operations.  The smaller scale and greater variety within biologics led to choice of a lower tech LIMS than the management had originally expected, since a smaller supplier could demonstrate that superusers would be able to carry on with configuration and localised implementation in different labs as the system was rolled out.  A ‘larger’ and better known system had more features but it became clear that the ‘configuration’ would have to be done by the suppliers and that reconfiguration after that was likely to be both difficult and expensive, essentially requiring a new, detailed requirements analysis and implementation for each new use case.

Another approach we have followed is to understand and manage variety, so that it can become routine.  This was an effective strategy for one of the world’s biggest producers of paints and coatings. They wanted to increase throughput and reduce time-to-market when formulating a new product.  Developing a new product formulation involves testing a vast number of possible combinations of basic ingredients.  To do this faster, they invested in a robotic system for high throughput experimentation.  However, they found that the breadth and flexibility of the robot interface meant that technicians were taking up to half a day to prepare the system to run each experiment.  When we got involved, we were able to develop an interface that allows scientists to design their experiments using predefined building blocks, and then supports the lab technicians by automatically preparing the experiment configuration for the robot. This approach of encapsulating the lab robot’s flexibility in software allowed them to double the throughput of the HTE lab.

Another way our customers try to manage routine work is to find external partners to take it on.  Sending routine tests out to a contract research organisation might solve one problem, but it often introduces a new ones:  how do you handle results coming in from someone outside your organisation?  For some answers, wait for my next blog, or you could go ahead and dig into Tessella’s white paper: Five Factors of Smart Laboratory Success.


Simon is a business analyst and consultant with more than 10 years experience in pharmaceutical ...

Latest Tweet from

RT @Tessella: Read @AnalyticsCave Matt Jones' latest blog on @ForbesTech How Do We Avoid The Threat Of Supercharged Artificial Stupidity? h…

about 5 days ago

© Copyright 2018 Tessella
All rights reserved