Defining, Modeling & Costing IT Services
Integrating Service Level, Configuration &
Financial Management Processes
1. INTRODUCTION
In our cost
driven economy IT is facing increasing pressure to account for and reduce
cost wherever
possible. The old axiom “You must do more with less” has never had such an
impact on IT operations and support as it does today. Thousands of IT managers
are being placed in a situation which forces them to defend their staffing
levels against both internal as well as external threats. To address this
situation, IT executives are being forced to better understand the services
they are providing and to provide an accurate cost benefit analysis of why the
services they offer are a better value than the services being offered by
external groups who at the very least offer the promise of fixed or at least known
costs.
Of course, the
basic requirement to do this is to have a clear definition of what services the
IT organization provides, the components and resources that make up the service
and what the associated costs for these services are. Understanding the scope,
characteristics and costs of defined services allows for better management of
the IT infrastructure as a whole. The sad fact of the matter is that very few
IT organizations can articulate what they do at this level of detail. Part of
the reason for this lack of information is due to the relative process maturity
and integration being practiced within many IT organizations.
This paper will
examine the fundamental steps for:
• Defining IT services
• Modeling IT services in a Configuration Management Database (CMDB)
• Developing service based IT costing models
These activities
are part of three IT processes (Service Level, Configuration, and
Financial
Management For IT) as documented within the Information Technology
Information
Library (ITIL®). While other processes have a relationship to this topic,
these processes
contain activities which directly related to the problem statement outlined above
and will be the focus of this discussion.
2. DEFINING IT SERVICES
It is often said
that in order to improve “something” one must first define it! This is no
less true when
dealing with the collection of activities that IT organizations execute for their
business customers. Typically when looking at an IT organizational chart one
can see a rudimentary breakdown of IT services defined at the directorate or
senior
management level.
Common names for these structures fall under the categories of:
• Application Development
• Operations
• Facilitates Management
• IT Support
• Hosting
• Security
• Service Delivery
• IT or Architectural Planning
• Etc.
These structures
begin to allude to the “professional” IT services which are being
delivered to the
customer and provide a starting point on how a certain category of
services can be
defined that are understood by both the business and the IT organization. While
these structural names facilitate the definition of IT services they also
promote a commonly held belief that IT services are silo or departmental based
when this is not always the case. Much like a process an IT service typically
crosses organizational and functional boundaries.
A major component
of Service Level Management is the definition of IT services within a Service
Catalog from which Service Level Agreements are negotiated with the client.
The following
diagram illustrates how Service Level Management defines IT services, publishes
them in a comprehensive Service Catalog and then develops Service Level
Agreements based
on these definitions with its customers.
The first step in
the creation of an IT Service Catalog is the definition and development of a
comprehensive list of IT services and systems that the IT organization provides
to its customer base. In order to accomplish this task it is important to
understand some basic definitions around types and classification of services.
IT Service:
• One or more technical or professional IT capabilities that enables a
business process.
An IT service
exhibits the following characteristics:
_ Fulfills one or
more needs of the customer
_ Supports the
customer’s business objectives
_ Is perceived by
the customer as a coherent whole or consumable product
IT System:
• An integrated composite that consists of one or more of the processes,
hardware,
software,
facilities and people, that provides a capability to satisfy a stated need or
objective
_ Is a collection
of resources and configuration items or assets that are necessary
to deliver an IT service
_ An IT system is
sometimes referred to as a Technology Solution
Configuration
Item (CI):
• A component of an IT infrastructure that is part of an IT system
_ A CI is an ITIL
term for what is often known as an IT Asset
_ CIs may vary
widely in complexity size and type – from a document or policy
to an entire system or a single
module or a minor hardware component
2.1 Technical & Professional Services
When defining IT
services the first order of business is to understand that there are two basic
types of services that IT provides. These two types can be classified as either
“Technical” or “Professional”
services.
A “Technical
Service” is defined as a technology based capability that the customer
consumes or uses
in order to facilitate a business process or function. Examples of
Technical
Services are:
• Email
• File / Print
• Application based services
• Network or internet access
• Office or desktop productivity
• Voice communications
• Etc.
A “Professional Service” is defined as the value added
activities that IT staff provide in order to support, maintain, monitor or
ensure the consistent and reliable delivery of the technical services. Examples
of Professional Services are:
• IT Architecture and Engineering
• IT Security
• IT Support
• Project Management Services
• Procurement Services
• Application Development and Enhancement Services
• Etc.
2.2 Service Classifications
Along with
Service Type it is also necessary to understand that services should be
separated
according to three basic classifications. These classifications are especially
important when
the time comes to apply them to a costing model. It is important to
understand that
the list of services distinguished under these classifications must be
determined by
each organization and will change according to the environment or
business model being
employed.
Core Or
Essential Services:
• A Core Service is a service which is required by all business stakeholders
and for
which each line
of business stakeholder must pay an appropriate share. These
services are like
“Air”, you need them to exist and there is no option to opt out of
their use or
consumption. Typical examples of Core Services are:
_ Data \ LAN
_ Email
_ IT Support
_ Voice
_ Security
Subscription
Services: 簽訂合約
• A Subscription Service is a service that can be chosen in an “A La Carte”
manner
based on the
business function the customer is engaged in. These services will only
appear on the
client bill of those clients that specifically use or subscribe to them.
Examples of
Subscription Services are typically application based services and are
described
according to the business process or function they support.
_ Enterprise Resource Planning (ERP) Services
_ Power Generation
Systems
_ Online Banking
_ Trading
Applications
_ Human Resources
Management
_ Market Research
_ Enhanced Desktop
Management or Forward Deployed Support
_ Etc.
Discretionary
Services: 使用才付費
• Discretionary Services are services that IT provides on a pay-as-you-go
basis. These services are typically only charged back to a client if the client
requests them for a special activity outside a standard service package.
Examples of Discretionary
Services are:
_ Project
Management
_ IT Consulting
_ Architectural
Reviews of new technology
_ Procurement
Services
_ Etc.
The full
description and detailing of these services in an IT Service Catalog around
various options of
level and availability is the domain of Service Level Management and is outside
the scope of this paper. For the purposes of modeling and costing it is enough that
services have been defined and classified as a design input for Configuration Management
and IT Finance. Going forward it is critical that the service definitions used in
costing and billing is kept in alignment with the Service Catalog.
2.3 Steps For Defining IT Services
The following
section defines the logical and sequential steps to define a list of IT
services. Those
steps are:
1. Define Major
Business Processes
2. Define
Enabling IT Services
3. Map IT Systems
To IT Services
4. Map IT
Components To IT Systems (This forth step is done by ITIL Configuration
Management)
2.3.1
Step 1: Define The Business Processes 定義業務流程
The
most appropriate way to define IT services is from a business or customer
perspective. To determine
this IT must understand how it facilitates the business in
enabling the
various business processes. So logically it follows that the place to start
this activity is to define what the business processes are. The following model
is taken from the ITIL book Understanding & Improving – The Business Perspective On Your IT Infrastructure. This model
breaks the business processes down into four major
categories.
• Management Processes 管理流程
• Support Processes 支援流程
• Innovation Processes 制度流程
• Primary Business Processes 主要商業流程
Each of these
categories in turn has sub-processes that need to be defined in order to get down
to a useable level of detail to start the service definition activity.
2.3.2
Step 2: Defining IT Services 定義IT服務
Many of the IT
services will be defined and named after the business process or function the
IT service facilitates. A benefit of aligning the IT service names with
business processes is that improves understanding for both the customer and IT
staff on how technology is aligned to meet business objectives.
To illustrate
this activity the “Business Support Processes”
category has been highlighted below:
Example Business Support Sub Processes: 業務支援流程範例
• Examples of typical business processes in this category are:
_ Human Resources 人力資源
_ Corporate Finance
財務
_ Office Support 公務
_ Logistics and
Facilities Management 後勤與設施
_ Communications 通訊
_ Etc.
While many of the
service names will be common from company to company, each
organization
needs to go through this exercise in order to define its personal list of IT
services. The
activity of doing this is in and of itself a learning step that helps promote a
better understanding of true business and IT alignment.
2.3.3
Step 3: Map IT Systems To IT Services 對應IT系統到IT服務
The next step in
this process comes more naturally to technical people since it involves defining
and naming the IT systems which the IT organization delivers and supports and mapping
them to the IT service definitions. Remember that an IT system is a collection of
components required to deliver a technology solution a customer. Often the IT
system inherits the name of the primary application it is delivering. Another principle to keep in mind that while there is a
single IT service definition, there are no limits to how many IT systems can be
mapped to this capability.
Some examples of
service / systems mappings are:
IT Service
|
IT System
|
Email
|
MS Exchange
Lotus Notes
|
Shared
Infrastructure
|
Data / LAN
Voice
Storage
Management
|
HR Management
|
PeopleSoft
Payroll
|
When all IT
services and systems have been defined by Service Level Management this information
is provided to Configuration Management to facilitate the design of the CMDB Object Model and to Financial
Management for the development of the Service Based Costing and Billing
Models.
2.3.4
Step 4: Map IT Components To IT Systems 對應IT元件到IT系統
The final step in
this process is the mapping of IT components or CIs to IT systems. This is the
function of the ITIL Configuration Management
process and will be modeled in the Configuration Management Database. The next
section of this paper will cover this topic.
3. MODELING IT SERVICES
Once IT services
have been defined and documented the next step is to leverage the
Configuration
Management process in order to model those services within the
Configuration
Management Database. Through object and data modeling techniques a
database of
Configuration Items can be created to present both a business service view as well
as a technology view of how CIs are related in order to support business
processes. In effect the ultimate goal of Configuration Management is to
facilitate the creation of a real-time virtual model of the IT infrastructure
in relation to how it supports and delivers IT services.
3.1 Configuration Management Objective
Configuration
Management provides a logical model of the infrastructure or a service by identifying,
controlling, maintaining and verifying the versions of Configuration Items in existence.
The goals of
Configuration Management are to:
• Account for(說明) all the IT
assets and configurations within the organization and its Services
• Provide accurate information on configurations and their documentation to
support all the other service
management processes
• Provide a sound basis for Incident Management, Problem Management,
Change Management and Release
Management
• Verify the configuration records against the infrastructure and correct
any
exceptions.
Configuration
Management is an important part of the ITIL service management
framework. It serves as
the central hub for information sharing and collaboration.
An asset, in ITIL
terminology, is called a Configuration Item. A configuration item can refer to
any type of items the organization wishes to control.
The CMDB must be
capable of registering these basic components:
Physical CIs: Server, switch, application, database, documents
etc. 實體
Logical CIs: IT services, systems, baseline records, etc. 邏輯
CI Attributes: CPU speed, serial number, version, author, purchase
date, etc 特性
CI Relationships: Parent-child, hosts, installed on, provides data
feed, etc. 關聯
3.2 Configuration Management IT Service Data Modeling
In order to model
IT services an object and data model must be developed in order to
illustrate how
different CI types are represented, which attributes they have and what
relationships
connect them. The data model dictates how the IT services are mapped into the
CMDB. The practical application of this is the creation of logical CI records
that represent IT services and how they breakdown into IT system, subsystem and
finally physical components. The concept presented by this approach allows the
physical Cis (hardware, software, documents, etc) to be related up into an IT
service chain as illustrated below.
To use an
analogy:
If
the infrastructure is the puzzle, and the CI the puzzle piece, then the
Configuration
Management
Object Model design is the picture on the puzzle box.
Just as it is
difficult to build a puzzle without the picture, it is difficult to understand
how various CI’s fit into the infrastructure without the object model.
Some key benefits
derived from this model are:
• The understanding of how CIs within the scope of the process relate to IT
business services
• How direct and indirect asset costs are related to IT services
• How availability figures relate to individual CIs, groupings of CIs and
overall
service availability targets
• Which CIs facilitate multiple IT services
• Prioritization of CIs in relation to business criticality and function
For each of the
IT business services and technical IT systems defined by the Service
Level Management
process there will be a record created in the CMDB within the logical structure.
Once this structure is built within the tool the logical structure will remain relatively
static and will not change drastically unless a new service is introduced to
the environment.
4. DEVELOPING A SERVICE BASED COST MODEL
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 center or proverbial bucket which at the end of the fiscal
period
gets upended on the table and then is divided up equally across the clients
regardless
of use.
There is little
to no ability to express accurate costs for providing services to clients, let alone
to provide an accurate tracking of how services are consumed by its
customers.This practice provides no ability to use costing as a management and
planning tool since you cannot improve what you don’t understand.
4.1 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.
An interesting
comment that one often hears when speaking to 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 bill to an
internal business
client they still have to account for the cost of provisioning IT services to
the business, and in turn receive next years budget allocation. Recently this
has become even more important with the current focus of the market being on
cost reduction 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.
Of course, the
catch here is that you need to have defined and modeled these services first before
you can cost them effectively. Trying to develop a costing methodology without implementing
the first two these steps outlined in this paper becomes very difficult if not impossible
to do accurately.
4.2 Understanding IT Costs
Admittedly ITIL
does not dictate what type of costing methodology should be employed. However,
the ITIL Service Delivery book does do a good job of summarizing the two most basic approaches of “Cost Centered Accounting” and “Activity or Service Based Costing.”
At a high level, Cost
Centered Accounting is the practice of pointing all costs and
expenses
in their direct form at a client or organizational entity. This is
traditionally the most widely used costing method since it works well with the
concept mentioned earlier of allocating the general cost of doing IT across all
clients in whatever equitable fashion can be devised.
Activity
or Service Based Costing is the practice of pointing all related costs and
expenses
at a defined activity or IT service. Once the service has been
completely costed a unit cost is defined. This
becomes the tool for understanding how the activity or service can be allocated
to a customer based on the consumption of the service.
To
further explore these concepts we need to define a few key terms.
Definitions: 三種成本類型
• Direct Costs: Clearly attributable to a single
customer\service\location
_ These costs are directly related
and are completely attributable to a specific
customer or service 可明確表示的成本對單一客戶\服務\地區
• Indirect – Shared Costs:
Incurred on behalf of all, or a number of
customers\services\locations 共用的成本
_ These costs are shared across a
number of customers and services and are
allocated according to some driver such as head count or percentage
• Unabsorbed or Overhead Costs: Are costs which can not be
directly attributed to a
customer\service\location 額外支出，特殊成本
_ These costs are not attributable to
a customer or service. Examples of
overhead costs are executive salaries, general administrative activities,
etc.
• Cost Unit: A cost unit is a breakdown
of the total cost of a service into a small unit
_ A cost unit is a breakdown of an
entire service cost into a unit that can be
allocated to a consumer. An example
of a unit cost is the cost per mailbox for
an email service charged to a line
of business.
It is
important to build a costing methodology which includes all three types of cost
since a service which is only costed based on direct costs will be
ultimately under recovered.
4.3 Service Based Costing 依據服務決定成本
By its very name
service based costing suggests an end-to-end view of the costs of
delivering an IT
service. Practically this means that a costing methodology and set of
cost centers need
to be defined using the service definitions provided by the Service
Level Management
process and as published in the service catalog. In principle this
means that the
line items appearing on the client bill are synchronized with the services as
they are defined within the SLAs and how CIs are captured and modeled within
the CMDB.
The following
figure illustrates how the principle of direct, indirect, and overhead costs all
come together to provide a complete picture of service based costing.
Based on the CIs
and roles that are modeled against the IT service in the CMDB the
direct costs for
the service can be derived fairly easily through query of the financial
attributes
recorded against those CIs that have no other service relationship. Also there will
be some CIs which are related to multiple services in a cross functional
capacity. An example would be an application server
that host multiple applications, the server in question would need to be
allocated across however many services it facilitated. 一對多的架構
4.4 Component Services 元件服務
Another element
to consider when establishing the indirect or shared costs is what’s
referred to as component services. A
component service or utility type service is a fully costed service that is not
directly displayed on the client bill or cost recovery
mechanisms.
The result of this decision is that they need to be allocated on top of a
direct or client
facing service in order to be recovered. Which services are deemed to be component
services is a decision of the IT financial process in the development of the costing
methodology. Examples of a component or utility service
would be if the IT organization wished to allocate the network service across
other services as a shared or indirect cost. A utility type of service
might be the cost associated to a data center, mainframe or raised floor
facility. These services are allocated against others which are client facing
based on some defined driver(驅動). A driver is the allocation method used to apportion the costs against other
services and might be as simple as a straight
percentage, head count, floor space, or number of components.
4.5 Service Based Costing Steps
The high level
steps for costing the services defined by Service Level Management are as follows:
Step 1: Define IT
services and systems
Step 2: Decide on
the service classification (core, subscription, discretionary)
Step 3: Model the
services and systems in the CMDB
Step 4: Decide
which services and systems will appear directly on the client bill
Step 5: Allocate
services that are not on the client bill against other services
Step 6: Define
drivers and an allocation methodology for the component services
Step 7: Define a
unit cost for the client facing service based on usage
Note: The diagram
above illustrates two fully costed services where one is presented on the
customer bill (desktop) and the other is allocated as a component services
(network) with a percentage of the overall cost of being applied to the total
cost of the desktop service.
5. CONCLUSION
In conclusion 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. Services need to be defined and managed in a proactive manner that
facilitates management decision-making. It is important to understand the
integration of
Service Level, Configuration and Financial Management and the strength of the
integrated model. One could go further to discuss the correlation to
Availability, Capacity, and IT Service Continuity which should also be
synchronized in their development and reporting with the service definitions.
Regardless of where your organization is in the pursuit of its Service
Management goals, the important thing to keep in mind
is that the true power of the ITIL framework is not in the description of best practices
for a single process, but in the integration of the overall framework.
