This page contains a Flash digital edition of a book.
inside view Finding the


When it comes to buying a LIMS, there’s a right way and a wrong way. Autoscribe’s founder and CEO, John Boother, explains


ne 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 soſtware. Essentially, they will adjust their own ways of working to fit the soſtware. 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. Tis enables the systems to meet both immediate requirements and those that materialise during the lifetime of the system. Te 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,


30 SCIENTIFIC COMPUTING WORLD


right solution O


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. Tis in turn starts to define the sample registration screens, and so forth. Tis really is a key part of the process. Something that oſten 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 soſtware 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. Te 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. Te 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. Tere 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


TO A LARGE EXTENT, THE ONUS IS ON THE CUSTOMER TO ENSURE THAT THEY UNDERSTAND THE DEPTH OF THE DECISION THEY ARE MAKING


thorough due diligence and by being absolutely clear on requirements. Tere 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. Te 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 siſt through and find a solution that’s right for them.


www.scientific-computing.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32