Friday, December 24, 2010

Automating SaaS Operations

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency" - Bill Gates

This is an article which I posted at the Nolio blog site as a guest blogger back in 2009. Not only is is relevant today, but perhaps even more so...

The Next Killer App
If I had a great idea for the next killer app (I have, actually) and if I had unlimited funds (I don’t, actually) I would have built the software as an on-demand offering.

I would have spent half my funds on building the operational support systems – provisioning, billing, retention policy, self-service, report generator, etc. The other half would be invested in building instrumentation, redundancy, automation, integration, application level monitoring, silent upgrades, customer notifications, and so on.

The rest of the money (you may wonder about my math, but hey, I’ve got unlimited funds) would go towards building the actual application.

Most SaaS vendors out there (and they are growing fast) have chosen the predictable path of building the application first, and worrying about serviceability later. This is the fastest way of getting to market with low costs. The next step is choosing some viable hosting solution and off we go, offering the world our ever better CRM.

Growth
Many months and dozens of customers later, reality hits with all the issues of servicing the software, rapid growth and dealing with labor intensive tasks that are the humdrum of daily life in a SaaS operation. Provisioning/de-provisioning, configuration changes, customized reports, and the most dreaded – upgrades, task the team as a whole, especially when the product is successful and the number of customers is growing daily.

It is not that SaaS executives, architects and engineers are lacking in any way. On the contrary, they are mostly smart, inventive, and creative and have a deep understanding of their customers’ needs in the specific domain. The problem is that they are product people, not service people. Practically none of them come from IT and cannot envision the life of a service operations engineer.

At this point, automation becomes crucial to the survival of the business.

Whether it is built into the next version (many architectures make this quite difficult) or done externally, automation is needed to reduce costs, physical labor, frustration and mainly, error-prone manual procedures. Repeatability, which is a derivative of automation, is also crucial.

Automation is needed across the board. Be it in setting up a new server, or building a new application instance. It could be a manual procedure regarding provisioning of application resources, or building a seamless upgrade procedure.

Outages happen. How quickly can you recover from a service disruption and ensure that the recovery does not create it own problems? Automation not only provides the routines for quick recovery, but instills a discipline of thinking out the necessary steps, discovering dependencies and planning ahead. An added benefit of automation is that it documents the process so you can go back and review the best and worst of your procedures.

In my next post I will take a closer look at the SaaS Upgrade Nightmare.

Thursday, December 16, 2010

2 x E-cube = S-cube - Simple math for SaaS Scalability Success

"The circumstances of human society are too complicated to be submitted to the rigor of mathematical calculation" (Marquis De Custine)


Recently I posted a discussion on the link between success with SaaS and scalability and how, therefore, the Service Operations needs to be geared to handle scale and deal with fast growth.

On a recent consultation engagement, I gave a presentation to the board members of a SaaS company that decided to penetrate the SMB, following their hardships in securing big deals in the enterprise market.
As part of the thought process and brainstorming session I came up with a marketing catchphrase to make a point. At the time I did not think much about it, but as I was working on the board presentation, I realized that there it was much deeper than I had originally thought.
I would like to share this with you.

The First Cube
What I drew on the white-board was roughly this artistic creation:







Announcing: “E-cube is the winning formula!”
  • Easy to Buy
  • Easy to Implement
  • Easy to Use

Easy to Buy - Their product is very easy to implement, and easy to on-board a new organization, (although it is a complex product). There is a technical issue that involves an architectural change, so that became part of the plan.

Easy to Use - the product has a great user interface and intuitive flow. They need to add tutorial videos.

Easy to Buy – That was lacking and that was what we decided to focus our efforts on. It included a lead generation program, a no-touch free trial and an improved landing site.

The Second Cube
As I was working on what it would take from the company’s end to deliver scalability, I realized there was another E-cube involved:
  • Easy to Sell
  • Easy to Scale
  • Easy to Maintain
It is all nice and well if you can bring thousands of leads to your site with the E-cube formula, but if you cannot convert these leads into paying customers and then give them the best service on a controlled budget, you will have not achieved your scalability goals.

So, Easy to Sell means - a simple pricing model and a top-notch insides-sales team (not easy to come by though) backed up by funnel management software. 

Easy to Scale means - a solid, configurable, multi-tenant architecture, self service features and automated procedures.

Easy to Maintain means – a full featured Operations Support System, Service Operations practices and the discipline to enforce them.

So with two E-cube guidelines one can achieve SaaS Scalability Success.

Ergo: 2 x E3 = S3

Q.E.D.

Thursday, December 09, 2010

The SaaS Consumer’s Point of View – Negotiating an Agreement

“The food was superb, the atmosphere was great, the service was outstanding; it was those goddamned customers that had to ruin it all”. (Morris Green, restaurateur, NYC, 1987)

This short article is an introduction to an interesting blog post that was published recently by Derek Singleton from ERP Software Advice, but before I let you go, I want to take this opportunity to talk about the customer’s perspective.
My writings, presentations and webinars have been mostly dedicated to the point of view of the software provider, whether SaaS or SaaS-to-be. I would like to present a different point of view.

Throughout the years of being on the software provider’s side I have learned a thing two on what makes a happy customer and that is the guiding light I have been trying to follow for years.
I believe that if we understand the customer’s perspective we have a better chance of providing a good service and creating a happy, loyal customer base.

Who is the customer?

SaaS adoption has been mostly done in a haphazard fashion throughout the years. Many of the early adopters were business managers at the department level in the enterprise.
Even within smaller companies, the decision to consume SaaS was usually a point solution, for a particular issue to handle and not as part of a well thought process and methodology.

In many cases the IT department and CIOs were kept out of the loop in defining needs, selecting the service, negotiating the deals and the process of provisioning and de-provisioning. In the extreme, IT found out about their company consuming a web application only when a user would call the help desk and ask for support.

As more CIOs are ‘getting it’, as more IT departments are becoming cloud-oriented they are becoming that target customers, rather than the end users. They are usually better equipped (once their fears are neutralized) to judge the provider, the application, the integration and to negotiate a better deal for the organization.
These IT professionals should be planning a Roadmap for SaaS so that the consumed applications become part of a coherent plan rather than something the cat dragged in.

We should start focusing on this new generation of SaaS customers.

An interesting article covering the negotiations with a provider is therefore presented.