You are currently browsing the tag archive for the ‘SaaS’ tag.

There’s a long history of companies not paying close enough attention to the contractual elements of acquiring software. Today, this extends into the world of cloud computing. Many companies are choosing to acquire software services through cloud-based providers and increasingly rely on access to cloud-based data, as is shown by our forthcoming benchmark research, in which a large majority of participating companiesvr_DAC_01_importance_of_cloud_data said that having access to data in the cloud is important or very important. As they say, I’m not a lawyer and I don’t play one on television, so what follows is intended to be nothing more than a conversation starter with legal counsel. But I do advise companies on how to use software to improve their business performance and provide guidance on what software they need to achieve their objectives. From that perspective, let me offer this blanket recommendation: Your company should examine the terms and conditions of its contracts carefully to be certain that it has the ability to control, access and retain its data in single or multitenant cloud-based systems. It should be prepared to add terms and conditions to any software-as-a-service (SaaS) contract to preserve ownership of and access to the data as well as other proprietary elements of that business relationship.

The fact is that choosing a cloud-based option presents a different set of legal issues that purchasers do not face with on-premises software, so it’s important that they consider the terms and conditions of the contract. Some of these issues aren’t completely new – they go back to the days before perpetual contracts and “open systems” were the norm. In that era, a company could find itself hostage to a vendor that shut down the company’s system remotely and prevented it from using the technology to run its business and retrieving its data from the system. Before entering into any SaaS contract or renewal, it’s important to review the details of the contract and its terms and conditions. The company should insist on modifying the wording of the contract if necessary to the satisfaction of both parties. It’s essential to perform this review early on, when vendors are short-listed, not at signing. It’s also important to review and, if necessary, revise the contract before each renewal. Customers have leverage at renewal since the most expensive event in a subscription-based business is losing a customer.

There are many facets to a SaaS contract, including performance, reliability and security as well as data. My focus here is on the last item.

Going into a relationship with a SaaS vendor, it’s essential that the contract specify what data the customer owns, whether that ownership is shared with any other parties, including the SaaS provider, and how the customer can obtain its data from the vendor. A SaaS contract should delineate what data the customer will have the right to take at the time it terminates the contract. This should include its data in the database tables but also might cover data about its specific configuration of the application and data from the database logs that pertains to its use of the system. It also should specify the form and format for that data as well as the timing of when the customer will obtain that data (for example, how many hours or days from when the customer requests it), how often the customer will be provided with data (unlimited requests is preferable) and the charges for such data transfers. Creating a set of extraction reports that harvests all the data from the buyer company’s tables may be adequate, but then again it may not be sufficient. The contract also should address contingencies for change of control (that is, if the vendor is acquired by another company) and bankruptcy.

Having database table data and information about the database structure is useful in the process of moving from one cloud vendor to another. Migrating from one vendor to another almost always involves setting up the successor system before the previous vendor’s contract expires. Also, in the process of finding and selecting a new vendor, a company will find it necessary to provide information about its existing system and the data that’s in it. This should be part of the background information included in a request for proposal (RFP), which should include a section detailing how the implementation service provider will manage the migration. Clarifying this part of the process ought to be a part of the selection process, and getting the details of the migration in writing before selecting a vendor and implementation partner reduces the possibility of encountering a potentially time-consuming and expensive problem. The responses to the RFP can help the buyer craft the contract terms and conditions with the successor vendor and implementation partner.

How often the customer can transfer data from the system vendor’s system is important because it’s likely that a customer will need to do so multiple times. For example, in most cases it will need to extract the data from the current vendor’s system at least once before the contract terminates in order to begin the implementation process for the follow-on system. This will be necessary weeks if not months before the termination date, followed by additional data extracts from the old to the new system. Companies also should consider how to replicate the process of running the incumbent and new systems in parallel during a testing phase. There may be fewer potential “gotchas” in migrating from one cloud to another because there are no system configuration and other infrastructure issues with which to contend, but there still will be many process, business logic and configuration kinks to work through. Even after migration, a company may find it necessary to maintain its instances with the old vendor for legal or audit purposes for several years. Setting the parameters of pricing a decommissioned version in a contract is likely to save money down the road.

There’s also the related issue of data ownership. A contract with a SaaS provider should acknowledge that the customer is the sole owner of its data and lay out the ability of the service provider to access that data with the objective of ensuring that the data can be used only to provide services to the cloud customer. Also, the legal ramifications of connecting a company’s cloud system to other applications or an operational data store should be spelled out.

Data retention and third-party access should also be covered in the contract because during a civil, regulatory or criminal legal proceeding, the customer may be subject to electronic discovery. This involves the exchange of information from electronic systems in electronic format. Data identified as relevant by the attorneys involved in such a process is placed on legal hold, which means that it cannot be deleted or altered. Making this explicit in a SaaS contract may reduce the possibility of legal repercussions if, for example, the vendor inadvertently eliminates or alters data that is covered by a legal hold.

The physical location or locations where the customer company’s data is held, as well as any backup sites, ought to be included in the contract. This is important because of requirements by some countries (for example, the EU Data Protection Directive) that specify where data can or cannot be located and whether data transfers are permitted. The contract also should spell out how the customer company will be notified ahead of time if the locations where its data is stored will change.

It strikes me that we are still in the naïve stage of the cloud software revolution, but it’s time to imagine the worst that can happen. I recommend that SaaS vendor user groups focus on the contractual aspects of their relationship with vendor, especially with respect to their data. They can collectively engage their corporate counsels in crafting a set of desired contract terms and establishing best practices for ongoing access to data and for facilitating migration from that vendor’s environment when customers wish to make the move. They also should focus on how secure their position would be in the event of a corporate bankruptcy and on the change of control provisions (if any) should their vendor be acquired. For their part, I recommend that vendors develop their side of contracts to anticipate having to meet their customers’ demands for open access and control. Just as buyers forced vendors to adopt a more open systems approach two decades ago, SaaS customers are unlikely to want to find their data locked in. Developing a legal framework to handle unfortunate contingencies makes better sense than trying to deal with issues on an ad hoc treadmill.

Regards,

Robert Kugel – SVP Research

As I noted in a recent analyst perspective note the recurring revenue business model is gaining increasing use worldwide. Our recently completed recurring revenue benchmark research shows that companies are using this business approach because they find that it can convey a strategic advantage in creating additional sales opportunities, making future revenues more predictable, enhancing their customers’ experience  and increasing customer loyalty. However, recurring revenue businesses have unique challenges, especially in finance VentanaResearch_RR_BenchmarkResearchand accounting departments because most ERP systems (the ones that handle the accounting function) are not designed to manage the specific requirements of a recurring revenue businesses.

One of the root causes of the problems finance and accounting departments encounter with managing the invoicing and billing of recurring revenue is that the order-to-cash process often is fragmented, with each part of the business doing its own thing and managing its activities. Our research on information optimization confirms that this is a common issue. A choppy process leads to fragmentation of data as it is entered multiple times in multiple systems. And because of such multiple entries, inconsistencies and errors are almost inevitable. For example, last-minute changes in a contract or a purchase order may not be entered everywhere or at the same time. After a couple of months customers may add or subtract services, and these changes may not be reflected accurately in every system at the same time. Creating new services or products thus can generate complexities that take time to implement. All these complexities and changes can create billing errors.

Finance departments wind up bearing the brunt of data fragmentation, a fact that is rarely appreciated by the rest of the company. Since they can’t take for granted that the billing data is utterly reliable, they construct monster spreadsheets to vr_Recurring_Revenue_06_finance_less_satisfied_with_invoicingreconcile the information about the customers’ services, pricing, the contract terms, usage and other factors that are stored in each of the systems. It takes time to work through the reconciliation spreadsheets, and this job requires experience. The more variations in the services and products offered, the more complicated and time-consuming the reconciliation process becomes. Therefore, it shouldn’t be a surprise that our research reveals that those working in finance and accounting organizations are far less happy with their company’s invoicing process than everyone else: only 29 percent of them are satisfied with invoicing, compared to nearly half (47%) of people vr_Recurring_Revenue_07_dedicated_system_users_are_more_satisfiedworking in other parts of a company. One way of dealing with such complexities is to put tight controls on what sales people can offer and what product managers can introduce. But this isn’t a good solution. It might save time spent by the accounting department but can make the company less competitive. Moreover, it’s unnecessary.

Dedicated billing systems that are designed for companies that offer recurring or subscription services enable finance and accounting departments to get what they need to perform their jobs well without diminishing the company’s ability to introduce new products or features quickly, and without severely limiting sales teams’ flexibility in negotiating pricing, terms and conditions. These dedicated billing systems provide finance and accounting groups with controlled, accurate and up-to-date billing information so that invoicing becomes easier and more reliable. They can substantially reduce or even eliminate errors (which can speed up collections), and they enable companies to handle customer billing inquiries quickly. Automating the process means reducing the need for administrative or operational overhead, thereby cutting costs. This probably accounts for the finding from our recurring revenue research that almost all (86%) users of dedicated billing systems are satisfied or somewhat satisfied, far more so than those that use spreadsheets to support their process and those that rely on their ERP system.

A well-designed recurring revenue billing system usually will automate the revenue recognition process to make it completely reliable and easier to audit. Companies that try to manage revenue recognition in desktop spreadsheets almost certainly will find that keeping track of even slightly complex services is difficult and time-consuming. It’s all the more difficult because in many recurring revenue businesses, customers frequently modify or change their contracted services or products. Using spreadsheets to track what revenue can be recognized and when is even more difficult when customers decide to add or drop features, bring on new users or respond to a new marketing offer.

The business case for investing in a dedicated billing system often can be made simply on the time (measured in full-time equivalent employees) saved in bringing on new customers, modifying their contracted services and preparing and checking invoices. It’s also important to be able to quickly add or modify a company’s offerings and to give sales people the ability to adjust the terms and conditions of contracts (within reason, of course) as needed to close a sale. I recommend that CFOs, controllers and heads of accounting in a business with a subscription or any other type of recurring revenue business model that are not using a dedicated billing system investigate this software; they should admit that most ERP systems are not designed to handle the specific requirements of these types of business. These dedicated systems usually are available as a cloud-based service, so they are relatively easy to deploy, and most vendors have experience integrating their offerings with ERP systems.

Regards,

Robert Kugel – SVP Research

RSS Robert Kugel’s Analyst Perspectives at Ventana Research

  • An error has occurred; the feed is probably down. Try again later.

Twitter Updates

Stats

  • 127,116 hits
%d bloggers like this: