SERVICE ASSET AND CONFIGURATION MANAGEMENT PROCESS Version 3, Rev. May 5, 2015
Document Version Control Document Name Process Owner Service Asset and Configuration Management Process Rebecca Nguyen Version Number Issue Date Prepared By Reason for Change 1.0 05/10/13 Terrie Coleman Initial Draft 1.1 09/11/13 Terrie Coleman Updates from Rebecca 1.2 09/13/13 Terrie Coleman Updates based on Network Gear team meeting 1.3 09/18/13 Terrie Coleman DNS Name Process added 1.4 09/26/13 Terrie Coleman Updates based on DNS team meeting 1.5 09/26/13 Terrie Coleman Server Process added 1.6 10/01/13 Terrie Coleman Storage Device Process added 1.7 10/23/13 Terrie Coleman Application Process added 1.8 11/27/13 Terrie Coleman Updated Application process based on team review. 1.9 12/27/13 Terrie Coleman Updated Server process map, RACI and procedures 2.0 12/30/13 Terrie Coleman Updated Storage Device process map, RACI and procedures 2.1 01/03/14 Terrie Coleman Updated DNS process map, RACI and procedures 3.0 04/27/15 Lynn Bosworth Updates due to process transition and necessary revisions throughout document CI Class Process Implementation Workshop Participants Network Gear Name and Reviewed Date Kevin Barney 09/12/13 Sean Schluntz 09/12/13 Mike Kilpatrick 09/12/13 Steve Young 09/12/13 Pascal Parrott 09/12/13 DNS Name Kevin Barney 09/26/13 Sean Schluntz 09/26/13 Greg Lennon 09/26/13 Steve Young 09/26/13 Pascal Parrott 09/26/13 Server Kraig Kluba Greg Lennon Chris Miller Rolinda Wang Storage Greg Lennon Rolinda Wang Chris Miller Applications Kevin Barney 12/06/13 Mimi Sosa 12/06/13 David Berluti 12/06/13 Darlena Torres 12/06/13 UCSF Internal Use Only 2 of 33 Revision: 05/05/15
Table of Contents SERVICE ASSET AND CONFIGURATION MANAGEMENT PROCESS... 1... 1 1. INTRODUCTION... 5 1.1. PURPOSE... 5 1.2. GOAL... 5 1.3. OVERVIEW... 5 1.4. KEY RELATIONSHIPS WITH OTHER PROCESSES... 6 1.5. DEFINITIONS... 7 2. ROLES AND RESPONSIBILITIES... 8 2.1. PROCESS OWNER/CONFIGURATION MANAGER... 8 2.2. CONFIGURATION ITEM (CI) CLASS OWNER... 8 2.3. CONFIGURATION ITEM (CI) CLASS ADMINISTRATOR... 8 2.4. CONFIGURATION ITEM (CI) COMPANY ADMINISTRATOR... 9 2.5. IT STAFF... 9 2.6. ITSM PRODUCT MANAGER... 9 3. AND RELATIONSHIP MAP... 10 4. CONFIGURATION MANAGEMENT DATABASE... 11 4.1. CMDB CONTENT & STRUCTURE... 11 4.2. CONFIGURATION ITEM CLASSES... 12 5. NETWORK GEAR CLASS PROCESS AND PROCEDURES... 12 5.1. SCOPE... 12 5.2. NETWORK GEAR CLASS LIFECYCLE... 13 5.3. NETWORK GEAR CLASS ACTIVITY DIAGRAM... 14 5.4. NETWORK GEAR CLASS RACI CHART... 15 5.5. NETWORK GEAR ENTRY CRITERIA... 15 5.6. NETWORK GEAR PROCEDURE... 15 5.7. NETWORK GEAR EXIT CRITERIA... 17 6. DNS NAME CLASS PROCESS AND PROCEDURES... 17 6.1. SCOPE... 17 6.2. DNS NAME CLASS LIFECYCLE... 17 6.3. DNS NAME ACTIVITY DIAGRAM... 18 6.4. DNS NAME RACI... 18 6.5. DNS NAME ENTRY CRITERIA... 18 6.6. DNS NAME PROCEDURES... 19 6.7. DNS NAME EXIT CRITERIA... 19 7. SERVER CLASS PROCESS AND PROCEDURES... 20 7.1. SCOPE... 20 7.2. SERVER CLASS LIFECYCLE... 20 7.3. SERVER CLASS ACTIVITY DIAGRAM... 20 7.4. SERVER CLASS RACI... 21 7.5. SERVER CLASS ENTRY CRITERIA... 21 7.6. SERVER CLASS PROCEDURES... 21 7.7. SERVER CLASS EXIT CRITERIA... 23 8. STORAGE CLASS PROCESS AND PROCEDURES... 24 8.1. SCOPE... 24 UCSF Internal Use Only 3 of 33 Revision: 05/05/15
8.2. STORAGE CLASS LIFECYCLE... 24 8.3. STORAGE CLASS ACTIVITY DIAGRAM... 24 8.4. STORAGE CLASS RACI... 25 8.5. STORAGE CLASS ENTRY CRITERIA... 25 8.6. STORAGE CLASS PROCEDURES... 25 8.7. STORAGE CLASS EXIT CRITERIA... 27 9. APPLICATION CLASS PROCESS AND PROCEDURES... 28 9.1. SCOPE... 28 9.2. APPLICATION CLASS LIFECYCLE... 28 9.3. APPLICATION CLASS ACTIVITY DIAGRAM... 29 9.4. APPLICATION CLASS RACI... 29 9.5. APPLICATION CLASS ENTRY CRITERIA... 30 9.6. APPLICATION CLASS PROCEDURES... 30 9.7. APPLICATION CLASS EXIT CRITERIA... 31 UCSF Internal Use Only 4 of 33 Revision: 05/05/15
This document contains confidential, proprietary information intended for internal use only and is not to be distributed outside the University of California, San Francisco (UCSF) without an appropriate non-disclosure agreement in force. Its contents may be changed at any time and create neither obligations on UCSF s part nor rights in any third person. 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 required to deliver 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 (CI). 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 subprocesses: 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 Configuration Items (CIs). This includes specifying the attributes describing CI types and their sub-components, as well as determining their interrelationships. UCSF Internal Use Only 5 of 33 Revision: 05/05/15
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. 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 should 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. UCSF Internal Use Only 6 of 33 Revision: 05/05/15
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: the CI s 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 organization s 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. UCSF Internal Use Only 7 of 33 Revision: 05/05/15
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 (CI) 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 (CI) CLASS ADMINISTRATOR There are usually several Class s for each CI class. In practice, the CI Class s 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 they re maintaining the CIs appropriately so 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 UCSF Internal Use Only 8 of 33 Revision: 05/05/15
Establishes relationships between CIs 2.4. CONFIGURATION ITEM (CI) COMPANY ADMINISTRATOR There are usually only one or two Company s. (This role can also be filled by a Class or Class Owner). It is elevated access from Class, but not all Class s 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 has same rights as a CI, 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 s may be the Class Owner plus one ( maybe two) CI Class s 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 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.6. ITSM PRODUCT MANAGER Manages the Service Asset and Configuration Management module Develop enhancements to CMDB Manages the Discovery tool UCSF Internal Use Only 9 of 33 Revision: 05/05/15
3. AND RELATIONSHIP MAP Incident Management Process Problem Management Process (TBD) Release Management Process Change Management Process Assists with Root Cause Analysis Assists in Lowering Risk to Production Enables Accurate Incident Routing CMDB Aids in Lowering Risk by understanding impact of Change and Ensures 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 Classes (Planning) Determine Access Control Model Control C)s Conduct Status Accounting Identify Configuration Items Conduct Configuration Verification and Audit Other Process Relationship Incident Management Problem Management Change Management Release Management Incident Management uses CI information to understand what CIs are involved in an incident Problem Management uses CI information to help track down the root cause of a problem Change Management uses CI information to understand the ramifications of a proposed change Release Management updates the Configuration Management System (CMS)* with information about deployed releases UCSF Internal Use Only 10 of 33 Revision: 05/05/15
* CMS: A set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes. 4. CONFIGURATION MANAGEMENT DATABASE 4.1. CMDB CONTENT & STRUCTURE The CMDB contains the following CI Class Configuration Items Attributes Relationships Example of the CMDB Structure Note: This example will be replaced with a UCSF example once it has been developed. UCSF Internal Use Only 11 of 33 Revision: 05/05/15
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. Class Name Description Network Gear Any piece of networking equipment that passes packets DNS Name Logical Host layer identifier Server Physical or Virtual computer dedicated to run one or more services (as a host), to serve the needs of the users of other computers on a network. Also includes console server. Storage Devices used for storing data Application Software that supports a business process. Data Center Any piece of equipment or application to support that environment, i.e., racks, monitoring systems Computer Done as part of Asset Management Printer Done as part of Asset Management Business Services An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business. Note: Additional classes will be implemented over time. 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 UCSF Internal Use Only 12 of 33 Revision: 05/05/15
5.2. NETWORK GEAR CLASS LIFECYCLE Received: CI is physically in the possession of team that will deploy it Received Deprovisioned: CI has reached the end of the lifecycle and is retired Deprovisioned Inventoried Inventoried: CI is available for deployment Deployed Deployed: CI is delivered and in service UCSF Internal Use Only 13 of 33 Revision: 05/05/15
5.3. NETWORK GEAR CLASS ACTIVITY DIAGRAM Network Gear Lifecycle Process v2.0 Lifecycle Stages: Received Inventoried Deployed Deprovisioned START Network Gear (aka CI Class Admin) 1 Receive Network Gear 2 Add/Modify Manufacturer? Yes bo 4 Create CI Record 5 Store Network Gear 6 Update CI Record 7 Prepare Network Gear for Deployment 8 Initiate Change Process 9 Update CI Record 11 Remove Network Gear from Service 10 Initiate Change Process 12 Update CI Record END Network Gear Company (aka CI Company Admin) 3 Update Manufacture/ Vendor Information Company Table Updates Manufacturer Vendor OS Vendor ServiceNow OS Version Table OS Version Model Table Model Name auto populated Name Serial #/Service Tag Support Group Category Manufacturer Model Name PO # Building Location Room Criticality Establish Relationships Provide Rack Info Deprovisioned Date - auto populated Disposition Type Create Task Update Vendor Maintenance EIMR If necessary UCSF Internal Use Only 14 of 33 Revision: 05/05/15
5.4. NETWORK GEAR CLASS RACI CHART 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 5.6. NETWORK GEAR PROCEDURE ID Step Responsibility Received 1 2 3 Received Network Gear The Network Gear is physically received by the Network Gear. Add/Modify Manufacturer? The Network Gear determines if the Manufacturer information is in the 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 The Network Gear Company is responsible for updating the Company, OS Version and Model tables in ServiceNow with the following information: Manufacturer Model Vendor OS Vendor OS Version Network Gear Network Gear Network Gear Company UCSF Internal Use Only 15 of 33 Revision: 05/05/15
ID Step Responsibility 4 Create CI Record The Network Gear is responsible for creating the Network Gear CI Record in ServiceNow. The following fields are required when the Status is Received: auto populated on creation Name Manufacturer Model Name Category Serial Number (unique identifier) Purchase Order Support Group Building Location Establish relationships between CIs Network Gear Inventoried 5 Store Network Gear The Network Gear is physically stored in an inventory location 6 Update CI Record The Network Gear is responsible for updating the Network Gear CI Record in ServiceNow. The following field is required when the Status is Inventoried Room Network Gear Network Gear Deployed 7 Prepare Network Gear for Deployment The Network Gear is configured and prepared for Deployment Network Gear 8 Initiate Change Process Network Gear 9 Update CI Record The Network Gear is responsible for updating the Network Gear CI Record in ServiceNow and establishing the relationships. The following field is required when the Status is Deployed: Criticality Network Gear Deprovisioned 10 Initiate Change Process Network Gear 11 Remove Network Gear from Service The Network Gear can manually remove the Network Gear CI from service by deprovisioning the record or the ServiceNow Swap feature can be used to replace the CI in service with a CI from Inventory. 12 Update CI Record The Network Gear is responsible for updating the Network Gear CI Record in 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 Network Gear Network Gear UCSF Internal Use Only 16 of 33 Revision: 05/05/15
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. 6. DNS NAME CLASS PROCESS AND PROCEDURES 6.1. SCOPE DNS Name records will be stored in the ServiceNow CMDB when they are created for the Configuration Item Classes being tracked in ServiceNow; this will include Network Gear, Server, and Storage CIs. As new CI Classes are added to the CMDB they will be included in the DNS Name Class scope. 6.2. DNS NAME CLASS LIFECYCLE Active DNS Active: DNS CI is in production and in the Domain Name System Inactive: DNS CI is no longer in production and has been removed from the Domain Name System Inactive DNS UCSF Internal Use Only 17 of 33 Revision: 05/05/15
6.3. DNS NAME ACTIVITY DIAGRAM DNS Name Lifecycle Process v2 Lifecycle Stages: Active Inactive DNS Name (aka CI Class Admin) START 1 Initiate Change Process & Create DNS Name CI Record 2 Create IP Address Record 3 Create Alias Record (if needed) 4 Update Domain Name System (manual) Yes 5 Lnitiate Change trocess & Remove DNS Name from Service 6 Delete IP Address and Alias Record 7 Reuse DNS Name? No END Service Now Fully Qualified Domain Name Active Date Autopopulates Support Group Add Relationships, if necessary Required Field Static IP Address Required Field Alias Name Inactive Date Autopopulates Relationships are unrelated when the status is inactive Delete: IP Address Record Alias Record 6.4. DNS NAME RACI 6.5. DNS NAME ENTRY CRITERIA The DNS Name process kicks off when a CI is going to be added on to the Network. UCSF Internal Use Only 18 of 33 Revision: 05/05/15
6.6. DNS NAME PROCEDURES ID Step Responsibility Active 1 2 3 4 Create DNS Name CI Record The DNS Name is responsible for initiating the Change Process, creating the DNS Name record in Service Now the following fields are required and establishing relationships: Fully Qualified Domain Name (no spaces allowed) - Active Active Date Auto-populates when status = Active Support Group Create IP Address Record The DNS Name is responsible for creating the IP Address record in ServiceNow the following field is required: Static IP Address Create Alias Record (if needed) The DNS Name is responsible for creating an Alias Name record for the DNS Name if it is needed. The following field is required: Alias Name Update Domain Name System (manual) The DNS Name is responsible for making sure that the Fully Qualified Domain Name is logged into the Domain Name System. This is a manual entry. DNS Name DNS Name DNS Name DNS Name Inactive 5 6 7 Remove DNS Name from Service When the DNS Name record is removed from service the DNS Name is responsible for initiating the Change Process and updating the following fields in ServiceNow: set to Inactive Inactive Date Auto-populates when status = Inactive Once the Status is set to inactive all of the Relationships associated with the DNS Record will be unrelated. Delete IP Address and the Alias Name Records When the DNS Name record is removed from service the DNS Name is responsible for removing the IP Address and Alias Name Records from DNS Name Record by selecting the Delete button in ServiceNow. Reuse DNS Name? The DNS Name will determine if the DNS Name will be recycled. Yes Go to Step 1 No END DNS Name DNS Name DNS Name 6.7. DNS NAME EXIT CRITERIA The DNS Name has been retired from service and is available for future reuse. UCSF Internal Use Only 19 of 33 Revision: 05/05/15
7. SERVER CLASS PROCESS AND PROCEDURES 7.1. SCOPE The Server Class will include the following category types: Physical Server Virtual Server Console Server Appliance 7.2. SERVER CLASS LIFECYCLE 7.3. SERVER CLASS ACTIVITY DIAGRAM Server Class Lifecycle Process v2 Lifecycle Stages: Received Inventoried Deployed Deprovisioned START Yes Server (aka CI Class Admin) 1 Receive Server 2 Add/Modify Manufacturer? Yes bo 4 Create CI Record 5 Store Server, if necessary 6 Update CI Record, If necessary 7 Prepare Server for Deployment 8 Initiate Change Process 9 Update CI Record 10 Attribute Changes? bo bo 11 End of Life? Yes 13 Remove Server from Service 12 Initiate Change Process 14 Update CI Record END Server Company (aka CI Company Admin) 3 Update Manufacture/ Vendor Information Company Table Updates Manufacturer Vendor OS Vendor ServiceNow OS Version Table OS Version Model Table Model Name auto populated Name Serial #/Service Tag Category Support Group Manufacturer Model Name Building Location Criticality Environment Establish Relationships Provide Rack & Slot information if necessary Deprovisioned Date -auto populated Disposition Type Attach Deprovision Worksheet UCSF Internal Use Only 20 of 33 Revision: 05/05/15
7.4. SERVER CLASS RACI 7.5. SERVER CLASS ENTRY CRITERIA The Server Procurement process has been completed and the Server has been physically accepted by the Server. 7.6. SERVER CLASS PROCEDURES ID Step Responsibility Received 1 2 Received Server The Server is physically received by the Server. Add/Modify Manufacturer? The Server determines if the Manufacturer information is in the 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 Server Server UCSF Internal Use Only 21 of 33 Revision: 05/05/15
ID Step Responsibility 3 4 Update Manufacturer/Vendor Information The Server Company is responsible for updating the Company, OS Version and Model tables in ServiceNow with the following information: Manufacturer Model Vendor OS Vendor OS Version Create CI Record The Server is responsible for creating the Server CI Record in ServiceNow. The following fields are required when the Status is Received: auto populated on creation Name Manufacturer Model Name Category Serial Number (unique identifier) Support Group Building Location Server Company Server Inventoried 5 Store Server The Server is physically stored in an inventory location. 6 Update CI Record The Server is responsible for updating the Server CI Record in ServiceNow. The following field is required when the Status is Inventoried Server Server Deployed 7 Prepare Server for Deployment The Server is configured and prepared for Deployment Server 8 Initiate Change Process Server 9 Update CI Record The Server is responsible for updating the Server CI Record in ServiceNow and establishing the relationships. The following fields are required when the Status is Deployed: Criticality Processor Type (not required if Category = Appliance) Environment 10 Attribute Changes? The Server is responsible for updating the CI record when the server attributes change. Yes Go to Step 9 No Go to Step 11 11 End of Life? The Server determines that server has reached end of life. Yes Go to Step 12 No Go to Step 10 Server Server Server UCSF Internal Use Only 22 of 33 Revision: 05/05/15
ID Step Responsibility Deprovisioned 12 Initiate Change Process Server 13 Remove Server from Service The Server can manually remove the Server CI from service by deprovisioning the record in ServiceNow. 14 Update CI Record The Server is responsible for updating the Server CI Record in ServiceNow. The 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 Server Server 7.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. UCSF Internal Use Only 23 of 33 Revision: 05/05/15
8. STORAGE CLASS PROCESS AND PROCEDURES 8.1. SCOPE The Storage Device Class will include the following category types: NAS Network Attached Storage SAN Storage Area Network DAS Direct Attached Storage 8.2. STORAGE CLASS LIFECYCLE 8.3. STORAGE CLASS ACTIVITY DIAGRAM Storage Device Class Lifecycle Process v2.0 Lifecycle Stages: Received Inventoried Deployed Deprovisioned START Y Storage Device (aka CI Class Admin) 1 Receive Storage Device 2 Add/Modify Manufacturer? Yes bo 4 Create CI Record 5 Store Storage Device, if necessary 6 Update CI Record, If necessary 7 Prepare Storage Device for Deployment 8 Initiate Change Process 9 Update CI Record 10 Attribute Changes? b b 11 End of Life? Y 13 Remove Storage Device from Service 12 Initiate Change Process 14 Update CI Record END Storage Device Company (aka CI Company Admin) 3 Update Manufacture/ Vendor Information Company Table Updates Manufacturer Vendor OS Vendor ServiceNow OS Version Table OS Version Model Table Model Name auto populated Name Serial #/Service Tag Support Group Manufacturer Model Name Provide Building & Room location, if necessary Category Criticality Establish Relationships Provide Rack & Slot information if necessary Deprovisioned Date -auto populated Disposition Type Attach Deprovision Worksheet UCSF Internal Use Only 24 of 33 Revision: 05/05/15
8.4. STORAGE CLASS RACI 8.5. STORAGE CLASS ENTRY CRITERIA The Storage Device Procurement process has been completed and the Storage Device has been physically accepted by the Server. 8.6. STORAGE CLASS PROCEDURES ID Step Responsibility Received 1 2 Received Storage Device The Storage Device is physically received by the Storage Device. Add/Modify Manufacturer? The Storage Device determines if the Manufacturer information is in the 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 Storage Device Storage Device UCSF Internal Use Only 25 of 33 Revision: 05/05/15
ID Step Responsibility 3 4 Update Manufacturer/Vendor Information The Storage Device Company is responsible for updating the Company, OS Version and Model tables in ServiceNow with the following information: Manufacturer Model Vendor OS Vendor OS Version Create CI Record The Storage Device is responsible for creating the Storage Device CI Record in ServiceNow. The following fields are required when the Status is Received: auto populated on creation Name Manufacturer Model Name Serial Number (unique identifier) Support Group Storage Device Company Storage Device Inventoried 5 Store Storage Device The Storage Device is physically stored in an inventory location. 6 Update CI Record The Storage Device is responsible for updating the Storage Device CI Record in ServiceNow. The following field is required when the Status is Inventoried Storage Device Storage Device Deployed 7 Prepare Storage Device for Deployment The Storage Device is configured and prepared for Deployment Storage Device 8 Initiate Change Process Storage Device 9 Update CI Record The Storage Device is responsible for updating the Storage Device CI Record in ServiceNow and establishing the relationships. The following fields are required when the Status is Deployed: Category Criticality 10 Attribute Changes? The Storage Device is responsible for updating the CI record when the server attributes change. Yes Go to Step 9 No Go to Step 11 Storage Device Storage Device 11 End of Life? The Storage Device determines that server has reached end of life. Yes Go to Step 12 No Go to Step 10 Storage Device UCSF Internal Use Only 26 of 33 Revision: 05/05/15
ID Step Responsibility Deprovisioned 12 Initiate Change Process Storage Device 13 Remove Storage Device from Service The Storage Device can manually remove the Storage Device CI from service by deprovisioning the record in ServiceNow. 13 Update CI Record The Storage Device is responsible for updating the Storage Device CI Record in 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 Storage Device Storage Device 8.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. UCSF Internal Use Only 27 of 33 Revision: 05/05/15
9. APPLICATION CLASS PROCESS AND PROCEDURES 9.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 9.2. APPLICATION CLASS LIFECYCLE Build: Application CI is being prepared for operations (new applications) Build Retired: Application CI has reached the end of the lifecycle and is retired Retired Operational Operational Application CI is in service UCSF Internal Use Only 28 of 33 Revision: 05/05/15
9.3. APPLICATION CLASS ACTIVITY DIAGRAM Application Class Lifecycle Process v2.0 Lifecycle Stages: Build Operational Retired START Application (aka CI Class Admin) 1 Identify New Application 2 Create CI Record 3 Open ServiceNow Ticket Hardware Requirements Application CI Record 5 Receive Notice Application Installed 6 Configure Application 7 Prepare Application for Deployment Affected Users Support Hours Hosting Criticality 8 Initiate Change Process 9 Update CI Record Yes 10 Attribute Changes? bo bo 11 End of Life? Yes 13 Remove Application from Service 12 Initiate Change Process 14 Update CI Record END ServiceNow Server Team auto-populated Application Name Category Version Business Owner Support Group Environment Main or Module 4 Initiate Server Process Operational Date Support Hours Criticality 9stablish welationships to other applications and interfaces. Update Cields Version Retired Date auto-populated 9.4. APPLICATION CLASS RACI UCSF Internal Use Only 29 of 33 Revision: 05/05/15
9.5. APPLICATION CLASS ENTRY CRITERIA The Application has been installed on a server and is ready for build-out. 9.6. APPLICATION CLASS PROCEDURES ID Step Responsibility Build 1 2 3 Identify New Application The need for a new application is identified by the Application. Create CI Record The Application is responsible for creating the Application CI Record in ServiceNow. The following fields are required when the Status is Received: auto populated on creation Application Name Category Version Business Owner Support Group Environment Main or Module Open ServiceNow Ticket (if applicable, i.e., no server for SAAS) The Application is responsible for opening a ServiceNow ticket for the Server team. The ticket will include: Hardware Requirements Application CI Record Application Application Application UCSF Internal Use Only 30 of 33 Revision: 05/05/15
ID Step Responsibility 4 Initiate Server Process Server Team 5 Received Notice Application Installed The Application has been notified that the application is installed and available for the build to start. Application 6 Configure Application Application Operational 7 Prepare Application for Deployment: Affected User Support Hours Hosting Criticality The Application is prepared to be operational. Application 8 Initiate Change Process Application 9 Update CI Record The Application is responsible for updating the Application CI Record in ServiceNow and establishing the relationships. The following fields are required when the Status is Deployed: Operational Date Support Hours Criticality (Update Version if this is an upgrade) 10 Attribute Changes? If the Application is being upgraded only the Version field on the CI record must be updated. Application Application Yes Go to Step 9 No Go to Step 11 11 End of Life? Yes Go to Step 9 No Go to Step 11 Application Retired 12 Initiate Change Process Application 13 Initiate Application Retire Process The Application can manually remove the Application CI from service by updating the status to Retired. 14 Update CI Record The Application 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 Application Application 9.7. APPLICATION CLASS EXIT CRITERIA UCSF Internal Use Only 31 of 33 Revision: 05/05/15
The Application has taken the Application out of service and the status has been set to Retired. UCSF Internal Use Only 32 of 33 Revision: 05/05/15
This Page Intentionally Left Blank UCSF Internal Use Only 33 of 33 Revision: 05/05/15