cómo hacer un ishikawa ti
TRANSCRIPT
![Page 1: Cómo hacer un ishikawa TI](https://reader035.vdocuments.mx/reader035/viewer/2022073103/55cf9828550346d03395ef50/html5/thumbnails/1.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022073103/55cf9828550346d03395ef50/html5/thumbnails/2.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022073103/55cf9828550346d03395ef50/html5/thumbnails/3.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022073103/55cf9828550346d03395ef50/html5/thumbnails/4.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022073103/55cf9828550346d03395ef50/html5/thumbnails/5.jpg)
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.