|
Root Cause Analysis - Lessons Learned |
|---|
 |
| REASON® Lessons Learned __________ __________ |
Lessons Learned and REASON® "Lessons Learned" as it would apply as a part of a REASON® implementation. The REASON® Root Cause Analysis process organizes data in a uniform way. This "ordering" of data allows a REASON "Lessons Learned" program to be extremely accurate and powerful. Everyone who has searched for something on the Internet knows that if you search for anything in a large database ---you get thousands of "hits". Often, only a small portion of these "hits" are even loosely associated with the information you were seeking. A simple search within a database is what constitutes most Lessons Learned systems worldwide. Again, anyone who searches on the Internet knows the results of these methods are often not relevant to your search. As an organization’s knowledge base grows, people with increased frequency are forced to look at irrelevant information…wasting time. This dynamic grows in an organization until it stops the in-flow of information into the system. Simply put---when people realize that they can not get useful or relevant information out of a knowledge base quickly...they stop putting it in and they stop using it. REASON® works differently. A REASON® search is much more accurate than any other Lessons Learned/ Knowledge-base searching method available. Due to the fact that the data is ordered upon its entry into the system, REASON's Lessons Learned system can look for interaction between key word search factors. The main obstacle for any knowledge base is the availability of meaningful information to those who need it. Only REASON® organizes the data in real-time with entry into the system. REASON® is not merely looking for the presence of key words in a document. REASON's Lessons Learned system is looking for actual interaction between the key words relevant to a current investigation. The end result is a knowledge base searching system that is by far more accurate than any other method. It gives those who seek it...ready access to relevant information. Simply put…only REASON "orders" data as part of its very process. "Ordered" information is searchable information. The better the information is organized the more able you are to accurately search for relevant information. REASON is the only system that takes advantage of "ordered-data" in a Lessons Learned system. This is the key to REASON's performance superiority. To Executive Management:Certainly, most of us can agree on the wisdom of learning from past mistakes. When an organization reaches the point where a Lessons Learned program is being planned and budgeted, the manager has several important responsibilities. He understands the full significance of implementing a system upon which critical decisions will be based. This brief is intended to provide background information that will assist managers during the planning stages for design and implementation of a computerized Lessons Learned system. From an executive management perspective, there can be only one criterion for assessing value from a Lessons Learned program. The system can be measured for value only on the basis of the unique prevention benefits it provides to the organization. Lessons Learned is not just an additional source of rules, or instruction booklets, or TQM/Safety meetings, or special bulletins and newsletters. The users of a Lessons Learned system are the employees, supervisors and managers on the job who have an immediate need for specific information to plan and accomplish their daily tasks. When a problem on the job occurs, they need the information on how to deal with the situation now, if their chances for mistake and injury are to be reduced. This is the prevention role that Lessons Learned should fill. Before the advent of REASON, major organizations established Lessons Learned programs. While the administrators of the programs spoke of the success of the system, the users of the system did not give the program high marks. They complained, "The Lessons never seem to apply to me" and "There is too much information to keep up with". To today's executive managers who are responsible for the investment in Lessons Learned, these complaints carry important messages. They tell us that conventional Lessons Learned approaches do not adequately target data to the user's needs. Why not? One reason is rooted in the way in which some conceptualize what a Lessons Learned System is. If those who establish and maintain the system, perceive it to be origin driven, rather than user driven, they may believe that success of the program can be measured by how many users receive their prepared, packaged and distributed stories with a lesson. There is no way to reconcile this definition of success with the comments from users. This is one of those areas of concern where an informed executive manager can provide the vision and set the criteria for success. The answer to establishing a cost-effective and successful program is to conceptualize Lessons Learned as a system designed to facilitate access to a relational data base of situational data. Situational data record a counter-quality problem as a series of causal interactions occurring within the organization. Instead of a collection of lengthy reports, the system holds electronic memories and models of the exact processes and interactions that produced the problems in the past. Now our vision of how the system works changes dramatically. There are new criteria and new expectations. In this vision, users contribute to the data resource every time they solve one of their own problems. There is no longer a labor intensive process just to get the data into the system. Now the data will not only provide a traditional report of the individual occurrences and recommended solutions, but will also provide the user with the ability to visit and explore the data in order to find relevant lessons quickly. There will be a growing volume of resource data to broadly represent the base of experience of the organization. There will be no artificial boundaries around the data. The resource will be accessible and responsive to the immediate needs of the user. Is such capability really possible? Yes it is; but even today there can be obstacles if old approaches or inappropriate methods are chosen. In the past the obstacles were the ponderous authoring and publishing processes that made timely lessons impossible. Now in today's world the problem can be too much information . . . or more correctly, too much information in the wrong form. If we understand how these unnecessary obstacles can be avoided, rapid and cost-effective implementation of a successful Lessons Learned system is possible. Planners and designers need to understand that conventional methods of accessing computerized data cannot accommodate high volumes of resource data without overloading the users. Finding The LessonsKey word searches, upon which computerized Lessons Learned systems have relied, provide fast access to records, but create an obstacle to usage by producing volumes of lengthy reports. When these conventional word searches are employed in the design of the system, the word searches may identify information vital to the user, but to find the information the user has to read through all of the reports located by the search in the hope that one of them will relate to his circumstances. Often this task will take hours. The screening effort required of the user is a disincentive to use the system. REASON solves the user's dilemma by providing 1) a data targeting method that provides a significantly smaller target, and 2) a means to significantly reduce the data screening process for the user. 1. Smaller Target:
Document SearchTraditional word searches set their sights upon the whole document as the target. If
the words appear anywhere in the document, it is listed as a "hit". Even if the
document says, "This report is definitely not about "chlorinated solvents",
a search for the words "Chlorinated" and "Solvent" will
find that report, and require the client to read it before he knows that it contains no
help for him. Direct InteractionInstead of using the entire report document as a target for the word search, REASON's
situational data narrows the search to only the causal interactions within the causal
process itself. For example, in a REASON situational data search, if the user searches for
the words "Chlorinated" and "Solvent" the files found on
the first-pass search will be only those in which the factors causally interacted
directly. Because the target is defined to key upon direct interaction of causes, REASON
searches successfully weed out irrelevant cases that are often accepted by conventional
word searches. Smaller yields with richer content result. Indirect InteractionWhen no case is found, the search continues to the next most proximate interaction. The
size of the target is progressively increased by one level at a time until a
"hit" occurs. While A and B do not interact directly, they are causally
associated within the process. As you can see, the worst case hit possible with the
REASON situational data search provides a better understanding of the interactive process
than the best case hit possible with traditional word searches. 2. Data Screening:Narrowing the search target produces better and fewer files to screen for information; that eliminates one of the obstacles. Now, let's see how REASON deals with the other. When the user views the cases found during his situational data search, the REASON Lessons Learned system writes a brief narrative abstract that is based upon the point of view of the user. The key words identify the points of interest to the user. The software knows where the key causes are located in the model; so it can write a story line that describes the chain of events that led to the problem. The abstract concentrates upon the concerns of the user, while masking the other areas in the model. If the abstract seems relevant to the user's situation on the job, he can request more details. All of the REASON data is scaleable to the user's level of interest, from abstract to full details, including the tree model of the problem, a full narrative, and a complete analysis. This feature provides a highly selective method that significantly reduces to only a few moments the time required for data screening of cases. REASON Lessons Learned . . . the future.Before REASON technology, Lessons Learned was limited to lessons that were based upon a relatively small sample of exceptional cases. Lengthy reports were distributed or posted. Lessons were used either to make long range planning decisions or to prevent the recurrence of previous losses. The process was valuable, but ponderous and limited in its applications. Now the qualities of timeliness and immediacy have been added to the data. The data is navigable and addressable. REASON has released the full potential of Lessons Learned. We will see line supervisors in the plant going to their Lessons Learned system a few minutes before setting up a job to examine the experiences that others have had in similar operations. Employees will solve on-the-job problems quickly, and contribute to the organization's base of knowledge each time they identify a solution. Supervisors and safety professionals will have critical information about every aspect of the operation at their fingertips. Quality professionals, with new ability to see how causes interact within the environment, will devise new ways to improve operations. Human factor engineers will examine exactly how and why personnel act or fail to act in specific and similar situations. Maintenance Directors will examine where and why equipment failures contribute to counter-quality problems. This is the future for safety and operations improvement that REASON has unlocked. We have the wisdom . . . and now the tools to benefit from our past mistakes. For more information about the REASON unified concept, REASON for ES&H Software and Lessons Learned, contact: DECISION systems, inc. Copyright © 2004 Decision Systems, Inc. |
