Meta Chargeback Pain or Gain (Dec2004) - With Cases

metagroup.
com
December 2004
800-945-META [6382]
Chargeback Pain or Gain:

The Critical Decision Facing CIOs Today
A META Group White Paper
Many organizations approach the problem of chargeback algorithm design by focusing attention on platforms for which usage-based allocation is most easily accomplished (typically IBM zSeries). Yet bills generated from these platforms end up recovering a significantly larger share of the costs than they actually generate. On average, approximately 15% of Global IT budgets are attributable to mainframe-related purchases, contracts, and activities, but at the same time, 25%-30% of the IT budget is recovered via billing for mainframe-resident services.
Chargeback Pain or Gain: The Critical Decision Facing CIOs Today
Contents
1.0 2.0
Management Summary ............................................................................. 2 Chargeback Structures............................................................................. 4
2.1 Inaccuracies and Problems With Chargeback Structures ................................................4 2.2 Factors Driving Chargeback..............................................................................................5 2.3 The Controversy Surrounding Chargeback ......................................................................6 2.4 Best-Practice Architectures...............................................................................................7 2.5 Cost Allocation for Shared Services and Infrastructures ..................................................9 2.6 Pain Sharing Versus Gain Sharing ...................................................................................9 2.6.1 An Old Problem and a Modern Solution .....................................................................10 2.6.2 Allocation by Example.................................................................................................10 2.6.3 Pain Sharing ...............................................................................................................11 2.6.4 Gain Sharing ...............................................................................................................11 2.7 Choosing Between Pain and Gain ..................................................................................12
3.0
3.1 3.2 3.3 3.4
Setting Relative Prices............................................................................ 13

Internal Exchange Rates.................................................................................................13 A Simple Example ...........................................................................................................13 A More Complex Case ....................................................................................................15 The General Case ...........................................................................................................16
4.0
4.1 4.2 4.3
Case Histories ......................................................................................... 19

Case History #1: A North American Bank.......................................................................19 Case History #2: A European Telecommunications Firm ......................................21 Case History #3: A European Bank ................................................................................22
208 Harbor Drive Stamford, CT 06902 (203) 973-6700 Fax (203) 359-8066 metagroup.com Copyright 2004 META Group, Inc. All rights reserved.
1.0 Management Summary

A chargeback system is a collection of applications, algorithms, and processes used by most medium to large organizations to allocate and recharge corporate lines of business (LOBs) and departments for IT operational costs. Despite their ubiquity, chargeback systems have proven controversial for two reasons: The general conclusion has 1. The cost and difficulty of developing and maintaining these systems, particularly for distributed environments
been, Chargeback if you must, but keep it simple and use fixed monthly charges .
2. Ongoing internal resistance to the concept of LOBs receiving bills from the IT organization, particularly when those bills were not based on easily understood metrics Until recently, most of the arguments regarding chargeback concerned the complexities involved in defining the appropriate units out of which to generate internal bills as well as overcoming the technical difficulties involved in measuring the consumption of those units once they were defined. The general conclusion has been, Chargeback if you must, but keep it simple and use fixed monthly charges possibly making some allowances for differences in quality of service. In the current environment, these issues, though still of some importance, pale in Cost allocation is becoming comparison with the issues surrounding ever more difficult as IT cost allocation techniques for shared IT architectures increasingly rely assets. Whatever mechanism is used for on shared layers of recovering costs, effective billing infrastructure. presupposes effective cost allocation. However, cost allocation is becoming ever more difficult as IT architectures increasingly rely on shared layers of infrastructure. To build effective chargeback systems in todays environment, two fundamental problems must be solved: 1. Corporations must become adept at allocating costs for shared services and infrastructure.
2. Once costs are allocated, corporations must develop the means to effectively compare the value of the services provided by the different platforms used to deliver IT functionality to the LOBs. Yet META Group research indicates that in many organizations these fundamental problems are still not being properly addressed. In these organizations, the charging for data center infrastructure services (servers, storage, network, people, and environmental costs) still remains largely rooted in the era before META Group commonly finds distributed computing. In this situation, a that a disproportionate number of disproportionate number of IT costs are loaded onto the systems that are shared IT costs are still loaded perceived to be the most expensive. This on the legacy systems that once perception may be based on the physical dominated the data center, but size of the system (e.g., a mainframe) or are now just one part of the total on assumptions about total cost of corporate IT infrastructure. ownership. META Group commonly finds that a disproportionate number of shared IT costs are still loaded on the legacy systems that once dominated the data center, but are now just one part of the total corporate IT infrastructure. Because cost is a major driver for technology platform choices, this common misallocation can affect the soundness of the decision-making process. In organizations where current best practices are being implemented, the focus is on building chargeback systems that are: 1. Reflecting the real, underlying relationship between IT resource consumption and cost accrual 2. Maintaining maps between IT and business process events and where possible, expressing the bills in business terms 3. Explicitly balancing unit charges among different platforms so that they accurately represent exchange values among different types of units The development of these systems typically requires deep knowledge of business processes and applications. It also requires integration with asset management and capacity planning technologies and processes.
We identify two alternative techniques that respond to these drivers: Pain sharing: Seeking to fairly allocate costs according to the added burden that each LOB adds to the organization. In other words, each LOB inflicts pain on the organization in the form of added costs to pursue its own business strategy, and the total pain borne by the corporation is to be divided up fairly. Gain sharing: The technique of allocating costs with the goal of fairly allocating the savings. For example, when a number of LOBs come to make use of shared services, all the LOBs taken together will usually achieve a net saving over what they would have collectively spent if each had acquired the service in question individually. Assuming there is no obvious way of allocating costs according to usage, gain sharing entails allocating costs to ensure that each LOB or department realizes a fair share of the savings that all of them together have achieved.
Once the cost allocation technique is chosen, companies must choose the platforms and services through which the allocated costs are to be recovered. Here, further care is required, since, as noted above, the tendency is to have the systems in which it is easy to track fine-grained usage (e.g., IBMs zSeries) bear the brunt of the cost recovery burden. It is understandable that businesses should approach cost recovery pragmatically and be satisfied with the actual recovery of costs allocated, in whatever way that recovery may be accomplished. Nonetheless, how a platform or service is used for cost recovery can have a dramatic effect on the perceptions of its cost. Failure to understand this impact can lead, in the long run, to suboptimal platform selection and an inability to come to grips with the true costs of IT.
2.0 Chargeback Structures

2.1 Inaccuracies and Problems With Chargeback Structures
During the past two years, META Group has seen the number of projects related to chargeback skyrocket among Global 2000 corporations. Thanks to a number of factors, which we will discuss below, more than 50% of the worlds major On average, approximately 15% of companies are developing new Global IT budgets are attributable chargeback systems or refurbishing or to mainframe-related purchases, extending existing chargeback regimes. contracts, and activities, but at the However, technology and architectural same time, 25%-30% of the IT trends make chargeback a more difficult budget is recovered via billing for problem today than it was in the 70s, mainframe-resident services. the 80s, or even the 90s.
Besides the political difficulties traditionally associated with asking lines of business to pay for their consumption of IT resources, dynamic resource allocation and virtualization thicken the integrated infrastructural layers on top of which diverse LOB applications are delivered. The spread of Web services and service-oriented architecture (SOA) designs only further aggravate the situation. Put another way, an ever greater percentage of function points utilized by LOBs now reside in shared service buckets. This makes it virtually impossible to use technological structure as a guideline for cost allocation, no matter how fine-grained usage tracking becomes. META Group has also observed that many organizations approach the problem of chargeback algorithm design by focusing attention on platforms for which usagebased allocation is most easily accomplished (typically IBM zSeries). Yet bills generated from these platforms end up recovering a significantly larger share of the costs than they actually generate. On average, approximately 15% of Global IT budgets are attributable to mainframe-related purchases, contracts, and activities, but at the same time, 25%-30% of the IT budget is recovered via billing for mainframe-resident services. After reviewing the factors that have led to the new wave of chargeback-related investment, we will examine possible solutions for both of the fundamental issues previously noted that is, corporations need to become adept at allocating shared services and infrastructure costs and then need to develop the means to A growing number of LOBs effectively compare value of the services are obtaining the right to opt provided by the different platforms used to out of using corporate IT deliver IT functionality to the LOBs (see Section 1.0). services. Effective
2.2
Factors Driving Chargeback
During the next 12 months, investment in chargeback systems among the Global 2000 will increase by approximately 10%. This increase is being driven by six largely independent factors:
chargeback will be required to rationalize these decisions and execute them smoothly.
1. A growing number of LOBs are obtaining the right to opt out of using corporate IT services. Effective chargeback will be required to rationalize these decisions and to execute them smoothly. 2. The renewed acceleration of merger, acquisition, and divestiture (MAD) activity will drive organizations to implement and maintain chargeback to understand and manage the financial consequences of LOB addition and removal.
3. The trend toward centralization and consolidation of infrastructure greatly complicates the understanding and management of IT costs, forcing organizations to move beyond back-of-the-envelope or spreadsheet accounting. 4. The spread of variable pricing-style contracts will demand more careful monitoring and management of usage. 5. Burgeoning user demand for IT resources increasingly is being scrutinized as a possible cause of IT profligacy. Chargeback is seen as a way of managing this demand while at the same time allowing LOBs a reasonable degree of autonomy with regard to their IT resource consumption decisions. 6. Centralization and consolidation frequently are creating situations where IT services are being delivered in countries remote from where they originate. Tax optimization in these scenarios will require more granular management of IT-related cash flows.
2.3
The Controversy Surrounding Chargeback
Chargeback remains controversial. Part of the controversy stems from the costs associated with the chargeback system itself. As a collection of algorithms and processes, sometimes coupled with dedicated hardware and network equipment, the development and maintenance of a chargeback system can be expensive. Throughout the 90s, Global 2000 companies that maintained these systems found themselves consuming on average 3%-4% of the IT budget. Furthermore, chargeback based on the detailed resource consumption statistics gathered from distributed systems and IP-based networks were a major technical challenge for vendors and in-house development teams alike. Economic analysis added fuel to the fire. Chargeback was frequently justified in terms of its ability to drive a rational allocation of IT resources, however: 1. This presupposed the existence of a market where IT resource units were traded and meaningful prices could be established. 2. In any case, any impact on actual costs presupposed that incremental costs could be attributed to the marginal consumption of IT resource units. Yet in many cases, marginal consumption was, for all intents and purposes, free. Beyond all of these contributors to controversy, the largest concern stemmed from the inevitable political consequences of chargeback. Not only did the user community actively resent the imposition of getting bills from the IT department,
but CIOs would find themselves and their staff expending significant amounts of time and effort arguing for any given pricing method and even more damaging for a specific cost allocation technique. In the latter case, the damage stemmed from the fact that the ITO would be drawn into controversies regarding the relative importance and effectiveness of different LOBs and departments. Therefore, as previously noted, chargeback has proven controversial because of the cost and difficulty of developing and maintaining these systems (particularly for distributed environments) as well as ongoing internal resistance to the concept of receiving bills from the ITO (in particular bills Various factors are forcing not based on easily understood metrics). Global 2000 organizations into Various factors are forcing Global 2000 organizations into the development of new chargeback systems and the extension of existing systems into the distributed environment, but fortunately, the technical issues involved in capturing billable units for distributed system consumption are being addressed by the vendor community. In addition to the efforts of boutique vendors like CIMS and Network Analytics, the large Infrastructure and application management concerns such as HP, IBM, and CA are all in the process of revamping their chargeback-related offerings. For example, in the case of IBM, the Tivoli Storage Resource Manager has recently been upgraded to capture billable usage data for network-attached storage (NAS) and storagearea network (SAN)-based storage systems. The best-practice chargeback systems now being built exhibit a common structure, as shown in Figure 1.
the development of new chargeback systems and the extension of existing systems into the distributed environment.
2.4
Best-Practice Architectures
Figure 1 Financial Management System Architecture Future State
Business Unit
Mediation engine also balances across multiple IT customers
BRM Core Chargeback Tool

Including Visualization Capabilities
Rating Engine
Business Process Cost Determination
Systems Management Tools Capacity Planning + Modelling Pricing Database (IT Services)
Business Process
Business Event Model
Mediation Engine (Prices to Billable IT Events)
Chargeable Business event
IT Event (e.g., MIPS Consumed)
Asset Repository (Cost)
Source: META Group
Historically, these systems focused on isolating IT system events that could be relatively easily tracked and billed for and whose billing could be shown to generate sufficient revenues to cover the IT budget.
As noted in Section 1.0, now the focus is on building systems that reflect the real underlying relationship between IT resource consumption and cost accrual, maintain maps between IT and business process events and where possible express the bills in business terms, and explicitly balance unit charges among different platforms so that they accurately represent exchange values among different types of units.
Now the focus is on building systems that reflect the real underlying relationship between IT resource consumption and cost accrual.
This typically requires deep knowledge of business processes and applications as well as integration with asset management and capacity planning technologies and processes.
2.5
Cost Allocation for Shared Services and Infrastructures
To overcome this controversy, Global 2000 organizations must begin by recognizing that cost allocation for fundamentally indivisible assets is, in fact, a political problem. Concerns about economic efficiency and technology architecture will typically offer no clue with regard to the cost allocation problem. To some degree, knowledge of business processes might serve as a guide, but business process knowledge usually is not sufficiently detailed for such a purpose. Nor is it clear that the choice of one cost allocation strategy over another could be directly tied to meaningful business goals in any direct manner. Instead, cost allocation is mostly about perceptions of fairness for example, whether or not a given LOB or department believes that it is being overly burdened with costs that impact the achievement of its specific targets. Next, there is the need to recognize that there is no single optimal cost allocation mechanism. Perceptions of fairness will depend on how the specific cost allocation problem is understood by the various stakeholders and on the specific business situation. We will now look at two alternative techniques that take these concerns into account.
2.6
Pain Sharing Versus Gain Sharing
Sometimes it is relatively easy to allocate costs for a given IT resource. When all resource usage can be traced to one individual or another, the total costs associated with that resource can simply be divided in a manner proportional to If an application integration resource consumption. Increasingly, platform such as WebSphere however, IT organizations are confronted has been deployed, it is with resources that do not lend themselves to such straightforward treatment. virtually impossible to develop For example, when multiple applications are mounted on a single Unix server there are many CPU cycles for which the consumption cannot sensibly be attributed to any specific application or even combination of applications. If an application integration platform like WebSphere has been deployed, it is virtually impossible to develop a resource consumption-based cost allocation method for either software or hardware.
a resource consumption-based cost allocation method for either software or hardware.
Finally, looking just a bit further into the future, if service-oriented architectures proliferate, virtually all linkage between user actions (even higher-level application transactions) and the consumption of lower-level resources will have been broken. So, how does one go about allocating costs fairly when resource consumption fails to provide a guideline? 2.6.1 An Old Problem and a Modern Solution The issue of appropriate cost allocation is, in fact, an old problem. It is one that has troubled Greek philosophers concerned with the nature of justice, rabbinical and secular judges trying to work out fair divisions of assets in difficult divorce cases, and government authorities struggling to develop politically acceptable taxation methods for public services. Despite the fact that the problem has a long and venerable history, only recently, with the help of mathematical game theory, has the problem been solved in its full generality, allowing us to apply that solution to IT chargeback. 2.6.2 Allocation by Example We can build an example by imagining that there is a corporation that has two lines of business the book business and the music business. Both businesses need server capacity, but the book businesss requirements could be satisfied by a server costing $2,000, while the music business needs the capabilities of a server costing $3,000. However, despite the music businesss needs, this same more expensive server would also have sufficient spare capacity to satisfy the book businesss requirements. Given the total economics of the situation, the corporation authorizes the expenditure on the more expensive server and directs both businesses to make use of its capacity. It is now up to the ITO to work out how to chargeback for this cost. Clearly, there is no easy way forward. The cost cannot be split evenly between the two businesses. Nor can the ITO simply charge the music business the difference between $2,000 and $3,000. Suppose that, if the music business had exclusive rights to the servers resources, it would only consume half of the servers capacity. The server is, after all, a corporate resource, and it would seriously distort the music businesss operational cost metric if it had to subsidize the entire over-capacity available on that resource. So, what should the IT organization do? A first step would be to lay out the various possible cost scenarios in what game theorists call a characteristic function. We will simply call it a cost scenario schedule (CSS): Scenario 1: No one buys anything. Total costs are zero. Scenario 2: The book business buys its own server. Total costs are $2,000.
10
Scenario 3: The music business buys its own server. Total costs are $3,000. Scenario 4: Both the music business and the book business share the server. Total costs are $3,000.
2.6.3 Pain Sharing Given this cost scenario schedule, the ITO now gets down to the work of allocating the total cost. As previously noted (see Section 1.0), there are actually two ways of going about this allocation that might be considered fair. The first, which we call pain sharing, seeks to fairly allocate costs according to the additional burden that each business adds to the corporation in each possible cost scenario in which it is Pain sharing is where each involved. (In other words, each business business inflicts pain on the inflicts pain on the corporation in the form of added costs to pursue its own business corporation in the form of added strategy. The total pain borne by the costs in order to pursue its own corporation is to be divided up fairly.) business strategy. The total To consider how this would be enacted, let to be divided up fairly. us start with the music business, which is involved in two of the four scenarios. In the third scenario, the music business causes an extra $3,000 to be spent, and in the fourth scenario, it causes an extra $1,000 to be spent. On average, therefore, the music business causes $2,000 to be spent by the corporation. On the other hand, in the second scenario, the book business causes an extra $2,000 to be spent, while in the third scenario, it is responsible for no additional spending. Therefore, the average extra expenditure attributable to the book business is $1,000. 2.6.4 Gain Sharing This is the second way of considering the cost allocation problem. As noted in Section 1.0, when a number of LOBs or departments make use of shared services, all the LOBs taken together will usually achieve a net saving compared to what they would have collectively spent if each had acquired the service in question individually. Now, assuming there is no obvious way of allocating costs according to
pain borne by the corporation is
When a number of LOBs or departments make use of shared services, all the LOBs taken together will usually achieve a net saving compared to what they would have collectively spent if each had acquired the service in question individually. The technique of allocating costs with the goal of fairly allocating the savings is called gain sharing.
11
usage, how does one allocate costs to ensure that each LOB or department realizes a fair share of the savings that all of them together have achieved? The technique of allocating costs with the goal of fairly allocating the savings is called gain sharing. If this principle is used to allocate the cost pool, the book business on its own would have had to pay $2,000 for its required capacity, while the music business would have had to pay $3,000. Since the corporation has ended up paying $3,000 for the total joint requirement, charging the book business $1,000 for utilization and charging the music business $2,000 for utilization ensures that each charge reflects an equal amount of savings over what each business would have had to pay if it had bought such capacity on its own. Although pain sharing is generally understood intuitively, many organizations have initial difficulties with the concept of gain sharing. Why would a line of business be happy to pay for the profit it obtains by using a shared resource? The point here is that the gain share, while a loss to the LOB, actually reflects that LOBs overall contribution to corporate profitability. When a significant percentage of IT With this example, the result turns out to be the same whether one gain shares or pain shares, and in many real-life situations, this turns out to be the case. Nonetheless, there are many instances where the two algorithms generate very different results. Therefore, the ITO and the business itself must be careful regarding the kind of fairness they want to enforce.
assets are fundamentally indivisible and the business is not anticipating a significant increase in resource consumption, or a significant expansion or reduction of the user base (e.g., not anticipating a merger or divestiture), pain sharing is called for. Otherwise, the gain sharing technique is recommended.
2.7
Choosing Between Pain and Gain
There are some clear guidelines for choosing between pain sharing and gain sharing, depending on the business situation: If a significant percentage of IT assets are fundamentally indivisible and the business is not anticipating a significant increase in resource consumption, or a significant expansion or reduction of the user base (e.g., not anticipating a merger or divestiture), then pain sharing is called for.
12
Otherwise, the gain sharing technique is recommended, since it ensures a certain amount of constancy and predictability in the face of otherwise radical change.
3.0 Setting Relative Prices

3.1 Internal Exchange Rates
Once costs are allocated to the various user communities, most chargeback system architects face the difficulty of comparing the costs of using various platforms. This difficulty is the result of most organizations not having explicitly developed a currency that shows, for example, what the fair internal exchange rate between a unit of Unix resource consumption and a unit of zSeries resource consumption. The key insight required for addressing through this issue is the recognition that cost recovery is independent of cost accrual. An organization may pay a certain amount of money to acquire a Unix platform, yet actually recover the money spent via a zSeries platform-based bill.
3.2
A Simple Example
Let us begin with an organization with a very simple IT asset base consisting of only two resource types: computers (all of one architecture, size, and brand) and a network (in this case, a TCP/IP network, for simplicitys sake). Suppose that the base of computers costs the organization $500,000 per year in maintenance and replacement purchases and the network cost the organization $400,000 per year. Next, suppose that the organization has decided to allocate total IT costs on some form of usage basis. Surveying the various alternatives, organization executives decide that CPU cycles serve as the most easily captured metric for the computers, while IP packets serve as the most easily captured metric for the network. Finally, imagine that, after a year, an analysis of the chargeback systems functioning shows: 1. Over the course of the year, the computers consumed 2 million CPU cycles. 2. Four million IP packets crossed the network. 3. Costs for the mainframe were recovered via applications that consumed 1.5 million CPU cycles and 1 million IP packets. 4. Costs for the network were recovered via applications that consumed 0.5 million CPU cycles and 3 million IP packets.
13
This situation can be represented as follows: 1.5M CPU cycles + 1M IP packets 2M CPU cycles 0.5M CPU cycles + 3M IP packets 4M IP packets
A few points must be made about this representation. First, there is no reference to the external cost of the items involved. The only critical issues are the total number of measurable units that have been attributed to the Historically, organizations have tried to assets involved and which units make the units associated with a given were used to recover the external asset (e.g., CPU cycles in the case of costs (whatever they may have computers) bear the brunt of cost been) of the assets involved. Second, historically, organizations have tried to make the units associated with a given asset (e.g., CPU cycles in the case of computers) bear the brunt of cost recovery for that asset. However, there is no necessity that they do so, and the increasing complexity of systems will undermine any attempts to maintain such a linkage. In this representation, although CPU cycles are primarily dedicated to the recovery of CPU costs, they are not exclusively dedicated to doing this. A similar remark can be made about IP packets. In any chargeback system such as that represented above, there is a unique exchange value that holds among the assets that constitute the IT base. To see that this is the case, let us imagine that the 1.5M CPU cycles and the 1M IP packets produce the 2M CPU cycles, while the 0.5M CPU cycles and 3M IP packets produce the 4M IP packets. Next, imagine that at the end of the year, IT operations has ended up with the 2M CPU cycles, while network operations has ended up with the 4M IP packets. We can now work the metaphor and ask how IT operations will acquire enough IP packets to recreate the 2M cycles required for the following year. Also, how will network operations acquire enough CPU cycles to recreate the 4M IP packets required for the following year? When considering the units that IT operations possesses, we see that this suborganization has 0.5 million CPU cycles in excess of what it requires to produce 2M CPU cycles. At the same time, it has a deficit of 1M IP packets. On the other
recovery for that asset.
14
hand, network operations has 1 million more IP packets than it requires for next years production, while finding itself 0.5M CPU cycles in deficit. Therefore, to reproduce this years results next year, both suborganizations would accept an exchange rate of 1 CPU cycle equaling 2 IP packets.
3.3
A More Complex Case
The existence of a unique exchange rate is not the result of only two resource types being involved. Suppose, for example, that storage units were also involved. Imagine that the organization consumed, in addition to the resources mentioned above, 5M megabytes of storage and recovered costs for this new resource according to the following representation: 1.25M CPU cycles + 0.5M IP packets + 1M megabytes 2M CPU cycles 0.5M CPU cycles + 3M IP packets + 1M megabytes 4M IP packets 0.25M CPU cycles + 0.5M IP packets + 3M megabytes 5M megabytes.
In this case, using the above chain of thought, the unique exchange rate would be: 1 CPU cycle equals 1.23 IP packets equals 2 megabytes
It should noted that in the case of a chargeback system with two asset types, the quantity of assets of one type that is used to help in the recovery of costs for the other type is exactly the quantity of assets that, at the end of the year, the owner of the other asset has in excess of what is needed to recover costs for that other asset, and vice versa. There is no guarantee of such symmetry in the case of chargeback systems with three or more asset types. In fact, the functioning of the exchange rate presupposes the ability to effect what amounts to triangular trades among the asset owners.
15
3.4
The General Case
These points can all be restated in general terms that bring out the mathematical structure of chargeback systems, wherein all costs can be allocated. For example: Let a, b, , and k be the types of asset, the costs for which a given system is trying to recover. Let Aa, Ba, , and Ka be the quantity of units of asset types a, b, , and k, the recording of which over the course of a year is used as a basis for cost recovery associated respectively with asset type a. Let Ab, Bb, , and Kb be the quantity of units of asset types a, b, , and k, the recording of which over the course of a year is used as a basis for cost recovery associated respectively with asset type b. until Let Ak, Bk, , and Kk be the quantity of units of asset types a, b, , and k, the recording of which over the course of a year is used as a basis for cost recovery associated respectively with asset type k.
Therefore, one may read Ab as being the units of asset A that are used in the recovery of costs for asset type b. It is also important to remind ourselves that before the exchange rate analysis can begin, Aa, Ba, ., and Ka, as well as Ab, Bb, and Kb, and Ak, Bk, and Kk must all be regarded as known quantities. We can think of the exchange rates to be determined as prices stated in terms of one of the asset type units. Effectively, one of the asset type units will become the currency for comparing exchange values across the chargeback system. Let Pa, Pb, , Pk stand for the prices of units of a, b, , and k, respectively, with the understanding that for one of those units, the price will be 1. In contrast to the situation with Aa, Bb, and Kk, etc., the quantities Pa, Pb, , Pk are all unknown, with the exception of the price associated with the asset type acting as a currency. Finally, let A, B, and K stand respectively for the total number of units of asset types a, b, and k that are captured by the chargeback system over the course of the year, or put another way, represent in asset unit terms the total cost of the asset to be recovered by the chargeback system.
16
Thus, the exchange rates are determined by considering the following k equations: Aa Pa + Ba Pb + + Ka Pk = A Ab Pa + Bb Pb + + Kb Pk = B Ak Pa + Bk Pb + + Kk Pk = K
In other words, we have k-1 linear equations with k-1 unknowns for which there are many straightforward solution algorithms available.
In the previous paragraph, we pointed out that: Aa + Ab + + Ak = A Ba + Bb + + Bk = B and that Ka + Kb + + Kk = K
From this situation, it follows that any one equation in our list can be inferred from the remaining k-1 equations. Furthermore, since we are selecting one asset type unit to act as the chargeback systems currency, we are left with k-1 price unknowns. In other words, we have k-1 linear equations with k-1 unknowns for which there are many straightforward solution algorithms available. In Figure 2 below, there is a simple model in spreadsheet format that illustrates the main principles described above. It is intended to show that the way platforms or services are used to recover costs via a chargeback system can radically impact the value (or cost) of the platforms or services as perceived by LOBs. In the spreadsheet, the cost of the mainframe unit is set to 1. Hence, the relative values of the other platforms or services are ultimately expressed in terms of the mainframe units. The selection of the mainframe unit as 1 is arbitrary. Any other unit could likewise have been chosen as the fundamental currency for the chargeback system. However, the relative values will remain the same no matter what currency is decided upon. When organizations use a spreadsheet of this type as an analytical tool, we recommend that they begin by selecting the mainframe unit as the fundamental currency.
17
Figure 2 META Groups Simple Illustrative Chargeback Model

z/OS Unix Network Equation Coefficient Coefficient Coefficient Constant 1 1 1 1 -1 2 1 1 -1 6 2 2 z/OS Unix Network Equivalent Equivalent Equivalent 1.00 2.00 3.00 0.50 1.00 1.50 0.33 0.67 1.00
Equations for: z/OS Server Unix Server Network
Solution 1 2 3
Note: This model is designed to illustrate concepts put forward in the associated META Group white paper. It is not a chargeback model per se.
Source: META Group
As is argued in this paper, META Group has found that many Global 2000 chargeback systems tend to make the mainframe platform appear more relatively expensive than it actually is, due to its effectiveness as a cost recovery instrument. Beginning with a mainframe-based currency can make that pathology especially transparent. It is worth noting that not all asset types need to be used to recover the costs for any given asset type. If it happens that an asset type is not used, the number of units associated with that asset type in the appropriate equation is zero. In summary, once an ITO has solved these equations, it will be able to state just how much a billable unit of one platforms services is worth in terms of the billable units of another platform.
18
4.0 Case Histories

The following three case histories offer real-world examples of the cost-recovery and chargeback systems used by organizations.
4.1
Case History #1: A North American Bank
The banks approach to chargeback can be characterized by three fundamental goals: 1. Full usage-based cost recovery and transparency 2. Application-centricity 3. Integration with overall corporate activity-based costing (ABC) processes While the latter two goals are still in the process of realization, all three goals have had a tangible impact on the charging discipline as currently implemented.
As with most Global 2000 firms that enforce chargeback, projects and labor are charged on a time and materials basis.
As with most Global 2000 firms that enforce chargeback, projects and labor are charged on a time and materials basis. It is with regard to operational service charges that the bank exhibits thoroughness and innovation. The operational service chargeback architecture has multiple layers: 1. The first layer includes the process of collecting and analyzing the cost data associated with each of the various systems supported by the corporate IT organization. It is important to note that this is a bottom-up process. Although the overall IT budget is taken as a given, it is continually calibrated against the sum of the individual cost models for each of the technologies involved. Such a calibration process is often ignored due to the fact that for many Global 2000 ITOs, the capacity planning staff plays virtually no role in the budgeting process once projected usage estimates are submitted. In contrast, at the bank, capacity planning and budgeting are intertwined throughout the budget planning cycle. 2. On the second layer, billable units are defined for each of the various technologies or systems under consideration. Acknowledging the fact that the
19
market has not provided Unix and Windows platforms with the same kind of usage capture utilities that come standard with zSeries technology, the bank has developed it own usage capture routines where required. A basic set of prices per billable unit are then created that are intended to recover the technologys costs over the course of a year. There are no a priori guarantees that any given billable unit and associated price will in fact allow the ITO to recover the costs associated with the system or technology to which it is being applied. However, the bank has tested its units and its prices extensively and is now satisfied that (assuming no radical technology or architectural shifts) the chargeback system will hold up with relatively minor modifications for the next few years. Any The major business applications are modifications will stem primarily modeled in terms of how userfrom overall budget increases or decreases. Once again, close meaningful transactions flow across cooperation with capacity planning different technologies or systems. has been fundamental here. 3. On the third layer, the bank takes a radically different approach. The major business applications are modeled in terms of how user-meaningful transactions flow across different technologies or systems. To date, the development of these models has been a largely manual process, but the models are highly detailed and have been built with the cooperation of both application development and operations teams. With the application models in hand, the cost of a transaction is then calculated, using the billable units and prices resident on the systems second layer. This cost then becomes the price for a transaction associated with the application. In essence, we are dealing with somewhat indirect mapping. Transactions are assigned a cost based on the number of second layer billable units they typically generate as they are processed. There is no guarantee that a given transaction will always generate the same number of billable units, and the use of shared or consolidated infrastructure components could make it difficult, if not impossible, to actually associate a billable unit with any given transaction. Therefore, there is always the possibility that cost recovery based on transactionbased charges will not zero out. Testing is critical for ensuring that it all works out, and fortunately the bank has undertaken this process of cost-recovery validation. Transaction-based charging currently covers approximately 70% of the IT operational budget, but the strategy is to recover all, or almost all, of the budget in this way.
20
The level of satisfaction with the chargeback system is high. This has less to do with the detail of its first- and second layer cost analyses than it has to do with the focus on transaction-based charging. The various lines of business greatly appreciate receiving bills that are articulated in terms that are meaningful to them. In fact, the perceived legitimacy of the IT operational chargeback is so high that the IT organization has become a center of excellence in the banks overall effort to analyze and manage business processes according to ABC principles. Despite the focus on transaction charging, however, the underlying cost analysis and willingness to create homegrown usage-tracking technology have allowed the bank to create a system that reflects the true costs associated with its technologies and platforms. The user-friendliness of the internal bills themselves would not be able in the long run to overcome a problem in the economic fundamentals.
4.2
Case History #2: A European Telecommunications Firm
A large European telecommunications firm is currently in the process of radically modifying its chargeback system. Historically, the system had charged on a usage basis for a heterogeneous mainframe environment and used a fixed Pressure to modify the existing monthly charging structure to recover costs costing and pricing methods for its ever-growing population of Unix and came from the increasing use desktop platforms. Pressure to modify the existing costing and pricing methods came from the increasing use of external service providers for the management of infrastructure operations. As these service providers introduced usage-based, variable pricing, the IT organization felt compelled to harmonize its internal chargeback with the external bills.
of external service providers for the management of infrastructure operations.
This work is still in progress. A major issue the ITO faces is the lack of tools for capturing usage-based data, particularly for Unix platforms. Although the ITO recognizes that these tools are available on the market, the lack of local or easily obtainable support for professional services has undermined the tool selection process.
21
Another major issue stems from difficulties with cost allocation. Historically, nonmainframe infrastructure was tightly coupled with individual applications. In virtually all cases, if a given application used Unix or Historically, non-mainframe infrastructure Windows environments, the was tightly coupled with individual environments deployed were applications. In virtually all cases, if a associated exclusively with that application. During the past two given application utilized Unix or years, however, the ITO has Windows environments, the come under increasing pressure environments deployed were associated to consolidate infrastructure exclusively with that application. wherever possible, and many applications now share underlying infrastructure resources. Determining how to carve up platform resources presents a major conundrum assuming resource consumption can even be measured. Furthermore, although outsourcing is likely to extend across an even larger segment of the firms infrastructure, the company has concluded that the applications built on top of that infrastructure will remain in-house and should be billed independently of the resources at the infrastructure layer. Segregation of application resource consumption units from infrastructure resource consumption units is also a problem the company believes it must address. Finally, the firm is increasingly committed to the Information Technology Infrastructure Library (ITIL) process definitions. In the forthcoming reorganization of its documentation, the ITIL will now include a new conceptualization of the financial management process to which the ITO is compelled to conform. Unfortunately, the specifics of that conceptualization currently remain unknown, which puts another brake on the refurbishment of the chargeback system. Therefore, although the organization recognizes the need to modify its chargeback capabilities in an IT context, where external service providers are playing an ever larger role, progress is slow and uncertain due to a combination of lack of effective tool availability and lack of clarity regarding the approach to take.
4.3
Case History #3: A European Bank
The bank continues to be an environment where mainframe-based applications play a dominant role in the business. Hence, its operational service chargeback system is predominantly built on top of usage-based statistics derivable from SMF (system management facility) records. CPU seconds and megabytes of disk storage are the primary billable elements. Nonetheless, the ITO is careful to
22
associate any consumption of these elements with business applications. The result is that, although users may find the billable elements themselves a bit arcane, there is little questioning with regard to cross-subsidization. The chargeback process is intimately tied to the capacity planning process. At the start of a budget cycle, the capacity planning staff projects usage in terms of the SMF-generated billable elements, and the projected IT budget is divided by the number of projected billable units, yielding a price per billable unit. However, no adjustments are possible during the course of the year. If the capacity planners have calculated their numbers incorrectly, the ITO bears the risk. In highly heterogeneous or highly volatile environments, this approach could prove quite risky indeed. Yet the stability of the banks environment and the extensive experience embedded in the chargeback system mean that the META Group has found price stability ITOs prices are viewed as legitimate to be one of the key factors affecting a by the lines of business and the user communitys perception of the budget is recovered within an acceptable degree of accuracy. ability of an ITO to behave like a META Group has found price stability to be one of the key factors that affects a user communitys perception of the ITOs ability to behave like a business rather than a cost center. When prices are allowed to fluctuate even changing just one or two times a year the user community finds it difficult to use price as a means of assessing the business impact of its IT resource consumption and comes to doubt the ITOs ability to forecast requirements. In general, price fluctuation leads the user community to not take seriously the bills they receive from the ITO and instead to regard them as a meaningless, timeconsuming aggravation. The banks ITO is aware of this, and from a chargeback point of view, it anticipates with some trepidation the small but growing deployment of applications distributed over Unix, Linux, and Windows platforms. The banks IT organization sees three problems: 1. Usage tracking utilities on these platforms are nowhere near as mature as they are for zSeries environments.
The chargeback process is intimately tied to the capacity planning process.
business rather than a cost center.
23
2. Even assuming that these utilities might be made available, the ITO has no accumulated experience to use in selecting the right billable elements. 3. It is inevitable that different instances of the same transaction type will consume different amounts of resources (however they are measured), particularly when IP network technology is involved in linking the supporting infrastructure together. This means that in distributed environments, prices will either be arbitrary and do a poor job of recovering costs, or users will find it difficult to associate costs with their actions. Each of these challenges could be overcome, but only if the bank is willing to make significant investment in the expansion and refurbishment of the existing chargeback system. This would also require rethinking of the Organizations that currently support a internal economics of the banks full chargeback system for distributed chargeback process. environments as well as mainframe platforms tend to spend about 3% of Organizations that currently their overall IT budget on chargeback support a full chargeback system system support and maintenance. for distributed environments as well as mainframe platforms tend to spend about 3% of their overall IT budget on chargeback system support and maintenance. The bank, on the other hand, spends closer to 0.5% of its budget. Hence, the banks ITO faces a dilemma when confronting an increasingly distributed application platform. It must either maintain existing chargeback quality, but at a considerably greater expense, or keep the current cost structure and accept inaccurate or fluctuating pricing schemes. Neither alternative is appealing, but the option of keeping the current cost structure and accepting inaccurate or fluctuating pricing schemes will severely undermine the IT organizations standing within the bank as well as its ability to evolve into a full-blown internal service provider. Will Cappelli is a vice president with META Group (EMEA), and Robert Redgate is a director consultant with META Group Consulting. For additional information on this topic or other META Group offerings, contact info@metagroup.com.
24
About META Group

Return On IntelligenceSM
META Group is a leading provider of information technology research, advisory services, and strategic consulting. Delivering objective and actionable guidance, META Group's experienced analysts and consultants are trusted advisors to IT and business executives around the world. Our unique collaborative models and dedicated customer service help clients be more efficient, effective, and timely in their use of IT to achieve their business goals. Visit metagroup.com for more details on our high-value approach.

Meta Chargeback Pain or Gain (Dec2004) - With Cases

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Meta Chargeback Pain or Gain (Dec2004) - With Cases

Uploaded by

Copyright:

Available Formats

metagroup.

Chargeback Pain or Gain:

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Management Summary ............................................................................. 2 Chargeback Structures............................................................................. 4

Setting Relative Prices............................................................................ 13

Case Histories ......................................................................................... 19

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

1.0 Management Summary

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

2.0 Chargeback Structures

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Factors Driving Chargeback

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

The Controversy Surrounding Chargeback

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Figure 1 Financial Management System Architecture Future State

Mediation engine also balances across multiple IT customers

BRM Core Chargeback Tool

Business Process Cost Determination

Business Event Model

Mediation Engine (Prices to Billable IT Events)

Chargeable Business event

IT Event (e.g., MIPS Consumed)

Asset Repository (Cost)

Source: META Group

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Cost Allocation for Shared Services and Infrastructures

Pain Sharing Versus Gain Sharing

a resource consumption-based cost allocation method for either software or hardware.

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

pain borne by the corporation is

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Choosing Between Pain and Gain

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

3.0 Setting Relative Prices

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

recovery for that asset.

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

A More Complex Case

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

The General Case

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

In the previous paragraph, we pointed out that: Aa + Ab + + Ak = A Ba + Bb + + Bk = B and that Ka + Kb + + Kk = K

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Figure 2 META Groups Simple Illustrative Chargeback Model

Equations for: z/OS Server Unix Server Network

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

4.0 Case Histories

Case History #1: A North American Bank

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Case History #2: A European Telecommunications Firm

of external service providers for the management of infrastructure operations.

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

Case History #3: A European Bank

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

The chargeback process is intimately tied to the capacity planning process.

business rather than a cost center.

Chargeback Pain or Gain: The Critical Decision Facing CIOs Today

About META Group

You might also like