You are currently browsing the tag archive for the ‘cloud’ 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 companies 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.
Robert Kugel – SVP Research
Our recently published Office of Finance benchmark research assesses a broad set of functions and capabilities of finance organizations. We asked research participants to identify the most important issues for a finance department to address in a dozen functional areas: accounting, budgeting, cost accounting, customer profitability management, external financial reporting, financial analysis, financial governance and internal audit, management accounting, product profitability management, strategic and long-range planning, tax management and treasury and cash management. Among the key findings is this: Not using the most capable software is an underlying cause, often unrecognized, of process, analytics and data issues.
Process design, analytics use and data availability and quality were the three most frequently cited issues, each selected by slightly less than half of participants. Software was the least frequently named issue, chosen by just 24 percent. That software was the least cited factor either means that most companies have this aspect of their business nailed down or – more likely – that they are focused on the symptoms and do not recognize the root causes of many of their process, analytics and data issues.
The lack of concern about software in finance departments points to a problem we have observed in our research for a decade. There is a connection between the technology that a company uses to support its processes and the issues that arise when it uses ineffective technology. Persistence in using such tools to execute finance processes is an ongoing barrier to improving the performance of finance departments. For example, companies often handle the mundane chore of accounting reconciliations with desktop spreadsheets. When electronic spreadsheets were introduced decades ago they offered a major improvement in the time required to perform processes. Today, however, dedicated software can perform the process even faster and more cleanly. Our research shows that companies that use software designed to automate their reconciliations process can close faster than those that have manual, spreadsheet-driven processes: More than twice as many that use automation (57%) can close their books in six or fewer days as those that do not (27%). Other research we have done consistently points to reliance on desktop spreadsheets as a root cause of process, analytics and data issues.
Software can have a profound impact on how well a company carries out essential processes. We find that the best-performing finance organizations adopt a total quality management approach to finance and accounting. As in a manufacturing operation, the objective in any finance department process should be to design quality into the process (for example by addressing root causes of errors in calculations and classification) and to ensure consistent execution of that process. Yet spreadsheets often are a source of errors: More than one-third (35%) of research participants said they have found data errors in the most important spreadsheet they use. The inappropriate use of spreadsheets instead of a dedicated application is often the source of problems that result in unnecessary work for the finance organization to correct them. Such glitches also affect other departments, operations and even customer-facing roles such as billing and credit. Inconsistent execution can even nullify the benefits of a well-designed process, but software with built-in workflow can eliminate the root causes of issues that arise when processes are managed with spreadsheets and email.
One of the most important roles that a finance department has is providing the rest of the company with analysis and perspective on business results to enable them to understand “the why behind the what.” Here, too, using the appropriate software can be a critical factor. Desktop spreadsheets are fine for relatively simple ad hoc analyses. However, because they are two-dimensional grids, desktop spreadsheets have a limited ability to manipulate data in multiple dimensions such as by business unit, product family, currency, geography and time. Moreover, creating periodic reports in spreadsheets consumes valuable time that would be better spent focused on addressing other, more valuable tasks. Self-service reporting, which I have advocated, and using the reporting capabilities of enterprise software are two alternatives. Replacing desktop spreadsheets with more capable software can address analytics issues.
The results of our research show that many finance executives and managers are unaware of the negative impacts of using inadequate software, especially the misuse of desktop spreadsheets. People “know” that desktop spreadsheets are the wrong choice; there is overwhelming evidence of their shortcomings. Yet they continue to be the default choice to support many repetitive, enterprise-wide processes because their convenience and familiarity have trumped their shortcomings. Until recently the alternatives were not sufficiently better to convince people to change their habits. That is no longer the case.
There are many compelling reasons for finance and accounting departments to increase end-to-end process automation by substituting dedicated applications and controlled data flows for spreadsheets. Ultimately this is a management issue. Finance executives must periodically evaluate the applications they use and determine whether there are better alternatives. They should routinely triage the desktop spreadsheets commonly used and replace them with more efficient and fully capable automated systems.