 Welcome to our webinar about public cloud understanding the business case and accounting implications. I'm Louise Wayne, I have a background in finance. I'm Julian Dickby, I'm a Solutions Consultant at Edison, generally helping our customers in their migration towards cloud solutions. During this webinar we aim to give you a better understanding of cloud, accounting for cloud, the total cost of ownership, the value proposition and changing behaviours to optimise cloud usage models. There's an opportunity to ask questions and we'll have a look at those at the end. Say some background, back in 2013 the government launched a cloud first policy around the adoption of public cloud and software as a service. Cloud adoption within the public sector is still behind the private sector as there are many concerns. The skills gap is a factor with a recent study showing that 36% of government workers haven't yet used cloud services. Security is of paramount importance, with many using this as a main concern. However the latest guidance highlights that security within the public cloud is often superior to other alternatives. This is underpinned with the recent announcement that blue light services can use public cloud. So the data held by police, ambulance fire and the Coast Guard can be stored in public cloud. This really supports the journey of travel and Gartner predicts that by 2020 having a corporate no cloud policy will be as rare as a no internet policy is today. The cloud economics, number two main drivers, there's a significant drop in capacity hoarding. When you have your own data center, racks run at 75% capacity to allow for scalability. So this means there's usually a quarter of your capacity wasted. In public cloud you match your cost with your usage. It's a pay-as-you-go model that scales depending on your demands. Within public cloud the main players are Amazon web services, Microsoft Azure and Google Cloud. So the second cost driver is lower unit costs. These major players offer increased scale, newer technologies, best practices and improved operational efficiency. These really are the best in-class infrastructure, SLAs and resilience. You're transferring the risks so you can focus on the core activities of your organisation. For example, if there is a heat wave it isn't your responsibility to ensure that the data center is called sufficiently. That's all with the public cloud provider. Let's have a look at an example. The comic relief, they use AWS. So we know comic relief for the Red Nose activities in March and they have an evening of television dedicated to raising donations for the cause. You'll see in this charts there's a two hour window during the evening when donations per minute peak. If they were hosting this on their own infrastructure they would need capacity to be able to deal with this level of cause. In AWS it isn't a problem and they simply pay for this doubling demands for the two hour window. So this is a great example of an organisation getting the most from the scalability of public cloud and not over-purchasing on-premise kick to allow for peak time capacity. So now we're going to have a look at some of the financial blockers we hear about. Now some of the terminology I use may be new or not relevant to your sector. However, a general understanding of the key accounting terms is really useful. So when you're talking to other stakeholders or other people who work in different industries and sectors you have a common understanding of the concerns. The CAPEX versus OPEX. The CAPEX is why you buy a fixed asset. Someone is going to last you several years and the cost is spread over the useful life of the asset in the form of depreciation. So this comes from the accounting principle of matching. So you're spreading the cost over the period of benefit. So on-premise this is things like hardware, storage, networking, software licensing, implementation and the cost is spread over the life of the asset. So for example if you buy a server and you have a depreciation policy of five years for service you'll see a fifth of that cost over the next five years feature in your costs as depreciation. In public cloud there's a shift from CAPEX to OPEX. So OPEX, Operating Expenditure. This is the ongoing cost for running your business. It impacts the expenditure in the current financial year. On-premise this is annual support and maintenance, power cooling, facilities, staff costs. In public cloud this is everything. The infrastructure, the cloud services, software licensing, staff costs. Now you've probably heard there's a real appeal for people to spend CAPEX. It's often easier to spend CAPEX in an organization than OPEX. Why is this? What is the appeal of CAPEX? Well owning assets make your company more valuable. It can be used as collateral for financing. And assets can be sold if cash is required. Now in some sectors you may not be aware whether you are spending OPEX or CAPEX. But what you do know is you're paying a supplier for goods or services in the form of cash. So cash are the funds you use to pay for these goods and services. On-premise this cash flow is spiky because of the unpredictable hardware purchases and annual licenses. You can't always predict when your service is going to break down and need to be replaced. In public cloud it's much steadier. It's a payment-fully based on consumption model. Let's have a look at an example. So this will be an example profit and loss account. I appreciate in some sectors this isn't represented as a profit and loss account. But for completeness we will include income. So a profit and loss account starts with income and then it takes into account the expenditure items. So here we have IT costs as one of the items of expenditure. In this example we're seeing the IT costs increase. Because in public cloud as we mentioned earlier there's a shift from CAPEX to OPEX. In this example are the costs of remaining static which gives you total OPEX. So total operating expenses increasing which is because the IT costs have increased. Now when looking at profit and loss accounts you have your net income. You take away your OPEX and that gives you a profit or loss. In this example we're calling that EBITDA which is the general accounting term. This is earnings before interest tax depreciation and amortisation. So you will see this has gone down because the IT costs have gone up. Now remember this was before depreciation and we said earlier there's a shift from CAPEX to OPEX. So when you include depreciation here for simplicity we've got depreciation going down by the same amount that we saw IT costs going up. So after including depreciation you get EBIT which is earnings before interest in tax. And you'll notice this is exactly the same in both models. So what we've seen is the shift from CAPEX which causes depreciation over the life of the project assets and an increase in IT costs. So EBITDA, EBIT does it really matter? Well in some industries and locations it does. In North America it is very significant as it is in many PLCs. So why is this that analysts and investors use EBITDA to measure trading performance? Because depreciation is outside of this measure and depreciation doesn't really measure trading activity. EBITDA is the main focus when looking at trading profitability. So things like bonuses may be on EBITDA growth or EBITDA as a percentage of income. And so it does get a lot of focus. And what we don't want is people adjusting the costs to negate the increasing IT costs. Or we don't want inappropriate procurement behaviour to try to manipulate these figures. What we need is for everybody to understand this bigger picture and to understand the shift between CAPEX to OPEX and the implications that has on depreciation and the profitability measures. And underlying cash is key. So now we're going to have a look at some accounts that see myths. So we've heard things like reserved instances can be capitalised. That is a myth. Also dedicated hosting can be capitalised. That is also a myth. Whilst in these instances you are signing up maybe for a longer period, you don't own the underlying infrastructure so it cannot be capitalised. Another myth is that consultancy, project management, training costs or relating to cloud migration can be capitalised. This is a myth. These costs are not attributable to acquiring or constructing an asset. Cloud will be capitalisable in the future. So will it be treated as CAPEX? No, that is also another myth. Now it is true that the accountancy bodies in the UK and the US are looking at the treatment of cloud accounting. And there's a new accounting standard coming in 2019, IFRS 16 lease accounting. At the moment there isn't any guidance on this that can be shared. So it's always best to speak to your accountants. So cloud is a lot less expensive or cloud is a lot more expensive. For this we will look at TCO which is a total cost of ownership model. So this model provides the solution with a higher value over time. It looks at how organisations can change the way they do business. So a TCO is often done for a three to five year time frame. But the benefits increase over time due to the learning curve for innovation and optimisation. What are the components? On-premise is the operational costs and the acquisition costs, the cost of buying it. In public cloud the main cost drivers are storage and compute and data transfer. So some checklists. So include the cost of service, storage, networking, IT costs, power and cooling, facilities costs. There's also some one off costs. So you'll need to write off the network value of your redundant assets once your kit has been decommissioned. In public cloud there's some optional extras for example, whether to outsource to a managed services provider. The benefits of this is expertise in your market. They will provide an ecosystem of related products and services. They'll offer billing flexibility because they will provide your bill rather than the cloud provider. There'll be your main point of contact and keep you informed of the evolving technology. This means you can focus on your core activities. So we should always look at the value proposition. So that following areas should be included when presenting your value proposition of moving to cloud. It is about the business outcomes. And you will notice many of these are non-financial, enabling the organisation to be better positioned to achieve its objectives. So platform breadth and global reach. Businesses no longer have to manage their own infrastructure. Instead you can build sophisticated scalable applications and have resources to run any workload from a platform that offers extensive services, features and geographical locations. You'll have superior reliability in high performance and sustainable and scalable IT. There's favourable economics as we've just mentioned and operational efficiency so you can instantly scale up and down. This leads to improved agility and pace of innovation. So overall this means that you can focus on your core activities rather than the infrastructure. And experimentation is easy to do at little cost. Really the risk of not moving to cloud is the opportunity cost to the organisation resulting from a lack of speed and agility. So what does this mean for IT leaders? We need to communicate the strategy to explain the shift from CAPEX to OPEX. We need to raise the understanding of the financial implications to ensure the right decisions are made and we should always be led by what is best for the organisation and encourage closer working between finance and IT. Finance has to know IT and IT has to know finance. That seems a good place to hand your over to Julian from IT. Thanks Louise. Good morning everyone. I'm going to talk you through some of the potential financial benefits of public cloud that can be initially overlooked. As an introduction it's worth considering the different models of the public cloud service. In particular who has management responsibility for the different tiers of the ICT stack in each of the different models. For on-premise infrastructure your organisation has responsibility for the full stack. Infrastructure as a service provides responsibility or moves responsibility for servers, storage, networking and the virtualisation solution to the platform provider. Infrastructure as a service is available with an additional managed operating system service through managed service providers. This will include patching, backup, AV and other OS maintenance. Platform as a service additionally provides management of middleware and runtime. As an example a database service where you are responsible only for the data and not the underlying database software. So someone providing the actual managed SQL server instance as an example. Finally software as a service provides you with a fully functional and managed application that is ready for use by your organisation and you have no involvement in the management of that application at all. When it comes to evaluating the financial benefits of moving to the cloud the initial focus tends to be on the cost of running servers in the cloud versus running them in on-premise data centres. This excludes the benefits of transforming your ICT by making use of multi-talent cloud solutions. So services not servers. When server virtualisation became the established approach within data centres, functions that were once installed on a single server tended to be split out into multiple servers due to the ease of deploying additional virtual machines. While this was a step forward in resilience and configuration management it brought with it the need to manage many additional servers and copies of operating systems. The move to the cloud can reverse this trend through the use of multi-talent services where the platform provider looks after all the underlying infrastructure including the operating system and core applications. For example, where you currently may have a Windows web server farm hosting a range of web-based applications you could elect to deploy your code to a web application service with no requirement for you to manage the web server operating system patching, backup, antivirus etc. What is more, the server farm could be scaled out and in automatically without any additional overhead for your team. The use of containers, for example docker technology is another way to add agility to your applications, prove compute resource efficiency and reduce the overhead of server management. This approach has been taken a step further with serverless technology that allows you to simply submit code to be executed and pay only for the compute time that it takes. It can be hard to quantify the financial benefits of such platform as a service model as the level of transformation of applications into this model that is possible can be difficult to determine. This should be part of an initial analysis of the candidate applications for moving to the cloud. Ultimately it will be a key element refocusing your ICT team on projects that differentiate your organisation. In addition to transforming applications there are a range of benefits within infrastructure as a service and cloud platforms that are realised by changing behaviours related to server infrastructure. With an on-premise data centre, compute resources are bought and paid for regardless of their level of utilization therefore certain behaviours have no benefit. For example, reducing the resources provided to a virtual server that is over provisioned won't reduce costs nor will powering off servers when not in use. In the public cloud pay for what you use model both of these can deliver significant savings. Monday to Friday 8am to 6pm is only 30% of the hours in a week so significant savings can be made by powering down unused infrastructure outside of the core hours. Scaling applications to meet increased demand requires the upfront purchase of computer hardware to cope with peaks even though it may be hardly used to its full capacity. This can be a significant cost burden for data centres running spiky workloads. In the public cloud you will pay more when you use more but only when you use it. Public cloud IS also provides a great jump off point for further evolution of your ICT service. As you make more use of past services for example your databases, your IS costs will reduce in the public cloud. In the on-premise data centre little savings achieves until the next infrastructure buying cycle meaning there is a period of paying double for the migrated service. The same applies to applications migrated to or being replaced by software as a service. Collectively these examples show how the calculation of the cost of running your current infrastructure in the public cloud is only really an initial estimate and will not demonstrate the potential savings delivered by the cloud provider's massive economy of scale. I'm just going to hand you back to Louise for a summary. Thank you. So the key messages are public cloud is becoming the norm. This does mean a move from CAPEX to OPEX models and the EBIT, EBITDAR impact around the profitability measures needs to be understood. TCO model is great for looking at the longer term value proposition. Always look at the bigger picture and understanding how to get the best value from public cloud. Are there any questions? I see we've got a question here from Dan around is it best to do a big bang migration or move with agile smaller projects? Yes. So it depends on what your key driver is for your cloud migration. So if you have a compelling event that means you need to exit a data centre in order to close down a building or some other major change that means that you need to basically find somewhere new to host your applications, then it is possible to do a big bang migration to the cloud. The approach will more or less replicate your existing infrastructure in the cloud and that's the fastest way to deliver that really. If you have more time to think about it, a migration over a longer period of time on a case-by-case basis with some transformation of your applications as you go, that's a sensible way to approach that. So it's really a horses for courses depending on what your key drivers are. OK, so we've got another question. So as a finance professional, how do you sort of skill up and understand more about the cloud? That's a good question. So from business partnering with the IT professionals, you can gain a lot of knowledge. Also the public cloud providers do also offer training. So there's a lot of training online. So I can recommend some of those if anyone would like to get in touch after the webinar. OK, I think we're almost coming to a close now. So thank you very much to Louise and Julian. And we just let you know there's going to be more coming for finance professionals and also for IT professionals wishing to understand more about how finance can play a role in digital transformation and adopting the cloud. I think actually we've got one more question coming. So when purchasing SaaS, what are the key factors to look out for, i.e pitfalls? So I mean, is that something? So I'll take that one. So obviously the most important thing when buying a SaaS application is that it meets your requirements so having a good solid understanding of what you need is paramount really to finding the right product. What typically SaaS applications are very good at the moment for standard business operations. So majority of organisations, 80% of what they do with IT is pretty much the same as the 80% that other organisations do. And there's a small, maybe 20% of IT that's actually specialist that differentiates their organisation. So where you have a common requirements across different organisations, SaaS applications work really well because they're designed to deliver for everyone. One of the things I would say in terms of SaaS that's good to look for is something called the API. It might be getting a bit technical, but essentially with applications that you have in your data centre today, you have access to the backend database and it's common for people to run queries against that database and generally create many applications to support business services. And it tends to be a bit ad hoc but there's a general expectation that you can get hold of that data through that backdoor route. With a SaaS application, that's not possible, not accessing the database directly at least. So that functionality is generally replaced by an API which allows you to write your own applications to deal with data that you might have in that application. So really good SaaS applications have a really good API. It's well documented, it's secure and it provides all the functionality that you need. Less good APIs, not well documented, don't work very well and may not actually cover all the features that you need. So in your initial assessment of your requirements, it's worth thinking about what your future needs will be in terms of creating applications that talk to this SaaS service and making sure that the API that that organisation provides is fit for purpose. It might be something that they still have on a roadmap and you'll be able to make a judgement as to whether you think they're going to deliver an appropriate API in the long term. But those are the things that I would look out for. OK. OK, so we just gave you a few more comments coming through. Mostly thank yous, which is lovely. So thanks very much for joining us today and this recording will be made available and we'll be following up with all of the participants to share that with them. Thank you very much everybody.