There’s a blog post on SandHill.com about reducing the cost of SaaS implementations.

The first few paragraphs really hit home:

In the on-premise enterprise software world, I have seen many software implementations go awry despite ballooning implementation expenditures. Customers never see their ROI until many years into the implementation, by which time they are so deep into upgrades, manpower turnover, shrinking IT budgets, IT organizational fiefdom – you get the picture – that ROI is the last thing on their mind.

As the customer struggles, the software vendor bears very little risk. The company has pocketed the license dollars and issued the press release on the customer acquisition.

With SaaS, the tables are turned. The SaaS software vendors (to their own detriment) have perpetuated this notion that, with SaaS, implementation will be effortless. But as we all know, enterprise software implementation is much more than just installing the software. Vendors must work harder to reduce deployment cost and improve ROI for their customers. Here’s how.

There’s two components of SaaS – where the software runs, and how the client pays the vendor. In this post I’m going to focus on how the vendor gets paid because it forces some interesting changes in vendor behaviour.

A traditional software sale goes something like this:

  • The hero salesperson goes in, does a magnificent sales job convincing the client that the package is wonderful and the vendor is deeply committed to success.
  • Customer issues Purchase Order and our hero salesperson exits stage left, pocketing his commission as he goes.
  • The vendor’s implementation team are then left to fulfill the commitments the salesperson made, within the sometimes very considerable constraints of budget, time, and technical feasibility (constraints that seldom bother the salesperson!).
  • In most cases the implementation effort is a matter of containing the damage rather than achieving something positive, and is the principle reason why there’s so little trust between customers and vendors.

Meanwhile, the customer’s business has stumped up a large capital sum in the hope of achieving some return at some point in the future based on the salesperson’s promise. All the risk is on the customer’s side at this point, because they’ve got an awful lot more invested than the vendor.

If you think about it, this is nuts. The vendor is selling an intangible – there’s no justification for a large up-front capital sum except to fit into the vendor’s existing financial model and sales compensation plan. Why can’t the customer pay for value received as it’s received?

I suspect the current state of affairs is just a matter of tradition, software companies have until now been able to get away with it – they haven’t needed to wean themselves off the up-front capital sum. Now capital is much more constrained so things are changing and customers are expecting to pay as they receive value.

Aside from making the finances easier, what’s really interesting is that rental now means a shared risk between the customer and the vendor – if the customer doesn’t get a return they won’t renew. That makes for much more open and honest conversations, and importantly from the vendor’s side, there’s a lot more learning going on – you really do have their attention. Chances are the vendor will need to change internally to respond to the new demands of this “Shared risk” approach – although one might wonder why it took this long to start caring about the customer’s outcomes.

Amphora started offering rental-type pricing for PatentSafe from the start, and I’m sure it’s one of the reasons why our products are some of the easiest ELNs to get going with, and deliver ROI with reasonable certainty. In addition, we’re wired up internally to ensure we learn as much as possible – we have a board-level position of “Director of Customer Relations” and the salesforce report into her which means one person has control over the entire customer experience from first touch to ROI realisation.

I should say that not everyone takes the rental-style option – I guess probably 50% of our customers rent in some way or another, Vs outright purchase. Getting so much of our revenue this way really forces us to pay attention and ensure the customer gets the business benefits we sold them – because if they don’t they will cancel! Our contracts also have short notice periods which means we never take anyone for granted, a deliberate decision on our part – it means we catch problems early.

Some customers don’t like this partnership approach – they’d rather buy the software and take responsibility for ROI themselves, taking the view that they know their organisation better than we do. Which is perfectly fine – some customers are amazingly professional and we just watch in awe. Other customers sometimes need a little help :-)

I guess the point is traditional software pricing means that a successful project is mainly the customer’s problem. Rental/SaaS-style pricing means both parties interests are aligned.

From the vendor’s perspective this is hard work but it makes you a better company in the end – better products, better services, better (and more ethical) sales. Yes you lose the big upfront windfall of outright purchase, but if you aren’t needing to artificially inflate your short term earnings and can manage your business for the longer term, that’s not a problem.

Yet another way in which being privately held is an advantage, I guess!

 

I was talking with one of our marketing peeps today and it appears we’ve had a massive increase in the number of inbound enquirers in the past few weeks.

They can’t seem to discern a pattern – we don’t even know what prompts them to come to us. But there’s been a seriously noticeable jump, from many different countries, and varying industries. Interestingly we’d expect this time of year (holiday time) to be relatively quiet, and what with the “Current economic climate” we were expecting things to be even quieter.

Either someone somewhere in Amphora did some pretty clever marketing without knowing it (Gold Star, whoever you are!) or perhaps the ELN market has finally reached critical mass.

Interesting, very interesting….

(if you do decide to email in – we’d love to talk to you about how we might be able to help you – mind telling us why you decided to contact us? :-) )

 

On the (rather hard to get into) LinkedIn ELN group, there was a question about the use of Open Source components in commercial ELN products.

We use a lot of Open Source components in our products, and I know we’re not alone.

There are vendors who are very committed to a specific platform – Windows (and associated libraries, APIs etc.), Oracle, and so on. Those will almost certainly have some Open Source components in them, but not much.

There are other vendors – Amphora (my company) and Rescentris are two that I know of – who have built on top of an Open Source stack. We do have some proprietary components but where there’s an Open Source alternative we use that.

Why?

  • The Open Source stuff just works better (and you can fix it if it isn’t).
  • Support is better.
  • Licensing issues go away (of course you have to abide by the Open Source license, but that’s not a problem as long as you check everything before the developers start using it).
  • It is dramatically cheaper for our customers to deploy. No expensive additional Windows Server or Oracle licenses (unless you want to use those of course – we can support them if you prefer).
  • We have much more latitude in deployment options. We can bundle our product in a variety of ways and on different platforms, which we wouldn’t be able to do if we were locked to a specific commercial platform. You can get PatentSafe as everything from SaaS, to an embedded device, to a traditional “Install this on your own server” software product.

A few years ago we got raised eyebrows about our platform choices (“We will only consider applications written in .Net”) but that’s not been an issue for a long time. Everyone assumes that the components we’ve assembled into the solution will work and we’re responsible for the overall performance of that – what bits we’ve chosen seldom get discussed.

From what I can see, Open Source starts at the bottom of the stack – the OS, generally – and is gradually moving up (Database, Application Server, some applications). Every commercial vendor needs to keep an eye on what value they are bringing compared to what’s provided by the community.

As an aside, we don’t consider ourselves to be a “Software Vendor”. We solve a business problem and it just so happens we deliver our expertise as some software which implements a “best in class” process. But we don’t consider we’re charging for “software” – we get paid for our expertise and how we deploy that to help customers solve their problem.

What that means is that as the software environment changes (and quite probably Open Source gets further up the stack) that’s not something that threatens our identity. I know some vendors (particularly those locked to proprietary platforms) aren’t so lucky, and I wonder how they will fare as the Open Source community begins to provide more and more of the “ELN” system.

 

I’ve put my older ELN presentations up on SlideShare here for amusement.

They are on the Amphora web site but I think it is more useful to have them on SlideShare.

 

We’ve updated the PatentSafe Repository Checker script, and importantly released it under an Open Source license (the GPL) which means anyone can check the integrity of a PatentSafe repository.

The project is on GitHub – here’s the project’s GitHub page.

The checker script is a completely separate implementation of the signature and repository code, and is a useful way for anyone – Amphora customer or not – to check that things are OK with their data.

An important part of PatentSafe’s value is that it creates an open repository which you can read and take in to court without needing any additional software from Amphora. Everything is completely open as standard, no need for a complicated export step, or any software except a PDF reader, a text reader, and OpenSSL. The open release of the checker script is just part of this.

© 2011 elnblog.com Suffusion theme by Sayontan Sinha
Private