At the end of that blog post, I committed to commenting in much more detail on the topic of Performance Management and the role of predictive analytics in a future blog.

There are various labels applied to the current Performance Management market such as: Enterprise Performance Management [EPM], Corporate Performance Management [CPM] and Business Performance Management [BPM]. For clarity and simplicity sake, I am going to use the acronym “EPM” to represent the category going forward.

Two of the application leaders in the EPM market are Oracle and SAP and they define EPM accordingly:

Oracle. EPM applications are a “broad range of strategic and financial performance management processes …[sic] that drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment.”

SAP. “Enterprise performance management starts with aligning operational plans, budgets, and resources to strategic objectives. It involves providing every information worker with contextual access to data they need to make faster, wiser decisions.

While the goal may be for EPM to involve “every information worker”, the reality is that EPM applications are primarily process-oriented and targeted to relatively small operations teams who are tasked with planning, modeling, budgeting and measuring the business. With few exceptions, EPM solutions are not designed for the Front Office LOB.

Directionally, though, applying Back Office-like performance management techniques to the Front Office to enable better business decisions by LOB is a tremendous opportunity. Using advanced mathematical modeling and statistical analysis with historical, current and forecast data rather than relying upon qualitative assessments just intuitively makes sense.

For example, here are some common business decisions that are typically made by individuals in the LOB using ‘best guess’ practices:

• Sales Rep – What is the price I should quote and negotiate that is most likely to be approved by the customer and simultaneously maximize revenue for my company and my commission check?
• Sales Manager – What forecast should I submit for my team based upon the current deals in the pipeline and the historical close rates of my sales reps?
• Marketing Manager – What is the best price I for my product line based upon the overall market forecast?
• Customer Support Representative - How long should I remain on the phone with this customer to address their concern?

To better address these business issues, a new class of realtime, analytical applications that use predictive analytics and statistical modeling techniques are beginning to appear in the Front Office.

These solutions use the data created through business and market transactions (e.g. SAP, Oracle) and enable the LOB organization to make much better business decisions that align with overall corporate objectives. To distinguish these revenue-oriented applications from their Back Office EPM brethren, I apply the label “Revenue Performance Management” or RPM.

Below are six primary areas of difference between EPM and RPM application requirements.

F&A/IT v. Line of Business

In the Back Office, F&A and IT own the resources and make the decisions that affect how the company manages and reports the business. Traditionally, these organizations have the people with the technical skills, domain expertise to use development tools to configure and customize and manage the systems and applications, and the budgets they need to run business systems such as: accounting, order management, payroll, tax, etc.

In the Front Office, Line of Business managers are in charge but in many cases neither they nor their organizations have access to capital budgets nor the technical personnel and/or expertise required to design, deliver and manage the applications they need to run their organizations. For example, Front Office groups such as Marketing, although potentially responsible for millions of $ in demand generation investment, have for years had to rely upon arcane tools such as email/spreadsheets to manage their function.

Cost Centers v. Revenue Centers

In the Back Office, the primary objective is cost containment. Every business process is analyzed to identify and remove overhead. Once an optimal method is determined by F&A/IT for a corporate business process (e.g. Create Purchase Order and Secure Approvals), an “internal policy” is generated and a corporate-wide mandate issued to drive compliance. Few, if any, are allowed to deviate from the policy.

In contrast, the Front Office is primarily focused on revenue generation. Since most companies can’t mandate revenue from their prospects/customers, they must incent the Front Office organization to identify and capture as much revenue as it possibly can. “Incentive Compensation” plans, bonuses, SPIFFs, etc. must be designed with the intent to find, secure, optimize and reward revenue production.

Static v. Dynamic

In the Back Office, every effort is made to stabilize business processes so that they don’t change and generate unnecessary overhead and errors. In the Front Office, change is the operative word. Customers change. Competitors change. Markets change. Territories change. The Front Office of a company must be able to quickly adapt and adjust to change. To address this side of the organization, applications must be easy to implement and manage and be extremely flexible. Relying upon an over tasked or in the case of small companies, a non-existent, IT organization is a non-starter.

As I stated in a previous post, I believe the primary reason Salesforce.com has become so successful is that it was the first company to recognize that with “internet-based computing”, the term used at the time, you could virtually eliminate IT. They pioneered the concept with SMBs and as their products have matured – enduring skeptics – they have gradually worked their way into the LOB organizations of large enterprises.

It is indisputable that Tom Siebel and Pat House, co-founders of Siebel Systems, identified and created what we now all know as the CRM market. However, Marc Benioff was shrewd enough to recognize that his delivery and business model was a better way to deliver CRM solutions to SMBs that have minimal IT support and LOBs inside larger companies who are tired of waiting on IT.

As described in Clayton Christensen’s book “The Innovator’s Dilemma”, Salesforce.com may not have created the CRM market but its disruptive innovation has exploited it.

Realtime v. Batch

The Business Intelligence market emerged out of the requirement for operational teams to be able to use transactional data to generate better business insight. Where online transactional processing (OLTP) was optimized to enable applications to quickly capture and view transactions, for reporting and analysis a different database structure/format was required. This led to the formation of online analytical processing (OLAP) and formed the basis of the Business Intelligence market.

The EPM market emerged in the Back Office out of OLTP/OLAP applications as companies realized they needed new applications that enable them to better plan, model and set budget targets for the business.

In a similar way, the RPM market is emerging in the Front Office. However, there is one very big difference between EPM and RPM.

With EPM, applications are designed more often around batched data.  While response time is important, if a report takes a while to run it may be inconvenient but it isn’t usually catastrophic to the business. Not so, with RPM applications. Here, the interactions can be in realtime and application performance is always critical. For example, if a customer asks a sales rep a question on the phone, the sales rep needs to be able to reply quickly. He can’t wait on the application .

Since the Front Office has few IT resources, RPM applications can’t rely upon IT to configure, manage and maintain them. They must be highly flexible, configurable; they must be SaaS-based. Consequently, the database and analytical architecture for RPM applications must be completely different than their EPM counterparts.

Voluntary v. Involuntary

If you perform a Back Office and/or operations function it is likely you must use an application to accomplish many, if not all, aspects of your job. For example; processing payroll, generating a purchase order, configuring an order, identifying a performance issue on a network, doing an audit, etc. These all require you to engage with an application to accomplish your task.

In the Front Office, other than a few applications (e.g. email), you may only interact occasionally with an application to accomplish your functional objectives. As a result, it is critical that Front Office applications are easy to interact with and generate easy to identify advantages to the individual using them. Otherwise, they won’t be used. RPM solutions, while needing to be quite sophisticated underneath, must have a very simple User Interface and must be able to be administered and managed by the Front Office organization on its own.

Subjective Data v. Objective Data

By far, here is what I believe is the biggest difference between the Back Office and the Front Office.

With relatively few exceptions, the Back Office is driven by objective data. A Purchase Order is either approved and signed or it isn’t. An entry into the General Ledger has either been made or it hasn’t. Revenue is either recognizable or it isn’t. And, these decisions can be made at a relatively slower rate than the Front Office.

In contrast, the Front Office is largely driven by subjective data and the decisions must be made much more rapidly to respond to immediate customer and/or market demands. What should the sales forecast be? How many widgets should I build? Are my sales territories optimized to maximize revenue? Am I spending too much/little money on support? Today, the answers to these questions are determined by largely by human judgment.

The CFO abhors “guesses” and wants to make decisions based purely upon facts. The CSO (Chief Sales Officer) lives in a world of ambiguity and must rely upon a series of educated guesses. If the CFO of a public company certifies the S-1 is correct and it isn’t, she might go to jail. If the head of Sales gets the forecast wrong, she might lose her job but isn’t likely to go to jail.

Therefore, the goal of RPM is to enable the Front Office to convert what has been primarily been subjective data into objective data so that the Back Office and the company overall can make better business decisions.

I have put my money where my mouth is with respect to Revenue Performance Management. I have made 4 investments to date in companies that have built realtime, analytically-based solutions targeted at the Front Office:

• Right90 (www.right90.com)
• Marketo (www.marketo.com)
• Cloud9Analytics (www.cloud9analytics.com)
• SignalDemand (www.signaldemand.com).

Each of these companies has designed and is currently delivering SaaS-based Revenue Performance Management solutions. Each is using analytics to help LOB organizations make better business decisions by converting what has been highly subjective data into objective data.

My underlying going-in thesis is that the world doesn’t necessarily need more transactional applications or business intelligence (reports/dashboards) for operational teams. Those markets are defined and owned by well-known incumbent brands.

The big market opportunity is in Revenue Performance Management; using applications that utilize data created by OLTP/OLAP that enable LOB organizations to make better decisions. By definition, these must be SaaS-based. Therefore, for the reasons I’ve discussed in previous blogs, it’s not going to be the incumbent brands that can capitalize upon this opportunity.

Only time will tell if I am right.

The HCIT market is very large and comprised of many large sub-markets. Overall, Piper Jaffray estimates the total HCIT market  to be $15.7B comprised of clinical and non-clinical HCIT systems and they break it into the following submarkets:

• Hospital IT
• Ambulatory IT
• Hospital Revenue Cycle Management
• Physician Revenue Cycle Management
• Connectivity/Interoperability
• EDI
• Payor IT
• Outsourced Services
• Drug Development

Within each one of these markets, there are literally dozens of private and public companies. Many of them have been around a long time.

There are many drivers behind the HCIT market but recently the key ones seem to be: shifting payment for procedure to payment based upon clinical outcome, multi-provider/payor access to patient data, and radical reduction of overall healthcare costs in all areas for all participants – patients, physicians, hospitals, insurance companies and government.

As I took a fresh look at the current major application software providers in each submarket, unsurprisingly I found that virtually all of them use a traditional enterprise software model. However, I can’t think of a industry better suited for the SaaS model than HCIT.

Hospitals – IT staff is under tremendous pressure to reduce costs while simultaneously improving service levels; using SaaS-based solutions the hospitals can substantially reduce their capital  and operational requirements. And, unlike corporate entities where competitive differentiation may lie in unique business processes and therefore require highly customized applications to support those processes, hospitals gain little by differentiating themselves this way. Instead, hospitals and all healthcare constituents benefit from economies of scale if the data and the processes are standardized. What about security? Yes, HIPAA/patient data is critical to secure but no more critical than financial data and SaaS has overcome this issue with flying colors in the traditional corporate world.

Physicians - Physicians don’t typically have IT staff and their concerns are far more about providing great patient care, not maintaining and operating patient management systems, EMRs, HIEs, etc. The SaaS model transfers the burden of managing and operating these systems (e.g. Patient Management, Lab, Prescriptions, Billing) onto the shoulders of the SaaS vendor thereby freeing the physician’s office to focus on patient care and outcomes.

Patients - Patients are becoming more and more interested in managing their own healthcare. High deductible plans, rising costs and looming tax legislation are forcing patients to better understand where and how they are investing their valuable health dollars. Having access to web-based applications that enable patients to consolidate and manage their interaction between insurance companies, physicians, hospitals and other healthcare providers will become increasingly more important. However, forcing a patient to interact with cumbersome master/detail list form-based applications is out of the question. By incorporating familiar UI (e.g. Facebook, Twitter, Blogger, etc.) into healthcare applications, users are far more likely to need little training and willing to use the applications thereby reducing support and operational expense for the providers. SaaS providers can easily provide role-based UI that shields the patient from the complexities of the application while providing other users (e.g. the physician’s office) with much more sophisticated UI for their needs.

Insurance Companies – Insurance companies also benefit from the SaaS model since it facilitates online connectivity and interaction between hospitals, providers and patients. Any time the process has to move from electronic to paper, which it does regularly now, there is operational overhead expense and the potential for error introduced into the process. If all participants are willing and able to participate electronically, costs and errors can be dramatically reduced.

While crowded, the HCIT market feels a lot like when we started Siebel Systems back in 1993. A lot of vendors – there were 300+ SFA vendors at the time. A very fragmented market – different companies solving different problems (e.g. SFA, Service, Support, Service, Marketing, etc.). No industry thought leader. Poorly-written applications without a comprehensive and extensible data model and application vision to address all functional business areas.

The Health 2.0 Conference reminded me of the SFA conferences held back in 1993 — lots of tiny booths staffed with people desperate to engage and sell their products. Keynotes and panels staffed with ‘experts’ who are well meaning and have domain expertise but without the experience and knowledge to create a multi-billion dollar industry, consolidate it and own it.

Based upon my recent observations, I think in spite of the hundreds of current HCIT companies there still exists an opportunity for an applications software company to emerge and own the HCIT market; one with a grand products vision yet with laser focus on solving a few key initial pain points using a SaaS-based model.

Since you need to be a member to read the full post, I have included the article in its entirety at the end of this blog post for your reading enjoyment.

I will wait for you while you read the article.

Welcome back.

Savinay makes several good points in his article. For example, I, too, believe that Cloud Computing will ultimately transform the way IT delivers computational and application services within the enterprise. And, one of the key drivers of this transformation – as with previous IT transformations  – is directly related to cost.

However, to make his point, he uses the analogy that Cloud Computing is similar to buying v. leasing a car and that this is a compelling reason for why IT will incorporate Cloud Computing into its operations. This is where he and I disagree.

Rather than buying/leasing a car, I believe that Cloud Computing is, instead, more analogous to hiring a taxi where the taxi driver/company is responsible for driving the car, managing the car as well as getting you from point A to point B. In exchange, you pay an agreed upon ‘rate’ for that service.

Whether you buy or lease a car, you (the customer) are still responsible for driving the car and managing the car (e.g. insurance, gas, mtce). However, when you hire a taxi you have transferred the burden of service delivery from your shoulders onto the shoulders of the taxi driver/company.

In fact, you will pay more (e.g. $ per mile) for the taxi service than if you drove yourself. However, by outsourcing the driving, you potentially derive multiple benefits: the driver may know a faster way to get to your destination, you don’t need to find parking, you don’t need to navigate traffic, and you are free to focus on getting other more valuable work accomplished during the amount of time you are in the taxi. And, it is a variable cost — you only pay for what you need.

Similarly, with Cloud Computing, you are transferring the burden of IT service delivery onto the shoulders of the Cloud Computing vendor such that the enterprise IT organization can focus on other more value-added issues. The Cloud Computing vendor is compelled to deliver a great product/application under an SLA with 4-5 9’s reliability, disaster recovery, 24/7/365 support. With IT departments shrinking daily, many are incapable of delivering comparable services at comparable (and variable) costs.

The fact that IT must increasingly do more with less resources and provide equal or better service at all layers – platform, infrastructure and application -  will ultimately be the driving force behind the Cloud Computing transformation. Yes, this normalizes out to ‘direct cost’ but the simple fact is that Cloud Computing vendors will live or die by their ability to deliver a compelling service that many enterprises have been simply ill-equipped to provide irrespective of the amount of $$ available in their budget.

*********************************************************************************************

Cloud Computing – Hype or Reality?

Guest Column by Savinay Berry, VP, Granite Ventures – PrivateEquityCentral.net

September 8, 2009

Cloud computing is the new “Web 2.0” of today’s tech world. Any company that remotely provided services associated with enterprise software now has products which have a “cloud” moniker attached to them – a phenomena seen not too long ago with Web 2.0, when a whole generation of companies doing fairly traditional Web-content development started calling themselves Web 2.0 companies. Given that both of these terms represent a set of related concepts spreading across software and hardware, the terminology has helped to guide a conversation in the right direction. Beyond that, many wonder whether the cloud is yet another tech trend caught up in a whirlwind of investment and media hype, or is it a model with real opportunity for market growth and success? What does cloud really mean? What are the components? And finally, where are the opportunities to invest? In this article, I will attempt to address some of these questions from an investor’s viewpoint, rather than from a technologist or management perspective.

To Buy or to Lease Is Really the Question….

One analogy to describe cloud computing is buying versus leasing a car. The first option (buying) is similar to the traditional license-based model of buying software, requiring a large lump-sum payment up front to cover the cost of the purchase and then running it on hardware that you own. The second option (leasing) is similar to running software on-demand on leased hardware. While the end-result of using the car is the same, the means to acquiring it are different. Consequently, the workflow and processes associated with leasing a car are different from that of buying a car (mileage constraints, geo constraints, payments, etc.). This analogy can be extended to cloud computing as well, where the end result of running applications with defined SLAs is the same, but the means to get to the application are different. Hence the workflow needed to access the application in a cloud computing paradigm is different – leading to the potential opportunity for innovation and investment.

To further illustrate this point, consider TurboTax, the tax preparation software from Intuit. Traditionally, over the last few years, if you wanted to use TurboTax, you went to the store, bought the CD, installed it on your desktop or laptop’s hard drive and then prepared your taxes. Cloud computing enabled Intuit to develop TurboTax.com, where users could easily log-in to the site, enter their information and file their taxes – without having to purchase any CD/software. Let’s walk through the costs associated with both of these workflows.

In the first case, the company (Intuit) will incur the cost of making the CDs, packaging them and finally shipping them to retailers. The retailers will markup the costs to make their margins, and finally you – the end user – will buy the software package at the store. In the second case, the company will setup TurboTax.com, and enable enough servers on the back-end (possibly by leasing them) to support peak load given the seasonal demand for filing taxes and establish monitoring software to ensure that the site is up and running all the time. Given the current access costs for leasing servers ($0.08 – $0.15/hour) and the relatively low amount of data that needs to be accessed (there are no video or pictures in a tax filing), the company (Intuit) will incur much less costs-per-user to serve the customer. In turn, Intuit will pass this cost savings to the customer, which clearly shows in the pricing – a CD-boxed version of TurboTax costs anywhere from $49 and up, while the online version costs $35 and up. This savings for the end user creates an opportunity for companies to capitalize on specific aspects of cloud computing.  One caveat to this example is the potential growth in the internal cloud – which is a concentrated collection of servers either managed by a third party or operated as a separate business within a company. An internal cloud does not follow the lease model, since the hardware is owned by the enterprise, but it does follow the re-use tenets defined by the external cloud, which leads to similar or better efficiencies. Investors are paying attention to this sector for both internal and external clouds, as explicit consumer interest has a direct impact on driving new markets.

An Evolution in Computing: Lower Cost and Less Time Leads to Market Change

Before going further, it is helpful to review the evolution of enterprise infrastructure over the last several decades and how that innovation has helped both enterprises and consumers. The earliest implementation of computing was in a mainframe environment, which gave way to client-server. Client-server continues to be dominant today, but several evolutions on top of the client-server architecture created more efficiencies. For example, SOA and virtualization created opportunities to re-use both software and hardware resources more efficiently. Finally, the extension of the data center directly led into the cloud, which provides a way to utilize the best aspects of both virtualization and SOA, as well as take efficiency and reuse to the next level.

Within this entire evolution, two attributes were catalysts of change: cost and time to deployment. It turns out that these are the two most important tenets of IT managers as they grapple with the increasing number of choices for implementing enterprise infrastructure. Given the rise of cloud service providers like Amazon, Google and Rackspace, the IT departments within enterprises will be challenged to stay relevant and will try to turn themselves into service-delivery platforms, rather than pure cost centers purchasing hardware. Thus, from an enterprise’s perspective, the cloud is essentially providing an impetus for IT managers to re-evaluate their infrastructure and invest in proactive changes, which forms a credible opportunity for innovative startups in this space. To provide a perspective on the size of the market, in 2008, $870 million were spent on server management software alone, with the spend on this market expected to increase to $2.3 billion by 2013, according to the 2009 IDC report on cloud computing.

The Architecture and Opportunity behind the Cloud

Now that we have established the cloud computing impact from both a consumer and an enterprise standpoint, let’s go into more detail on the architecture of cloud computing and where some interesting opportunities for investing may lie. At the core, cloud computing can be divided into three layers: infrastructure-as-a-service, platform-as-a-service and software-as-a -service.

Infrastructure-as-a-service (e.g., hardware services like the ones from Amazon, Rackspace, GoGrid) will eventually get commoditized and platform-as-a-service is an area that will need the most work from established companies like Google, Microsoft and Amazon. However, the area of software-as-a-service will be ripe for innovation.

Specifically, as applications like Google documents, mobile apps, Salesforce.com, and others shift into the cloud, services driving these applications will be essential. Some examples of these services are databases, billing, analytics and security. Broader adoption of cloud computing within the production environments of companies like Pfizer and ING – where data security is critical – will not happen unless a robust end-to-end security solution exists in the market. Such opportunities will help to create a large and growing market for potential investments in the cloud computing sector.

Since I expect that the future IT environments will be a hybrid implementation of both internal data centers/cloud and external cloud, various tools will be required to ensure that applications, images and databases can be transferred from one resource to another without losing context, policies and security. The need for this “cloud brokerage” will create a category of companies for these management tools. Fundamentally, these tools will adapt existing functions in data centers, like resource planning, provisioning, applications management and transaction profiling, into services catering to the distributed and flexible nature of the cloud.

Finally, due to the potential commoditization of cloud infrastructure (e.g., Amazon Web Services, Google, Rackspace), companies may want to get the best pricing structure depending on time-of-day use, similar to the concept of energy usage on a time-of-day use in states like California. A third-party marketplace providing an arbitrage opportunity for enterprises to shift images from one cloud to another could be an interesting opportunity; however, this vision will not materialize until enterprise adoption of the cloud architecture reaches a critical mass.

By now you can probably establish that while the term “cloud” has a certain amount of hype associated with it, once you peel away the layers and dive in, opportunity is waiting.  The cloud represents investment opportunities and a potentially robust market positioned to change the way enterprises conduct business. The only question remaining is when this market will ripen, rather than if it will ever come to be.

Savinay Berry is a vice president at Granite Ventures (www.granitevc.com), an early-stage venture-capital firm that invests in innovative software, services and communications companies. He received his M.B.A. from the Kellogg School of Management and a Master’s in Engineering Management degree from the McCormick School of Engineering & Applied Sciences, Northwestern University. He holds a Master’s of Science degree in Electrical Engineering from Michigan State University and a B.S. degree from the University of Pune, India.

While at the application level, it’s easy to view Salesforce.com as the star of that sector, it gets a little murky as you move to other functional areas of the front and back office as well as down the overall cloud ’stack’. As with most nascent markets,  the market is highly fragmented: CoLo/Managed Services (e.g. Rackspace, OpSource, many others),  Infrastructure/Platform (e.g. Amazon, Salesforce.com, VMWare, many others), Tools (e.g. Salesforce.com, Corent, Serena, SAP/Coghead, many others), and some a mixture of 2 or more areas (e.g. Salesforce.com).

To make some sense of the trends, I attended a presentation last year by Bill McNee who is an industry analyst with Saugatech. I thought he did a particularly good job breaking the market down into sectors, segments and strategies. Here were some of his observations and predictions he shared with respect to the growth of cloud computing and SaaS at that time:

1. Core systems of record (e.g. Finance, HR and BI/EPM) are growing rapidly – both SMB & Enterprise are adopting.
2. International is beginning to grow.
3. Standalone applications is Wave 1, International is Wave 2, Workflow/Collaboration is Wave 3 and Measured/Monitored/Managed business processes are Wave 4.
4. Platforms are beginning to proliferate.
5. M&A will accelerate.
6. Customer satisfaction is generally quite high with high annual renewal rates.

Bill went on to say that their data showed that 70% of the companies with >100 employees would deploy at least 1 SaaS-based application by 2012. And, he believed that one of the biggest market opportunities would be SaaS-based BI/CPM which in 2008 represented about 17.3% market share and would grow to 40.7% by the end of 2010.

He also predicted that SaaS-enablement would lead to cloud development — which indeed is occurring. Salesforce.com’s announcement of Force.com last year and its latest quarter’s growth from that business is proving this out. In addition,  with acquisitions by companies such as SAP with Coghead last year and VMWare with SpringSource this quarter, we are now beginning to gain a sense for how this may play out.

For traditional software companies in the fight for ‘cloud’ leadership, the overriding issue that remains is the hostile business model that SaaS/cloud computing presents. Wall Street measures these companies by in-quarter revenue growth and margins. Deferred revenue and in-quarter expense are antithetical to those models. With Salesforce.com, they have been successful in selling to the Line of Business and primarily SMB’s (that’s where 90%+ of their business still resides). Selling a Platform/Tools to IT and larger companies is a big departure from that success. However, they recently hired some big sales hitters from Siebel Systems to help address that issue.

Here is some other data Bill shared with us based upon their market research polls:

1. 40% of large enterprises will seriously consider SaaS-based ERP, HR, order management, and procurement solutions.
2. 30% will choose a new next gen SaaS solution provider
3. By 2012, only 20%-40% of software will be sold under traditional perpetual license model

In support of this data, I  think we are beginning to see SaaS break into the back office — initially in SMB — just as Salesforce.com did with its CRM applications. Companies such as Host Analytics, SmartTurn, and Adaptive Planning are beginning to make  progress in an area that has traditionally gone unserved by the large enterprise ERP suppliers such as SAP, Oracle and Manhattan Associates.

However, even though we are beginning to see where companies are picking their spots to compete in the cloud/SaaS space, identifying the future master brand(s) out of this fragmented market is challenging. I would say, though, that the comments I made in a blog I wrote early last year titled “Global Market Leadership” are still germane to becoming the next ‘master brand’.  It may be one of the existing competitors we know about today or, in fact, it may come from a new entrant we have not yet seen.

That’s what makes this market so exciting.

I really enjoyed working with Cary because he acted as a member of my management team; he first focused on the business objectives I wanted to accomplish and then applied law to help me accomplish those objectives. He also helped me negotiate through a minefield of sticky issues like Vendor Specific Objective Evidence (VSOE) for revenue recognition and managing SLA issues.

Cary now has his own legal practice, Platkin Law,  and one of his specialities is helping SaaS startups. I asked Cary if he wouldn’t mind addressing a number of common legal issues that SaaS companies are faced with and he was kind enough to oblige.

Bruce:  What key terms should a SaaS Agreement contain?

Cary: SaaS agreements are typically subscription services agreements that address key customer concerns with service levels, security, privacy, and ultimately performance.   

More detailed SaaS-specific issues include: how mid-term add-on user subscriptions are handled; the details of the renewal process; whether support is bundled in or extra; what usage rules apply to your users; and how third party services are made available through your service.

There are many ways to address these issues depending on your particular business, but one thing is clear – SaaS providers need to ensure their hosting and other services vendors are providing “back-to-back” terms for the terms being offered to customers. 

If you use outside vendors to provision your service, it is critical that you secure the same or better terms from your hosting vendors than your customers will seek from you.   If your vendor doesn’t back you up on the commitments you’ll need to make, you’re really out on a limb.  On one hand, you might choose to manage your risk tightly by seeking a one-off exception from the hosting vendor, but this can slow the sales cycle.  On the other hand, you might choose to accept the risk, close your sale quickly, and make contract commitments that your hosting vendor cannot or will not back up.

Sometimes the risk is merely a matter of numbers that you can easily analyze.  For example, say your SLA is 99.9% with one day of credit for each one hour of downtime.  Your vendor has agreed to provide you the same basic SLA and credit, so you feel comfortable with that arrangement.  But what if a good handful of customers demand 99.99% and two days of credit for each one hour of downtime?  Your risk is merely the delta between the coverage you have from your vendor and the commitment your customers want you to make. 

Crunch the numbers and cross your fingers.

Sometimes the risk is more cut and dry.  For example, say your customer insists it must be permitted physical access to the hosting facilities and full access to the detailed SAS 70 Type II security audit reports on the hosting facilities.  If your hosting vendor limits physical access to its facilities and restricts your right to distribute the revealing audit reports (both common security measures), then promising these things to your customer is simply not possible without an exception from the hosting vendor.

So as you develop your contract terms early on, anticipate your customers’ demands, think through the details, and insist that your vendors get on board with your business and your customers’ needs.

Bruce: Speaking of SLAs, should a SaaS company offer a Service Level Agreement, and if so, what are the key terms they should spell out in the SLA?

Cary: Whether to provide an SLA or not is a business decision based on customer demands and competitive landscape.  Obviously, if you can avoid making a commitment, most lawyers will tell you that’s a good thing.

However,  I think SLAs are a critical element to successfully market a SaaS offering, and more and more, SLAs are required to adequately compete with both on-demand and on-premise alternatives.  If your SLA is world-class and you can make your current performance metrics constantly available to customers, your customers will appreciate it, even if your system goes down from time to time.

There are many types of SLAs, so the first question is what are you going to measure and commit to?  Support levels (response times for support tickets) and system availability are minimum requirements for today’s SaaS offerings.  You might also offer SLAs around reliability — number of outages or time between outages — or response time for your system’s ability to turn around input and output.  Beyond that, I think it can be a bit difficult to offer accessibility, performance or scalability SLAs because there are so many factors that contribute to these issues. 

In any event, most customers want the availability SLA and the performance warranty to run in parallel, so if the system is down for an extended period of time, the customer can max out its SLA credits, and still terminate the contract for breach of warranty if you are ultimately unable to fix the system.

When drafting your SLA, describe in great detail:

• the definition of metric being measured (availability, reliability, etc.); 
• how the SLA percentage is calculated;
• the permitted exclusions to performance, including scheduled maintenance, customer-caused problems, and other issues outside of your control; and
• how credits (or refunds) are calculated and applied to customer accounts.

One tip about credits:  don’t over-do it.  The biggest and best SaaS providers experience downtime events on a regular basis.  No one expects dial-tone availability, and you probably only marginally better than the customers’ own internal IT staff.  You don’t want one or two events to wipe out your business.  One day of credit for each hour of downtime is typical, but only after the system has already fallen below your target availability level and only for use with renewal terms.

Bruce: What terms do you feel should never be in SaaS Agreements?

Cary: I have been encouraging my clients to hold the line on accepting unlimited liability for confidentiality breaches. 

While security of the system and privacy of the customer data are critical customer concerns, you are not Fort Knox.  You can and should use the same type of security measures that other vendors in the industry use.  But if a hacker gets in despite these measures, is it really fair to hold you fully responsible for the damages?  If you said “yes,” then you agree that your monthly subscription fee is adequate to cover not only software and hosting services, but unlimited insurance against this common business risk.  Assuming you were able to buy insurance for this risk, how much do you think unlimited coverage would cost you?   Some multiplier of fees paid, up to a comfortable cap in the high 6 or low 7 figures, is probably adequate to close most transactions – why accept more and put your entire business at risk for something no one can absolutely guarantee?

You might be surprised to learn that other terms that might not be necessary in your SaaS subscription agreement are traditional software license terms.  If your offering is a pure multi-tenant hosted offering without any local client for the customer to use, then you are merely providing access and use of a service.  You are not licensing software in the manner most customers are accustomed to.  This is a subtle but important distinction for your template subscription agreement – SaaS is easier to sell when you continually reinforce the notion that this is not a software license plus associated hosting and managed services.  Rather, it’s a subscription service that is offered the same way to every subscriber.  There’s no delivery of software, no need for source code escrow, and most importantly for the multi-tenant solution, no custom hosting services terms often found in ASP or managed services agreements.  

Bruce: How should a SaaS company set up its Agreements from the beginning so it can avoid revenue recognition problems downstream?

Cary: I am not an accountant so I can only speak to the kinds of terms clients have told me are important to them.  First, SaaS providers know that revenue recognition is one of the great barriers-to-entry for publicly-traded enterprise software companies.  This is because subscription services revenue is recognized ratably over the life of the agreement as the services are performed, which runs contrary to the up-front revenue recognition model of traditional  software license deals.

Pure play SaaS providers build stable annual revenue streams that end up being more predictable.  So, the key to success with subscription agreements is to do all you can to keep the revenue flowing and renewing.    

Although revenue is recognized differently, accountants tend to care about the same issues that arise with standard software and services:  

• Acceptance terms should be avoided (the free 30-day trial and smaller up-front start-up costs have made this easier for customers to bear);
• Payment terms should not be extended too far into the future;
• SLAs should be achievable and warranties should be “documentation” based; 
• remedies for breach of these commitments should be credits on future services only, no refunds of fees paid;
• termination for any reason should result in refund of unused prepaid fees only, not fees for services rendered prior to the date of termination.
• future product commitments should be avoided. 

Bruce: What about multi-year Agreements? Should companies execute multi-year Agreements? If so, for how long?

Cary: Multi-year agreements are great for business — I haven’t met a person selling SaaS yet who preferred short-term subscriptions.  Multi-year contracts are typically procured through the use of higher discounts on fee that are paid annually in advance (or for unconvinced customers, quarterly in advance for the first year and annually thereafter). 

Customers being customers, they love discounts, but hate commitments.  So, I usually recommend terms that require the customer to pay the delta between the discounted multi-year rate and the higher short-term rate in the event it terminates the subscription mid-term or at the end of the shorter term.  SaaS providers with better leverage might even suggest some percentage of terminated subscription fees (up to 20%) as an early termination fee.

Bruce: If a SaaS company is planning to handle customers/data from the U.K./Europe/Asia, will they need make any special provisions?

Cary: This is a very complicated question that depends on many factors including where your company is incorporated, where your data centers and support staff are, where your customer is, where their end users are, what kind of customers they are, what kind of data they are uploading to your system, etc.

The easy answer is if you are a US company that has been selling to US customers, and you are suddenly selling into international markets, you should probably seek knowledgeable US or local counsel to work with your finance team to iron out required terms.

The most common issue that US SaaS providers face early on is Safe Harbor certification.  Many EU customers will not do business with a US company holding personally identifiable information unless it warrants that it complies with the UE-EU Safe Harbor framework.  Participation in this program requires annual self-certification that your company complies with security and privacy standards set forth by the US Department of Commerce at www.export.gov/safeharbor.  I do caution clients not to over-commit to the customer here – EU customers have their own requirements to comply with privacy regulations.  When you are holding and processing data on behalf of your EU customer, you can only really commit to security terms, but issues related to the direct relationship between your customer and its individual end customers can only be managed by your customer.  A simple example:  if privacy regulations provide that the individual should have the ability to “opt out” of marketing programs that use their personal information, only your customer can manage this obligation, so it is not likely that you are in a position to help or hurt their compliance with this regulation.

Bruce: Are there simple things  a SaaS company can do develop a easy, scalable contracting process?

Cary: Perfecting the contracting process is often overlooked, but it can have such an important impact on close rates, cash flow, and customer satisfaction.  From a legal perspective, the easiest thing you can do to close contracts quickly is to use fair, industry standard terms that meet or exceed your customers’ expectations.  For each term in your subscription agreement, you should know not only the industry standard and your customers’ expectations, but also how much risk you are willing to tolerate.  Your law firm’s standard software or services agreement probably won’t do here.  You really need to think through each of the issues, or you’ll learn the hard way as customers begin to question certain provisions with each new deal.

 From an operational perspective, you’ll want to use an automated contract management system that integrates with all of your company’s workflows.  As such, you should solicit input from all of the company functions that touch this important process:  sales, sales operations, finance, legal, provisioning, and support.

If the offering is marketed to the low-end of the SMB market, then an online transaction system with a posted click-to-accept subscription agreement is ideal for an easy, scalable solution.  However, this is rarely sufficient for my clients – even if they can use an ecommerce system, there are always clients who want to negotiate terms or even use their own agreements.  So there has to be an exception process, and an 80-20 goal (or better) of closing as many deals as possible without business or legal exceptions.

I find that the best contracting structure for most SaaS companies is a simple page or two order form generated out of a sales order processing system.  The order form should contain all the applicable customer information, products and pricing being purchased, and a space for one-off terms applicable to the deal (future discount provisions, early termination rights, etc.).  And most importantly from a legal perspective, it should state that acceptance of the order form (by signing the form, emailing acceptance, or issuing a PO) constitutes acceptance of your posted subscription agreement (including the URL).  The posted subscription agreement can in turn reference other posted policies such as support policy, SLA, security policy, etc.  You should have a Word version of the subscription agreement and the related policies available for prospects that request the ability to redline.

Finally, your lawyer can help you minimize legal fees for negotiations by helping you prepare tools that empower non-lawyers to close deals with standard exceptions.  These tools may include:

• a list of regularly-used alternative business and legal terms,
• a “playbook” that describes the purpose of the various clauses in your contracts and provides alternatives,
• an approval matrix to ensure that the right people around the company are approving exceptions to standard terms.

* * *

Legal Disclaimer.  The materials available at this web site are for informational purposes only and not for the purpose of providing legal advice. You should contact your attorney to obtain advice with respect to any particular issue or problem. Use of and access to this Web site or any of the e-mail links contained within the site do not create an attorney-client relationship between Platkin Law Offices and the user or browser.

Investing in Enterprise SaaS

Tech Giants Ramp Up Their Online Offerings

(From THE WALL STREET JOURNAL)

By Ben Worthen and Justin Scheck

The recession is forcing technology heavyweights Oracle Corp., Hewlett-Packard Co., and SAP AG deeper into a low-profit business that the companies have traditionally resisted: selling online software. As businesses look to cut costs many are turning to Web-based software, which saves companies from having to buy or maintain expensive back-office computers.

Instead, the software is run on servers owned by software makers and can be accessed over the Internet, making the total cost of the systems a quarter the cost of traditional software in some cases, analysts say.

Technology giants such as Oracle have avoided providing online software because it is less profitable than traditional software, and sales could cannibalize those of existing products. It also requires software vendors to absorb expenses, including hardware purchases, that previously have been borne by customers.

As recently as September, Oracle Chief Executive Larry Ellison declared that online software companies “haven’t figured out how to make money.” But now the Redwood Shores, Calif., company is developing more than 10 online software programs, including ones that track employees and job applicants, say people briefed on the matter. Oracle declined to comment.

Meanwhile, Germany’s SAP says it expects to release an online purchasing tool later this year, plus two other applications next year. H-P said earlier this month it will develop online versions of almost all its business software. And Microsoft Corp. and International Business Machines Corp. have also moved into online software over the past year.

The changes are being driven by customers, who are looking for ways to cut technology spending in the downturn. “There’s a lower total cost of ownership” with online software, says Joanne Cummins, chief information officer at printing company Standard Register Co. in Dayton, Ohio.

Ms. Cummins intends to replace Oracle software later this year with an online product. She says she doesn’t want to buy and manage the hardware needed to support traditional software, and wants to avoid having to upgrade to a new version of the software every few years.

Fully embracing online software is risky for big technology vendors. “My bet is that these large incumbents are going to be unable to cross this bridge,” says Bruce Cleveland, a venture capitalist at InterWest Partners who previously ran the online software business for Siebel Systems. “They will not be able to transform their business models.”

Most traditional software makers are used to immediately booking revenue from sales of their products. For instance, Oracle’s list price for its traditional customer-management software is $3,750 for every person in a company that uses it, plus $825 per user a year in annual support fees, though most companies receive a discount.

With online software, revenue is recognized over the length of a contract, which often run several years. One of the few online software products Oracle currently sells costs just $70 per user per month. The contracts are often unprofitable initially because of the upfront costs of setting up a new customer, but can be profitable if a customer stays on a system for many years.

The big software makers are just getting their feet wet in online software, analysts say. But the more online software these large companies sell the more likely they are to hurt their profit margins. Oracle currently has a net profit margin of 24.6%. In contrast, online software company Salesforce.com Inc. has a net margin of just 4.4%, though it spends a higher percentage of revenue on sales and marketing.

Switching from a traditional software business to an online model can be “hugely disruptive,” says H-P software chief Tom Hogan. “Shareholders don’t like it, and it’s a real conflict between business strategy and fiduciary duty.”

Some smaller companies that have already switched to selling online software have found the change difficult. Procurement-software maker Ariba Inc. posted several unprofitable quarters when it shifted in 2005 and saw its shares tumble. It’s “a tight rope to walk,” says Kevin Costello, Ariba’s president.

Overall, online software is estimated to account for just $9.5 billion of the $284 billion businesses will spend on software this year, according to research company IDC. But online-software sales are rising more than 40% a year compared with 3.4% for software overall.

Some big tech firms have tried to move into online software before – with difficulty. In 2007, SAP launched an online version of its management software with much fanfare. But to protect sales of its traditional software, SAP said it would only sell the online product to small- and midsize businesses that couldn’t afford its other software. Last year, SAP cut funding for the online software as executives said they couldn’t make any money on it.

SAP now plans to sell online software that complements its traditional software and doesn’t compete with it, and will have a separate telesales organization to push the new products, says John Wookey, an SAP executive vice president.

SaaS companies are typically built upon a stream of relatively low cost subscription licenses, paid out monthly/quarterly/annually — even multi-annually. Unfortunately, for the vendor, the subscription model usually generates far less up front cash than a traditional ‘perpetual license’ software model. But, over time, the compounding effect of the SaaS model can build into a nice annuitystream — provided churn rates are minimized.

It is this up front cash differential that is the primary appeal of the SaaS model over the traditional software model with customers. However, this differential is also what makes the model vexing for the SaaS management team and the investors.

If we examine the income statement of a typical SaaS company, we find that the operating ratios are not that disimilar from a traditional software company that uses a perpetual license model.  Both require similar sales, marketing, engineering, SG&A, etc expenses. However, the SaaS company has the additional burden of absorbing the expense of delivering and managing the service.

The compounded problem of less up front cash and additional expense can make the SaaS model a challenge for the vendor. Therefore, in order for a SaaS company to be successful it must be very efficient in how it designs, builds, markets and sells its service.

Also, while the operating ratios of both models may appear to be similar there are some fundamental differences in how each generate revenue. In a perpetual software license model, revenue is a function of sales capacity. That is, revenue generation is driven by the number of fully onboarded and trained sales representatives. In contrast, SaaS revenue generation is a function of lead generation; sales capacity should only be added once it is determined that sales will be unable to keep up with total lead pipeline generation.

In a traditional software company, lead generation typically comes from 3 primary sources: sales, marketing and partners. We can debate the ratios but basically a traditional software company should expect the sales, marketing and partner organizations to each deliver 33% of the leads in each period in sufficient quantity such that there is an overall pipeline of 3x+ the total number of qualified opportunities needed to achieve the period’s revenue objectives.

In a SaaS model, given its cash constraints and dependency upon lead generation to drive revenue, it is imperative that the lead generation function be highly structured and optimized. 

In all companies, but especially in a SaaS company, the marketing function should be held equally accountable for revenue production as the sales organization; sales should be held accountable for “in period” revenue production and marketing should be held accountable for ”future period” revenue production – where “future period” revenue is in the form of contacts generated by any form (sales, marketing and/or partners) that are qualified and then converted into “sales-ready” leads.

In addition, rather than just the 3 primary lead sources discussed previously (sales, marketing and partners) one other lead source must be added. This critical lead source is “customers”. Done correctly, this is the lowest cost lead source and most valuable; there is nothing more credible than a customer who is willing to promote the benefits of your products. In a SaaS model constrained by cash, it is imperative that you harness this lead source and maximize its effect.

Here are two simple suggestions to help you leverage your customers in the lead sourcing/generation process: 

1. Make it easy for your existing customers to share with anyone else the output of your application. For example, the UI should enable a customer to send graphical reports with data generated by your application with the phrase ”powered by..”  at the top and bottom of the report.  And, you should enable/encourage the recipients to click on ”powered by..” which can take them to a landing page where you can serve an offer to trial the application. 
2. Create a community. There are a number of community applications out there (e.g. Jive, Lithium, HelpStream, HiveLive, etc.)  and you can pick any one of them that appeals to you depending upon the type of features you desire (e.g. ranking/ratings engine, chat, surveys, etc.). These applications enable you to embrace your customers daily, query what they like and don’t like about your products and to use them as mavens and/or super references. You can then use your community as part of your SEO/SEM strategy. On your landing pages, you can offer the prospect a trial and at the same time give them the ability to roam/query your community to find out whether your “marketing hype” matches up to reality. Nothing like a real customer to sell a prospect.

The bottom line is that in order to make the SaaS model successfully work for you – as well as your customers – you need to focus on lead generation. And, due to the cash constraints, you must be hyper-efficient in managing your lead sourcing/generation process. The key here is to harness the power of your customers. Without them, you will place the financial burden of lead generation primarily upon your company and potentially consume more capital than is necessary.

As a result, large software companies whose innovation/growth strategy has relied upon a steady stream of start-up company candidates to acquire may be faced with a shortage in the not-so-distant future. Consequently, companies that have traditionally relied upon their strategic software providers to deliver innovative new solutions to enable them to further optimize back office and front office operations will suffer. 

A Spin on the Spin In

Given the current issues associated with the traditional venture capital business model (e.g. lack of liquidity) and the fear to invest in enterprise software start ups, and the innovation/growth pressures that the large software brands are faced with I believe there is a unique opportunity for the venture community and the large software brands to come together.- using a modified version of the classic spin in.

For this discussion I am defining a spin in as a company formed with the explicit endorsement and investment – including personnel, cash and IP – by a large software company and venture investors. The express purpose of the spin in is to build strategic products and/or go after new markets with the ultimate objective that the large software company will acquire the spin in at some point in the future.

The concept is relatively straightforward and has been tried, tested and proven most successfully in high tech by Cisco but it has also been used by companies in other industries as well as the federal government. However, this approach has not typically been employed by software companies.

Why? Well, primarily because there hasn’t been any need. Large software companies have had the benefit for years of relying upon the venture community to finance a plethora of competitive software start-ups that identify new markets, create innovative technology, and secure customers.  Once some/most of the technical and business risk s are removed and the 2-3 leaders emerge, the large software companies have been able to approach these  ‘winners’ and acquire one of them either willingly or unwillingly. This process has been used successfully by many of the larger brands including, but not limited to: Computer Associates, IBM, McAfee, Microsoft, Oracle, SAP, and Symantec.

Another reason spin ins have not been utilized much by the software industry is due to the widespread ‘Not Invented Here’ (NIH) syndrome that most successful software companies express. The attitude is typically “we can do this better, faster, and cheaper ourselves.”

However, the facts tend to conflict with the attitude.  As companies grow, few really innovative products are started, completed, and successfully brought to market. Each year when the products organization and executive team sit down to consider all the proposed projects for the following year, there is a finite budget to distribute. A line is drawn and all the projects that fall below the line go unfunded. The projects that are usually funded are those that are the current mainstay of the company; the ones that are most likely to generate short-term product and maintenance revenue.

The dilemma is that those projects that fall below the funding line could very well be the innovation the company needs to thwart competition and secure and grow substantial future revenue streams. In addition, many of those proposed, unfunded projects may come from some of the most talented personnel in the company. When those projects don’t make the cut, the people associated with those projects can become extremely frustrated and threaten to, and often do, leave the company to ‘pursue other interests’. This can put a significant brain drain on the company.

The framework of the spin in structure I am proposing is different from the more traditional approach and it is my attempt to address the issues of each of the constituents involved: the large software company, the venture investor and the “spin in” management/employees. While there are some financial/structural problems associated with the spin in derivation I am proposing (there are no panaceas) I believe the benefits could far outweigh them.

Product Selection

The key to selecting a specific project/product as a candidate for a spin in is to ensure the product is strategic to the success of the large software company and that the market opportunity is large enough to support an independent entity.  A product idea that is just a feature of a larger product suite is not a suitable spin in candidate. Think of it this way, if it won’t pass a venture capital firm’s due diligence as a sizeable, standalone firm it isn’t a viable candidate as a spin in.   

Financial Structure

There are several important elements required to make a spin in a viable financial structure for the large software company, the investors, and the employees. Below is my proposed framework for such a structure.

Ownership

The first objective is to ensure the spin in’s financials are kept off the large software company’s books and preventing it from diluting the large software company’s earnings while the spin in grows to profitability. To achieve this, the large software company must pass an outside auditor’s scrutiny demonstrating it doesn’t possess a majority and/or controlling interest. Practically, this means the company must own less than 20% of the spin in and cannot have a formal seat on the Board of Directors.

This is why the large software company needs the venture community as a strategic partner. The large software company can own at most up to 20% so it cannot execute this on its own. The venture community is the ideal partner because it brings money and expertise in building start ups.  

For some large companies, the lack of majority control makes a spin in a non-starter because they don’t have formal control. However, ultimate control comes from the fact the spin in is going to be highly dependent upon working with the large company to gain access to its marketing and distribution channels.  Doing anything to jeopardize that is not in the financial interest of the spin in’s management team and venture investors.

To attract a world-class management team and employees, the spin in will need to allocate a minimum of 20%-25%.

Therefore, simple math suggests venture investors will own up to 60% of the spin in at its onset and may need to provide up to 100% of the forecasted cash requirements. The large software company can contribute any one or all of the following: IP, key employees, marketing programs, a ready-made distribution channel, and even cash to account for its percentage ownership position.

Collar

The primary difference between the spin in structure I am proposing and a traditional spin in is the use of a financial “collar”. It is this collar that can ensure the large software company, the venture investors and the management team are incented to make the spin in become a successful business.

The terms of the collar I am suggesting gives the large software company a call option. This option includes a “first right of refusal” to purchase the company at a pre-determined multiple of revenue for a pre-determined period of time, thereby protecting the large software company from having to compete to buy the spin in on the open market.  This is only fair since the spin in will require the large software company to provide a significant amount of marketing and distribution support.

To ensure the large software company remains interested in the success of the new entity over the long term, irrespective of potential market and regime changes, the venture investors hold a put option to sell the spin in back to the large software company at a certain point in time at a certain multiple of paid in capital.

The collar can be structured such that the management team and employees are incented to drive a range of increased valuation outcomes tied directly to revenue and expense objectives. For example, the call and put options can be set such that they don’t begin to run until year 5. This gives the management team the ability to drive the company’s revenues as high as they can to drive a higher multiple if the call option is executed. If the put option is executed, the management team and employees only receive 50% of their equity ownership which incents them to make the business as successful as they can. Both options can expire at the beginning of year 8 so that if the large software company or the venture investors don’t execute their option, the management team is free to operate thereafter.

Although it is beyond the scope of this article, I have put together a set of terms and models with a variety of outcomes that show how this modified spin in approach is financially attractive to the large software company, the venture investors and the management team.

Summary

Software innovation is still needed by the large software companies and enterprises. For all the reasons discussed, large software companies are not able to do much real innovation internally. For at least the past 5 years, the venture community with few exceptions hasn’t been willing to fund new start ups focused on traditional enterprise software. And, due to current macro-economic conditions, the venture community is struggling with its business model.  As a result, I believe the enterprise software innovation engine could slowly grind to a halt if the status quo remains. I believe there is a unique opportunity for both of these communities to partner using a modified spin in approach. While clearly requiring compromise by all parties involved the spin in could solve a number of key issues that could enable the enterprise software innovation cycle to thrive.

The potential benefits of a spin in approach for large software companies are:

• Strategic projects that might not be funded because they are below the line are able to get funded.
• The cost of development is carried off the parent company’s balance sheet until such point the product is in the market and generating revenue so it is potentially non-dilutive to corporate earnings.
• The parent company is able to effectively retain key personnel by enabling them to exercise their entrepreneurial spirit.
• The spin in retains some of the parent company ‘DNA’ so cultural issues that affect most acquisitions are minimized.
•  The products that are developed can be managed such that they are architecturally consistent with the parent company’s products so there is little overhead integrating the “spin in” products.

 The benefits to the venture investors are:

• They can be certain the technology and business being created are interesting to the large software company from the onset, so they can invest with some confidence that the start up will ultimately have value v the typical 9 out of 10 failure rate they normally experience.
• While the upside will be capped, it his highly likely there will be a reasonably positive return within 5-8 years and therefore the investment will be accretive to the fund’s multiple and IRR.

The benefits to the entrepreneurs are:

• You will be funded!
• Lack of sales and marketing, not technology, is what typically kills most enterprise software companies. With a strategic investor/partner that is motivated to give you access to its customer base with a relevant offering this issue is mitigated.

I have shared this modified spin in concept with some executives at a few large software companies and I think I’ve heard all the reasons why it won’t work. However, as a former senior executive of a large software company, I haven’t yet heard anything to date that, with some work and compromise, makes the concept a non-starter.

So, I’m putting out a challenge to all those large enterprise software company CEOs and senior executives. Find that innovative project you’ve wanted get to market but for some reason just can’t get off the ground. I will share with you the full overview of this modified spin in model and why I believe it will work.

Those few companies that do manage to make it with breakthrough technology are quickly threatened by the incumbents. You are either compelled to sell the company at a time when the multiple for the management team and venture firm is potentially uninteresting or face increasingly greater sales risks as the big brands use their internal relationships to raise fear, uncertainty and doubt [FUD] about the long term prospects of your company and products. This, in turn, causes you to have to make bigger discounts with correspondingly lower margins, endure longer sales cycles, etc. until you give up and either sell out or call it quits. This phenomenon isn’t restricted to just small start-ups. Even larger enterprise software companies have had a difficult time surviving; look at what happened with PeopleSoft, Siebel and Hyperion.

Consequently, over the past 5 years there have been fewer and fewer venture-backed enterprise software companies initiated. The enterprise software start-up has been the ’pipeline of innovation’ that enterprise IT and enterprise software providers have relied upon to bolster their returns. Yet, that pipeline is now drying up.

Ironically, one of the major problems that plagues large public software companies is that their ability to innovate and bring new products to market tends to be inversely related to their success and growth. That is, the bigger they get the less innovative they become. There are two primary reasons for this perplexing phenomenon.

The first is that existing customers place increasingly significant demands upon the company’s product resources to provide bug fixes and deliver enhancements to current product lines. Over time, maintenance and product revenues from existing customers dwarf new customer revenue so companies must invest the majority of their resources to secure these revenue sources, leaving few resources for new product initiatives. Second, the public markets expect companies to generate increasingly better operating results – improved revenues and margins each and every quarter.  Investing in new product initiatives results in little short term revenue increases. The problem is compounded by the fact these new product investments immediately impact the expense side of a public company’s balance sheet. This can lead to poor margins and a depressed stock price which in turn can jeopardize a senior management team’s employment tenure with the company.

An advantage a successful public software company would seemingly have is access to cash to fund new product initiatives. However, while many of these companies do throw off a substantial amount of cash each quarter the quandary they face is that they are unable to use that cash to finance new development initiatives without negatively affecting their quarterly income statement. Interestingly, if they allow their cash balances to grow large enough, shareholders begin to demand the company increase its overall returns through quarterly dividends. Therefore, other than providing a safety blanket buffer for liquidity, cash offers virtually no medium-long term competitive advantage for a public software company.

Some public software companies have adopted the strategy of using their cash and/or stock to innovate and grow through acquisition; the in-quarter investment expense correspondingly offset by an equal increase in total assets. The downside is that this can take a substantial amount of cash and/or requires very liquid stock. Therefore, this approach is generally limited to a very few large companies such as IBM, Microsoft, Oracle and SAP.  Additionally, these companies are reliant upon finding companies that are willing to sell, they must pay a premium to the market value for the company, the technology they acquire must be architecturally consistent with their current products to gain immediate benefit, and more importantly they must entice existing key personnel to stay — which is very hard to do.

For example, take a look at how many senior executives and managers remain at Oracle 1-2 years after an acquisition; by that time, the top talent from those companies usually leave to ‘pursue other interests’. Unfortunately, these are the very people who invented the new technology and created a successful business. Oracle may have a maintenance stream but they are left with little innovation talent.

Look at Workday; this is Dave Duffield’s SaaS-based reincarnation of PeopleSoft. Many of the best folks from PeopleSoft – who were part of the Oracle acquisition – are now at Workday, readying that company to take on Oracle and its PeopleSoft installed base.

None of these issues are necessarily showstoppers but each of them introduces complexity and expense and requires a significant investment of executive and employees’ time.

These problems, and others, can result in product innovation stagnation over time and lead to competitive vulnerability for established public software companies that must serve customers and investors simultaneously. At some point, the lack of a steady pipeline of innovative, private enterprise-oriented software companies to fuel their need for growth could lead to their ultimate decline and downfall.

Given the current issues associated with the traditional venture capital business model (e.g. lack of liquidity) and the fear to invest in enterprise software start ups, and the innovation/growth pressures that the large software brands are faced with I believe there is a unique opportunity for the venture community and the large software brands to come together.

My proposal to address this growing problem is to use a modified “spin in” corporate structure to bring these two communities together. Put to work successfully by Cisco, I believe a version of this structure could help to ameliorate the lack of liquidity and lack of innovation that the venture community and big brands are facing.

I will speak more about this concept in my next blog post.