IPaaS

No, it is not a typo, and neither am I contemplating adding another acronym to the alphabet soup. I am simply emphasizing an important aspect of the business - Intellectual Property-as-a-Service. IPaaS is the upper tier of SaaS, what might be known in the industry as ‘Managed Services’ or ‘Expert Services’.
An enterprise software vendor should be delivering more than a software tool. If it also provides a methodology, best practices, and subject matter expertise, then the differentiating value of that ISV is clear. It is (supposed to be) the hub of knowledge of all of its customers on how to do ‘It’ right. ‘It’ may be document, process, or project management, or business intelligence, or performance testing, or CRM, ERP, ABC and XYZ.
Its products are expected to encompass years of experience at a particular vertical or a process by interacting with the customers, heeding to their needs and compiling all of their usage history into the product and the company’s knowledge base.

There are countless tools out there being offered on-demand: email, webex, Google’s Apps and Microsoft Live, to name a few.
What differentiates these services from IPaaS is that they do not require a domain-level expertise. Almost anyone can log into a web-based tool such as webmail and start deriving value from it.

But, one may claim, this domain-level expertise is true for any ISV that offers vertical or complex, process driven systems. So why is this more compelling in the SaaS model?

There are three reasons.

The first is that SaaS vendors can channel their resources into offering a higher level experience for their customers. Most traditional ISVs devote most (if not all) of their professional services’ talents to installation, customization and upgrades/maintenance. If you take these activities out of the equation in the SaaS model, the ‘Professional Services’ can be upgraded to ‘Expert Services’ and dedicate the manpower to helping their customers derive more value from their products.

The second, and even more compelling, reason is that in the SaaS model the software vendors can generate another revenue stream from offering project-based, domain-level expertise. In the traditional model, no company in its right mind would buy and install an enterprise system to run a year-end financials project or a pre-launch performance testing project. Now this is possible with the on-demand model. The software vendor - the ‘expert’- owns the infrastructure; the systems are already installed and ready to use. Send in the expert team (this is a figure of speech of course, the beauty is that you can do it remotely) to run the project and extract a high price for this valued service.

The third, and most important, is the fact that no one has as much visibility into the domain as the SaaS provider. It can view how the software is being used, what kind of data is kept and how it is being manipulated. It can run queries on aggregated data and provide benchmarks and best practices.

Very few companies today make a use of this source of knowledge (and, yes, power) but I predict that it will become an important differentiator in the near future.

Chronicle of a Death Foretold (III)

or 'How to aSaaSinate your Business' (part 3) (view part 2) (view part 1)

The BizEye story is fictitious of course, but one that describes a possible scenario, though not likely in its extremity. Allowing the state of affairs to deteriorate to such a low level without management intervening at an earlier stage amounts to gross negligence. Such a company probably would not have achieved the state of prominence that they have in the market.
Still, it is worth looking at the various actions that were taken or neglected to be taken. This article is focused mainly on the technical and operational aspects, but it is worth noting that other bad decisions were taken at BizEye, which made the profitability of an on-demand offering even harder to achieve. They include an over-simplified pricing mechanism and lack of planning with other functions within the organization, such as finance, sales, and customer and professional services.

So, what could have BizEye Technologies done differently to avoid the dilemma that they are facing? Of course, they should have done their homework, better estimate costs and especially, raise the red flag at a much earlier stage. But beyond these obvious observations, there are a number of SaaS- pecific issues they should have tackled early on.

C-Level commitment
The switch to a SaaS model from an on-site perpetual model requires an understanding that it is not simply another delivery mechanism, but rather a paradigm shift. The company needs to align itself to start selling a service, rather than a product. (see Impact on the Organization)
The switch involves every organization within the company, and some departments will clearly push back the initiative. Being a strategic move, it is the CEO's perogative to make sure that the executive staff is on the same page and not just paying lip service. Without a commitment of all C-level and VPs, to work towards a successful implementation, any company will likely experience many of the difficulties that plagued BizEye.

A Pilot is just that
A pilot project is a inherent step in the process, unless the company is a pure SaaS player. This proof of concept should not cloud the minds of the SaaS champions. It must be limited in time and scope and have a sunset strategy. The pilot would be a very good time to test the concept, learn of the problems, processes and solutions and feed back into product marketing and R&D. These latter two should already have personnel dedicated to the next phase of a hosted offering, whether it is built into the product or integrated with existing application management solutions.

Think Big
Plan in advance a solution that will allow for incrementally scaling up of very large numbers, as that is the end goal of a SaaS offering. This does not necessarily mean large upfront investments, but it does mean having a path in mind that will not necessitate changes in the future of architecture, process or hosting solution. Nine times out of ten, the architecture and planning are geared for a 'proof of concept', with the champions saying that these problems are "good problems" that we will be happy to deal with, when they happen. By the time that happens they are not "good problems" any more, rather they may end up killing the business.

Technology and Automation
Since staffing is still the most expensive line item on your budget, incorporate technology and automation in every aspect of the operation. This includes automating processes like customer on-boarding and provisioning, delegated authority for every administrative activity, self configuration, automated billing, self healing infrastructure to mention but a few.

Bottom line: Economies of scale will prove very profitable when and if the business grows at an exponential rate of the staffing growth.

Automation and Delegation are a subject of a separate article that I will post in the future. Beyond all that has been written above, these are the crucial components that can make or break a SaaS business.

Chronicle of a Death Foretold (II)

or 'How to aSaaSinate your Business' (part 2) (view part 1)

Cracks were starting to show.
The operations team complained that they are drowning in customer requests and are not keeping up with hardware and hosting requirements. The business growth was accommodated by throwing bodies at problems:

Adding a new customer consisted of setting up a new environment, provisioning resources, filling out an excel sheet with the customer information. Adding users to the system needed manual intervention and any administrative function required a Customer Service Representative (CSR) to process a change request.

Billing also was managed through an excel sheet, since the financial model did not integrate with the perpetual model’s existing financial systems; so any modification required manual labor.

The CSRs, who often escalated to the Operations team, handled customer-specific configuration requests with an-ever lengthening resolution time.

By now, the operations team was handling 35 customers with hundreds of users. Combined, they consumed 35 dedicated systems, and were becoming increasingly unhappy with the responsiveness and degradation of the service levels. Some angry calls were received at the helpdesk center.

An upcoming release of the perpetual version, with exciting new features was starting to look like a nightmare. The field had already installed it in about 50% of the customer base, but the hosted services still had the old version. The upgrade date was being postponed time after time, as they could not figure how to simultaneuosly upgrade 35 different systems. One option was to do it incrementally, but that would mean that they had to maintain two different versions, and keep track of which customer had which version.

Curt and Diane lamented that the whole SaaS trial was going to blow up in their collective face. It was clear that they must stop accepting new customers and quickly get technical solutions. By now, the operations team had accumulated vital knowledge of how to do things ‘right’ but that demanded R&D, QA and Services resources.

Diane reported to Sanjib and he called a meeting with the executive team. Diane laid out the plan, showed the growth rates, enthusiastically presented the huge opportunities and requested a commitment from the C-level to make the new model a success.
Bill, VP R&D explained that his resources are stretched thin because of all the ‘real’ customers out there, a new release that is way off schedule and still many issues with the last release that has half his team working with QA to resolve some serious bugs. He couldn’t see how more than three dedicated people would be available to look at an on-demand solution. In any case they won’t have anything ready in the next two quarters.
Joana, the CFO, suggested that if they hiked the price of the service to make the margins, that would justify enlarging the allocated funds of an endeavor that has, so far, just been bleeding the company.
Raul, VP of customer services, claimed that his team was getting a disproportionate number of calls from the SaaS customers, and his CSRs were not really equipped to deal with the users’ requests. He needed a dedicated team just to deal with the hosted customers and he does not have the budget for it.

Sanjib, who was a cautious supporter of the SaaS initiative, realized that he was only partially informed of the state of affairs and faced a true dilemma. He knew that BizEye could not abruptly drop the service, loose face and 35 customers, but he understood that the SaaS solution was not realizing the promised economies of scale and, with the current state of affairs, his best case scenario was to break even.

He assigned Diane, Joana and Bill to a committee to review possible options and report within two weeks, and he required from Diane a post-mortem on why such a promising prospect has turned into a nightmare.

Curt sat in the corner, biting his fingernails.

Next posting: Conclusions