In the previous article I discussed the subject of Billing and Chargeback. This entry discusses some of the issues raised in that post as additional considerations.
Chargeback and Standards
Implementing efficient standards is a given in any IT organisation. However inevitably what should be a single standard always turns out to be partial implementation of multiple standards as time progresses. This occurs because standards change; companies acquire other companies and their technology; companies expand and so on. Sometimes it is simply too cost prohibitive to retro-fit new standards especially when things like server names are intrinsic to the installation of a software product (like databases).
Irrespective of the issues, it is still necessary to adhere to standards in order to implement effective chargeback and billing. After all, resources have to be attributed to owners at some stage. This means maintaining an efficient CMDB (Configuration Management Database) relating IT resources to business owners/customers within the organisation. Whether that is via a spreadsheet or custom DB doesn’t really matter; it’s the content and its accuracy that counts.
As storage resources are provisioned, then so these standards should be maintained. I always strive to ensure any resources can be mapped back to a server or business unit. For example, zoning names should contain the server name as a minimum. On storage arrays, storage groups should be related to the host/owner as should WWN visible names. The format of fields should be consistent too, in order to enable scripts to process the values; choose consistent separators between fields (like the ‘_’ symbol) for example.
Chargeback Measuring Tools
If the standards are right, then extracting the data for billing should be simple. The process may be as basic as using scripts to collect data; it may mean using the reporting features of your provisioning software, as most tools have some kind of reporting mechanism. It may mean using a bespoke reporting tool, like Storage Fusion’s SRA product. However it is achieved, the requirements are simple; map configuration information to the service you are offering and assign costs to customers/owners on that basis. For example, if your charging is based on tiers of storage, the reporting/measuring process needs to be able to identify the tier types. Making the Service Catalogue too complex at the outset can be self defeating if billing can’t easily be implemented.
Chargeback Measuring Interval
How frequently should you measure and/or charge? I always find this subject interesting as there are ways for customers to avoid paying if they are clever. Imagine the following scenario; billing is run monthly on the last day of the month and charges are accrued on assigned storage on that date. However the storage team are able to turn around requests for provisioning/decomissioning within 48 hours. So, for your project, you request space on the 2nd day of the month, run all the analysis you need, back up your data and return the storage 3 days before the end of month, at which time the resources are returned to the free pool and when billing occurs, the customer pays nothing.
Whilst this example is an extreme case, and I doubt whether most users would be in a position to take advantage, it demonstrates that a badly designed service catalogue, delivery structure and billing mechanism can lose money. Alternatively, measuring utilisation on a daily basis could be time consuming and expensive to operate, therefore a compromise has to be found and this will depend on your specific circumstances. Some options could be:
- Bill monthly on a fixed date; assume customer inertia will mean very little “cheating” of the system will occur. Build that into the overall cost.
- Bill monthly and include any provisioning requests made that month — a minimum charge of one month regardless.
- Sample data daily or weekly and bill monthly based on average consumption.
There are no specific rules to abide by here. What’s important is the way in which billing, product catalogue and operational management occur are all lined up and consistent.
