A highly valued operational goal of most technologydriven enterprises such as research and service laboratories is the seamless integration of processes and data into a tightly unified continuum to provide accurate updates on key metrics such as income versus expenditures, workflow rates, the status of samples, time expended on particular tasks, the demand for products and services, and the state of inventories, among others. One of the most important contributors to the success of this goal is an innovative combination of computer hardware and software tools that incorporate bundles of applications and capabilities—commonly referred to as enterprise resource planning (ERP).

The origins of ERP systems may be traced back about 20 to 30 years to materials resource planning (MRP) systems, which handled inventory, scheduling, and planning in the manufacturing sector, says Pat Phelan, a research vice president at Gartner who advises IT outfits and businesses on ERP strategic planning; ERP globalization; and a variety of related implementation, support, and development issues.

“The term ERP was coined at the time when software vendors were starting to package or bundle different components of their offerings into suites of software. This transcended materials planning and started to include backoffice functionality such as finance, human resources, and payroll,” says Phelan. She explains, “There was a transformation from bundled packages that had several applications for manufacturing functions to bundles that enabled business management, including back-office administration.”

Turning to the question of ERP systems in laboratory operations, Phelan says that ERP systems do not typically include industry-specific, technical data handling. Some aspects of pharmaceutical operations may be exceptions that include inventory management or sales processing, which may be linked to order, customer, or vendor masters with built-in product expiration dates. “Some of that kind of information may be found in the basic ERP solution, but technical laboratory results, experimental tracking data, and other specialized information would

Phelan explains that ERP systems are focused mainly on the administrative and managerial functions needed to run businesses. “In manufacturing entities, there may be some way to leverage the MRP aspect—inventory, supply chain, planning, and scheduling—into the laboratory environment,” she says. One caveat is that such systems may not “instinctively be a good fit out of the box because they are not necessarily designed with [the] laboratory environment in mind.”

The utility of ERP systems in the laboratory may be facilitated or even enhanced when they are integrated with laboratory information management systems (LIMSs) in a way that harmonizes the lab’s internal and external business processes. As they become more established, it is evident that LIMSs have broadened out from their laboratory-centric focus on the management of samples and reports. LIMSs are now integrally involved in the enterprise-wide dissemination, sometimes globally, of technical and scientific information. They are increasingly being deployed to optimize and improve quality control, resource allocation and deployment, cycle time, and overall productivity and quality.

Because they touch almost all operational areas, ERP systems have evolved into the integration hub for other information management systems in many business enterprises. The work assignments of in-house QA/QC laboratories in manufacturing entities, for example, are initiated in the ERP system, which typically alerts the LIMS and other relevant functions such as the manufacturing execution system (MES). Communication between disparate systems such as LIMSs and MESs is facilitated by the ERP.

In an American Laboratory article (March 2004) entitled “Integrating LIMS Into a Large-Scale Manufacturing Environment,” Colin Thurston, LIMS product manager with Thermo Electron (Cheshire, UK), noted that a typical ERP-LIMS interaction entailed downloading “quality data plus any reference data to [the] LIMS” and uploading “either summary results or disposition decisions to [the] ERP [system].” Thurston wrote that once results are entered into the LIMS and all the parameters are verified, they may be sent to the ERP [system] automatically for any additional processing. He noted, “Either the LIMS or ERP [system] can be the trigger for usage decisions regarding product disposition, delivery, or shelf life.”

Addressing initiatives to promote the integration of LIMSs and ERP systems to drive the uniform distribution of quality information in organizations while raising the efficiency of operations, Thurston wrote, “… some LIMS vendors have introduced standard interface solutions to integrate LIMSs with leading ERP systems, such as the Enterprise R/3 (SAP Software AG).” He explained that such interfaces required “a special, functionally rich enterprise-centric LIMS to expedite the bidirectional data flow between the laboratory and manufacturing, streamline data handling, and integrate data collection and reporting.”

Pointing to the flexibility and user-friendliness of LIMS-ERP system interfaces, Thurston pointed out that some progressive LIMS vendors have created “user-driven mapping functions as part of their ERP integration solutions.” He explained that these gave LIMS users easy access to information from the ERP system in a familiar LIMS format. “Advanced inspection point processing functionality allows inspection points to be created within the LIMS via a configurable mapping process so that recognizable data objects can be sent, for example, to the R/3 quality management module.” He added that upgrades only required “simple reconfiguration of the objects in the LIMS interface.”

Not unexpectedly, there are often problems using this interface. In many quarters it is considered unacceptable to implement laboratory software systems that are not able to communicate effectively, and there is the growing expectation that beneficial interfaces should be automatic. While there have been notable improvements over the years, by and large interfacing between software modules has not been trouble free.

Then there is the question of duplication—as labs increasingly assume the posture of a business that has to manage planning, inventory, and accounts payable and receivable functions, among others, LIMSs are being viewed as surrogate laboratory ERP systems. This leads to the inevitable question: If both the ERP system and LIMS are robust and can deliver all the necessary information as well as facilitate laboratory activity, is it necessary to have both?

In an article in Scientific Computing World (January/ February 2005), Mark Gonzalez, technical director of LabWare Europe, noted that while ERP systems work well as the central dominant software system in production, requirements such as terminologies and detailed workflows of laboratories are quite different and may sometimes conflict with those on the production side. Gonzalez used the example of the term “sample” to elucidate: “From production’s perspective, a ‘sample’ is a jar full of some liquid, powder, or solid that is sent to the lab; from the lab’s perspective, a ‘sample’ is a collection of tests to be done. One jar can easily lead to many LIMS samples, such as aliquots and subsamples. Equally, LIMS samples are sometimes created from composites of several production samples.”

He explained that labs have detailed workflows that cover sample handling. “These workflows include basic elements such as sample login and result entry, as well as more complex elements such as sample sequencing and data review.”

The dynamic nature of labs—complete with constant workflow changes—is seen by Gonzalez as added justification for deploying and using LIMSs versus the exclusive reliance on ERP systems in laboratory settings. “Large-scale ERP systems can be updated to reflect these changes, but these updates tend to have an effect on non-lab-related activities. Since a LIMS is primarily a laboratory system, it can be updated and reconfigured to address workflow changes without affecting the rest of the business,” Gonzalez explained in his article.

What seems clear now is that after about 25 years on the market, vendors are not rushing to change the core functionalities of ERP systems. At the heart of ERP systems are the financial and accounting modules, which remain largely unchanged. To be sure, there have been innovations among the supporting technologies around the core capabilities. In practical terms those innovations responded to a strong need for simplification among users—easier ways to enter and use the data that has been collected and inputted into ERP systems. In fact, one of the distinct current trends is toward simpler interfaces and deployment methods for users. In its 2010 Magic Quadrant for ERP for Product-Centric Midmarket Companies report, Gartner observed the following: “The improved ease of use, extended search capabilities, and moreintegrated analytics features drive the use of ERP by more types of users.”

As mobile and wireless devices such as smartphones and tablet computers become more ubiquitous—and more widely accepted in the laboratory setting—vendors are striving to make their ERP tools accessible via simple user interfaces on heavily used mobile tools such as the iPad or optimized Android applications.

Looming as the largest area of change in the ERP arena now is the growing enthusiasm for cloud computing by companies, along with the software as a service (SaaS) model for making ERP software available to end users. A cloud-based approach to ERP could simplify the complexities typically associated with the technology, while SaaS substantially reduces the need to build in-house capabilities to accommodate ERP tools—appropriate software can be accessed from a provider’s repository, as needed, over the Internet.

Gartner’s Phelan says, “Today we are watching for new and old vendors to reinvent themselves in the cloud. We don’t think that all the ERP in large complex organizations will ever be completely in the cloud, but there are some aspects of ERP that would be a good fit … [so] we are watching this very closely right now.”

Turning to the question of future challenges, Phelan sees some troubling issues around security.

“Not all the vendors are transparent about how they are securing things and ensuring quality, security, and compatibility among different ERP components. A system may be secure by itself but changes substantially when you combine components that are not compatible,” she says. In addition, she sees some future challenges in the use of disparate data taxonomies and policies across organizations and countries. The pace, management, quality, and control of change in the ERP arena also constitute important future challenges, according to Phelan.