Known Error Database

CMS

Information Management

The CMS will hold details of all of the component s of the IT Infrastructure as well as the relationship s between these components. It will act as a valuable source for problem diagnosis and for evaluating the impact of problems (e.g. if this disk is down, what data is on that disk; which services use that data; which user s use those services?). As it will also hold details of previous activities, it can also be used as a valuable source of historical data to help identify trends or potential weaknesses – a key part of proactive Problem Management (see Continual Service Improvement publication).

The purpose of a Known Error Database is to allow storage of previous knowledge of incidents and problems – and how they were overcome – to allow quicker diagnosis and resolution if they recur.

The Known Error Record should hold exact details of the fault and the symptoms that occurred, together with precise details of any workaround or resolution action that can be taken to restore the service and/or resolve the problem. An incident count will also be useful to determine the frequency with which incidents are likely to recur and influence priorities, etc.

It should be noted that a Business Case for a permanent resolution for some problems may not exist. For example, if a problem does not cause serious disruption and a workaround exists and/or the cost of resolving the problem far outweighs the benefits of a permanent resolution – then a decision may be taken to tolerate the existence of the problem. However, it will still be desirable to diagnose and implement a workaround as quickly as possible, which is where the KEDB can be of assistance.

It is essential that any data put into the database can be quickly and accurately retrieved. The Problem Manager should be fully trained and familiar with the search methods/algorithms used by the selected database and should carefully ensure that when new record s are added, the relevant search key criteria are correctly included.

Care should be taken to avoid duplication of records (i.e. the same problem described in two or more ways as separate records). To avoid this, the Problem Manager should be the only person able to enter a new record. Other support group s should be allowed, indeed encouraged, to propose new records, but these should be vetted by the Problem Manager before entry to the KEDB. In large organizations where Problem Management staff exist in multiple locations but a single KEDB is used (recommended!), a procedure must be agreed between all Problem Management staff to ensure that such duplication cannot occur. This may involve designating just one staff member as the central KEDB Manager.

The KEDB should be used during the Incident and Problem Diagnosis phases to try to speed up the resolution process – and new records should be added as quickly as possible when a new problem has been identified and diagnosed.

All support staff should be fully trained and conversant with the value that the KEDB can offer and the way it should be used. They should be able readily to retrieve and use data.

Note: Some tools/implementations may choose to delineate Known Error s simply by changing a field in the original Problem Record. This is acceptable provided the same level of functionality is available.

The KEDB, like the CMS, forms part of a larger Service Knowledge Management System (SKMS) illustrated in Figure 4.6. More information on the SKMS can be found in the Service Transition publication.

Figure 4.6 Service Knowledge Management System

Дата добавления: 2014-12-23