When selecting a LIMS, ELN or LES, potential customers look for functionality that matches their needs. Additionally, most companies will have some other criteria, such as the operating system or database they prefer to use. But when systems offer basically the same features and run on the same platforms, there are other technical considerations to review before purchasing one.
Web and Cloud
Products developed specifically for the web and for cloud usage are not the same as those that aren’t. Products might technically run in a web browser or in the cloud but it doesn’t mean they can do so, efficiently. If the product doesn’t have a track record running well in a web browser or if it doesn’t have any (or many) customers using it in the cloud, then don’t plan to use it, that way.
Another issue related to this is that products that specifically run in web browsers tend to best run in a specific one. Features such as the grid fill-down might not work if you don’t use the right browser. So, if you have users that have to run a specific browser and it’s not the one your new system best works with, it’s worth investigating whether this is a good idea. Sometimes, the product just doesn’t properly run at all in the wrong browser, possibly hanging during certain transactions, or not bringing up tabs or information that’s expected. If you have hammered your users into complying with a single browser, ask yourself whether you can now break their habit if you have to force them to sometimes use a different one.
Supporting the Beast
Yes, I mean your system. The big systems could especially be considered beasts. They take enormous amounts of effort to maintain and update. I don’t want to make it sound unmanageable, but it might be, depending on your situation.
One of the big support issues will be the tools you will use for making changes to your system. Many systems truly are just a bunch of buttons and such, where you don’t need to be a programmer to change them. But as you move up the food chain to the “big” systems, that changes. That’s where you need to consider your own internal skills and needs.
There are proprietery tools in some systems. LabWare LIMS/ELN and Thermo Fisher Scientific SampleManager LIMS/LES have these. LabWare has its LIMS Basic and SampleManager has its VGL. These languages are designed to be used to help you program in these systems. They’re extremely powerful. Sales people often insist we call them “scripting” languages so that they sound less scary, but you can make major screw-ups with these if you don’t know what you’re doing. Don’t think for a moment that you don’t need programming skills to make major changes with these languages, that includes an idea what I mean when I say “structured design,” SLC or SDLC (if you have to ask what these mean, you shouldn’t be doing it!).
The bottom line is that you can’t have your software vendor or consultants do everything for you, forever. It’s just too expensive. At some point, you MUST have at least some skills to make a few changes and to be skilled-enough to do them in a supportable manner. Sometimes, customers will make the statement “well, then, we just won’t ever make these types of changes” and that doesn’t typically last long as it’s a strategy that’s contrary to the purpose of these products, which is to be extremely flexible.
So, if you don’t want to deal with software lifecycles, code vaults and similar issues, that should greatly affect your decision on which system to purchase and how to move forward both in your purchase AND your implementation.