C1 Defining the problem

Because the investigation is based on the definition of the problem, this definition has to state precisely which deviation(s) from the agreed service levels have occurred.

Often, during the definition of a problem, the most likely problem cause is already indicated. Take care not to jump to conclusions, which can guide the investigation in the wrong direction from the beginning.

In practice, problem definition is often a difficult task because of a complicated IT Infrastructure and non-transparent agreements on service levels

C2 Describing the problem

The following aspects are used to describe the problem, i.e. what the problem IS:

• Identity. Which part does not function well? What is the problem?
• Location. Where does the problem occur?
• Time. When did the problem start to occur? How frequently has the problem occurred?
• Size. What is the size of the problem? How many parts are affected?

The ‘IS’ situation is determined by the answers to these questions. The next step is to investigate which similar parts in a similar environment are functioning properly. With this, an answer is formulated to the question ‘What COULD BE but IS NOT?’ (Which parts could be showing the same problem but do not?).

It is then possible to search effectively for relevant differences in both situations. Furthermore, past changes, which could be the cause of these differences, can be identified

C3 Establishing possible causes

The list of differences and changes mentioned above most likely hold the cause of the problem so possible causes can be extracted from this list.

C4 Testing the most probable cause

Each possible cause needs to be assessed to determine whether it could be the cause of all the symptoms of the problem.

Date: 2014-12-29; view: 906