The Four Ps of Successful Cloud Finance

Size: px
Start display at page:

Download "The Four Ps of Successful Cloud Finance"

Transcription

1 White Paper Professional Services The Four Ps of Successful Cloud Finance

2 Table of Contents page Executive Summary... 1 Pricing... 2 Planning... 3 Participation... 6 Processes... 7 Keeping It All Together... 10

3 Executive Summary In the early stages of cloud adoption, companies focused on topics such as the technology, getting up and running quickly, and cost reduction. But, as companies mature in their adoption of cloud, the IT teams that run private clouds are increasingly grappling with questions such as How should I charge for cloud services? Simply put, the answer is Charge like a public cloud provider. But, to answer in more depth, it s useful to take a step back and consider the real reason the question is being asked because there s more at stake than just rating and pricing. The recent explosion of interest in service pricing has come from pressure on internal IT in the form of competition from the public cloud. Now that there are service delivery alternatives, business units are forcing market economics onto IT: they want to choose what to consume from IT and pay accordingly. In this transition to internal market economics, IT really needs to become an internal business and behave like public cloud providers, not just in terms of speed of execution but also in terms of pricing and financial transparency. It is crucial to understand that while IT may not operate to actually make a profit, the internal market approach is identical to a for-profit business but with a margin target of zero. This paper examines how IT can succeed in this transition by considering four aspects that are closely linked the four Ps of hybrid cloud services finance: Pricing Forcing a fundamental shift in IT Planning Accurately anticipating demand Participation What services to offer (or not) Processes Transparent ordering and billing Figure 1. The Four Ps This white paper primarily focuses on providers of private clouds for PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), with limited discussion of other roles (brokers, resellers, and hybrid cloud services consumers) where particularly relevant. 1

4 White Paper The Four Ps of Successful Cloud Finance Pricing The idea of applying market economics to internal IT is not new. It has been discussed both within industry groups (such as the IT Financial Management Association) and the literature, yet implementation has been slow going and few have implemented true consumption based internal pricing. One factor that has stymied progress is the view that this is about consumption based cost recovery. This viewpoint obscures the issue because it implies that supply comes before demand. But if you really want to make market economics work, you need to shift your thinking: demand comes first, and pricing needs to reflect expected demand, competition, and where supply will come from for a given service. That said, pricing poses three basic challenges: method, supply, and rate. Method In a cloud context, the choice for the method boils down to subscription vs. metering. Subscription means that users pay for what they order, regardless of whether they use it. While it is the more straightforward option, it is less desirable in the eyes of the consumer. Metering means that users pay based on what is actually used in a given period. It is usually the preferable option but it creates two challenges: additional process complexity, and financial risk in terms of capacity. However, since metering is what state-of-the-art public cloud services providers offer, it should at least figure in your roadmap. Supply The key supply decision for internal IT here is whether to supply internally, to act purely as a broker sourcing services from the public cloud, or both. While this is primarily a participation decision (which will be discussed later), it does impact pricing in the following manner: If IT requires services from an external supplier to deliver its own services, the external provider cost is a direct cost element like any other, and therefore input to the rate that IT sets for internal customers. If IT is brokering services from external suppliers (i.e., IT is the conduit but not the provider), there are indirect costs to consider. As a service broker, IT is still accountable to the consumer and bears the cost of supplier management or value-added capabilities. For example, a hybrid cloud management platform that provides financial and service assurance aspects (such as data security, preventive maintenance, and monitoring) clearly incurs costs in terms of onboarding and operation, which need to be factored into the rate, either statically or dynamically (by means of a percentage uplift on the provider price). Rates As in any business, rates must reflect a view of demand, competition, and cost with the first two elements representing a fundamental shift of focus for internal IT. Many IT departments already implement chargeback mechanisms such as full cost recovery (covering items such as labor, management, and software/hardware depreciation) either on a project basis or as part of their annual budgeting process. However, market economics require a different approach in a number of aspects: 2

5 1. The rate must be set on a per-service or per-product basis, accounting for all of the components that make up the service: time and materials, design, construction, and operation. For each service, you must also define the units and packages for which you intend to charge. For example, monitoring a service might be an option that users choose, so you need to be able to define the cost just for monitoring. 2. The rate must be one that your customers will agree to pay. This means that you need to shift to a market-based approach: build to a palatable price not build and then price. You need to consider what external providers charge for a similar service. Even in cases where there is a corporate ban on using external suppliers, the very existence of known external prices becomes a benchmark that internal IT must consider. You need to determine whether you can actually provide the service at the same (or lower) price, or if not, offer differentiating features that justify your higher price. You need to consider demand because your price represents full cost recovery, rather than marginal cost per unit. You need to have a good idea of how many units you are likely to sell to be able to price a single unit in a way that overall recovery will match overall costs. This is why planning for demand and capacity is critical. 3. If you are going to provide cloud services externally, you may want to consider dynamic pricing such as customer-specific prices, service bundles, and trial-period discounts, as well as the ability to vary price on a frequent basis based on market conditions. Planning Cloud makes on-demand provisioning a reality, but this brings with it inherent capacity management risks: how can IT cope financially with the need for instantaneous supply? Mitigating Two Types of Risk There are two distinct risks that planning can mitigate: Providing capacity for instantaneous supply (capacity risk) Appropriate cost recovery (cost-recovery risk) The capacity risk is a direct result of the IT transition from cost center to demand-driven internal supplier. This transition removes the protective wall of the IT budget, since we have no budget can no longer be used as an excuse. To even contemplate providing the variable cost that the business is looking for, IT needs to be able to flex up and down based on what the business orders, and can t say we are sold out when the budget limit is reached. Nor can it revise prices upwards if the business wants to use less than expected. The cost-recovery risk comes from the move to a per-service, per-unit cost-recovery method. There is no guarantee that the cost assumptions used to set rates will accurately prove true. For example, if expected demand does not materialize, costs per unit will increase. In fact, you are unlikely to achieve a profit and loss of exactly zero through unit-based charges alone. 3

6 White Paper The Four Ps of Successful Cloud Finance There are two approaches to mitigate these risks: 1. Implement financial mechanisms to share the risk with internal customers 2. Reduce the dollar amount at risk, because it reduces risk for the enterprise as a whole Financial Mechanisms TRUE-UPS A true-up mechanism enables enterprises to implement a zero-cost IT function, where all costs must be recovered from business units. If, by the end of the financial period, business units have paid less than the total IT costs, they are still charged the difference. For example, if the difference is small, you could simply apportion it between your customers based on their share of the total IT cost. BUDGETS AS FRAMEWORK CONTRACTS It is common in a B2B context to establish volume contracts, which then get drawn down over a period. An internal demand budget can work in the same way and allow both parties (IT and business units) to share the risk. Business units need to commit to a certain initial volume, and in return can lock in the price for the total volume. This should result in more accurate estimates that will give IT some level of certainty of projected demand. Joint capacity planning is required for this method to work, and the contract or budget will likely need periodic review to allow for adjustments based on actual demand. A PHASED TRANSITION FROM SUBSCRIPTION TO METERING When considering forecast vs. actual demand, you can apply a third financial mechanism to ease the capacity-risk challenge of moving to metering-based services. In a subscription-based model, users in the business may well order and pay for capacity that they don t use. In the initial move to metering, you can maintain chargeback on a subscription basis while providing showback for metered services and you could offer auto-scaling services that minimize consumption automatically, which lowers cost for the enterprise as capacity utilization is improved. This way, the business users still retain a share of the capacity risk, but in return get the information they need to better manage their total consumption. Lowering the Stakes The more important risk mitigation strategy is to reduce the dollar amount at risk. In essence, IT has to build a cost structure resilient to variability using numerous, well-established methods. MAKE YOUR CAPACITY RISK YOUR SUPPLIERS UPSIDE The best approach is to shift the capacity risk for both labor and infrastructure onto your suppliers. Labor: Each IT team can forecast for core demand, and prepare an external supplier to provide additional resources for peak demand (or if demand rises faster than forecasted). This buys time to hire and train, but more importantly, it creates a win-win as IT s contingent demand becomes the supplier s upside. Infrastructure: Well-established purchasing models allow IT to pay vendors only when capacity is actually provisioned, even if it is pre-installed in the data center. While it is trickier to scale back cost 4

7 if future demand decreases (a likely scenario for an unpredictable or cyclical business), certain vendors, such as Micro Focus now offer a flexible computing model that addresses even this issue. Naturally, it is always worthwhile asking vendors for any other creative solutions they might be able to offer. USING THE PUBLIC CLOUD Another approach is to use public cloud providers, precisely because they can provide true variable cost that internal IT may find hard to match. You should set policies to decide where workloads should run (public vs. private cloud) based on business differentiation, time to-market, security, service assurance, and cost. In general terms, these are the representative policy approaches: Maximalist portfolio In this approach, the default position is to run workloads in the public cloud whenever possible. This will generally reduce management bandwidth, capital expenditure, and fixed headcount, while also mitigating the capacity risk. However, defining whenever possible can be tricky, especially since variable cost (no CAPEX) is not the same as lower cost, and balancing price against risk and service level is essential to maintaining optimal service delivery. Optimizing use of public cloud, using cost and performance analysis tools, must become a core IT competence to be successful. Minimalist portfolio This approach is the opposite; namely, the default position is to run workloads in the private cloud because the enterprise sees cost, risk, and loss-of-control issues with public cloud, and so, as a matter of policy, restricts its use. In this case, there are two issues that need to be addressed with care, or this approach will likely fail in practice: Exception criteria for public cloud use must be carefully crafted so that business needs can still be met IT must be able to provide the velocity that businesses have come to expect from public cloud; otherwise, in time, business will likely circumvent or overturn the policy Choice per service In this approach, the decision of where to run a given workload is made separately for each business service based on policies related to business differentiation, data and process security, service assurance, cost, and time-to-market. To simplify the decision process, it may be decided at the enterprise level that a defined set of business services must run in a private cloud (for example, financial systems such as general ledger, accounts payable, accounts receivable), while each business unit can make its own decisions for the rest of the services they own. Choice within a service Besides these portfolio approaches to governing the use of public cloud by service or set of services, there are ways to use public cloud within a service, such as bursting or (re)designing an application to run with different tiers in different clouds. There is an important trade-off here between capacity and complexity. The complexity of application design, build, and management may outweigh the cost benefit of using public cloud capacity, especially when network costs are considered. So, while you should not ignore these options, you should fully cost them with care. 5

8 White Paper The Four Ps of Successful Cloud Finance In summary, all of the basic rules of forecasting and cost impact analysis apply to cloud financial planning. One important rule of thumb is the law of large numbers: The broader the usage, the more accurate the forecast. Therefore, deciding what cloud services to offer is crucial, which leads us to the importance of participation. Participation If the move to cloud means that IT really is acting like a business analyzing demand, setting market-based prices, absorbing financial risk then it must be free to make participation decisions as to what services it will offer and how, and it must make them with eyes wide open. What to Supply (Internal IT as Service Provider) It is a truism of automation that standardization should come first. This is particularly applicable to cloud for two reasons: 1. Cloud is the ultimate state of end-to-end IT automation, and design mistakes will be costly to fix 2. Accuracy of demand forecasting is subject to the law of large numbers, so providing widely used, standard services will make for a more accurate forecast In other words, offering cloud services should be a catalyst for standardization an obvious conclusion when the best candidates for shared resources are the most widely used ones. The opposite is also true: Resources not in high demand won t be shared much, and demand will be very hard to forecast. So, if raising utilization rates is one of your objectives of cloud adoption, you are much more likely to succeed if you pick services that are in high demand. We should note that there are services you will not want to provide as a cloud service at least not in a financial sense. For example, a business unit may use a particular technology that no one else uses, at low scale. They may want to use the benefits of time-to-market that cloud provides, but you may not be in a position to offer per-unit price. You can offer speed of execution but not a variable cost model. What and Where to Source (Internal IT as Service Broker) Next, you need to determine whether you can provide the service at the same (or lower) price than external suppliers, or offer differentiating features that justify your higher price. If you cannot, you may wish to broker service from an external cloud supplier (public or shared) instead of providing the service yourself. You also need to consider which of the aforementioned policy approaches you need to cater for. It may be that for specific types of service, policy will dictate that you need to offer the same service yourself, even if your price is higher. If you wish to act as broker, choosing providers is another important participation decision. As mentioned in the Pricing section, managing the suppliers from whom you are brokering services, especially in production environments, may carry material cost per provider for onboarding onto a brokerage and management 6

9 platform. In addition, external suppliers are not made equal in terms of offerings, service levels for security and assurance, and cost per unit, so assessing their fitness for purpose for your enterprise s demands is an important part of the sourcing decision. Processes Pricing, planning, and participation are mostly analytical in nature, whereas processes while still requiring deliberate and careful analysis have a strong execution ingredient that is technology-dependent and tightly coupled with cloud delivery. We can divide cloud finance processes into four stages: (1) Analyze, (2) Budget and plan, (3) Order and bill, and (4) Showback. They apply equally, but in different ways, at all layers business service, application, and infrastructure of an enterprise architecture. Analyze Budget and plan Order and bill Showback Figure 2. The Four Stages of the Process Model Analyze From a financial process perspective, the pricing, planning, and participation strategies discussed in the preceding sections are all part of the Analyze stage. It covers researching and deciding what to implement and how: what services to provide and broker, how to charge for them, and at what kind of rates. The subsequent stages are where all of these decisions are actually executed. Since cloud is so reliant on end-to-end automation, a large part of this execution is implementing (or sourcing) an automation platform such as a hybrid cloud management platform that provides the ability to execute the cloud finance processes. While implementing such a platform, avoid focusing so much on the implementation itself that you lose sight of the key goals set and decisions made at the Analyze stage. Budget and Plan SET UP PRICING RULES AND RATES The Budget and plan process sets up the pricing rules and rates in the platform, in preparation for consumption. Complexity will vary based on the situation. For example: For a purely internal provider, it may be a relatively simple approach of setting fixed prices for the financial year. 7

10 White Paper The Four Ps of Successful Cloud Finance If brokering external providers to internal users is included, a fixed percentage uplift might be applied. This will require more sophistication in the pricing engine of the hybrid cloud management platform. If external customers are to be served, more dynamic pricing may be needed, such as contractspecific pricing or context-sensitive discounting for volume, loyalty, or incentive periods. ACCOUNT MANAGEMENT: SET CONSUMPTION QUOTAS In both internal and external contexts, account management is required if you want to control consumption per consumer or group of consumers (e.g., a business unit) based on a quota, and track actuals to plan (the quotas forming the plan). For internal tenants, this is likely to be a budget quota, and for external tenants, a contract quota. Setting up the quota in the platform should be a similar process in either case and must be done before consumption can begin. This is, of course, an iterative process as quotas may change based on changing circumstances (e.g., increased demand). SET SUPPLY BUDGET While this is not a cloud-specific aspect, since IT like any other department has annual expenditure budgets, IT executives should look out for any material changes in the resource needs and sourcing mix necessitated by cloud. Based on your participation strategy, it is important to plan the supply flip side of potentially oscillating demand. Order and Bill This set of processes implements financial calculations and controls: the mechanisms you use to price services order-by-order, control the ordering of services (through either passive or active approvals), and produce the resulting billing advisory record. The Order and bill process relies on the ability of your hybrid cloud management platform to handle your process needs as defined in the Analyze stage, and then set up in the Budget and plan stage. As with many aspects of cloud, the process at this execution stage needs to be fully automated, such that you can produce an accurate billing advisory record based on the rates, rules, quotas, and consumption data without any manual intervention. THE PRICING ENGINE The pricing engine prices a particular order. Depending on your situation, this may range from a static application of a rate card (requiring only a database) to a dynamic, rule-based calculation of price, based on multiple context-specific variables (such as tenant, time, service bundles, and so on). ACCOUNT MANAGEMENT: QUOTA DRAWDOWN AND APPROVALS Quotas are set up as part of Budget and plan, but drawing them down transaction by transaction happens in Order and bill. When a consumer orders a service, the platform decides based on your policy how to approve the order and provide the services. You may choose to not have any approval gate and simply track planned vs. actual via reporting at the Showback stage. Another more sophisticated option is to approve the request automatically if it is within the available quota. In some cases, in addition to a check against the quota, you may want to implement other financial controls such as requiring management approval if order value exceeds a predefined threshold, or an escalation option to request a quota increase if an order hits the quota ceiling. 8

11 BILLING ADVISORY The first thing to consider when it comes to the billing advisory is that you must couple ordering and billing together to associate a bill with the order. When a consumer orders a service, you need to ensure that key reference data, in addition to the order itself, is also transmitted to the billing advisory system, or is available for the billing system to discover. These may include items such as period, billable service, billing method, price, account or tenant, business unit, and even a reference for the consuming service (if you want to identify which application service is consuming the infrastructure service that has been ordered). If you plan to support container-based applications, which fully automate provisioning and de provisioning, keep in mind that the order will be issued by the container, not by a user: You will need to fully automate the procedure by which consumption facts are obtained, even for subscription-based billing. This need for system data is even more critical if you are charging by consumption where metering information must be gathered via one or more metering subsystems of the delivery platform. The end-result, however, is identical: The billing advisory applies the order information (rates at time of consumption) to the usage information (metered quantities) to create a billable amount. SETTLEMENT: CHARGEBACK VS INVOICING The billing advisory record can then be used for reporting purposes (known as showback) or for actual financial settlement, whether chargeback or invoicing. Chargeback: The billing advisory details are used to trigger movement of amounts among cost centers in the internal financial system. Invoicing: The billing advisory provides the data for raising account receivables and invoicing, typically by feeding an ERP system. Whether the invoice is for an aggregate amount or order by order, and whether the billing advisory is shown separately or as part of the invoice, needs to be agreed upon by the provider and the consumer. To reduce the volume of adjustments, in a B2B context, you may provide a billing advisory to the consuming organization to verify before the invoice is raised. Showback TRANSACTION ONLY VS FULL SERVICE Whatever billing method you use, you must be able to show consumers what services they have consumed and what costs they incurred, at aggregate and per-unit level. The most basic capability is transaction-only, which considers each order by itself and simply provides a billing advisory per order. A full service method helps the service consumer make sense of the charges by aggregating them in various ways (e.g., over time, by service, by organizational unit), which can then reveal useful information such as what volume of which infrastructure services the applications have consumed. This method is effectively a roll-up or drill-down showback and allows consumers to both: Relate IT costs to business benefits (using the roll-up) Understand key IT cost drivers (using the drill-down) and drive cost vs. quality trade-off decision making As IT moves away from being a pure service provider toward being a service broker, it can also start incorporating charges from third parties into the showback capability. 9

12 Contact us at: Keeping It All Together The Whole Is Greater Than the Sum of Its Parts The transition to cloud is forcing IT to become an internal business. Business units will choose, on a continuous basis, what to consume from the IT storefront, whether via a catalog or an API, and pay accordingly. It is not easy for IT to make this transition, and in the day-to-day world, many of the issues discussed here one at a time will arise concurrently. When this happens, the four Ps should provide useful guidelines for organizing the decisions you need to make. Learn More At AA H 08/ Micro Focus or one of its affiliates. Micro Focus and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus or its subsidiaries or affiliated companies in the United Kingdom, United States and other countries. All other marks are the property of their respective owners.