Why Organizations Should Reconsider Their Current Chargeback Systems
Imagine Mary, Fred and George are gathered for a budget meeting with Ellen, their company’s CIO, to discuss another budget shortfall. Ellen asks, “What caused this million-dollar shortfall?” George says, “We think it’s related to the decision by accounting to shift one of their major workloads from our Power Systems* platforms to our VMware tower. We were getting approximately $800,000 in chargeback recoveries for that application, called the XB app, and those recoveries disappeared when they moved it.”
Mary adds, “We’re behind in our VMware recoveries too. It looks like we’re headed for a $230,000 deficit there and we think it might also be due to the new XB application.”
Then Fred says, “I know they took the application off, but I haven’t seen a reduction in capacity requirements, so my Power* costs haven’t decreased. I certainly don’t want to be the one explaining to the other departments why their chargeback is going up again!”
Ellen asked her team to gather more answers about the XB application shift.
The Staff Meeting
Mary asks Fred, “What did you find out about the Power situation?”
“We recover our Power costs by charging for LPARs,” says Fred. “We try to set the LPAR chargeback rate every year by looking at our total cost and dividing by the number of LPARs hosted during the year. The users always complain. They can’t figure out what drives a need for more LPARs; frankly, neither can we. That’s up to the architecture and programming teams. We just host the workloads. The XB application was using four LPARs last year and that drove $800,000 in recoveries. When they took the application off, it freed up some capacity on the servers, but we still need to pay for the servers and maintenance. It didn’t drive down the peak requirements for CPU resource either, so we still need as many cores as we used before. Those are our cheapest MIPS. Our actual expense only went down about $30,000.”
George looks perplexed. “Why were we charging them $800,000 if this application only costs us $30,000?”
“I think it has to do with the way we average things,” Fred explains. “Many of our costs are fixed, so when we remove LPARs, our costs don’t go down much. The idea of the Power enterprise server is to put lots of work in it to defray the overall cost. Taking work out doesn’t really decrease the fixed-cost burden, so it leaves the last remaining applications and LPARs with carrying all of the burden and drives up their cost. While it makes sense to the platform defector to leave based on the chargeback cost, it isn’t necessarily a good decision for the company.”
“But,” George asks, “Why are we down by $1 million?”
Mary reveals a chart (see Figure 1 below; click to view larger).
“We charge $300 per image per month for a typical virtual image,” Mary explains. “We base that chargeback on the average cost of an image. However, this application was exceptionally demanding on the processors, and instead of costing $108,000 for 30 images, it actually cost $338,000. So we ended up with a funding shortfall when this application got added. Now we’ll have to spread that against all of our other users.”
George looked worried. “Wow,” he says. “Do you see where this is headed? No wonder this is a recurring problem. Accounting just saved $692,000 by switching platforms for the XB application. Now everybody else’s costs are going to go up and we’re going to get more of these platform changes. We’re spending money as a company to make poor platform choices based solely on our chargeback scheme. We need to fix this.”
Chargeback Economics Drive Decisions
Unfortunately, scenarios like this are common. Chargeback systems have become a bigger issue over the past few years because what used to be an arcane accounting function has increasingly become a decision-making tool. Simple systems designed to spread budget allocations are simply not up to the task of driving effective decision-making through a flawed pricing mechanism. Current chargeback systems have five primary flaws:
- Overly broad averaging across diverse workloads and applications
- A failure to account for fixed costs in infrastructure and treating all costs as if they were entirely variable
- Technology adoption, causing new users of a technology to bear all of the initial costs
- Technology abandonment, causing existing users to pay for the ongoing costs of technologies after one constituent switches technologies
- Scope and interaction between solution elements as what appear to be independent choices can have unintended consequences
Consider Fixed Costs
Inevitably, unit cost calculations require an average: A company has $X cost and Y items, $X/Y = $x cost per item. This metric has two important underlying assumptions:
- All items are essentially the same
- Adding (or subtracting) an item changes the total in a linear way
Oftentimes neither of these assumptions is correct. The presence of a high proportion of fixed costs ensures that the second assumption is wrong. IT assets are often fixed capital purchases. Reducing usage does not allow a consequent reduction in operating expense. This model is one reason that mobile phone bills quickly went from a per-minute billing charge to a fixed, monthly fee. Phone companies make very large capital investments that must be paid for whether the phones are used or not. Mobile customers learned that phone bills could drastically vary every month. In this case, a fixed fee was a better solution for both providers and users.
IT organizations should consider adopting a similar model. Fixed charges during longer periods of time (e.g., quarterly or annually) with some small proportion of variable charges encourage conservation of resources. Users can more accurately budget, and IT is more likely to recover fixed costs. The alternative is to constantly vary unit costs as usage changes, which could lead to frustration and distrust between providers and users.
George and Mary had a variation of this problem. George lost chargeback recoveries, but did not see a proportional reduction in cost. Mary ended up with heavier than average workloads that weren’t accounted for in her current unit-cost metric. This problem frequently occurs in chargeback systems and leads to a paradox in which everyone sees an increase in cost even though the pricing model predicted a cost reduction.
Adoption and Abandonment
Imagine a new, 100-unit apartment building with an owner who decides to charge the first 10 tenants for the entire cost of the new building. Even if the new apartment building offered superior accommodations and the cost would be competitive once it was fully occupied, the apartment building would never be full because the first tenants would find the rent prohibitive. Many IT organizations create a similar problem by asking early adopters to bear all of the costs of a new technology.
The flipside of this issue is technology abandonment. Users chasing the next technology fad often leave IT holding the sunk costs in past investments. The new technology may be better, however, a true financial accounting of costs and benefits should include the sunk costs of past investments. When resources are shared between users, other users are unfairly saddled with these sunk costs, which further distorts the value calculation of users and providers.
IT organizations must factor in the effects of technology shifts on total cost. They should ensure chargeback mechanisms support strategic decisions and reflect real value to the organization.
Seeing the Full Scope
Chargeback can often drive users to make narrow decisions without considering unwanted side effects, such as increased software costs driven by platform changes. In the example with Mary, she or her customer may see an increase in software charges as a result of additional cores or platforms required with moving the application. Unfortunately, it may be difficult for Mary or the user to figure out why software charges increased. In many cases, these charges are covered under separate budgets, or are captured in a large budget and allocated to all users. Software costs go up, and no one knows why. The software cost example is by no means unique. Other costs could include those associated with security, operations and facilities.
Communication is Crucial
Like many infrastructure managers, Ellen, Mary, Fred and George are in for a rough time. They typically have little or no control over the chargeback systems that are imposed. Their users see constantly shifting unit costs that seem to thwart any efforts at achieving lower costs causing a loss of confidence in the chargeback systems and IT management’s ability to manage costs.
Finding solutions may not be easy, but they could involve preventing users from making technology decisions on the basis of chargeback, better alignment of chargeback to cost, and consciously designing chargeback to drive strategic technology choices. No matter what IT organizations decide to do, they must manage the effects of chargeback and communicate with users to ensure that IT decisions lead to better service and lower user costs.