John Trigg kicked off an interesting exchange on The Integrated Lab about community participation, especially by vendors etc.

I think there’s multiple issues here, more than would fit in a comment to the original post, hence this one.

The good news is there are examples of how healthy communities can arise, the bad news is the ELN market isn’t there just yet. There’s still a lot of old-school thinking around about how a market should communicate, especially by vendors (Wolfgang and I are the only ELN implementors actively blogging for example).

My view, formed both as a result of my own experience as a “customer” and by books like The Cluetrain Manifesto, is that markets are conversations. This is especially the case in new markets, where none of us know what we’re doing, and the only distinction between “Vendors” and “Customers” is that the vendors are trying to generate enough marketing fluff to hide from the users that they’re making it up too!

I guess there’s at least three levels of conversation/interaction that need to happen in a market:

  1. We need to figure out the problem and how to solve it in general terms. This is market formation stuff.
  2. Customers need help getting from “I think I might have a problem” to “This is the kind of solution I am looking for”. This is the start of “Curious Buyer”.
  3. Once the prospective customer has some idea what they are looking for they then need to decide which is the “best” vendor.

Each of these deserve a post on their own, but for the sake of brevity some quick thoughts…

The Market Formation Conversation

CENSA was a really good place for the Industry to figure out what the problem was, although it’s usefulness declined once the industry got to a size where the vendors hired marketing people and sent them rather than their CTOs or founders. We still need something like that because we’re still not where we need to be in terms of really understanding the “map” of the space we call “ELN”. There’s too much confusion even in the use of basic terms, and when that’s combined with sales & marketing efforts a lot of projects just start out doomed from the start.

Personally, I’d love to see all the vendors and consultants running their own blogs, blogs written by people who are responsible for actually helping customers, writing about their daily experiences. I know a lot of people are constrained in their messaging, but I don’t think that’s going to work much longer so Sales & Marketing may as well get used to it.

I’d also love to see people with an ELN blog their experiences. Again, this is hard to do but I’d love to see even anonymous blogging (although how do you know it’s not a vendor… this has happened in other industries, sadly). The academics are starting to blog though, and that could well be our salvation – although the needs of Industry and Academia are somewhat different, so the conversation is going to get a little skewed.

Helping the Curious Buyer

In terms of helping a curious buyer, typically that’s a role a consultative-based sales person would do. If done well (and by well I mean ethically) this is often an excellent way for a buyer to quickly understand their problem and how it might get solved. This is why at Amphora we have a very “soft” sales approach, tend to hire people with more of a consulting background than sales, and have a compensation system which focuses on long term customer success not “get the sale in”.

However, not all vendors work in that way – some can’t (because of their company structure) and some just lack the vision. So buyers don’t trust any “Vendor”. Which is why the Industry needs ways of helping Curious Buyers move forward, and sites like The Integrated Lab are a good starting point for this.

Some people view analyst reports as a possible way out for a Curious Buyer – “If I buy this report it will tell me what to do”. Unfortunately this rarely works even in mature industries because of the inherent conflicts such analysts encounter – you’re generally reading something that’s heavily vendor influenced.

I know that our interactions with Analysts hasn’t been good – a “review” of our product appeared based on not actually seeing our product, our market positioning is totally misrepresented, and even the basic analysis is wrong – we weren’t even given the courtesy of being able to respond. Not going there again.

Having said that I do quite like the guys from RedMonk who have an “Open Source” approach to Analysis. Here’s the first couple of paragraphs of their web site:

RedMonk is the first analyst firm built on open source. We’re dedicated to providing high quality research at no cost, and believe that the dialog that follows is beneficial to us, our community and our clients.

William Gibson once said that “the future is already here, it’s just unevenly distributed,” and we concur. RedMonk analysts spend their days learning from the communities that are defining the future of technology, distilling our findings into free research, and working with clients to explain the likely impact.

Bit of a contrast from the traditional “Buy our badly researched and very expensive report, and oh by the way we do consulting so you can CYA even more” analyst!

Right now our solution to this phase is a very soft, consulting-centric sales approach. It is expensive (for us) but it does work. We also do lots of conference talks and articles where we concentrate mainly on industry issues and our experiences, rather than product pitches or “real user case study” type stuff. Our hope is that if you like our approach, find what we say interesting, then you’ll come and talk further.

Picking the right product

Once our Curious Buyer has a good idea of what they want to do, it’s time to pick the vendor. I think this is the easiest bit right now, because the vendors are sufficiently differentiated that once you understand the problem you quickly end up with one or two candidate vendors – so get them in and have a chat with them, and then take up references.

I’m not sure product reviews will help right now. It will be too hard to do an “Apple to Apples” comparison, and without a decent map of the market it will add more confusion than enlightenment for a Curious Buyer.

This is also my concern about case studies right now – rarely are they positioned in a way that allows the audience to understand how their specific needs relate to the needs of the subject of the case study. So you get someone walking out of a case study believing they’ve just heard that it’s perfectly possible to use one ELN throughout your organisation – which is perfectly true but only if you all do the same kind of science!

Summary

I must admit I don’t know the solution to all of this. I know we have a big problem, and I know the first step is to start the conversation – which is why I started this blog.

 

Wolfgang Rumpf of Recentris has started blogging. Recentris and Amphora have some customers in common (their ELN works really well with PatentSafe) and we often recommend them for Biologists with data-centric pain. Quality guys, with a lot of expertise, and it is good to see them joining the conversation.

 
This entry is part of a series, ELNs and the Credit Crunch»

Using the two models to split the ELN problem up into different areas and data types, project teams can clearly see the different parts of the problem they face and how to tackle each one.

In cases where the demand for an ELN originates from Medicinal Chemists then clearly an ELN from one of the many vendors in this space will service that need, and as this is a relatively mature area of the industry a solution can be purchased in the traditional manner. However, teams should resist the vendor’s encouragement to view all scientists alike as non-chemists are unlikely to be well served by something that is primarily focused on Medicinal Chemists.

For Biology and other areas which don’t draw chemical structures, the demand for an “ELN” is often an expression of frustration by the scientists that they are using computers in their work, but are still forced to use a paper notebook. In that case, their needs may well be met by something that focused on the record keeping functions which are currently being performed by the paper notebook – an aspect rather inelegantly referred to as Patent Evidence Creation & Preservation (PECP). The scientists will rarely require any additional software but if they do it will be focused on particular niches – data management, additional workflow support etc. which will either be very specific or could easily be met with common software they probably already have as part of their standard desktop.

Most R&D organisations would feel a sense of discomfort if the possibility of “Silos” of information were to appear. Fortunately, PECP systems are by definition generally applicable and they can form the central repository of the organisation’s knowledge, available to all. A common PECP usefully reduces legal risk by ensuring common practices across the company, whilst freeing scientists to select their tools of choice without having to compromise as a result of legal considerations.

We need to stop thinking of an ELN as a single product, and more a system of parts integrated together. Some might fear the I (“integration”) word, but with today’s tools and sensible interfaces, it really isn’t a big deal. You can argue that cut & paste, or printing, are perfectly sensible integration mechanisms. I’m no fan of Microsoft, but when everything is on a common platform the only integration pain tends to be vendor pain/stubborness – and in today’s world Cash is King!

By focusing on what’s needed and building on existing investments, whilst avoiding the temptation of scope creep, project teams can give their scientists a replacement for the paper notebook for typically a tenth of the price, deployed in a matter of weeks. Always a proven approach, in today’s more austere environment the more realistic approach of ELN 2.0 might not be as exciting and produce as much consulting revenue, but it is the way to deliver real value, today.

 
This entry is part of a series, ELNs and the Credit Crunch»

Not all of the “Stuff” sloshing around the lab is the same, and distinguishing between them helps tease out the best place to store things. We use a simple Triangle Diagram (originally proposed by John Trigg of PhaseFour which really just tries to point out that stuff is related, but it’s at different levels of abstraction:

51DC4C72-5A54-4E90-B9D7-BA9AA67F3E31.jpg

It is quite hard to draw definite lines around things, but I think most people can appreciate that a raw data dump from an instrument is somewhat different from a report to management, or that an experimental write up in word is different from some tabular data in a spreadsheet. The differences between the levels come out in:

  • The software that’s used to read the file and interpret the content. Some will require very specific software (e.g. from an instrument vendor), but a PDF or text file can be read by many different things.
  • Who might be interested in the data. Again, some files are useful to anyone (for example, a report) but some only useful to certain people with specific training.
  • How long your company might want to keep the data, and indeed how long you are realistically able to keep the data. Typically the lower you go, the harder it is to keep something, so if you feel it’s business critical you really need to pay attention to the formats used.

This differentiation can really help in ELN System design. Partly it draws your attention to what needs to be stored in the ELN (typically the “Experiment” write up level), and what can be left in systems e.g. a database or a file server, which can be pointed to from the ELN.

Not everything needs to be stored in the ELN, and indeed it would be unrealistic to expect to be able to do so. The important thing is common keys so you can offer the user a link to more information, and the advent of web-based systems has made this level of “integration” so trivial one sometimes feels a bit of fraud describing it as such.

By building on the storage tools you have in place, and focusing an ELN on Experiments, the resulting system is cheap to run, costs little to acquire, and results in little disruption to existing practices.

You can read the final part of this series here.

 
This entry is part of a series, ELNs and the Credit Crunch»

Most R&D organisations have more than one scientific discipline under their aegis. These groups will have developed their own suites of IT tools to help them do their work, everything from common desktop infrastructure to instruments and specialist tools. Some of these might be common to other groups, some will be very specific (and often unknown to anyone else). Meanwhile, the corporate-centric record keeping functions have remained in the commonly used Paper Lab Notebook.

B05B10C3-C321-40E5-BAB8-1412EFDE9143.jpg
“Broad” and “Deep” functions

The “ELN” question often arises when companies buy more and more IT to support the science, yet the only record keeping option is the paper notebook – a situation that generally arises because of the patent/legal issues around lab work in Discovery. Broadly, the the more computers you use, the more the paper notebook sucks – and to add insult to injury whilst you can search the entire planet using Google, the paper notebook is very much a “Write only” device!

The challenge for project teams is how to replace the paper notebook, and this is where splitting out what you mean really helps. Unfortunately most vendors have tried to expand the definition of “ELN” as far as possible which turns any project into a high-risk “do it all” venture, with an associated price tag.

By focusing on either the improvement of support for a particular niche or on replacing the paper notebook’s general record keeping process, projects can easily build on what’s already in place and achieve faster, more predictable ROI. Later projects run according to the same framework will by definition build on what’s already in place so there should be little scope for missed opportunities.

Vendor-driven approaches to use a single product for more than one area bring increased risk and often the promised cost savings are overwhelmed by the costs of replacing perfectly serviceable existing tools.

The next post examines what is stored in ELN systems, which is another useful way of looking at the ELN problem.

© 2011 elnblog.com Suffusion theme by Sayontan Sinha