Over at The Integrated Lab, John Trigg looks at the ELN Vs LIMS issue which has come around again as more traditional “LIMS” vendors introduce “ELN” products targeted at their traditional QA/QC customer base. He says:
But perhaps the real issue here is our application-centric view of laboratory systems
Which I very much agree with. So many projects start out not looking at their problem but instead “What ELN should we buy?”. When the terms we use such as “Electronic Laboratory Notebook” and even “Laboratory Information System” cover such a wide spectrum of potential functionality, starting out that way without being clear about what you are trying to achieve is a recipe for failure.
When we meet people for the first time we always ask “Why did you make time to see us?”, and hopefully they tell us the business problem they are trying to solve. If they answer “Because we’re looking for an Electronic Laboratory Notebook and you are an ELN vendor, show us what you do”, we find ourselves asking questions like “Why do you want one?” and “What do you think one will do for you?” which helps us to get to the root of the issue.
You’d be surprised how many people who tell us they want an ELN (and are quite certain about that!) but in fact have a problem that doesn’t need one – they might just need to use their existing software in a different way, or buy something like an SDMS or a LIMS.
I know that the traditional sales school says you should immediately “re-engineer” the prospect’s “vision” to suit the features of your product, but in my experience that rarely leads to a happy outcome even if you do manage to make the initial sale. If the end users didn’t need one, then just because the organization went out and bought one, and the vendor’s salesperson convinced them to buy his (plus the consulting time to aid with the inevitable painful implementation) it doesn’t mean the project is going to be a success in terms of achieving a Return On Investment.
From my perspective (as a technology implementor, not a salesperson), the sales process is where a potential customer and a potential vendor communicate and establish if what the vendor has to sell is going to solve the business problem the potential customer is prepared to spend money to solve. That often involves clarifying what the real problem is, before we get into solutions.
From the vendor side that means being willing to say “That’s not us, why don’t you go talk to these guys”, and from the customer side that means talking to us about the business problem you need solve, not what application you think you want to buy.
Once we understand a business problem, then if appropriate we can show how our ELN might be able to solve it. But not before. This sometimes upsets people who want us to just come in and demo, but surely the idea of the sales meeting is to have a productive outcome, and requires communication? Which is why we like to ask as many questions of prospective customers as they might ask of us, as strange as people find that.
I’d rather have a meeting where after 10 minutes we mutually come to the conclusion that there isn’t a fit, than labor with on each side pretending there at some point might be a happy outcome. If we communicate well at the first meeting, it means if things do go forward there’s a high probability of success all round.
(This approach of finding out people’s business problem and telling them if we aren’t a good fit did cause problems with our sales team until we changed their focus and compensation to be biased towards “happy customers” rather than just “make sales”. A small but important tweak which really helped the quality of the business, but still raises eyebrows when we recruit new salespeople.)
