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.
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
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
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
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:
Status accounting reports can be used to establish system baselines and enable Changes between baselines and Releases to be traceable. Status reports may include:
Potential Procedures to Track CI Status
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:
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
ITIL Concepts Related Interview Questions
|ITIL Configuration Management Interview Questions||Project Management Interview Questions|
|Change Management Interview Questions||ITIL Concepts Interview Questions|
|Strategic Planning for Project Management Interview Questions||PRINCE Interview Questions|
|Project Manager Interview Questions||Project Coordinator Interview Questions|
|ITIL Service Transition Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.