This research note is restricted to the personal use of A01308944@itesm.

mx
G00210322

Four Key IT Service Management Frameworks

FOUNDATIONAL Refreshed: 25 September 2015 | Published: 22 March 2011

Analyst(s): Colleen M. Young

As IT leaders attempt to mature their IT service management (ITSM)

capabilities, they often consult external sources, such as ITIL documentation
or consultants, for appropriate tools, techniques and methods. The plethora
of approaches and widely varied semantics has generated considerable
confusion around key service management frameworks specifically, their
purpose and their relationships to one another. As a result, necessary
artifacts are inappropriately combined, omitted or misapplied to the
detriment of service effectiveness.

Gartner foundational research is reviewed periodically for accuracy. This document was last reviewed
on 25 September 2015.

Key Findings

By definition, a "service" is an action that delivers a benefit to a recipient. Services are,

therefore, intangible and must be expressed in terms of the recipient's value expectation.

Technological components and processes are not services; they are service fulfillment
elements.

The purpose of ITSM is to optimize service outcomes, not process outcomes or technological
asset utilization.

IT organizations that invest in ITSM tools or management artifacts without first articulating their
services inevitably commoditize themselves and solidify their role as a back-office utility, not as
a service partner.

IT organizations cannot optimize their services if they don't know what their services are. A
service portfolio stating those services and their value propositions is the cornerstone of all
service management initiatives.

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

Recommendations

Do not avoid, mix or combine service management frameworks. Do not substitute back-office
frameworks for front-office frameworks. Such oversights reinforce the stereotype that IT doesn't
understand "the business" and solidify the perception that IT is not worth engaging beyond
transactional fulfillment.

All frameworks must correlate to the service value and outcome captured in the service
portfolio. Without that correlation, the IT organization will inevitably optimize assets or
processes rather than service outcomes. The service portfolio must come first.

Table of Contents
Analysis.................................................................................................................................................. 2
The Four Key ITSM Frameworks.......................................................................................................2
The Service Portfolio.........................................................................................................................4
The Service Catalog......................................................................................................................... 6
The Process-to-Service Map............................................................................................................ 7
The IT Service View CMDB...............................................................................................................9
Conclusion..................................................................................................................................... 10
Recommended Reading.......................................................................................................................10

List of Tables
Table 1. Service Identification..................................................................................................................5
Table 2. Value Statements and SLAs...................................................................................................... 6
Table 3. Sample Catalog Entry................................................................................................................7
Table 4. Sample Process-to-Service Map............................................................................................... 8

List of Figures
Figure 1. The Four Key ITSM Frameworks.............................................................................................. 3

Analysis
The Four Key ITSM Frameworks
There are four key IT service management frameworks. Each targets a different stakeholder, and
each has a distinctly different purpose. When understood and correctly implemented, these four
Page 2 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

frameworks clarify the anatomy of the service value chain, connecting the dots between a specific
technical component or activity and the actual service results it drives. This ability is crucial to
delivering predictable, repeatable service outcomes and continuously improving results.
Following are the four key ITSM frameworks:
1.

Service portfolio

2.

Service catalog

3.

Process-to-service map

4.

IT service view configuration management database (CMDB)

As Figure 1 shows, the first two frameworks are "front-office" artifacts directed to business
stakeholders. The last two are "back-office" artifacts directed to IT leaders and organizations
involved in the operational execution of a service.
Figure 1. The Four Key ITSM Frameworks

Service Consumer

Service Provider

"The Business"

"IT"

Key Stakeholders

Contract
Negotiators

Transaction
Initiators

Service
Executors

Technology
Caretakers

Business
leaders who
authorize
and
ultimately
pay for
services

End users
who request
things on a
day-to-day
basis

IT personnel
who
execute
processes
to fulfill a
request or
transaction

IT personnel
who provision
or administer
the
technological
components
associated with
a service

Service
Portfolio

Service
Catalog

Process-toService Map

Configuration
Management
Database

The Front Office

The Back Office

Source: Gartner (March 2011)

Page 3 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

Before any of these frameworks are developed, it is important to be clear that the whole point of
ITSM is to optimize service outcomes from the point of view of the ultimate consumer, not another
IT organization involved in the service delivery value chain (see "ITSM Fundamentals: Defining
Provider Relationships and Accountabilities Across a Service Value Chain"). Therefore, every
decision and every framework must support that goal. This means that it is pointless to create any
of these frameworks until the consumer has been identified and the service portfolio itself has been
articulated. The portfolio must come first. IT organizations cannot optimize their service outcomes if
they don't know their services and what the expected outcomes actually are.
Furthermore, without the portfolio, there is no common organizing construct for the other
frameworks, and there is no ability to correlate process and configuration changes or catalogs to
service outcomes. The inevitable result is that valuable time is wasted in managing the artifact (a
catalog or CMDB) or a fulfillment element (a process or a technological component) rather than in
optimizing the service outcome.

The Service Portfolio

Every internal IT organization functions within two domains. The first is the architectural domain,
which is concerned with delivering new IT-enabled capabilities to the enterprise. Its business value
is based on the degree to which the IT-asset-based capabilities have their intended impacts on
business key performance indicators (KPIs). The second is the service domain, which is concerned
with the value-added management capabilities that an internal IT organization brings to bear in
shepherding and stewarding those IT-asset-enabled business capabilities. Its business value is
based on the effectiveness of the IT organization as a service provider when compared with other
alternatives chiefly, external service providers.
A service portfolio is a strategic articulation of the IT organization's core capabilities and service
value to the enterprise. Physical, tangible assets are not services, and they do not belong in a
portfolio. Rather, the portfolio answers the questions, "Why should the enterprise buy the service?"
and "Why should the enterprise buy it from an internal IT organization, rather than another
alternative?" It is targeted to senior business leaders who want to know they are getting good
service value for their money and that they can't do better somewhere else.
The service portfolio lists and describes the IT organization's services and their explicit business
value propositions. A fully centralized IT organization with both application and infrastructure
services might have 10 to 15 true services. Table 1 illustrates how IT services are usually articulated
in a portfolio and how they perhaps should be articulated as they get closer and closer to making
true business contributions. The clearer the description is from a business perspective, the easier it
is to create value-based service-level agreements.
Imagine crafting a business value statement for PCs, mobile phones or printing. Then, imagine
crafting one for desktop management or workplace services. Which is easier? Which is more
compelling? The service is not the asset. The service is the act of provisioning, maintaining and
disposing of the asset. The service value is derived from a combination of the asset's businessenabling capabilities and the IT organization's effectiveness in sustaining those asset-enabled
business capabilities.

Page 4 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

Table 1. Service Identification

Typical Items Masquerading as
Services

E-mail

Network monitoring

Security

Videoconferencing

Remote access

Mobile phones/PDAs

PCs

Printing

A Market-Oriented, True Service List

A Business-Value-Oriented,
True Service List

Desktop management
services

Collaboration
services

Telecommunications services

Facilities services

Workplace
services

Application hosting services

Secure access services

Mobile computing services

Source: Gartner (March 2011)

A common misconception is that the service portfolio is just marketing collateral or "brochureware."
While it is true the portfolio is an important communications tool, it is significantly more than that.
The inclusion of a well-honed value statement makes it the basis of every other ITSM planning aid,
because the value statement specifies what is being optimized. The value statement is the truing
mechanism that enables the creation of business-based service-level metrics. Those metrics, in
turn, are the performance goals IT must manage against.
Furthermore, by having a strategic portfolio that is value-based, IT leaders are able to correlate their
costs and performance to the business value that is generated. Table 2 continues the example from
Table 1 to illustrate how a well-stated service facilitates meaningful value statements, which in turn
facilitate meaningful SLAs.

Page 5 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

Table 2. Value Statements and SLAs

Service
Name
Workplace
services

Sample Value Proposition

Anytime, anywhere work

capabilities combined with
secure, "choice-rich" technology
environments enhance
worker productivity, satisfaction
and retention by enabling
personalized work spaces,
individualized tools and flexible
employment practices.
Scalable, flexible workplace
technologies and efficient
change practices adapt to the
nature of work being performed,
driving greater asset utilization
and productivity.

Sample SLAs

1.

Annual IT satisfaction surveys indicate a minimum

of 90% satisfaction, with year-over-year
improvement of no less than 2%.

2.

Ninety-five percent of the time, workplace adds,

moves and changes will be fully completed within
three business days of the request.

3.

Ninety-five percent of the time, personal computing

and technology devices will be delivered to the
worker within 10 business days of the purchase
request.

4.

A minimum of 50% of worker requests for

connectivity for previously unsupported personal
devices will be fulfilled; standardized
implementation practices to be achieved within one
business quarter.

Source: Gartner (March 2011)

The Service Catalog

The service catalog is the operational manifestation of the service portfolio. It is targeted to the dayto-day consumers of IT products and services. Unlike the portfolio, the catalog can contain physical
assets as long as they are something the defined customer would actually request and buy. Like any
other catalog in any other realm of life, an IT catalog is intended to facilitate service ordering and
fulfillment. It is fundamentally transactional in nature. It is organized so that the things a consumer
wants to request are easy to find, and it is articulated so that options are well-understood. In
addition, it clarifies how to order or request the service, when to expect the transaction to be
completed under ordinary circumstances (this is not the same thing as an SLA), and what to do if
those expectations are not met. It says nothing about how the IT organization goes about fulfilling
those requests.
Fundamentally, the catalog's purpose is to make it easier for a consumer to do business with IT. As
with the portfolio, this necessitates articulating it from the point of view of the consumer, not of the
provider. Connecting the catalog to the portfolio further requires that every item in the catalog be
associated with one and only one service from the portfolio. This enables cost accounting rollups that correlate service cost to service value. It also provides important context that elevates what
would otherwise be a commodity transaction to a value-based service. Moreover, it enables the
pursuit of aggregated, value-based SLAs at the portfolio level, rather than technology- and
transaction-centric performance metrics at the catalog level.

Page 6 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

IT organizations that implement a catalog without first building a portfolio inevitably build it to make
their own lives easier, treating other co-provider IT organizations that are involved in process
handoffs as customers. They articulate the catalog contents from an IT-centric perspective,
including back-office fulfillment elements that are of no interest to an end consumer. They also tend
to set pricing and SLAs at the catalog level. This cements the business perception of IT as a
commodity and forces the IT organization to continue justifying its existence on the basis of cost. It
creates an untenable management burden due to the sheer number of SLAs that need to be
managed, and inevitably, they are the wrong SLAs, because they are not based on any
understanding of who the customer is, or of the service's desired business value and contribution.
In short, a catalog that is unsupported by a portfolio further entrenches business leaders' belief that
IT doesn't understand the business and is not worth engaging. By contrast, a catalog that is
supported by a portfolio elevates the conversation, captures all the business value-adds that a
competent IT organization delivers, and creates the basis for both a performance-based IT culture
and an effective activity-based costing system.
Table 3 continues the previous workplace example to illustrate what the typical catalog entries
might look like, depending on how integrated they are with functions such as real estate and HR.
Table 3. Sample Catalog Entry
Service (From the Portfolio)
Workplace services

Catalog Elements

PCs and laptops

Phones/PDAs

Tablets

Printers, scanners and copiers

Accounts and user IDs

Connectivity devices (local, remote and home office)

Office/cubicle space and furniture

Parking permits and security badges

Secured facilities keys

Corporate charge cards

Source: Gartner (March 2011)

The Process-to-Service Map

The process-to-service map correlates to a service all the activities associated with fulfilling it and
meeting its SLAs. The map's primary purpose is to make explicit the relationships between services
and processes, so that performance and process optimization can occur. It captures the intangible

Page 7 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

fulfillment elements of every service. As such, it is a crucial back-office decision framework for IT
leaders, but it should not be positioned with business leaders or IT product/service consumers.
The process-to-service map is necessary because there is not a one-to-one relationship between
services and processes. If the average fully centralized IT organization has 15 services, it might have
200 processes. It will never be possible to optimize all those processes, so the IT organization
needs a mechanism for knowing which ones matter. That can be assessed only in relation to the
existence of business-based SLAs, and the degree to which SLAs are or are not being met
(see "A Framework for Designing IT Service and Process Metrics").
The IT organization that is optimizing processes for services that already meet their SLAs is wasting
resources by investing in service outcomes that are not valued by the business at the probable
expense of services that are underperforming. The only way to respond to a business leader's
insistence that a particular service's performance be improved is to have a measurable statement of
expected performance (an SLA) and to know specifically what processes drive that performance
(the process-to-service map) so that the explicit processes impeding performance commitments are
recognized and can be improved.
As shown in Table 4, the process-to-service map has processes on one axis and services on the
other, with the appropriate intersections marked out. It can be built as a simple spreadsheet.
Table 4. Sample Process-to-Service Map
Services
Processes

Workplace services

Application hosting services

Project management services

Total

Demand management

Disaster recovery

Procurement

Resource brokering

Etc.

Total

Source: Gartner (March 2011)

Beyond clarifying the specific processes a given service depends on so that service performance
can be deliberately engineered, this graphical representation illustrates which processes are core,
because they underpin virtually every service (there is generally a high correlation between "core"
services and ITIL). It further indicates where multiple services might share a specific process so that
dependencies are understood and IT can avoid "breaking" one service while "fixing" another. It also
forms the basis for real-time SLA monitoring and activity-based service costing. Lastly, because the
process-to-service map helps to identify logically related sets of processes, it's a vital tool in
Page 8 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

designing process- and performance-based organizational structures (see "Six Steps to ProcessBased IT Organizational Design"). Note: Some IT organizations acquire IT catalog tools with backoffice workflow engines. In this case, the process-to-service map becomes the key reference for
populating the tool's workflow components. However, whether translated into a tool or retained as a
graphical representation, the process-to-service map is strictly a provider view unsuitable for
consumption by consumers.

The IT Service View CMDB

Every IT service has activity-based fulfillment elements, because a service is the value-based result
of an action or actions that is, a series of processes, activities or tasks. These processes,
activities or tasks directly result in service fulfillment or are acted out on technological assets, which,
in combination with processes, deliver a service outcome. While the IT service view CMDB is similar
to the process-to-service map in many ways, it focuses on the physical rather than intangible
fulfillment elements of a service and is more aligned to service change and execution, rather than
service prioritization and planning.
As we already indicated, a service may or may not have technological dependencies, but if it does,
those dependencies must be understood if the provider organization is to guarantee results. The
process-to-service map is a vital tool for understanding what drives service performance and for
planning or prioritizing service improvement efforts; thus, it is predominantly a decision framework.
Once a service has been targeted for change, it is crucial to understand all of its fulfillment elements
and what other services those elements touch. The CMDB provides those insights, while facilitating
impact assessments for other management concerns, such as compliance and disaster recovery.
A CMDB's primary benefit is to deliver a top-down, service-oriented view of the infrastructure
components that compose an IT service and the interdependencies between those components.
CMDBs are designed to depict parent-child, peer-to-peer and hierarchical relationships across base
configuration elements.
Creating a CMDB requires the following:

Solid configuration management and discovery processes. This is because the CMDB
leverages other information sources and includes only the information that is necessary to
support a service.

A strong sense of objective. The information collected and maintained must serve a purpose.

An owner who is responsible for the ultimate integrity of the information that the CMDB
contains.

Integrity metrics to which the owner can be held accountable.

CMDB information sources include (but are not limited to) inventory tools, spreadsheets and
configuration repositories. IT service-dependency-mapping tools can facilitate the discovery
process for IT service relationships, but the CMDB is unique in that it also reconciles information
from multiple sources, providing a trusted view into the technological components that a service

Page 9 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

actually requires. A good CMDB tool will provide service modeling and mapping; information
integration, federation and reconciliation; and synchronization.

Conclusion
Each of the aforementioned frameworks targets a specific stakeholder and serves a specific
purpose, but all are fundamentally aligned to the achievement of a predefined, value-based
outcome. For this reason, the frameworks must be developed from the top down. The available
range of ITSM automation tools has an important role to play in service management, but typically
codify only the catalog and the CMDB. Most tools have a stronger back-office rather than frontoffice orientation. Few support the service portfolio or the process-to-service map.
IT leaders must be careful to avoid "running to what is most familiar" that is, technology when
starting their service management journey. Beginning ITSM with a bottom-up, asset-centric
orientation virtually guarantees making three classic ITSM mistakes:

Positioning assets or processes as services

Targeting catalogs to co-providing IT organizations, rather than to service consumers

Mistaking tactical transactions for strategic, high-value services

The good news is that all of these missteps can be avoided. When properly implemented, this set of
four ITSM frameworks provides the means to reorient key stakeholder relationships and
conversations away from technology toward business results, and away from cost toward value.

Recommended Reading
Some documents may not be available as part of your current Gartner subscription.
This is the first in a five-part series devoted to ITSM best practices and fundamentals. We suggest
reading the following additional research in the sequence indicated:
"ITSM Fundamentals: How to Create an IT Service Portfolio"
"ITSM Fundamentals: How to Construct an IT Service Catalog"
"ITSM Fundamentals: How to Build an IT Process-to-Service Map"
"ITSM Fundamentals: Defining Provider Relationships and Accountabilities Across a Service Value
Chain"
"Understand Shared-Service Fundamentals and Avoid Perennial Traps"
"Six Steps to Process-Based IT Organizational Design"
"A Framework for Designing IT Service and Process Metrics"
"Mature Your IT Service Portfolio"
Page 10 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

"Know the Difference Between Service Portfolios and Service Catalogs"

"Q&A: Configuration Management Databases, From Implementation to Business Value"
"Configuration and ITAM Intersect in the IT Service View CMDB"
"The What, Where and Why of Configuration Items in Your CMDB"

Page 11 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx

This research note is restricted to the personal use of A01308944@itesm.mx

GARTNER HEADQUARTERS
Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096
Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

2011 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartners prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartners research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartners Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see Guiding Principles on Independence and Objectivity.

Page 12 of 12

Gartner, Inc. | G00210322

This research note is restricted to the personal use of A01308944@itesm.mx