The Lab Man knows of several large companies that have successful centralized internal laboratory automation groups, such as Amgen, Bristol-Myers Squibb, Eli Lilly and Pioneer Hi-Bred to name a few.  Other companies have taken a decentralized approach, with automation resources scattered throughout various functional groups of the organization.  Regardless of the organization, anyone involved with implementing lab automation in a corporate environment faces some of the same issues and questions.  What technology can I use "off-the-shelf"?  What can be customized to fit my workflow and who does the customization?  What do I need to create or customize myself?  How does the customized technology get supported long-term?  The Lab Man talked with Peter Grandsard, an Executive Director of Research with Amgen Inc. in Thousand Oaks, CA about his Research and Automation Technologies group with regard to these same questions.

Peter indicates the mission of the R&AT department (yes, they call themselves rat!) is to acquire and implement effective laboratory automation technologies to expedite the discovery and development of therapeutics.  They are an eclectic group of 16 employees, consisting of chemists, biologists, engineers and physicists, plus four full-time outside contractors (three system integrators and one machinist).  They are responsible for four Amgen research sites in the United States.

The Lab Man asked Peter what their philosophy is toward "build or buy" given the strong resources in the group.  He replied that they would always like to "buy" and implement technology "off-the-shelf", but Amgen believes that automation and informatics should fit the internal workflow, rather than vice-versa, so often modification of existing technology is necessary.  In approximately one in five cases, some degree of create-from-scratch is necessary - either a component of the system or the entire system itself.  In these cases, they prefer to work with a collaborator, such as a national laboratory, academic group or a commercial technology provider.

Peter says this philosophy really hasn't changed over the past 10 years, but several factors involved in the decision making have indeed changed.  They find the commercially available lab automation technology has improved and become more robust and reliable, thus requiring less tinkering just to simply make it work.  Commercial sources of customized solutions have matured as well.  Peter also finds that his internal resources have matured, becoming more knowledgeable and capable, so they have greater internal capacity to create from scratch.  Interestingly, he says that 10 years ago his (then) less experienced staff was quite eager to "build" but project urgency and some lack of experience often forced them to "buy".  Now, with more experience and capability, these same people are still eager to "build", but better appreciate the business tradeoffs, and so tend to make more balanced build or buy decisions.

When working with outside collaborators to achieve custom solutions, Peter feels that it's key to match the Amgen goals and motivations with that of their collaborator.  For instance, if the Amgen goal involves developing really novel, one-off technology, then they choose a collaborator with a matching mission, an organization with instrumentation research as a focus, such as a national laboratory.  If the goal requires doing extensive biology or chemistry application development, then they may choose an academic laboratory that has "wet science" capability.  If the goal is to create custom technology that then can be replicated and supported across multiple sites, then the collaboration will likely involve a commercial entity.  Peter finds that commercial entities are eager to collaborate today on new development, to share the risk of new product development and test the market.

And what is the philosophy for staffing his group today?  As with many companies, Amgen is watching headcount carefully.  So the R&AT group has created a capacity and capability model, which delineates the type and amount of skills necessary to fulfill their mission.   Certain roles are defined as "core" to their mission and will be accomplished via full-time employees.  Other roles, such as support, maintenance, training, system replication and fabrication are not considered "core" and will be fulfilled via contractors.  Some roles, like system integration, fall into both categories.  When headcount is tight, they lean more toward fulfilling that role via outside resources.

So, that's the inside story from one company.  Why don't you share some of the philosophy from your organization?  Leave a comment!  Please! 

Until next time,

Domo Arigato, Mr. Roboto