Home > Blogs > VMware Accelerate Advisory Services


Is Your IT Financial Model Fit for ITaaS and the Cloud?

Harris_SeanBy Sean Harris

IT as a Service (ITaaS) and Cloud Computing (Public, Private & Hybrid) are radically different approaches to delivering IT, from traditional IT delivery models, that require new operating models, processes, procedures and organisations to unlock their true value. While the technology enables this change, it does not deliver it.

Measuring the Business Value of IT as a Service

A question I hear often from customers is, “How do I measure and demonstrate the value of ITaaS and Cloud Computing?”  For many organisations, the model for measurement of value (the return) and cost (the investment), as well as the metrics that have context in an ITaaS delivery model, are unclear.  For example, most (surprisingly not every) customer I deal with can articulate the price of a server, but that metric has no context in an ITaaS delivery model.

Link IT Cost to ValueI have talked before on this very blog about the importance for IT in this new digital era to be able to link the investments in IT and the costs of running IT to the gains in business efficiency and true business value. This will link your business services, the margins and revenues they generate and the benefits they deliver to customers and the business as a whole to IT costs and investments. This is one step. The other side of this equation is how to represent, measure and track the cost of delivery of the IT services that underpin the business services, then present them in a form that has context in terms of the consumption of the business services that are delivered.

Have you mapped your business services to IT services in terms of dependency and consumption?

Have you mapped IT spend to IT services and IT service consumption?

What about your organisation and procedures? How do you account for IT internally?

The Project-Based Approach

Most of the organisations I speak to have a project based approach to IT spend allocations. There are variations in the model from one organisation to the next, but the basic model is the same. In this approach:

  • Funds for new developments are assigned to projects based on a business plan or other form of justification.
  • The project is responsible funding the work to design and develop (within the organisations governance structure) the business and IT services needed to support the new deployment.
  • The project is also typically responsible for funding the acquisition of the assets needed to run these services (although the actual purchase may be made elsewhere) – these typically include infrastructure, software licenses, etc.
  • In most cases the project will also fund the first year (or part year) of the operational costs. At this point responsibility for the operation is passed to a service delivery or operations team who are responsible for funding the on-going operational aspects. This may or may not include a commitment or ownership of tech refresh, upgrades and updates.

What is included can vary drastically. Rarely is there any on going monitoring of the costs mapping to revenues and margins. When it comes to tech refresh, in many cases, it is treated as a change to the running infrastructure and so needs an assigned project to fund that refresh. This leads to tech refresh competing with innovations for a single source of funds.

The Problem with Project-Based Accounting

Just for a second, imagine a car company offering a deal where you (the consumer) pay the cost of the car, the first years service, tax, insurance and fuel and then after that you pay NOTHING (no fuel, no insurance, no tax, no service). Would that not lead you to believe that after year one the car is free?

While the business as whole sees the whole cost of IT, no line of business or business service has visibility of the impact it is having on the operational cost of IT. It is also extremely hard, if not impossible, to track if a business service is still operating profitably, as any results are inaccurate and process of calculation is fragmented.

Surely this needs to change significantly if any IT organisation is to seriously consider moving to an ITaaS (or cloud) delivery model? Is it actually possible to deliver the benefits associated with ITaaS delivery without this change in organisation and procedure?

Applying a service-based costing approach can seem intimidating at first, but it is essential to achieving value from your ITaaS transformation and gets much easier with expert help.  If you are approaching this transformation, contact our Accelerate Advisory Services team at VMware who, along with the Operations Transformation Services team, provides advice and guidance to customers around constructing an operating model, organisation, process, governance and financial management approach that supports an ITaaS delivery model for IT.

=======

Sean Harris is a Business Solutions Strategist in EMEA based out of the United Kingdom.

2 thoughts on “Is Your IT Financial Model Fit for ITaaS and the Cloud?

  1. Daniel Scott

    The value of ITaaS and Cloud Computing in financial modeling cannot be understated. If you ask me, the most important element to financial modeling is having a comprehensive and effective tool. There are many free tools online right now that are on the cutting edge of personal financial modeling tech. Whether you use a tool like OnTrajectory or some other website, there are a plethora of options out there. Once you have found an effective tool, then things like ITaas and Cloud Computing become critical.

  2. Sean Harris

    @Daniel_Scott: I agree that it is impossible to truly operate an ITaaS environment without having a handle on your IT financial management and allocations, however I have to disagree on your approach. As technologists we repeatedly make the mistake of selecting a tool to solve the problem before fully defining the problem and the desired outcomes. This results in trying to force the problem into a shape defined by the tool rather than selecting a tool based on the shape of the problem and the desired outcome and, in my experience, is the number one reason for project failure. My advice would be firstly define the problem itself and it’s scope, then define the desired outcome and then start to sketch and approach to get from problem to solution. Use this to develop a set of criteria against which all tool offerings can be assessed and accept the following. It is very unlikely that one tool will be perfect for all selection criteria, it is usually a case of selecting based on best fit rather than perfect fit, and be prepared for the answer that it may be a combination of more than one tool that is needed to truly solve the problem.

Comments are closed.