ELSEVIER Laboratory Information Management 26 (1994) 37-42

Chemometrics and intelligent laboratory systems: Laboratory information management

Laboratory automation: quo vadis? *

R.D. McDowall * Department of Chemistry, University of Surrey, Guildford, Surrey GU2 5HX, UK

(Received 20 Februaj 1994; accepted 15 March 1994)

Abstract

The future of laboratory automation is debated. The current status of laboratory automation is analysed and suggestions are made for the future. Laboratory automation should be organised globally within companies; have its own strategy which defines individual projects with their own cost codes. Organisationally, laboratory automation should have its own staff with a dedicated performance appraisal scheme. An individual automation project should be resourced professionally by both the line function and the automation specialists. To measure the success and to monitor and control the project, the performance metrics of the finished system should be defined before work on the project commences. 7

1. Introduction

Laboratory automation is the subject of many books and papers. There are a number of inter- national conferences devoted to the various as- pects of the subject: the International LIMS Con- ference, Laboratory Automation and Robotics (ISLAR), Automation and Laboratory Exposition (ALEX) and Automation, Robotics and Artificial Intelligence to name just a few. Also larger con- ferences may have an automation component within them.

* Corresponding author. Mailing address: 73 Murray Avenue, Bromley, Kent BRl 3DJ, UK. ?? Paper presented at the Third International Symposium on Automation, Robotics and Artificial Intelligence Applied to Analytical Chemistry, San Diego, CA, January 1994.

There is great commercial activity by both in- strument, software and system vendors because of the large potential market in analytical, pro- cess and clinical chemistry. There is great intel- lectual activity also. But just how successful have we been in implementing automation?

The central thesis of this article is that labora- tory automation offers great potential but often fails to deliver. Hence the question: Quo vadis, or, are we on the right track?

Following discussions with others and from my own experience, many automation projects are conceived on the whim of individuals, the proj- ects rarely have defined end points and have variable management support within organisa- tions. In this article, I will present my views of why this occurs and offer some possible ways to overcome the problems.

09255281/94/$07.00 0 1994 Elsevier Science B.V. All rights reserved SSDI 0925-5281(94)00004-E

38 R.D. McDowall/ Laboratory Information Management 26 (1994) 37-42

2. Status quo: the real world

Let us first review how we plan and execute automation projects at work. In most major or- ganisations, laboratory automation is carried out by enthusiastic laboratory people who try to fit automation projects around their regular job. As such they can run into management or project conflicts which may result in them failing to de- liver in both areas. When this occurs the usual result is that the automation work is dropped and the routine work is completed. The supervisor will be judged on the routine or normal work and rarely on the automation project. Therefore the pressure is put on the laboratory worker to stop the automation project and complete their nor- mal work.

In the majority of laboratories and organisa- tions, automation is not organised centrally and experience is not available to all.

This is so easily influenced by the attitudes of local management who can actively support and sponsor laboratory automation within their own areas or restrict it. As laboratory automation is organised locally, it is run at the whim of local management. A change in local management can have great influence on laboratory automation in an area: for better or worse.

Thus begins the first reason for failure of automation: unprofessional resourcing of proj- ects. Laboratory automation scientists are rarely allocated full time to automation projects.

Individual projects are usually poorly justified and have few, if any, performance metrics to measure success or failure. Performance metrics can be defined as the quantitative means to quan- titatively measure an automation project. They can be used to define the success, minimum ac- ceptable performance or failure of a system. However, the metrics should be defined at the start of the project.

Furthermore, the majority of laboratory au- tomation projects are local and the experience gained usually resides locally with a few individu- als. This experience is invariably lost when an individual moves out of a department or bktween companies. This invaluable experience, that is learned by success and failures, is rarely passed between functional areas and remains at the local level.

3. The root causes of failure

There are two main reasons for this lack of technology transfer:

- Political boundaries between functional groups can actively prevent or discourage the transfer of information about automation proj- ects. A manager can feel that the investment in automation is his or her own and does not want the expertise passed on. This may be simply for personal gain.

There are a number of root causes that we should investigate to understand the reasons for the perceived failure of laboratory automation. Once these causes are understood, they must be solved before laboratory automation can really play a major role in organisations. We look at the problems from three sides: from the perspectives of management, the users and the practising au- tomation scientist. Note that the root causes are human and not technological.

3.1. Management

- Individual groups work in isolation and sim- ply by lack of knowledge are ignorant of what other scientists are doing in the area. This is because there is no mechanism for the transmis- sion of this knowledge. It is passed through an organisation informally through personal con- tacts, two members from the same company meeting at a scientific meeting or even through a vendor.

The heart of the management problem is their failure to perceive the wider benefits (or, indeed, any benefit) from an investment in laboratory automation. This can be due to a number of factors:

worked at the bench.

- The attitudes of management and their fail- ure to understand the potential of laboratory automation. The lack of understanding is usually based on ignorance: I didn’t do that when I

R.D. McDowall /Laboratory Information Management 26 (1994) 37-42 39

- Closely allied to the lack of understanding is the fear of creating an alien environment. This environment they cannot control due to lack of knowledge and understanding, thus the beginning of a vicious circle.

- Failure to organise and plan automation on a global and strategic level. There are very few examples of laboratory automation being success- fully organised on a large scale;

- Failure to resource projects professionally: Setting up automation projects but when there are resource conflicts pull staff from automation work for normal duties. Allied to this is often a failure to set priorities for automation projects and maintain them.

- The lack of appraisal schemes for staff working on automation projects.

3.2. Users

The heart of the user problem is very similar to that of management. Again the failure of many users to perceive the wider benefits (or, indeed, any benefit) from laboratory automation which can be due to a number of factors: ?

- The attitudes of users and their failure to understand the potential of laboratory automa- tion. The lack of understanding is usually based on ignorance: I don’t want to change and per- ceived threat to either jobs or known ways of working (fear of the unknown).

- Allied to the lack of understanding is the actual fear of working in an alien environment. This environment may require new skills e.g. computer skills; as they cannot control this envi- ronment users may become resistant to change or hostile.

Note how the first two management points are similar to the user points above. Yet without the active involvement and commitment of both groups, laboratory automation will fail.

3.3. Automation scientists

Caught between the pincer movement of labo- ratory management and the users are the au- tomation scientists. However, practitioners of lab-

oratory automation are not blameless and can have attitudes or approaches that can cause prob- lems.

- Lack of a business case for most automation projects (toys for the girls and boys syndrome). This occurs less often these days but we are still bedeviled by some of the first automation proj- ects involving robots in the early to mid 1980s where many ended in failure because the applica- tion did not have sufficient thought put into it.

- The inability of many automation scientists to realise that laboratory automation is multidis- ciplinary. Many early projects failed because of the failure to include the other disciplines inher- ent in laboratory automation: mechanical and electronic engineering, communications, interfac- ing, computer science, etc.

- Reward schemes for scientists working on automation projects are usually poor. The work is usually not recognised as part of their normal function. There may be a local manager who may be very supportive of a local group but recom- mendations for reward or promotion may fail with senior managers.

- Many projects concentrate on automating the status quo and often do not look into the future. There are a large number of robotics applications that have automated sample prepa- ration but have failed to integrate it with the analysis stage of a procedure. While sample preparation has been speeded up there may still be a manual process for linking the robot with an instrumental analysis.

- There is a lack of performance metrics for most automation projects. This does not allow an objective measure of success for an automation project. Performance metrics, such as turn-around time, the time to complete a certain task or productivity figures, enable design and control of the project during the implementation and the means to measure success once complete.

- Interaction and communication between the automation scientists and management and the users can be sporadic and at worst non-existent. This is grave failing that can allow the fears of both groups to grow and ferment. Communica- tion, at the start of a project and during it, about the potential and benefits of automation and the

40 R.D. McDowall /Laboratory Information Management 26 (1994) 37-42

project’s progress should be a prime requirement of staff leading automation projects.

4. Quo vadis: possible solutions for laboratory automation

This section covers the areas that must be improved to enable laboratory automation to op- erate effectively on a global scale within organisa- tions. Table 1 summarises the status quo of labo- ratory automation and the evolution required to achieve an effective organisation that can consis- tently deliver projects.

4.1. Global laboratory automation organisation

Companies organise information technology (IT) and information science departments on a global scale. Why not do the same for laboratory automation? Some laboratory automation proj- ects are IT projects in their own right, e.g., labo- ratory information management systems (LIMS). However, many automation projects actually bridge the laboratory bench and a major IT pro- ject, such as robotic systems for preparing and analysing samples that can be controlled from a data system or LIMS. IT projects can only go so far, it is the automation projects that fill in the gaps and create the fully automated environment.

To do this effectively, laboratory automation should be planned on a company-wide scale with an organisation and its own budgets. The usual approach within an organisation is for a cost centre code. One radical idea, in the current economic climate, would be to create a profit centre.

Once the automation group is established, it

Table 1 Future migration path for laboratory automation

requires a strategy [1,2]. From the automation strategy, a portfolio of automation projects is developed. The laboratory automation group would be actively involved in the prioritisation of projects and co-ordination of effort across the whole organisation to ensure no duplication of effort. This group would work alongside members from the functional areas seconded for the dura- tion of an individual project. This organisation will ensure that experience gained on one project is learnt and passed on to others.

The staff within this organisation should be working full time on automation projects. Labo- ratory automation staff usually come from the laboratory environment rather than from a pure IT one. The number of automation scientists within an organisation would usually be relatively small. Their numbers would be increased when necessary by full-time laboratory staff seconded to automation projects.

Automation scientists should act as facilitators and catalysts using both their laboratory experi- ence and automation skills. Within the global laboratory automation organisation there should be access to all the disciplines required such as electrical and mechanical engineering and com- munications, or the ability to access the appropri- ate functional departments for such expertise.

An important and vital aspect of automation projects is the interaction with management and the users. Project sponsorship is covered in the next section. As important is the interaction with users. Empathy with the users and the under- standing of their problems is an important per- ception that is essential for automation scientists to have. The ideal automation scientist would be an ex-user.

Factor Existing situation Future situation

Organisation Automation staff appraisal scheme Project sponsorship Project justification Project performance metrics Post implementation review

Local Non-existent Poor and sporadic Poor: buy and try Non-existent: no objective measures Non-existent, lessons learnt are lost or poorly communicated

Global Appraisal criteria related to project Active and consistent Professional: try and buy Defined before the project starts Formal report against performance metrics

R.D. McDowall /Laboratory Information Management 26 (1994) 37-42 41

4.2. Active project sponsorship

Management must be more proactive about supporting laboratory automation projects. It is vital for the success of any automation project that the sponsor actively supports and champions it. Many managers give only minimal support for automation projects and balk when pressured by more senior managers. Education is required to demonstrate that project sponsorship is not a mere token role.

The key responsibilities of a project sponsor include:

- Demonstrating full project commitment. This means not just mentioning it at the start of a project and forgetting it until it is implemented or failed but talking about it actively. This commit- ment must be both in public and private.

- Facilitate any change management required during the implementation of a project. This is linked to the point above. An active and commit- ted project sponsor not only helps the project at the boardroom or senior management meeting but also at the laboratory bench.

- Ensure there are no human or organisa- tional barriers to hinder the project and assist in resolving any budget problems.

The sponsor should also provide the authority to the project manager and automation team and then demonstrate it actively. The project sponsor is one of the main keys to a project’s success.

4.3. Project proposal and justification

Within the framework of an integrated labora- tory automation organisation, each project should be properly justified. Each project, from those essential to blue sky, should be defined and justi- fied professionally. This should include the aims of each section of work, the expected deliverables and the performance metrics (see later).

The emphasis of automation should be ‘try and buy’ rather than ‘buy and try’. There is an interesting cultural approach here. The American approach is to see a piece of equipment, buy it, experiment with it and then discard it if there is no benefit. In contrast, the European approach is to look carefully at the same equipment, haggle of the price, think for some time, buy it, carry out

the same experiments and then discard it if there is no benefit.

The better, and more professional, approach is to use a proof of concept or a pilot study with limited objectives to see if a system, application software or equipment can carry out core objec- tives and has the flexibility for expansion. This removes laboratory automation from the 1980s approach outlined above. Rather than try to achieve everything in one attempt, a project should be encouraged to attempt proof of con- cept or a pilot study to show the feasibility of the idea. Grandiose projects with unlimited resources will not be allowed, only carefully considered and researched projects will have any chance of being accepted.

4.4. Perfomtance metrics

The vast majority of automation projects do not set any performance metrics when they start. This is due, in part, to the fact that few if any performance metrics have been gathered in the areas where the project will be sited and also, in part, are considered alien to the scientific culture. The truth is that we have not needed to look at metrics in the past and we were not subject to the same stringent controls. This is changing - rapidly.

However, those projects that do set metrics tend to be very conservative, e.g., a gain of lo- 20% in overall efficiency. These days such a pay- back may not make a project cost effective. The problem is that we look mainly at automating the status quo and not to improving the operation of the whole process. We must be more adventurous and challenging in the targets we set for our automation projects.

Performance metrics allow the success of any project to be measured quantitatively. This can be balanced with an assessment of the risk of a project to obtain a risk-benefit.

4.5. Post-implementation review

Few automation projects are reviewed to see how effective they have been or if they have achieved their objectives. Therefore, six months after a project has been handed over to a func-

42 R.D. McDowall /Laboratory Information Management 26 (1994) 37-42

tional group, a post-implementation review should be carried out. This enables the project to be measured against the performance metrics de- cided at the conception. The review should con- firm that the benefits identified in the project proposal have been achieved, whether the project was under or over budget and what lessons have been learnt. The formal reporting of a post im- plementation review will allow an organisation to communicate the experiences throughout the lab- oratory automation community.

4.6. Appraisal schemes for automation scientists

There are a number of approaches that can be taken with appraisal schemes. There could be the linking of success with reward on a sliding scale: blue sky or feasibility projects should have little linkage as the risk of failure is high. However a mission critical project could have most of the reward linked directly to success.

Other factors to influence an appraisal scheme would be the achievement of the performance metrics by a project, the ability of a laboratory automation staff to influence their customers, response to changes in project plans.

5. Summary

This article is intended to stimulate debate about the future of laboratory automation. Specifically: How is it organised? What are its objectives? How should it run and measure proj- ects?

The key to success of any laboratory automa- tion project is successful management of the hu- man issues involved:

- Changing the ways of working of users who are reluctant to change or outright hostile to a project.

- Influencing the attitudes of managers who are not usually committed to automation.

- Ensuring the approach of automation scien- tists and the staffing of projects is organised professionally.

Perhaps the title of this article should have been “Do organisations deserve laboratory au- tomation?”

Acknowledgement

This paper was presented at the Third Inter- national Symposium on Automation, Robotics and Artificial Intelligence applied to Analytical Chemistry, San Diego, January 1994. The author thanks members of the audience for the ques- tions raised after presentation that have helped him improve this paper.

References

[l] R.D. McDowall, Strategic approaches to laboratory au- tomation, Chemometrics and Intelligent Laboratory Sys- tems: Laboratory Information Management, 17 (1992) 265 283.

[2] D. Mole, R.J. Mason and R.D. McDowall, The develop- ment of a strategy for the implementation of automation in a bioanalytical laboratory, Journal of Pharmaceutical and Biomedical Analysis, 11 (1992) 183-190.