IT is getting really interesting as new technologies such as virtualization open doors to different IT economic models to more customers, one being a move towards a Service Provider model where organizations like Internal IT start to charge their customers Pay-As-You-Go (PAYG) models for services like Desktops. But these models increase the risk on IT and therefore need better management – but how?
Introducing Service Provider-esque PAYG models is a more open economic model for IT which changes the dynamics between customer and IT, and encourages new IT behaviour such as efficiency through better capacity management. But how do you know if you’re doing good or bad? Here are four key variables that must be planned for and monitored,
At the beginning of any VDI solution you will develop a business case which will contain, amongst other things, a financial model of TCO/ROI and possibly NPV, IRR and Payback. If you’re really good you will be developing a Desktop Service strategy with blended solution portfolio and demand management approaches to achieve the financial model.
At 50,000ft there are several key variables to your financial model that you should not just plan for, but also monitor over the lifetime of your solution:
- Features - high availability costs money, so you are likely to have tiers and categorizations of desktops linked to their SLA, capacity etc.
- Payment - if you’re really good, your customer will pay OpEx on a quaterly basis and not have to pony up for $10M of CapEx to buy the solution.
- Schedule – that ROI will give a date / elapsed time when the investment is paid back. The shorter this time frame is, the better. Think of it as the break-even point you need to hit, so what is the monthly run-rate to get you to that point?
- Volume – my bet is that your VDI architecture is designed for a maximum volume, unless you’ve been smart and gone for a scalable pod approach. What volumes do you expect at what date? Is it better for this number to be less than, or more than, planned?
You can bet your last dollar that some or all of those will change during the lifetime of your VDI solution – but is that change good or bad?
Are you offering platinum, gold, silver, bronze desktops? Each have different Features and link to Payments because they might be different OpEx prices. If you expose these tiers and pricing to your customers, then you are taking the one way road to open market competition economics.
Put yourself in the shoes of a business manager: “Why should I pay Internal IT $250/qtr for a hosted desktop when I can buy physical for less/similar, or use a cloud offering?” The common response by Internal IT to this question is: “You HAVE to buy from us!” (footnote: even if we cost more and are worse). That kind of mandate might seem smart, but it’s a key indicator that Internal IT is losing the battle and has lost the war. If this is an Outsourcer saying this, then the writing is on the wall for them and I can 100% guarantee they are going to have to go through a tender at the end of their contract (expensive for outsourcer).
One thing you should definitely offer in addition to tiers of service (think SLAs) is different technologies. This is your opportunity to truly deliver Desktop Services to deliver different product lines. Think of different production lines producing these product lines, and you have a desktop storefront to display them direct to your users. Your users now buy what they need based on price and features they require: Desktops R Us?
How do you know what Features to offer? What levels of service? What functions? You can only do this successfully by starting with a marketing mindset and putting yourself in the shoes of your customers. How many customers do you have? How many different types? What do they need vs. want? And when? Check out Desktop Strategy based on ITIL.
If you do your research correctly, you should not just have a list of Features to put into your portfolio, but you should also know the price point and the demand levels over time.
These features should go in a service catalogue like that offered by newScale.com, and you should monitor take up of these features through such a product, and like a supermarket adjust the positioning and blend of products on offer.
If you know these feature variables (feature list, price point, demand levels, time) then you can plan and measure your performance against them. Variance from the plan is an opportunity to (a) get better at planning by understanding what went wrong, and (b) modify your delivery of the service to match the changed demand. An example of the latter is providing cheaper storage if the demand wants to pay less for lower performance.
Have we seen the end of days for customers paying a whacking great CapEx up front and depreciating the assets over time, in favour of OpEx only IT? Cloud is an example of OpEx only IT, but it isn’t the only one.
If you are providing the solution that requires multiple technologies you can get financing from companies like Cisco to pay for it all in one go then charge you a monthly/quarterly bill. Cisco will even put the consortium of technologies together for you to reduce the risk even further!
With this kind of out of the box thinking you might end up at a “pay per seat” model, where the ultimate paying business customer only pays for the assets they use. An example is paying quarterly for the number of desktops / user seats they consume. The price they pay depends on the desktop feature list, which is a mix of SLA, performance, capacity and functions such as what applications are accessed.
If you already know your Features and have prepared a marketing plan for VDI (or Desktop Service) then you should be able to work out what it will cost you to deliver the service, over time, and therefore what price you might charge and on what terms. This is time for IT to start thinking like a Service Provider and thinking about margins.
It’s an evolution for many IT shops but I hear lots say they want to move to this model: or die in the face of aggressive service providers like AWS who are using things like VPC to encroach into their data centers.
New payment models need sign-off from legal and finance teams and they will expect terms to be adhered to, and if they aren’t then there may be bonuses (for better) or penalties (for worse).
If you know your Payment terms, then you should have a good business plan showing how much money goes out and comes in over time. You should understand how these Payments are going to help you achieve your plan as laid out in your financial model. Will you deliver the Payback as promised in the business case to the CFO? If you monitor run-rate and features and payment terms you should know ahead of time if you are going to win/lose and be able to adjust your execution to tip the scales in your favour.
The glue between the Payments and the financial model, especially the ROI and Payback, is the Schedule. This is your planned vs. actual service numbers. In the Schedule you have provisioning numbers and consumption numbers.
The provisioning schedule shows how much and when the service provider is releasing new capacity into the service. For VDI this could be a new ESX host, or a new bunch of disks, or a new tier of desktop.
The consumption schedule shows how much and when the customers use the desktops. For VDI this is desktops deployed, by tier.
The schedule is measured by run-rate and links to Volume. If your run-rate is lower than planned, you are not on schedule and at risk of not hitting your plan. If your run-rate is higher than planned, you are at risk of exhausting capacity and in effect making the service unavailable to new customers.
Accurate data is key to a good schedule – make sure the data collection and reporting is automated and little if any human “adjustments” are made. You’re only lying to yourself.
The Schedule is useful for a variety of reasons, but it is the number you should look at weekly to see where you actually are in terms of capacity provisioned versus consumed. You can use demand and capacity management techniques to affect the schedule, such as increasing prices / deployment times to slow the run-rate, or decreasing prices / speeding up deployment or adding new product lines to increase the run-rate.
Link closely to Schedule, Volume is the cumulative value of your monthly run-rates and it is ties to Payments because if you are smart enough to go all OpEx then this is the “concurrent desktops” you will be billed for.
Volume is also tied to the customers’ business goals: if the customer needs to migrate 2000 users in one quarter, then your volume numbers in the plan should reflect this and provisioned capacity should be ready for it.
On a chart of volume vs. money out vs. money in, it also shows the levels, per desktop tier, where you break even and where you lose / make money.
Volumes must be accurately taken from a system point such as the service catalogue or lifecycle management tool that can accurately report, at any time, how many concurrent desktops are deployed (if that is the volume measure).
Projected Volumes are critical for negotiating a pay-as-a-you-go OpEx deal with vendors like Cisco. Volume numbers in a PAYG model are like the “minutes used” in a mobile phone contract in that you might have to pay for a minimum commitment, perhaps bursting fees – the variables are many. If you get the projected volume wrong then you might be paying too much for too few desktops, so you need to either renegotiate the Volume terms or start increasing Volume!
Plan for an monitor the Features, Payment, Schedule and Volume of your VDI (or Desktop Service) solution. If your solution is already up and running, you can retrospectively view your performance: it’s never too late.
If you do the above then you have the information at hand to manage your portfolio of application and desktop services based on sound economics that the CxOs will appreciate. These might even give you the confidence to start using efficiency ratios (power in to desktops deployed / users supported) and even new technologies such as Cloud desktops.
If you don’t do any of the above then maybe you’re just another tech shop that probably doesn’t know how good or bad you’re doing, and that kind of ignorance might be bliss but it is not a winning strategy.