Transcription

Service TransitionSERVICE ASSET ANDCONFIGURATION MANAGEMENTPROCESSVERSION: 4.3REVISION DATE: February 23, 2017

Service TransitionService Asset and Configuration Management ProcessUSER GUIDE4.3 02/23/2017ContentsSection 1. Introduction .11.1Purpose .11.2Goal .11.3Overview .11.4Key Relationships with other processes .21.5Definitions.2Section 2. Roles and Responsibilities .42.1Process Owner/Configuration Manager .42.2Configuration Item Class Owner .42.3Configuration Item Class Administrator .42.4Configuration Item Company Administrator .52.5IT Service Continuity Management (ITSCM) Role.52.6IT Staff .52.7ITSM Product Manager .5Section 3. SACM Process and Relationship Map .6Section 4. Configuration Management Database .74.1CMDB Content and Structure .74.2Configuration Item Classes .7Section 5. Network Gear Class Process and Procedures .35.1Scope .35.2Network Gear Class Lifecycle .35.3Network Gear Lifecycle Process .45.4Network Gear Class RACI Chart .45.5Network Gear Entry Criteria .55.6Network Gear Process .55.7Network Gear Exit Criteria .6Section 6. Server Class Process and Procedures .76.1Scope .76.2Server Class Lifecycle .76.3Server Class Lifecycle Process .76.4Server Class RACI Chart .86.5Server Class Entry Criteria .86.6Server Class Procedures .86.7Server Class Exit Criteria .10Section 7. Storage Class Process and Procedures .117.1Scope .11Page i

Service TransitionService Asset and Configuration Management ProcessUSER GUIDE4.3 02/23/20177.2Storage Class Lifecycle .117.3Storage Class Lifecycle Process.117.4Storage Class RACI .127.5Storage Class Entry Criteria .127.6Storage Class Procedures .127.7Storage Class Exit Criteria .14Section 8. Application Class Process and Procedures .158.1Scope .158.2Definition: Business Service – Application - Software .158.3Application Class Lifecycle .168.4Application Class Lifecycle Process .178.5Application Class RACI .178.6Application Class Entry Criteria .188.7Application Class Procedures .188.8Application Class Exit Criteria .19Section 9. Establishing Relationships in the CMDB .209.1Applications and Server Relationships .20Section 10. SACM CMDB Audit Protocol .2110.1SACM CMDB Audit Purpose .2110.4Background .2110.3SACM CMDB Audit Process .21Section 11. CMDB Structure & Business Service Versus Application .2211.2CMDB Structure Model .22Section 12. Glossary .23Section 13. Revision History .24Section 14. Appendices .2514.1CI Class Owners & Subject Matter Experts .2514.2SACM CMDB FY16 Goal Milestone Schedule .25Page ii

Service TransitionService Asset and Configuration Management ProcessUSER GUIDE4.3 02/23/2017Section 1. Introduction1.1PurposeThe 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 anIT service, including their relationships.This document will define the relationship of SACM to other processes, roles and responsibilitiesof SACM and the process flow.1.2GoalThe goal of the SACM process is to provide an understanding between incidents andconfiguration items.The Configuration Management Database will be the source of truth for configuration items andtheir relationship to other configuration items at UCSF.1.3OverviewThe Service Asset and Configuration Management process ensures the integrity of the ITinfrastructure by the tracking, recording and reporting on configuration items.In order to adequately manage and control these CIs, the SACM process is supported by aConfiguration Management Database (CMDB) capable of holding information on all CIs, includingattributes and relationships between them. SACM enables IT to achieve control andmanagement 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:PlanningProcess Objective: To define the CMDB plan, including purpose, scope, and objectives. DefinesClasses, naming conventions, roles and responsibilities, and interfaces with other systems.IdentificationProcess Objective: To define and maintain the underlying structure of the CMDB (theConfiguration Model), so that it is able to hold all information on CIs. This includes specifying theattributes describing CI types and their sub-components, as well as determining theirinterrelationships.Configuration ControlProcess Objective: To ensure that no CIs are added or modified without the requiredauthorization and those modifications are adequately recorded in the CMDB.Status AccountingProcess Objective: To ensure that CI details are updated as the CI goes through the lifecycle.Page 1

Service TransitionService Asset and Configuration Management ProcessUSER GUIDE4.3 02/23/2017Verification and AuditProcess Objective: To perform regular checks, ensuring that the information contained in theCMDB is an exact representation of the CIs actually installed in the live production environment.1.4Key Relationships with other processesChange ManagementThe Change Management and SACM processes are designed to work together seamlessly inorder for the CMDB to accurately reflect the changes that have taken place. ChangeManagement utilizes the information stored in the CMDB for the assessment and authorization ofrequests for change (RFCs). SACM, by holding information on the relationships between CIs,facilitates this process for Change Management.Incident ManagementThere is a strong relationship between SACM and Incident Management. Incident Managementutilizes information from the CMDB for incident recovery and for informing users on the status ofCIs in the infrastructure. The Service Desk can also assist with the validation of the integrity ofinformation 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 itsactivities; it should be able to rely on the SACM process and the CMDB to provide accurateinformation.Problem ManagementProblem Management procedures must ensure that each time a problem or known error occursand is recorded in the IT Service Management tool, the corresponding process record is linked tothe affected CI in the CMDB.Release ManagementRelease Management is responsible for the management of the introduction of new CIs to the ITinfrastructure. The objective of this process is to ensure and coordinate the production readinessor supportability and distribution of new elements introduced to the IT infrastructure. The processaccomplishes this in close collaboration with Change Management and SACM.1.5DefinitionsConfiguration Management Database (CMDB)CMDB is a logical database containing all relevant information about IT infrastructurecomponents, as well as the relations between those components. Each component is referencedin 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, arouter, a disk array, etc. A CI is defined by four (4) components:Page 2

Service TransitionService Asset and Configuration Management Process USER GUIDE4.3 02/23/2017Status – 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 lifecyclecould 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 moreappropriate 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 atthe same time.Configuration Item ClassAll CIs with the same nature are grouped within classes. All CIs within a CI class have the samebehavior, for example the lifecycle. Some typical CI Classes: Application, Network Gear, Server,Documentation.Configuration Audit ReportA report summarizing the results of a CMDB audit, highlighting revealed differences betweenCMDB records and the actually installed CIs.IT InfrastructureThe sum of an organization’s IT related hardware, software, data communications facilities,procedures, documentation and people.ITILITIL defines the set of all necessary processes and provides best practices for IT Service deliveryand support.Page 3

Service TransitionService Asset and Configuration Management ProcessUSER GUIDE4.3 02/23/2017Section 2. Roles and Responsibilities2.1Process Owner/Configuration Manager 2.2Accountable for the end-to-end processEnsures the success of the processActs as the process advocate to the enterpriseSupports the effective use of the Service Asset and Configuration Management processProvides process design and improvement guidanceLeads the SACM process governance committeeDefines access privilegesConfiguration Item Class OwnerThere are usually only one or two Class Owners for each CI Class.Needs to understand and proficient in their class and recommend improvements for theirrespective classes.Accountable for the following: 2.3Acts as subject matter expert for CI ClassCreates/Modifies/Retires CI ClassCreates/Modifies/Retires CIs within their ClassEnsures the integrity and completeness of the CI ClassEstablishes relationships between CIsConfiguration Item Class AdministratorThere are usually several Class Administrators for each CI class. In practice, the CI Class Administrators may be the Class Owner plus individuals who the CIClass Manager entrusts with the process, and there will be larger number of individuals whomanage 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 becomecontent experts (SMEs) in the SACM/CMDB process and can be called upon, as secondaryresource for Q&A or in Class Owner absence.Also, some CI Class Admins will attend workshops and will also train others i