Professional Documents
Culture Documents
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:
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):
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.
RCA is an essential ingredient in pointing organizational change efforts in the
right direction.
Finally, it is probably the only way to find the core issues contributing to your
toughest problems.
While it is often used in environments where there is potential for critical or
catastrophic consequences, this is by no means a requirement. It can be
employed in almost any situation where there is a gap between actual and
desired performance. Furthermore, RCA provides critical info on what to
change and how to change it, within systems or business processes.
Significant industries using root cause analysis include manufacturing,
construction, healthcare, transportation, chemical, petroleum, and power
generation. The possible fields of application include operations, project
management, quality control, health and safety, business process
improvement, change management, and many others.
Your problems may not be as spectacular as the ones pictured above, but they
probably have many similarities under the surface. This is the point of root
cause analysis -- to dig below the symptoms and find the fundamental,
underlying decisions and contradictions that led to the undesired
consequences. If you want your problems to go away, your best option is to
kill them at the root.
Teknik analisis yang bertahap dan terfokus untuk menemukan akar masalah suatu
problem, dan bukan hanya melihat gejala-gejala dari suatu masalah.
Example sentence(s):
http://pusdiknakes
Keselamatan Pasien.
- Institut Manajemen
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 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 Ha
http://w w w .unha
- LP Universitas Hasanuddin
Peserta mampu melakukan analisis akar penyebab dengan 5 Why's.
ASKEDU
http://w w w .aske
- ASKEDU
Untuk membedakan antara modus kegagalan (modes of failure), penyebab
(cause of failure), dan efek (effect of failure), maka diambil 3 kotak terakhir
dari tiap-tiap analisis akar penyebab masalah masing-masing sebagai cause
of failure, mode of failure dan effect of failure.
Mercu Buana
Explanation:
Padanan pada Kateglo juga analisis akar penyebab.
Mercu Buana
http://74.125.153.
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.
Control of Change Cause Analysis - Manual for performing "3CA" analysis of
root causes, which seeks to identify changes that could have been controlled,
or where controls failed.
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.
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.
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
Cause Analysis differ in their balances of objectivity versus subjectivity. Moving
subjectivity too early into the process ultimately destroys it's integrity.
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
Causal Factor Tree Analysis
...
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.
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.
3.
4.
5.
6.
7.
8.
9.
10.
* 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
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.
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:
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
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
Pros
Provides structure for the recording of evidence and display of what is known.
Through application of logic checks, gaps in knowledge are exposed.
Tree structure is familiar and easy to follow.
Can easily be extended to handle multiple (potential) scenarios.
Can incorporate results from the use of other tools.
Works well as a master investigation/analysis technique.
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:
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.
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.
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.
Terkadang untuk sampai pada akar masalah bisa pada pertanyaan kelima atau bahkan
bisa lebih atau juga bisa bahkan kurang tergantung dari tipe masalahnya. Metoda root
cause analysis ini cukup mudah dan bisa sampai pada akar masalahnya, bukan hanya
di permukaan saja. Dan mencegah masalah tersebut terulang lagi.
Tahapan umum saat melakukan root cause analysis dengan why why analysis:
1. Menentukan masalahnya dan area masalahnya
2. Mengumpulkan team untuk brainstorming sehingga kita bisa memiliki
berbagai pandangan, pengetahuan, pengalaman, dan pendekatan yang berbeda
terhadap masalah
3. Melakukan gemba (turun ke lapangan) untuk melihat actual tempat, actual
object, dan actual data
4. Mulai bertanya menggunakan why why
5. Setelah sampai pada akar masalah, ujilah setiap jawaban dari yang terbawah
apakah jawaban tersebut akan berdampak pada akibat di level atasnya.
Contoh: apakah kalau ada jadwal rutin maintenance maka akan mudah buat
analisis akar masalah lebih kentara pada proses perencanaan inovasi demi memunculkan
solving, perubahan dan memunculkan inovasi. Meskipun menurut Suud (2010) tidak
selamanya inovasi adalah perubahan namun kita yakin perubahan merupakan bagian dari
inovasi.
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 cabangcabang 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).
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/Dosen kurang kompeten/tidak banyak belajar
Sb1-2: Guru/Dosen mengajar ditempat lain atau sibuk mencari uang tambahan
Sb1-3: Kesejahteraan kurang
Sb1-4: APBN tidak mencukupi
Sb1-5: Pajak banyak hilang korupsi merajalela (temuan...)
Sb2-1: Siswa input (lulusan sekolah sebelumnya) kurang berkualitas
Sb2-2: Unit pemroses rendah (guru, fasilitas, dll)
Sb2-3: Anggaran APBN Rendah (BOS tidak normal)
Sb2-4: Pajak negara terserap sedikit
Sb2-5: Korupsi dan sadar pendidikan moral rendah
Sb3-1: Masyarakat kurang peduli kualitas lulusan siswa
Sb3-2: Masyarakat sudah menganggap biasa atau terbiasa dengan KKN
Sb3-3: Rekruitmen siswa dan SDM tidak bersih atau transaparan
Sb3-4: Ada ketidak sesuaian penerapan kebijakan
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)
Sb4-1: Membutuhkan banyak praktek dan referensi
Sb4-2: Indikator atau tujuan terlalu luas dan banyak
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.