The lab, the LIMS and the enterprise

E L S E V I E R Laboratory Automation and Information Management 32 (1996) 63-69

Laboratory automation and information management

The lab, the LIMS and the enterprise 1

M i k e M u r p h y *

Sema Group, Norcli~'e House, Station Road, Wilmslow, Cheshire SK9 1 BU. United Kingdom

Received 24 September 1995: accepted 1 July 1996

Abstract

The traditional view of a LIMS has been that its purpose is to help the laboratory to manage its data; this despite the fact that the 'I ' in LIMS is supposed to stand for information. The natural consequence of this approach has been that many LIMS have been defined purely in terms of the internal workings of the laboratory. This approach not only misses a number of opportunities to make the laboratory serve the business better, but can do an active disservice to the wider enterprise by failing to ensure that the fight information is provided to the right customer at the fight time. This paper will consider how to place the laboratory in its proper business context, and thus to define the system for true business benefit and obtain a budget for the project which reflects its value to the enterprise.

Kew'ords: True business benefits of LIMS

1. Introduction

The main focus of this paper is not so much to describe how to specify and purchase a LIMS as to look at the way to get the best business benefit from it. In these days of commercial stringency it is increasingly necessary for laboratories to justify their existence, and the possibil i ty of outsourcing has to be admitted for laboratories which come to be seen as an overhead, howsoever necessary. Equally, the process of getting a budget for the purchase of a new system is getting more complicated as organisations are looking for better and better justifications for any investments in technology. The answers to all these problems lie in obtaining a proper understanding of

* Tel.: +44-1625-531531; fax: +44-1625-530911: e-mail: mike.murphy @ mail.sema.co.uk.

1 Presented at LIMS'95, 7-9 June 1995, Bonn, Germany.

how your laboratory interacts with its parent organisation, the business ~enefits which the organisation expects and the unex:~ected additional business benefits which the laborz:tory can deliver to enhance its position and prestige within the organisation.

The processes I will describe are a subset of the stages of a full proje~:t definition illustrated in Fig. 1. This paper concentrates on the business facing aspects of project defimtion of interest to the readers of this journal, leaving the more technical matters to one side.

2. Customer focus

Many people bel.:eve that the word customer is becoming over-used these days. People using the railways are no longer passengers but customers, even the delinquent .youth subjected to the supervi- sion of the probatioa service or its equivalent has

0925-5281/96/$15.00 Copyright © 1996 Elsevier Science All rights reserved. PH S 1 38 l- 14 1 X(96)00006-8

64 M. Murphy /Laboratory Automation and Information Management 32 (1996) 63-69

'1 Business related

0 Technical

Fig. 1. The process of project definition.

become a client - - which is pretty much the same thing. Nevertheless, the implication of service, the provision of what people actually want or need, is fundamental to the delivery of business benefit and thus to the perception of a laboratory's value and its LIMS' success.

So the start point on the road to a successful LIMS is not the internal requirements of the laboratory but the identification of the laboratory's business objectives in terms of the customer service it provides. Know your customers, find out what they want and take steps to ensure you can deliver it.

Knowing your customers is the first step in the review of business objectives (step 2 of project definition). The process is more than simply cata- loguing the people to whom you send results. I suggest that your actual customer base is signifi- cantly larger than that, and that it includes some of your customers' customers - - the people who ulti- mately receive the information which started out in your laboratory - - whose satisfaction is directly related to the quality of information you produce. Let me give a couple of examples.

In research and development a number of different types of laboratory contribute information into the development of a new product. In the pharmaceutical industry for example conventional analytical chemistry information is put alongside haematology, histopathology and a wide range of other information

in order to demonstrate the safety and efficacy of the new drug. The direct customer for any given result is normally the Director of the particular study under which the results are generated. The indirect customer is the regulatory affairs department responsible for preparing the license submission in which these results will appear, and more indirectly still the officers of the regulatory body which will decide whether or not to grant a license for the product. Clearly, the most important of these three is actually the most indirect, as the satisfaction of the regulator is potentially an issue of commercial survival for the laboratory and its parent company.

In the water supply industry a similar situation can be seen. The primary customer for water quality data is the operational manager responsible for the water or effluent treatment operation. There is a range of secondary customers however, including the various environmental authorities, the pressure groups who act as the conscience of the industry and individual members of the public who may be con- cerned about the colour and smell of water you are supplying to their houses or be affected by specific pollution incidents.

All these direct and indirect customers need to be considered when you set out to look at a LIMS which is to make a genuine contribution to the business it serves. Make a list of who they are, the list might turn out to be longer than you think.

M. Murphy/Laboratory Automation and Information Management 32 (1996) 63-69 65

3. Customer needs and wants

Customer requirements will vary greatly. The first thing to do is to find out what they are by surveying the people you have identified in the previous stage (step 4 of project definition). Clearly your ability to do this will vary with the closeness of the relation- ship between the laboratory and its customer; for example the water quality laboratory manager will not be able to question the population of the area he supplies. Nevertheless there should be people in your organisations who can represent the more remote customers, so talk to them instead.

Please remember in your discussions with your customers to encourage them to look into the future; if you base your plans on the maintenance of the status quo you will fail because your business and its information requirements are a moving target. Some examples of things to check for are:

• Does the business plan call for the building of a new plant? If so, is it a future source of work and customer for information?;

• are new products being planned or developed which will modify the laboratory's work, range of customers, etc.?;

• is there any intention to modify the quality system which the laboratory supports? How does this affect the information required from the laboratory?;

• can you expect any tightening of regulatory requirements affecting, for example, the precision to which results have to be reported?

The information you need to acquire is a list of all the needs and wants your customer base can come up with. The bulk of these needs will be expressed as a catalogue of information topics such as " w e need to know whether this batch is within specification". These requirements will be easy to obtain, and you can start the debate by preparing a list of the information you currently supply to your customers and asking them to validate it. Almost certainly their information needs will have changed, probably they will have grown, but there may also be items of information they no longer need. The deletions from the list may provide some savings which can be used to fund the new requirements, so they are well worth looking for. You also need to know as much as possible about volumes and frequencies, both current and projected, as these go a long way towards defin-

ing the capacity required of your new systems, and therefore the cost.

What you may be less likely to get without press- ing for it are the related requirements about the presentation of information. Are there particular formats of presentation required by regulators or other indirect customers? Is money being spent in translat- ing the information you provide into these formats (which could be saved by providing the material in that form in the first place)? There is the potential to make a contribution to overall business effectiveness here simply by smoothing the passage of the information from your laboratory to its final recipient, with all the related quality improvements that such a development normally brings with it.

The next component of your customers' requirements will be the timeliness of information. The best information is as good as useless if it is not available at the right time, so be sure you understand the timing requirements and the reasons for them. Once again, this information may not be offered, so make a point of asking. One possible vehicle for obtaining this information is to ask your customers to indicate their satisfaction with the service you are providing at present, and the ways in which it might be im- proved. Wherever possible try and determine both requirements and current satisfaction levels in quan- tifiable terms; this will provide a concrete scale against which the improvements delivered by the new system can be demonstrated. Such a scale can be a valuable management tool in its own right, considering both the laboratory systems and the overall performance of the operation.

Finally, and most difficulty, you need to know what the information is worth. All information costs money to generate, and should therefore be required to pay for itself. You need to understand the cost of certain information not being provided, so that you can weigh it against the cost of its production. Information that your customers are not prepared to pay for is probably only 'nice to have', and may therefore be struck from the list of requirements when the pressure starts to come onto the budget. The differentiation between mandatory and desirable requirements can be crucial to the commercial success of a project. It is important to recognise when requirements are being set which are unlikely to be met by commercially available software packages,

66 M. Murphy/Laboratory Automation and Information Management 32 (1996) 63-69

because the cost of additions can be greater than you might expect; I will return to this subject later in the paper. For the time being it is sufficient to point out that if any such requirements are genuinely mandatory the business reasons for them should be fully understood so that the necessary decisions can be taken during the budgeting and procurement processes.

4. Additional marketing

There is another point to consider before we leave your customers and pass on to the later stages of the project. Is there information which the laboratory generates, perhaps as a bi-product, which your customers might be able to use? Very often laboratories are asked to concentrate on the production of facts, while they may be perfectly capable of enhancing the value of those facts by informed interpretation. Is there a market for this in your organisation? If so this is another source of budgetary justification for the system, and a possible vehicle for promoting the laboratory within the organisation as a whole.

Always remember that considering these value- added services may identify additional potential customers, whose possible needs and desires should also be considered.

of you the next step is to consider whether your own organisation and processes are appropriate to the new situation (project definition step 7). If your existing laboratory does not make significant use of computers, and many still do not, you can anticipate substantial changes of organisation and productivity from the introduction of new systems, but in all cases there are a number of questions you should ask yourself (remembering at all times to quantify as far as possible):

• Are there economies of scale to be obtained from reducing the numbers of sites on which you operate?;

• are your processes susceptible to automation by the use of robots or sample processors, whether bench top or on an industrial scale [1]?;

• are you currently spending time, effort and risk transcribing data which could be acquired directly from the analytical instruments [2,3]?

Given the answers to these sorts of questions you can build a model of the organisation and the business processes you require to meet your customers' demands, and can start to form some estimate of the costs. You are also now in a position to identify it a high level the functional requirements of the LIMS that will best support you in your business.

5. Information suppliers

You have now identified a whole range of information outputs from the laboratory, and the value of each. It is important to remember that you cannot meet this demand unless you are provided with the basic material on which to work, which may make you a customer of a number of other parts of the business. The next step (project definition step 6) is to ensure that you understand what information you need to get, and from where, before you commit to supplying information derived from it. Consider your relationships with these suppliers of information so that you can identify the most cost effective methods of obtaining the information you require.

6. Organising yourself

Now that you know what is going to be expected

7. Plan for change

It is virtually certain that the exercise carried out to date will have started to change the organisation. Opportunities for greater efficiency and effectiveness will have been identified, and these will inevitably impact on people, the nature of their jobs and the way they do them. It is essential to treat these changes seriously and sensitively if they are to be implemented successfully, because skilled people are one of the laboratory's major assets. At this stage in the process it is generally sufficient to identify the change management issues that will have to be dealt with (step 9), and to make it clear to the people in the laboratory that the process of change is going to be handled properly. Planning for the management of change is a component of the overall project plan (step 11). Remember that change management is a specialist skill in which you may require some outside assistance.

M. Murphy~Laboratory Automation and Information Management 32 (1996) 63-69 67

8. Identify the costs

Given the information you have built up during the exercise to date there is only one significant item left, which is the cost of the LIMS itself. Naturally you will get this by approaching a range of suppliers and asking for budgetary estimates, but it is worth thinking about the information you provide them. If you simply ask for the cost of a list price system for a given number of users the answer you will get will not truly reflect the cost of the system you actually require, so give the vendors a reasonable idea of what you want. It is important that you express your requirements as far as possible in terms of required capabilities or problems to be solved, not as techni- cally expressed solutions. Clearly if you need to connect to an existing network that requirement must be defined in technical terms, but if you merely want to be able to define, for example, levels of access rights simply say so (rather than describing how it might be implemented). This will allow the vendor or integrator to make the best use of their offering to produce a cost effective result, and will also identify any custom features you might require. It is important to clearly differentiate between mandatory and desirable features of the proposed system, so that they can be separately costed. This will make it easier to decide what to include and what to leave out when you start to construct the business case.

The other important fact to provide the vendors is an estimate of the amount of data you expect to have to handle. How many samples, tests and results per annum? How long will results be kept available for enquiry on the system? Do you intend to keep copies of reports (e.g., certificates of analysis) on the system, and if so for how long? All these points are vital to the vendors' ability to accurately determine the amount of computer hardware you will require, which will be a substantial component of the system cost. Getting this calculation wrong will result in disappointment because the system will be unable to meet the demands placed upon it, either immediately or in the future, so remember to be forward looking in this as much as in the functional requirement.

Having got these costs, do not forget to factor in the costs of your own people's involvement in the project. Make sure you understand what the vendors are going to expect of you, and balance that against

the degree of involvement you want your people to have. Remember that even if the vendor is prepared to go into purdah for a period of time and come out with your ideal system (which I doubt), you will get a better result by ensuring that they work with representatives of your operation who actually understand the business requirement.

The costs of user training must also be borne in mind in these calculations. Generally speaking you will require two different levels of training: users and system managers. Training at both these levels will normally be available from the system vendors, but you may wish to have the training tailored to the ways in which you want to use the system. Clearly this will involve additional cost, but this is likely to pay for itself in a shorter work-up period before the system becomes fully effective. A commonly adopted strategy is to buy training from the vendors for system managers and a small number of key users, and then to have them prepare and deliver the training required by the rest of the laboratory staff. This reduces the capital cost of the project (training normally being included in the turn-key price for the system), but you should remember to include the cost of your peoples' time for both the receipt and delivery of training. It need hardly be said that such training is a worthwhile investment in its own right as it helps to reduce the work-up period already mentioned besides being an essential pre-requisite to the use of the system in any formally quality assured or regulated laboratory.

9. Build the business case

The likelihood is that the cost of providing all you have asked for will be greater than you expect. In my experience this is the norm. What a lot of people do at this point is to look for the solution which either has the lowest cost or the cost which most closely matches the estimated budget. Some eliminate the highest and lowest cost solutions immediately and (assuming that the other systems fall within their cost expectations) proceed to make a selection from the rest. Generally speaking this method of proceed- ing results in some measure of disappointment, which can cause the system, and consequently the laboratory, to be perceived as having in some sense failed.

68 M. Murphy/Laboratory Automation and Information Management 32 (1996) 63-69

What very few organisations try to is to determine the solution which provides the best value in terms of allowing you to meet the critical success factors identified for the laboratory and the system. My suggestion to you is that this is the right way to proceed if you are to achieve the best compromise between the expected and the actual costs. There are a number of ways in which you can do this:

(1) Strip out all the unimportant requirements (based on the determination of mandatory versus desirable carried out during your investigations) and determine the economic impact. Remember however that what appears unimportant to you may be some- body's pet idea, so for Heaven's sake consult before you take any irrevocable decisions.

(2) If that does not get you the answer you require, the next stage is to look again at the cost justification for some of the components. The cost of a given facility (if you can strip it out) should exceed the costs of not having it, which include all the costs of inefficiencies both inside the laboratory and amongst your customers.

(3) If the facilities you require will provide business benefit to your customers it is reasonable to ask them to bear some of the costs. This can cause accounting difficulties, but if you can present a good enough case at a high enough level these can normally be overcome.

(4) Look at the possibility of phasing the implementation. Are there logical subsets of the system which will deliver business benefits in their own right? If so it may be possible to phase the implementation in such a way that the return you get from the first phase helps to fund the second, and so on.

You may have to go around this cycle more than once in order to achieve a consensus, but it should result in your building a cost benefit case (project definition step 12) which will satisfy both your management and your customers. All that now re- mains is to present it properly (step 14).

10. The LIMS project

Once you have got the go-ahead to spend, or more accurately to invest, the necessary sum of money you have another series of stages to go through:

• formal procurement of the LIMS package and any associated consultancy and implementation services [4];

• the specification and /or prototyping of the appli- cation;

• the implementation of the system; • the installation and commissioning of the system

in the laboratory; • validation [5].

These subjects are outside the scope of this paper.

11. Post-implementation monitoring

The last point I would make is that it is no good setting such a project running and just sitting back to reap the benefits. I have already observed that change is the only certainty in business, and you will doubt- less have taken the point that this applies to your businesses and the drivers they place on your laboratories. It is essential therefore that you should continually monitor the performance of the system and the laboratory against the agreed business objectives, and indeed monitor the continuing validity of the objectives themselves. In doing this you will manage your situation proactively, preventing problems from arising by seeing them coming before they arrive. As Simon and Garfunkel once said "try to keep the customer satisfied"; if you do you will retain the respect of your colleagues and the grateful attentions (in the form of monthly salary cheques) of your employers.

12. Summary

Let me sum up the main points: (1) Your laboratory is in business to serve cus-

tomers - - and be in no doubt that it is in business. (2) The success of your laboratory, and of your

LIMS, will be judged against the service you give to those customers, and this judgement will determine what budget (if any) you get for a new LIMS.

(3) In order to serve your customers you need to understand their wants, their desires and the value of those wants and desires.

(4) Knowing what you have to deliver you can organise yourself, and define your LIMS requirement, to achieve it.

M. Murphy / Laboratory Automation and Information Management 32 (1996) 63-69 69

(5) Having got yourself in a position to supply your current customers with what they need and can afford, continually monitor your success in deliver- ing a high level of customer satisfaction, and take steps to keep the customers satisfied before they realise they are not.

References

[1] B. Law, Robotics: Capabilities, Potential and Problems (Pharmanalysis Europe, Edinburgh, 1993).

[2] M. Murphy, Integration of Laboratory Computer Systems in the Commercial Environment, Data Handling, Automation, Regulation and Technology Conf. (DART '94), Amsterdam (1994).

[3] R.D. McDowall, Data Integrity from Sample Preparation to Final Report (Pharmanalysis Europe, Edinburgh, 1993).

[4] L.A. Broad et al., Selection of LIMS for a Pharmaceutical Research and Development Laboratory - A Case Study (Sci- entific Computing and Automation, Maastricht, 1990).

[5] M. Murphy, Validation and Certification: Commercial and Regulatory Aspects (Scientific Computing and Automation, Maastricht, 1990).

Documents

The lab, the LIMS and the enterprise