A few people had noticed that there was a new picture on my blog but that it was not a picture of me. This is one of those situations where I accepted an upgrade, it had unintended consequences (the picture of someone else popping-up on my blog) and I decided not to roll it back – that there are more good features than problems and, also, that I didn’t currently plan to devoting time to kicking that person off my blog, being busy with other things. And, in that, it’s the same issue we face with LIMS, ELN and LES upgrades.
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?
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.
Some time ago, I made a post here about the levels of configuration and the misconceptions around them. What led-up to this post were conversations with customers and the continued realization that customers are still not being educated on what the term “configuration” means in our industry.
In a past post, I mentioned systems that let themselves become non-compliant. The issues I spoke about are actually issues for non-regulated systems, as well. All systems need some amount of maintenance and proper usage. However, there are other symptoms I hear among those groups who aren’t properly maintaining or using their systems. Here are some warning signs.
Some companies will write, generially, by their company names. Others will tell the names of the people who write the articles. I use my name for these posts, not merely the generic “GeoMetrick Entperprises” and I have some reasons for that.
Compliance is so important that even those people such as myself who are not compliance people must to do what we can to help customers work toward this goal. Today, I will give you three documentation tips from the implementation side of the project.