HP ITSM Reference Model

Briefing Document
Background

The HP Information Technology (IT) Service Management Reference Model is the intellectual property of HP's
Software and Services Group (SSG). This process model complements the other two key assets of HP's services
business: people and technology. It is based on a set of industry standard concepts defined in the Information
Technology Infrastructure Library (ITIL). ITIL was originally created by the UK government to better understand
the management of services delivered to an end-user community by IT professionals. Over the years, ITIL
principles and philosophy have been verified and refined, under the stewardship of an independent organization
chartered with its maintenance, from the feedback of IT professionals and end-user organizations.

Designed within a cross-divisional framework, the model facilitates alignment between several internal HP software
and services businesses. Given the recent public introduction of a new HP initiative called "Service Management,"
emphasis on the model will increase. This initiative brings HP professional services together with software to
market a "total solution" by offering customers a complete assessment of - and improvement plan for - their IT
service delivery infrastructure, including an optimal balanced offering of insourcing assistance (using HP process
consulting, education, and software technology) and client/server management services. Such a plan can be
implemented with a combination of HP people, process, and technology drawn from the product lines of OSD,
NSMD, SSD, HSD, FCBU (FRD), and HPC. The existence of the HP IT Service Management Reference Model
substantially increases our depth of discussion with the customer by facilitating a consulting dialogue using a
common language, and by showcasing HP service and software offerings that respond to discovered needs.

HP leveraged its own wealth of IT experience by involving HP's internal IT organization (E-BIS) as an active
participant in the model's development and verification.

Note: The diagrams and slides alluded to in this document refer to the content1.ppt and content2.ppt slide sets
which can be viewed or downloaded through the “slidesets” link on the Process Guide navigation bar.

How HP can use the ITSM Reference Model

The HP marketing initiative, Service Management, describes a total solution for customers, employing HP's wealth
of resources in People, Processes, and Tools. The ITSM Reference Model provides the crucial Process link, and can
be used by various HP organizations in servicing the customer.

On the People side of the house (HP Professional Services):

• HP Consulting services will use the model to assess the customer's environment and needs. They then can
recommend an optimal level of outsourcing (HP Client/Server Management services) and insourcing.
• HP Client/Server Management services will use the model in the planning, development, pre-sales, and
delivery of outsourcing services, to ensure all the proper linkages are in place between processes delivered by
HP and by third party service partners.
On the Technology side of the house (HP Software Applications and Application Integration Services), the ITSM
Reference Model is used to guide product planning and software development, as well as to plan, implement, and
support delivery of integration services.

HP ITSM Process Groups and Processes

We begin with a diagram showing the cyclical nature of the four major process groups of IT Service Management
and a subsequent diagram showing specific processes which are associated with those process groups. This

ITSM_B1.DOC HP Internal Use Only Page 1 of 5

continuous cycle starts with the development of an IT strategy based on business objectives and progresses through
design and deployment phases to the Operations Bridge, a command center (similar to a nautical "bridge") wherein
Incident Management works cooperatively with Operations Management and Problem Management to handle the
ongoing operation and management of services and infrastructure. In the very heart of this diagram you can see the
twin processes of Configuration Management and Change Management. Configuration Management establishes and
maintains IT's central data (asset) repository and Change Management performs IT's central control function.
Together, they form the core of the overall IT Service Management Reference Model, and touch every aspect of it.

While a traditional perspective might propose that Service Design be its own process "group," distinct from the
management processes, the development team takes the stance that Service Design is simply the initial instance of
prudent service management, and, therefore, an integral part of that process group. Moreover, Service Design
should be considered as part of the ongoing process of Service Management, and not a singular event.

High-Level Linkages

Now we zoom in to show the nuances of the cyclical nature of the process groups' high-level inputs and outputs.
The cycle is not simply a single counter-clockwise loop.

Flanking the core processes of Configuration Management and Change Management on the top right and bottom left
stand two symbiotic process groups, Service Design & Management and Operations Bridge, which constantly feed
each other with service objectives/measures and service performance information, respectively. This
interdependence establishes the primary structure for continuous improvement in the quality of delivered IT
services.

Flanking the Configuration and Change Management processes on the top left and bottom right are two other
process groups, one that represents major strategic IT processes, and the other, processes which focus on building
and deploying change to IT services and infrastructure. Unlike the day-to-day changes performed by Service
Design and Management and the Operations Bridge, which use frequent data interchange to optimize delivery and
fine-tune services, these two process groups bridge the gap between external factors and the internal mechanics of
IT service delivery. The Business - IT Alignment group bridges the gap by translating changes in overall business
objectives to new IT strategies. The Service Development and Deployment group bridges the gap by translating
planned IT services into the environmental infrastructure (hardware, software, networks, procedures, etc.) and into
the service deployment needed by the Operations Bridge to deliver service to the customer.

Finally, Service Reports are fed back to Customer Management from the Service Design and Management process
group, to provide all the service performance information needed to support regular service review presentations to
the customer.

Process Workflows

The two workflows are an attempt to show a very high-level main stream of service-oriented activity through the
model. We are not trying to show all possible flows and decisions. Rather, we are trying to illustrate the primary
path, or life-cycle, a service might take through all of the key IT processes, separated logically into two major
activities - Standard Service Development, and Customer-Specific Service Activation. Let's walk through both
workflows using the scenerio of a new service being developed, and then being activated for a particular customer:

Flow #1: Standard Service Development

First it is important to understand that HP recognizes the importance of investing heavily in the development and
management of standard services, services which can be leveraged across multiple customers, in order to have a
truly efficient and profitable IT business, and the ITSM Reference Model reflects that value. Though custom service
development is accommodated, the assumption is that IT starts communicating to the customer via its standard
service offering, and then negotiates additional custom service additions as necessary.

ITSM_B1.DOC HP Internal Use Only Page 2 of 5

We start in the Business - IT Strategy Alignment process group with the Business Assessment process. Once the
market requirements are understood through analysis, and existing customer service and support requirements are
defined through the Customer Management process, standard service recommendations are made to the IT Strategy
Development process. Since new services must be designed within the context of an overall IT strategy, IT Strategy
Development drives the formulation of the customer's operating principles and optimal support structures to ensure
that those principles are met - policies and standards, architecture, processes and organizational models. Based on
this IT strategic direction and marketing input, and constrained by the IT budget, standard service investment
decisions are made.

These investment decisions drive the Service Planning process (within the Service Design & Management process
group), which gathers functional requirements and begins to define a new service. The Availability Management
process designs and monitors aspects of the service that affect its availability and security, taking into consideration
any contingencies which might occur. The Capacity Management process designs and monitors aspects of the
service that affect service supply and demand. The Cost Management process designs and monitors aspects of the
service that affect affordability, cost recovery and billing, resulting in a service budget. Each of these three
management processes may be iterative as decisions made in one process may affect one (or more) of the others.
For example, a cost management decision may affect a contingency (continuity) planning specification. All of these
technical specifications are provided back to the Service Planning process, which makes appropriate service buy
versus build decisions, and which accordingly develops an integrated end-to-end service manufacturing and
procurement specification.

The procurement specification is used by the Availability Management process to develop Operating Level
Agreements with service/product suppliers, to ensure that IT can meet its service level obligations to the customers
who will subscribe to the future service. Service design configuration data is recorded by the Configuration
Management process. A service development plan is provided to the Change Management process so that it can
manage the overall service development project. Once the Change Management process issues a service
development workorder, the Build and Test process (within the Service Development and Deployment process
group) pulls the manufacturing and procurement specifications from the Service Planning process, and develops a
standard service master blueprint, stored as standard service configuration data in the Configuration Management
process, which can be replicated and activated for specific customers by the Release to Production process.

Flow #2: Service Activation for Specific Customers

Once the standard service has been built in process flow #1, the Customer Management process includes the new
offering in their marketing materials and conducts service selling and requirements assessment activities with
current and potential customers' executive management. When the customer expresses interest in purchasing a
particular service or set of services, the Customer Management process notifies the Service Level Management
process of the need for contract negotiation with the customer's IT manager to agree upon a Service Level
Agreement (SLA). These SLA terms, once finalized, are provided to the Customer Management process for
presentation to the customer's executive management, whereupon a purchase order for new services is obtained.
This triggers the development of a service activation plan for a new customer by the Service Level Management
process, submitted to and managed by the Change Management process.

The Change Management process issues a release workorder and schedule to kick off the replication of the standard
service from the master blueprint developed by the Build & Test process for this specific customer. The Release to
Production process owns this replication and service activation responsibility, procuring and manufacturing
according to the specifications, loading customer-specific configuration data into the Configuration Management
Database, installing service infrastructure into the customer's production environment, and providing the Operations
Management process the service deliverables and service activation necessary to begin service delivery to that
customer. Change Management also ensures that Cost Management sets up appropriate billing processes for that
customer.

Service delivery occurs on an on-going basis in the Operations Management process, monitoring production
environment status and administering to the environment. If something goes wrong (or if a proactive threshold trap
is set and then the threshold is exceeded) , an incident occurs. Most incidents are resolved quickly by the Incident

ITSM_B1.DOC HP Internal Use Only Page 3 of 5

Management process in order to minimize downtime and return the customer to service quickly. In some cases,
particularly serious or troublesome cases are escalated and are resolved by root cause analysis in the Problem
Management process. This process also addresses incident trends which, by eliminating the cause, can be prevented
proactively.

In order to fix problems, changes may be needed either in the service or in the environment. The Problem
Management process submits fix recommendations to the Change Management process to control impact to the
production environment of the change activity. Service Level Management regularly collects service performance
data, which is used to present formal service performance reviews to the customer's IT management. This service
performance review provides an opportunity to identify needs for new or improved services, perhaps triggering a
repeat loop through the service development workflow cycle.

Q&A

Why is "Help Desk" not shown on the model?

Both within and external to HP, there are a number of meanings for Help Desk which would have caused more
confusion than adopting a different term. Also, the main function of this process is managing an incident from
detection/acceptance through to closure. Thus, we decided on Incident Management because it conveys the meaning
of the process clearly. "Help Desk" is really more akin to a service than to a functional process.

Why is "Account Management" not shown on the model?

Again, both within and external to HP, there are a number of meanings for Account Management which would have
caused more confusion than adopting a different term. We chose Customer Management for the process name
instead of the ITIL recommendation of "Customer Liaison". It is a stronger, more active term that better conveys
the purpose of executive account management, still calls attention to the strategic "customer-focus" being demanded
by IT customers all over the world, yet does not get confused with any operational management activities sometimes
associated with the term "Account Management".

How do "Service Planning" and "Service Level Management" differ?

While HP's ITSM Service Planning process provides standard service (anticipated leveragability across multiple
customers) and service level design (the Service Level Manager contributes service level definition for standard
services to the Service Planning process), ITSM's Service Level Management provides custom service (customer-
specific) and service level design, as well as SLA development/negotiation and ongoing performance monitoring
and management for services delivered to individual customers.

Why are "Build and Test" and "Release to Production" not found as specific processes in the ITIL documentation,
but they are in the ITSM Reference Model?

ITIL clearly has its limitations. It is very mainframe computer-oriented, and we have needed to enhance it to fit
better into a distributed client/server environment. Furthermore, it never specified clear "change build" and "change
deployment" processes - only the management of these changes in "Change Management" (this has been clearly
documented in ITIL as a separate function than the performance of the change itself - "separation of duties" to
promote the control function intended in the overall workflow). It appears that ITIL intended to have the change
build and deployment functions handled within the Operations Management process. However, for major changes
to service and infrastructure, one would expect explicit processes for these functions instead of lumping it into the
already full plate of Operations Management, since they really are different activities. Furthermore, the process
model is more aligned with the CPLC methodology flow if it acknowledges these activities explicitly. The absence
of explicit change build and deployment processes is considered a weakness commonly pointed out by ITIL
consultants (as the development team has had interactions with several of them). Therefore, under the advice of our
process consultant, we inserted a Service Development & Deployment process group, with "Build and Test" and
"Release to Production" processes to reflect these missing critical processes.

ITSM_B1.DOC HP Internal Use Only Page 4 of 5

Why don't you just call "Configuration Items (CIs)" assets?

Configuration Item is such a key concept in ITIL, and broadens the definition of "asset" to include not just
traditional hardware and software assets but also things not normally associated with the term, such as
documentation, data, objects and concepts such as users or events, and relationships between / attributes of any of
these items, leaving the Configuration Manager flexibility to define relationships and attributes as any values which
are needed to meaningfully describe the items. Examples: user access to device; device parent of device; location
of device; owner of data.

ITSM_B1.DOC HP Internal Use Only Page 5 of 5