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:






tidak berulangnya kasus yang sama
bisa diterapkan
tidak membutuhkan investasi yang sangat tinggi
fleksibel dengan komponen lainnya
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):



In normal chaotic organizational environments it is often quite difficult to find
candidates for root cause analysis because the situations which repeat are
either distributed over time so one doesn't realize they are actually recurring,
or the situation happens to different people so there isn't an awareness of the
recurring nature of the situation. systems-thinking.org
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.

As a business process improvement tool, RCA seeks out unnecessary
constraints as well as inadequate controls.







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):

Saat ini Pendekatan Analisis Akar Masalah banyak di gunakan di lingkungan
pelayanan kesehatan / rumah sakit untuk menyelesaikan masalah akibat
Kejadian Tidak Diharapkan (KTD) dan Sentinel Event untuk Program
Institut Manajeme

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
- Jurnal Universitas Indonesia

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.
Pojok Anti Korups
http://pojokantikor
-
Definition from Wikpedia :
Analisis akar penyebab ialah cara mengatasi masalah yang bertujuan untuk mengenali
akar penyebab masalah atau kejadian.
Example sentence(s):

Salah satu teknik analisis yang biasa digunakan dalam menganalisa
kegagalan suatu sistem adalah analisis akar penyebab (Root Cause Analysis).
RCA adalah sebuah metode yang terstruktur yang digunakan untuk
menemukan akar penyebab dari masalah kerusakan poros.
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.
-
5 Why dalam Analisa Masalah
Banyak yang mengatakan bahwa analisa akar masalah itu adalah suatu aktivitas yang
rumit dan kompleks, well, ada benarnya, tetapi ada juga cara untuk melakukannya
dengan cara yang sangat sangat mudah.
Yang ingin kami kenalkan adalah 5-Why. Yep, terjemahan bebasnya “5-Kenapa”.
Jika Anda melihat ada masalah oli tercecer di lantai, apa yg Anda lakukan? Tentu
saja, yang pertama kali Anda lakukan adalah meminta orang lain untuk
membersihkannya.
Langkah berikutnya, tanyalah KENAPA oli bisa tercecer di lantai? Jawabannya
adalah karena oli ini merembes dari tangki oli yang bocor. Tindakan kita adalah
perbaiki tangki oli tsb.
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.
Introduction to Root Cause Analysis
There's a lot of information on Root Cause Analysis available on the web.
Unfortunately, if you're a beginner, finding useful, easy-to-use information can be
difficult. That's why I've put together this list of 4 useful web resources for an
Introduction to Root Cause Analysis.
Note: the first three links point to PDF documents.




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.
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
analysis with much precision, especially if issues of human or organizational
performance are involved.
In addition, I believe that many people instinctively recognize that some aspects of
root cause analysis are inherently subjective. By necessity, RCA requires that an
analyst compare that which is to that which ought to be... and what ought to be is
often a matter of opinion. Furthermore, the development of recommendations (the
most obvious outcome of root cause analysis) is certainly subjective in nature, as there
is rarely an absolute standard to determine which solution is best, even for purely
technical issues.
However, I don't believe any of the above justify characterizing root cause analysis as
an art, or as "more art than science." In general, art is the application of creativity for
its own sake without any objective criteria for judging quality. In contrast, root cause
analysis, while containing elements of creativity, is rarely (if ever) applied without a
specific purpose, or without objective criteria for what constitutes a quality outcome.
I would argue that root cause analysis is a science, or is at least a process that must be
performed scientifically. The following description of scientific method from
Wikipedia provides a good summary of my viewpoint:
Scientific method is a body of techniques for investigating phenomena and acquiring
new knowledge, as well as for correcting and integrating previous knowledge. It is
based on observable, empirical, measurable evidence, and subject to laws of
reasoning.
Note the emphasis on the use of evidence and reasoning for investigating and
acquiring knowledge: this could very well serve as a working description of the root
cause analysis process. Consider also that science can refer to both natural (or "hard")
sciences like physics and chemistry, or social ("soft") sciences like economics and
sociology. The following description of social science from Wikipedia provides
additional insight:
The social sciences are groups of academic disciplines that study the human aspects
of the world. They diverge from the arts and humanities in that the social sciences
emphasize the use of the scientific method and rigorous standards of evidence in the
study of humanity, including quantitative and qualitative methods.
So, even root cause analysis efforts that delve into issues of human and organizational
performance must be performed scientifically and be subject to rigorous standards of
evidence. (Of course, this has little bearing on the parts of a root cause analysis that
deal solely with physical/technical issues.)
In summary, the root cause analysis process contains many elements that are not
consistent with the belief that it is an art. These elements (evidence, reasoning,
objective standards), however, are fully consistent with the characterization of root
cause analysis as a science, or at least as a process dominated by scientific thinking.
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.
Meaning of Root Cause
In the practice known as Root Cause Analysis (RCA), we are generally looking for
reasons to explain why a problem occurred. In most cases, we find that there are many
reasons for any given problem. Some (or most?) of them may be far removed in time,
space, and subject from the problem itself. We typically call such reasons Root
Causes, and according to theory, correcting these Root Causes will prevent future
occurrences of this problem, and potentially many others.
The basic RCA method is to simply ask "Why" over and over again until you arrive at
a Root Cause. The real question then becomes: how do we know when to stop asking
"Why"? At what point are we satisfied that we've identified a Root Cause? What is a
Root Cause? These are questions that constantly spark disagreement among RCA
practitioners. While there is some disagreement as to what constitutes a Cause, the
real fireworks begin when you try to define the word Root.
Dictionary.com has a rather lengthy definition of Root. I won't reproduce it here, but
it should suffice to say that there are many different definitions. However, there are a
few common meanings that run through most of them:





Roots are frequently hidden under the surface.
Roots provide support or act as a base.
Roots relate to origins and sources.
Roots are primary and fundamental.
Roots are established and entrenched.
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.




Roots can spread out further than you expect.
Roots can be hard to find and harder to get rid of.
Roots that aren't removed may continue growing.
Roots are often very dirty.
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
Cause Analysis differ in their balances of objectivity versus subjectivity. Moving
subjectivity too early into the process ultimately destroys it's integrity.



Investigation must be completely objective, in order to expose only factual
relationships.
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.
Decision is subjective in that multiple options may exist to correct or eliminate
root causes, and selection of the right options must be coloured by what we
want our values to be in the future.
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!
Methods for Root Cause Analysis
Maslow's Law of Problem Solving: If the only tool you have is a hammer, every
problem looks like a nail.
Wilson's Corollary: Even if a problem really is a nail, you've still got to know whether
to bang it in or yank it out.
This is a constant work in progress... the only root cause analysis tools available for
review at the moment are:




Barrier Analysis
Change Analysis
Causal Factor Tree Analysis
...
Other Recommended Articles



Systematic Problem-Solving Sequence
Phases of Root Cause Analysis
Introduction to Root Cause Analysis
RCA Tool Comparison
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.




Participation: No statistical differences (between the 3 tools) were perceived
regarding the ability to spark constructive discussion in a group setting.
Causality: No statistical differences were perceived regarding the ability to
identify interdependencies between causes, or to find root causes.
Factors: No statistical differences were perceived regarding the ability to find
factors (causes, effects, or both), or relationships between them. However,
post-hoc testing showed that the CED was perceived to be better at
categorizing factors.
Usability: There were significant statistical differences observed in this area.
Generally, the CRT was judged to be much harder to use than both the CED
and the ID.
Root Cause Results
Beyond the statistical results, the study examined the ability of the students to identify
root causes that were specific and reasonable. Note that this factor was examined
separately from the usability factor discussed above.



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
A vision of how an organization would look if it had a fully developed culture of
continuous improvement, from The Root Cause Vision.
1.
2.
3.
4.
Continuous improvement is acknowledged by all as a core business activity.
Root cause thinking has permeated all levels of the organization.
The seeking out of underlying truths has become instinctual.
We respond to problems quickly and rationally, with appropriate focus and
engagement.
5. We do not waste time or energy on blame; learning is the focus.
The Root Cause Way
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.
Were the potential consequences of the error known? *
What about the activity made it prone to the occurrence of the error?
What about the situation contributed to the creation of the error?
Was there an opportunity to prevent the error prior to it's occurrence? *
Once the error was committed, was there any way to recover from it? *
What about the system sustained the error instead of terminating it?
What fed the error, and drove it to become a bigger problem?
What made the consequences as bad as they were?
What (if anything) kept the consequences from being worse?
* 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 don’t 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 BOGUS Test
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 don’t 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




Conceptually simple, easy to grasp.
Easy to use and apply, requires minimal resources.
Works well in combination with other methods.
Results translate naturally into corrective action recommendations.
Cons




Sometimes promotes linear thinking.
Sometimes subjective in nature.
Can confuse causes and countermeasures.
Reproducibility can be low for cases that are not obvious or simple.
Definitions
Barrier: A construct between a hazard and a target, intended to prevent undesired
effects to the target. A barrier is often passive, i.e. it’s protective nature is inherent to
it’s structure, and no additional action on the part of any agent is required to afford
this protection.
Control: A mechanism intended to prevent undesired effects to the target. A control is
often active, i.e. it’s protective nature is brought into being through the actions of an
agent.
Countermeasure: A barrier or control intended to cut off a pathway between hazard
and target.
Hazard: An agent that can adversely affect a target.
Pathway: A route or mechanism that provides the means, or medium, through which a
hazard can affect a target.
Target: An object that requires protection, or needs to be maintained in a particular
range or set of conditions.
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:






preliminary hazard analysis was inadequate;
appropriate countermeasure was not provided;
inappropriate countermeasures were provided;
existing countermeasure was inadequate;
existing countermeasure was not properly employed;
existing countermeasure was rendered inoperative;



hazard was not controlled;
target should not have been exposed to hazard;
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




Conceptually simple, easy to grasp.
Works well in combination with other methods.
Results translate naturally into corrective action recommendations.
Can be used to find causes that are obscure, or that defy discovery using other
methods.
Cons





Requires some basis for comparison.
Resource intensive, requires exhaustive characterization of deviation.
Applicable only to a single, specific deviation.
Provides only direct causes for a deviation.
Results may not be conclusive; testing usually required.
Definitions
Change: A discrete difference between an occurrence exhibiting the deviation, and a
similar occurrence that did not exhibit the deviation.
Deviation: A situation in which actual results or actual performance differed from
what was expected.
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
Change analysis is heavily dependent on comparison with similar situations.
However, there are varying degrees of similarity, depending on how close the
undeviated condition is to the deviation under investigation. The best case scenario
for change analysis is when you have previous operational history for the exact same
task or operation. In this case, changes or differences that could have contributed to
the deviation are easily identifiable.
The problem with trying to compare situations that are less similar is that other,
inherent differences in underlying conditions may mask differences that were
responsible for the deviation. Since each difference identified in the change analysis
procedure is considered a potential cause, the list of potential causes may include
some of these inherent differences -- which may or may not bear any causal relation
to the specific deviation under investigation.
It therefore is critical that an appropriate basis for comparison be selected when
performing change analysis. Furthermore, inherent differences between the actual
deviated condition and the situation chosen for comparison must be fully identified
and handled with extreme care. Finally, when verifying true cause by testing, the test
condition must be made as identical to the actual deviated condition as possible.
Causal Factor Tree Analysis
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






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




Cannot easily handle or display time dependence.
Sequence dependencies can be treated, but difficulty increases significantly with
added complexity.
Shows where unknowns exist, but provides no means of resolving them.
Stopping points can be somewhat arbitrary.
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:



The cause must be fundamental (i.e. not caused by something more
important), AND
The cause must be correctable by management (or does not require
correction), AND
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.)



The cause is a system response to a requirement imposed from outside the
system, OR
The cause is a contradiction between requirements imposed from within the
system, OR
The cause is a lack of control over system response to a disturbance, OR

The cause is a fundamental limit of the system design.
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 - Large or Small
Events?
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.
Models in Root Cause Analysis
Models are representations of reality. They can be detailed or abstract, complex or
simple, accurate or misleading. Whether we realize it or not, everything we perceive
is processed using models. Therefore, it is important for us to understand how models
can help us to understand reality, yet may also mislead us if not used with appropriate
care and attention.
Models are used extensively in root cause analysis. Probably the most fundamental of
these is the model of causation. There are models based on manipulability,
probability, counterfactual logic, etc. This is an area of considerable complexity, as no
single model seems to address all possible situations.
The counterfactual logic model of causation is used most often in root cause analysis,
as it is the easiest to grasp and is generally the most useful. It is the model that gives
us the necessary and sufficient test, and for this alone, it's usefulness to the
investigator or analyst is boundless. However, even this model fails under certain
circumstances.
Consider the statement "smoking causes cancer" -- can this statement be proven (or
disproved) using the necessary and sufficient test? Not really. However, despite it's
difficulties in certain areas, the counterfactual logic model of causation is sufficient in
the overwhelming majority of cases. This is because it:




easily guides our thought processes in a predictable way,
provides rules that can be applied unambiguously and repeatably,
helps us ensure completeness in causal reasoning, and
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.
Analisa akar masalah dengan Why Why Analysis
(Riyantono Anwar. 2011. http://belajarlean.blogspot.com/2011/09/analisa-akar-masalahdengan-why-why.html)
Why why analysis (analisa kenapa kenapa) adalah suatu metode yang digunakan
dalam root cause analysis dalam rangka untuk problem solving yaitu mencari akar
suatu masalah atau penyebab dari defect supaya sampai ke akar penyebab masalah.
Istilah lain dari why why analysis adalah 5 whys analysis. Metoda root cause analysis
ini dikembangkan oleh pendiri Toyota Motor Corporation yaitu Sakichi Toyoda yang
menginginkan setiap individu dalam organisasi mulai level top management sampai
shopfloor memiliki skill problem solving dan mampu menjadi problem solver di area
masing-masing.
Metoda yang digunakan oleh why why analysis adalah dengan menggunakan iterasi
yaitu pertanyaan MENGAPA yang diulang beberapa kali sampai menemukan akar
masalahnya. Contohnya sebagai berikut:
Masalah: Mesin breakdown
1. Mengapa? Komponen automator tidak berfungsi
2. Mengapa tidak berfungsi? Usia komponen sudah melebihi batas lifetime 12
bulan
3. Mengapa tidak diganti? Tidak ada yang tahu
4. Mengapa tidak ada yang tahu? Tidak ada jadwal rutin maintenance
5. Mengapa tidak ada jadwal rutin? Inilah akar masalahnya
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
maintenance untuk melakukan penggantian komponen secara rutin. Apakah
hal tersebut paling masuk akal dalam menyebabkan dampak di level atasnya.
Apakah ada alternatif kemungkinan penyebab lainnya?
6. Pada umumnya solusi tidak mengarah pada menyalahkan ke orang tapi
bagaimana cara melakukan perbaikan sistem atau prosedur
7. Jika akar penyebab sudah diketahui maka segera implementasikan solusinya
Monitor terus performancenya untuk memastikan bahwa masalah tersebut tidak
terulang lagi.
FISHBONE DIAGRAM PERANGKAT
ALTERNATIF ANALISIS AKAR
MASALAH
Kini zaman globalisasi dan turbulensi dimana tergambarkan segala sesuatu yang
berhubungan dengan perilaku manusia dan antara manusia seakan tanpa batas. Dimana
sepanjang zaman hingga sekarang dan masa yang akan datang semakin cepat berubah.
Ungkapan Bung Karno mantan presiden RI dalam salah satu pidatonya “jika kita tidak
mengikuti perubahan maka kita adalah sejarah.”
Konteks tersebut di atas mengarahkan kita pada pemikiran bahwa adalah subjek dan objek
pada diri manusia. Hal ini bermakna bahwa manusia menciptakan perubahan dan perubahan
itu sendiri mengkreatur manusia itu sendiri. Demikian hal dengan pendidikan sebagai
apresiasi dari setiap perubahan manusia dan hal yang mampu mengubah manusia. Oleh
sebab itu tidak sedikit para ahli yang mengungkapkan bahwa sekolah sebagai wahana
pendidikan merupakan agen perubahan.
Satu hal yang patut dipikirkan adalah bahwa pendidikan pun demikian pada diri manusia.
Yaitu sebagai objek dan subjek dari perubahan manusia bahkan bisa mempercepat,
mengoptimalkan setiap perubahan itu sendiri. Pendidikan mampu mengubah manusia dan
manusia itu sendiri yang mampu mengubah pendidikan. Oleh sebab itu tidak sedikit kini
muncul berbagai paradigma baru dalam sistem pendidikan sebagai bukti nyata bahwa
pendidikan berubah seiring dengan perubahan manusia. Dan manusia pun berubah seiring
dengan perkembangan sistem pendidikan itu sendiri.
Di pihak lain, tidak bisa diragukan lagi bahwasanya manusia tak akan terlepas untuk
mengeksplorasi segala sumber daya yang dimilikinya. Dengan cara mencurahkan segala daya
dan kemampuanya untuk selalu berinovasi menemukan sesuatu yang baru yang dapat
membantu hidupnya menjadi lebih baik. Jika manusia tidak menggali segala kemampuanya
maka ia akan tertinggal bahkan tergerus oleh zaman yang selalu berkembang.
Dalam dunia pendidikan Inovasi adalah hal yang mutlak dilakukan karena tanpa inovasi akan
terjadi kemandekan pada dunia pendidikan yang kemudian berimbas pada pada elemenelemen kehidupan yang lain seperti politik, ekonomi, sosial dan lain-lain. Pertanyaan yang
terbentuk kini adalah realisasi prinsip dasar inovasi untuk pemecahan masalah atau
kebermaknaan inovasi itu sendiri. Hal ini berangkat dari bahwa segala macam proses
berawal dari perencanaan yang matang “if you fail to plan, you plan to fail” sehingga konteks
analisis akar masalah lebih kentara pada proses perencanaan inovasi demi memunculkan
solving, perubahan dan memunculkan inovasi. Meskipun menurut Su’ud (2010) tidak
selamanya inovasi adalah perubahan namun kita yakin perubahan merupakan bagian dari
inovasi.
Implementasi Fishbone Diagram (Prof. Kaoru Ishikawa) dalam Merencanakan
Inovasi Pendidikan
1. Merencanakan Inovasi Pendidikan
Berdasarkan pada 6 prinsip dasar inovasi pendidikan maka setidaknya kita tidak akan
semena-mena dalam merencanakan inovasi. Kembali ketitik awal bahwasanya proses
inovasi dapat bermula dari munculnya kesenjangan (GAP), ketidaksesuaian sehingga
diperlukan pembaharuan, perubahan atau tindakan korektif atau kebijakan baru yang
sifatnya inovatif, meskipun setiap perubahan belum berarti inovasi namun setiap
inovasi meski di dalamnya adalah perubahan. Singkatnya langkah langkah secara
global sebagai berikut di bawah ini:
1. Dokumentasi gap atau kesenjangan dan ketidaksesuaian (proses). Baik secara
kuantitatif maupun kualitatif. Hingga terbentuk prosses flowchart.
2. Identifikasi kebutuhan (demand) pelanggan dalam hal ini pengguna jasa
pendidikan.
3. Menganalisis gap dan kesenjangan dan ketidaksesuaian (analisa proses) tersebut.
4. Pengembangan tindakan korektif (root causes analysis)
5. Implementasi inovasi.
6. Validasi
Tahapan tersebut di atas menunjukkan bahwa root causes analysis memegang peranan
penting dalam menentukan kebijakan selanjutnya (korektif/pembaharuan/inovasi).
Gejolak, Penomena, Gap, Ketidak sesuian yang terjadi dalam proses pendidikan atau
berbagai permasalahan yang aktual baik teoritis maupun paraktis, baik dalam tatanan
makro maupun mikro, bahkan skup yang lebih kecil seperti permasalahan di dalam
kelas dijadikan sandaran dalam berinovasi di dunia pendidikan. Namun untuk
kebermaknaan suatu inovasi tetap harus mengusung prinsip-prinsip inovasi itu sendiri.
Untuk itu salah satunya, masalah yang diungkap haruslah terlebih dahulu dinalisis
(akar masalah) sehingga inovasi betul-betul berkenaan dan bermakna (mainfull).
Berikut di bawah ini adalah diagram framework dimana esensi analisis akar masalah
demi mewujudkan inovasi pendidikan yang penuh makna.
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).
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.
Gambar 2.3 Fishbone Diagram (Gasversz, 1997:113)
Pertanyaan Why? Bercabang hingga mencapai lima yang menggambarkan sub tulang
ikan itu sendiri. Dimana kategori utama Manusia, Pengukuran, Metode, Materia,
Mesin dan Lingkungan dapat diganti sesuai kebutuhan misalkan, dalam konteks
permasalahan penurunan kualitas lulusan bisa diganti dengan: Sarana Belajar, Orang
tua, Teman Sekolah, Kurikulum, Guru, Kepala Sekolah, Lingkungan Belajar, dll.
3. Implementasi Root Cause Analysis menggunakan Fishbone Diagram dalam
Perencanaan Inovasi Pendidikan
Penerapan atau implementasi Fishbone Diagram dalam analisis akar masalah dalam
berinovasi di bidang pendidikan, berikut di bawah ini langsung disajikan dalam
bentuk contoh root cause analysis dalam bidang pendidikan.
Contoh 1.
Masalah: Mengapa Kualitas Lulusan SDM Rendah?
Kategori Utama
Sebab 1 (Sb1): Guru/Dosen
Sebab 2 (Sb2): Siswa
Sebab 3 (Sb3): Masyarakat
Sebab 4 (Sb4): Kurikulum
Five Why
Why Sebab 1 Sebab 2 Sebab 3 Sebab 4
Guru Siswa Masyarakat Kurikulum
Why 1 Guru/Dosen kurang kompeten/tidak banyak belajar Siswa input (lulusan
sekolah sebelumnya) kurang berkualitas Masyarakat kurang peduli kualitas lulusan
siswa Kurikulum kurang tepat atau salah arah.
Why 2 Guru/Dosen mengajar ditempat lain atau sibuk mencari uang tambahan Unit
pemroses lembaga pendidikan sebelumnya berkualitas rendah (guru, fasilitas, dll)
Masyarakat sudah menganggap biasa atau terbiasa dengan KKN Ada kepentingan
tidak etis dalam penyusunannya
Why 3 Kesejahteraan kurang Anggaran APBN Rendah (BOS tidak normal)
Rekruitmen siswa dan SDM tidak bersih atau transaparan
Tidak ada akses kontrol untuk masyarakat atau pemerhati pendidikan
Why 4 APBN tidak mencukupi Pajak negara terserap sedikit Ada ketidak sesuaian
penerapan kebijakan Sistem demokrasi anomali yang sarat akan KKN
Why 5 Pajak banyak hilang korupsi merajalela (temuan...) Korupsi dan sadar
pendidikan moral rendah Korupsi dan sadar pendidikan moral rendah
Korupsi dan sadar pendidikan moral rendah
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
Sb3-5: Korupsi dan sadar pendidikan moral rendah
Sb4-1: Kurikulum kurang tepat atau salah arah
Sb4-2: Ada kepentingan tidak etis dalam penyusunannya
Sb4-3: Tidak ada akses kontrol untuk masyarakat atau pemerhati pendidikan
Sb4-4: Sistem demokrasi anomali yang sarat akan KKN
Sb4-5: Korupsi dan sadar pendidikan moral rendah
Gambar 2.4 Fishbone Diagram Rendahnya Kualitas SDM Indonesia
Pertimbangkan tentang kejujuran, konseptual yang kuat untuk mewujudkan jawabanjawaban, ”Mengapa?” sebanyak lima kali. Oleh sebab itu dianjurkan untuk
melaksanakan Brainstorming dengan kekuatan Tim, jadi lebih dari satu orang
pemikir. Dari contoh tersebut di atas, dapat diinterpretasikan bahwa akar masalah
adalah masalah perilaku negatif KKN terutama korupsi dan pendidikan moral yang
rendah sehingga untuk meningkatkan kualitas SDM kita adalah memberantas perilaku
KKN terutama korupsi melalui perbaikan pendidikan moral atau penegakan positif
moral apapun caranya (jalur pendidikan maupun supremasi hukum).
Contoh 2.
Masalah: Mengapa Siswa SMA Kesulitan Menyerap Pelajaran Kimia ?
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)
Sb4-1: Membutuhkan banyak praktek dan referensi
Sb4-2: Indikator atau tujuan terlalu luas dan banyak
Sb4-3: Materi yang harus disampaikan banyak
Sb4-4: Tuntutan lulusan untuk melanjutkan ke jenjang pendidikan yang lebih tinggi
Sb4-5: Perbaikan pendidikan untuk jenjang yang lebih tinggi.
Sb5-1: Referensi dan praktek kurang memadai
Sb5-2: Alat dan bahan serta buku sumber kurang memadai
Sb5-3: Keterbatasan dana
Sb5-4: Keterbatasan bantuan dana dari pemerintah dan komite sekolah
Sb5-5: Alokasi dana dari pemerintah dan siswa terbatas
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.
Perubahan zaman sekarang menjadikan perubahan dunia pendidikan yang semakin
kompleks permasalahannya dimana pendidikan sebagai sebuah sistem mangghasilkan
permasalahan dari subsistem-subsistem pendukungnya dari mulai tatanan kebijakan hingga
empris praktis, baik dari level makro hingga mikro. Hal ini mampu mengaburkan inti
permasalahan sehingga diperlukan analisis akar masalah untuk menghasilkan tindakan
korektif, pembaharuan bahkan inovasi baik discovery maupun invention.
Root Causes Analysis melalui perangkat Fishbone Diagram (Diagram Ishikawa). Membantu
inovator untuk menginventarisir, menghindari keragaman masalah dan menemukan akar
masalah untuk berinovasi, sehingga inovasi itu sendiri manifull (sangat bermakna).
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.
Su’ud, Udin Syaefudin. 2010. Inovasi Pendidikan. Bandung: Alfabeta.