meta chargeback pain or gain (dec2004) - with cases

7/28/2019 Meta Chargeback Pain or Gain (Dec2004) - With Cases

http://slidepdf.com/reader/full/meta-chargeback-pain-or-gain-dec2004-with-cases 1/26

m e t a g r o u p . c o m • 800-945-META [6382 ]

December 2004

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.”



208 Harbor Drive • Stamford, CT 06902 • (203) 973-6700 • Fax (203) 359-8066 • metagroup.com

Copyright © 2004 META Group, Inc. All rights reserved.


1

Contents

1.0 Management Summary............................................................................. 2 2.0 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 Setting Relative Prices............................................................................ 13

3.1 Internal Exchange Rates.................................................................................................13 3.2 A Simple Example...........................................................................................................13 3.3 A More Complex Case ....................................................................................................15 3.4 The General Case...........................................................................................................16

4.0 Case Histories ......................................................................................... 19 4.1 Case History #1: A North American Bank .......................................................................19 4.2 Case History #2: A European Telecommunications Firm ......................................21 4.3

Case History #3: A European Bank ................................................................................22






2

1.0 Management Summary

A chargeback system is a collection of applications, algorithms, and processesused by most medium to large organizations to allocate and recharge corporatelines of business (LOBs) and departments for IT operational costs. Despite their ubiquity, chargeback systems haveproven controversial for two reasons:

1. The cost and difficulty of developingand maintaining these systems,particularly for distributedenvironments

2. Ongoing internal resistance to the concept of LOBs receiving bills from the ITorganization, particularly when those bills were not based on easilyunderstood metrics

Until recently, most of the arguments regarding chargeback concerned thecomplexities involved in defining the appropriate units out of which to generateinternal bills as well as overcoming the technical difficulties involved in measuringthe consumption of those units once they were defined. The general conclusionhas been, “Chargeback if you must, but keep it simple and use fixed monthlycharges — possibly making some allowances for differences in quality of service.”

In the current environment, these issues,though still of some importance, pale incomparison with the issues surroundingcost allocation techniques for shared ITassets. Whatever mechanism is used for recovering costs, effective billingpresupposes 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 today’s environment, two fundamentalproblems must be solved:

1. Corporations must become adept at allocating costs for shared services andinfrastructure.

The general conclusion hasbeen, “Chargeback if you must,but keep it simple and use fixed

monthly charges ….”

Cost allocation is becoming ever more difficult as IT

architectures increasingly rely on shared layers of

infrastructure.






3

2. Once costs are allocated, corporations must develop the means to effectivelycompare 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 fundamentalproblems are still not being properly addressed. In these organizations, thecharging for data center infrastructure services (servers, storage, network, people,and environmental costs) still remainslargely rooted in the era beforedistributed computing. In this situation, adisproportionate number of IT costs areloaded onto the systems that are

perceived to be the most expensive. Thisperception may be based on the physicalsize of the system (e.g., a mainframe) or on assumptions about total cost of ownership.

META Group commonly finds that a disproportionate number of shared IT costsare still loaded on the legacy systems that once dominated the data center, butare now just one part of the total corporate IT infrastructure. Because cost is amajor driver for technology platform choices, this common misallocation can affectthe soundness of the decision-making process.

In organizations where current best practices are being implemented, the focus ison building chargeback systems that are:

1. Reflecting the real, underlying relationship between IT resource consumptionand cost accrual

2. Maintaining maps between IT and business process events and wherepossible, expressing the bills in business terms

3. Explicitly balancing unit charges among different platforms so that theyaccurately represent exchange values among different types of units

The development of these systems typically requires deep knowledge of businessprocesses and applications. It also requires integration with asset managementand capacity planning technologies and processes.

META Group commonly findsthat a disproportionate number of

shared IT costs are still loaded on the legacy systems that oncedominated the data center, but

are now just one part of the total corporate IT infrastructure.






4

We identify two alternative techniques that respond to these drivers:

• Pain sharing: Seeking to fairly allocate costs according to the added burden thateach LOB adds to the organization. In other words, each LOB inflicts “pain” on theorganization in the form of added costs to pursue its own business strategy, andthe total pain borne by the corporation is to be divided up fairly.

• Gain sharing: The technique of allocating costs with the goal of fairlyallocating the savings. For example, when a number of LOBs come to makeuse of shared services, all the LOBs taken together will usually achieve a netsaving over what they would have collectively spent if each had acquired theservice in question individually. Assuming there is no obvious way of allocatingcosts according to usage, gain sharing entails allocating costs to ensure thateach LOB or department realizes a fair share of the savings that all of themtogether have achieved.

Once the cost allocation technique is chosen, companies must choose theplatforms 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 thesystems in which it is easy to track fine-grained usage (e.g., IBM’s zSeries) bear the brunt of the cost recovery burden. It is understandable that businesses shouldapproach 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 impactcan lead, in the long run, to suboptimal platform selection and an inability to cometo grips with the true costs of IT.

2.0 Chargeback Structures

2.1 Inaccuracies and Problems With Chargeback StructuresDuring the past two years, META Group has seen the number of projects relatedto chargeback skyrocket among Global 2000 corporations. Thanks to a number

of factors, which we will discuss below,

more than 50% of the world’s major companies are developing newchargeback systems or refurbishing or extending existing chargeback regimes.However, technology and architecturaltrends make chargeback a more difficultproblem today than it was in the 70s,the 80s, or even the 90s.

On average, approximately 15% of Global IT budgets are attributableto mainframe-related purchases,

contracts, and activities, but at thesame time, 25%-30% of the IT

budget is recovered via billing for mainframe-resident services.






5

Besides the political difficulties traditionally associated with asking lines of business to

pay for their consumption of IT resources, dynamic resource allocation andvirtualization thicken the integrated infrastructural layers on top of which diverse LOBapplications are delivered. The spread of Web services and service-orientedarchitecture (SOA) designs only further aggravate the situation. Put another way, anever greater percentage of function points utilized by LOBs now reside in sharedservice buckets. This makes it virtually impossible to use technological structure as aguideline 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 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 GlobalIT budgets are attributable to mainframe-related purchases, contracts, andactivities, but at the same time, 25%-30% of the IT budget is recovered via billingfor mainframe-resident services.

After reviewing the factors that have led to the new wave of chargeback-relatedinvestment, we will examine possible solutions for both of the fundamental issuespreviously noted — that is, corporations need to become adept at allocatingshared services and infrastructure costs andthen need to develop the means to

effectively compare value of the servicesprovided by the different platforms used todeliver IT functionality to the LOBs (seeSection 1.0).

2.2 Factors Driving Chargeback During the next 12 months, investment inchargeback systems among the Global2000 will increase by approximately 10%.This increase is being driven by six largely independent factors:

1. A growing number of LOBs are obtaining the right to “opt out” of usingcorporate IT services. Effective chargeback will be required to rationalize thesedecisions and to execute them smoothly.

2. The renewed acceleration of merger, acquisition, and divestiture (MAD) activitywill drive organizations to implement and maintain chargeback to understandand manage the financial consequences of LOB addition and removal.

A growing number of LOBsare obtaining the right to “opt

out” of using corporate IT services. Effective

chargeback will be required torationalize these decisions

and execute them smoothly.






6

3. The trend toward centralization and consolidation of infrastructure greatly

complicates the understanding and management of IT costs, forcingorganizations to move beyond back-of-the-envelope or spreadsheet accounting.

4. The spread of variable pricing-style contracts will demand more carefulmonitoring and management of usage.

5. Burgeoning user demand for IT resources increasingly is being scrutinized asa possible cause of IT profligacy. Chargeback is seen as a way of managingthis 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 ITservices 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 costsassociated with the chargeback system itself. As a collection of algorithms andprocesses, 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 foundthemselves consuming on average 3%-4% of the IT budget. Furthermore,chargeback based on the detailed resource consumption statistics gathered fromdistributed systems and IP-based networks were a major technical challenge for vendors and in-house development teams alike. Economic analysis added fuel tothe fire. Chargeback was frequently justified in terms of its ability to drive a rationalallocation of IT resources, however:

1. This presupposed the existence of a market where IT resource units weretraded and meaningful prices could be established.

2. In any case, any impact on actual costs presupposed that incremental costscould be attributed to the marginal consumption of IT resource units. Yet inmany cases, marginal consumption was, for all intents and purposes, free.

Beyond all of these contributors to controversy, the largest concern stemmedfrom the inevitable political consequences of chargeback. Not only did the user community actively resent the imposition of getting bills from the IT department,






7

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 damagestemmed from the fact that the ITO would be drawn into controversies regardingthe 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 ongoinginternal resistance to the concept of receiving bills from the ITO (in particular billsnot based on easily understood metrics).

2.4 Best-Practice ArchitecturesVarious factors are forcing Global 2000organizations into the development of newchargeback systems and the extension of existing systems into the distributedenvironment, but fortunately, the technical

issues involved in capturing billable units for distributed system consumption arebeing addressed by the vendor community. In addition to the efforts of boutiquevendors like CIMS and Network Analytics, the large Infrastructure andapplication management concerns such as HP, IBM, and CA are all in theprocess of revamping their chargeback-related offerings. For example, in thecase of IBM, the Tivoli Storage Resource Manager has recently been upgradedto capture billable usage data for network-attached storage (NAS) and storage-area network (SAN)-based storage systems.

The best-practice chargeback systems now being built exhibit a commonstructure, as shown in Figure 1.

Various factors are forcing Global 2000 organizations into

the development of new chargeback systems and theextension of existing systems

into the distributed environment.






8

Historically, these systems focused on isolating IT system events that could berelatively easily tracked and billed for and whose billing could be shown togenerate sufficient “revenues” to cover the ITbudget.

As noted in Section 1.0, now the focus is onbuilding systems that reflect the realunderlying relationship between IT resource

consumption and cost accrual, maintainmaps between IT and business processevents and where possible express the billsin business terms, and explicitly balance unit charges among different platformsso that they accurately represent exchange values among different types of units.

Figure 1 — Financial Management System Architecture Future State

Source: META Group

Systems

Management

Tools

Business

Process

Asset

Repository

(Cost)

CapacityPlanning

+

Modelling

Core Chargeback ToolIncluding Visualization Capabilities

BRM

MediationEngine

(Prices to BillableIT Events)

BusinessEventModel

PricingDatabase

(ITServices)

Rating Engine Business ProcessCost

Determination

IT Event(e.g., MIPS Consumed)

ChargeableBusiness event

Mediation enginealso balances

across multiple ITcustomers

Business Unit

Now the focus is on building systems that reflect the real

underlying relationship betweenIT resource consumption and

cost accrual.






9

This typically requires deep knowledge of business processes and applications aswell as integration with asset management and capacity planning technologies

and processes.

2.5 Cost Allocation for Shared Services and InfrastructuresTo overcome this controversy, Global 2000 organizations must begin byrecognizing that cost allocation for fundamentally indivisible assets is, in fact, apolitical problem. Concerns about economic efficiency and technology architecturewill typically offer no clue with regard to the cost allocation problem. To somedegree, knowledge of business processes might serve as a guide, but businessprocess knowledge usually is not sufficiently detailed for such a purpose. Nor is itclear that the choice of one cost allocation strategy over another could be directlytied to meaningful business goals in any direct manner. Instead, cost allocation ismostly about perceptions of fairness — for example, whether or not a given LOBor department believes that it is being overly burdened with costs that impact theachievement of its specific targets.

Next, there is the need to recognize that there is no single optimal cost allocationmechanism. Perceptions of fairness will depend on how the specific costallocation problem is understood by the various stakeholders and on the specificbusiness situation.

We will now look at two alternative techniques that take these concerns intoaccount.

2.6 Pain Sharing Versus Gain Sharing Sometimes it is relatively easy to allocate costs for a given IT resource. When allresource usage can be traced to one individual or another, the total costs

associated with that resource can simplybe divided in a manner proportional toresource consumption. Increasingly,however, IT organizations are confrontedwith resources that do not lend themselvesto such straightforward treatment.

For example, when multiple applications aremounted on a single Unix server there aremany CPU cycles for which the consumptioncannot sensibly be attributed to any specific

application or even combination of applications. If an application integration platformlike WebSphere has been deployed, it is virtually impossible to develop a resourceconsumption-based cost allocation method for either software or hardware.

If an application integration platform such as WebSphere

has been deployed, it isvirtually impossible to develop

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






10

Finally, looking just a bit further into the future, if service-oriented architectures

proliferate, virtually all linkage between user actions (even higher-level applicationtransactions) and the consumption of lower-level resources will have been broken.So, how does one go about allocating costs fairly when resource consumptionfails to provide a guideline?

2.6.1 An Old Problem and a Modern SolutionThe issue of appropriate cost allocation is, in fact, an old problem. It is one that hastroubled Greek philosophers concerned with the nature of justice, rabbinical andsecular judges trying to work out fair divisions of assets in difficult divorce cases, andgovernment authorities struggling to develop politically acceptable taxation methodsfor 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 problembeen solved in its full generality, allowing us to apply that solution to IT chargeback.

2.6.2 Allocation by ExampleWe can build an example by imagining that there is a corporation that has twolines of business — the book business and the music business. Both businessesneed server capacity, but the book business’s requirements could be satisfied bya server costing $2,000, while the music business needs the capabilities of aserver costing $3,000. However, despite the music business’s needs, this samemore expensive server would also have sufficient spare capacity to satisfy thebook business’s requirements. Given the total economics of the situation, the

corporation authorizes the expenditure on the more expensive server and directsboth businesses to make use of its capacity.

It is now up to the ITO to work out how to chargeback for this cost. Clearly, thereis no easy way forward. The cost cannot be split evenly between the twobusinesses. Nor can the ITO simply charge the music business the differencebetween $2,000 and $3,000. Suppose that, if the music business had exclusiverights to the server’s resources, it would only consume half of the server’scapacity. The server is, after all, a corporate resource, and it would seriouslydistort the music business’s operational cost metric if it had to subsidize the entireover-capacity available on that resource.

So, what should the IT organization do? A first step would be to lay out the variouspossible cost scenarios in what game theorists call a “characteristic function.” Wewill 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.






11

• 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 SharingGiven this cost scenario schedule, the ITO now gets down to the work of allocatingthe 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 “painsharing,” seeks to fairly allocate costs according to the additional burden that eachbusiness adds to the corporation in eachpossible cost scenario in which it is

involved. (In other words, each businessinflicts “pain” on the corporation in the formof added costs to pursue its own businessstrategy. The total pain borne by thecorporation is to be divided up fairly.)

To consider how this would be enacted, letus start with the music business, which isinvolved in two of the four scenarios. In thethird scenario, the music business causes an extra $3,000 to be spent, and in thefourth scenario, it causes an extra $1,000 to be spent. On average, therefore, themusic business causes $2,000 to be spent by the corporation. On the other hand, inthe second scenario, the book business causes an extra $2,000 to be spent, while inthe third scenario, it is responsible for no additional spending. Therefore, the averageextra expenditure attributable to the book business is $1,000.

2.6.4 Gain SharingThis is the second way of considering the cost allocationproblem. As noted in Section 1.0,when a number of LOBs or departments make use of sharedservices, all the LOBs takentogether will usually achieve a netsaving compared to what theywould have collectively spent if each had acquired the service inquestion individually. Now,assuming there is no obvious wayof allocating costs according to

Pain sharing is where eachbusiness inflicts “pain” on the

corporation in the form of added costs in order to pursue its own

business strategy. The total pain borne by the corporation is

to be divided up fairly.

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 havecollectively spent if each had acquired the service in question individually. Thetechnique of allocating costs with thegoal of fairly allocating the savings is

called “gain sharing.”






12

usage, how does one allocate costs to ensure that each LOB or departmentrealizes 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 ownwould have had to pay $2,000 for its required capacity, while the music businesswould 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 thateach charge reflects an equal amount of savings over what each business wouldhave had to pay if it had bought such capacity on its own. Although pain sharingis 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 gainshare, while a loss to the LOB,actually reflects that LOB’s overallcontribution to corporate profitability.

With this example, the result turns outto be the same whether one gainshares or pain shares, and in manyreal-life situations, this turns out to bethe case. Nonetheless, there are

many instances where the twoalgorithms generate very differentresults. Therefore, the ITO and thebusiness itself must be carefulregarding the kind of “fairness” theywant to enforce.

2.7 Choosing Between Pain and GainThere are some clear guidelines for choosing between pain sharing and gainsharing, depending on the business situation:

• If a significant percentage of IT assets are fundamentally indivisible and thebusiness is not anticipating a significant increase in resource consumption, or a significant expansion or reduction of the user base (e.g., not anticipating amerger or divestiture), then pain sharing is called for.

When a significant percentage of IT assets are fundamentally indivisibleand 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 amerger or divestiture), pain sharing

is called for. Otherwise, the gainsharing technique is recommended.






13

• Otherwise, the gain sharing technique is recommended, since it ensures acertain amount of constancy and predictability in the face of otherwise radical

change.

3.0 Setting Relative Prices

3.1 Internal Exchange RatesOnce costs are allocated to the various user communities, most chargeback systemarchitects face the difficulty of comparing the costs of using various platforms. Thisdifficulty is the result of most organizations not having explicitly developed a“currency” that shows, for example, what the fair internal “exchange rate” between aunit of Unix resource consumption and a unit of zSeries resource consumption.

The key insight required for addressing through this issue is the recognition thatcost recovery is independent of cost accrual. An organization may pay a certainamount of money to acquire a Unix platform, yet actually recover the money spentvia a zSeries platform-based bill.

3.2 A Simple ExampleLet 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 anetwork (in this case, a TCP/IP network, for simplicity’s sake). Suppose that thebase 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 someform of usage basis. Surveying the various alternatives, organization executivesdecide 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 system’sfunctioning 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.5million CPU cycles and 1 million IP packets.

4. Costs for the network were recovered via applications that consumed 0.5million CPU cycles and 3 million IP packets.






14

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 referenceto the external cost of the items involved. The only critical issues are the totalnumber of measurable units thathave been attributed to theassets involved and which unitswere used to recover the external

costs (whatever they may havebeen) of the assets involved.

Second, historically,organizations have tried to makethe 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 nonecessity that they do so, and the increasing complexity of systems will undermineany 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 remarkcan be made about IP packets.

In any chargeback system such as that represented above, there is a uniqueexchange value that holds among the assets that constitute the IT base. To seethat this is the case, let us imagine that the 1.5M CPU cycles and the 1M IPpackets “produce” the 2M CPU cycles, while the 0.5M CPU cycles and 3M IPpackets “produce” the 4M IP packets.

Next, imagine that at the end of the year, IT operations has ended up with the 2MCPU 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 IPpackets to recreate the 2M cycles required for the following year. Also, how willnetwork operations acquire enough CPU cycles to recreate the 4M IP packetsrequired for the following year?

When considering the units that IT operations possesses, we see that thissuborganization has 0.5 million CPU cycles in excess of what it requires to produce2M CPU cycles. At the same time, it has a deficit of 1M IP packets. On the other

Historically, organizations have tried tomake 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.






15

hand, network operations has 1 million more IP packets than it requires for nextyear’s production, while finding itself 0.5M CPU cycles in deficit.

Therefore, to reproduce this year’s results next year, both suborganizations wouldaccept an exchange rate of 1 CPU cycle equaling 2 IP packets.

3.3 A More Complex CaseThe existence of a unique exchange rate is not the result of only two resourcetypes being involved. Suppose, for example, that storage units were also involved.Imagine that the organization consumed, in addition to the resources mentionedabove, 5M megabytes of storage and recovered costs for this new resourceaccording 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 theother 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 withthree or more asset types. In fact, the functioning of the exchange rate presupposesthe ability to effect what amounts to “triangular trades” among the asset “owners.”






16

3.4 The General CaseThese points can all be restated in general terms that bring out the mathematicalstructure 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 istrying 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 costrecovery 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 costrecovery 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 costrecovery associated respectively with asset type k.

Therefore, one may read “Ab” as being “the units of asset A that are used in therecovery of costs for asset type b.” It is also important to remind ourselves thatbefore 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 thecurrency for comparing exchange values across the chargeback system.

Let P a, P b, …, P k stand for the prices of units of a, b, …, and k, respectively, withthe understanding that for one of those units, the price will be 1. In contrast to thesituation with Aa, Bb, and Kk, etc., the quantities P a, P b, …, P k 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 assettypes a, b, and … k that are captured by the chargeback system over the courseof the year, or put another way, represent in asset unit terms the total cost of theasset to be recovered by the chargeback system.






17

Thus, the exchange rates are determinedby considering the following k equations:

• Aa P a + Ba P b + … + Ka P k = A• Ab P a + Bb P b + … + Kb P k = B--• Ak P a + Bk P b + … + Kk P k = K

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 theremaining k-1 equations. Furthermore, since we are selecting one asset type unit toact as the chargeback system’s 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 illustratesthe main principles described above. It is intended to show that the way platformsor services are used to recover costs via a chargeback system can radicallyimpact 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 relativevalues of the other platforms or services are ultimately expressed in terms of themainframe 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, werecommend that they begin by selecting the mainframe unit as the fundamentalcurrency.

In other words, we have k-1

linear equations with k-1unknowns for which there aremany straightforward solution

algorithms available.






18

As is argued in this paper, META Group has found that many Global 2000chargeback systems tend to make the mainframe platform appear more relativelyexpensive than it actually is, due to its effectiveness as a cost recovery instrument.Beginning with a mainframe-based currency can make that pathology especiallytransparent. It is worth noting that not all asset types need to be used to recover thecosts for any given asset type. If it happens that an asset type is not used, thenumber 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 justhow much a billable unit of one platform’s services is worth in terms of the billableunits of another platform.

Figure 2 — META Group’s Simple Illustrative Chargeback Model

Source: META Group

1.001.503.0032-121Network

0.671.002.00221-11Unix Server

0.330.501.0016111z/OS Server

Network

Equivalent

Unix

Equivalent

z/OS

EquivalentSolution

Equation

Constant

Network

Coefficient

Unix

Coefficient

z/OS

CoefficientEquations for:

1.001.503.0032-121Network

0.671.002.00221-11Unix Server

0.330.501.0016111z/OS Server

Network

Equivalent

Unix

Equivalent

z/OS

EquivalentSolution

Equation

Constant

Network

Coefficient

Unix

Coefficient

z/OS

CoefficientEquations for:

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.






19

4.0 Case Histories

The following three case histories offer real-world examples of the cost-recovery andchargeback systems used by organizations.

4.1 Case History #1: A North American Bank The bank’s approach to chargeback can be characterized by three fundamentalgoals:

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 theprocess of realization, all three goalshave had a tangible impact on thecharging discipline as currentlyimplemented.

As with most Global 2000 firms thatenforce chargeback, projects and labor are charged on a time and materials basis.

It is with regard to operational service charges that the bank exhibits thoroughnessand innovation.

The operational service chargeback architecture has multiple layers:

1. The first layer includes the process of collecting and analyzing the cost dataassociated with each of the various systems supported by the corporate ITorganization. It is important to note that this is a bottom-up process. Althoughthe overall IT budget is taken as a given, it is continually calibrated against thesum 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 Global2000 ITOs, the capacity planning staff plays virtually no role in the budgetingprocess once projected usage estimates are submitted. In contrast, at thebank, capacity planning and budgeting are intertwined throughout the budgetplanning cycle.

2. On the second layer, billable units are defined for each of the varioustechnologies or systems under consideration. Acknowledging the fact that the

As with most Global 2000 firmsthat enforce chargeback,

projects and labor are charged on a time and materials basis.






20

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 thetechnology’s costs over the course of a year.

There are no a priori guarantees that any given billable unit and associatedprice will in fact allow the ITO to recover the costs associated with the systemor technology to which it is being applied. However, the bank has tested itsunits and its prices extensively and is now satisfied that (assuming no radicaltechnology or architectural shifts) the chargeback system will hold up with

relatively minor modifications for the next few years. Any

modifications will stem primarilyfrom overall budget increases or decreases. Once again, closecooperation with capacity planninghas 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-meaningfultransactions flow across different technologies or systems. To date, thedevelopment of these models has been a largely manual process, but themodels are highly detailed and have been built with the cooperation of both

application development and operations teams. With the application models inhand, the cost of a transaction is then calculated, using the billable units andprices resident on the system’s second layer. This cost then becomes the pricefor a transaction associated with the application.

In essence, we are dealing with somewhat indirect mapping. Transactions areassigned a cost based on the number of second layer billable units they typicallygenerate as they are processed. There is no guarantee that a given transactionwill always generate the same number of billable units, and the use of shared or consolidated infrastructure components could make it difficult, if not impossible, toactually associate a billable unit with any given transaction.

Therefore, there is always the possibility that cost recovery based on transaction-based charges will not “zero out.” Testing is critical for ensuring that it all worksout, and fortunately the bank has undertaken this process of cost-recoveryvalidation. Transaction-based charging currently covers approximately 70% of theIT operational budget, but the strategy is to recover all, or almost all, of the budgetin this way.

The major business applications aremodeled in terms of how user-

meaningful transactions flow acrossdifferent technologies or systems.






21

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 thefocus on transaction-based charging. The various lines of business greatlyappreciate 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 thatthe IT organization has become a center of excellence in the bank’s overall effortto analyze and manage business processes according to ABC principles.

Despite the focus on transaction charging, however, the underlying cost analysisand willingness to create homegrown usage-tracking technology have allowedthe bank to create a system that reflects the true costs associated with itstechnologies and platforms. The “user-friendliness” of the internal bills

themselves would not be able in the long run to overcome a problem in theeconomic fundamentals.

4.2 Case History #2: A European Telecommunications Firm A large European telecommunications firm is currently in the process of radicallymodifying its chargeback system. Historically, the system had charged on ausage basis for a heterogeneousmainframe environment and used a fixedmonthly charging structure to recover costsfor its ever-growing population of Unix anddesktop platforms.

Pressure to modify the existing costing andpricing methods came from the increasinguse of external service providers for themanagement of infrastructure operations.

As these service providers introduced usage-based, variable pricing, the ITorganization felt compelled to harmonize its internal chargeback with theexternal bills.

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 toolselection process.

Pressure to modify the existing costing and pricing methods

came from the increasing useof external service providers

for the management of infrastructure operations.






22

Another major issue stems from difficulties with cost allocation. Historically, non-mainframe infrastructure was tightly coupled with individual applications. In

virtually all cases, if a givenapplication used Unix or Windows environments, theenvironments deployed wereassociated exclusively with thatapplication. During the past twoyears, however, the ITO hascome under increasing pressureto consolidate infrastructurewherever possible, and manyapplications now share

underlying infrastructure resources. Determining how to carve up platformresources presents a major conundrum — assuming resource consumption caneven be measured.

Furthermore, although outsourcing is likely to extend across an even larger segment of the firm’s infrastructure, the company has concluded that theapplications built on top of that infrastructure will remain in-house and should bebilled independently of the resources at the infrastructure layer. Segregation of application resource consumption units from infrastructure resource consumptionunits is also a problem the company believes it must address.

Finally, the firm is increasingly committed to the Information TechnologyInfrastructure Library (ITIL) process definitions. In the forthcoming reorganizationof its documentation, the ITIL will now include a new conceptualization of thefinancial 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 chargebackcapabilities 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 effectivetool 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 applicationsplay a dominant role in the business. Hence, its operational service chargebacksystem is predominantly built on top of usage-based statistics derivable from SMF(system management facility) records. CPU seconds and megabytes of diskstorage are the primary billable elements. Nonetheless, the ITO is careful to

Historically, non-mainframe infrastructurewas tightly coupled with individual

applications. In virtually all cases, if agiven application utilized Unix or

Windows environments, theenvironments deployed were associated

exclusively with that application.






23

associate any consumption of these elements with business applications. Theresult is that, although users may find the billable elements themselves a bit

arcane, there is little questioning withregard to cross-subsidization.

The chargeback process is intimatelytied to the capacity planning process.

At the start of a budget cycle, thecapacity planning staff projectsusage in terms of the SMF-generated billable elements, and the projected ITbudget 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 provequite risky indeed. Yet the stability of the bank’s environment and the extensive

experience embedded in thechargeback system mean that theITO’s prices are viewed as legitimateby the lines of business and thebudget is recovered within anacceptable degree of accuracy.

META Group has found price stabilityto be one of the key factors that

affects a user community’s perception of the ITO’s ability to behave like abusiness rather than a cost center. When prices are allowed to fluctuate — evenchanging just one or two times a year — the user community finds it difficult touse price as a means of assessing the business impact of its IT resourceconsumption and comes to doubt the ITO’s ability to forecast requirements.

In general, price fluctuation leads the user community to not take seriously thebills they receive from the ITO and instead to regard them as a meaningless, time-consuming aggravation. The bank’s ITO is aware of this, and from a chargeback

point of view, it anticipates with some trepidation the small but growingdeployment of applications distributed over Unix, Linux, and Windows platforms.

The bank’s IT organization sees three problems:

1. Usage tracking utilities on these platforms are nowhere near as mature as theyare for zSeries environments.

The chargeback process isintimately tied to the capacity

planning process.

META Group has found price stability to be one of the key factors affecting a

user community’s perception of theability of an ITO to behave like a

business rather than a cost center.






24

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 willconsume different amounts of resources (however they are measured),particularly when IP network technology is involved in linking the supportinginfrastructure together. This means that in distributed environments, prices willeither be arbitrary and do a poor job of recovering costs, or users will find itdifficult to associate costs with their actions.

Each of these challenges could be overcome, but only if the bank is willing tomake significant investment in the expansion and refurbishment of the existing

chargeback system. This wouldalso require rethinking of theinternal economics of the bank’schargeback process.

Organizations that currentlysupport a full chargeback systemfor distributed environments aswell as mainframe platforms tendto spend about 3% of their overall IT budget on chargeback system support andmaintenance. The bank, on the other hand, spends closer to 0.5% of its budget.

Hence, the bank’s ITO faces a dilemma when confronting an increasinglydistributed application platform. It must either maintain existing chargebackquality, but at a considerably greater expense, or keep the current cost structureand accept inaccurate or fluctuating pricing schemes.

Neither alternative is appealing, but the option of keeping the current coststructure and accepting inaccurate or fluctuating pricing schemes will severelyundermine the IT organization’s standing within the bank as well as its ability toevolve 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 onthis topic or other META Group offerings, contact [email protected].

Organizations that currently support afull chargeback system for distributed environments as well as mainframe

platforms tend to spend about 3% of their overall IT budget on chargeback

s stem su ort and maintenance.



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

Documents