Charge-back? Yes, we have to. Everyone thinks charge-back systems are unfair, and IT hates to use them. We think we've found the least-evil scheme.

October  1995

Everyone who gets even near a charge-back scheme (a method for spreading the cost for centralized computer support across the supported departments) hates the experience. Department chiefs see them as unfair, and IT could do without the programmatic and political bother. We think we've come upon a scheme that fits hand-in-glove with today's client/server environments. (1,400 words)

Mail this article to a friend

When parents of young children get together, they inevitably rank the phrases used by their kids that they hate most. Perennial contenders include:

• "Are we there yet?"
• "Do I have to?"
• "But I'm not tired!"
• "I'm getting car-sick!"

Information Technology department managers similarly gather and compare the phrases they hate most. Our favorites:

• "I need this today, tomorrow at the latest."
• "The (fill in the blank) seems slow today."
• "My PC crashed. Do you know why?"
• "Do we have to do a charge-back?"

While we hate talking about charge-back as much as the next IT managers, everyone asks us about it, so it must be important. This month, we reveal our least-despised charge-back scheme for the modern, client/server environment. We concentrate on the not-for-profit entities (i.e., net-to-zero), since most IT organizations fall into this category. However, the principles could apply to for-profit IT organizations as well.

Back in the mainframe days, we employed two methods for apportioning computer-related costs to supported departments -- utilization billing and allocation. We discuss the plusses and minuses of both, then outline our compromise.

Utilization billing
Utilization billing charges for actual computing resources consumed, including

• Disk space
• CPU time
• Network connections
• Network use
• Printing
• Staff time

Third-party accounting/utilities packages capture daily system use, then calculate (usually once a month) an intricate set of computations for billing. We found problems with these packages. They consume what we think is a high amount of disk space, and require human and CPU cycles to implement, maintain, and support them. On the user side, department chiefs couldn't understand the complex algorithms for calculating a charge like:

Disk charge = disk space x 1.125 + disk I/O's x 3.315

We didn't even understand the methodology and we supported it. Perhaps because they couldn't understand utilization billing, department chiefs felt they were charged too much. To alleviate this nightmare, IT and finance people devised the "allocation" method.

Allocate, shmallocate
Allocation is simple and is usually handled by bean counters. At each month-end close, accountants divide the total IT expense by the number of using departments and charge each the result. In a more "calculated" approach, accountants break down the percentage of utilization into using departments and "allocate" that percentage of IT costs back. For example, if the Widget Dept. used 30 percent of IT's resources, the calculation would be:

Total IT expense x .30 = Widget Dept. charge

The biggest problem in this scenario is determining that Widget Dept. really used 30 percent. This has always been a controversy because departments felt they were still overcharged! Like establishing fair income taxes, there seems no equitable way to allocate costs.

While we hate talking about charge-back
as much as the next IT managers, everyone
asks us about it, so it must be important.

How to charge-back using client/server technology
While just about everything else about client/server makes life more difficult for IT managers, ironically, charge-back is easier. Here's how we do it.

The first and probably most important charge back issue is dealing with the capital budget on the front side. We found that by first giving some capital costs for IT infrastructure back to the business units, it was easier to deal with them and meet their requirements. Let them justify the capital requirements for new business systems (hardware, software, support). This way, they determine the real cost/benefit of a new system and if it meets their business needs. IT does not shove systems down business unit throats; business units determine their own systems needs.

We also recommend that the business units justify (and have capital authority for) such infrastructure components as:

• Desktop computers
• Upgrades
• Application servers
• Printers
• Modems
• Plotters
• Other peripherals

Once installed, the asset is transferred to IT, which owns the expense budget. A key issue here is ensuring that business unit capital budgets are kept in line with IT expense budgets. This requires ongoing, effective communication-especially during the budget cycle. If the CIO budget is reduced, then it is up to the CEO to get corresponding business unit capital budget reductions.

Charge back can become
a simple methodology,
not a cumbersome headache.

Now there is no real contention between business units and IT because the business units "own" the capital and justification for IT spending is based on business requirements. To maintain this harmony continuous communication is needed between the parties involved and cannot be over-stressed -- communicate, communicate, communicate! The CIO must keep an open, direct dialogue with business unit management and business unit IT functions.

IT piece of the pie
Remember we said the business units get "some" of the capital requirements for IT infrastructure, not all! We recommend that the CIO maintain capital requirements for infrastructures such as networking, telephones, and other "utility" functions that are provided to the organization. He or she must also have expense budget authority for people, including system administration (desktop support), data center staff, and network support staff.

For infrastructure, there should also be some directives from the CEO level, such as: "Our company will have an effective enterprise-wide, global network that will help us achieve a competitive advantage." The CEO has then given the CIO authority to "spend" on the network. If these directives don't occur then there will still be cost issues between IT and the business units -- guaranteed! So, now that we've established the budget methodologies, how do we charge back?

Advertisement

KIS method
It's always best to keep things simple, even in charge back methodology. We've identified new ways to deal with capital and expense budgets, now let's look at a simple method of charge-back. For networking, determine the network charge. This consists of all network related expenses such as:

• Labor
• Leased lines
• Equipment
• Software
• Other related items

Then, divide the total network charge by the number of employees.

This becomes the "network charge" (and can be monthly or quarterly). Do the same for desktop, telephone, voice mail, etc. Add these figures together for the "total" desktop charge. Bill the using department this charge times the total number of employees in the department/division.

For the data center, define the total data center charge including hardware, labor, software licensing, maintenance, etc. Divide the total data center charge by the number of applications/servers supported to obtain a per application charge. Bill the business unit an application/server charge for each of their owned applications. For application developers/support, the charge is direct to the business unit for their development function since the development/support people report in a "dotted-line" manner to the business unit.

The business unit now has direct control of their development costs, priorities, and backlog since they have their own development resource. Billing IT's charges back to the business units is then accomplished by set internal standards, typically through general ledger accounting.

We developed the invoice inside IT, and sent it to a department server where they viewed the invoice on-line (no need for paper). The tool used was described in our October, 1994 article "Managing integrated systems."

Some might say this is another allocation method. It certainly seems that way but at least now there is a way to compare costs. On an ongoing basis we would compare the cost of our internal IT service to those provided by outside vendors and provide that information to our customers. One example would be networking. Since we know our network cost we could compare that to third-party providers.

Department chiefs can weigh the cost of IT providing the service versus getting that service from someone else (We do not dictate they use us.) This way we were able to show that we provide cost-effective service.

Presto! Happy users
Charge-back has always been a serious issue because business units were never satisfied with the cost or the level of service. We recommend re-engineering IT to become more responsive to business units and be perceived as a help, not a hindrance. Couple the re-engineering with a re-alignment of the budgets, by doing this you attack the problem, not put up more roadblocks.

Believe it or not, charge back can become a simple methodology, not a cumbersome headache.

Resources

• Disk space
  
• CPU time
  
• Network connections
  
• Network use
  
• Printing
  
• Staff time
  

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-10-1995/swol-10-unix.html
Last modified: