Some of the customers who read these posts are working to do as much of the actual work on their system, as possible, to include LIMS/ELN/LES System Administration, configuration, programming, etc… Others have decided that they don’t need to build some or all of these skills in-house and are asking their software vendors or other outside consulting firms (such as the premier GeoMetrick Enterprises) to do the work, instead. In doing this, while you do avoid having to build the skills in-house, you do not abdicate yourself from the potential issues that can come from this.
In my last post, I suggested to customers interested in running mobile apps for their LIMS, ELN or LES that they consider writing their own or having someone write one for them. I suggested writing them specifically for the devices that they will use. But some clever folks are still thinking they’re going to write one generic app that works for everything. They think if they do this that, if they switch devices, they can just swap the new devices in. Here are two more considerations.
These days, a criterion of looking for a new LIMS, ELN or LES is more and more commonly that it have mobile capabilities or some other mobile factor. More customers are looking for this. Yet, how critical is this on your requirements list?
Over time, many systems, despite strong procedures and practices, end up with portions that are convoluted or messy, in one way or another. I see plenty of opportunities where customers could get in and rewrite some code to make it cleaner and easier-to-manage. I’ve written about this, before. And, as before, I think we all acknolwedge that this is a tricky business because, first off, everyone is already too busy to do this and, secondly, it could introduce other problems. But we’re seeing a growing trend in this that I specifically want to talk about: Version 7 LabWare LIMS upgrades.
Most of us consultants probably can tell at least one story where database backup (or lack thereof) plays an important part in a sad story of an implementation that’s gone off-track.
Reporting from the systems we use, the LIMS, LIS, ELN and such, is challenging. Getting data onto a report and in a format that meets the users needs or for regulatory purposes, is not trivial. Today, I will give you three high-level tips on how to get that data out and in a usable format. A lot of your reporting success or failure will depends on the tools you are using, too, of course.
Dealing with unprintable characters is fine when you’re doing it on-purpose but, otherwise, I have just one thing to say about them.
I might have mentioned this but one of the tasks I’ve been doing quite a bit of, this year, is sitting in for missing LIMS system admins. For example, when someone’s LIMS System Admin leaves and you need someone to fill the gap – that would be me doing the filling.
In my last post, “Notes on Software Testing Habits,” I ran through a few thoughts about how to look at your software testing habits. Regulated or not, there are many commonalities.
In LinkedIn, I recently forwarded a post by Martin Lush entitled “Don’t Blame the Person – Fix the System!” One outcome for me from that is that it started a variety of side conversations with other people in the industry. One area of conversation that came up is that of testing, as a general topic and, today, I want to share my own thoughts on testing.