"Tools and Techniques of TQM": Paper ON
"Tools and Techniques of TQM": Paper ON
PAPER ON
PAPER PRESENTED BY
-1-
APPLYING TOOLS & TECHNIQUES OF TQM IN ENGINEERING EDUCATION Abstract Kaoru Ishikawa developed seven basicvisual tools of quality so that the average person could analyze and interpret data. These tools have been used worldwide by educational institutes for TQM process, companies, managers of all levels and employees. The Seven Tools are: Histograms, Pareto Charts, Cause and Effect Diagrams, Run Charts, Scatter Diagrams, Flow Charts, Control Charts. This paper reflects the use of fishbone diagram in Total Quality Management Process of teaching and learning method. A combination of systems thinking, and cause-and-effect diagrams is an effective strategy for gaining feedback. Traditional cause-and-effect diagrams depict causes and effects in a simple linear relationship.It are a tool for analyzing process dispersion. It is also referred to as the "Ishikawa diagram," because Kaoru Ishikawa developed it, and the "fishbone diagram," because the complete diagram resembles a fish skeleton. The diagram illustrates the main causes and sub causes leading to an effect (symptom). It is a team brainstorming tool used to identify potential root causes to problems .Because of its function it may be referred to as a causeand-effect. Diagram In a typical Fishbone diagram, the effect is usually a problem needs to be resolved, and is placed at the "fish head". The causes of the effect are then laid out along the "bones", and classified into different types along the branches. Further causes can be laid out alongside further side branches. This paper applies cause effect diagram to teaching problems in educational institutes. 1. Introduction The main goal of the Fishbone diagram is to illustrate in a graphical way the relationship between a given outcome and all the factors that influence this outcome. The main objectives of this tool are: Determining the root causes of a problem. Focusing on a specific issue without resorting to complaints and irrelevant discussion. Identifying areas where there is a lack of data.
This technique is very much applicable to the software industry and to Notes and Domino. There are problems in Notes-based applications and in Domino administration in which root cause analysis is important. For example, replication problems can occur for a number of reasons, including replication settings, database access levels, document security, or other factors. The Fishbone diagram helps us to arrive at the root cause of a problem through brainstorming for quality improvement.
Main Cause Main Cause A Level 3 Cause Level 2 Cause
Level 1 Cause
Main Cause
Main Cause
-2-
Fig2. Example: Pizza Preparation and Delivery (Stage 1) 1. Select the most appropriate Cause and Effect format. 2.Generate the causes needed to build a Cause and Effect dia gram Use : a) Brainstorming without previous preparation collected prior to meeting. b) Check sheet based on data Collected prior to meeting. Hierarchical relationship of the effect to the main causes and their subsequent relationship to the sub causes.
Steps towards constructing Cause and Effect diagram 1. Construct the Cause and Effect diagram a) Place the problem statement in a box of right hand side of the writing surface. Allow plenty of space.Use a flipchart sheet,or a large white board. A paper surface is preferred since the final cause and effect diagram can be moved. Tip: Make sure be every agrees on the problem statement. Include as much information as possible on the what ,where, when, and how much of the problem. Use data to specify the problem. b) Draw major cause categories or steps in the production or service process. Connect them to the backbone of the fishbone chart . Fig 3. Stage 2
People
M ethods
M aterials
-3-
Illustration note: In a Process classification type format, replace the major bone Categories with: order taking, Preparation, Cooking, delivery. Be flexible in the major cause bones that are used. In a production Process the traditional categories are: causes Place the Brainstormed or data based in the appropriate category In brainstorming, possible causes can be placed in a major cause category As each is generated , or only after the entire list has been created.Either Works well but brainstorming the whole list first maintains the creative flow Of ideas without being constrained by the major cause categories or where the ideas fit in each bone. Some causes seem to fit in more than one category.Ideally each cause should be one category,but some of the people causes may legitimately belong in Two places. Place them in both categories & see how they work out in the end.
2. When to use it You may find it helpful to use the Fishbone diagram in the following cases:
To analyze and find the root cause of a complicated problem When there are many possible causes for a problem If the traditional way of approaching the problem (trial and error, trying all possible causes, and so on) is very time consuming The problem is very complicated and the project team cannot identify the root cause
3. When not to use it Of course, the Fishbone diagram isn't applicable to every situation. Here are a just a few cases in which you should not use the Fishbone diagram because the diagrams either are not relevant or do not produce the expected results:
The problem is simple or is already known. The team size is too small for brainstorming. There is a communication problem among the team members. There is a time constraint; all or sufficient headcount is not available for brainstorming .The team has experts who can fix any problem without much difficulty.
-4-
-5-
U nreliable cars D rivers get lost O vens too sm all Late Pizza deliveries on Fridays &Saturdays
Poor dispatching
R out of un Ingredients
M ethods
M aterials
Fig 4. (Stage 3) 4. The benefits and Weaknesses of each Cause- andEffect diagram Benefits: 1. Helps organize & relate factors. 2. Provides a structure for brainstorming. 3. Involves everyone. 4. Its fun. 5. Fishbone Diagrams are occasionally useful for initial brainstorming. Potential drawbacks: 1. Might be difficult to facilitate if developed in true brainstorming fashion. 2. Might become very complex. 3. Fishbone Diagrams tend to be either far too simplistic or far too detailed in real world use.
Disturbance in class
Lack of communication skills Staff Lack of core knowledge Problems faced in teaching
Notes Student
5.Description Draw major cause categories or steps in the production or service process. Connect them to the Backbone of the Fishbone chart .In a Process Classification type format, replace the major bone categories with People, Stationary, Teaching Aids. Place the Brainstormed or data based causes in the appropriate categories like:
Staff, Student, Books, Notes, LCD Projector, OHP, Teaching Aids. In Brainstorming, Possible causes can be placed in a major cause category as each is generated or only after the entire list has been created. If ideas are slow in coming ,use the major cause categories. Ask repeatedly of each cause listed on the Bones, either Why does it happen?.
best solutions to prevent an incident from occurring, and a Cause Map helps reach this ideal by efficiently laying outon one map the impact to the organizations goals, the system of causes supported with evidence and the best solutions. 6. Conclusion The above example details the application of the Fishbone diagram in identifying the root cause of a software problem. We hope that you find this method useful in diagnosing your own software problems. You can apply the Fishbone diagram to any number of issues that your IT organization encounters. In part two of our series, we cover the Pareto principle and how it can help you to manage problems that you determined using this analysis tool. The Cause Mapping method of root cause analysis builds upon and refines some of the fishbone diagrams original concepts. The concepts, examples and exercises involved with the Cause Mapping method improve the way people analyze, document, communicate and solve problems. The purpose of an investigation is to find the
7. References 1. Constant, D., Re: CMMI Representations, which one is the better? Yahoo SPI Mailing List, February 10 2004, URL: http://groups.yahoo.com/ group/cmmi_process_imp rovement 2. Software Engineering Institute, Process Maturity Profile SCAMPI v1.1 Appraisals Results 2006 Year End Update, Software Engineering
Measurement and Analysis Team, Carnegie Mellon University, March 2006,URL:http://www.sei .cmu.edu/appraisalprogra m/profile/pdf/CMMI/200 6marCMMI.pdf 3 Bate, R., Kuhn, D. A., Wells, C., Armitage, J., Clark, G., Cusick, K., Garcia, S., Hanna, M.,Jones, R., Malpass, P., Minnich, I., Pierson, H., Powell, T. & Reichner, A., Systems
Engineering Capability MaturityModel (SECMM) Version 1.1, Software Engineering Institute, CMU/SEI1995-MM-003, Maturity Model, November 1995, URL:http://www.sei.cmu. edu/pub/documents/95.re ports/pdf/mm003.95.pdf