Common Process Customizations - ITIL Concepts

As we’ve seen, there really is no “out-of-the-box” ITIL process. Everyone must build a process, and the library offers advice on what areas the process should cover. But building the process can be confusing because configuration management represents a new way of thinking for many people and because the configuration management discipline intersects with so many other process areas. The following paragraphs describe some of the facets of the process and the most common procedures that need to be considered and documented.

Top Down Process

Good process engineers normally work from the top level of detail down to the bottom. They start with a single flow that describes the entire set of process steps, albeit at a very high level. Then each nontrivial step is defined in a more detailed flow, which may also include steps that are still too high level to be practical. The exercise continues until each process step at the lowest level can be accomplished by a single person in a reasonable amount of time. If your organization is just beginning to explore and deploy configuration management, it might make more sense for your high-level process to combine control and status tracking into one top-level process.

Planning Procedures

For planning set of procedures, many lower level procedures must be defined for an organization. Defining the schema may seem like a onetime event, but we need to document changes relating to the schema. We should also document the naming conventions and other data standards because data consistency greatly enhances accuracy. We should also document how CI’s will be uniquely identified. It also makes sense to include a general change control mechanism for changing policies, standards, and procedures in the future. The following list indicates some of the procedures you should document as part of this first process area:

Potential Procedures to Document for Planning

  • Manage configuration management plan changes
  • Naming standard for configuration items
  • Standard values for key attributes

Procedures for CI Identification

It is important for an organization to define how data will be collected, and especially how disparate sources will be reconciled. One of the important task in configuration management is to marry the correct demographic data, such as user name, location, organizational ownership, and asset tag number, with the technical data, such as CPU speed, installed software, and network address.

The most challenging procedures in configuration identification is to discover and document the relationship between CI’s. Our procedures should document who is responsible for discovery of each type of relationship, and how those relationships will be captured and maintained.

Potential Procedures for Identification of Configuration Items

  • Identifying computer workstations
  • Importing data from a scanning tool
  • Preparing for and conducting a wall-to-wall inventory at a site
  • Conducting a data center inventory
  • Registering application CIs as part of the development cycle
  • Creating a policy for registering documents as configuration items
  • Establishing relationships in the workstation space
  • Establishing relationships in the data center space
  • Establishing relationships in the network space

Procedures for Control of CIs

Majority of your process customizations will occur are of controlling CIs. But you will quickly discover that control is a matter of considering every exception. Most organizations begin with the notion that every CMDB update must happen as a result of an enterprise change record. Unfortunately, there is some level of change, either explicitly documented or tacitly understood, that your organization doesn’t choose to capture in a request for change. The control procedures will be the most volatile set for most beginning configuration management programs.

Potential Control Procedures

  • Integration of configuration management with change control
  • Administrative updates to the CMDB
  • CMDB usage in a compliance audit
  • Standards of access to CMDB data
  • Discovery of unregistered configuration items
  • Handling registration errors in configuration data

Status Tracking Procedures

Status reports should be produced on a regular basis, listing, for all CIs under control, their current version and change history. Status accounting reports on the current, previous and planned states of the CIs should include:

  1. unique identifiers of constituent CIs and their current status, e.g. 'under development', 'under test', 'live'
  2. configuration baselines, Releases and their status
  3. latest software item versions and their status for a system baseline/application
  4. the person responsible for status change, e.g. from 'under test' to 'live'
  5. Change history/audit trail
  6. open problems/RFCs.

Status accounting reports can be used to establish system baselines and enable Changes between baselines and Releases to be traceable. Status reports may include:

  1. baseline and release identifiers
  2. latest software item versions for a system build/application
  3. the number of Changes for a system
  4. the number of baselines and releases
  5. the usage and volatility of CIs
  6. comparisons of baselines and releases.

Potential Procedures to Track CI Status

  • Definition of CI lifecycle
  • Procedure for managing relationships at each lifecycle change
  • Managing versions of a CI
  • Recording and using CI history

Audit Procedures

Before a major release or Change, an audit of a specific configuration may be required to ensure that the customer’s environment matches the CMDB. Before acceptance into the live environment, new releases, builds, equipment and standards should be verified against the contracted or specified requirements. There should be a test certificate that proves that the functional requirements of a new or updated CI have been verified, or some other relevant document (i.e. RFC).

Physical configuration audits should be carried out to verify that the 'as-built' configuration of a CI conforms to its 'as-planned' configuration and its associated documents. Interrogation facilities are required to check that the CMDB and the physical state of CIs are consistent.

Plans should be made for regular configuration audits to check that the CMDB is consistent with the physical state of all CIs, and vice versa. These audits should verify that correct and authorized versions of CIs exist, and that only such CIs exist, and are in use in the operational environment. From the outset, any ad-hoc tools, test equipment, personal computers and other 'non-registered' items should either be removed or registered through formal configuration management. Non-registered and unauthorized items that somehow make an appearance during configuration audits should be investigated, and corrective action should be taken to address possible issues with procedures and the behavior of personnel. All exceptions should be logged and reported. The configuration audits should check in addition that change and release records have been properly authorized by change management and that implemented Changes are as authorized. Configuration audits should be considered at the following times:

  1. shortly after implementation of a new Configuration Management system
  2. before and after major Changes to the IT infrastructure
  3. before a software release or installation to ensure that the environment is as expected
  4. following recovery from disasters and after a 'return to normal' (this audit should be included in contingency plans)
  5. at random intervals
  6. in response to the detection of any unauthorized CIs
  7. at regular intervals.

Automated audit tools enable regular checks to be made at regular intervals, e.g. weekly. For example, desktop audit tools compare the build of an individual's desktop to the master build that was installed. If exceptions are found, some organizations return the build to its original state.A rolling programme of configuration audits can help utilize resources more effectively. The service desk and support groups should be instructed to check that CIs brought to their attention, e.g. the software that a caller is using, are as recorded in the CMDB. Any deviations should be reported to Configuration Management for investigation. If there is a high incidence of unauthorized CIs detected, the frequency of configuration audits should be increased, certainly for those parts of the IT infrastructure affected by this problem. Note that unauthorized installations are discouraged when the Configuration Management team is seen to be in control and to carry out regular and frequent audits. If an epidemic of unauthorized CIs is detected, selective or general configuration audits should be initiated to determine the scale of the problem, to put matters right, and to discourage a proliferation of unauthorized CIs. Publicity will help to reduce further occurrences.

Potential Procedures for Auditing the CMDB

  • Frequency of CMDB audits
  • How to select an auditable sample
  • Criteria to be used to determine sample accuracy
  • Handling discrepancies discovered in audits
  • Reporting on audit outcomes
  • Return audits and handling of repeated failures

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

ITIL Concepts Topics