This term has its place in history. Today you would be hard pressed to find a store in a basement or even one that has any real bargains to be had in it. Merriam Webster claims its first use was back in 1948 but it is otherwise scant on the history of the term. As usual they have the right definition: the bargain basement offers products 'of inferior quality and worth' and are 'markedly inexpensive.'
Historically LIMS products were missing functionality or simply did not work and you, the consumer, had to bear the brunt of the costs (and risk) associated with making them better. For some vendors this was a 'win-win' proposition -- a bet they couldn't lose. Once your organization purchased the software licenses you became more than a consumer; you became beta testers and subject matter experts for future releases. If things were not working to some degree at least part of responsibility could be attributed to your own staff. In this climate the costs of maintaining laboratory systems increased for consumers and gave rise to today's LIMS service aftermarket that supplies, among other things, LIMS consultants.
All of these cost increases drove consumers to seek out alternatives. Some came to this website looking for answers. Here the recommendation was, if you are able, just build your own systems. This perspective, taken along with recent advances in the LIMS product capabilities, has been in some cases taken by management to mean that laboratory professionals should build their own systems mainly to reduce cost. Their goal has been to supplement these new initiatives with low-cost technical help that lack an understanding of laboratory processes, systems, or safety. Instead of low-cost bargain basement bliss the result here has actually been a disaster for the dedicated LIMS service industry and a looming one for businesses themselves.
The Bargain-Basement I.T. Resource Vendor
It is impossible to provide LIMS services at low prices unless there is a dramatic shift in the production, manufacture, and consumption of these systems. By analogy, it is impossible to fly to the moon on the cheap without a drastic change in the capabilities involved in the manufacture, production, and consumption of space vehicles.
We appear, however, to be in an age of unprecedented and sometimes completely unwarranted optimism. For example, today people are actually trying to change the dynamics of building space vehicles at enormous expense and with questionable success.
Likewise in LIMS today we are experiencing a shift in the manufacture of these systems, particularly the move away from proprietary customization languages to popular ones (C# or Java for instance) as well as a heavy push toward configurable systems that either reduce or eliminate the need for software code for customization (it is mostly point, click, drag icons, etc.). In short, it is getting easier to make a LIMS customization that can span across system upgrades. This, coupled with the unwarranted and overly optimistic view that laboratory users can instantly develop and maintain their own systems with only minimal outside help, is largely a pipe dream. The introduction of DIY tools and practices into the laboratory marketplace will have the effect of reducing some, but not all, of the needs of a specialist. Done correctly it will reduce costs and improve systems gradually. In the medical profession the division of labor makes a trip to the surgeon unlikely unless a lower cost general physician says it is warranted. This specialization creates opportunities for cost savings and efficiencies in service delivery but in no way makes doctors obsolete. In LIMS we might find generalists and individuals capable of system configuration that are widely available with specialists at the ready to handle more specialized needs. But tossing out the entire system in favor of software tools with minimal IT support is the wrong route.
Unfortunately some organizations have turned to their generic IT resource vendors to supplement their LIMS initiatives.
Resource Vendors Control The Consumption Spoon
Another recent trend in IT involves large-scale service providers. We can liken the arrangement between a corporation and a large-scale IT services provider to be a bit like that of a household with its own dedicated chef. The family no longer wants to cook and agrees to hire a dedicated company to supply all of its eating needs. So long as the family gets three square meals a day and a few snacks the service provider is free to operate as it sees fit.
Continuing the analogy, imagine that the family has to take in Grandma Martha along with her specialized eating needs. She needs to eat at specific times and has dietary needs that are not like anyone else in the household. The service provider realizes that the cost of feeding Grandma Martha is exorbitant and will affect their profit margin. Due to the nature of their contract however they cannot refuse to feed Grandma Martha or ask for more money (they obtained the contract, after all, by promising to be cheaper than anybody else). The solution? Starve Grandma Martha and/or confuse her to believe that she has taken her pills and eaten when she really has not. Her very presence in the home becomes a detriment to making a profit.
The users of LIMS share their lot with Grandma Martha. Their specialized needs will kill a fixed-price/bargain producer's profit margin. That provider's goal in short order will be to make those needs conform to other types of systems that are far less complicated and can be serviced purely by information technology staff. In other words, their goal is to reduce LIMS to something that can be satisfactorily managed by people that can follow a script on an SOP mechanically. Anyone in the LIMS service business knows that this is going to produce unsatisfactory results for anything outside the most basic circumstances but companies cannot see this.
Advances in product capabilities coupled with a company's desire to save money have led some to clearly misunderstand the goal of DIY in laboratory informatics. DIY tools and practices are meant to safely hand off responsibilities to the end user while reducing the workload of the LIMS service provider. The end user community then becomes increasingly helpful in the stabilization and delivery of systems. It was not meant to supplant the need for LIMS service providers. Generic IT service delivery organizations cannot supply LIMS services because they lack the understanding to be effective. The very nature of their business is to reduce costs and operationalize IT system activities, a model that cannot supplant the need for IT professionals that specialize in the LIMS space.
DIY is not something that is going to save your organization gobs of money in the short term. It is meant to enhance your end users understanding of systems. It helps them set their expectations and communicate their desires more effectively with LIMS service providers and with vendors alike. Improper application of DIY principles is causing hardship among LIMS service providers that are in a pitched battle with your generic IT service providers. If this continues it will eventually result in increased system failures, dangerous outcomes for patients/society/laboratory users, and will generally produce unhappy (and under-productive) laboratory personnel.Go Back
Citation: The Bargain Basement. (2016). Retrieved Sun Apr 30 04:59:16 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1475592898