But getting back to the point, locating computers in the laboratory is not new; we’ve been doing it for 40 years or so, and its getting easier. Flat screens, mounted on telescopic arms, membrane keyboards, on slide-away trays, and use of KVM devices to switch the desk-bound processor between use at the desk or in the lab, have all helped. Of course this doesn’t overcome the basic mobility of a paper notebook, and it remains to be seen whether mobile electronic devices will have any impact on laboratory work. Already there are ELNs that are iPad-ready; there’s a major LIMS vendor that has been advertising for some while, a LIMS running on an iPhone. It is possible that these mobile devices may offer the possibility of capturing data, notes and ideas that can be synced back to a laboratory system so that the chore of sitting down and fully documenting an experiment can be conducted in an office environment.

But what if…..we were to use multimedia, rather than just text and images, to record experiments, or if the laboratory became a ‘Minority Report’ example of ubiquitous computing???? It may be some way away, but I suspect its not the ELN that is doomed.

The other news item appeared on the BBC website: ‘MI5 staff who lack computer skills made redundant’. (MI5 is the UK counter-intelligence service). In a round of compulsory and voluntary redundancies, MI5 staff lacking IT skills are being told that they are not wanted. Counter-terrorism is increasingly dependent on technology and officers have to adapt to keep up and to be completely comfortable using computers and the latest technology. This would never happen in a laboratory, would it?

The course presented at SmartLabs Exchange outlined a systemic approach to automation, tracing its evolution from the days when quantitative chromatography was based on cutting out peaks and weighing them, to current requirements for integrating disparate laboratory instruments, systems and robotics into a unified laboratory ‘solution’. Considerable emphasis was placed on process and workflow understanding, the choice of technology infrastructure and the role that systems such as LIMS and ELNs can play in facilitating integration. From a manager’s perspective, the introduction of laboratory automation is equivalent to introducing a small scale ‘scientific manufacturing’ operation and therefore warrants appropriate policies and practices. Good planning plays a critical role in the deployment of laboratory automation, based on well-defined goals and business justification.

The course provided an excellent overview of strategic approach to laboratory automation. Full details of the public course schedule offered by the Institute for Laboratory Automation can be found here.

I can well remember witnessing projects where (a) the objective was to faithfully reproduce a paper process on a computer, and (b) there was no give and take over a specific requirement. In the first case, the project was a total failure; it reproduced fundamental flaws in the paper process and never took advantage of the capabilities of the technology. In the second case, the only way out was some very clunky customisation that was unable to survive the next software release. Clearly there are some things that we as human beings are very good at, and there are other things that computers are very good at. There’s still a way to go before these qualities are fully merged, so the more we can do to adapt to the logical capabilities of a system, rather than expect the system to adapt to our occasional illogical capabilities, the more likely we are to find a successful solution. Now that’s not to say we just give in to whatever is presented to us in the way of a computerised system, but we do need to be confident that we have a robust and logical process that we can apply the technology to.

In terms of a collaborative approach with vendors over RFPs, the issue may bear resemblance to Game Theory and the Prisoner’s Dilemma. The basic scenario is competitive, from a financial perspective, and communication, is to some extent, driven by the passing of a document (RFP) between the two parties. In this context, achieving a win-win isn’t going to be easy.

Unfortunately the RFP process is never going to be completely open and collaborative, but that’s not to say that it cannot get better. Like many aspects of business life, standardisation, and a one-size-fits-all approach tend to eliminate the flexibility that is needed to drive good outcomes.

There were a couple of points that did arise in the formal programme that are worth recording. The legal implications of ELNs has been a feature of ELN conferences since they first started. Generally the theme of the presentations has been the reassurance to potential purchasers of ELN systems that electronic records are acceptable in patent litigation and interference cases. There were two presentations in the SMi conference relating to legal issues of ELNs, firstly by Colin Sandercock and then by Matthew Dick (Bristows). Colin’s presentation focused primarily on the situation in the US, whereas Matthew gave an overview of the UK situation, plus some insights into the broader European situation. Surprisingly, there is no harmonization regarding discovery/disclosure relating to electronic records across the European Union.

The most significant message that came from the two presentations was a subtle change of emphasis from ‘it’s perfectly OK to use electronic records in court’ to ‘there are some distinct benefits to using electronic records’. The benefits accrue mainly with the enhanced speed and accuracy of searching electronic records. Since the number of records presented in the discovery phase can be significant, computerised search tools can significantly shorten the time to extract relevant data, and hence reduce costs.

The other presentation that was of particular interest was by Jo Mulgrew of Pfizer. Jo gave a detailed description of the support structure that Pfizer have put in place for a range of laboratory applications. The support system is based on ‘compliance’ of user adoption and uses a range of ‘Enterprise 2.0’ tools during and after implementation to optimise roll out and the on-going user experience of the application. I’m hoping, in due course, to post more details of Pfizer’s approach to in-house support as it seems to represent a benchmark and may offer some best practice ideas to other organisations.

Within the context of laboratory data and information management, raw data tends to draw out some interesting debate along the lines of what constitutes raw data, how and where do we store it, and for how long?

Those of us involved in the business of laboratory systems and laboratory integration can be kept pretty busy with the technological challenges of acquiring, managing and storing ever increasing volumes of raw data, but behind these challenges are some more fundamental questions that need to be answered before we can even start thinking about a solution.

So, if we assume that we know what the raw data is, the decision about how long we keep it is influenced by three different considerations.

Firstly, scientists are often hoarders of data and like to hang on to raw data as basic scientific evidence, for reference purposes,  or for re-assessment in the light of future scientific or technological advances. This requirement has no definable timeframe.

Secondly, there is an ethical position, largely determined by regulatory bodies, to allow for the re-examination of data in the light of the consequences of unforeseen defects, failures or adverse effects of products or processes.  This timeframe may be determined by, or related to the lifetime of the product or process.

Thirdly, there is a business requirement to address IP protection in terms of the underlying value of the data to the business.  This may have a long timeframe if it is relevant to a patent, but could in other circumstances have a relatively short timeframe.

Making the decision on what to store and for how long has its complexities, but the combination of regulatory and legal guidance, business best practice, good technology and hopefully, common sense, is helping shape a way forward.  However, it is always good to remember that the scientific knowledge food-chain starts with the raw data, and an item by Derek Lowe (Data, Raw and Otherwise), loosely connected to ‘Climategate’ on In the Pipeline serves as a good reminder of the importance of raw data from the scientist’s perspective.

The programme served to highlight the difference between the perspective of business success and user acceptance. Its difficult to argue against the fact that RyanAir are a successful business, but at what cost?

So when it comes to informatics projects, how do we measure success? There are three phases in an implementation that may have different measures. In the short term, completing the implementation on time, on budget and in full (all deliverables) represents the conclusion of a successful project. In the mid term, the return on investment becomes a success criterion; how soon can we claim that the upfront costs have been recovered through some form of increased productivity. But in the long term, the metrics become more fuzzy. Most informatics projects will have a knowledge management component that targets sharing, collaboration and IP protection that lead to some discernible improvement in the way the business operates. These three phases roughly align to the three basic criteria of cost, time and quality, the emphasis in the first phase being on time and project costs, in the second phase on ROI (costs) and in the third phase on quality. So in the Ryanair example, the difference of opinion centres around ‘quality’, a discussion that seems sadly out of date since ‘fit for purpose’ is a modern acceptable catch-all definition for quality, and that having the latest and greatest doesn’t automatically correspond to a quality solution.

This argument tends to reinforce the fact that user acceptance is the most critical long term success factor for any informatics project, and as a consequence, identifies where a lot of effort needs to be made in project planning. This means keeping careful control of user requirements, keeping users involved throughout implementation, and recognising and supporting the full spectrum of users.

This was the basis of a presentation I gave at the 5th Forum on Laboratory Informatics, San Francisco, Oct 26-28th. The presentation is available here.

Now, knowledge management (KM) is a scary topic, open to abuse and exploitation by unscrupulous vendors and consultants. The principles of KM all make good sense; it’s just that an ‘industry’ seems to have grown around the topic that sees it as a potential revenue stream. I’ve spent some time working in KM teams and with KM initiatives in my corporate career, and the conclusions that I came to were:

• KM solutions do not come in a shrink wrap box
• You cannot implement KM, it is an outcome
• KM is about people; technology can facilitate good KM, but that’s all

Basically, Information Technology is a big part of the problem, but a small part of the solution.

By complete chance I came across an article written by Elisabeth Goodman, about a company (Deep Visuals Ltd) being run by an ex-colleague of mine, Alan Payne. The article touches briefly on some of the KM outcomes from the enterprise-wide ELN implementation from our Kodak days and was a good reminder that despite the up-front concerns about the investment, longer term benefits accrue from (a) sharing and making information accessible, (b) ensuring that systems are easy to use, and (c) evolving a culture based on collaboration.

Reading Elisabeth’s article caused me to check her blog, and I found a number of interesting posts that may be of interest to visitors to this site – you’ll find a link in the Blogroll in the left-hand sidebar. The item that really caught my eye was There’s more to decision making than meets the eye or.. why we shouldn’t dismiss gut feelings. Serendipity has always had a significant role in science; so many of the major scientific breakthroughs and advances originate from chance observations and things that went wrong. We often learn more from failure than success! You can’t help but wonder where we would be if Lean and Six Sigma had come along a couple of centuries earlier. That’s not to say that Lean and Six Sigma don’t have a place in science, but I side with Elisabeth in her conclusion that we need to keep some reasonable space for right brain thinking alongside the systematic and structured approaches that strive to attain increased efficiency and productivity.

As a footnote, I’ve just finished reading a novel, The Invention of Everything Else by Samantha Hunt. It is an entertaining literary mystery based on the life of Nikola Tesla, an outstanding but somewhat neglected 20th century inventor. Pure right brain!

A lesson I learned very early in my career was that you just do not computerise a manual process. A whole department in which I worked fell victim to a misguided and misdirected effort to replace a paper-based sample logging system with a computerised version. The new system replicated the paper process, with all of its limitations; same workflow, same forms. There was no pretence at designing anything; the outcome was a system that users hated; offered nothing new or better, and caused three or four years of mayhem.

I’ve recently experienced the other extreme, switching from a windows-based smart phone to an iPhone. Now, the iPhone does hardly anything that the Windows phone couldn’t, but it’s the way it does it that makes the difference – a classic case of good design maximising usability.

So, how good is laboratory software design, and what would be a good indicator of good design? I can’t help feeling that the ultimate indicator would be no need for a user manual or a training course. Unlikely I know, but we can dream!

I don’t know what effort laboratory software vendors put into design and usability – it would be great to hear from them – but usability, and hence user acceptance, is always a criterion that is held up as a measure of a project’s success. But sometimes it just seems that user acceptance is an outcome of the training program.

Update: Some of you have had problems viewing the file.  With the author’s permission, I am posting a PDF version of the article.

Oh, well I suppose I should expand on this further. We have terms such as COTS (Commercial Off-The-Shelf) as a response to things like GAMP (Good Automated Manufacturing Practice):

http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview

Is “COTS” Confusing?

Here’s what I see that continues to happen: we come out with a set of guidelines that imposes or suggest certain terminology and, if it sounds like an appealing thing to achieve, everyone wants to call themselves by that term. One such term is COTS. I had started an academic discussion of the “true” meaning of this term in my LIMS/Laboratory Informatics group in LinkedIn and found some good academic responses to the term:

http://www.linkedin.com/groupRegistration?gid=36640

However, I realize that there is a different dynamic of understanding during the sales process of these systems.

Now, it could be that there are circumstances where the terms do apply. It could be that end-customers expect too much from these systems. Regardless of the intentions of what COTS should have meant, there is an expectation from many customers that they will purchase these systems, have a small implementation to “configure” them and an equally small series of validation scripts and will be up-and-running. The truth is that, with many of these systems, the projects are more extensive than this.

Why Do We Care What “COTS” Means?

The reason this is important for customers to understand is that it will affect the budget you need to allocate, as well as the types of people to allocate. Many of these projects require a true project manager and people with experience in delivering software specifically for these exceptions-based systems, as opposed to those with specific experience in “from scratch” software delivery. Using people that only know how to install systems is not sufficient, either.

As such, the people buying new systems have to be made aware of the fact that they will not know what level of effort to allocate to these projects without doing an in-depth study of their requirements and comparing it to these systems, especially if their installation will be a large one.

And, they cannot rely on those of us that are selling them the software or the services to do it for them, unless they specifically bring in a person just for that purpose. The reason is that each person involved will be true to our own mission, regardless how “honest” each claims to be and will do so as a practical matter, to some extent. If that mission is to sell the software, that is primarily what you must expect that person to do – not to make an unbiased evaluation of your project situation. As such, I truly believe that each customer must become a savvy buyer just as they would if they were buying an automobile.