One of the topics that I’m most interested in at the moment is the question of how organisations buy a LIMS. It might seem like that would be quite obvious, but there is a lot of poor information out there and anyone thinking of investing in an information management system needs to tread with care. A key point to remember is that a LIMS is a solution for a problem, rather than simply a product. Let me make a distinction here; out-of-the-box solutions on the market are products that are delivered to customers who then have to adapt their processes to fit the software. Essentially, they will adjust their own ways of working to fit the software. What should be happening, however, is that the solution is configured to meet the precise requirements and processes of the customer’s business. And there is a very significant difference between these two approaches.
Of course, the way these situations are handled can make the difference. Due to a number of factors, such as a lack of infrastructure resources or funding, very small laboratories lend themselves to out-of-the-box solutions, but they should choose ones that are highly configurable and that have clear upgrade paths. This enables the systems to meet both immediate requirements and those that materialise during the lifetime of the system.
The first step in defining requirements for a LIMS is to decide what reports the lab wants to generate from the system – this is crucial given that the main benefit of a LIMS revolves around the way in which the reporting of data and information is managed. When looking at a LIMS workflow, there will be a sample registration function that will vary widely from laboratory to laboratory. By identifying the reports that are needed, customers are defining the data that needs to be entered into the system beforehand. This in turn starts to define the sample registration screens, and so forth. This really is a key part of the process.
Something that often gets overlooked is a requirements document. Surprisingly, it is not always viewed as a necessity. However it should be recognised that a requirements document only provides a snapshot in time that addresses today’s laboratory needs. While this is important, what is absolutely imperative is that the chosen system can keep up with fluctuating requirements. If it does, the lifetime will be extended significantly, leading to a reduced cost of ownership on average per year. One of our oldest installed systems has been in operation for 22 years, and it has been able to continue as the upgrade path has enabled the company to keep up with the latest features and technology.
Looking at the publicity material from major LIMS vendors, it would be easy to view every system as being configurable. But the danger lies in the fact that some customers don’t really understand precisely what that term means. As far as many vendors are concerned, it means the writing of code, making the customer vendor-dependant as opposed to the self-sufficiency that comes with configuration tools. I do believe that some customers are misled into believing that configuration means something they can do, whereas most systems actually require software developers on site. And you only have to look at the job ads to see the qualifications required for system implementers for LIMS companies.
All of this is only adding to the stigma associated with LIMS in certain quarters that states that they never work as they should or do what is expected of them. The industry really needs to overcome this issue and the way to do that is by addressing the gathering of requirements, the scope of projects and by fully describing the system types on the market, with attention paid to what is necessary for implementing new or replacement systems.
The stigma has lessened now, but there are still cases that serve to enforce it. For example, I know of a system that went into a UK site in 1996 and the company still has IT personnel onsite adding extra programs. There is also a contract lab that spent millions of pounds on a system and it has had eight programmers onsite in the past two years. Again, these situations could have been avoided by simply performing thorough due diligence and by being absolutely clear on requirements. There really are many issues that continue to surround the implementation of LIMS, and not having the time to write down requirements is essentially giving a vendor a blank cheque. LIMS are not necessarily small investments and so need to be approached very cautiously.
When a customer goes through the process of justifying why a LIMS is needed, it’s imperative that the various people who will use the system are involved in the process early on as this will lead to a far greater buy-in from the user base. The basic point to remember is that, to a large extent, the onus is on the customer to ensure that they really understand the depth of the decision they are making. It really is a case of buyer beware, but there is some good information out there – such as our free guide titled ‘How to buy a LIMS’ – that can help people sift through and find a solution that’s right for them.
