Service Transition

SERVICE ASSET AND

CONFIGURATION MANAGEMENT
PROCESS
VERSION: 4.3 REVISION DATE: February 23, 2017
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Contents
Section 1. Introduction .........................................................................................1

1.1 Purpose ..............................................................................................1

1.2 Goal ....................................................................................................1
1.3 Overview ............................................................................................1
1.4 Key Relationships with other processes ........................................2
1.5 Definitions..........................................................................................2

Section 2. Roles and Responsibilities ..................................................................4

2.1 Process Owner/Configuration Manager .........................................4

2.2 Configuration Item Class Owner .....................................................4
2.3 Configuration Item Class Administrator .........................................4
2.4 Configuration Item Company Administrator ..................................5
2.5 IT Service Continuity Management (ITSCM) Role.........................5
2.6 IT Staff ................................................................................................5
2.7 ITSM Product Manager .....................................................................5
Section 3. SACM Process and Relationship Map ................................................6

Section 4. Configuration Management Database ................................................7

4.1 CMDB Content and Structure ..........................................................7

4.2 Configuration Item Classes .............................................................7
Section 5. Network Gear Class Process and Procedures ...................................3

5.1 Scope .................................................................................................3

5.2 Network Gear Class Lifecycle ..........................................................3
5.3 Network Gear Lifecycle Process .....................................................4
5.4 Network Gear Class RACI Chart ......................................................4
5.5 Network Gear Entry Criteria .............................................................5
5.6 Network Gear Process ......................................................................5
5.7 Network Gear Exit Criteria ...............................................................6
Section 6. Server Class Process and Procedures ...............................................7

6.1 Scope .................................................................................................7

6.2 Server Class Lifecycle ......................................................................7
6.3 Server Class Lifecycle Process .......................................................7
6.4 Server Class RACI Chart ..................................................................8
6.5 Server Class Entry Criteria ..............................................................8
6.6 Server Class Procedures .................................................................8
6.7 Server Class Exit Criteria ...............................................................10

Section 7. Storage Class Process and Procedures ...........................................11

7.1 Scope ...............................................................................................11

Page i
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

7.2 Storage Class Lifecycle ..................................................................11

7.3 Storage Class Lifecycle Process...................................................11
7.4 Storage Class RACI ........................................................................12
7.5 Storage Class Entry Criteria ..........................................................12
7.6 Storage Class Procedures .............................................................12
7.7 Storage Class Exit Criteria .............................................................14

Section 8. Application Class Process and Procedures ......................................15

8.1 Scope ...............................................................................................15

8.2 Definition: Business Service Application - Software ...............15
8.3 Application Class Lifecycle ...........................................................16
8.4 Application Class Lifecycle Process ............................................17
8.5 Application Class RACI ..................................................................17
8.6 Application Class Entry Criteria ....................................................18
8.7 Application Class Procedures .......................................................18
8.8 Application Class Exit Criteria .......................................................19
Section 9. Establishing Relationships in the CMDB ..........................................20

9.1 Applications and Server Relationships ........................................20

Section 10. SACM CMDB Audit Protocol .............................................................21

10.1 SACM CMDB Audit Purpose ..........................................................21

10.4 Background .....................................................................................21
10.3 SACM CMDB Audit Process ..........................................................21
Section 11. CMDB Structure & Business Service Versus Application .................22

11.2 CMDB Structure Model ...................................................................22

Section 12. Glossary ............................................................................................23

Section 13. Revision History ................................................................................24

Section 14. Appendices .......................................................................................25

14.1 CI Class Owners & Subject Matter Experts ..................................25

14.2 SACM CMDB FY16 Goal Milestone Schedule ..............................25

Page ii
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 1. Introduction
1.1 Purpose
The purpose of this document is to describe the Service Asset and Configuration Management
(SACM) process.

SACM aims to maintain information about Configuration Items (CI) required for the delivery of an
IT service, including their relationships.
This document will define the relationship of SACM to other processes, roles and responsibilities
of SACM and the process flow.

1.2 Goal
The goal of the SACM process is to provide an understanding between incidents and
configuration items.

The Configuration Management Database will be the source of truth for configuration items and
their relationship to other configuration items at UCSF.

1.3 Overview
The Service Asset and Configuration Management process ensures the integrity of the IT
infrastructure by the tracking, recording and reporting on configuration items.

In order to adequately manage and control these CIs, the SACM process is supported by a
Configuration Management Database (CMDB) capable of holding information on all CIs, including
attributes and relationships between them. SACM enables IT to achieve control and
management over its IT assets and provides management information about the IT infrastructure.

The Service Asset and Configuration Management process is divided into five sub-processes:

Planning

Process Objective: To define the CMDB plan, including purpose, scope, and objectives. Defines
Classes, naming conventions, roles and responsibilities, and interfaces with other systems.

Identification

Process Objective: To define and maintain the underlying structure of the CMDB (the
Configuration Model), so that it is able to hold all information on CIs. This includes specifying the
attributes describing CI types and their sub-components, as well as determining their
interrelationships.

Configuration Control

Process Objective: To ensure that no CIs are added or modified without the required
authorization and those modifications are adequately recorded in the CMDB.

Status Accounting

Process Objective: To ensure that CI details are updated as the CI goes through the lifecycle.

Page 1
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Verification and Audit

Process Objective: To perform regular checks, ensuring that the information contained in the
CMDB is an exact representation of the CIs actually installed in the live production environment.

1.4 Key Relationships with other processes

Change Management

The Change Management and SACM processes are designed to work together seamlessly in
order for the CMDB to accurately reflect the changes that have taken place. Change
Management utilizes the information stored in the CMDB for the assessment and authorization of
requests for change (RFCs). SACM, by holding information on the relationships between CIs,
facilitates this process for Change Management.

Incident Management

There is a strong relationship between SACM and Incident Management. Incident Management
utilizes information from the CMDB for incident recovery and for informing users on the status of
CIs in the infrastructure. The Service Desk can also assist with the validation of the integrity of
information in the CMDB due to its function as the central point of contact for users and clients.
Incident Management relies on information captured within the CMDB about CIs to perform its
activities; it should be able to rely on the SACM process and the CMDB to provide accurate
information.

Problem Management

Problem Management procedures must ensure that each time a problem or known error occurs
and is recorded in the IT Service Management tool, the corresponding process record is linked to
the affected CI in the CMDB.

Release Management

Release Management is responsible for the management of the introduction of new CIs to the IT
infrastructure. The objective of this process is to ensure and coordinate the production readiness
or supportability and distribution of new elements introduced to the IT infrastructure. The process
accomplishes this in close collaboration with Change Management and SACM.

1.5 Definitions
Configuration Management Database (CMDB)

CMDB is a logical database containing all relevant information about IT infrastructure

components, as well as the relations between those components. Each component is referenced
in the CMDB as a Configuration Item (CI).

Configuration Item (CI)

A CI is the unitary element of a CMDB. Some CI examples: a server, a business application, a

router, a disk array, etc. A CI is defined by four (4) components:

Page 2
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Status the CIs lifecycle. For a hardware CI, a typical lifecycle can be: Ordered, Delivered,
Installed, In production, Stopped, Broken, Scrapped. For an application CI, another lifecycle
could be: In production, Stopped, Decommissioned.
Traces the history of the CI and its updates.
Attributes informational fields related to the CI. They may vary depending on the CI Class.
For example, a serial number is typical of hardware CIs, whereas a version number is more
appropriate for software CIs.
Relations There are several types of relations (physical relations, logical relations,
dependency relations, etc.) and relations have the characteristics of belonging to two CIs at
the same time.

Configuration Item Class

All CIs with the same nature are grouped within classes. All CIs within a CI class have the same
behavior, for example the lifecycle. Some typical CI Classes: Application, Network Gear, Server,
Documentation.

Configuration Audit Report

A report summarizing the results of a CMDB audit, highlighting revealed differences between
CMDB records and the actually installed CIs.

IT Infrastructure

The sum of an organizations IT related hardware, software, data communications facilities,

procedures, documentation and people.

ITIL

ITIL defines the set of all necessary processes and provides best practices for IT Service delivery
and support.

Page 3
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 2. Roles and Responsibilities

2.1 Process Owner/Configuration Manager
Accountable for the end-to-end process
Ensures the success of the process
Acts as the process advocate to the enterprise
Supports the effective use of the Service Asset and Configuration Management process
Provides process design and improvement guidance
Leads the SACM process governance committee
Defines access privileges

2.2 Configuration Item Class Owner

There are usually only one or two Class Owners for each CI Class.

Needs to understand and proficient in their class and recommend improvements for their
respective classes.

Accountable for the following:

Acts as subject matter expert for CI Class

Creates/Modifies/Retires CI Class
Creates/Modifies/Retires CIs within their Class
Ensures the integrity and completeness of the CI Class
Establishes relationships between CIs

2.3 Configuration Item Class Administrator

There are usually several Class Administrators for each CI class.

In practice, the CI Class Administrators may be the Class Owner plus individuals who the CI
Class Manager entrusts with the process, and there will be larger number of individuals who
manage CIs in their respective class (larger number than Company Admins).
CI Class Admins are knowledgeable about the CIs in their Class. They are, or will become
content experts (SMEs) in the SACM/CMDB process and can be called upon, as secondary
resource for Q&A or in Class Owner absence.
Also, some CI Class Admins will attend workshops and will also train others in their class and
assist in ensuring theyre maintaining the CIs appropriatelyso they may be a bit more
senior.

Responsible for the following:

Acts as designee of CI Class Owner

Creates/Modifies/Retires CI Class
Creates/Modifies/Retires CIs within their Class
Ensures the integrity and completeness of the CI Class
Establishes relationships between CIs

Page 4
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

2.4 Configuration Item Company Administrator

There are usually only one or two Company Administrators. (This role can also be filled by a
Class Administrator or Class Owner). It is elevated access from Class Administrator, but not all
Class Administrators will have this role, as it should be limited. All Class Admins should not be
able to add/modify vendors, manufacturer and models in the CMDB.

The Company Administrator has same rights as a CI Administrator, PLUS, they can also create
and maintain the 'companies' (vendor type info) in the CMDB, i.e., create a new company record
such as for Cisco or Comtel.

In practice, the CI Company Administrators may be the Class Owner plus one (maybe two) CI
Class Administrators that have proven track record in following process and are detail oriented.

Responsible for the following:

Add/Modify vendors, manufactures and models to the CMDB

2.5 IT Service Continuity Management (ITSCM) Role

When new CIs are created, the default value for the CI Tier Field is Pending Business Impact
Analysis. The holder of the ITSCM role is the only one who can change the Tier to the values of
1, 2, 3 or 4 once the Business Impact Analysis (BIA) is completed.

2.6 IT Staff
Ensures valid CIs are selected against incidents and planned changes
Validates CI information and highlight CI inaccuracies using the CI Update Flag, (which
notifies the CI Class Owner).

2.7 ITSM Product Manager

Manages the Service Asset and Configuration Management module
Develop enhancements to CMDB
Manages the Discovery tool

Page 5
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 3. SACM Process and Relationship Map

Problem
Incident Release Change
Management
Management Management Management
Process
Process Process Process
(TBD)

Assists with Assists in

Root Cause Analysis Lowering Risk
to Production

Enables Accurate Aids in Lowering Risk by

Incident Routing understanding impact of
Change and Ensures
CMDB Correct Staff Approval

Changes to CMDB are under Change Control

And
Production Changes are reflected in CMDB

Service Asset and

Configuration Management Process

Determine CI Determine
Control Conduct Status
Classes Access Control
CIs Accounting
(Planning) Model

Conduct
Identify
Configuration
Configuration
Verification and
Items
Audit

Other Process Relationship

Incident Management Incident Management uses CI information to understand what CIs are involved in an incident

Problem Management Problem Management uses CI information to help track down the root cause of a problem

Change Management Change Management uses CI information to understand the ramifications of a proposed change

Release Management updates the Configuration Management System (CMS)* with information
Release Management
about deployed releases

Page 6
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 4. Configuration Management Database

4.1 CMDB Content and Structure
The CMDB contains the following
information:

CI Class Configuration Items

Attributes
Relationships

Example of the CMDB Structure

4.2 Configuration Item Classes

CIs with the same nature will be grouped within classes that share the same data models. CIs
within a CI Class have the same behavior, for example they will all follow the same lifecycle.

The following CI Classes have been identified to be implemented at UCSF. Each Class will have
its own set of process and procedures.

Page 7
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Class Name Description

Network Gear Any piece of networking equipment that passes packets

Physical or Virtual computer dedicated to run one or more services (as a host), to serve the
Server
needs of the users of other computers on a network. Also includes console servers.

Storage Devices used for storing data

Application Application that supports a business process.

Any piece of equipment or application to support that environment, i.e., racks, monitoring
Data Center
systems

Computer Done as part of Asset Management

Printer Done as part of Asset Management

Communication Devices Done as part of Asset Management

Note: Additional classes will be implemented over time.

Page 2
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 5. Network Gear Class Process and

Procedures
5.1 Scope
All network equipment that passes packets will be included in the Network Gear Class:

Access Point
Blade
Chassis
Firewall
Load Balancer
PBX
Router
Switch
VPN
Voice Gateway
Wireless Controllers

5.2 Network Gear Class Lifecycle

Received Inventoried Deployed Deprovisioned

Received: Inventoried: Deployed: Deprovisioned:

CI is physically in CI is available for CI is delivered and CI has reached the
the possession of deployment placed into service end of the lifecycle
the team that will and is retired from
deploy it service

Page 3
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

5.3 Network Gear Lifecycle Process

Network Gear Lifecycle Process v2.1

Lifecycle Stages: Recv Inventoried Deployed Deprovisioned

START
6
1 2
4 5 Prepare
Receive Add/Modify
Store Create Network Gear
Network Gear Class Administrator

No
Network Manufacturer
Network Gear CI Record for
Gear ?
Deployment
Yes

8 12 13
9 Remove Update
Update
Attribute Network Gear CI
CI
Changes from Service Record
Record as
?
Necessary

No No

7
Yes Initiate 11
10
Change Initiate
Deprovision Yes END
Process Change
?
Process
Network Gear Company

3
Administrator

Update
Manufacture/
Vendor
Information

5.4 Network Gear Class RACI Chart

Responsible Those who do the work, facilitate it and/or organize it

Accountable The one who ensures the desired outcomes are reached and has yes/no decision making authority
Consulted Those who have critical expertise to contribute before a decision is made
Informed Those who are significantly affected by the activity/decision and must be informed to ensure successful implementation

Page 4
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

5.5 Network Gear Entry Criteria

The Network Gear Procurement process has been completed and the Network Gear has been
physically accepted by the Network Gear Administrator

5.6 Network Gear Process

ID Step Responsibility

Received

Received Network Gear Network Gear

1 Administrator
The Network Gear is physically received by the Network Gear Administrator.
Inventoried

Add/Modify Manufacturer? Network Gear

The Network Gear Administrator determines if the Manufacturer information is in the Administrator
2 system and needs to be updated or is not in the system and must be added.
Yes Go to Step 3
No Go to Step 4
Update Manufacture/Vendor Information Network Gear Company
The Network Gear Company Administrator is responsible for updating the Company, OS Administrator
Version and Model tables in ServiceNow with the following information:
3
Manufacturer
Model
Vendor
Store Network Gear Network Gear
4 Administrator
The Network Gear is physically stored in an inventory location
Create CI Record Network Gear
The Network Gear Administrator is responsible for creating the Network Gear CI Record in Administrator
ServiceNow. The following fields are required when the Status is Received & Inventoried.

Received:
Status auto populated on creation
Name
Manufacturer
5 Model Name
Category
Serial Number (unique identifier)
Support Group
Building Location
Room

Inventoried:
Purchase Order
Deployed

6 Prepare Network Gear for Deployment Network Gear

Administrator

7 Initiate Change Process Network Gear

Administrator

Page 5
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

8 Update CI Record as Necessary Network Gear

The Network Gear Administrator is responsible for updating the Network Gear CI Record in Administrator
ServiceNow. The following field is required when the Status is Deployed.

Deployed:
Tier (Criticality)
Static IP Address
Establish relationships between CIs
9 Attribute Changes? Network Gear
Yes Go to Step 8 Administrator
No Go to Step 10
10 Deprovision? Network Gear
Yes Go to Step 11 Administrator
No Go to Step 9
Deprovisioned

11 Initiate Change Process Network Gear

Administrator

12 Remove Network Gear from Service Network Gear

The Network Gear Administrator can manually remove the Network Gear CI from service Administrator
by deprovisioning the record or the ServiceNow Swap feature can be used to replace the
CI in service with a CI from Inventory.
13 Update CI Record Network Gear
The Network Gear Administrator is responsible for updating the Network Gear CI Record in Administrator
ServiceNow. The following field is required when the Status is Deprovisioned:
Disposition Type
A task will be created for the Support Group as a reminder to do the following:
Update the vendor maintenance contract
Submit an EIMR (Equipment Inventory Modification Request), if the Network Gear CI
was over $5,000.00

5.7 Network Gear Exit Criteria

The Network Gear CI has been removed from service, the CI has been deprovisioned and the
Deprovisioning Task has been closed.

Page 6
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 6. Server Class Process and Procedures

6.1 Scope
The Server Class will include the following category types:

Physical Server
Virtual Server
Console Server
Appliance

6.2 Server Class Lifecycle

Received Inventoried Deployed Deprovisioned

Received: Inventoried: Deployed: Deprovisioned:

CI is physically in CI is available for CI is delivered and CI has reached the
the possession of deployment placed into service end of the lifecycle
the team that will and is retired from
deploy it service

6.3 Server Class Lifecycle Process

Server Class Lifecycle Process v3.2

Lifecycle Stages: Received Inventoried Deployed Deprovisioned

START
Server Engineering Server
Class Administrator

1 2
Receive Server Build Virtual or 6
Virtual
Request from Physical Server
Applications ? Provisioning
No process
7
Physical 8
Create CI
Initiate
Record
3 Operational
Establish
Receive 4 Acceptance
Relationship
Process
Server Operations

Server, Add/Modify to Application

Rack and Manufacturer
Stack ?
9
Initiate
Change
Process

Yes
Yes
Server Class Company Administrator

10 15
14
Update 11 Update CI
Remove
5 CI Attribute Record
Server from
Server Operations/

Update Record Changes (Including

Service
Manufacturer/ as ? Relationships)
Vendor Necessary
Information
No No

12 13 END
End of Initiate
Yes
Life Change
? Process

Page 7
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

6.4 Server Class RACI Chart

Responsible Those who do the work, facilitate it and/or organize it

Accountable The one who ensures the desired outcomes are reached and has yes/no decision making authority
Consulted Those who have critical expertise to contribute before a decision is made
Informed Those who are significantly affected by the activity/decision and must be informed to ensure successful implementation

6.5 Server Class Entry Criteria

A server build request is received from Applications.

6.6 Server Class Procedures

ID Step Responsibility

Received

Receive server build request from Applications Server Engineering

1
Class Administrator
Virtual or Physical? Server Engineering
2 Yes Go to Step 6
No Go to Step 3
Receive Server, Rack and Stack Server Engineering
3
Server Operations
Add/Modify Manufacturer? Server Engineering
The Server Administrator determines if the Manufacturer information is in the system and needs to Server Administrator
4 be updated or is not in the system and must be added.
Yes Go to Step 5
No Go to Step 6

Page 8
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

Update Manufacturer/Vendor Information Server Operations/

The Server Company Administrator is responsible for updating the Company, OS Version and Server Company
Model tables in ServiceNow with the following information: Administrator
Manufacturer
5
Model
Vendor
OS Vendor
OS Version

Inventoried

6 Server Provisioning Process Server Engineering

Create CI Record establish relationship to application Server Engineering

The Server Administrator is responsible for creating the Server CI Record in ServiceNow. The Server Operations
following fields are required when the Status is Received & Inventoried:

Received:
Status auto populated on creation
Name
Manufacturer
7 Model Name
Serial Number (unique identifier)
Support Group
Building Location
Processor Type (not required if Category = Appliance)

Inventoried:
Category
Establish Application relationship(s)
Deployed

8 Initiate Operational Acceptance Process Server Engineering

The Server is configured and prepared for Production Operation Server Operations
9 Initiate Change Process Server Operations
Change Request is created by Server Operations and assigned to Server Operations who presents
the change at CAB, processing it through closure.
10 Update CI Record as Necessary Server Operations
The Server Administrator is responsible for updating the Server CI Record in ServiceNow and Server Administrator
establishing the relationships. The following fields are required when the Status is Deployed:
Tier (Criticality)
User Organization
Maintenance Conditions
Backup System RPO
Cabinet Location
Rack Unit Position
Chassis
Environment
Maintenance Group
Maintenance Window

Page 9
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

11 Attribute Changes? Server Operations

The Server Administrator is responsible for updating the CI record when the server attributes Server Administrator
change.
Yes Go to Step 10
No Go to Step 12
12 End of Life? Server Operations
The Server Administrator determines that server has reached end of life. Server Administrator
Yes Go to Step 13
No Go to Step 11
Deprovisioned

13 Initiate Change Process Server Operations

The Server Administrator creates the Change Request and processes it through closure. Server Administrator

14 Remove Server from Service Server Operations

The Server Administrator can manually remove the Server CI from service by deprovisioning the Server Administrator
record in ServiceNow.
15 Update CI Record (Including Relationships) Server Operations
The Server Administrator is responsible for updating the Server CI Record in ServiceNow. The Server Administrator
following field is required when the Status is Deprovisioned:
Deprovisioned Date auto populated when status is set to Deprovisioned
Disposition Type
A warning message is presented when the Status is Deprovisioned
Please attach the appropriate deprovisioning worksheet

6.7 Server Class Exit Criteria

The Server CI has been removed from service, the CI has been deprovisioned and the
deprovisioning worksheet has been attached to the Change Request.

Page 10
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 7. Storage Class Process and Procedures

7.1 Scope
The Storage Device Class will include the following category types:

NAS Network Attached Storage

SAN Storage Area Network
DAS Direct Attached Storage

7.2 Storage Class Lifecycle

Received Inventoried Deployed Deprovisioned

Received: Inventoried: Deployed: Deprovisioned:

CI is physically in CI is available for CI is delivered and CI has reached the
the possession of deployment placed into service end of the lifecycle
the team that will and is retired from
deploy it service

7.3 Storage Class Lifecycle Process

Storage Class Lifecycle Process v2.1

Lifecycle Stages: Received Inventoried Deployed Deprovisioned

START Y
5 7 13
1 2 6 9 10 11 14
4 Store Prepare Remove
Receive Add/Modify Update Update Attribute End of Update
No Create Storage Storage N Storage
Storage Manufacturer CI Record, CI Changes Life CI
CI Record Device, if Device for Device from
Storage Device Administrator*

Device ? If necessary Record ? ? Record

Server ENGINEERING

necessary Deployment Service

Y
N END
8 12
Initiate Initiate
Change Change
Process Process

Yes

3
Update
Manufacturer/
Vendor
Storage Device Company Administrator*

Information
Server ENGINEERING

Page 11
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

7.4 Storage Class RACI

Responsible Those who do the work, facilitate it and/or organize it

Accountable The one who ensures the desired outcomes are reached and has yes/no decision making authority
Consulted Those who have critical expertise to contribute before a decision is made
Informed Those who are significantly affected by the activity/decision and must be informed to ensure successful implementation

7.5 Storage Class Entry Criteria

The Storage Device Procurement process has been completed and the Storage Device has been
physically accepted by the Storage Device Administrator.

7.6 Storage Class Procedures

ID Step Responsibility

Received

Received Storage Device Server ENGINEERING Storage

1 Device Administrator
The Storage Device is physically received by the Storage Device Administrator.
Add/Modify Manufacturer? Server ENGINEERING Storage
The Storage Device Administrator determines if the Manufacturer information is in the system and Device Administrator
2 needs to be updated or is not in the system and must be added.
Yes Go to Step 3
No Go to Step 4

Page 12
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

Update Manufacturer/Vendor Information Server ENGINEERING Storage

The Storage Device Company Administrator is responsible for updating the Company, OS Version Device Company Administrator
and Model tables in ServiceNow with the following information:
Manufacturer
3
Model
Vendor
OS Vendor
OS Version
Create CI Record Server ENGINEERING Storage
The Storage Device Administrator is responsible for creating the Storage Device CI Record in Device Administrator
ServiceNow. The following fields are required when the Status is Received:

Status auto populated on creation

Name
Manufacturer
Model Name
4
Serial Number (unique identifier)
Support Group

NOTES Following to be reviewed via workshop with Class Owner:

After Save is selected:
Category=Resource is defaulted (other options: NAS, SAN, DAS, UPS)
Subcategory=File Share, is defaulted (other options: Controller, Storage, Enclosure with Disks)
These are NOT required fields
Inventoried

5 Store Storage Device Server ENGINEERING Storage

The Storage Device is physically stored in an inventory location. Device Administrator

6 Update CI Record Server ENGINEERING Storage

The Storage Device Administrator is responsible for updating the Storage Device CI Record in Device Administrator
ServiceNow. The following field is required when the Status is Inventoried
Status
Deployed

7 Prepare Storage Device for Deployment Server ENGINEERING Storage

The Storage Device is configured and prepared for Deployment Device Administrator

8 Initiate Change Process Server ENGINEERING Storage

Device Administrator
9 Update CI Record Server ENGINEERING Storage
The Storage Device Administrator is responsible for updating the Storage Device CI Record in Device Administrator
ServiceNow and establishing the relationships. The following fields are required when the Status is
Deployed:
Status
Tier (Criticality)
Establish Relationships Between CIs

Page 13
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

10 Attribute Changes? Server ENGINEERING Storage

The Storage Device Administrator is responsible for updating the CI record when the server Device Administrator
attributes change.
Yes Go to Step 9
No Go to Step 11

11 End of Life? Server ENGINEERING Storage

The Storage Device Administrator determines that server has reached end of life. Device Administrator
Yes Go to Step 12
No Go to Step 10

Deprovisioned

12 Initiate Change Process Server ENGINEERING Storage

Device Administrator
13 Remove Storage Device from Service Server ENGINEERING Storage
The Storage Device Administrator can manually remove the Storage Device CI from service by Device Administrator
deprovisioning the record in ServiceNow.
13 Update CI Record Server ENGINEERING Storage
The Storage Device Administrator is responsible for updating the Storage Device CI Record in Device Administrator
ServiceNow. The following fields are required when the Status is Deprovisioned:
Deprovisioned Date auto populated when status is set to Deprovisioned
Disposition Type
A warning message is presented when the Status is Deprovisioned
Please attach the appropriate deprovisioning worksheet

7.7 Storage Class Exit Criteria

The Storage Device CI has been removed from service, the CI has been deprovisioned and the
deprovisioning worksheet has been attached to the Change Request.

Page 14
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 8. Application Class Process and

Procedures
8.1 Scope
The Applications Class will include applications that are tracked through SDLC and Change
Management process and which support a service that is delivered to a customer. This includes
instances in various environments such as:

Production PRD
Test - TST
Development - DEV
Stage STG
Training TRN
Performance PERF
Sandbox SBX
Disaster Recovery - DR
Support SUP

8.2 Definition: Business Service Application - Software

Class Description Examples

Business Service A category of services, which Applications, Access & Accounts

includes applications and
software.

Application Runs on a server. Solutions built Exchange, Epic, MyAccess

on top of applications can be
listed as modules (usually
customer-facing) or utilities
(usually administrative). Can be
developed and/or hosted
internally, or developed and/or
hosted by a vendor.

Software Is a client and/or runs on an Adobe Acrobat Pro, iList,

endpoint (e.g., desktop, laptop, Perceptive Experience
mobile device). This can include
commercial software or desktop
and mobile applications created
in-house.

Page 15
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

8.3 Application Class Lifecycle

Build:
Application CI is being
prepared for operations
(new applications)

Build

Retired:
Application CI
has reached the end of the Retired
lifecycle and is retired
Operational

Operational
Application CI
is in service

Page 16
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

8.4 Application Class Lifecycle Process

Application Class Lifecycle Process v2.2

Lifecycle Stages: Build Operational Retired

START
Yes
Application Class Administrator

3 8 9 10 13
1 2 7 11 12
Vendor Update Finalize Update Initiate
Identify Create Application Attribute End of
Hosted Yes CI Application CI No Yes Application
New CI Record Configuration Changes Life
Application Record as Production Record as Retirement
Application Process ? ?
? necessary Process necessary Process

No
14
Remove
No Application
from Service

4 6 15
Open Receive Update
ServiceNow Notice CI
Ticket for Application Record as
Systems Installed necessary

END

5
Server Team

Initiate
Server
Process

8.5 Application Class RACI

Page 17
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Responsible Those who do the work, facilitate it and/or organize it

Accountable The one who ensures the desired outcomes are reached and has yes/no decision making authority
Consulted Those who have critical expertise to contribute before a decision is made
Informed Those who are significantly affected by the activity/decision and must be informed to ensure successful implementation

8.6 Application Class Entry Criteria

The Application has been installed on a server and is ready for configuration.

8.7 Application Class Procedures

ID Step Responsibility

Build

Identify New Application Application Administrator

1
The need for a new application is identified by the Application Administrator.
Create CI Record Application Administrator
The Application Administrator is responsible for creating the Application CI Record in ServiceNow. The
following fields are required when the Status is Build:
Status auto populated on creation
Application Name
Version
Manufacturer Product Name
Manufacturer Product Version
Business Owner
Category
DR Site
2
Location (if DR Site=Other)
Number of Users
User Organization
Environment
Distribution List
Support Group
Description
Tier (Criticality) This field will state, Pending Business Impact Analysis and be grayed out. To establish
Tier level, create a Request Item:
o Go to website: https://ucsf.service-now.com/ess/ and select Consulting & Development >
Business Impact Analysis Request. You will be contacted by a BIA ITSM team member.
Vendor Hosted Application Application Administrator
3 Yes Go to Step 7
No Go to Step 4
Open ServiceNow Ticket for Systems Application Administrator
The Application Administrator is responsible for opening a ServiceNow ticket for the Server team. The ticket
4 will include:
Hardware Requirements
Application CI Record

5 Initiate Server Process Server Team

Received Notice Application Installed Application Administrator

6 The Application Administrator has been notified that the application is installed and available for the build to
start.

Page 18
 Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

ID Step Responsibility

7 Application Configuration Process Application Administrator

8 Update CI Record as Necessary Application Administrator

Operational

9 Finalize Application Production Process Application Administrator

The Application is prepared to be operational.
10 Update CI Record as Necessary Application Administrator
The Application Administrator is responsible for updating the Application CI Record in ServiceNow and
establishing the relationships. The following fields are required when the Status is Operational:
Status
Hosted By
Support Hours
Operational Date
Establish Relationships Between CIs Working with other respective IT Departments (Server), as
necessary
(Update Version if this is an upgrade)
11 Attribute Changes? Application Administrator
If the Application is being upgraded only the Version field on the CI record must be updated.

Yes Go to Step 10
No Go to Step 12
12 End of Life? Application Administrator
Yes Go to Step 13
No Go to Step 11
Retired

13 Initiate Application Retirement Process Application Administrator

Includes a Change Request if necessary
14 Remove Application from Service Application Administrator
The Application Administrator can manually remove the Application CI from service by updating the status to
Retired.
15 Update CI Record as Necessary Application Administrator
The Application Administrator is responsible for updating the Application CI Record in ServiceNow. The
following field is required when the Status is Retired:
Retired Date auto populated when status is set to Retired

8.8 Application Class Exit Criteria

The Application Administrator has taken the Application out of service and the status has been
set to retired.

Page 19
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 9. Establishing Relationships in the CMDB

9.1 Applications and Server Relationships
All relationships within ServiceNow are Parent/Child.

Application A [Depends On] Server B

Server B [Is a Dependency for] Application A

Page 20
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 10.SACM CMDB Audit Protocol

10.1 SACM CMDB Audit Purpose
The purpose of this protocol is to perform periodic audits of the Information Technology Service
Management (ITSM) CMDB. The CMDB is the source of truth for CIs and their relationship to
other CIs at UCSF. These audits will ensure adherence to the SACM process and the ongoing
accuracy of the CMDB.

10.4 Background
This audit protocol was initially identified as an IT departmental goal for FY16 (see appendix
14.2), however the result of this effort was adopted as an ongoing periodic audit of the SACM
CMDB. Ongoing periodic audits will be performed on a quarterly basis.

10.3 SACM CMDB Audit Process

The SACM process ensures the integrity of the IT infrastructure by tracking, recording and
reporting on CIs and their relationships to other CIs. This process is supported by the CMDB as
the vehicle for managing and controlling these CIs. Periodic audits of the CMDB will confirm the
records to be the accurate source of truth for CIs within the UCSF IT infrastructure.

The periodic audit will consist of a three pronged approach to validate the data found in each
record as well as the relationships between CIs.

Spot Check Validation Randomly select at least 20% of records from each CI class
to be validated
Recent Activity Validation Select all CI records updated in the past three months
sorted by class
Identification of Irregularities Export all to a spreadsheet and sort by class, inspect
and identify inconsistencies/irregularities

The following policy guidelines provide the framework for ensuring the integrity of the critical CI
records contained in the CMDB:

The Class Administrator is responsible for ensuring the accuracy of the record for
each CI.
Periodic auditing of randomly selected records from the CMDB is the accepted
method of validating record accuracy.
Records will be selected in such a way to be representative of the entire database
and all records will have the same chance of being selected.
The audit is performed on the required fields for each CI record to ensure accuracy
and to confirm applications are correctly linked to associated servers.
The data fields in the selected records will be validated against information gained
from the actual CI.
A designated neutral party selected by the Process Owner is responsible for
performing the data review and relationship validation for the records audited.
Compliance will be calculated based upon the cumulative results for all the CI
records selected for validation.

Ongoing periodic audits will be performed on a quarterly basis.

Page 21
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 11.CMDB Structure & Business Service

Versus Application
11.2 CMDB Structure Model

The bottom layers, physical and logical are the Infrastructure CIs. Infrastructure is mostly closely
associated with the hardware devices in the environment.

The middle layer or system, are the Applications CIs. Applications are the software elements that
are directly touched and felt by end users. Examples include Microsoft Exchange, PeopleSoft,
ServiceNow ITSM, or custom shipment-tracking system. Products like Microsoft Internet Explorer,
MS Word, and Adobe Acrobat can also be seen as applications, but UCSF decided to include
these in the software class instead. The distinction is applications require development and
typically goes through a software development lifecycle (SDLC). Items in the Software class are
off the shelf product you just install.

Business Service is the top layer of the CMDB structure model. Ideally, every application CI
should support and roll up to a business service, i.e., PeopleSoft Financials and PeopleSoft
RAS applications supports the business service Financial Services or ServiceNow and
PagerDuty supports the business service Service Management Services. This class has not
been formally rolled out so no review of attributes has been done or things added and removed
have not yet been formally managed. UCSF is purely using this CI class right now for
categorization purposes in Incident and Service Request. This class will be looked at formally as
part of the Service Catalog / Service Portfolio at a future date. Until a process for this class is
completed, information that needs to be tracked where there is no attribute, put it in the
description field for now. There may currently be CIs in the Business Service class that needs to
be in the Application or Software Class.

All three classes (Business Service, Application and Software) potentially have to go through
Change Control, so this is not a distinguishing factor.

Page 22
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 12. Glossary

Define all terms and acronyms required to interpret the Project Charter properly.

Page 23
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 13.Revision History

Version Date Name Description

1.0 05/10/13 Terrie Coleman Initial Draft

2.0 12/30/13 Terrie Coleman Updated individual process maps, RACI and procedures

Updates due to process transition and necessary revisions

3.0 04/27/15 Lynn Bosworth
throughout document

Updates stemmed from Class Owner Workshops, i.e., Server Class

3.1 05/15/15 Lynn Bosworth
new Visio, modified RACI and procedures.

Added to Appendix: Added CMDB Structure & Business Service vs

3.2 09/02/15 Lynn Bosworth Application. Added Communication Devices Class Owners. Added
Relationships chart

4.0 12/28/15 Kevin Barney Revised format, updated process maps and added Audit Protocol

Addition of ITSCM Role & Business Service, Application and

4.1 06/15/16 Kevin Barney
Software definition

4.2 10/17/16 Lynn Bosworth Updating Class Owners and SMEs, section 14.1.

Completed updates to all Classes (added, moved, removed field

4.3 02/23/17 Lynn Bosworth names, status changes of when fields are required) and other
updates throughout.

Page 24
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Section 14.Appendices
14.1 CI Class Owners & Subject Matter Experts
Class Owners & SMEs

Network Gear
Ian Gwin Class Owner ITS Sean Morford SME ITS

Steve Young Class Owner MC Emerson Mendoza SME MC

Server
Don Francis Class Owner Operations David Carcamo SME
ITS & MC
Don Francis Class Owner Rolinda Wang SME
Engineering ITS & MC
Storage
Don Francis Class Owner Operations David Carcamo SME
ITS & MC
Don Francis Class Owner Rolinda Wang SME
Engineering ITS & MC
Applications
Irene Brezman Class Owner MC Pilar Collins SME MC
Natasha Komarovskaya SME MC
Connie Standfield SME MC

Mimi Sosa Class Owner ITS Freddie Tai SME ITS

Andy Li SME ITS

Communication Devices Class

Sunny Bang Class Owner IT Connie Standfield SME
Clinical Systems

Ian Gwin Class Owner IT All Matt McFetridge (Video & SME MC/ITS
Others TeleHealth)
SME MC/ITS
Graham Perkins (Unified
Communications)

14.2 SACM CMDB FY16 Goal Milestone Schedule

IT Department FY16 Goal Improve IT Service Management through the implementation of
operational processes

Implementation of an IT Configuration Management Database

Identify configuration items and their relationships
Establish processes that define the full lifecycle of configured items and establish
CMDB audit protocol
Identify Tier 1 and 2 of IT supported production applications, servers and network
gear for populating data and managing in CMDB
Identify IT managed applications for populating data and linking to associated servers

Page 25
Service Transition USER GUIDE
Service Asset and Configuration Management Process 4.3 | 02/23/2017

Planned Completion
Milestone/Deliverable
Date
Threshold December 31, 2015

Development and adoption of the CMDB Audit Protocol Policy (this

document)
Creation of the audit sampling mechanism developed and ready for use March 15, 2016
Target March 31, 2016

First audit demonstrates that 90% of Tier 1 and 2 IT supported

production Applications, Servers and Network Gear records are
accurately populated and managed in the CMDB

To determine the percentage met, a random sampling of 20 CIs from

each CMDB Class (Application, Server, and Network Gear) will be
audited based on Audit protocol established. The audit must reveal
that 90% of the CIs audited are accurately managed
Outstanding June 30, 2016

Second audit demonstrates that 90% of IT managed applications as of

May 31, 2015 are populated and accurately linked to associated
server(s)

To determine the percentage met, a random sampling of 30 Application

CIs will be audited based on Audit Protocol established. The audit must
reveal that 90% of the audited Application CIs are accurately linked to
associated server(s)

Page 26