>> On Thu, 29 Dec 2005 10:53:49 +1000, Steven Harris <[EMAIL PROTECTED]> said:
> I like your graph, would it be too much to ask for you to explain your > charging scheme? That is always a vexed issue particularly with those > managers who make unreasonable volume or retention demands, and giving them > what they want, but charging them what it really costs for the service is a > nice stick to be able to beat them with. Not at all; I can hold forth on this at some length. (shocked, I know you are) Billing is always an exercise in shared fantasy. Pretending that this is not so will only frustrate you. You have to start with a set of principles which are politically acceptable, and then do rigorous math from those principles, ignoring that they may be insane from an engineering standpoint. My organization is (was) a so-called "Auxilliary of the State of Florida". We were mostly a State agency, but we had special accounting rules that permitted us to have bank accounts and retain money across years. This was because, as a 'data center', we were expected to regularly make purchases which were far in excess of a given year's budget. We were also permitted to bill other state agencies for our services, in real dollars, which we put into banks, and periodically bought new mainframes. My politically-acceptable fantasy principles were as follows: + Recover costs + Recover enough that the service can be prepared for growth + Don't recover more than that What are the costs? We had a director-level employee whose entire writ was answering that question; the cost evaluation experience was fascinating and educational, and not a litle painful. Your organization will have its' own standards for things like amortization, measuring benefits overhead for staff time, redistribution of front-office costs, cubage in the machine room, power and air handling, etc. etc. But we have ours, and at the end of the day (koff-months-koff) it came down to a bottom line of our annualized costs. These principles are insane. Most of our computer equipment is amortized at 4 years. For the library chassis, we're at 8 and counting. For the CPUs, we're lucky if we make it to 3. Disk is all over the map, and how do you note that my TSM disk is often cast-offs from another project? Insane. But it matches the principles, so soldier on. That was the number I was supposed to recover. Now, how should I split it up? I started out taking every measurement I could get TSM to cough up (and we all know that we can measure it MANY ways) and trying to assign numbers to them all. This was hideously complex, and incomprehensible even to the architect. I went through several iterations of simplification, and finally realized that I had the wrong end of it: The metrics for charging must be easy to measure, but that's only necessary, not sufficient. The important measures are ones over which the clients, the end-users, have direct control. They don't care about tapes, they don't need to know when I move from 3590-J to K, or B to E, or to 3592s. And if I bill them for frational-tapes, then they will be aware when I change underlying system structure. Ew. I ended up with basically two numbers: Transfer, and storage. Transfer is upload (backup, archive) and download (restore, retrieve), as measured by the acctlogs. Storage is whatever Q occ comes up with (or actually a select, but you get the idea). Pleasantly, I'm a pack rat, and retain logs and accounting logs. Every time I came up with a new set of rates, I could re-apply them to the last [period] of data. This let me start twiddling rates, seeing how I could weight billing towards one or the other. I decided that I would start off aiming for total storage charges to be about equal to total transfer charges; that is, when I add up a years' bills, about half of it should be in each category. As time has passed and costs have gone down, I've nudged one or the other rate, mostly focusing on how I'd be changing user behavior. If people are keeping too much stuff around (I had one customer seriously claim they wanted 40 copies) then the transfer cost goes down instead of the storage. I presented the completed charge algorithm to management, and it passed muster. I presented it to customers, and they screamed. We changed the inputs. Less fantasy FTE, different fantasy purchasing behavior, less theoretical total cost. This is where I realized I was dealing with a matter of shared fantasy instead of engineering. We went through several adjustments along these lines, and ended up with a rate that my customers absolutely love, at least those of them who have a grasp of the differences between TSM and running dump against a local tape drive. From the fact that they love it, I can infer that we're not charging enough. Oh well, I'm running a University service, not a business. I'll add to the fantasies reflected in my situation that much of my backup work is in fact not billed, it's "internal". This is less interesting from a dollars perspective (the Data Center pays for it one way or another) than from a "poor feedback" perspective. My internal customers have only me carping at them to help them understand and control their behavior. - Allen S. Rout - That'll teach you to ask me to explain something. :)
