Global LIMS - Is It Worth It?
Standardizing on a single LIMS product is arguably the most common central objective of every new LIMS project at virtually every big pharma company I know of that is actively planning or implementing a new LIMS for their QC or R&D labs. However, some recent experiences on two global LIMS projects have caused me to question the soundness of the whole global LIMS concept. And yes, I can already picture the eyes popping and hear the cries of "heresy!" from corporate IT managers. Let me explain.
When viewed from the perspective of the business (i..e., the lab), the potential pitfalls in these projects are as numerous and deep as gopher holes in the fairway in Tiger Woods' latest Caddy Shack-themed commercial. In one project in which I was involved, corporate lab management was very clear that they wanted the new system harmonized across all their sites. It was then up to the IT project team to drive the project and provide them with ammunition to sell it to the labs. In another project, IT knew they needed to replace two incumbent LIMS, one an aging custom-built legacy system and the other a customized commercial-off-the-shelf (COTS) LIMS. This time it was IT that knew they had to drive the project forward and needed to help sell the idea to two different groups of already contented legacy system users on opposite sides of the Atlantic. My two recent experiences are probably not a statistically valid sampling, but when combined with other "anecdotal evidence" gathered from talking with industry peers, I get the feeling that these are not isolated cases. So why is it that IT and corporate management are the ones pushing the labs forward on these global standardization projects instead of the labs clambering for updated informatics systems from their IT departments?
You're not likely to find many labs that don't want new computer systems that help them do their jobs better. It's also unlikely you'll ever hear of individual site labs in a global organization putting their site priorities aside and calling for global harmonization. So the drive or vision in these global projects is normally developed and justified at the corporate IT and business level. To understand why the drive is coming from there you have to understand some of the potential benefits of standardization.
Some of the most obvious drivers from the IT perspective include issues such as replacing aging legacy systems because of compliance issues or obsolete hardware and software (anyone have a LIMS running on Oracle 7, VMS or a VAX?), lowering costs of software purchases and vendor support through volume buying, lowering internal support costs by decreasing the number of vendor products to be supported, or lowering integration costs by reducing the number of different vendor products that have to be integrated into the enterprise.
From the business perspective, drivers might include reducing costs by validating a core standard configuration once before deploying to all sites, reducing costs of training, and increasing efficiency associated with integrating and sharing incompatible information from different vendor systems. These all generally benefit the corporation rather than an individual lab. Each can be considered as a contributing factor to Total Cost of Ownership (TCO) and standardization generally targets lower corporate cost of ownership as a major justification for global LIMS projects.
So there appear to be some pretty rational reasons for global standardization of LIMS for both corporate IT and the corporate lab management, but the site labs are typically reluctant to buy into these projects. Do they know something that corporate management and IT don't? Does the prospect of standardizing a critical lab informatics tool like LIMS scare them? Are they content with what they have and see no need for standardization with their other site peers? Are they just too busy trying to get samples analyzed and product shipped to even think about another corporate IT project? Are they worried that the new corporate standard LIMS won't be a good fit for the newly harmonized ways of working and be less effective than their current legacy LIMS? In fact, all of these are the most frequently voiced concerns I've encountered in situations where there has been overt or, in some cases, covert resistance to global LIMS efforts from the site labs. It's probably worth looking at each of these concerns from the site lab perspective.
So what could the lab know that IT and corporate don't? Typically they know all too well that the biggest challenge will not be the technical job of changing out the old LIMS for a new one but rather that in order to use the same LIMS globally in a standardized configuration, the lab business processes at each site will have to be standardized. Unless they have their heads in the sand, IT is probably also aware of this but, conveniently for them, this is typically identified as a "business issue" they can't fix.
This is a big deal to the labs because, most of these big pharma companies today are agglomerations of smaller heritage companies (with their own unique histories and ingrained business processes) brought together over the years by mergers and acquisitions. Even in cases where the company has grown organically without any significant mergers or acquisitions, sites in different regions or countries may have been established tens of years apart and been operated independently for many years. Consequently the sites have probably been free to acquire whatever IT systems or develop whatever business practices they needed to operate efficiently in their local environment. As a result, many companies have a mish-mash of different IT systems and organizational and business models.
Many site labs will bristle at statements that they need to standardize their practices with other sites. From a narrow view, looking only at the site labs' needs, there may be no obvious need to standardize. However, the corporate consumers of lab data might have a litany of different data report formats they receive from various sites that need to be converted, compiled, and formatted for things like annual product reviews. Receiving their data in consistent and standardized formats would dramatically improve those processes.
What about the fear factor on the subject of standardizing on a critical lab informatics tool like LIMS? Sometimes this is simply a matter of overcoming inertia or resistance to change. Change is feared because it may disrupt an otherwise smoothly operating process in the lab. Other times, there is a legitimate concern that once all the compromises necessary to accommodate the site requirements have been incorporated into the new system configuration, they'll be left with a "dumbed-down" system that makes too many compromises. This may come down to a situation of "haves" and "have-nots". In these cases, it is probably inevitable that the labs that had the most invested in their legacy systems (the "haves") will perceive the initial global system as somewhat of a step backward while the "have not" sites with the least sophisticated or no system at all will perceive the new systems as a step forward. There is no easy solution to this conflict, but with the right commitment to continuous improvement, the gaps between functionality and expectations should be narrowed with each new global system upgrade delivered.
Any kind of meaningful standardization project is going to require significant involvement of the labs in order to design new business processes and a system that works well for all sites. At times, labs may simply be too overwhelmed with routine lab work or other IT projects to be able to free up key subject matter experts to work on the project full time in order to negotiate and design new processes and LIMS configurations. In these situations, options are limited and the lab may have to provide the resource or risk either delaying the project or getting something that doesn't work for them since they did not have input into the process.
Finally, and this may seem unorthodox to some, but one way to overcome the fear and risk of a mismatch in harmonized business requirements and the global LIMS is to use the constraints inherent in the COTS product to help focus business harmonization efforts. In other words, focusing solutions throughout the harmonization process on gaps between process and functionality, but keeping harmonized solutions realistic by using COTS package experts to rein in expectations.
So back to the original question. With all the potential pitfalls for the lab, is the concept of a global LIMS a wise one to pursue? I think the answer is "yes." While there are many flavors of global LIMS that vary in specific details of the approach and degree of standardization, the potential benefits to the global organization are significant. In most cases the pitfalls can largely be overcome through careful planning, using experienced resources in the right places, and executing the project well. In the final analysis, this is the direction the industry has taken. Sometimes, the needs of the many outweigh the needs of the few, or even the one. To stay competitive, quality and R&D labs in global organizations may have little choice but to make the best of the situation.