Why COTS is preferred
One question that seems to be resolved relates to the battle between a pure in-house custom development project and a commercially available software product. The conflict has largely been won, in terms of volume at least—in the favor of commercial solutions. That is to say, more labs buy commercial systems than develop their own. As laboratory information management systems (LIMS) have matured, functionality, reliability and flexibility have grown to the point where labs can focus on their core competencies—analytical testing—and let software companies leverage their large customer base and code writing skills. There are certainly still laboratories pursuing custom developed solutions but as with other products—ERP systems, CRM systems, sales force automation—a majority of labs have made the transition to commercial solutions. This outcome is based on four primary principles:
Software Development: Commercial solutions in general benefit from a dedicated software development focus and a formal institutionalized process. End products are vetted by multiple customers and if the solution is not robust enough, market pressures will force the company out of business. The internal laboratory IT staff, however well intentioned, does not typically have the same level of development skills. Acquiring and retaining those skills—hiring or contracting—is cost prohibitive for the lab and takes away resources that may be better utilized for increasing testing activity, capability, and quality.
Configurability: A COTS that is “configurable” essentially offers the best of both worlds. The system can be modified to fit the unique needs of a lab but still take advantage of automated and streamlined procedures that fit a more standardized model. The key is that configurability does not require the traditional hard coding that custom systems typically require. COTS systems instead rely on “switches” in the system that can be turned on and off, and on a pliable user interface (i.e. fields that can be easily modified).
Spreading Costs: COTS solutions have a lower total cost of ownership because development and support costs are spread out across a large customer base. This is true for core functionality as well as integration with third party software and hardware. Custom products are inherently one-of-a-kind works of art and all costs of development, upgrade and support are shouldered by one laboratory. Further, with a custom solution, there is no vendor to hold accountable or call center to contact for support.
Technology Advancement: COTS solutions are more likely to incorporate new and improving functionality because software companies are driven by competitive pressure to evolve. A custom solution is by definition created to a very narrow set of requirements and there are rarely funds for investment in developing significant new versions.
Why a Hybrid Fails
A hybrid approach has also been tried wherein a lab may seek out a commercial software solution and take possession of the source code. A prominent characteristic is that modifications to the product go beyond configurability and include code changes. With this “open-ended” model, the expected benefits include a reduction in upfront costs and a greater degree of control. These benefits are often illusory. It may appear to be a shorter path to customization but the related overhead burdens of managing the system are onerous. There are three intrinsic problems:
Increased Staffing: The company must staff up to include a permanent team dedicated to development, integration and support—sapping resources that could otherwise be used in the lab to increase testing volumes. It begs the question of whether or not this is really where a lab wants to invest human resources.
Loss of Development Leverage: By customizing a commercial solution, the basic leverage of a common platform is undermined. Once customization begins, the benefit of cost spreading diminishes and you have a user base of one.
Burden of Support: A mixed support model becomes a double burden. The lab will be forced to provide user and technical support—for the customizations—while the original vendor must still provide some level of support for the core functionality. There is no single source of accountability and the balancing act is untenable. Who is responsible for what?
Conclusion
When purchasing a LIMS, you should absolutely expect a system with the features you need, the flexibility to grow, reliability you can count on, and a reasonable price. While some systems come close, it is doubtful that any one system could exactly match your needs one hundred percent out of the box. Consequently you have to weed through the features, functions, benefits, and costs of each model and do what is best for you lab.
You can develop a custom system that completely replicates every current procedure—good and bad—in your lab but the cost will be tremendous and the ongoing support burden overwhelming. On the other hand, you can buy a pre-packaged LIMS-in-a-box and completely change your policies and practices. Again, the costs to your business will be prohibitive—changing everything you do—and more than likely you will degrade your service to your clients.
We believe a feature-rich solution that is configurable and bends to your needs but also provides a standardized, stable and robust platform, provides you with the best mix of cost and capability. At the same time, such a system enables you to focus your lab resources on analytical testing rather than software development. And your IT team, which is skilled in managing systems, can focus on their primary objective rather than become a software development shop or support call center. You get the benefits of repeatability but the ability to support the practices that make your lab unique—without overburdening your IT organization.