A new paradigm for customer value, Part 2 of 3

Part 2: The SaaS approach emerges, bringing economic benefits through the restructuring of software

As the flaws in the ASP model were gradually being exposed, a second generation of vendors began to emerge. These vendors did not take traditional enterprise software and try to force it into a hosted world.  Instead, they created new software platforms fundamentally designed for on-demand delivery that had the following characteristics:

· One, single version (with automated upgrades)

· A single, consolidated platform (the entire software stack)

· One target environment

· One deployment methodology

· Automated customer provisioning (new customers were simply turned on)

· Less configuration, more automation.  Users were offered simpler versions of the applications that satisfied the 80/20 rule, but radically reduced the configuration burden.

By rationalizing the problem and providing a stack that automates the provisioning, maintenance, and normal plumbing that goes along with the implementation and maintenance of software, SaaS fundamentally changed the economics of software delivery.  You may not be able to fully tweak every piece of the software, but people have discovered that most often, they don’t really need to. Instead of selling the kit to build the car, these companies sell the entire vehicle pre-assembled.

SaaS model aligns vendor and customer incentives

Moreover, since SaaS providers incur the cost of maintenance, operations and management, they are driven to reduce these costs.  It has been said that only 20-30% of the total cost of a software platform is license cost – the remainder is the cost of implementing, managing, and operating  the software (people, hardware and other resources). By focusing on this previously ignored part of the software value chain, SaaS providers can dramatically shift the value equation.

Operational SaaS is a success – but then there’s the BI problem.  How do you analyze the resulting data?

As mentioned earlier, software companies that provide operational applications (e.g., CRM, ERP) embraced the SaaS model first.  After a few years of growth and customer expansion, customers had accumulated a significant amount of business critical data in their operational solutions and naturally demanded analytical solutions for reporting.  Since analyzing data directly against an operational database can be catastrophic, vendors began searching for analytics partners.

SaaS operational vendors try to partner with traditional analytics solutions – with unimpressive results

Although these operational companies were based on the SaaS model, many of the potential partner vendors that they evaluated were traditional, behind-the-firewall BI solutions that were already established in the analytics industry.  Unfortunately, these traditional analytics vendors did not have true SaaS offerings, or were struggling to have their traditional model wedged into a SaaS-like delivery.  As a result, the operational software SaaS players were partnered with sub-optimal solutions.

Most often, the analytics partners’ setup costs and deployment method limited the SaaS vendor to the custom, one-off software delivery business when it came to analytics; they lost the compelling economics of their mainline businesses.  In a way, the analytics component ended up as a one-off consulting organization, an inefficient adjunct to the more scalable SaaS operational software model.  The takeaway is clear: mixing software models doesn’t work.  A SaaS vendor can’t redeem a traditional BI partner, and a traditional BI partner can’t add much value to a SaaS vendor.

Stay tuned for Part 3: Business Intelligence in a true SaaS model

Election hounds and pollster politicos - our "click around" demos are up

The Birst website now features the ability to preview what it feels like to use Birst - without even registering or using a password.  Just click on the link to the demo and check out dashboards and reports right away.

These demos are located on the Tours and Demos page.  Click here (http://www.birst.com/tour-demo.php)

For you election junkies, we have a demo with some great data on how the 2004 Presidential election broke out by state and congressional district.  We've also included the demographic data for that congressional district from the 2000 Census, so that you can see not only how a district voted, but how it breaks down by ethnicity, gender, income, etc.  Slice and dice the data any way you like, filter reports to see exactly the data you want, change the way you look at the world.  To go straight to this demo, click here.

If you're more of the armchair CEO type, we have a demo showing results for an imaginary company.  Or if you're a baseball fan, we have a number of charts and statistics on baseball history.

And as always, let us know what you think.  Email us at feedback@birst.com

A new paradigm for customer value: how Software-as-a-Service Business Intelligence offers more for less, faster

This three part series explores how software has moved from traditional solutions to SaaS and how the customer is finally getting the value that they need from BI delivered on-demand.

Part 1: The ASP model offers high hopes, but ultimately low value

The Software-as-a-Service (SaaS) business model is attracting significant attention from both customers and investors, since SaaS promises to fundamentally change the economics and customer value of software.  As a result, customers are increasingly turning to SaaS vendors for software solutions and publicly traded SaaS companies are receiving valuations far above those of traditional software vendors.

To understand why a SaaS model is so compelling, it’s first important to understand the limitations of another business model – that of application service provider (ASP).

The ASP Model – placing traditional software on the web

In the late 1990s and very early 2000s, the application service provider model was very popular. The theory was: take software traditionally delivered via CD-ROM and deliver it in a pre-configured, hosted model to create cost benefits for the vendor and customer. It was thought that by packaging the applications in this manner that the following would happen:

• 
  
  Economies of scale in operations could be achieved


• 
  
  Customer configuration demands would be limited


• 
  
  Deployments of new customers could be streamlined

If these things were accomplished, one could alter the economics of software delivery.

However, this model suffered from some critical flaws.

The critical flaw: the same software that was designed for customer installation and configuration was being used for hosted operation. Many of the design trade-offs that software vendors had made favored extreme configurability.   This allowed them to answer “yes” to feature/requirement requests from customers by essentially pushing back onto the customer the burden of installing and configuring the software.

The economics of traditional licensed software created strong incentives to discount the operational burdens of the customer and create half-features that,  in order to become fully functional, required the customer to finish the job with services.  In the traditional software model, the customer didn’t realize their obligations and added expense until well after the software is purchased. This is a critical reason for the disillusionment with enterprise software that has taken place over the last decade.

The ASP model essentially required that the hosting provider finance the cost of customer configurations. Instead of improving the economics for the vendor, it actually made the economics of software worse.  In fact, it has been argued that customers of ASP solutions demanded more from their ASP providers than they would have of their own internal IT had they relied on the internal organization for delivery.  These costs far outweighed any economic gains from standardizing operations and scaling up support staff.

The end-result: the ASP model did not create any economic benefits over a traditional software delivery model. The total cost of software delivery was shifted a bit, but not changed (if anything it got worse). ASP providers ended being sold-off and treated more as a conventional outsourcing option.  Customers did not see a significant reduction in cost or improvement in service.

Business Intelligence walks into the ASP trap

History has shown that every architectural shift in computing begins first in operational applications and then moves to the Business Intelligence market about 5-7 years later. The same seems to be true for the shift to the ASP hosted model.   The first generation of ASP companies provided operational applications.  BI providers followed later -- several attempted to take the same software that they sell via CD-ROM and provide a hosted alternative.  Despite calling themselves “SaaS,” these offerings are essentially the ASP business model.  As a result, they have encountered the same challenges that ASP providers of operational applications experienced; they are having a difficult time providing compelling value for a compelling price.

Stay tuned for Part 2: The SaaS approach emerges for operational software