Five Tips For Laboratory Informatics Product Selections

Recently, I was working on a software product selection and when I started making the list of software products to put in the process, it was not the first time that I noticed they were all offering the same features.

Let us stop and be honest about this - at this point, after all these years of laboratory informatics software, many vendors are offering many of the same features. Yet, that does not mean we still cannot find ways to select one product over another.

I have been doing product selections for years and I will tell you that it is not nearly as hard as you think it is. Of course it is easier for me having worked with so many customers to do this. But if you are trying to do it, yourself, do not feel overwhelmed. There are ways to tackle this.

1. Wading Through The Alphabet Soup of Laboratory Informatics With Requirements

We have a laboratory informatics alphabet soup of LIMS, ELN, LES, LIS, SDMS, and more. Too often, potential software customers try to figure out what these mean. The bottom line is that they do not actually mean anything. A product sold as a LIMS might also be sold as an LES, for example. Forget about the acronyms. Gather your requirements and see what products match.

Note: Right about here, I would normally tell you what these acronyms mean. It really does not matter so much so that I will not waste the space on it.

This is where I always tell you to gather your requirements, first. Gathering your requirements will help you understand the first set of criteria you need to look for. In fact, if you have too many to look for, go through and prioritize them. I am not kidding but many of you will be shocked how much this clarifies the rest of the process. And, for those where it does not clarify it that much, there are more helpful steps, so keep reading.

As just one example, if you need to find a product with stability features, and if it is a high priority, you probably would not bother looking at products that do not have that feature.

2. Requirements Are Not Just Features

If your requirements only list features that you need in your system, you will still be stuck, right about now. There will still be too many products to select from.

Do not forget to include all of your other requirements. If you have any legal requirements, regulatory requirements, data reporting requirements, analytics requirements, support requirements, system requirements, hosting requirements, or any other item that has nothing to do with an actual feature, include those. As a group, these are called "non-functional requirements." However, I do not personally always put these into a single group. I often specifically put system requirements together and find groups for some of the others, separate from that.

As yet another tip, if you do not want to include them in your requirements document, you can have a supporting document that is separate. But keep them close together.

3. Requirements Are Not Just for Today But For the Future

Here is where I want to remind you all of something really important - you are not just listing requirements for what you want to implement, today. This is not just meant for you to dump your processes and data into this new piece of software and start operating, today.

These systems are expensive. The licenses are just a drop in the bucket compared to what it costs to implement and maintain them. With that, some of the requirements I add are specific to helping the customer understand what it will take to maintain this system so that it runs efficiently for the future.

This is why I always include questions around what it takes to make changes to the system. Does it require programming, such as C# or Java, for example? Can you do it, yourself, or does the software vendor have to charge you to do it? Understanding all this helps you understand the types of people you need to contract or hire and what type of budget you need to manage the system.

Where I talk about maintenance, keep in-mind your system will grow. Today, it might perform well. Next year as your company grows, will it be too slow? Proper and ongoing maintenance activities are meant to deal with these types of issues. By the way, this is hard work. It is not easy to do. Do not wait until you have these issues to start thinking about this. It is not something you can accomplish overnight.

4. Requirements are Not RFPs/RFQs

Now, I want to tell you that requirements are not your RFP (Request For Proposal) or RFQ (Request For Quote). If you are regulated, and even if you are not, your requirements are meant as a list that you can track back to your test matrix. You will adjust them at a certain point to reflect the system you actually implemented and how or whether it meets various requirements. It will not meet every requirement on your original list, especially in Phase 1 of your implementation.

But back to RFPs/RFQs - ask open-ended questions. For example, if you have twenty stability requirements, do not ask twenty stability questions. Instead, just ask the vendor to describe how their stability features work. You might then ask for more details based on the specific types of studies you work with. However, it is easier to ask what a system offers and try to think whether it manages your own studies in a manner that you find practical. Once you understand the basics, then, you can ask more questions.

Alternately, there are times when we do not really care that much about how something works. For those of you who are still using mainly contract manufacturing or contract labs and do not yet need to handle certain features on your own, this is where you can ask more general questions.

Then, if you think you want a specific set of features for the future, but do not know what you will need, just ask it as a yes or no question, such as, "Does this system provide an environmental monitoring module? If not, in a few sentences, describe how this system could be used to manage that." In that, you at least have an idea what is offered, even though you are not yet ready for those features

5. Understanding COTS Systems

COTS stands for Commercial Off The Shelf. These are systems that come with some pre-built features but which require quite a lot of work to make properly operational within your own company.

Purchasing and implementing them is vastly different from having custom (bespoke) software written for you and vastly different from purchasing smaller, more specific software that you merely install and deploy.

If you do not understand this, this is where you will misunderstand how to deploy and how to maintain your new system. This is where you will either not ask the right questions when you make your purchase or you will not fully understand the responses you get back. In that, your selection process has just failed.

Finally: Cradle to Grave

Whether your system is a regulated system or not, consider everything you do takes your system from the cradle to the grave. It takes you from the day you decide to spend money to buy something to the day you retire the system.

That period of time will either help your company greatly, possibly preparing you for Lab 4.0, or it will be a horrible experience that bleeds money and takes more resources than you imagined for a system that barely supports what it needs to.

Take what I said above to heart. Where upper management or people you are delivering to do not believe what you are telling them, just do your best. These are tough concepts to get across. I know a lot of you have told me how frustrated you are, and how hard it is to know all this but not be able to get anyone to believe you, if you are the expert trying to accomplish this.

It might not help you to know that I believe you and many others out there are rooting for you. Yet, maybe that is all you will get, today, and it will HAVE to be enough.