Eureka Outsourcing Solutions (P) Ltd

Eureka Outsourcing Solutions (P) Ltd
Eureka Outsourcing Solutions (P) Ltd

Monday, December 13, 2010

SIX SIGMA - P2


Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or incidents. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.
RCA, initially is a reactive method of problem detection and solving. This means that the analysis is done after an incident has occurred. By gaining expertise in RCA it becomes a pro-active method. This means that RCA is able to forecast the possibility of an incident even before it could occur. While one follows the other, RCA is a completely separate process to Incident Management.
Root cause analysis is not a single, sharply defined methodology; there are many different tools, processes, and philosophies of RCA in existence. However, most of these can be classed into five, very-broadly defined "schools" that are named here by their basic fields of origin: safety-based, production-based, process-based, failure-based, and systems-based.
Despite the seeming disparity in purpose and definition among the various schools of root cause analysis, there are some general principles that could be considered as universal. Similarly, it is possible to define a general process for performing RCA.
Basic elements of root cause
  • Materials
    • Defective raw material
    • Wrong type for job
    • Lack of raw material
  • Man Power
    • Inadequate capability
    • Lack of Knowledge
    • Lack of skill
    • Stress
    • Improper motivation
  • Machine / Equipment
    • Incorrect tool selection
    • Poor maintenance or design
    • Poor equipment or tool placement
    • Defective equipment or tool
  • Environment
    • Orderly workplace
    • Job design or layout of work
    • Surfaces poorly maintained
    • Physical demands of the task
    • Forces of nature
  • Management
    • No or poor management involvement
    • Inattention to task
    • Task hazards not guarded properly
    • Other (horseplay, inattention....)
    • Stress demands
    • Lack of Process
    • Lack of Communication
  • Methods
    • No or poor procedures
    • Practices are not the same as written procedures
    • Poor communication
  • Management system
    • Training or education lacking
    • Poor employee involvement
    • Poor recognition of hazard
    • Previously identified hazards were not eliminated
A CTQ tree (Critical to Quality tree) is used to decompose broad customer requirements into more easily quantified requirements. CTQ Trees are often used in the Six Sigma methodology.
CTQs are derived from customer needs. Customer delight may be an add-on while deriving Critical To Quality parameters. For cost considerations one may remain focused to customer needs at the initial stage.
CTQs (Critical to Quality) are the key measurable characteristics of a product or process whose performance standards or specification limits must be met in order to satisfy the customer. They align improvement or design efforts with customer requirements.
CTQs represent the product or service characteristics that are defined by the customer (internal or external). They may include the upper and lower specification limits or any other factors related to the product or service. A CTQ usually must be interpreted from a qualitative customer statement to an actionable, quantitative business specification.
To put it in layman's terms, CTQs are what the customer expects of a product... the spoken needs of the customer. The customer may often express this in plain English, but it is up to the CTQ expert to convert them to measurable terms using tools such as DFMEA, etc.
A Pareto chart, named after Vilfredo Pareto, is a type of chart that contains both bars and a line graph, where individual values are represented in descending order by bars, and the cumulative total is represented by the line.
Simple example of a Pareto chart using hypothetical data showing the relative frequency of reasons for arriving late at work
The left vertical axis is the frequency of occurrence, but it can alternatively represent cost or another important unit of measure. The right vertical axis is the cumulative percentage of the total number of occurrences, total cost, or total of the particular unit of measure. Because the reasons are in decreasing order, the cumulative function is a concave function. To take the example above, in order to lower the amount of late arriving by 80%, it is sufficient to solve the first three issues.The purpose of the Pareto chart is to highlight the most important among a (typically large) set of factors. In quality control, it often represents the most common sources of defects, the highest occurring type of defect, or the most frequent reasons for customer complaints, and so on.These charts can be generated by simple spreadsheet programs, such as OpenOffice.org Calc and Microsoft Excel and specialized statistical software tools as well as online quality charts generators.

Ishikawa diagrams (also called fishbone diagrams, cause-and-effect diagrams or Fishikawa) are diagrams that show the causes of a certain event -- created by Kaoru Ishikawa (1990)[1]. Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify these sources of variation. The categories typically include:

  • People: Anyone involved with the process
  • Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws
  • Machines: Any equipment, computers, tools etc. required to accomplish the job
  • Materials: Raw materials, parts, pens, paper, etc. used to produce the final product
  • Measurements: Data generated from the process that are used to evaluate its quality
  • Environment: The conditions, such as location, time, temperature, and culture in which the process operates

The 4 Ss (used in service industry)

  • Surroundings
  • Suppliers
  • Systems
  • Skills
The check sheet is a simple document that is used for collecting data in real-time and at the location where the data is generated. The document is typically a blank form that is designed for the quick, easy, and efficient recording of the desired information, which can be either quantitative or qualitative. When the information is quantitative, the checksheet is sometimes called a tally sheet.
A defining characteristic of a checksheet is that data is recorded by making marks ("checks") on it. A typical checksheet is divided into regions, and marks made in different regions have different significance. Data is read by observing the location and number of marks on the sheet. 5 Basic types of Check Sheets:
·         Classification: A trait such as a defect or failure mode must be classified into a category.
·         Location: The physical location of a trait is indicated on a picture of a part or item being evaluated.
·         Frequency: The presence or absence of a trait or combination of traits is indicated. Also number of occurrences of a trait on a part can be indicated.
·         Measurement Scale: A measurement scale is divided into intervals, and measurements are indicated by checking an appropriate interval.
·         Check List: The items to be performed for a task are listed so that, as each is accomplished, it can be indicated as having been completed.

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.[1]

Sterneckert (2003) suggested that flowcharts can be modelled from the perspective of different user groups (such as managers, system analysts and clerks) and that there are four general types:[9]
  • Document flowcharts, showing controls over a document-flow through a system
  • Data flowcharts, showing controls over a data flows in a system
  • System flowcharts showing controls at a physical or resource level
  • Program flowchart, showing the controls in a program within a system
Notice that every type of flowchart focuses on some kind of control, rather than on the particular flow itself.[9]

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.