Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL®, IT Governance & Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronyms like ITIL, Lean, Agile, DevOps, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive

ITIL Implementation Roadmap (Financial Management for IT) – Part 12

Remember Nothing In Life Is Free!

Many of us can hear our parent’s voice drilling into our minds this simple truth!

Somewhere, somehow someone is always paying the bill for things that do not seem to have an obvious price tag!

Dawn Mular in her blog shares this perspective: Everything Costs SOMETHING, even if we can’t see the sticker!

An interesting comment that one often hears when speaking to IT organizations about the discipline of costing is that they are a “cost center” and as such, they are not in the business of charging for their services. This is often used as a convenient excuse to not look at the disciplines of IT costing in any significant detail. However the logical response to these organizations is that even though they may not provide a formal bill to an internal business client they still have to account for and report on the cost of provisioning IT Services to the business in order to receive next years budget allocation.

So call it what you want, but in both cases money is being transferred to the IT organization for services rendered. You see contrary to what ITIL suggests charging is never really optional. What is optional is the formality in which you conduct this transaction. Whether it is a formal bill or a transfer of money to an internal cost center, money is still changing hands.

Recently this has become even more important with the current focus of the market being on cost reduction, outsourcing and financial governance. IT organizations are no longer being afforded the grace they once were, and the business is demanding an accurate accounting and tracking of IT costs related to use and consumption.

While IT struggles in many areas to become more proactive in the management and delivery of its services to the client. This is nowhere more apparent then in the way that technology costing is typically done.

Regrettably what usually occurs during the year is that all IT costs and expenses are collected into a large cost centre or proverbial bucket which at the end of the fiscal period gets upended on the table and then is divided up equally across the business clients regardless of use.

Financial Management for IT Services

Objective: Financial Management is the sound stewardship of the monetary resources of the organization. It supports the organization in planning and executing its business objectives and requires consistent application throughout the organization to achieve maximum efficiency and minimum conflict

The primary activities of Financial Management include costing, accounting and recovery.  Most organizations have a rudimentary costing and budgeting process based on a technical domains instead of service architecture.  This is largely due to the missing input of other processes such as Service Level and Configuration Management.  In principle, the services defined in the Service Catalog are the same services that are modeled within the CMDB.  These same service definitions should represent the general ledger accounts and chargeable elements that appear on a client bill.  Without this integration, the Financial Management process is typically implemented along the following levels of maturity.

  1. Costing models are targeted at understanding the cost of individual or like collections of assets or resources, such as an individual server or collection of servers.  Costs for these technical components or people resources are bundled and allocated back to the business customer based on a shared allocation model not representative of actual use.  Forecasts and actual expenses are based on a technical model.  If services are defined, they are done so from a financial perspective that is not representative of the actual services delivered to the business by the IT organization.  At this point of maturity, there are no real dependencies as the Financial Management process mitigates the lack of other processes by defining costs models and chargeback systems at a best effort level.

  2. As indicated above, the services defined in the IT Service Catalog should form the basis for the IT budgets and the GL accounts defined in the costing, reporting and forecasting models.  This level of maturity requires Service Level Management to be implemented at least to the point that services are defined and are used for planning and forecasting.  In order to establish which costs are direct and indirect, Configuration Management is required to establish the relationships between components as they relate to IT systems and services.

Troy’s thoughts what are yours?

“This planet has - or rather had - a problem, which was this: most of the people on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn’t the small green pieces of paper that were unhappy. ~Douglas Adams

Posted by Troy DuMoulin on 02/17 at 09:44 PM
  1. Very interesting post Troy.

    As you said in your post, ideally the services defined in the Service Catalog are the same services that are modeled within the CMDB. But what if they are not?

    I’m currently working with an organization that has a very sophisticated cost model for charging back IT costs to the business and this cost model does combine the cost components into services. The CIO has worked closedly with the business on developing this.
    At the same time, the infrastructure/service delivery side of the IT division has developed their own service catalogue, and the services defined in it are not the same as the ones in the cost model. Is there a way to bridge the two together?

    Posted by .(JavaScript must be enabled to view this email address)  on  11/09  at  03:53 PM
  2. Hello Lee

    Sounds like there is a mis-alignment between two groups that should be working in concert. The very fact that the Cost Models look little like the Services in the Catalog cannot be positive in any circumstance that I can think of.

    However there are a few circumstances where the cost models may look a bit different than the stand alone services listed in a catalog.

    The principle where this is possible is when a Service Offering is created by creating bundles of existing services based on a customer type or consumption pattern. An example of this is when I worked with one organization that had an Office Automation Service Offering made up of Support, Email, Desktop, Virus Management, etc..

    Now saying this the Catalog can list both the stand alone services as well as the bundled Service Offerings.

    Perhaps this is one path to integration for you Lee.

    Troy

    Posted by Troy DuMoulin  on  11/09  at  06:37 PM
  3. Page 1 of 1 pages

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

What is missing: North, South, East?