In an earlier blog, I described a simple way to start building a cost model based on infrastructure cost recovery. This approach tried to account for costs actually incurred, so that you could have a good idea of who is using your infrastructure budget, and maybe have a basis for charging them. Obviously, this is what all service providers need to understand, but it is also something that many IT practices are starting to tackle.
The problem with that approach, however, is that if you passed the resulting costs onto a customer based on the "actual cost" idea, you would be spending a lot of time arguing with your customer. The customer (whether internal business or an external customer) would query how the hell they ended up with a bill of $5,127.63 this month, when last month it was $3,502.24. This is a good lesson I learned from talking to service providers. Customers are very gun-shy of the "shocking mobile phone bill" event. Anyone paying for an IT service is VERY keen for it to be predictable, consistent from month to month, and easily understood.
So, how to marry these two ideas? On the one hand, the provider side of the service has definite costs, and those costs need to be accurately tracked and apportioned out to the users of that service. And on the other hand, the customer doesn't want to end up with highly fluctuating costs, unpredictable bills, and NEVER to receive some huge bill they can't explain. The "inexplicable bill" is a problem, even when a customer is willing to deal with the varying bills. What I mean by that is, when a bill comes and the customer queries it, how would the provider explain how those particular numbers got calculated? Do you imagine a conversation where the customer is interested in how many CPU cycles were consumed, Bytes transferred, memory consumed on physical server, etc? I can imagine a shouting match full of accusations, doubts, lack of trust, and ultimately an unhappy experience.
The insight from a few of my service provider friends was "the simple cost model". I guess it's nothing magic - but it makes good sense as part of a "dual cost model". One for internal validation of real costs incurred. The other for something you can confidently invoice, explain and backup with simple data.
Take a cursory look around a few IaaS provider price lists, and you'll find some easy examples. For instance, $35/month for a virtual machine of a standard size. Other costs might include certain specific resources added to the VM configuration, like another vCPU or disk, or larger memory size. I think the key to making this work simply is to limit the sizing choices available to the customer, so that prices increment is only a small number of known ways. Then it is easy to look at a list of customer VMs, and without the aid of a spreadsheet or detailed metrics, you could quickly work out the cost of that setup. Thus, a customer knows what they're up for, and can understand an invoice when it arrives, AND can have a conversation with the provider about it without it turning into a frustrated screaming match!
Now, I did mention before about how to marry this "outward cost" with the accurate internal cost. This is a reconciliation exercise that should be done on a regular basis, to ensure that whatever the customers are being charged is as close as possible to the real costs incurred (and maintaining whatever profit margins to go with it). You might find that the "incurred cost + margin" and the "invoiced revenue" would vary by 10% either way from month to month - but as long as the two numbers gravitate near each other over time, you are winning! And as variances become clear, then the customer model might need some slight adjustment. Why adjust only the customer model? Because the internal model is based on real costs and should be the more accurate number, and the customer model is intentionally simplified and a bit artificial.
Well, hopefully those thoughts make sense. One cost for keeping internal, and a simpler derived cost for charging on to your customers/users. This approach should make sense regardless of whether you are providing services to your own business users, or to commercial customers.
Happy modeling, and as always please throw any comments back my way!
No comments:
Post a Comment