THE BUSINESS CASE FOR CLOUD BY CHRIS TIERNAN

Transcription

1 THE BUSINESS CASE FOR CLOUD BY CHRIS TIERNAN business with CONFIDENCE icaew.com/itfac

2 ICAEW s IT Faculty provides products and services to help its members make the best possible use of IT. It also represents chartered accountants IT-related interests and expertise, contributes to IT-related public affairs and helps those in business to keep up to date with IT issues and developments. As an independent body, the IT Faculty is able to take a truly objective view and get past the hype surrounding IT, leading and shaping debate, challenging common assumptions and clarifying agreements. For more information about the IT Faculty please visit icaew.com/itfac. Copyright ICAEW 2012 All rights reserved. If you want to reproduce or redistribute any of the material in this publication, you should first get ICAEW s permission in writing. The views expressed in this publication are those of the contributor. ICAEW does not necessarily share their views. ICAEW will not be liable for any reliance you place on information in this publication. You should seek independent advice. ISBN

3 THE BUSINESS CASE FOR CLOUD By Chris Tiernan

4

5 Contents 1 INTRODUCTION What s new Cloud appeal Messages from the Guide to Business Cases The journey to the Cloud Digital natives and digital migrants 03 2 WHAT IS NEW ABOUT THE CLOUD? Cloud formation Low-level business Clouds Medium-level Clouds Interconnected Cloud services Sales, support and contracts High-level Clouds Badge engineering Financial considerations Summary 07 3 WHAT REMAINS THE SAME? Cloud service specification Plethora of vendors Understanding costs and benefits Contracts Transfer to the Cloud Managing the Cloud service Financial management Business continuity planning Exit management Summary 12 4 CONCLUSIONS 13 APPENDICES APPENDIX A: ICAEW AND OTHER SOURCES OF INFORMATION ON BUSINESS CASES AND CLOUD 14 APPENDIX B: ECONOMIES OF SCALE HOW SIZE MATTERS 15 APPENDIX C: CLOUD BUSINESS CASE INFORMATION CHECKLIST 17 ABOUT THE AUTHOR 19 The business case for cloud 01

6 1 INTRODUCTION The ICAEW IT Faculty Guide to Business Cases was published mid 2010 and since then the Cloud has risen to prominence. Many claim this to be a revolutionary technology which will radically change how enterprises will use and manage IT. The parallel often cited is that long ago we stopped making our own electricity. Now we can stop having to worry about making our own IT. This message has strong appeal to executives in enterprises of all sizes, so every manager responsible for IT now needs to consider Cloud as a means of providing some, or perhaps even all, future IT services. This has important implications for business management and those who review and approve IT spend. 1.1 WHAT S NEW? But what really is new and what is the old re-packaged with a Cloud label and, in particular, how should business and financial management consider Cloud options? Is it as cheap as chips and can everyone afford it on their credit cards, or are there hidden management issues and costs which have still to be considered seriously and taken into account when contemplating Cloud adoption? The Business Case for Cloud has been written to complement the Guide to Business Cases (see Appendix A) and seeks to answer these questions from a non-technical perspective. While no prior knowledge of Cloud technology or terminology is required it is recommended that the two guides are read in conjunction as many of the principles and management practices mentioned in the Guide to Business Cases also apply to this guide, particularly Appendix C. Readers wishing to gain a fuller understanding of Cloud technologies and terminology should consult other relevant ICAEW publications, some of which are listed in Appendix A. 1.2 CLOUD APPEAL One of the major attractions of Cloud is that it appears to relieve management of its involvement in a wide range of IT activities; freeing it up to get on with its business. Gone (is the belief) is the need to expend capex on server hardware, find a safe place for it and employ anyone on a permanent or occasional basis to look after it and to sort out the problems and have the issues of managing IT specialists. A further attraction is that the Cloud service providers, through sharing overhead costs across their customer base, should be able to achieve significant economies of scale not available to smaller businesses running their own IT. Less fuss and cheaper what more could you ask? 1.3 MESSAGES FROM THE GUIDE TO BUSINESS CASES A key principle expounded in the Guide to Business Cases was that all change requires up-front expenditure (investment) and carries uncertainties (risks) before business benefits materialise. Very often necessary expenditures are not identified early, which is why many projects overrun with respect to both time and budget, and an optimistic view is taken of benefits, so not all envisaged benefits materialise. Now much of the investment is from opex and this should all be included in business cases. The Guide to Business Cases gives further guidance on what to include, especially in the area of business change costs. 1.4 THE JOURNEY TO THE CLOUD At present you might have your own IT equipment on your premises with one or more IT specialists on whom you call when there are problems or you want to make changes. Some of these IT specialists might concentrate on what lies under the covers and some might look after applications which have been specifically developed for your business and the way you work. You might have expended quite a lot of time and money getting them fit for purpose. 02 The business case for cloud

7 Every organisation which depends on IT to get its work done has developed its own set of habits (good and bad) in terms of the way it uses IT and what it expects IT to do. Anyone who has changed from one major release of software to another has experienced the frustrations of not being able, easily, to find functionality which has been moved around. It can take quite some time to get used to new software. That difficulty can be compounded when the software supplier is changed as well, while extra training costs and disruption can also be incurred. Cloud holds out the prospect that a supplier will rent you the use of its equipment, housed on its premises, and look after what is under the covers so you will not need technical specialists. Whether you will still need your bespoke applications will depend on how important they are to you and whether any supplier can provide an alternative which is a good fit. If it can, you might not need your application specialists either. Also, rather than paying for your own hardware and software (other than what you carry around) out of capex, it can be part of the service cost and so becomes opex. Further, you might get greater flexibility in terms of how much is available for you to use at any point in time and for how long you are committed to keep paying for it. This is very good news if you have big peaks and troughs and/or you are growing rapidly or reducing your headcount. But is this reality or a myth obscured by clouds of sales hyperbole? 1.5 DIGITAL NATIVES AND DIGITAL MIGRANTS 1 Those of you who are young enough to have grown up with such facilities have come to be called digital natives. Those of us who can recall older technologies are known as digital migrants. Digital natives are said to get it and have an intuitive understanding of the Cloud. Digital migrants are more cautious, recalling the troubles and traumas of badly managed business IT. Digital natives expect constant change and some outages and loss of data stuff happens! They expect to treat IT as a commodity and what they use in the workplace should be at least as good as they have at home. Digital migrants worry about security, data protection, contract terms, policies and procedures. There is clearly a cultural digital divide which needs to be bridged between what this technology has to offer the consumer and its role in the work place. The Business Case for Cloud helps to bridge that digital divide. Section 2 What is new about the Cloud? is directed to digital migrants and looks in more detail into what is different about the Cloud. Section 3 What remains the same? is directed at digital natives and looks at what lessons from the past remain important when managing business strength IT services. Hopefully by considering both perspectives a common understanding can be reached. 1 See The business case for cloud 03

8 2 WHAT IS NEW ABOUT THE CLOUD? Whether you are a digital migrant or a digital native, you are almost certainly already a Cloud user. Through free voice services and social networks you communicate with relatives, friends and colleagues around the world. You undertake personal research using search engines which scan the internet. You download news, books, music and videos to devices sold in the high street or bought over the net. 2.1 CLOUD FORMATION The two fundamental factors which have given birth to the Cloud are: omnipresent, always-on, fixed and mobile, high-speed internet connections at consumer prices; and substantial investments being made by particular vendors in large, and in some cases enormous, data centres. This combination means that potentially, anyone, anywhere can communicate and exchange data, using a wide variety of devices, with IT services, on almost any scale, running virtually anywhere in the world. Gigantic corporations with household names have emerged over the last decade with new business models based on these factors. In a number of cases that growth has been fuelled by consumer demands. So why not now apply this to businesses of all sizes? 2.2 LOW-LEVEL BUSINESS CLOUDS Most businesses now use some Cloud applications eg, for virus protection and spam filtering, software updates, remote technical support and business continuity, backup and archival services. These run at the housekeeping level and users might be generally unaware of them. These services also demonstrate how economies of scale can bring down costs (see Appendix B). In these cases there is a very high degree of commonality among the services provided to customers, whatever their size and business. The suppliers also have certain costs which are incurred regardless of the number of customers eg, setting up and maintaining their special software and investing in automation. Thus, as the number of customers increases, certain unit costs decrease. They obviously have some costs, like hardware, which increase as the number of customers increases. Overall, however, their business models depend on being able to provide such services more economically than their customers could do for themselves. Through scale and the expectation of attracting possibly hundreds of millions of users, these services have been consumerised. Some businesses have gone further by renting processing capacity and storage space in suppliers data centres. In these cases they only need to acquire equipment which connects to the internet. You can run all of your favourite software in the rented IT capacity with this approach, though you will still need to look after that software yourself. The benefits here come from only renting what you need at the time. Hence, if you have significant short-term or intermittent requirements for large quantities of capacity this might be more economical than you owning the equipment. An example here is a well-known charity which receives practically all of its income electronically on a few nights each year, in coordination with television programmes highlighting its work. But above certain requirements and duration of use, this rental approach can be more expensive than owning the assets. It is like comparing renting and owning a car. A variant of this is that the supplier provides and supports both the hardware and operating systems and you provide and support just your own applications. At first sight this might appear attractive in that it looks like you will not need technical expertise. However, issues of compatibility can arise (if the supplier needs to update its operating systems to maintain vendor support) which do call for expertise and/or you incur extra supplier costs for the supplier to fix any issues arising between your applications and the new versions of the operating systems. 04 The business case for cloud

9 2.3 MEDIUM-LEVEL CLOUDS Moving up from the housekeeping and hardware level, there are other ubiquitous IT services which could be, and often are, Cloud based, like hosting websites. Here there can be much more customisation to the needs of particular users. Indeed, the work might get split between the supplier and the customer eg, with the supplier providing the hosting environment and the customer providing the material seen by visitors to the sites. These services can be very low cost but will offer commensurately low compensation for any outages; think carefully about what you would lose if your website was to be down for a day! However, if your site has dramatic variability in the number of daily hits, you might prefer the cost flexibility offered above. In cases where websites need access to changing data, like availability of stock or vacancies, there clearly needs to be some always-on connection between the Cloud-hosted services and this data. Now some part of the service is consumerised and the rest customised, with the former, rather than the latter benefiting from economies of scale. Indeed, extra costs might be incurred developing special interfaces between these systems and your data. 2.4 INTERCONNECTED CLOUD SERVICES It is quite possible that for any particular organisation, each of the Cloud-based services mentioned above is supplied by a different vendor, each with its own contract terms and needing to be managed, at least from time to time. It is also likely that these various Cloud services will need to intercommunicate with one another which might mean that special software interfaces need to be written and supported between them. You might also want to write some software to wrap up your systems so they can be easily moved between suppliers should you choose to do so. This also raises the question of how you get any problems resolved and when you want changes, how they get implemented. 2.5 SALES, SUPPORT AND CONTRACTS A substantial cost for vendors can be their sales staff, contract negotiators and customer-facing support staff. Potentially, these all increase as the number of customers grows so offering few economies of scale from this element of their costs. The solution is for vendors to offer standardised services, so all customers get the same functionality, under standard, non-negotiable contracts with support provided via a website, portal or from a centralised team. They then charge additionally for any bespoke requirements. This is a model very familiar to us from utility service providers, like telephone, gas and electricity suppliers, although the hourly rates for Cloud people might be much higher. In order to keep such costs down, a number of Cloud service providers do not want to deal directly with end users but operate through partners. Those partners might receive discounts from the Cloud services providers which enable them to make a profit selling on the services and often provide additional services of the more traditional types, like personalised helpdesks and resources to fix problems and make changes. 2.6 HIGH-LEVEL CLOUDS A number of Cloud service providers offer not just to host applications and data but also provide their own proprietary software. This can range from highly generic , text, spreadsheet, presentation and collaboration 2 software, through software for specific business functions like customer management, finance, HR, procurement and facilities management, to industry-specific applications like hotel bookings. With these your processing takes place in their data centres on their equipment where your data is held and they take care of technical and application issues. You might even be able to pay by the transaction, although there might be a standing charge as well, for example, to be connected. The economies of scale here arise from standardisation of application software across multiple customers. Vendors might also achieve further economies by sub-contracting eg, for the provision of data centre services, to organisations who supply such services to multiple vendors. It is important to consider that proprietary software might not work in the same way as the software with which your people have been working and with which they are familiar. Changing to new software is likely to destroy any economies you are seeking, and changing the way your 2 Collaboration software enables a group of dispersed users to work concurrently, across the internet, on the same documents, spreadsheets, presentations, set of calendars etc. The business case for cloud 05

10 people work also has a cost and might take some time. If all you need is basic functionality, then Cloud could be the way to go. But if your sales proposition to your clients and customers depends on some complex functionality, there is much more to consider. Clearly, using universally available and inexpensive software facilities will not provide you with competitive advantage. But not using consumerised software, where that is all you need, might give rise to competitive disadvantage if your bespoke software causes your costs for special support to be higher. With traditional outsourcing it was said: retain in-house what is core to your business and outsource the chore. Now with the entry cost to the IT capabilities offered in the Cloud being so low, what do you really need to do differently from your competitors and is that uniqueness paying for itself? Much off-the-shelf software is very richly endowed with functionality which hardly anybody uses or even knows exists. Do you need all of that or something more basic and less expensive? A few more points to consider when standardising on proprietary software in the Cloud are whether the supplier can change its functionality upon which you depend, at any time without your agreement and how you would remove your data from suppliers systems in an intelligible form when data storage formats can also be proprietary and confidential. 2.7 BADGE ENGINEERING Now that every IT supplier must have a Cloud offering, beware of services which have been given a makeover simply by changing their names. A classic example would be an service provided from a supplier s data centre using hardware which you own (capex) and software which you license and is configured specifically to your needs, with telecoms links dedicated to you and support tailored to you. This is traditional outsourcing which has been around for decades, even if it might now be called a Cloud-managed service. A Cloud solution would use the internet and would be a standardised service available to anyone using centralised shared equipment owned and software licensed by the provider and you would pay for it all on an inclusive, annual subscription basis, per user (opex). This is a very different financial (and potentially, operational) model. 2.8 FINANCIAL CONSIDERATIONS For many organisations, IT purchases make up a substantial part of their capital expenditure and IT managers, as a consequence, often find approvals for upgrades and improvements to IT facilities difficult to secure. Also, rarely is IT spend directly attributed to those for whom the IT services are provided because of the complexity of apportioning shared resources. This means it can be difficult to hold to account those who are really causing IT costs to be incurred. Thanks to the business propositions of Cloud service providers, it is beginning to look as if some of these issues can finally be addressed. Other than, perhaps, the equipment which people carry around (laptops, smart phones and other mobile devices), practically all of the rest could become opex and be paid for on an annual subscription basis with each user s subscription recharged to that user. Where end-user equipment is expensed, we might be coming towards the end of seeing depreciation being recorded in the IT budget but that depends on what the business capitalises. If the business does not own the physical assets then capital allowances cannot be claimed on them but the costs, being opex, are 100% tax deductible in the tax year in which they arise. Switching to opex, means issues about appropriate depreciation/amortisation periods and profit and loss write-offs disappear. Also budget swings when fully depreciated assets continue to be used and then need to be replaced are also avoided. As a number of these services are upgraded and improved on a rolling basis by the provider within the charges, IT managers will not need to make so many requests for additional funds and when they do they will not be for as much. Further, the requests they do make are likely to be more easily linked to business changes eg, transaction volumes and headcount. However, the Cloud does present a few new challenges, like the effect on key business ratios based on capital expenditure (eg, ROCE), how return on investment will be calculated (what is the investment now?) and, potentially, a greater variability throughout the year in IT spend. Also with traditional outsourcing, physical assets might have transferred to the supplier at book value. Cloud suppliers do not want your equipment so you might need to take a profit and loss hit in switching to the Cloud. 06 The business case for cloud

11 A further consideration arises from the speed with which some Cloud services can be brought into operation. Where it once took, say, eight weeks from getting the capital approval for a new server to when it is up and working, that might now take as little as eight hours. Will the business be ready to use it in that time to generate benefits or will this just bring IT expenditure forward by two months? 2.9 SUMMARY There is no doubt that the Cloud offers some new options for the provision of IT services which appear to be financially attractive where basic office functionality is all that is needed. As with all IT solutions, as needs become more sophisticated then complexity and costs increase. While aspects of the Cloud business models can benefit from economies of scale, this is typically achieved through simplification and standardisation. This reduces the entry cost for some applications but puts the onus back on businesses to conform, at least when interconnecting services, with pre-set vendor interfaces and configurations. Lower running costs are not the whole picture as explained in Section 3 What remains the same? The business case for cloud 07

12 3 WHAT REMAINS THE SAME? Decades of experience with the provision of IT services has shown that certain management practices have to be applied to every service if it is going to be fit for business use. In the context of Cloud services this implies, at least, that the following are needed: A specification of what the service is to provide and how it is to interface with other Cloud and non-cloud services. Quotations for a number of vendors offerings and evidence of their competence. Understanding the costs involved and the benefits which can be expected. A contract saying what the supplier is to provide to whom, at what cost, and what happens if things go wrong or are to change. A plan to transfer from the current service to the Cloud service. A process for how problems get fixed and changes made. A method for keeping track of what payments are due to the supplier. A business continuity plan for coping with disaster situations, like the supplier failing. An exit plan for removing data and applications from the Cloud service so they can be used elsewhere, perhaps in other Cloud services. Very few of the above items need to be considered by domestic users of social networks. Such networks are just there, sitting on the Web and often only a user name and password are needed to make use of them. Occasionally there are outages and security issues but digital natives have become inured to them. From a business perspective, every one of the above bullets needs management attention and has costs associated with it which increase with the size and complexity of the services sought. They all need to be considered in business cases for Cloud, see Appendix C. Each of the above bullets is examined briefly below. In reality, there is much more to consider than space allows in this guide and specialist service, commercial and legal advice might well be needed in addition to that offered by your own procurement and contract specialists. 3.1 CLOUD SERVICE SPECIFICATION While one of the characteristics of Cloud is the provision of standardised services with the same being offered to all customers to keep vendors costs down, the same does not apply when multiple Cloud services are to be used, especially if they are interdependent eg, they share data or they need to link up with IT services still run in-house or elsewhere. With more than one Cloud service, it is necessary to consider how data will be shared and what sorts of interfaces can be built between the services, what those interfaces will cost and who will support and maintain them. Synchronising data also needs to be taken into account as does passing data from one to another. Case study A Cloud application for dealing with suppliers was acquired by a purchasing function without consulting IT why did they need to as the application was hosted in the supplier s data centre and worked over the internet? This acted as a diary and workflow system to keep track of deadlines and suppliers were required to enter their proposals and quotations in a particular format. Unfortunately, the format of the downloaded data was incompatible with formats used by the business functions who needed to review the suppliers responses. It became a manual task to transfer data to and from the Cloud application, so eliminating all of the benefits of using Cloud services and, overall, increasing costs. 08 The business case for cloud

13 A number of key lessons emerge from this case study. For example, a master plan is still needed for how IT is to be deployed and to whom, who needs to be consulted about the way it is going to be used and the extent to which the users can rely on it. It can also be very frustrating trying to obtain detailed descriptions of the facilities that Cloud vendors are offering. Typically they might refer you to a set of links to their websites. There you might find outline descriptions with no authoritative document numbering and change control. Tomorrow those links might not work or might point to completely different documents, so how would you prove to the vendor that its service was not conforming to specification? The only way some services can be understood is by actually using them; this can significantly extend any evaluation, as you will need to describe and prioritise what you want and compare that with what you experience. 3.2 PLETHORA OF VENDORS There has been a veritable cloud burst of vendors raining down on the market place. They offer a multitude of different services and putting all the bits and suppliers together can be like assembling your own car from a collection of spare parts, with you having to draw up the design and getting it through the MOT. Further, as with any new line of business, many of them are very small and will eventually either cease to trade or be bought up by larger players. This is a key gamble when considering business use, especially, if they have all of your data when the administrator is appointed or your access to the services you have purchased may simply be turned off. It is also vital to understand how competent these suppliers are. In many cases it has been their customers who have made the vendors services roadworthy as the vendors might be focused largely on the underlying technology, not the business use of it. 3.3 UNDERSTANDING COSTS AND BENEFITS The starting prices might appear to be very attractive as little as a few pounds per month per user. As discussed in Section 2 What is new about the Cloud? these figures have been achieved by vendors stripping everything back to common denominators and spreading fixed costs over millions of customers. But these charges are usually only part of the costs which need considering, as indicated below (and see Appendix C for further details). The internet is awash with white papers setting out so-called business cases for various Cloud solutions. Many have been written by vendors and some by industry watchers who have been paid by vendors. Typically these cases compare the running costs of Cloud services with the running costs of pre-cloud services and ignore the procurement, contracting, set up, transition, service management, business change and other costs which, depending on the Cloud solution and buyer, can amount to more than the savings in running costs over many years (see Appendix C for more details). The extent of the benefits which can accrue depends very much on the size and nature of the business considering Cloud, the complexity of the IT it needs and its dependence on it. Relatively small businesses might be able to free themselves of many of the IT issues which have beset them for years, like finding someone whom they trust to fix the IT and undertake upgrades when needed. Such organisations can save expensive floor space, effectively rent services for relatively short periods without having to expend capex and have IT facilities available to them which only large organisations could previously afford. Larger organisations now, with Cloud, have another route by which the business functions can be provisioned quickly with new IT capabilities. This might allow the IT function to get more done for them without significant extra cost or additional headcount. Large organisations might have very complex IT facilities with multiple interconnections between various systems. As the number of interfaces increases with the square of the number of systems which need to be interconnected, adding multiple Cloud services might give rise to a significant number of technical challenges and extra work to maintain them. Where traditional outsourcers currently provide end-to-end services and manage all the many sub-contractors, a key issue is whether the incumbent outsourcer is open to replacing some of its services with Cloud services. For example, moving into the Cloud (effectively to a competitor) might leave the outsourcer with surplus staff and equipment. How is it to cover those costs and make up for the future loss of profits it was expecting to achieve? Again, you might need to take more control to make such changes happen. The business case for cloud 09

14 3.4 CONTRACTS Whenever payment is involved between independent parties, some form of contract needs to, or will, exist. At one extreme, you might just tick a box on a website to say you agree with the vendor s terms and conditions, but do you ever read what they say? Who owns your data and derivatives of it, who has the copyright in what, what redress do you have if the service is down, for what is the vendor accepting liability, what can you use its site to do, are you subject to English or a foreign law? You should print off the contract and get an expert to read it and let you know how you, your applications and your data stand. Don t forget, vendors versions of contracts have been written to protect their best interests and might not mention things which are important to you like how quickly problems will be fixed and other service levels eg, for making changes and getting queries answered, and what refunds you will get for poor service. When service levels are mentioned, be sure to understand how the vendor calculates its performance against them and how you can verify them. Be very careful about what these contracts do not say, seek help if needed. At the other end of the spectrum, you might need a contract tailored specifically for you and the services you are seeking. However, you might find that you cannot contract directly with the provider of the services and so need to go through an intermediary who might or might not understand the contract between it and the ultimate supplier. This can result in contract drafting and negotiating costs of the same order, if not greater, than traditional outsourcing, perhaps running into hundreds of thousands of pounds or more but typically for services which are much smaller in scale, scope and/or value. Another factor to consider here is the number of parties with which you might need to contract, each having its own starting points for drafting and negotiations. The complexity of the service which you are buying is just a small part of such contracts. The greater part of these contracts needs to cover what happens if there are problems or changes to avoid future disputes about what you and they should be doing. 3.5 TRANSFER TO THE CLOUD Today, all your services might be in-house but you want them running from the Cloud in the future. How do you get your data and applications out there, who can help and what happens to who and what are left behind? A very useful characteristic of many Cloud services is that at very low cost it is possible to try and buy. That means, for example, you could sign up for a few mailboxes and test them out by transferring dummy s to them and checking the functionality provided. With such a pilot, you can get an idea of how much work is needed to migrate to the Cloud and how much effort users will need to devote to learning how to use it and familiarising themselves with any differences compared with the current services. It would also be worthwhile going through the full life cycle of mailboxes, from setting them up to emptying them out and closing down the accounts and restoring the data in your current mailboxes. If you do not do this, how will you know that you will be able to move away from the vendor if the need ever arises? Compared to transferring to traditional outsourcers, it is worth remembering that true Cloud service providers will not want to take on your surplus staff, your old equipment, or your thirdparty contracts. This means you could incur redundancy or re-training costs, profit and loss writeoffs and contract termination costs which would not have arisen with traditional outsourcing. It is worth bearing in mind that these services are out there and you need to get to them. This might involve you in determining your network connectivity requirements and paying for help from your existing providers or a partner of the Cloud supplier to get you there. This will need running as a project with a number of suppliers involved (and your own staff) who you will need to manage and between whom you might wish to establish procedures to ensure roles are clearly defined. Another area worth checking out with the try and buy approach is how to use any portals through which you might communicate with the supplier and what information you will receive, perhaps via special feeds, about the quality and quantity of services provided to you; information which you might need to claim refunds for poor service or to identify where a problem lies eg, with the Cloud provider for that service or elsewhere in your infrastructure. 10 The business case for cloud

15 3.6 MANAGING THE CLOUD SERVICE A characteristic of many Cloud services is that they are self-service. If you need information about the service being provided you might need to go to their portal and download the details you are seeking. If they are not there you might not be able to get them in any form. Further, if you are likely to need the equivalent of a helpdesk to deal with queries, problems and changes, you might need to provide that facility yourself or contract with a traditional outsourcer to provide it. Some changes can only be made by gold partners of service providers, so you might have no choice but to engage one of them. Don t expect to have a named personal contact at the vendor. An advantage often voiced for the Cloud is not having to worry about any of the underlying technology, that the vendor will keep it refreshed and apply updates and fixes eg, security patches. This is fine so long as the vendors actions are not apparent or the changes benefit you. But some changes which you will not be able to stop them making might cause you suddenly to have to change the ways in which your people work. It might even be that the change will actually cause you to want to change suppliers, for example a change to a virus software package with functionality that is no longer acceptable to you. You also need to make arrangements to deal with problems arising between vendors caused by mismatches in setups or other incompatibilities of operation. Such issues might be no one s fault; the services may just be evolving in different directions. It is down to you to sort out such issues and because much of these standardised services is under the covers, it might not be at all obvious where to start. If the vendor is using proprietary software and proprietary database structures, you need to think about their auditability. What audit software can you run to verify that the transactions were processed as they should have been and, if you want extracts of data, what information will be provided with that data to give it meaning? These arrangements need to be incorporated in written contracts just in case your favourite vendor gets taken over and you later need to establish your rights with another party. 3.7 FINANCIAL MANAGEMENT An expression frequently used with Cloud is: pay-as-you-go ; but what exactly does each vendor mean by this? For example will you only pay for what you have used, like electricity, or does it mean you pay on the basis of what is available for you to use, like a non-cancellable flight ticket? The difference is, with the former, if you do not use it you do not pay for it but with the latter you still pay even if you do not use it. Another variant is an annual subscription, say per user. What happens if you want to change the user eg, can, say, a mailbox be emptied (but to where?) and then reassigned to another user within the same subscription or do you need a new subscription for the new user and will you get a refund on the partial use of the first mailbox? What happens when you get to the end of each year; can the vendor then unilaterally change the annual price and/or terms and conditions? Annual subscriptions might be superficially attractive, but you will need to understand such things and keep track of all the subscriptions in case any expire and the vendor deletes your data. Hardware and software inventory and configuration management might be service management processes that are simplified in the Cloud but subscription management replaces them. 3.8 BUSINESS CONTINUITY PLANNING Two virtues expounded by vendors of certain Cloud services is that their storage is now so cheap that you never need to waste time deleting anything and they are responsible for taking backups. This might be good news for day-to-day operations but what happens if the vendor goes out of business or its data centre suffers a major disaster? How do you then get your data back, what disaster recovery facilities do they have available and how long will it take them to get your business up and working again? The security arrangements and resilience of many Cloud data centres are claimed to be far superior to the vast majority of in-house facilities but that does not necessarily stop glitches arising from time to time. Business continuity plans are still needed for services in the Cloud to minimise the impact on your business and due diligence is required to validate the claims of the Cloud providers. Such data centres are also hailed as greener, being based on newer, more compact technology in environments optimised to reduce carbon footprints. However, calculations of energy cost savings frequently result in non-material sums. The business case for cloud 11

16 3.9 EXIT MANAGEMENT Under 3.6 Transfer to the Cloud it was mentioned that before getting into a Cloud service it is well worth (through try and buy or a pilot study) verifying that you can get your data and software back out in a timely fashion and in a form which you can continue to use, either in-house or to pass to another vendor. This is particularly important if the Cloud service uses proprietary software and database structures. Take care that not only can you extract your data but that you can automatically reprocess those extracts so they can be replicated in a replacement system without loss of data and without considerable effort. At present there are probably more tools, both chargeable and non-chargeable, to automate processes to migrate to the Cloud than to migrate from vendors or between vendors. Make sure that you only enter two-way streets. Key information to ensure that you can exit smoothly will include having sufficient details about your use of the services, key functionality on which your users depend to do their work, volumes etc. to allow you or another vendor to price an alternative service. You also need to understand notice periods, especially for automatic data deletions, and when payment periods end, as well as what no charge (and chargeable) assistance you can call upon. It is highly advisable to have an exit plan to go alongside the business continuity plan SUMMARY Cloud might appear low cost and easy but the extent of the work needed to assess, contract for, transfer to, manage and exit from Cloud services depends greatly on what is to be put out in the Cloud and its importance to your business. It is not as simple as a domestic user signing up to and using a social network. There can be some significant management challenges. See Appendix A for more information about Cloud and Appendix C for a checklist of information which you might wish to consider in making a business case for moving into the Cloud. 12 The business case for cloud

17 4 CONCLUSIONS This guide has attempted to draw together the digital natives and the digital migrants to consider the new options which the Cloud might be able to provide your business and the management considerations which have emerged from early adopters. There is still considerable sales hype about what the Cloud can do and frequently the lessons have had to be learnt the hard way by actually getting into it and using it for a period of time. First consider the following points: Where you are in the life cycle of the equipment and software you are currently using. When will it need to be refreshed/upgraded and/or be written off? Other than what you carry around, do you need any server equipment on-site eg, because you want to control backup copies? Is your internet (fixed, and where needed, mobile) speed and reliability sufficient for your business to depend on it? In order to meet your business requirements do you need devices which can be used both on- and off-line? Is the software you are using just the same as that used by millions of other people? If so, this or something like it has probably now been commoditised in the Cloud. Could your main financial, customer management, HR, procurement and other general business software be replaced by one or more Cloud providers running, supporting and upgrading its packages at its premises? Is recently created software which gives you competitive advantage ie, few others have anything like it, really paying its way and does putting this software out in the Cloud mean you can reduce running and support costs if you do not need it outside of business hours? Seek advice on whether it is technically feasible to run old software which gives you competitive advantage in the Cloud without rewriting it extensively. Re-read the Guide to Business Cases and The Business Case for Cloud to determine whether or not you can make a case for moving to the Cloud. Understand both the positive and negative aspects of moving to the Cloud and beware of anybody who is very enthusiastic either way. If the Cloud looks worth pursuing, try it out in a small way to understand what is involved in moving there and whether the business case needs revising from your experience. It is early days and lessons are being learnt by vendors, users and advisers every week. If in doubt, seek help from someone who is impartial and can draw on their real-life experiences with business uses of the Cloud, not just their personal domestic use. The business case for cloud 13

18 APPENDIX A: ICAEW AND OTHER SOURCES OF INFORMATION ON BUSINESS CASES AND CLOUD Chris Tiernan (2010), Guide to Business Cases Increasing Value from Investments, London: ICAEW. Chris Tiernan (2012), Will the Cloud kill capex? Chartech, May/June 2012: ICAEW. Barnaby Page (2010), Cloud Computing A Guide for Business Managers, London: ICAEW. IT Faculty (2011), Building Trust in the Digital Age: Rethinking Privacy, Property and Security, London: ICAEW. Dr Mark I Williams (2012), Making the Move to Cloud Computing, London: ICAEW. IT Governance Institute (2008), Enterprise Value: Governance of IT Investments, The Val IT Framework 2.0. Rolling Meadows, IL: IT Governance Institute. 14 The business case for cloud

19 APPENDIX B: ECONOMIES OF SCALE HOW SIZE MATTERS Economies of scale are frequently mentioned in the context of the Cloud. It is very important to understand how and when they apply to determine if they will benefit you. The IT and telecommunications industries have seen many examples of the benefits of economies of scale. Without them we would not be able to make telephone calls for pence, acquire very sophisticated desktop software for a few hundred pounds or immensely powerful equipment for less than a thousand pounds. All of this happened because some very far-sighted individuals gambled on there being huge demand for these goods and services. They were prepared to invest, on a massive scale, in infrastructure, software development and manufacturing facilities. Fortunately, for both the investors and us, the demand was there, so we all benefited. IS SIZE SUFFICIENT? Is size alone sufficient, or are there other factors at play? When do economies of scale arise and how do they change with volume? By economies of scale most of us mean that the individual unit cost of something decreases with increasing quantity. An example would be paying less than twice as much for double the quantity. Suppose a call centre uses a call management system which costs 100k pa and each operator with his or her screen costs 20k pa. We can plot the total cost of the call centre as the number of staff increases (Figure 1). We can also plot the total cost divided by the number of staff to obtain the average unit cost per person (Figure 2). The second graph is the more interesting. As the number of staff increases from one to five, there is a dramatic reduction in the average unit cost. Between five and 10 staff, it still falls, but much less rapidly. Above 10, the average unit cost falls only very slightly, even for much larger numbers of staff. So, we might talk of economies of scale between one and five, or even up to 10, staff but, above that, any economies of scale are barely noticeable Figure 1: Total cost ( k pa) Figure 2: Average unit cost ( k pa) WHAT IS HAPPENING? The reason for this is that when that part of the total cost which does not vary with volume (the call management system) is divided by the number of staff using it, it becomes an increasingly less significant contributor to the average unit cost. Meanwhile, the 20k pa unit cost per person does not change as the number of staff increases. Hence, the line levels off towards 20k pa. So economies of scale do not go on forever. They eventually peter out. Size matters only up to a point. Thereafter it makes a non-material difference. The business case for cloud 15

20 INCREASING ECONOMIES OF SCALE What do we have to do to get further economies of scale, say beyond 10 staff? Notice the staff cost was the limiting factor above. We need to make each person more productive. Another organisation has a 200k pa call management system with which its staff can each handle twice as many calls as ours. We can overlay their situation on our two earlier graphs to give us Figures 3 and 4. (The x-axis takes as its unit the workload one of our people can handle.) Figure 3 shows that the crossover point at which the other system becomes less expensive is equivalent to 10 of our people using the current system. If we are expecting volumes to grow above that, the other organisation s approach would be less expensive as productivity would be higher Figure 3: Comparison of total costs ( k pa) Figure 4: Comparison of average unit costs ( k pa) EFFECT ON AVERAGE UNIT COST But what would be the effect on average unit costs? Figure 4 shows they would be marginally lower with the more expensive system ( 25k pa becoming 20k pa) at 20 of our people and somewhat less ( 23k pa becoming 17k pa) at 30. So, although productivity has doubled, unit costs have only reduced over this range to some 70-80% of what they would be on the less expensive system. Further, if we moved to the more expensive system but then volumes declined, average unit costs would actually be much higher than on the less productive system, even if we adjusted staff numbers to match the new workload. We would travel left up the higher curve in Figure 4. CONCLUSIONS So what do we learn from this? 1. Simply increasing volumes does not necessarily give us any economies of scale. 2. The shape of the curve for each situation needs to be understood to determine in what ranges economies of scale apply. 3. We need to understand our position on the curves and where we expect to move in order to determine whether economies of scale apply to us. 4. Economies of scale eventually peter out close to the variable element in the cost. 5. In order to achieve economies of scale beyond point 4., the variable element has to be reduced which might involve investing in more productive tools (take care to check points 2 and 3 again). 6. Unless volumes increase substantially after such investment, the reduction in average unit costs is likely to be small compared with the investment and productivity increases. 7. If volumes then fall, average unit cost will be greater than if the investment had never been made. So, we cannot expect economies of scale to apply simply because volumes grow, or we aggregate workloads through consolidation of different internal groups or aggregate our workload with other customers of a Cloud services provider. We need to understand each situation as it applies to us. 16 The business case for cloud