Checklist CMS CMDB: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
<seo metakeywords="itil cms, cms itil | <seo metakeywords="itil cms, cms itil cmdb, itil cms cmdb, itil configuration management system, ci record, configuration item, itil ci" metadescription="Template CMS/ CMDB Configuration Management System/ Configuration Management Database. The CMS is a coherent logical model of the IT organization’s ..." /> | ||
<imagemap> | <imagemap> | ||
Image:ITIL-Wiki-de-es.jpg|DE - ES - Checklist CMS CMDB - Template CMS CMDB - Configuration Management System (CMS)/ Configuration Management Database (CMDB)|100px | Image:ITIL-Wiki-de-es.jpg|DE - ES - Checklist CMS CMDB - Template CMS CMDB - Configuration Management System (CMS)/ Configuration Management Database (CMDB)|100px | ||
Line 7: | Line 7: | ||
</imagemap> | </imagemap> | ||
<br style="clear:both;"/> | <br style="clear:both;"/> | ||
== <span id="CMS ITIL CMDB">Overview</span> == | |||
'''ITIL Process''': [[ITIL V3 Service Transition|ITIL 2011 Service Transition]] - [[Service Asset and Configuration Management]] | '''ITIL Process''': [[ITIL V3 Service Transition|ITIL 2011 Service Transition]] - [[Service Asset and Configuration Management]] | ||
Line 16: | Line 18: | ||
<p> </p> | <p> </p> | ||
The ''Configuration Management System (CMS)'' is set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships | The ''Configuration Management System (CMS)'' is a set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships. A CMS may manage more than one physical ''Configuration Management Databases (CMDB)''. Its underlying structure is defined by the ''[[Checklist CMS CMDB#Configuration Model and CI Types|Configuration Model]]'', a logical model of the IT organization’s service assets. | ||
The CMS is used to store information on all ''[[Checklist CMS CMDB#Configuration Item Records - CI Records|Configuration Items (CIs)]]'' under the control of [[Service Asset and Configuration Management|Configuration Management]]. | |||
CIs can be of [[Checklist CMS CMDB#CI types and sub-types|various types]]: the CMS almost always covers services and IT infrastructure, but might also cover other item types like policies, project documentation, employees, suppliers, etc. | |||
<p> </p> | |||
__TOC__ | |||
== Configuration Model and CI Types == | |||
The structure of the CMS is defined by the ''Configuration Model'', which specifies the types of CIs managed through the CMS, including their attributes and relationships. The Configuration Model is often maintained as a (set of) documents or data models. It also manifests itself, for example, in the table structure of the databases used to store configuration information. | |||
''The Configuration Model typically defines the following structural aspects of the CMS:'' | |||
<p> </p> | |||
===== CI types and sub-types ===== | |||
CI types and sub-types managed in the CMS, usually in the form of a tree structure as in the following example: | |||
# Main types (e.g. Service, Hardware, Software, Document, Staff ...) | |||
# Sub-types (e.g. Server, Printer, ... - refinement of the main type into sub-types) | |||
# … further sub-types as appropriate | |||
===== Attributes ===== | |||
(Attributes to be managed for each CI type) | |||
===== Status values ===== | |||
(allowed status values describing the lifecycle of the CI types) | |||
===== Relationships between CI types ===== | |||
E.g. | |||
# "Is a component of" | |||
# "Is associated with" | |||
# "Uses" | |||
# "Is a new version of" | |||
# "Will be replaced by", … | |||
===== Authorities and controls ===== | |||
# CI type owner | |||
# Authorities for creating, authorizing, modifying or deleting the CIs of this type, as appropriate, normally assigned as access rights in the CMS and relevant sub-systems | |||
# Applicable controls, guidelines and policies (e.g. mechanisms to ensure that only authorized personnel is able to apply changes to the CIs and modify the related CI records in the CMS, or controls/ procedures to ensure the configuration data remain consistent when CIs are added or removed) | |||
# Applicable guidelines and policies | |||
# Reporting, auditing and verification requirements | |||
<p> </p> | |||
== Configuration Item Records - CI Records == | |||
The | The details of actual CIs ("instances of CI types") are stored in CI Records. The exact set of attributes to be maintained for a CI will vary depending on the CI type at hand, as specified in the Configuration Model. | ||
''CI Records typically contain the following information:'' | |||
<p> </p> | <p> </p> | ||
===== Identifier ===== | |||
(Unique identifier - ID) | |||
===== Name ===== | |||
===== Description ===== | |||
===== CI owner ===== | |||
(CI owner/ person in charge) | |||
===== CI type ===== | |||
===== Manufacturer information ===== | |||
# Manufacturer name | |||
# Serial number | |||
# License number/ reference to license contract | |||
===== Version information ===== | |||
===== Location ===== | |||
# Physical location, if applicable | |||
# Logical location, if applicable (e.g. URL or directory on a fileserver) | |||
===== Modification history of the CI Record ===== | |||
# Date of CI Record creation | |||
# Modifications | |||
## Date | |||
## Person in charge | |||
## Description of modification | |||
===== Status history ===== | |||
(description of the life cycle of a CI with status values, as for example "Undergoing Test", ..., "Active", ..., "Undergoing Maintenance", ..., "Out of Operation", ...) | |||
# Present status and version | |||
# Status and version history (historical Changes to the status of the CI or Changes planned for the future) | |||
## Status change | |||
## Description | |||
## Time and date of the Change in status | |||
===== Relationships to other CIs ===== | |||
E.g. | |||
# "Is a component of" | |||
# "Is associated with" | |||
# "Uses" | |||
# "Is a new version of" | |||
# "Will be replaced by", … | |||
# ... including relationships to services supported by the CI. | |||
===== Licensing information ===== | |||
===== Document references ===== | |||
# Contractual documentation | |||
# Operating documentation | |||
# User documentation | |||
# Emergency-relevant documentation | |||
# Other documentation | |||
<p> </p> | <p> </p> | ||
== References to Configuration Items (CIs) - Note == | |||
CIs are typically referenced from other service management systems. | |||
In an Incident Management system, for example, an Incident Record will contain a reference to one or more affected CIs. So these relationships are recorded in [[Checklist Incident Record|Incident Records]] rather than the CI records. | |||
<p> </p> | <p> </p> |
Revision as of 13:54, 2 May 2012
<seo metakeywords="itil cms, cms itil cmdb, itil cms cmdb, itil configuration management system, ci record, configuration item, itil ci" metadescription="Template CMS/ CMDB Configuration Management System/ Configuration Management Database. The CMS is a coherent logical model of the IT organization’s ..." />
![DE - ES - Checklist CMS CMDB - Template CMS CMDB - Configuration Management System (CMS)/ Configuration Management Database (CMDB)](/images/thumb/6/6d/ITIL-Wiki-de-es.jpg/100px-ITIL-Wiki-de-es.jpg)
Overview
ITIL Process: ITIL 2011 Service Transition - Service Asset and Configuration Management
Checklist Category: Checklists ITIL Service Transition
Source: Checklist "Configuration Management System (CMS)/ Configuration Management Database (CMDB)" from the ITIL Process Map
The Configuration Management System (CMS) is a set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships. A CMS may manage more than one physical Configuration Management Databases (CMDB). Its underlying structure is defined by the Configuration Model, a logical model of the IT organization’s service assets.
The CMS is used to store information on all Configuration Items (CIs) under the control of Configuration Management.
CIs can be of various types: the CMS almost always covers services and IT infrastructure, but might also cover other item types like policies, project documentation, employees, suppliers, etc.
Configuration Model and CI Types
The structure of the CMS is defined by the Configuration Model, which specifies the types of CIs managed through the CMS, including their attributes and relationships. The Configuration Model is often maintained as a (set of) documents or data models. It also manifests itself, for example, in the table structure of the databases used to store configuration information.
The Configuration Model typically defines the following structural aspects of the CMS:
CI types and sub-types
CI types and sub-types managed in the CMS, usually in the form of a tree structure as in the following example:
- Main types (e.g. Service, Hardware, Software, Document, Staff ...)
- Sub-types (e.g. Server, Printer, ... - refinement of the main type into sub-types)
- … further sub-types as appropriate
Attributes
(Attributes to be managed for each CI type)
Status values
(allowed status values describing the lifecycle of the CI types)
Relationships between CI types
E.g.
- "Is a component of"
- "Is associated with"
- "Uses"
- "Is a new version of"
- "Will be replaced by", …
Authorities and controls
- CI type owner
- Authorities for creating, authorizing, modifying or deleting the CIs of this type, as appropriate, normally assigned as access rights in the CMS and relevant sub-systems
- Applicable controls, guidelines and policies (e.g. mechanisms to ensure that only authorized personnel is able to apply changes to the CIs and modify the related CI records in the CMS, or controls/ procedures to ensure the configuration data remain consistent when CIs are added or removed)
- Applicable guidelines and policies
- Reporting, auditing and verification requirements
Configuration Item Records - CI Records
The details of actual CIs ("instances of CI types") are stored in CI Records. The exact set of attributes to be maintained for a CI will vary depending on the CI type at hand, as specified in the Configuration Model.
CI Records typically contain the following information:
Identifier
(Unique identifier - ID)
Name
Description
CI owner
(CI owner/ person in charge)
CI type
Manufacturer information
- Manufacturer name
- Serial number
- License number/ reference to license contract
Version information
Location
- Physical location, if applicable
- Logical location, if applicable (e.g. URL or directory on a fileserver)
Modification history of the CI Record
- Date of CI Record creation
- Modifications
- Date
- Person in charge
- Description of modification
Status history
(description of the life cycle of a CI with status values, as for example "Undergoing Test", ..., "Active", ..., "Undergoing Maintenance", ..., "Out of Operation", ...)
- Present status and version
- Status and version history (historical Changes to the status of the CI or Changes planned for the future)
- Status change
- Description
- Time and date of the Change in status
Relationships to other CIs
E.g.
- "Is a component of"
- "Is associated with"
- "Uses"
- "Is a new version of"
- "Will be replaced by", …
- ... including relationships to services supported by the CI.
Licensing information
Document references
- Contractual documentation
- Operating documentation
- User documentation
- Emergency-relevant documentation
- Other documentation
References to Configuration Items (CIs) - Note
CIs are typically referenced from other service management systems.
In an Incident Management system, for example, an Incident Record will contain a reference to one or more affected CIs. So these relationships are recorded in Incident Records rather than the CI records.