Professional Documents
Culture Documents
Prinsip Prinsip Metode Analisis Akar Masalah
Prinsip Prinsip Metode Analisis Akar Masalah
Setiap masalah selalu mempunyai akar masalah. Akar masalah sangat penting
diketahui untuk melakukan tindakan perbaikan dan pencegahan secara efektif. Untuk
mengukur efektifitas tindakan perbaikan, tips berikut ini mungkin dapat dipakai
sebagai acuan untuk menetapkan kriteria efektif:
bisa diterapkan
mudah dievaluasi
dll
Jika saat ini efektif, mungkinkah bulan depan atau tahun depan bisa muncul kembali
masalah yang sama? sangat mungkin, karena faktor variasi akan muncul secara alami
dari faktor man, material, method, and machine.
A process improvement and error or defect prevention tool that examines the
individual processes within a system, identifies the control or decision points, and
uses a series of why? questions to determine the reasons for variations in the process
paths.
Example sentence(s):
On receipt of initial notification, the department will provide the hospital with
a sentinel event reference number to be indicated on the root cause analysis,
risk reduction action plan summary and other correspondence about the
episode. Victorian State Government - Health
Root cause analysis (RCA) is a methodology for finding and correcting the
most important reasons for performance problems. It differs from
troubleshooting and problem-solving in that these disciplines typically seek
solutions to specific difficulties, whereas RCA is directed at underlying issues.
bill-wilson.net
Root cause analysis (RCA) is a methodology for finding and correcting the most
important reasons for performance problems. It differs from troubleshooting and
problem-solving in that these disciplines typically seek solutions to specific
difficulties, whereas RCA is directed at underlying issues.
In safety and risk management, it looks for both unrecognized hazards and
broken or missing barriers.
It helps target CAPA (corrective action and preventive action) efforts at the
points of most leverage.
Finally, it is probably the only way to find the core issues contributing to your
toughest problems.
Teknik analisis yang bertahap dan terfokus untuk menemukan akar masalah suatu
problem, dan bukan hanya melihat gejala-gejala dari suatu masalah.
Example sentence(s):
- Institut Manajemen
Institut Manajeme
http://pusdiknakes
Resiko Klinis
Metode Analisis Akar Masalah dan Solusi (MAAMS) ini menyajikan suatu
cara berpikir yang diperagakan dengan tata-alir (flow chart), disertai dengan
beberapa contoh. Penerapan MAAMS membantu penggunanya untuk berpikir
induktif maupun deduktif, kualitatif maupun kuantitatif, lebih mendalam dan
menyeluruh, serta mempermudah kerjasama inter, multi, atau transdisiplin.
- Jurnal Universitas Indonesia
Jurnal Universitas http://journal.ui.ac
Untuk masalah sosial dan humaniora bisa digunakan metode analisis akar
masalah dan solusinya (MAAMS), yang mencari sebab-dari-sebab sekaligus
berpikir out of the box. Pengalaman mempraktikkan MAAMS di kelas ilmu
sosial dasar sejak pertengahan 1990-an menunjukkan mahasiswa mampu
memahami secara metodis bahwa banyak masalah sosial berakar pada
korupsi (harta, takhta, cinta asmara, dan gabungannya) dan mengajukan
solusi dasarnya. Maraknya korupsi pada bangsa ini merupakan indikasi
banyaknya keterbelahan kepribadian.
http://pojokantikor
- LP Universitas Hasanuddin
http://w w w .unha
http://w w w .aske
Mercu Buana
http://74.125.153.
Mercu Buana
Explanation:
Padanan pada Kateglo juga analisis akar penyebab.
Cukup? Cobalah tanya lagi KENAPA tangki oli bocor. Jawabannya adalah karena
tangki ini tidak ada pemeriksaan berkala untuk kebocoran. Tindakan kita adalah
masukkan poin pemeriksaan kebocoran tangki di jadwal pemeliharaan kita.
Cukup? Coba tanyakan lagi KENAPA tidak ada pemeriksaan berkala untuk
kebocoran? Ternyata jawabannya adalah tidak ada aktivitas identifikasi mengenai
apa saja check-point (poin pemeriksaan) dari tiap peralatan. Tindakan kita adalah
memperkenalkan aktivitas identifikasi check point untuk tiap peralatan.
Apa yang kita lakukan untuk mendapatkan akar masalah dan peluang perbaikan
sebanyak diatas? Well, hanya bertanya, simply by asking.
Cara menjalankannya, kumpulkan orang-orang yang relevan dan punya semangat
perbaikan. Anda tentu saja tidak memerlukan seorang skeptis dan pesimis yang
meragukan setiap action-plan kita. Kedua, lakukan dalam waktu yang singkat. Jika
Anda membutuhkan sampai 2 jam untuk menjawab, mungkin Anda memerlukan
perangkat (tools) yang lebih kuat. Misalnya diagram tulang ikan.
Root Cause Analysis for Beginners - Article from the July 2004 issue of
Quality Progress, provides an overview of the purpose and justification for
Root Cause Analysis, and demonstrates application.
Events and Causal Factors Analysis - Detailed guidance on the Event and
Causal Factor method for event sequencing. Provides charting symbol
standards and tips for application.
Root Cause Live - Community site for users and providers of performance
improvement, failure analysis, and incident investigation services. Nonproprietary and non-industry-specific.
Some care and thought has gone into compiling this list -- for instance, the first 3
resources describe analysis tools that are designed to be used together, and also
provide worked examples. The last one is the best overall source of Root Cause
Analysis information (and expertise) that I have been able to find on the web.
I hope you'll find this list of resources useful. You can find more information at my
RCA Resources page. Also, if you're interested in specific tools, please check out my
page on root cause methods. If you have any questions or suggestions about any of the
links I've recommended, please feel free to leave a comment.
Root Cause Analysis - Art or Science?
There are many commonly held beliefs about root cause analysis that bother me.
Perhaps the single most irksome to me is the statement "it's an art, not a science." I
don't have anything against art, but I don't believe that this statement does justice to
the practice of root cause analysis. In fact, I believe it is one of the most damaging
perceptions that can be held by an investigator or be communicated to others.
So, why do people believe this? One widely-held perception is that root cause analysis
is not repeatable, i.e. the belief that different analysts performing independent
investigations of the same issue will not arrive at identical results. Another
commonly-stated reason is that it can be difficult to state the results of a root cause
While certain aspects of the process may be subjective in nature, even these must be
performed within an objective, scientific framework for the process to have any
validity. Thus, the assertion that RCA is "more art than science" is not justified, and
should not be promoted.
What about the etymology of Root? According to the Online Etymology Dictionary,
Root comes from the Old Norse word rot for "underground part of a plant." The
current meanings of Root make sense in this respect. The etymology tells us that
when we use the word Root today, we are basically using it as a metaphor to suggest
the qualities of plant roots. In addition to the list above, the following qualities come
to mind.
When RCA practitioners talk about Root Causes, they are basically talking about
Causes that have all the qualities listed above. They want you to understand that
problems are like plants that you don't want, i.e. weeds. If you leave a weed alone,
you will end up with more weeds. If you try to remove a weed by cutting it off at the
surface, your weed will grow back. The part of a weed you have to kill or remove to
prevent future weeds is the root. The best overall solution would be to treat the soil so
weeds don't take root in the first place!
So, back to the real questions at hand: what is a Root Cause? At what point are you
satisfied that you've found one? When can you stop asking "Why"? Here's a short
answer: you're right next to a Root Cause for your problem when you reach a
fundamental force, law, or limit that cannot be removed by any action taken within
your system. The actual Root Cause is the contradiction between your system's values
(purpose, rules, culture, etc.) and these fundamental forces, laws, or limits.
That's all I'm going to say for now, but I'll be exploring this topic in more detail in the
future. Keep watching my blog for more articles on this topic.
A previous article discussed the definition of the word root as it applies to the concept
of root cause. However, that article did not provide a definition for the word cause.
While the meaning of cause may seem obvious to the casual observer, this article will
develop a very precise definition that is useful for the incident investigator or root
cause analyst.
One simple, general definition of cause is the producer of an effect. This isn't a very
precise definition, but we can use it to get at something more useful. Let us break it
down into components with that goal in mind.
First, consider the concept of an effect. The word itself is fairly ambiguous, because it
is so often tied to the word cause, as in cause and effect. Looking at the concept
intuitively, however, yields some insight. What is the difference between having an
effect, versus having no effect?
In a situation where some action was taken, but there is no effect, then nothing
changed. If there was an effect, then something must have changed. The difference is
then the presence or lack of a change. In essence, an effect is a change.
Our definition for cause can now be written as the producer of a change. Let us now
try to refine this by expanding upon the concept of a producer. What is required to
produce a change?
A change requires that there be a discrete difference between initial and final states.
Except for processes like radioactive decay, where the impetus driving the change of
state is completely internal, there must be an external driver. Additionally, there are
usually other factors required to exist coincident with the driver.
What is required, then, is a set of factors sufficient to drive a particular change of
state. One or more of these factors may be active in nature, such as an action or
another change. Others may be passive or constant, such as local ambient conditions
or object properties.
Given a set of factors sufficient to drive a change, it would be instructive to ask what
happens if one or more of the factors were not present. If the factor is not necessary,
then it doesn't matter whether it does or does not exist. However, if the factor truly is
necessary but not present, then the change cannot happen.
So, in order for a change to be produced, we must have a sufficient set of factors in
which all necessary factors are present. If any of the necessary factors are not present,
the change does not occur -- each of the necessary factors is a sort of on/off switch for
the given change. In this sense, each of the necessary factors can be considered a
cause of the effect.
Incorporating all the points discussed above leads to the following definition for
cause:
A cause is any necessary component of a set of factors sufficient to drive a change.
This definition is somewhat wordy, but is very precise. It is also valuable because it
provides a clear test of whether an action or condition is in fact a cause for a given
effect. Using this definition, it is possible to screen out factors that are irrelevant.
Conversely, this definition can be used to identify missing evidence or even rule out
invalid hypotheses.
Phases of Root Cause Analysis
Root Cause Analysis (RCA) is generally conducted in several phases. I've seen some
methodologies that break down the RCA process into as many as a dozen different
steps. In reality, however, there are just three main phases we need to be concerned
about. More importantly, these three phases are very different from each other... so
different that they should always be kept distinctly separate. I've designated these
phases Investigation, Analysis, and Decision. Read on to see why.
Phase 1: Investigation
The purpose of the investigation phase is to discover facts that show HOW an incident
occurred. During investigation, we are not concerned with what didn't happen, or
what should have happened -- the only concern is what actually happened, without
any judgement of value. Investigation deals with facts in a value-neutral manner.
During the investigation phase, if you find yourself using words like "not", "should",
"error", "incorrect", "inappropriate", etc., STOP! You are injecting value judgements
into a practice that requires absolute neutrality. Facts exist regardless of what we think
or feel about them. Jumping too early into what should have happened will obscure
your vision of what did happen.
There may be times when required facts simply aren't available -- critical evidence
was destroyed in the process, or there were no witnesses to a critical event. In such
cases, you have some options. Consider secondary sources that may not be
conclusive, but could provide enough circumstantial evidence to guide further
investigation. Attempt to reconstruct the event using plausible scenarios and then
perform controlled tests to confirm or deny the most likely explanations.
Regardless of the tools you use, the final product of the investigation phase should be
a factual representation of the incident. If some facts were not available, and theory
(backed up by testing) had to be used instead, ensure this is clearly evident in the
representation of the incident. This representation should then be thought of as a
complete script or plan for reproducing the incident in detail. Only after you've
reached this point should you progress to the next phase, Analysis.
Phase 2: Analysis
The purpose of the analysis phase is to discover reasons that explain WHY an incident
occurred. This is when you take the purely factual representation of the incident and
view it within the context of the system (or organization) that created it. The values of
the system (purpose, rules, culture, etc.) can now be used to compare what actually
happened against what should have happened, at any point during the incident.
During the analysis phase, do not let yourself fall into the trap of believing that the
values of the system are always correct! You are not just analyzing the incident itself,
but also the system that created it. Mentally place yourself within the incident, watch
events unfold, and then determine if the system's values were, for example: correct
but inadequately applied, insufficient to prevent the incident, or incorrect such that the
system's values actually created (or contributed to) the incident.
Don't get too caught up in the mechanics of the analysis tool being used. Many tools
are available to aid the analysis phase. Each has it's own strengths and weaknesses,
and preferred realms of application. For example, if you're not getting any insight
using barrier analysis, switch over to change analysis. The point of any analysis tool is
to provide insight, and in some situations, one tool may be vastly superior to another.
Finally, do not let questions like "how can I fix this? ..." be considered during the
analysis phase. It is all too easy to let desired corrective actions colour your
perceptions of an incident's causes. However, analysis is about discovering conditions
that exist now or existed in the past. The future must not enter into the equation.
Jumping too early into what could be risks obscuring your vision of what is.
Regardless of the tools you use, the final product of the analysis phase should be a
finite set of root causes for the incident that show why it was inevitable. Yes,
inevitable -- these are fundamental, latent conditions that were just laying around
waiting for some kind of trigger to activate. Only after you've reached this realization
should you progress to the next phase, Decision.
Phase 3: Decision
The purpose of the decision phase is to develop recommendations that identify WHAT
should be learned and WHAT needs to be done. In this phase, we are concerned with
correcting or eliminating the root causes of an incident. This can only be
accomplished if both learning and action occur. Learning without action is mere
mental trickery, while action without learning is simply useless physical exercise.
Both are required for long-term, effective results.
During the decision phase, beware of overly-specific, conditional corrective action
recommendations! It is often tempting to save effort by cramming one more feature or
condition into an existing mechanism. However, doing so often just adds complexity
to a situation that has already shown itself to be prone to failure. Do not be afraid to
recommend complete redesign in such situations.
In some situations, there may be several options available to correct or eliminate a
root cause. In such cases, a structured decision analysis method should be used to
gauge competing recommendations against criteria such as simplicity, effectiveness,
longevity, cost, etc. However, do not forget to consider potential risks or side-effects
of each recommendation as well. In correcting one set of root causes, be sure you are
not creating another set of latent conditions or weaknesses that could lead to future
(perhaps completely different) incidents.
Finally, once it is decided which lessons must be learned and which actions must be
taken, make one final check. Evaluate the recommendations against the original
incident. Ask yourself "if we had known these lessons, and had these measures in
place, would the incident still have occurred?" Similarly for the root causes, ask "...
would these root causes still exist?" Only when you can honestly answer "NO" to both
of these questions do you have a plan that has a good chance of being effective.
Closing Notes
Hopefully, by this point you have begun to understand why I've identified three
different phases of Root Cause Analysis and why they should be kept separate. I hope
this one final thought will help you understand completely: the three phases of Root
Analysis can be subjective, but only to the extent that different systems or
organizations have different values, some of which may be contradictory or
incorrect.
Finally, note that in this whole article, I've not taken us past the point of deciding what
to do. In other words, what about actually doing? In my opinion, that's a completely
different process, perhaps the subject of a future article. All I will say at this point is
that the Root Cause Analysis philosophy outlined above fulfills the "Plan" portion of
the "Plan-Do-Check-Adjust" cycle. Hopefully, what I've written here will help you
Plan better!
Barrier Analysis
Change Analysis
...
As a discipline, Root Cause Analysis (RCA) has been approached from two different
areas, industrial safety or performance improvement. The industrial safety viewpoint
is oriented primarily at preventing bad things, while the performance improvement
viewpoint is aimed at producing good things. There is overlap between the two
priorities, but overall, the differing viewpoints have led to the development of
different "schools" of RCA, with different tools and philosophies.
There has historically been extensive research and development dedicated to RCA
tools for industrial safety (worker safety, process safety). The requirements are wellknown, a wide variety of tools have been developed, and the strengths and
weaknesses of specific approaches are understood. (This is not to say that the tools are
perfect, because they're not.) However, the story is a little different in the performance
improvement area. The theoretical underpinnings are generally not as well-developed,
and while there are a number of tools available, there is less knowledge about the
usefulness of the various tools.
A recent study by Dr. Anthony Mark Doggett [Ref 1] tries to improve the state of
knowledge regarding three tools used widely in the performance improvement school
of RCA: the cause-effect diagram (CED), the interrelationship diagram (ID), and the
current reality tree (CRT). The purpose of the study was to "...compare the perceived
differences... with regard to causality, factor relationships, usability, and
participation." In doing so, Doggett attempts to address the perception that "...one tool
is as good as another tool."
Note: Please have a look at my RCA Tools page if you're interested in detailed
information on other tools.
Statistical Results
A key feature of this study is that it is qualitative, and measures perceived differences
between the tools. The measurements were obtained by having several groups of
college students actually perform RCAs. They were introduced to the tools, given
opportunities to ask questions, and then presented with a problem and asked to "...find
the perceived root cause of the problem." Afterwards, the students' perceptions were
captured using question surveys and analyzed statistically.
CED: In general, students using the CED were not able to identify specific
root causes, even though they perceived it to be better at "... facilitating
productive problem-solving activity, being easier to use, and more readable."
ID: Students using the ID were able to find (i.e., identify and agree upon) root
causes, but they were of mixed quality as regards specificity and reasonability.
Otherwise, the ID was perceived to be no worse than the CED, in general.
CRT: The students perceived the CRT as complex and difficult to use.
However, even though most students using the CRT were uncomfortable doing
so, the quality of their outputs was better. They were able to find root causes
most of the time, and with high integrity in over half the cases.
Conclusion
Regarding the findings for the CRT, Doggett states that "This was one of the
distinguishing findings of the study." He stops short of saying this in his conclusions.
Nevertheless, the finding is still immensely valuable -- even though the CRT is
complex and more difficult to use, analysts employing it are more likely to find
accurate root causes. Coupled with the team problem-solving dynamic, and the new
thought processes introduced, that is the most important consideration.
Root Cause Checklists
The Root Cause Vision
One expression of the basis for root cause analysis, from The Root Cause Way.
1. Problems occur as a result of cause and effect.
2. The severity (or significance) of a problem is more dependent on
the system landscape than on the nature of the initiating
disturbance (the immediate active and permissive causes).
3. The immediate causes of a problem are usually caused by
something else that is more important.
4. Causes almost always come in groups (or, it is rare that any given
effect is the result of just a single isolated cause).
5. Cause and effect form a continuum that can be traced from the
point of occurrence, back to some underlying, fundamental cause or
set of causes.
6. Some of the fundamental causes for a given problem may be very
far removed from the point of occurrence.
7. The fundamental causes shape the landscape in which our systems
and processes operate.
8. The fundamental causes can be found through investigation and
analysis.
9. If fundamental causes are modified appropriately, the conditions
necessary for occurrence of the problem will cease to exist...
thereby preventing recurrence of the problem.
10.The activity by which fundamental causes are found and corrected
is called Root Cause Analysis.
Incident Response
Initial questions to ask the next time you experience a problem, from Patterns of
Response.
1. What is the current, actual impact of the problem?
2. What is the potential impact if the problem is not solved?
3. What level of risk are we willing to live with, that is also supportable
from a moral/legal/contractual viewpoint?
4. What would be an acceptable outcome that balances risk, cost, and
benefit?
Causal Factor Logic Checks
Fundamental logic checks to employ for verification of any and all causal claims
arrived at through investigation or analysis, from Five-by-Five Whys.
1. What proof do I have that this cause exists? (Is it concrete? Is it
measurable?)
2. What proof do I have that this cause could lead to the stated effect?
(Am I merely asserting causation?)
3. What proof do I have that this cause actually contributed to the
problem I'm looking at? (Even given that it exists and could lead to
this problem, how do I know it wasn't actually something else?)
4. Is anything else needed, along with this cause, for the stated effect
to occur? (Is it self-sufficient? Is something needed to help it along?)
5. Can anything else, besides this cause, lead to the stated effect?
(Are there alternative explanations that fit better? What other risks
are there?)
Human Error Questions
Questions for probing the reasons for events that appear to be caused by human error,
from Human Error.
1. Was the possibility of the error known? *
2. Were the potential consequences of the error known? *
3. What about the activity made it prone to the occurrence of the
error?
4. What about the situation contributed to the creation of the error?
5. Was there an opportunity to prevent the error prior to it's
occurrence? *
6. Once the error was committed, was there any way to recover from
it? *
7. What about the system sustained the error instead of terminating
it?
* If YES, why did the event proceed beyond this point? If NO, why not?
The BOGUS Test
A simple test for evaluating the quality / believability of root cause statements, from
The BOGUS Test.
1. Beyond Control: Some conditions are beyond our control, like
stupidity, gravity, or the weather. We can't make them go away, nor
can we change their fundamental natures. The problem is that by
identifying such a condition as a cause, we run the risk of deciding
to ignore it because its "beyond our control." The attribution of
cause should instead be made to a lack of protection against a
hazard.
2. Obvious: At times, the cause of a problem seems completely
obvious -- so obvious that we can't resist naming it. Items that fall in
this category often involve actions by people, including "operator
error" and "lack of procedure compliance." Stopping at this point is
akin to finger-pointing, though. People do what they do for a reason,
good or bad... dig deeper and find out why.
3. Grandiose: Sometimes you hear cause statements that make you
wish you knew what the investigator was smoking. "We did not
leverage our core competencies to instill a culture of knowledge
discovery and effect a paradigm shift to agile performance..." is an
example of a grandiose cause statement. It would be better to say
something like "... we dont learn from our past mistakes, and that is
hurting us." There is virtue in simplicity -- try to distill cause
statements down to their pure essence.
4. Unrelated: We often have more than one problem to deal with, and
it can be tempting to tie one problem to another in order to save
time and effort. However, in doing so we must ensure that we do
not attempt to "force-fit" an unrelated cause onto a different
problem. In trying to kill two birds with one stone, we might later
find that both birds are alive and well, and happily making new baby
birds that can't wait to grow up and come peck your eyes out.
5. Simplistic: Earlier I said that there is virtue in simplicity. However,
there is danger in being overly simplistic. We must recognize that
some problems are more complex than others, and may result from
the interaction of several different causes. If we don't identify all the
relevant interactions, we may miss something truly important.
The fields of incident investigation and root cause analysis are over-abundantly
supplied with acronyms, like E&CF, ETBA, MORT, MES, etc. After much
investigation, I've determined that to become really famous in this business, you've
got to have at least one acronym attributed to you. Therefore, I hereby unleash the
BOGUS test upon the world at large, as defined by these five factors:
Beyond Control
Obvious
Grandiose
Unrelated
Simplistic
Obviously, BOGUS is an acronym. What makes BOGUS better than most acronyms,
however, is that it is easily pronounceable, is spelled the same as a real English word,
and the meaning of that word is applicable to the concept. In other words, it is the
perfect acronym, and it is all mine! Well, okay... you can use it too, but you should
first read the explanatory text below.
Beyond Control: Some conditions are beyond our control, like stupidity, gravity, or
the weather. We can't make them go away, nor can we change their fundamental
natures. The problem is that by identifying such a condition as a cause, we run the risk
of deciding to ignore it because its "beyond our control." The attribution of cause
should instead be made to a lack of protection against a hazard.
Obvious: At times, the cause of a problem seems completely obvious -- so obvious
that we can't resist naming it. Items that fall in this category often involve actions by
people, including "operator error" and "lack of procedure compliance." Stopping at
this point is akin to finger-pointing, though. People do what they do for a reason, good
or bad... dig deeper and find out why.
Grandiose: Sometimes you hear cause statements that make you wish you knew what
the investigator was smoking. "We did not leverage our core competencies to instill a
culture of knowledge discovery and effect a paradigm shift to agile performance..." is
an example of a grandiose cause statement. It would be better to say something like
"... we dont learn from our past mistakes, and that is hurting us." There is virtue in
simplicity -- try to distill cause statements down to their pure essence.
Unrelated: We often have more than one problem to deal with, and it can be tempting
to tie one problem to another in order to save time and effort. However, in doing so
we must ensure that we do not attempt to "force-fit" an unrelated cause onto a
different problem. In trying to kill two birds with one stone, we might later find that
both birds are alive and well, and happily making new baby birds that can't wait to
grow up and come peck your eyes out.
Simplistic: Earlier I said that there is virtue in simplicity. However, there is danger in
being overly simplistic. We must recognize that some problems are more complex
than others, and may result from the interaction of several different causes. If we don't
identify all the relevant interactions, we may miss something truly important.
The best defenses against BOGUS cause determinations are rigorous application of
necessary and sufficient logic during an investigation, and requiring corroborating
evidence for every causal claim. Then when you're done investigating, use the
BOGUS test as a final check of root cause statements, prior to developing corrective
actions. Think of it as a quality control check of your root cause analysis.
Alternatively, you might want to use the BOGUS test if you're responsible for giving
final approval for implementation of a corrective action plan. Please do me a favour,
though... if you do decide to reject a report because of the BOGUS test, don't tell the
report's author about me. I don't need that kind of attention!
Barrier Analysis
Description
Barrier analysis is an investigation or design method that involves the tracing of
pathways by which a target is adversely affected by a hazard, including the
identification of any failed or missing countermeasures that could or should have
prevented the undesired effect(s).
Pros and Cons
Pros
Cons
Reproducibility can be low for cases that are not obvious or simple.
Definitions
Discussion
At the heart of barrier analysis is the concept of the target. The primary quality of a
target is that it exists under a specified range or set of conditions, and that we require
it to be maintained within that specified range or set of conditions. This very general
quality means that almost anything can be a target -- a person, a piece of equipment, a
collection of data, etc.
Given the concept of the target, we then move to the means by which a target is
adversely affected. By adverse effect, we mean that the target is somehow moved
outside of it's required range or set of conditions. Anything that does this is called a
hazard. This is a very general quality -- almost anything can be a hazard. However, it
is possible to uniquely define hazard/target pairs by the pathways through which
hazards affects targets.
Having identified hazards, targets, and the pathways through which hazards affect
targets, we arrive at the concepts of barriers and controls. These are used to protect
and/or maintain a target within it's specified range or set of conditions, despite the
presence of hazards. The primary quality of a barrier or control is that it cuts off a
pathway by which a hazard can affect a target.
Barriers and controls are often designed into systems, or planned into activities, to
protect people, equipment, information, etc. The problem is that design and planning
are rarely perfect. All hazards may not be identified beforehand, or unrecognized
pathways to targets may surface. In both of these cases, appropriate barriers and
controls may not be present. Even if they are present, they may not be as effective as
originally intended. As a result, targets may lack adequate protection from change or
damage.
The purpose of barrier analysis is thus to identify pathways that were left unprotected,
or barriers and controls that were present but not effective. All pathways relate to
specific hazard/target pairs, and all barriers and controls relate to specific pathways.
Success in barrier analysis depends on the complete and thorough identification of all
pathways.
Concepts
Energy and Change
The concept of energy has historically been used to characterize the pathways by
which hazard affects target. Very generally, energy is any physical quantity that can
cause harm. There are many types of energy, including electrical, mechanical,
hydraulic, pneumatic, chemical, thermal, radiation, etc. Note again that these are all
physical quantities, and can only be used to describe physical hazards. Consequently,
the types of barriers and controls that can be considered are primarily physical in
nature, or relate to physical harm.
More recently, hazard pathways have been characterized by the concept of change.
This concept is based on the recognition that any change in a target's condition,
physical or otherwise, could be detrimental or undesired. This allows us to consider
hazards and damage mechanisms other than the purely physical, and can lead us into
areas that are more administrative, knowledge based, or policy based in nature.
Furthermore, the concept of change does not prevent us from investigating purely
physical phenomena.
The pathway characterization (or viewpoint) affects the types of hazards, targets, and
damages that will be seen and considered during investigation and analysis.
Investigation from a purely energy-based viewpoint will tend to concentrate on
physical, energy-based hazards and damage mechanisms. Alternatively, a changebased viewpoint can be used to find both physical and non-physical damage
pathways. For this reason, it is recommended that a change-based characterization for
hazard/target pathways be adopted for general usage.
Countermeasure Effectiveness
Recall that the purpose of a barrier or control (i.e., countermeasure) is to cut off a
pathway by which hazard affects target. Many options may be available for cutting off
a hazard/target pathway, and some options may be more effective than others. Some
variables that can be used to differentiate various countermeasures include action,
placement, function, and permeability.
Action: This refers to whether the countermeasure is passive or active. Passive
constructs (i.e., barriers) tend to be more effective than those requiring action or
intervention (i.e., controls).
Placement: This refers to the location (in space, time, sequence, etc.) of a
countermeasure along the hazard/target pathway. Those located closer to the hazard
end of the pathway are often more effective than those located closer to the target.
Function: This refers to how the countermeasure cuts off the hazard/target pathway.
Those that prevent creation, accumulation, or release of a hazard tend to be more
effective than those that harden, warn, or rehabilitate the target.
Permeability: This refers to the extent that the countermeasure cuts off the
hazard/target pathway. Those that completely cut off the pathway tend to be more
effective than those that only limit or reduce the hazard.
Given the variables above, it is easy to say that the most effective countermeasure
against a potential hazard would be a hard, passive barrier at the source that
completely prevents creation of the hazard. This is rarely (if ever) practical, however.
We are then forced into designing or planning countermeasures that merely reduce
risk. This means that no single countermeasure can ever be 100% effective.
Reduction of risk to acceptable levels often requires the use of multiple, diverse
countermeasures. Multiple, because usually no single countermeasure can provide the
required risk reduction. Diverse, because the possibility of common-mode failure
itself increases overall risk. Barrier analysis thus needs to consider all the following:
where countermeasures should have been provided, but were not;
how existing countermeasures failed to prevent undesired change;
whether an appropriate mix of multiple and diverse countermeasures was provided;
and
if the overall risk of undesired change was acceptable.
Disadvantages
The use of barrier analysis presupposes that countermeasures were considered during
the design of a system, or planning of an activity. The results of a complete and
thorough barrier analysis may identify many opportunities to create new
countermeasures, or to improve existing countermeasures. However, given the same
consequence to investigate, different investigators might propose any of the following
(or variations and/or combinations thereof) as root causes:
etc.
All these statements may be true. However, such variability makes it extremely
difficult to rely on barrier analysis alone as a root cause analysis tool. It is therefore
recommended that barrier analysis results always be reviewed independently, and that
barrier analysis never be used as the sole method for determining root causes.
In the opinion of the author, the only statement above that qualifies as a potentially
valid root cause statement is the first, "preliminary hazard analysis was inadequate."
This statement could then be qualified with supporting evidence and analysis; in fact,
all the other items listed might be provided to illustrate how the preliminary hazard
analysis failed.
Change Analysis
Description
Change analysis is an investigation technique that involves the precise specification of
a single deviation so that changes and/or differences leading to the deviation may be
found by comparison to similar situations in which no deviation occurred.
Pros and Cons
Pros
Can be used to find causes that are obscure, or that defy discovery
using other methods.
Cons
Definitions
Discussion
As suggested by the name of the technique, change analysis is based on the concept
that change (or difference) can lead to deviations in performance. This presupposes
that a suitable basis for comparison exists. What is then required is to fully specify
both the deviated and undeviated conditions, and then compare the two so that
changes or differences can be identified. Any change identified in this process thus
becomes a candidate cause of the overall deviation.
What is a suitable basis for comparison? There are basically three types of situations
that can be used. First, if the deviation occurred during performance of some task or
operation that has been performed before, then this past experience can be the basis.
Second, if there is some other task or operation that is similar to the deviated
situation, then that can be used. Finally, a detailed model or simulation of the task
(including controlled event reconstruction) can be used, if feasible.
Once a suitable basis for comparison is identified, then the deviation can be specified.
Various schemes exist for performing this specification. Perhaps the most useful
scheme (attributed to Kepner and Tregoe) involves four dimensions (WHAT,
WHERE, WHEN, and EXTENT) and two aspects (IS and IS NOT). Regardless of the
scheme used, the end result should be a list of characteristics that fully describe the
deviated condition.
Given the full specification of the deviated condition, it becomes possible to perform
a detailed comparison with the selected undeviated condition. Each difference
between the deviated and undeviated situations is marked for further investigation. In
essence, each individual difference (or some combination of differences) is a potential
cause of the overall deviation.
After the potential causes are found, each is reviewed to determine if it could
reasonably lead to the deviation, and under what circumstances. The most likely
causes are those that require the fewest additional conditions or assumptions. In this
way, a large list of potential causes can be whittled down to a short list of likely
causes. Finally, given the likely causes, the actual or true cause(s) must be identified.
Generally speaking, the only way to verify which likely cause is the true cause is by
testing.
The purpose of change analysis is thus to discover likely causes of a deviation through
comparison with a non-deviated condition, and then to verify true causes by testing.
True causes found using change analysis are usually direct causes of a single
deviation; change analysis will not usually yield root causes. However, change
analysis may at times be the only method that can find important, direct causes that
are obscure or hidden. Success in change analysis depends ultimately on the precision
used to specify a deviation, and in verification of true cause through testing.
Concepts
Change
Change is introduced in all factors of life continuously. Some sources of change are
planned, as in deliberate actions taken to achieve a purpose. Other sources of change
are unplanned, as in natural, random variation, or as in factors introduced
unintentionally due to outside influences or as the result of error. Whatever the source,
change is often a source of disruption in the normal, expected, or usual flow of events.
When change is not accounted for or compensated, it can lead to deviations.
As discussed above, change analysis depends on the recognition of changes or
differences that could have led to a specific deviation. Sometimes, however, multiple
changes may have occurred over time that combine to cause the deviation. Therefore,
it is important for the investigator to consider combinations of changes or differences
as potential causes, in addition to individual changes or differences.
Similarity
Description
Causal factor tree analysis is an investigation and analysis technique used to record
and display, in a logical, tree-structured hierarchy, all the actions and conditions that
were necessary and sufficient for a given consequence to have occurred.
Pros and Cons
Pros
Cons
Definitions
Branch: A cause-effect link from one item in the tree to another immediately above it.
This assumes the tree is drawn from the top down, i.e. consequence on top and causes
below it.
Chain: A continuous sequence of branches from one item that is lower in the tree,
through one or more intervening items, to one item that is higher in the tree.
Endpoint: An item in the tree that has no branches leading into it; the first (or lowest)
item in a chain leading to the final consequence.
Discussion
Tree structures are often used to display information in an organized, hierarchical
fashion: organization charts, work breakdown structures, genealogical charts, disk
directory listings, etc. The ability of tree structures to incorporate large amounts of
data, while clearly displaying parent-child or other dependency relationships, also
makes the tree a very good vehicle for incident investigation and analysis.
Combination of the tree structure with cause-effect linking rules and appropriate
stopping criteria yields the causal factor tree, one of the more popular investigation
and analysis tools in use today.
Typically, a causal factor tree is used to investigate a single adverse event or
consequence, which is usually shown as the top item in the tree. Factors that were
immediate causes of this effect are then displayed below it, linked to the effect using
branches. Note that the set of immediate causes must meet certain criteria for
necessity, sufficiency, and existence. More information on what constitutes a
necessary and sufficient cause can be found in this article on the definition of cause.
Proof of existence requires evidence.
Once the immediate causes for the top item in the tree are shown, then the immediate
causes for each of these factors can be added, and so on. Every cause added to the tree
must meet the same requirements for necessity, sufficiency, and existence. Eventually,
the structure begins to resemble a tree's root system. Chains of cause and effect flow
upwards from the bottom of the tree, ultimately reaching the top level. In this way, a
complete description can be built of the factors that led to the adverse consequence.
Often, an item in the tree will require explanation, but the immediate causes are not
yet known. The causal factor tree process will only expose this knowledge gap; it does
not provide any means to resolve it. This is when other methods such as change
analysis or barrier analysis can be used to provide answers for the unknowns. Once
the unknowns become known, they can then be added to the tree as immediate causes
for the item in question.
Each new cause added to the tree should be evaluated as a potential endpoint. When
can a cause be designated as an endpoint? This is an object of some debate. Several
notable RCA practitioners use some version of the following criteria:
If the cause is removed or corrected, the adverse consequence does not occur.
These three criteria, taken together, are basically just a statement of the most-widely
used definition for "root cause". An alternate set of criteria, preferred by the author, is
presented below. Note that these are all referenced to the system being analyzed. (An
article deriving and explaining these criteria is forthcoming.)
A causal factor tree will usually have many endpoints. The set of all endpoints is in
fact a fundamental set of causes for the top consequence in the tree. This fundamental
set includes endpoints that would be considered both beneficial or detrimental; every
one of them had to exist, otherwise the consequence would have been different.
Endpoints that require corrective action would typically be called root causes, or root
and contributing causes if some scheme is being used to differentiate causes in terms
of importance.
In summary, the causal factor tree is an investigation/analysis tool that is used to
display a logical hierarchy of all the causes leading to a given effect or consequence.
When gaps in knowledge are encountered, the tree exposes the gap, but does not
provide any means to resolve it; other tools are required. Once the required
knowledge is available, it can be added to the tree. A completed causal factor tree
provides a complete picture of all the actions and conditions that were required for the
consequence to have occurred. Success in causal factor tree analysis depends on the
rigour used in adding causes to the tree (i.e., ensuring necessity, sufficiency, and
existence), and in stopping any given cause-effect chain at an appropriate endpoint.
Systematic Problem-Solving Sequence
Problems happen all the time. How we choose to respond is a major factor in
determining how badly we will be affected by any given problem. I would argue that
a systematic response is best, and furthermore, I propose a 9-stage sequence as
discussed in this article.
If you are already familiar with other problem-solving methodologies, like 8D or
DMAIC, some aspects of the recommended sequence may seem familiar to you. I
believe the sequence proposed below is more comprehensive than either of those, but
is also compatible with them.
There are 9 stages in the sequence. However, instead of thinking of them as 9
independent entities, I tend to see them as 3 groups of 3:
RESPOND MITIGATE ASSESS... (Problem Response)
INVESTIGATE ANALYZE DESIGN... (Root Cause Analysis)
EXECUTE REVIEW ADJUST... (Corrective Action)
Much more could be written about these groupings, and the problem solving sequence
in general, but I'll let it go for now. Just keep in mind the intent of presenting such a
thing is to provide a structured framework for solving problems, not to box you in or
limit you unnecessarily. Please use this if you think it will be helpful; otherwise,
ignore it!
1. RESPOND - Respond to the problem: address injury/damage that has already
been caused, make appropriate notifications, preserve/quarantine evidence to
the extent possible, initiate cleanup actions.
2. MITIGATE - Mitigate the immediate causes: take action to reduce the
production and/or release of the bad thing, enhance protections against it, find
a way to eliminate it or minimize it.
3. ASSESS - Assess risk: determine extent of condition, review adequacy of
measures in place, assess risk of further harm, decide if deeper analysis
required.
4. INVESTIGATE - Investigate the how: track the actual sequence of events,
figure out what changes of state took place, determine the script behind the
problem.
5. ANALYZE - Analyze the why: break down the script and determine critical
points, figure out what should have happened, find the gaps between actual
and expected, uncover key forcing factors, determine extent of cause.
6. DESIGN - Design the solution: find the weaknesses, pick the points of most
leverage, develop solution options, decide on best combination of actions,
validate the plan, get buy-in and funding.
7. EXECUTE - Execute the plan: develop timeline, obtain materials, marshall
resources, initiate action, monitor performance, verify completion.
8. REVIEW - Review effectiveness: check for recurrence of original problem,
check for instances of related problems, verify actions taken still relevant,
assess continued risk.
9. ADJUST - Adjust the plan: address deficiencies in execution, assess effects of
changes from outside the plan, identify new/revised actions needed to ensure
effectiveness.
Stages 4 - 6 above are discussed more thoroughly in Phases of Root Cause Analysis...
however, note that the phase previously referred to as Decide is now designated
Design. I just thought Design captured the intent better.
Root Cause Analysis (RCA) can be applied to events of any size or significance.
However, it's usually applied to large events, i.e. those with serious consequences.
Even so, it can and should be applied to smaller events as well. Statistically, smaller
events are more likely to occur than larger events. Thus, application of RCA to small
events may identify many significant opportunities for improvement.
Given that smaller events are more likely to occur, should we focus our RCA efforts
solely on smaller events? This would have the advantage of ensuring that we have a
statistically significant sample from which to draw learning opportunities. Why, then,
do we expend so much effort applying RCA to large events if we can get the same (or
better) benefits by focusing on small events? This idea could be expressed as follows:
Little events happen all the time. We should analyze each little event. After we have
enough observations, we will have a statistically significant sample. This should be
the basis for our learning.
Instead, we analyze the big events because they catch our attention. Big events come
around only once in a while. We spend a lot of time investigating them. However, we
have only one sample point. Therefore, our results have little statistical significance.
By emphasizing investigation of the big events, we are potentially learning the wrong
things because we may be placing too much emphasis on issues that have very little
statistical significance.
Is this a valid idea? Should we emphasize RCA of small events, and perhaps do away
with RCA of large events altogether? I'll try to answer that question in this article.
There is a common belief that large events and small events have the same causes.
Therefore, it is assumed that by analyzing small events and applying lessons learned
from them, we prevent large events as well. However, using this strategy, do we limit
the severity of potential future events?
Suppose we analyze only small events. We'll have a lot of data on common event
initiators and latent conditions. As we'll have a lot of data, we'll develop a very good
understanding of the events and our corrective actions will be very good. We'll knock
down the frequency of these events by a significant amount, perhaps even eliminate
them completely.
Again, we have to ask the question, have we limited the severity of potential future
events? If we assume that all events, large and small, have the same root causes, then
the answer is yes. Is this true though? What makes a small event different from a large
event?
Speaking very generally, it's the interaction of various latent conditions. Some of these
latent conditions may be deeply embedded in the operations of our systems. They may
be very subtle conditions that will not be activated very often. With a low probability
of occurrence, we won't have much data on them and we may not have any
protections against them.
They may be very simple conditions that, under ordinary circumstances, cause no
problems for us. Its when circumstances change in unexpected ways that these kinds
of conditions become a real danger. An event that might ordinarily terminate with
very low consequences could, under less common circumstances, terminate with very
serious consequences.
Consider a condition like grinder kickback. This can occur when using a grinder
because the grinder "catches" on whatever's being worked on, and the rotational force
of the spinning grinder wheel causes the entire tool to kick back toward the operator.
Standard safety precautions while using such a tool include maintaining a proper
stance and appropriate distance from the grinder. Kickback is a known condition, and
under most conditions, is easily compensated for.
Now, throw in a twist. A worker decides that, in a standing or kneeling position, he
can't get a good angle on whatever he's grinding. He decides that the best, fastest way
to get the job done is to lie down on the floor, and hold the grinder above him to get at
the bottom of the piece he's grinding. He has every intention of being very careful.
However, he has just removed his ability to avoid a kickback if it occurs. The weight
of the grinder is now working against him, as well.
The job starts out fine. Then the grinder catches on something. It kicks back. The
worker can't avoid it. The mechanics of the event are such that the grinder moves
laterally towards the worker's head. The worker receives an extremely serious
laceration to his face.
This is a "large" event. You would never have expected it to happen. The
circumstances of the event were unusual. The probability of the event happening
again appears to be low. Should we subject this event to a detailed root cause
analysis?
Of course we should! We should investigate and analyze the heck out of this event.
However, we must not limit ourselves to the question of "why did the worker use the
grinder that way." We must instead find out "what is it about the way we do business
that: set up this situation, forcing the worker to make this choice; convinced the
worker that he needed to do the job this way; kept him from taking more time to get a
different tool or to rotate the piece he was working on."
I'm not making this up. It actually happened two years ago. The worker required
extensive reconstructive surgery to one side of his face. It was pure luck that he didn't
lose his nose or one of his eyes.
In conclusion, my belief is that we must investigate and analyze the sporadic, large
events. So what if the probability of occurrence is low? Remember that risk is
probability times consequences. If the potential consequences are high, we must do
what we can to prevent those consequences from occurring -- even if it is a low
probability event. Sometimes, a sample of one is more significant than a sample of
thousands.
becomes unworkable in those special cases where it does not provide good
answers.
This last point might initially seem to be a disadvantage. How can a model that
becomes unworkable ever be beneficial? Consider it this way -- what if we used an
alternate model that happily gave us answers, well outside it's range of applicability?
We might very well continue using the model without realizing that it no longer
applied. Even worse, we would believe the wrong answers that the model helped us
find!
What other types of models do we employ in root cause analysis? In some cases, we
may develop engineering models for physical processes, in order to understand how a
failure occurred. In others, we might model an industrial processes to show where
bottlenecks are constraining throughput. These types of models are used quite
frequently, and generally require specialized knowledge to use properly. However, the
difficulty of developing and using such models may actually pale in comparison to the
modeling of human behaviour.
We need models of human behaviour because humans are so incredibly complicated.
Such models must account for information input and processing, communication,
motivation, learning, decision, fatigue... the list goes on and on. Then, on top of
models for individual human behaviour, we must add models for group,
organizational, and societal behaviour and interaction. The problem seems intractable.
Nonetheless, several generalized models do exist.
One step above the models of human and organizational behaviour are models of
accident initiation and propagation. The driver for research interest in this area is
obvious, as industrial accidents are potentially the most damaging events that can
occur. Death and destruction, possibly on a large-scale, are the consequences. It is
hoped that by understanding how accidents occur, we can find strategies to reduce the
risk of such events.
Accident models, in fact, tend to be models of human and organizational behaviour.
What makes accident models different is the sharp focus on failure propagation. The
underlying assumption tends to be that accidents start as relatively simple, minor
events that eventually spiral out of control. In fact, most recently developed accident
models tend to be system models that focus attention on complex interactions between
multiple, lower-level failures or infractions.
In the end, we are left with models upon models upon models... each with their own
rules and assumptions, strengths and weaknesses. As stated previously, models are
useful because they help us abstract away unimportant data so we can increase our
focus on useful information. This is the strength of using models; unfortunately, it is
also the main weakness. If models are used without knowledge of their assumptions
and limitations, we could end up discounting potentially important facts and
misdirecting our investigations.
There is no single "model of everything" we can rely upon to provide good answers in
all cases. However, we shouldn't be fooled into thinking that the various models can't
help us achieve better root cause analysis results. Models can guide us to possibilities
we might have missed, and provide insights that we might not have seen. The key
success strategy may well be to have knowledge of a wide variety of models that can
be used in a variety of situations. Then, as with anything else in life, we must simply
ensure that we understand the tools we use, before we use them.
Gambar 2.1 Frame Work Implementasi Fishbone Diagram dalam inovasi Pendidikan
2. Fishbone Diagram
Diagram Tulang Ikan atau Fishbone diagram sering pula disebut Ishikawa diagram
sehubungan dengan perangkat diagram sebab akibat ini pertama kali diperkenalkan
oleh Prof. Kaoru Ishikawa dari Jepang. Gasversz (1997: 112) mengungkapkan bahwa
Diagram sebab akibat ini merupakan pendekatan terstruktur yang memungkinkan
dilakukan suatu analisis lebih terperinci dalam menemukan penyebab-penyebab suatu
masalah, ketidaksesuaian, dan kesenjangan yang ada. Selanjutnya diungkapkan bahwa
diagram ini bisa digunakan dalam situasi: 1) terdapat pertemuan diskusi dengan
menggunakan brainstorming untuk mengidentifikasi mengapa suatu masalah terjadi,
2) diperlukan analisis lebih terperinci terhadap suatu masalah, dan 3) terdapat
kesulitan untuk memisahkan penyebab dan akibat. Berikut disarikan dari Gasversz
(1997, 112:114) tentang langkah-langkah penggunaan diagram Fishbone.
1. Dapatkan kesepakatan tentang masalah yang terjadi dan diungkapkan masalah itu
sebagai suatu pertanyaan masalah (problem question).
2. Bangkitkan sekumpulan penyebab yang mungkin, dengan menggunakan teknik
brainstorming atau membentuk anggota tim yang memiliki ide-ide berkaitan dengan
masalah yang sedang dihadapi.
3. Gambarkan diagram dengan pertanyaan masalah ditempatkan pada sisi kanan
(membentuk kepala ikan) dan kategori utama seperti: material, metode, manusia,
mesin, pengukuran dan lingkungan ditempatkan pada cabang-cabang utama
(membentuk tulang-tulang besar dari ikan). Kategori utama ini bisa diubah sesuai
dengan kebutuhan.
4. Tetapkan setiap penyebab dalam kategori utama yang sesuai dengan menempatkan
pada cabang yang sesusai.
5. Untuk setiap penyebab yang mungkin, tanyakan mengapa? untuk menemukan
akar penyebab, kemudian daftarkan akar-akar penyebab masalah itu pada cabang-
cabang yang sesuai dengan kategori utama (membentuk tulang-tulang kecil dari ikan).
Untuk menemukan akar penyebab, kita adapat menggunakan teknik bertanya
mengapa lima kali (Five Why).
6. Interpretasikan diagram sebab akibat itu dengan melihat penyebab-penyebab yang
muncul secara berulang, kemudian dapatkan kesepakatan melalui konsensus tentang
penyebab itu. Selanjutnya fokuskan perhatian pada penyebab yang dipilih melalui
konsensus itu.
7. Terapkan hasil analisis dengan menggunakan diagram sebab-akibat itu dengan cara
mengembangkan dan mengimplementasikan tindakan korektif, serta memonitor hasilhasil untuk menjamin bahwa tindakan korektif yang dilakukan itu efektif karena telah
menghilangkan akar penyebab dari masalah yang dihadapi.
Gambar 2.2 Fishbone Diagram (Gasversz, 1997:113)
Pada langkah ketiga 3 tersebut di atas kategori utama dapat kita ubah menjadi sebab
satu (Sb1) atau sebab 2 (Sb2) dan selanjutnya hingga menjadi cabang-cabang kecil
sebab Sb1a, Sb1b dan seterusnya. Kita sepakati konteks korektif dalam hal ini adalah
produk atau proses perbaikan dalam bidang pendidikan sehingga menghasilkan suatu
pembaharuan/inovasi pendidikan baik dalam bentuk discovery maupun invention
baik dalam tatanan mikro maupun makro.
Kategori Utama
Sebab 1 (Sb1): Guru
Sebab 2 (Sb2): Siswa
Sebab 3 (Sb3): Masyarakat
Sebab 4 (Sb4): Kurikulum
Sebab 5 (Sb5): Sarana
Five Why
Why Sebab 1 Sebab 2 Sebab 3 Sebab 4 Sebab 5
Guru Siswa Masyarakat Kurikulum Sarana
Why 1 Guru kurang kompeten Siswa kuarang antuasias belajar Masyarakat kurang
peduli kualitas jasa pendidikan Membutuhkan banyak praktek dan referensi Referensi
dan praktek kurang memadai
Why 2 Fasilitas pendidikan dan pelatihan kurang Teacher center dan pembelajaran
sering konvensional Masyarakat hanya sekedar berpifikir tentang lulus dan tidak lulus
Tujuan kurikulum banyak
Buku, Alat dan bahan kurang memadai
Why 3 Tidak ada waktu dana pendukung Kurangnya referensi atau buku sumber dan
praktek Terlalu percaya pada sekolah Materi yang harus disampaikan banyak
Keterbatasan Dana
Why 4 Pendanaan dari pribadi, pemerintah dan komite sekolah kurang lancar
Kurangnya fasilitas Membatasi diri hanya berpikir tentang kelangsungan pendidikan
siswa (ekonomi) Tuntutan kelulusan untuk melanjutkan kuliah Keterbatasan bantuan
dari pemerintah maupun komite sekolah
Why 5 Alokasi dana pemerintah dan siswa terbatas. Alokasi dana pemerintah dan
siswa terbatas. Angapan ekonomi lebih utama untuk kehidupan dibanding lainnya
Perbaikan pendidikan untuk perbaikan ekonomi. Alokasi dana pemerintah dan siswa
terbatas
Atau tampilan deskripsi dapat berupa catatan demikian yang jika diterapkan dalam
fishbone diagram memunculkan gambaran tulang besar dan tulang kecil ikan. Sebagai
berikut:
Sb1-1: Guru kurang kompeten
Sb1-2: Fasilitas pendidikan dan pelatihan kurang
Sb1-3: Tidak ada waktu dan cana dukungan
Sb1-4: Pendanaan pribadi, pemerintah dan komite sekolah kurang
Sb1-5: Alokasi dana pemerintah dan siswa terbatas
Sb2-1: Siswa kurang antusias belajar
Sb2-2: Teacher center
Sb2-3: Kurangnya referensi atau buku sumber dan praktek
Sb2-4: Kurangnya fasilitas
Sb2-5: Alokasi dana pemerintah dan siswa terbatas
Sb3-1: Masyarakat kurang peduli kualitas jasa pendidikan
Sb3-2: Masyarakat hanya berpikir tentang lulus dan tidak lulus
Sb3-3: Terlalu percaya pada sekolah
Sb3-4: Membatasi diri berpikir tentang kelangsungan perekonomian
Sb3-5: Ekonomi lebih untuk kehidupan (sekolah pun untuk perbaikan ekonomi)
Gambar 2.5 Fishbone Diagram Rendahnya Daya Serap Siswa SMA Terhadap
Pelajaran Kimia
Dari contoh tersebut di atas, dapat diinterpretasikan bahwa akar masalah adalah
keterbatasan pendanaan baik dari pemerintah maupun komite sekolah untuk
menunjang proses belajar baik tingkat profesional/komptensi guru maupun siswa.
Sehingga solusinya adalah penggalangan dana atau pengalokasian/pendistribusian
dana yang diterima sekolah untuk menutupi kekurangan tersebut. Konteks tersebut di
atas tidak mutlak, artinya hasil analisis akar maasalah bergantung pada individu/Tim
melaksanakan Brainstorming. Bahkan kajian seperti di atas (kesulitan belajar) bisa
dipersempit skupnya dalam konteks materi, metode mengajar, media, guru, siswa, dll,
bergantung pada sudut pandang Tim analisis akar masalah.
Dari contoh 1 dan 2 nampak sekali bagaimana analisis akar masalah sangat membantu
dalam merencanakan tindak lanjut atau tindakan pemecahan masalah. Dimana
outcome-nya adalah dapat dalam bentuk perubahan atau perbaikan bahkan inovasi
baik discovery maupun invention. Setidaknya hal ini membantu mahasiswa dalam
upaya membuat inovasi melalui jalur skripsi atau thesis, untuk guru membantu dalam
memperlancar penilitian tindakan kelas. Selain itu lembaga pendidikan baik pusat
maupun daerah serta sekolah itu sendiri sebagai wujud organisasi dimana di dalamnya
terjadi proses manajemen sudah selayaknya berinovasi yang berbasis pada 6 prinsip
inovasi untuk lebih bermakna setidaknya dapat menjauhi untuk mengeluarkan
kebijakan-kebijakan pendidikan yang tidak bijaksana.
DAFTAR PUSTAKA
Danim, Sudarwan. 2010. Manajemen dan Kepemimpinan
Ytransformasional Kekepala Sekolahan. Jakarta: Rineka Cipta.
,. 2010. Inovasi Pendidikan Dalam Upaya Peningkatan
Profesionalisme Tenaga Kependidikan. Bandung: Pustaka Setia.
Gaspersz, Vincent. 1997. Manajemen Kualitas Penerapan Konsep-Konsep
Kualitas Dalam Manajemen Bisnis Total. Jakarta: PT. Gramedia Pustaka
Utama.
Harsono, Ari. 2008. Metode Analisis Akar Masalah dan Solusi. MAKARA,
SOSIAL HUMANIORA, VOL. 12, NO. 2, DESEMBER 2008: 72-81
Kusmana, Suherli. 2010. Manajemen Inovasi Pendidikan, Ciamis:
PascasarjanaUnigal Press.
Mulyasa, E. 2008. Menjadi Guru Profesional Menciptakan Pembelajaran
Kreatif dan Menyenangkan. Bandung: Rosda.
Suud, Udin Syaefudin. 2010. Inovasi Pendidikan. Bandung: Alfabeta.