Problem Models It may be useful to use problem models to handle problems that have not and will not

be resolved,
perhaps because the cost or risk is too great or because the technology is due for replacement. These problem
models are similar to the incident models described earlier in our lecturers, identifying the steps to take. They are
used in addition to entries in the known error database.

When Is a Problem Raised? Sometimes it is helpful to raise a problem record while the incident is still open. Each
organization will decide its own criteria for when a problem should be raised. For example, a problem may be raised
when the support teams are sure that the incident has been caused by a new problem, because the incident appears
to be part of a trend or because there is no match with existing known errors. The incident may have been resolved
by the service desk or support teams without knowing the cause and so there is a risk that the fault may reoccur.
This is particularly true in the case of a major incident; the underlying cause needs to be identified as soon as
possible to prevent future disruption to the business. The problem diagnosis activity may take place in parallel with
the incident resolution and may continue after the successful resolution, until the underlying cause is identified and
removed. It is also possible that suppliers may inform their customers of problems that they have identified.

Steps in Problem management

Step 1: Detecting Problems The first step in the process is to identify that a problem exists. As we discussed
previously, problems may be raised either reactively in reaction to incidents or proactively. In addition to the triggers
identified earlier, a problem may also be identified as a result of alerts received as part of event management. The
event monitoring tools may identify a fault before it becomes apparent to users and may automatically raise an
incident in response.

Step 2: Logging Problems Having identified that a problem exists, a problem record should be logged. The problem
record must contain all the relevant information, time-stamped to provide a complete picture. Wherever possible,
the service management tool should be used to link problem records with the associated incident records. Incident
details need to be copied into the problem record. Some tool sets enable the creation of a problem record from an
incident, with automatic linking between the two. This can be very useful and saves a lot of time cutting and pasting
details from one record to another. Should be very careful, however we should remember that the incident has not
“become” a problem; the incident must continue to be managed to resolution whether the problem is resolved or
not. Typical details entered in a problem record and copied from the incident would include details of who reported
it and when, details of the service and equipment used, and a description of the incident and actions taken. The
incident record number and the priority and category would also be required.

Step 3: Categorizing Problems Problem should be categorized in the same way as incidents, and using the same
categorization scheme will make linking incidents and related problems together much easier. An essential
prerequisite for identifying trends in incidents is the accurate and consistent categorization of incidents. If every
service desk analyst logs the same fault differently, it will be impossible to discern a trend. The example of poor
response could be logged as a user complaint, a network issue, an application issue, or even “miscellaneous” or
“other.” The problem manager should emphasize the importance of accurate categorization to the service desk. The
use of incident models can be very helpful here because they standardize the way common incidents are recorded.
Enforcing categorization on incident resolution, as mentioned earlier, will also help ensure incident categories are
accurate and problem management works better.

Step 4: Prioritizing Problems As with incidents, the priority of a problem should be based on the impact to the
business of the incidents that it is causing and the urgency with which it needs to be resolved. The problem manager
should also consider how frequently the incidents are occurring. It is possible that a frozen screen that can be
resolved with a reboot is not a high-priority incident if it is occurring 100 times a day, the combined impact to the
business may be severe, so the problem needs to be allocated a high priority. The impact to the business must
always be considered, so factors such as the cost of resolving the incident, and the time this is likely to take, will be
relevant when assessing priority.
Step 5: Investigating and Diagnosing Problems The next stage in the process is to investigate and diagnose the
problem. There may not be the resources to investigate every problem, so the priority level assigned to each will
govern which ones get the necessary attention. It is important to allocate resources to problem investigation,
because until the problem is resolved, the incident will recur, and resources will be spent on incident resolution.

The ITIL framework suggests a number of different problem-solving techniques, which are helpful in approaching the
diagnosis logically. The CMS can be very helpful in providing CI information to help identify the underlying cause. It
will also help in identifying the point of failure, where several incidents are reported; the CMS may identify that all
the affected CIs are linked to the same CI. The KEDB may also provide information about previous, similar problems
and their causes. Where a test environment exists, this can be used to re-create the fault and to try possible
solutions.

Step 6: Identifying a Workaround Although the aim of problem management is to find and remove the underlying
cause of incidents, this may take some time; meanwhile, the incident or incidents continue, and the service is
affected. When a user suffers an incident, the first priority is to restore the service so that they can continue
working. A priority of the process, therefore, is to provide a workaround to be used until the problem is resolved.
The workaround does not fix the underlying problem, but it allows the user to continue working by providing an
alternative means of achieving the same result. The workaround can be provided to the service desk to enable them
to resolve the incidents, while work on a permanent solution continues. The problem record remains open, because
the fault still exists and is continuing to cause incidents. The details of the workaround are documented within the
problem record, and a reassessment of its priority may be carried out. It is possible that IT or business management
may decide to continue to use the workaround and suspend work on a permanent solution if one is not justified. A
problem affecting a service that is due to be replaced, for example, may not be worth the effort and risk involved in
implementing a permanent solution. In the previous example regarding the car that fails to start, the owner may
decide not to repair the fault if the car is to be replaced within weeks. Until it is replaced, the owner uses the
workaround of jumper cables, rather than pay the mechanic to fi x the fault.

Step 7: Raising a Known Error Record When problem management has identified and documented the root cause
and workaround, this information is made available to support staff as a known error. Information about all known
errors, including which problem record it relates to, is kept in the known error database (KEDB). When repeat
incidents occur, the support staff can refer to the KEDB for the workaround. There may be times when a workaround
is available although the root cause is not yet known for example, a reboot restores the service, although we do not
know what causes the error. On other occasions, we may know the cause but not have a workaround because a
change has to be implemented to fix the fault.

Sometimes a known error is raised before a workaround is available and sometimes even before the root cause has
been fully identified. This may be just for information purposes; a workaround may be available that has not been
fully proven. Rather than have a rigid rule about when a known error should be raised, a more pragmatic approach is
advisable; a known error should be raised as soon as it becomes useful to do so.