Skip to content

Out on a LIMSThe Blog for People Who Risk Life and LIMS on a Daily Basis

Can R&D and QC be Combined Into One System? Five Factors to Consider

Volume IIEntry 71 of 113 in 20162 min read5 comments ↓

Written by Gloria Metrick on . Published as written. It may not reflect how these systems work today.

I have been working with customers quite a bit on product selections, lately, and one topic that frequently comes up, especially for small companies that can afford a limited number of systems, is whether R&D (Research & Development) and QC (Quality Control) can share the use of one installation of a laboratory software system. I'm about to give you the consultant's answer, "It depends."

It actually does depend on the product you select. Let's talk about five factors that influence this:

  1. Workflows. R&D and QC cannot share a workflow. If it's difficult to add and manage multiple workflows, the system cannot work for both groups in the same installation. Each group has their own reasons to "approve" things. In R&D, it's more to keep others from reading their work before they're ready. In QC, it's because they're required to route their work through a specific number of approvals.
  2. Analyses. They cannot use the same analyses. You might look at their list of analyses and say, "Well, if it walks like a duck and it talks like a duck, it must be a duck." Yes, but one is Moscovy duck and the other is a Crested duck. The R&D duck (analysis) has the possibility to change and possibly has different components and restrictions than the QC duck (analysis).
  3. Audits. R&D folks don't usually need to be prompted when they change a result but QC people usually do. This is just annoying to force the R&D folks to enter things that they don't need.
  4. E-signatures. R&D folks don't usually want to use the e-signatures and, if they do, only in the most limited fashion. This is as opposed to the QC folks who find a lot of places they plan to use these. Having to use this in a universal way will just kill the R&D process - it's just way too much to ask them to accommodate this. If this can't be setup separately for each, then they can't share the implementation.
  5. System Administration. Normally, both groups can come to some agreement regarding how they will manage the system. It requires they agree on some naming conventions that will keep them from stepping on each other or possibly some security measures that keep their data separate. If they can't come to terms on this, they can't share a system.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

The conversation

5 comments from 3 people, July 27 to July 28, 2016. Gloria replied 2 times.

  1. jefflv

    This is a great article. I get this question every so often, and these are nice, succinct responses that match my experience as well.

  2. Terry Iorns

    Another consideration I have often seen is frequency of upgrades and management of customizations. R&D usually wants the latest and greatest at all times while QC only wants critical updates because of the cost of revalidation, retraining, and maintenance of any customizations.

    1. Gloria MetrickAuthor

      With regard to the "latest and greatest" I see more-and-more companies offering quicker updates. With regard to the iVention iLES system, when I mention to people that it offers continuous updates, some find it a really cool idea others seem to find it a bit frightening. One of the questions I am most frequently asked about it is whether you HAVE to accept those updates. In the case of iVention, you definitely don't have to.

      However, in the case of the other vendors where there are quick updates, I find that they don't force those updates on customers, either. If someone was going to buy such a product, I'd say that it's almost certain that you get a choice on whether to take the updates but I'd definitely make sure I asked that question if I were the buyer, just to be 100% sure about it.

  3. William D Tumbleson

    Another good article Gloria. For my take, a few LIMS in the market today can separate their workflows in a way that they can be used with different groups rather successfully. But that is not to negate your points, you are dead on. Sometimes it is a matter of computing efficiency ... you don't want to overload your computing resources with too many groups and records slowing down how quickly you are able to store and retrieve data, but as importantly when down time comes (and it will) you want as few groups affected as possible at any one time. Thus separation makes more and more sense.

    Where I see a more difficult issue is when you have an organization that tries to force all users of the system to use it exactly the same way. And thus, we are back to your points. All valid, and all true!

  4. Gloria MetrickAuthor

    This comment specifically refers back to Bill T.'s comments on workflow but also to the conversation in-general:

    A couple months ago, a potential new customer called me to talk about selecting a new LIMS/QMS/ELN/whatever. But they had started the process and actually already signed a contract to buy a system that was not in those categories but that was a completely workflow-driven piece of software (yes, I know you're going to ask why they called me if they'd signed the contract, but you know sometimes people for free would like a little validation of the fact that they didn't make a huge mistake).

    They asked me (and not verbatim), "So, isn't LIMS and these other system really just about workflow? Isn't that where the main issues are at?" Thinking about that, my basic response was that, yes, that really is a major issue. And while I did bring up other factors with them, such as instrument integration and the fact that someone selling a LIMS knows how to implement the LIMS processes better than someone selling a system that's more generic, that's all I came up with at that very moment.*

    As such, for all these new products coming out that are more workflow-driven and especially those coming out in our own industry, I have to wonder if that makes this entire discussion one that will become moot in the future. Ten years from now, let's see if we're still having this discussion.

    Not that it matters for the sake of this discussion, but for those of who you are curious-enough that you're going to e-mail to ask this, the outcome was that the potential customer says that they know their processes, the vendor doesn't need to, and that they will make sure the system reflects what they need and that they were quite comfortable with that. Some customers really can do this and so I wished them the best and moved along.

Comments are closed. This conversation is from 2016. Ask us to remove a comment

Working on the same problem in your lab?

Talk to a laboratory informatics scientist