My father-in-law owns a farm in Preston, Idaho (famous for the film, “Napoleon Dynamite”). There is a small creek (pronounced “crick” in Preston) that intersects the property and feeds a small pond in the center of the property. The story is sometimes told of when the pond had to be drained.
It seems there was some obstruction to the pond effluent. The pond had a small concrete dam with a steel plate flood gate. The flood gate was opened and the pond drained so the obstruction could be removed. As the pond drained, an old rusty Model A Ford began to appear. Once the water level passed the Ford, and as the pond continued to drain, an old refrigerator was seen. After the pond was completely drained, the Ford, refrigerator and other junk in the bottom of the pond were chained to the tractor and pulled out. The pond was then refilled.
Not long ago, I got the opportunity to drain the pond at work. I was assigned an investigation, the purpose of which was to find why we were not able to correctly account for some units of very expensive product. As I pursued the investigation, it was discovered that the operators had just a few seconds to count over one hundred units of product and that this was done about every 2-3 minutes. The counter measure was to create a template, that would be placed over a tray (or case) of units, to see if they looked correct. Voila! Problem solved.
What?! But, wait a minute! You say that there is still a problem with the accountability? Yep, you guessed it. I was assigned another investigation for the same thing not long after the first investigation. So I dug a little deeper this time. The data I analyzed showed that the templates for counting the units of product worked well on the large units, but because the small units were in presentations of nearly 600 units, it was difficult for operators to tell if the count was correct or not. Hence, the potential for an erroneous count was still there. The counter measure implemented at that point was the introduction of an automated visions system that would use a computer and camera to do the counting, taking out the potential for Human Error. Finally! Glad that’s over.
Hold on now! I just got done fixing this problem. It can’t still be happening, can it? Another investigation assigned for the same thing, yet a few weeks later. When will the bleeding stop? In this investigation, I learned there was a new step in the process for additional testing to ensure oxygen content of the product was less than 1%. Final unit accountability of the product was completed before this step was executed. The problem was that a failed unit would be rejected, thus changing the count. This was not accounted for in the planning phase for implementation of this new step in the process; fixed yet again.
Process improvement is often referred to as Draining The Pond. It is the process of looking for incremental improvement rather than betting on big step changes. As you improve productivity through process improvement, you find other opportunities for improvement. The beauty of Fault Tree Analysis, is that you can capture several gaps in the process – junk in the pond – simultaneously by creating a visual of all the hypothetical gaps.
When I was doing these investigations, I was not disciplined in using Fault Tree Analysis in this way, but it would have helped prevent the non-value added activity of doing multiple investigations for the same issue. That is not to say that Fault Tree Analysis will be the end all, be all for any issue. I have been involved in investigations that used Fault Tree Analysis, which did not capture all the potential gaps for the Loss Event. However, capturing more gaps in an investigation, rather than fewer, is a more efficient way of…
Draining The Pond.
Showing posts with label Loss Events. Show all posts
Showing posts with label Loss Events. Show all posts
Wednesday, December 16, 2009
Friday, December 11, 2009
A Writer Writes!
I have a favorite movie. It is a dark comedy starring Billy Crystal, who plays Larry, a bitter and frustrated would be author, teaching creative writing at the local community college. The movie is a hilarious dark comedy, but that's not the point of this post! At the end of each class session portrayed in the film, Larry finishes his class session by stating to his students, "A writer writes!"
I am currently in the process of studying a book. I say studying because at first I just read it. The book is entitled, "How To Run Seminars & Workshops," (Robert L. Jolles, Wiley, ISBN 0471715875). There is a section on writing, which states, "Planning to write is not writing. Thinking about writing is not writing. Talking about writing is not writing. Researching to write, outlining to write - none of this is writing. Writing is writing."
So now I have two paragraphs in this post about writing. Why, one might suppose, is that? Well here it is: You can execute an Investigation. You can do it using Fault Tree Analysis or some other methodology. You can identify Root Cause and the appropriate Actions to mitigate the Loss Event and prevent it's recurrence. You can involve SMEs and your Investigative Team members. At the end of the day, you will have to document your findings. For many people, this is sometimes the worst possible aspect of an investigation, made more so when the summary requires approval from various parties, each of whom has their own opinion as to style and grammer, and which can reject your summary for tawdry edits that often don't make sense.
There are a million reasons why we don't like to write. However, at the end of the day, if we do not write at one point or another, the investigation is incomplete. In order to truly complete the investigation, it needs to be "wrapped up in a bow," through documenting (read as "writing") the investigation.
Lead Investigators, or at least a member of the Investigative Team, is typically a writer. And the Root Cause Analysis, must be documented and summarized so a record exists for review in the future. If for nothing else, to enable prevention of the same issues in the future. You may not feel like your documentation is up to par, and perhaps it is not. At least not now. But the more you write, the better you get at writing.
Over the course of a 26 month period, I documented 115 Investigations, all requiring full Root Cause Analysis. Many suggest that I am an expert. However, I contend, if that is the case, it is only through the continued practice that took place from writing so many investigative summaries in so short a period of time. Anyone can develop this skill set if they have a mind to. It's not difficult, although you have to toughen up your hide and accept feedback from time to time. But this is no problem if you truly wish to excel. The key thing to remember is...
A writer writes!
I am currently in the process of studying a book. I say studying because at first I just read it. The book is entitled, "How To Run Seminars & Workshops," (Robert L. Jolles, Wiley, ISBN 0471715875). There is a section on writing, which states, "Planning to write is not writing. Thinking about writing is not writing. Talking about writing is not writing. Researching to write, outlining to write - none of this is writing. Writing is writing."
So now I have two paragraphs in this post about writing. Why, one might suppose, is that? Well here it is: You can execute an Investigation. You can do it using Fault Tree Analysis or some other methodology. You can identify Root Cause and the appropriate Actions to mitigate the Loss Event and prevent it's recurrence. You can involve SMEs and your Investigative Team members. At the end of the day, you will have to document your findings. For many people, this is sometimes the worst possible aspect of an investigation, made more so when the summary requires approval from various parties, each of whom has their own opinion as to style and grammer, and which can reject your summary for tawdry edits that often don't make sense.
There are a million reasons why we don't like to write. However, at the end of the day, if we do not write at one point or another, the investigation is incomplete. In order to truly complete the investigation, it needs to be "wrapped up in a bow," through documenting (read as "writing") the investigation.
Lead Investigators, or at least a member of the Investigative Team, is typically a writer. And the Root Cause Analysis, must be documented and summarized so a record exists for review in the future. If for nothing else, to enable prevention of the same issues in the future. You may not feel like your documentation is up to par, and perhaps it is not. At least not now. But the more you write, the better you get at writing.
Over the course of a 26 month period, I documented 115 Investigations, all requiring full Root Cause Analysis. Many suggest that I am an expert. However, I contend, if that is the case, it is only through the continued practice that took place from writing so many investigative summaries in so short a period of time. Anyone can develop this skill set if they have a mind to. It's not difficult, although you have to toughen up your hide and accept feedback from time to time. But this is no problem if you truly wish to excel. The key thing to remember is...
A writer writes!
Wednesday, December 9, 2009
Could You Please Show Me Your ID?
The organization I work for requires an ID card to enter the network of buildings that make up our campus. I am a person of routine. My wife often refers to it as OCD, but I prefer to think of it as routine. To some degree, we are creatures of habit.
At any rate, on this particular morning, my commuter vehicle was in the garage for maintenance, so I had to drive another vehicle. I forgot to transfer my parking pass from the commuter vehicle to the one I was temporarily using. I had to stop at the front gate and ask for a temporary parking pass.
"Could you please show me your ID?" the security guard politely asked.
"Sure, hang on a minute," was my reply as I started digging my wallet out of my back pocket. No sooner had begun search for my wallet, that I became painfully aware that my morning routine had somehow been disrupted and I had left my wallet on my dresser. I commute an hour each way and I plead with the guard, now somewhat suspicious, that I for me to run back home for my wallet, would constitute and additional two hours of drive time for me, and two hours of lost productivity for the organization.
Suspicion had evolved to impatient indifference and I was waved on to the security desk at the main entrance. Once I got there, it took nearly an hour to get through all the red tape that would allow me to get to my desk and grind out value for the organization. But I made it. Finally.
What does this have to do with investigations? As you build your Fault Tree Analysis, you need to give each hypothetical cause in your growing tree a value. This value is called a Fault ID. The Fault ID helps investigative team members, approvers and stakeholders understand the relationships of the various faults hypothesized to be potential root cause, as well as potential relationships they may have one with another.
Top line, or First Order hypotheses have a value represented as a whole number beginning with zero or one and progressing from there. Secondary or Second Order hypotheses have a decimal value of one place, such that any hypothesis subordinate to a First Order hypothesis would be as 1.1 for the first hypothesis, 1.2 for the second and so on. Tertiary, or Third Order hypotheses are separated by decimal as a delimeter and follow the same convention as the Second Order hypotheses. In other words, Fault ID subordinate hypotheses to Fault ID 1.1 above, would be 1.1.1, for the first tertiary hypothesis, 1.1.2 for the second tertiary hypothesis, and so forth. This convention is true also for Quaternary and Quinary subordinate hypotheses.
For an example of a partial Fault Tree showing Fault IDs, look at the image below.
When you think of order of magnitude, as you build your Fault Tree, it can become very large and quite cumbersome. This is where the Fault IDs of the various hypotheses becomes most important. Keeping track of these hypotheses, and seeing the potential Interactions that exist are key a successful investigation. Particularly if it is a large scale investigation.
The Fault ID has additional value I'll save for a later post. The point of this post is to explain what, exactly, a Fault ID is and how it is used. Below, you can see an image of what a Fault ID looks like. Just remember that when you are building your Fault Tree Analysis, someone interested in your investigation, perhaps an Investigative Team member, a Stakeholder or an Approver, may ask you...
Could you please show me your ID?
At any rate, on this particular morning, my commuter vehicle was in the garage for maintenance, so I had to drive another vehicle. I forgot to transfer my parking pass from the commuter vehicle to the one I was temporarily using. I had to stop at the front gate and ask for a temporary parking pass.
"Could you please show me your ID?" the security guard politely asked.
"Sure, hang on a minute," was my reply as I started digging my wallet out of my back pocket. No sooner had begun search for my wallet, that I became painfully aware that my morning routine had somehow been disrupted and I had left my wallet on my dresser. I commute an hour each way and I plead with the guard, now somewhat suspicious, that I for me to run back home for my wallet, would constitute and additional two hours of drive time for me, and two hours of lost productivity for the organization.
Suspicion had evolved to impatient indifference and I was waved on to the security desk at the main entrance. Once I got there, it took nearly an hour to get through all the red tape that would allow me to get to my desk and grind out value for the organization. But I made it. Finally.
What does this have to do with investigations? As you build your Fault Tree Analysis, you need to give each hypothetical cause in your growing tree a value. This value is called a Fault ID. The Fault ID helps investigative team members, approvers and stakeholders understand the relationships of the various faults hypothesized to be potential root cause, as well as potential relationships they may have one with another.
Top line, or First Order hypotheses have a value represented as a whole number beginning with zero or one and progressing from there. Secondary or Second Order hypotheses have a decimal value of one place, such that any hypothesis subordinate to a First Order hypothesis would be as 1.1 for the first hypothesis, 1.2 for the second and so on. Tertiary, or Third Order hypotheses are separated by decimal as a delimeter and follow the same convention as the Second Order hypotheses. In other words, Fault ID subordinate hypotheses to Fault ID 1.1 above, would be 1.1.1, for the first tertiary hypothesis, 1.1.2 for the second tertiary hypothesis, and so forth. This convention is true also for Quaternary and Quinary subordinate hypotheses.
For an example of a partial Fault Tree showing Fault IDs, look at the image below.
When you think of order of magnitude, as you build your Fault Tree, it can become very large and quite cumbersome. This is where the Fault IDs of the various hypotheses becomes most important. Keeping track of these hypotheses, and seeing the potential Interactions that exist are key a successful investigation. Particularly if it is a large scale investigation.
The Fault ID has additional value I'll save for a later post. The point of this post is to explain what, exactly, a Fault ID is and how it is used. Below, you can see an image of what a Fault ID looks like. Just remember that when you are building your Fault Tree Analysis, someone interested in your investigation, perhaps an Investigative Team member, a Stakeholder or an Approver, may ask you...
Could you please show me your ID?
Monday, December 7, 2009
Were You Entitled, or Was The Title Won?
NOTE: The title of this post is also a link to the article referenced within the post.
I recently received a post (see link above) regarding "Learned Helplessness", which is defined as "where people 'learned to behave helplessly, even when the opportunity is restored for them to help them self by avoiding an unpleasant or harmful circumstance.'" Unfortunately, I see "Learned Helplessness" too much in business and community. I believe our culture has evolved from the independent self-sufficiency exemplified by the puritanical contingent of our country's forefathers, to a culture of entitlement (read as "helpless").
I work with and teach others to take ownership for who they are and the results of their actions. This is often times difficult when people have been entitled too long, but told they are performing well (read as "vanilla" not "balanced" feedback) in spite of the evidence of their labors. I have a 2X2 Capability Awareness matrix I use to help illustrate the entitlement mindset. It is sometimes difficult for people to accept, but once they do, they are on the road to recovery.
Ultimately, the fundamental flaws of our economy right now are evidence of this mentality. Unfortunately, it does not just evidence itself with the "less fortunate." Learned Helplessness is often enabled in the executive suites, by group think, or what I like to refer to as Cognitive Myopathy. At other times it is enabled by lack of integrity and professional courage.
In short, Learned Helplessness has pervaded every facet of our society in pandemic proportions. Sounds pessimistic doesn't it? I, however, am an optimist. I believe that armed with the correct knowledge, delivered by those with the professional courage to render the appropriate balanced feedback, that most people will want to do the right thing and to feel good about, rather than justify themselves. Given this assumption, I believe also that ours is not a hopeless state. As stated in my prior post, good investigators are generally also good leaders. They have to leverage leadership to gather, assimilate, collate and make sense of all the data that exists around the Loss Event and then identify and develop Actions for the Root Cause. If you are doing investigations, and not exemplifying the characteristics of a good leader, you are in danger of a less than complete investigation. In order to accomplish a good investigation, you have to work at leadership, and as such, solicit the help and support of other. An attitude of Entitlement or Helplessness, will only scare of the support you need to be successful.
So when you are done with the investigation, ask yourself...Were you entitled, or was the title won?
I recently received a post (see link above) regarding "Learned Helplessness", which is defined as "where people 'learned to behave helplessly, even when the opportunity is restored for them to help them self by avoiding an unpleasant or harmful circumstance.'" Unfortunately, I see "Learned Helplessness" too much in business and community. I believe our culture has evolved from the independent self-sufficiency exemplified by the puritanical contingent of our country's forefathers, to a culture of entitlement (read as "helpless").
I work with and teach others to take ownership for who they are and the results of their actions. This is often times difficult when people have been entitled too long, but told they are performing well (read as "vanilla" not "balanced" feedback) in spite of the evidence of their labors. I have a 2X2 Capability Awareness matrix I use to help illustrate the entitlement mindset. It is sometimes difficult for people to accept, but once they do, they are on the road to recovery.
Ultimately, the fundamental flaws of our economy right now are evidence of this mentality. Unfortunately, it does not just evidence itself with the "less fortunate." Learned Helplessness is often enabled in the executive suites, by group think, or what I like to refer to as Cognitive Myopathy. At other times it is enabled by lack of integrity and professional courage.
In short, Learned Helplessness has pervaded every facet of our society in pandemic proportions. Sounds pessimistic doesn't it? I, however, am an optimist. I believe that armed with the correct knowledge, delivered by those with the professional courage to render the appropriate balanced feedback, that most people will want to do the right thing and to feel good about, rather than justify themselves. Given this assumption, I believe also that ours is not a hopeless state. As stated in my prior post, good investigators are generally also good leaders. They have to leverage leadership to gather, assimilate, collate and make sense of all the data that exists around the Loss Event and then identify and develop Actions for the Root Cause. If you are doing investigations, and not exemplifying the characteristics of a good leader, you are in danger of a less than complete investigation. In order to accomplish a good investigation, you have to work at leadership, and as such, solicit the help and support of other. An attitude of Entitlement or Helplessness, will only scare of the support you need to be successful.
So when you are done with the investigation, ask yourself...Were you entitled, or was the title won?
Friday, November 6, 2009
Descend To The Lowest Level You Can!
How often have you overheard a conversation and heard the phrase, "I don't think they can get much lower than that." Usually, this is about someone in particular and their perceived behaviors. The statement generally has a negative connotation.
How about the sometimes wildly entertaining Caribbean dance, the Limbo? The object is for participants to dance under a bar or pole, that is lowered through successive turns of the participants. When a participant falls, they are eliminated from the dance, until the dancer who can go the lowest remains. The thought is, how low can you go?
When doing an investigation, you want to get to the lowest level you can. You want to peel away the layers of circumstances that will get you to the root cause. This is often done using "Cause of the Cause" or "5 Why Analysis". Fault Tree Analysis is a disciplined approach to these processes. Essentially, you want to go as low as you can go. You want to descend the lowest level possible.
Each hypothetical cause has one or more hypothetical causes subordinate to it. Eventually, you will get to a point where you have exhausted all reasonable possibilities. Typically, you will find that there are usually no more than five levels of "Why" or hypothetical causes. Evaluation of these hypothetical causes then lends you some measure of confidence as to whether they were truly contributory to the Loss Event. The key, however, is to go to the bottom, get to the root of the Fault Tree, or the Root Cause.
When pursuing your investigation, it is important to remember...
Descend to the lowest level you can!
How about the sometimes wildly entertaining Caribbean dance, the Limbo? The object is for participants to dance under a bar or pole, that is lowered through successive turns of the participants. When a participant falls, they are eliminated from the dance, until the dancer who can go the lowest remains. The thought is, how low can you go?
When doing an investigation, you want to get to the lowest level you can. You want to peel away the layers of circumstances that will get you to the root cause. This is often done using "Cause of the Cause" or "5 Why Analysis". Fault Tree Analysis is a disciplined approach to these processes. Essentially, you want to go as low as you can go. You want to descend the lowest level possible.
Each hypothetical cause has one or more hypothetical causes subordinate to it. Eventually, you will get to a point where you have exhausted all reasonable possibilities. Typically, you will find that there are usually no more than five levels of "Why" or hypothetical causes. Evaluation of these hypothetical causes then lends you some measure of confidence as to whether they were truly contributory to the Loss Event. The key, however, is to go to the bottom, get to the root of the Fault Tree, or the Root Cause.
When pursuing your investigation, it is important to remember...
Descend to the lowest level you can!
Wednesday, November 4, 2009
To Be or Not To Be...
Hypotheses are interesting things. They are, or they are not. There is no middle ground. Now on the other hand, you may have some measure of confidence (which we will discuss in a later post) as to whether the hypothesis is, or is not. When pursuing an investigation, you are inundated with hypotheses.
What are hypotheses, relative to an investigation? Well, once you know what the Loss Event is, you have to hypothesize different scenarios that might have caused the loss event. Some of those hypotheses will be the result of data that you collect immediately after the event and when you build your time line. Others will be what if's based on SME knowledge of the process surrounding the Loss Event. Others still, will be subordinate to the first level hypotheses. In other words, cause of the cause.
Ultimately, what you wind up with is a Fault Tree of hypotheses. You will begin collecting data that will enable you to prove your hypotheses with some measure of confidence. As you work through all the hypotheses in your fault tree, you will eventually begin to discern either Root Cause, or one or more interactions leading to the Loss Event. In the end, a Fault Tree is a grouping of hypotheses either related and/or subordinate to one another, and which lead to the Loss Event.
With respect to the truth of any hypothesis found on a Fault Tree:
To be or not to be...
That is the question!
What are hypotheses, relative to an investigation? Well, once you know what the Loss Event is, you have to hypothesize different scenarios that might have caused the loss event. Some of those hypotheses will be the result of data that you collect immediately after the event and when you build your time line. Others will be what if's based on SME knowledge of the process surrounding the Loss Event. Others still, will be subordinate to the first level hypotheses. In other words, cause of the cause.
Ultimately, what you wind up with is a Fault Tree of hypotheses. You will begin collecting data that will enable you to prove your hypotheses with some measure of confidence. As you work through all the hypotheses in your fault tree, you will eventually begin to discern either Root Cause, or one or more interactions leading to the Loss Event. In the end, a Fault Tree is a grouping of hypotheses either related and/or subordinate to one another, and which lead to the Loss Event.
With respect to the truth of any hypothesis found on a Fault Tree:
To be or not to be...
That is the question!
Monday, November 2, 2009
Do It, Do It Right, Do It Right Now!
Last week I had a posting called, "Just Do It!" after the Nike slogan, used so often in their advertising. Before, "Just Do It!" was even considered by Nike, I was serving a mission for my church in the late 70's. One of our church leaders had a placard on his desk which said, "Do it, Do it right, Do it right now!" Everyone knew that this was his credo and we made it ours. It has since stuck with me.
So what does the mantra, "Do it, Do it right, Do it right now!" have to do with investigations? The following are my thoughts on the matter:
When you are faced with the challenges and choices of life, in your work or otherwise, as an investigator, just remember...
Do it, Do it Right, Do it right now!
So what does the mantra, "Do it, Do it right, Do it right now!" have to do with investigations? The following are my thoughts on the matter:
- Do It: This simply means "Take Action." If no action is taken, nothing gets done. A Loss Event has occurred. You are aware of it, or previously unaware of the Loss Event, it has been assigned to you for investigation. Take Action. Begin the investigation. Understand the events surrounding the Loss Event and use that understanding to determine Root Cause. The point is, that unless you "Do It," nothing will ever be resolved. No Root Cause will be found.
- Do It Right: When taking action, during the course of your investigation, be sure you are taking the right action. Question everything. Require the appropriate data to support or disclaim all your hypotheses. Talk to the SME's and SMI's, both. Don't be afraid to challenge. Don't be afraid to be challenged. Gather all the data and information you can. Organize it, codify it and prepare it for review and/or approval. Most of all, be sure your Corrective Actions are appropriate and sound and prevent future Loss Events of like kind.
- Do It Right Now: There is a sense of urgency in business. Any business. The business of work, the business of community, the business of family, all require some sense of urgency to resolve issues and resolve them quickly. Understanding this as investigators, we should take action and we should take the right action. However, waiting does not help at all, we need to take action now! The sooner we take action, the sooner resolution will take place, the sooner we improve whatever process we are investigating, and the sooner we reap the benefits of such.
When you are faced with the challenges and choices of life, in your work or otherwise, as an investigator, just remember...
Do it, Do it Right, Do it right now!
Friday, October 23, 2009
Johnny Appleseed and Fault Tree Analysis
As a child in the sixties (as opposed to a child of the sixties, if you know what I mean), I learned about an American folk hero, part legend, part reality, named Johnny Appleseed. He would travel the frontier, what we now call the Midwest, planting apple trees. Little did I know, that later in my adult life, I would venture to and settle down in, the literal stomping ground of this icon of American folk lore.
Born John Chapman, Johnny Appleseed was an American pioneer nurseryman who introduced apple trees to large parts of Ohio, Indiana, and Illinois. He became an American legend while still alive, largely because of his kind and generous ways, his great leadership in conservation, and the symbolic importance of apples.
What does Johnny Appleseed have to do with Fault Tree Analysis? Well, I thought you would never ask. And if you didn't, I'm going to tell you anyway! Johnny planted apple seeds and they grew up into trees. As investigators, we get loss events planted on us, but that's OK, cause that's what we do. Our Fault Trees grow down into trees, much like a root system.
Hmmm....
Perhaps Johnny Appleseed could have benefited from using Fault Tree Analysis to determine why apple trees and conservation were lacking in the Midwest at the time, rather than plodding around the country side.
Just a thought.
Born John Chapman, Johnny Appleseed was an American pioneer nurseryman who introduced apple trees to large parts of Ohio, Indiana, and Illinois. He became an American legend while still alive, largely because of his kind and generous ways, his great leadership in conservation, and the symbolic importance of apples.
What does Johnny Appleseed have to do with Fault Tree Analysis? Well, I thought you would never ask. And if you didn't, I'm going to tell you anyway! Johnny planted apple seeds and they grew up into trees. As investigators, we get loss events planted on us, but that's OK, cause that's what we do. Our Fault Trees grow down into trees, much like a root system.
- You start with the Loss Event.
- From the Loss Event, you identify Causal Factors. These may be locations in a value chain, or activities on a time line. Either way, Causal Factors are high level hypotheses as to the occurrence of the Loss Event.
- From the Causal Factors, you identify the Root Cause Categories. These are hypotheses subordinate to each of the Causal Factors. You can begin to see how this tree grows.
- From Root Cause Categories, you then have your Near Root Cause(s), which are further hypotheses as to the Loss Event, subordinate to the Root Cause Categories. Now you're really drilling down.
- Finally, from the Near Root Cause(s), you derive Root Cause(s). These are subordinate, still, to the Near Root Cause(s). They are still hypothetical, until validated otherwise through qualitative and/or quantitative data. (This process is the Verification Log, which I will discuss in another post.)
Hmmm....
Perhaps Johnny Appleseed could have benefited from using Fault Tree Analysis to determine why apple trees and conservation were lacking in the Midwest at the time, rather than plodding around the country side.
Just a thought.
Sunday, October 11, 2009
Loss Events & Losers
Nobody wants to be a loser. In order to not be a loser, an organization must understand what a Loss Event is. Understanding what a Loss Event is, will enable the organization to investigate the cause of the Loss Event, identify Root Cause, and the appropriate Action or Counter Measure(s) to correct the Root Cause. However, before any of this can happen, the organization must understand what a Loss Event is.
Simply put, a Loss Event, is where something is lost in the process of doing business. I don't necessarily mean the type of loss that would prompt you to go to the lost and found. Rather, the loss is typically measurable in monetary terms, for most businesses. Losses can be the dollar value of down time, defects, a safety incident; you can think of as many examples as there are companies in operation.
The problem is, that any loss event represents lost revenue to the organization. If the loss event is down time, then you have the cost of not producing product, the cost of replacing equipment that was damaged or in disrepair, the cost of labor during the downtime, etc. If the loss event is defects, then you might have the the cost of rework, lost opportunity cost if you cannot rework and have to scrap, cost of equipment or line time to do the rework, cost of overtime to execute the rework or manufacture replacement product, etc. If the loss event is a safety incident, you can follow nearly all the same paths for the cost involved, but you might have some different costs such as doctor's visits, workers compensation, etc.
The point is, that a loss event, in the simplest terms a business can understand, is the erosion of revenue and/or profits. In order to understand the cause of the loss events, organizations will employ formal Root Cause Analysis (RCA). I personally like to use a Fault Tree when doing RCA. Using RCA methodologies will drive the investigator to Root Cause. Knowing Root Cause will enable the appropriate Actions or Counter Measures. The appropriate Actions or Counter Measures will prevent the Loss Event from occurring again. Prevention of another, similar Loss Event provides an incremental increase in the revenue and profits of the organization.
Organizations that have not figured this out, or choose to ignore Loss Events, are Losers, (fiscally of course!)
Simply put, a Loss Event, is where something is lost in the process of doing business. I don't necessarily mean the type of loss that would prompt you to go to the lost and found. Rather, the loss is typically measurable in monetary terms, for most businesses. Losses can be the dollar value of down time, defects, a safety incident; you can think of as many examples as there are companies in operation.
The problem is, that any loss event represents lost revenue to the organization. If the loss event is down time, then you have the cost of not producing product, the cost of replacing equipment that was damaged or in disrepair, the cost of labor during the downtime, etc. If the loss event is defects, then you might have the the cost of rework, lost opportunity cost if you cannot rework and have to scrap, cost of equipment or line time to do the rework, cost of overtime to execute the rework or manufacture replacement product, etc. If the loss event is a safety incident, you can follow nearly all the same paths for the cost involved, but you might have some different costs such as doctor's visits, workers compensation, etc.
The point is, that a loss event, in the simplest terms a business can understand, is the erosion of revenue and/or profits. In order to understand the cause of the loss events, organizations will employ formal Root Cause Analysis (RCA). I personally like to use a Fault Tree when doing RCA. Using RCA methodologies will drive the investigator to Root Cause. Knowing Root Cause will enable the appropriate Actions or Counter Measures. The appropriate Actions or Counter Measures will prevent the Loss Event from occurring again. Prevention of another, similar Loss Event provides an incremental increase in the revenue and profits of the organization.
Organizations that have not figured this out, or choose to ignore Loss Events, are Losers, (fiscally of course!)
Subscribe to:
Posts (Atom)