cómo hacer un ishikawa ti

6
How do I relate what IT does to the objective of the organisation? – Macanta answers back.02/01/10 An IT Service Manager within an emergency services organisation once asked me the following question: “Our primary objective is to save lives and as a Service Manager within the organisation what I do appears to be far removed from this. How do I, or can I relate my performance measures to this objective?” This is a common problem. How to relate what I do to the objective of the organisation? Ideally the organisations mission and objective should be set first and cascaded down through the organisation. Each objective set for each division, department, team and person within the organisation should relate back to the overall objective and be visible to every person within the organisation. In this way, everyone can see how their performance relates to the objective of the organisation and can be measured against it. However, more often than not, this does not happen and individuals and teams set their own objectives in order to be able to measure performance but they do not relate to the organisational objective, as this has not been communicated effectively. It is then difficult for individuals to understand their contribution to the overall objective of the organisation. As a Service Management consultant I often hear IT staff stating that their role is, for example, “to fix the network”. I then ask why and the reply is “because it is broken” and then I ask why again and the response is “because the Service Desk sent me an Incident”……and so on and so on. The questioning can continue for a long while before we get to the point where the individual states that they are fixing the network because there is customer who wants to buy a tin of beans from their local

Upload: cavero

Post on 29-Dec-2015

8 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Cómo hacer un ishikawa TI

How do I relate what IT does to the objective of the organisation? – Macanta answers

back.02/01/10

An IT Service Manager within an emergency services organisation once asked me the following

question:

“Our primary objective is to save lives and as a Service Manager within the organisation what I do

appears to be far removed from this.

How do I, or can I relate my performance measures to this objective?”

This is a common problem. How to relate what I do to the objective of the organisation?

Ideally the organisations mission and objective should be set first and cascaded down through the

organisation. Each objective set for each division, department, team and person within the

organisation should relate back to the overall objective and be visible to every person within the

organisation. In this way, everyone can see how their performance relates to the objective of the

organisation and can be measured against it.

However, more often than not, this does not happen and individuals and teams set their own

objectives in order to be able to measure performance but they do not relate to the organisational

objective, as this has not been communicated effectively. It is then difficult for individuals to

understand their contribution to the overall objective of the organisation.

As a Service Management consultant I often hear IT staff stating that their role is, for example, “to

fix the network”. I then ask why and the reply is “because it is broken” and then I ask why again and

the response is “because the Service Desk sent me an Incident”……and so on and so on.  The

questioning can continue for a long while before we get to the point where the individual states that

they are fixing the network because there is customer who wants to buy a tin of beans from their

local supermarket! They understand that the organisation is in the food retail business, but they

don’t relate their role to the overall organisational objective.

So, how can we overcome this? How can we relate our role in the organisation to the overall

objective?

Page 2: Cómo hacer un ishikawa TI

One method I have used is to utilise some of the techniques used within Problem Management. I

have done this with various IT teams to help them understand their role and it has the impact of

them understanding their importance and the vital role they have to play. It also helps staff

understand the consequences of not doing a good job and the impacts that it can have.

One such technique is Cause and Effect Analysis.

A Cause-and-Effect Diagram (also known as a “Fishbone Diagram”) is a graphical technique for

grouping people’s ideas about the causes of a problem.

The cause & effect diagram is the brainchild of Kaoru Ishikawa, who pioneered quality management

processes in the Kawasaki ship-yards and in the process, became one of the founding fathers of

modern management.

In the question it is stated that the objective of the organisation is to save lives. So find an instance

where the objective failed and use the Cause and Effect diagram to determine the causes of the

problem.

Using a Cause-and-Effect Diagram forces the team to consider the complexity of the problem and

to take an objective look at all the contributing factors. It helps the team to determine both the

primary and the secondary causes of a problem and is helpful for organising the ideas generated

from a brainstorming session.

It is used after the causes have been grouped by relationships (for example, by using a Causal

Table).

A Causal Table, also known as the Why-Because Technique, allows the team to analyse the root

cause(s) of a problem. As well as being an important step in constructing a Cause-and Effect

diagram. It can also be used on its own to help analyse a problem.

Create a table (see example below):

Why? Because?

Conduct two brainstorming sessions with the team to find out the team’s ideas about the causes of

a problem:

The first time, the team brainstorms the evident or immediate causes of the problem (the why). List

these under “Why” in the chart.

Page 3: Cómo hacer un ishikawa TI

The second time, the team analyses each immediate cause by considering the question “Why is

this a Problem? Because….” Write in the answers under “Because” in the table. This step will help

the team determine the root causes. End the analysis when you reach causes over which you have

no control.

Example:

Why? Because?

Why did the patient

die?

Because they were allergic to the drugs

administered

Why didn’t the

doctor know they

were allergic?

Because the doctor did not have access to the

patients records

Why didn’t they

have access to the

records?

Because service 302 exceeded its capacity

threshold

Why did server 302

exceed its capacity

threshold?

Because the workload has increased

Why did the

workload increase?

Because the media department was moved to

East Building and they now connect to server 302

which placed additional workload on server 302

Why was server 302

capacity not

considered as part

of the move?

Because physical moves are not a part of the

Change Management process

In the above example, the root cause was due to the lack of procedure to check the capacity

requirements when departments are relocated. If additional capacity is added to server 302, this will

not stop this type of problem from recurring as it is the process that is at the root cause.

Now, illustrate graphically the causes grouped by relationships by using the Cause-and-Effect

Diagram where:

The problem under investigation is described in a box at the head of the diagram.

Page 4: Cómo hacer un ishikawa TI

A long spine with an arrow pointing towards the head forms the backbone of the “fish.” The

direction of the arrow indicates that the items that feed into the spine might cause the

problem described in the head.

A few large bones feed into the spine. These large bones represent the main categories of

potential causes of the problem. Again, the arrows represent the direction of the action; the

items on the larger bones are thought to cause the problem in the head.

The categories you use are up to you to decide. In an IT environment a suggestion is:

Processes / procedures

Technology

Organisation / Environment

People

The smaller bones represent deeper causes of the larger bones they are attached to. Each bone is

a link in a Cause-and-Effect chain that leads from the deepest causes to the targeted problem.  The

following diagram is a fishbone template.

The following is an example of a completed template.

Page 5: Cómo hacer un ishikawa TI

Once the fishbone is complete, you are well on your way to understanding the root causes of the

problem.

It can then be seen what the contribution of IT was to that problem – the technology, the people, the

processes and the organisation. In this way, staff can see how they contributed to the failure of the

organisations objective and how they can resolve the situation to ensure that they now contribute to

the achievement of the organisations objective.