In the first entry of this series, I presented an overview of cloud terminology and defined the main business offerings. I also touched upon the key essentials, such as defining your needs, building your strategy for change, listing the various players, and gathering reference checks, in establishing a proper research process for implementing an “as a service” (*aaS) solution.
I also emphasized the need to communicate and educate your workforce on the upcoming changes to promote involvement and cultivate a shared vision. In fact, this should be a formula for success for any of your implementation projects.
In part 2 of this guide for small to medium businesses (SMBs), the procurement phase, I’d like to cover the core elements of the selection and brokering process of cloud assets. And by means of procurement, I suggest to consider the following:
- shortlist of vendors
- service level agreement
- contractual considerations
Onward to the Vendor Shortlist
By now, through your contacts with vendors and their completed request for information (RFI)—containing thousands of functional and technical criteria about different options—your knowledge of the cloud solution under consideration should have evolved from shaky to comfortable. However, if you are still struggling with the idea of building your RFI, Technology Evaluation Centers (TEC) has developed RFI templates for various solution types. In these templates, each criterion has been worded to allow software vendors to identify their product’s level of support. Simply make sure that you personalize them to reflect your business needs.
Additionally, to help you further manage your list of contenders, take a look at this third article of a series written by TEC analyst Gabriel Gheorghiu entitled The Path to ERP for Small Businesses, Part 3: Selection of ERP Software, and focus on the differentials of cloud procurement.
The completed RFIs will certainly help you eliminate vendors that cannot support certain key functionalities to operate your business, further shortening the list. If the vendors’ RFIs have been built in Microsoft Office Excel, you can always create your own macros and run a comparison of various options, although this may prove to be a lengthy and painful exercise.
However, getting assistance from a decision support system (DSS) can prove useful in terms of not only expediency, but also objective evaluation of available functionality. For example, using TEC’s DSS allows you to compare a type solution from multiple vendors based on vendor responses to these thousands of functional and technical criteria that conform to TEC’s established standards of accuracy. TEC’s DSS has a built-in score for each vendor response on level of support provided for each criterion, enabling you to perform a quantitative comparison of various software solutions. The DSS can also provide you with advanced comparative reports, such as a failed criteria report—a list of critical functionalities that are not supported by the vendors’ options. From this point, the next step is to invite the vendor to conduct solution demonstrations.
Vendor demos allow you to verify and validate firsthand the solution’s functionalities that are claimed to be supported by the vendor. Being thorough and systematic is critical, particularly for those SMBs planning to move to a platform with enhanced capabilities. Use your RFI to create a demo script by selecting the functionalities most important to your business, which will be evaluated for concept (Yes/No), ease of use (logical access from menus, drill-down capabilities, etc.) and process fit with your own organization. Ideally, have process owners/users evaluate the functionalities presented in the demos that are specific to them, as they are in a good position to compare with current activities.
During the demo, you can get qualitative answers to questions such as: Can you create a purchase order more effectively with this solution? How many steps are required to complete an order?
Once each demo has been completed, and you have perhaps eliminated more candidates, it is necessary to run another comparative analysis to perhaps eliminate additional contenders. It is to this shortlist of vendors that you will be sending your request for proposal (RFP).
In your RFP, it is important that you address the following key points, in addition to the supported functionalities, to gain the most accurate assessment of a total cost of ownership (TCO) of the cloud solution:
- Data Conversion and Migration. The vendor must provide you with an evaluation of the amount of work required to convert and migrate your data into the solution’s framework. Data structure differentiation and ease of export from your database will play a role in the cost. Using a fairly common database model, such as SQL, should alleviate any exportation concerns.
- Number of Users and Respective Roles. Despite a utility-based billing, some vendors do charge per type of role/module attached to each user. As such, you need to provide vendors with a generic inventory list of your personnel (no names—just titles and respective functions) who will use the solution.
- Training. Knowing the number of users, the vendor will be able to issue a quotation for a training program on the new solution. It is advisable to get quotes for on-premise as well as remote training.
- Support. Request the cost structure for solution support from the vendor, with the understanding that cost will change with emerging issues. You will at least have the possibility of running “what if” scenarios. Additionally, you can request incident reports from the vendor, as well as query the vendor’s customers on the vendor’s level of support for previous projects.
- Data Storage. Vendors may charge for storage space based on use. Consider running a few scenarios, such as current use and plausible additions, for budget considerations.
- Exit Cost. This refers to cost incurred for termination of the contract (fully served, voluntary early termination with penalties, or breach of contract). Keep in mind that the exit cost includes cost for exporting your data in a format that can be easily integrated with your next platform, be it on-premise or cloud-based, so be sure to request which format can be obtained.
- Updates. Validate when updates will be implemented and their associated costs, if any. Some vendors may charge once a year, per update, or not at all for the duration of the contract.
- Service Level Agreement. This is the document that will prescribe the quality of delivery of the solution to your organization. This is defined in greater detail in the next section.
All these points should be reflected in the final contract, with the understanding that the solution is scalable according to your needs. Therefore, once you have received the RFPs from the vendors, it is important to run a few scenarios to evaluate your operational cost against the vendors’ respective cost structures. Consider building a vendor matrix—a table with criteria set as rows and vendors as columns for comparative analysis—for each scenario to compare costs. However, it may just be easier to use TEC’s DSS for arrive at a comparative cost analysis.
Service level agreement
A service level agreement (SLA) is basically a list of operational understandings between your organization and the vendor on the quality of the delivery and support for a solution. This document is binding and must be provided with the service contract in the execution of the business relationship. Not all SLAs are similar, and to date, it is still common practice to negotiate the various elements. Here are some of the points that need to be addressed in the SLA:
- Availability. Vendors will guarantee the availability of your solution to various degrees depending on the robustness of their infrastructure and on the level of connectivity between your organization and their servers (direct or indirect connection). It’s important to ask question such as: When the service is up, can you make modifications at all times? Confirm with the vendor when the solution is fully available (no read-only, select modules only, etc.). But here’s the spoiler. Vendors can readily make the solution available on their servers, but they do not control the service level of your Internet connection, so if the latter is problematic, then a change in Internet service provider (ISP) may be worth considering.
- Problem Resolution. A vital point that needs to be defined is the speed with which the vendor can address technical issues. Often, this point is scaled according to the nature of the urgency and the functionality being affected (e.g., production order creation in less than 1 hour, stock transfer request issues in less than 4 hours, etc.). I recommend prioritizing your functionalities and confirming with your vendor the implementation of these priorities.
- Back Up and Recovery. You may decide to back up your data at your vendor’s site, a third-party storage vendor site, or within your own premises. In any event, it is important that you define how often your data is being backed up to give you an idea of how recent your latest available version is, should a recovery process need to be engaged. The speed at which the vendor can perform system recovery also needs to be addressed.
- Performance. This point of service can be tricky, as it tends to be associated with a fair amount of subjectivity. Although the solution’s performance is subject to a variety of factors that may be out of your control—such as fluctuating Internet connection, size of the database, complexities of the transaction, etc.—it may have significant impact on the efficiency of your operations. Thus, validating the overall performance of the solution with vendor’s customers is appropriate. Refreshing your screen and seeing how fast the content updates can be another means of evaluating performance.
- Data Security & Compliance. Above all else, establish the security requirements your business needs to function, and validate these with the vendor. Request reports on various incidents that have occurred, and discuss and agree upon permission to conduct audits on the vendor’s security practices. Additionally, your vendor and its potential third-party affiliates need to comply with your local data privacy legislation, which falls under your legal obligations. Clauses to that effect should be included in the contract.
The appropriate penalties to be incurred for failing to comply with these expectations also need to be included in the SLA, as such failure can have a significant direct impact on your business. When it comes to SLAs, I recommend that you contact other customers for an appraisal of the vendor’s performance. It might help you identify some of the vendor’s weaknesses and even a potential deal breaker. These customers should help you get answers to questions such as: How were issues handled when the vendor was found at fault? How much effort was needed to validate a claim? How long did it take for compensation to be issued? These penalties should reflect the potential impact that such events could have on your business. However, be realistic and prepared to back up your numbers, as unrealistic penalties will simply not be agreed upon.
Contractual Considerations
Brokering an *aaS, with all its technical intricacies, still means one thing: you are brokering a service. As such, some key contractual elements in relation to services still apply:
- Defining the Solution/Service. By drafting a contractual version of your RFP with all the solution’s functionalities and features supported by the vendor and tying it with the solution’s brand name, you legally ensure that the solution with the functionalities is the actual “product” being delivered. And verify that the solution brand used is trademarked under the vendor. If not, confirm with the vendor and get a declaration to that effect. This will prevent potential “confusion” with other solutions, should an issue arise in regard to a lack of functionality support from the vendor.
- Price Structure. This refers to every pricing point that relates to the implementation, usage, and exit strategy of the solution by your organization. What this means is that you and the vendor need to agree on all these points so that no surprises arise. And one way to get your vendor to be forthcoming on possible hidden charges is to include a clause in the contract stipulating that no further charges other than those specified in the current agreement will be accepted.
- Legal Framework. Whether you have chosen a local or foreign vendor, it is crucial to have the contract defining the applicable law—even more so if the vendor is foreign. This will formalize the rules of engagement, should an issue require the involvement of legal support. Going to court is damaging enough, but spending time in court or mediation to simply come to agreement on the applicable law means lost time and resources for your organization.
- Contract Length. When entering an agreement with a new vendor, there is always a certain level of uncertainty. A prudent course of action is to ensure the duration of your first contract with this vendor is long enough to implement the solution and short enough to wait for expiry without incurring penalties. A year is therefore reasonable.
Other legal considerations, such as intellectual property, that are peculiar to your business should also be stipulated in the contract being brokered with your cloud vendor. This process is understandably lengthy, but taking the time at the outset will provide added security to your operations that will serve you well in the long run. And, of course, this contract can serve as a basis for future agreements with other cloud vendors.
At this point, you should be able to choose from your shortlist of solutions and celebrate with a well-deserved bottle of champagne.
On Your Way!
With this entry, you should have the core essentials to broker a cloud service and implement the solution within your organization. Doing your homework before implementing such a solution will ensure that you business flourishes under the clouds.
In the final part of this series, I will be discussing the management of cloud services and overall consideration in integrating this structure within your organization. I will also present some strategic perspectives to help you bridge the gap between your needs and the cloud offerings.
I certainly invite you to share any experiences you have had with cloud solutions. Leave your comments below!