Do you sometimes feel as if it’s raining acronyms? You see LIMS, LIS, ELN, LES, SDMS, MES and such and you start to think it’s never-ending? Well, you’re not alone.
When It’s Raining Acronyms, Make GeoMetrick Enterprises Your Umbrella
Not only can we help you but we’ll give you the first important tip, right now:
LIMS ELN LES LIS: Theoretical Definitions
This is a brief guide of what the main acronyms (LIMS, ELN, LES, LIS) are “supposed” to mean:
Did You Understand All That? Meanwhile, Let’s Continue
Those are the theoretical definitions of LIMS, ELN, LES and LIS. These are not always the definitions you find in the marketplace. As such, if you’re hearing from a vendor about a LIMS, for example, and think the LIMS they’re describing doesn’t sound as if it match this description, you’re not misunderstanding the situation.
First of all, if you go to a software vendor and tell them, “I want to buy a LIMS,” then some will call what they have a LIMS and try to sell it to you. Others will relabel their software based on the market they want to sell it to. If they’re selling to the clinical market, they might call their system a “clinical system” or a “LIS” but when selling to another market, might call their product a “LIMS.”
The other issue is that we don’t happen to agree on the terms. Some people claim that an ELN refers only to systems that would be used as a laboratory notebook for research purposes. Another example is that there appears to be some people who randomly use the terms LIMS and LIS, interchangeably.
Even where the labels seem to match, various systems are oriented toward different markets. An ELN meant for biology isn’t the same as one meant for chemistry. A LIMS sold for pharmaceutical use might have different features (and cost model) than a LIMS sold to the consumer products industries.
What Do You Do, Now?
If you now wonder what you do if this is so confusing, just remember what we first told you, which is to stop reading the acronyms. But past that, here is what you need to do:
- Gather your Requirements.
- Prioritize your Requirements.
- Determine which requirements are actually going to be given to the software vendors. There might be some that, in the end, don’t quite seem appropriate to include.
That list looks short but you must have already figured out that it’s a lot of work. However, making at least one good pass at this usually gets you to the point where you have a better idea what you need. When you know what you need, you can then discuss your needs with the software vendors.
Right about now, some of you reading this are feeling overwhelmed. LIMS, ELN, LES – they seem to blend together. This is a lot of work to undertake. At this point, you wonder how to get started. There are three basic choices:
When you write your requirements, remember this – they’re not just about process features. Don’t forget to include other requirements, such as regulatory, operating system, database brand, or other non-functional requirements, as well.
LIMS ELN LES : Next Steps
Once you’ve gathered your requirements and start talking to the software vendors, you’ll begin to have a better idea what you need and what’s available.
Here’s what you need to do:
- Make a list of software vendors you think might be potential providers.
- Start contacting these vendors asking some basic and high-level questions.
- Keep track of which ones aren’t suitable and which ones are worth pursuing.
- While you’re doing this, turn your requirements into an RFP/RFQ (Request for Proposal/Request for Quote).
- Send this RFP/RFQ to whomever is left. Only send it to those you’re serious about. This is because you neither want to waste the software vendor’s time on this to create it nor yours and your team’s to read it.
- You will want to read each of these and respond back. You might have more questions about the responses you get. In addition, some vendors will respond in a manner that indicates that they didn’t understand your question. Some will actually have more questions about your intent.
LIMS ELN LES : Demos
Finally, the exciting part – the demos. Now, everyone on your team has an idea what to look for. You will only ask two or three vendors to give a demo. Ideally, you should be able to narrow this to two vendors but, if it seems really close, try to keep it at three.
Otherwise, they all start to blend together. Plus, it’s a lot of work. There are many reasons why you want to keep the number low. At this point, you’ve seen screenshots of the products and know quite a lot about them. Now, it’s time to be able to see it all in action.
A demo doesn’t always have to require the software vendor be on-site, by the way. So, keep that in-mind. If you have a strong internet service, your software vendor could potentially give your demo via some tool such as WebEx. If your service isn’t strong, though, you won’t want to do it that. Another option is to ask ahead of attending a conference you and the vendor will attend about setting up a time to get a demo, there.
If you get to the end of the process and haven’t selected anything, don’t get too frustrated. You’re not alone.
When you get stuck in the process, repeat some of the steps. If you find there are requirements that are confusing to all software vendors, you can rewrite them. If you find you don’t have enough vendors on your list, go out and find more. As with most processes, iteration is the alternative to a dead process.