So now that you know how accurate your CMDB is, you can calculate the accuracy to several decimal places. Whatever your number turns out to be, you will immediately be challenged by someone to make it better. After all, operations people are never satisfied with less than perfection! The next step is to understand how the errors came to be in your database. This involves a bit of detective work and a lot of understanding of your processes. With some experience, you’ll realize that the type of the error often determines what caused the error. In this section, we look at the various causes and work backward to what types of errors are likely to be seen with these causes. The results are summarized in Figure .
Different classes of error require different handling.
Clerical errors are the most obvious. It is very easy to see most typographical or transposition errors. Clerical errors can also occur whenever a person uses a direct interface to create or update configuration data. This can involve choosing the wrong value from a drop-down list, selecting the wrong radio button, or any other such mistake made on an entry screen. Errors can be introduced any time manual entry is needed, but the error may not actually be introduced in data entry.
Many times we ask technicians to gather configuration information when they are in a data center server room or at a user desktop. Because most technicians don’t carry a laptop or other entry device with them, they pull out a pencil and write down the needed information; or worse yet, try to remember it until they get back to their desk. When they try to re-create the information, they have either lost the paper, can’t read their own handwriting, or have simply forgotten what they tried to remember.
Clerical errors are the most difficult kind of errors to detect, but perversely they are the simplest to correct. These errors are usually subtle, like the transposing of two digits in the serial number of a piece of equipment, or having the wrong location specified. These errors normally cannot be identified through clever queries or searches in the CMDB, but only through careful comparison or spot checks. The best way to prevent clerical errors is to automate more of the process. This can take many different creative forms. You can implement a scanning tool on each piece of equipment so technicians do not have to write down information.
You can even issue hand-held devices so that technicians can electronically scan external characteristics like asset bar codes and device serial numbers. You can implement electronic links from procurement or software licensing systems to create new CIs without having to manually enter them. Any way that you can avoid a person writing down or typing in configuration data will be one less way that clerical errors can be introduced into the database.
It is probably not possible to eliminate all manual activities from the configuration management process. You can also eliminate some clerical errors by increasing the training of your key people who will manually be handling or entering data. Teach people not to try to remember information, give them at least a clipboard and a paper form to capture data accurately, and train them to double-check data as they enter it. It is surprising how even these low-tech safeguards can improve the accuracy of the CMDB.
A second class of errors to be aware of are process errors. These occur typically when some process has failed or hasn’t been followed well. For example, there are organizations that fail to properly link the change management process with the incident management process. The service desk gets a call that a desktop PC won’t power on. An incident is opened and sent to the desk side support queue. A technician goes to the desk and finds that the system board on the computer is bad, so a replace computer is needed.
The correct step would be to branch to the change management (or install / Move/Add/ Change) process at this point and follow that until the appropriate configuration update is made before coming back to incident management to indicate resolution. In organizations that don’t have well-integrated processes, the new PC may be acquired from a storage or redeployment locker without consideration of the configuration database update. The result is an incorrect state for both the broken machine and the machine that has been newly called into service—errors introduced because of a failed process.
The most common process errors are introduced because of unauthorized changes. People who decide that the “needs of the business” supersede the need for a change record will rarely update the CMDB to reflect the environment after they’ve gone ahead with their change. When these changes are made, errors are introduced to the CMDB, and the rest of the IT organization suffers with inaccurate data. There are also cases where people are honestly trying to follow the operational processes, but overlook steps that provide correct configuration data. All these are cases of process errors.
Some process errors can be found through standard operational reporting or special queries designed to look for certain types of errors. Other process errors, such as unauthorized changes, are found through scanning technology or spot audits. The difference is that processes should yield predictable results—you can often use this fact to find errors by finding where the results are not predictable. Several times already we’ve considered a report that shows recently completed changes and whether the CMDB has been updated after the change. This same report can often be used to find process errors.
The primary way to avoid process errors is to create more control points in the processes and to train all of your people to follow the processes. Each control point is another opportunity to have a report that might find whether process errors have been made. Of course, more control points and measurements will also cause more process overhead, driving up the cost and slowing down the process. Use these control points judiciously to minimize your errors, but then relax them as your people are more accustomed to the discipline of configuration management.
The final kind of error we’ll consider is the programming error. Hopefully these will be the rarest form of error in your CMDB, and the easiest to spot. Programming errors potentially could be introduced by your CMDB tool itself or by the underlying database management middleware, but those would be very rare situations. In most cases, programming errors are the result of some integration software that is trying to pull data from other sources into the CMDB or federate data and reflect that data into the CMDB. These integration programs can be written in a variety of ways, and often aren’t built with the full rigor your business applications use. Programming errors can be spotted with reporting. Normally they show up as impossible inconsistencies in the data. For example, you might see all workstations added on a single day as having two gigabytes of memory, when you know your environment is more heterogeneous than that. Keeping an adequate report of what CIs are added or changed by each execution of your integration tools is extremely important to protect against the possibility of programming errors. Programming errors are eliminated through stronger testing of your integration work. If the programs are tested adequately, preferably in a development or testing environment first, there should be very few cases where programming causes errors in the CMDB.
Finding errors that exist, and preventing errors from creeping into the CMDB in the first place, should be a significant investment area for you for the first several years of your configuration management effort. Only after your accuracy is consistently better than 97 percent should you start directing your investments toward higher business value. After all, the value of all other processes and projects depending on configuration data will be diluted if your accuracy is not high enough.
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|
Itil Concepts Tutorial
Overview Of Configuration Management
Gathering And Analyzing Requirements
Determining Scope, Span, And Granularity
Customizing The Configuration Management Process
Planning For Data Population
Putting Together A Useful Project Plan
Choosing The Right Tools
Implementing The Process
Populating The Configuration Management Database
Choosing And Running A Pilot Program
Communication And Enterprise Roll Out
Building A Configuration Management Team
The Many Uses For Configuration Information
Measuring And Improving Cmdb Accuracy
Improving The Business Value Of Configuration Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.