Understanding Configuration Management System (CMS) and Configuration Management Database (CMDB) – Part 3

Supplier Management is the ITIL V3 process responsible for defining and maintaining the Supplier and Contracts Database (SCD), which is a database or structured Document used to manage supplier contracts throughout their lifecycle. The SCD contains key attributes of all contracts with suppliers, and should be part of the Configuration Management System (CMS), which is a subset of the overall Service Knowledge Management System (SKMS).

As mentioned in my previous post, a CMDB is a database within a CMS. At the data level, the Configuration Management System (CMS) may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries (DML).

Ideally, a SCD (Supplier and Contracts Database) which stores information on supplier and contracts used in service management is also a database within the CMS. Relationship information between a Service to Suppliers of outsourced or externally supported components that supports that specific Service should be defined and captured in the CMS. In addition, the relationships between the Service, any Service Level Agreements (SLAs) and Underpinning Contracts (UCs) linked to that Service ought to be captured as well. These information forms part of the Logical Configuration Model of that Service. Using this Logical Configuration Model, any Service Management staff can easily trace the components used to support the Service, related SLAs and contracts and also finds information about the related suppliers.

Be careful of the inconsistency in the naming of the terms. A “gotcha” if you are taking the ITIL examinations. There is no “Supplier Management Information System” or SMIS, unlike the new ITIL V3 terms Availability Management Information System (AMIS) or Capacity Management Information System (CMIS) which are information systems used to support Availability Management and Capacity Management respectively. The information system to support Supplier Management is simply called SCD (like the old ITIL V2 Availability Database or ADB and Capacity Database or CDB). By the way, there is a SMIS in ITIL V3 but it stands for Security Management Information System.

Read more...

Understanding Configuration Management System (CMS) and Configuration Management Database (CMDB) – Part 2

Is the Service Portfolio and Service Catalogue part of the Configuration Management System (CMS) in ITIL V3? Yes.

We can and should define a “Service” as a configuration item (CI) and build a logical configuration model  for the Service, i.e. linking the “Service” CI to the other components or CIs that supports the Service. Such logical configuration models are useful when handling incidents, solving problems, assessing impact of changes or developing a cost model for a service.

Services are described using specification sheets (Service Specifications) and forms part of the Service Catalogue and Service Portfolio. Hence, the Service Specifications, Service Catalogue and Service Portfolio should be registered as controlled documents, subject to the Change Management process, and hence defined as CIs within the Configuration Management System (CMS).

In actual implementation, the Service Catalogue may take the form of a matrix, table or spreadsheet. Some may even document their services in an intranet and present it in the form of web pages, with drill down capability to show greater details as required. The Service Catalogue can be viewed as a "database”, which forms part of a federated CMDB, containing detailed information and attributes of the Services and has linkages or relationships with other physical CMDBs within the CMS.

Read more...

Announcement on ITIL V2 withdrawal

ITIL has formally announced the dates for the withdrawal of ITIL V2 certification. More details can be found in the link below:

http://www.exin-exams.com/content/news/ogc-announces-timeline-for-withdrawal-of-itil-v2.aspx

For those hoping to pursue the ITIL Expert certification via the V2 Manager route, note that the V2 Manager certification examinations will be withdrawn on 31 August 2010 and the V2 to V3 Manager Bridge will be withdrawn on 30 June 2011.

All of the above will be available for re-sits until 30 June 2011.

Do sign up for the next ITIL V2 Manager and V2 to V3 Bridge courses before it is too late.

Read more...

Understanding Configuration Management System (CMS) and Configuration Management Database (CMDB) – Part 1

In ITIL V2, the CMDB is described as a database that contains the relationships between all the system components, including Incidents, Problems, Known Errors, Changes and Releases. The CMDB also contains information about Incidents, Problems, Known Errors, corporate data about employees, suppliers, locations and business units. It also goes on to say that the CMDB is often used to store details of Services and relate them to the underlying components and may also be used to store contracts and licences.

ITIL V2 seems to imply that a configuration management system is a set of tools used to support the Configuration Management activities.

In ITIL V3, the definition of CMS and CMDB is slightly changed from that of ITIIL V2. According to the ITIL V3 Glossary:

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.

CMDB = A database used to store Configuration Records
throughout their Lifecycle. The Configuration Management System
maintains one or more CMDBs, and each CMDB stores Attributes of Configuration Items (CIs), and Relationships with other CIs.

In other words, a CMDB is a database within a CMS. At the data level, the CMS may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries (DML). A SCD (Supplier and Contracts Database) which stores information on supplier and contracts used in service management is also a database within the CMS and can be considered a CMDB.  A service catalogue is just a form of CMDB.

According to the ITIL V3 books, the CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and business units, customers and users.

Relationships are the mechanism for associating RFCs, incident records, problem records, known errors and release records with the services and IT infrastructure CIs to which they refer. All these relationships should be included in the CMS. Request for Change (RFC) and change and release records will identify the CIs affected.

What about the actual incident, problem, change and release records? Are the actual records stored in or forms part of the CMS? According to the ITIL Glossary, the CMS contains “information about” incident, problems, Known Errors and Releases. 

I think actual incident, problem, change and release records should be considered as part of the CMS although the ITIL V3 Service Operation book does not explicitly mention about storing incident records in the CMS. However, it mentions that Problem Management uses the CMS to identify faulty CIs and also to determine the impact of problems and resolutions. The CMS can also be used to form the basis for the KEDB and hold or integrate with the Problem Records. This means CMS may or may not store Problem and Known Error records, but the relationships information should be captured in the CMS.

The ITIL V3 Service Transition book does explicitly mention that the change and release records are stored within the CMS.

• As an RFC proceeds through its lifecycle, the change document, related records (such as work orders) and related configuration items are updated in the CMS, so that there is visibility of its status. Estimates and actual resources, costs and outcome (success or failure) are recorded to enable management reporting.
• Release information is recorded within the CMS, supporting the release and deployment process.

In real-life implementations, off-the-shelf tools from vendors like HP (HP Service Center) and BMC (Remedy) provides an integrated toolset that contain integrated modules to support the Incident, Problem, Change and Configuration Management processes. It contains all incident, problem and known errors records with relationships and linkages to the services and CI details stored in a database.

Read more...