Skip to main content

ITSM - The A B C’s of Financial Management

At the core of IT Service Management is the ability of the service provider to align capabilities to meet business requirements.  Not only is it expected that the service provider does this but today’s market requires that we provision faster than ever before for the least amount of cost. This requires a shift from looking at costing models that focus primarily on components such as HW, SW, or other infrastructure costs to a model that looks at what is it costing us to provision the end-to-end service.  When we think of Financial Management most will immediately think of number crunching, bean counters, and all those mathematical formulas that go along with that.  It is all of that.  We need to be able to create business cases and to justify the cost of new or changed services in our environment. Financial Management for IT services will certainly include calculations for Return on Investment and Internal Rate of Return as well as assistance in assessing the overall Value on Investment.

In addition to understanding portfolio management and creating service catalogs, the ITIL Service Offerings and Agreements class discusses best practices for Financial Management and the three sub-processes that are required for success.  These include:

A)     Accounting
It is through standardized accounting methods, ledgers and procedures that we can track our IT spend. We must account for where did the money go?  Accounting activities will also ensure a cost model framework that will allow the service provider to determine costs and also ensure that they are allocated correctly.  Cost models are utilized to understand the impact of new or changed services from a financial perspective.   ITIL Best Practice states “Knowing where money has been spent does not explain why the money was spent, which services it was used for and whether the customer received value. “  Accounting will ensure a cost framework where direct and indirect charges can be allocated to a service/customer and assist in understanding not only where the money was spent but most importantly why.

B)      Budgeting
Truly Financial Management is all about funding and overall financial stewardship.  Budgeting process activities allow the service provider to predict and control the allocation of funds to the organization. Budgeting is a forecast while accounting is actual.  You could say that through the periodic negotiation and budget cycles the determination is made for “What money will be made available” and then through accounting activities we track “Where did that money go”. 

C)      Charging
Charging is the only one of these three sub-processes that is optional.  All invoicing for charges must be clear and concise and not ambiguous to the customer being billed. If you are provisioning a service to an internal business unit there may be some notional charging (funny money) but perhaps no real or hard charging is taking place.   Charging creates a sense of value and greater appreciation for the IT services delivered to internal customers.  Charging for services provides the business with more accurate information and allows business leaders to make informed decisions about the use of their technology.

So there you have it! Financial Management for IT Services is not only comprised of the (one’s, two’s and three’s) or the number crunching, it is really all about the A, B, C’s of Financial management.  Accounting, budgeting and charging process activities ensure good overall financial stewardship for service providers.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…