Building Making It Happen
Establishing Making-it-Happen as ‘Formal & Measurable’ Business Discipline
  Sign-in         Register
    
   Data Quality Program DMA Data Quality Program Approach  

Execution-MiH Encyclopedia  →   Enterprise Intelligence  →  SECTION -  Data Quality  →  CHAPTER -  Data Quality Program  → 

Data Quality Gaps Root Cause Analysis

The root cause analysis of data quality problems is a big subject. There are innumerable methods, techniques and heuristics, which can be applied. Both what and why of data quality leads to firming-up the right approach and plan for quality program. PLEASE REFER the detailed list of possible root causes in a separate chapter Reasons for Bad Data Quality

The output of Data Mapping & Assessment is the documented gaps between what we expected and what exists. The next step is to undertake root-cause analysis.

There is no standard procedure as such for undertaking root-cause analysis. One can use various quality tools OR their combination to find the root-cause. (For example- fishbone diagram, scatter diagram, pareto chart..). There is a detailed list of the possible causes of data quality issues, in topic Reasons for Bad Data Quality, which you can refer to while doing the root-cause analysis.

The following are some of the basic tools related to the root cause analysis.

This list and the content is picked verbatim (with thanks!) from Wikipedia. Please refer the link Root Cause Analysis

5 Whys

My car will not start. (the problem)

Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)

The questioning for this example could be taken further to a sixth, seventh, or even greater level. This would be legitimate, as the "five" in 5 Whys is not gospel; rather, it is postulated that five iterations of asking why is generally sufficient to get to a root cause. The real key is to encourage the troubleshooter to avoid assumptions and logic traps and instead to trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem.

Pareto Analysis

Pareto analysis is a statistical technique in decision making that is used for selection of a limited number of tasks that produce significant overall effect. It uses the Pareto principle - the idea that by doing 20% of work you can generate 80% of the advantage of doing the entire job. Or in terms of quality improvement, a large majority of problems (80%) are produced by a few key causes (20%).

Pareto analysis is a formal technique useful where many possible courses of action are competing for your attention. In essence, the problem-solver estimates the benefit delivered by each action, then selects a number of the most effective actions that deliver a total benefit reasonably close to the maximal possible one.

Steps to identify the important causes using Pareto analysis

  • Step 1: Form a table listing the causes and their frequency as a percentage.
  • Step 2: Arrange the rows in the decreasing order of importance of the causes (i.e, the most important cause first)
  • Step 3: Add a cumulative percentage column to the table
  • Step 4: Plot with causes on x- and cumulative percentage on y-axis
  • Step 5: Join the above points to form a curve
  • Step 6: Plot (on the same graph) a bar graph with causes on x- and percent frequency on y-axis
  • Step 7: Draw line at 80% on y-axis parallel to x-axis. Then drop the line at the point of intersection with the curve on x-axis. This point on the x-axis separates the important causes (on the left) and trivial causes (on the right...

Fishbone Diagram


Most Ishikawa diagrams have a box at the right hand side in which is written the effect that is to be examined. The main body of the diagram is a horizontal line from which stem the general causes, represented as "bones". These are drawn towards the left-hand side of the paper and are each labeled with the causes to be investigated, often brainstormed beforehand and based on the major causes listed above. Off each of the large bones there may be smaller bones highlighting more specific aspects of a certain cause, and sometimes there may be a third level of bones or more. These can be found using the '5 Whys' technique. When the most probable causes have been identified, they are written in the box along with the original effect. The more populated bones generally outline more influential factors, with the opposite applying to bones with fewer "branches". Further analysis of the diagram can be achieved with a Pareto chart.

Fishbone

Cause Mapping

Most problems have many interrelated causes, and cause mapping is designed to physically map out, on paper, those relationships. But before creating a cause map, an organization’s goals must be well-defined and clearly communicated. Deviations from these overall goals define the problem and, thus, determine how a cause map should start.

Overall goals could include on-time delivery, a workplace free of safety hazards, and so forth. Most important, they should be easily quantifiable so that everyone immediately knows when these goals aren’t met. Delivery time can be quantified; “friendly” customer service, on the other hand, can be more difficult to measure.

Cause Mapping resembles problem solving tools such as the Ishikawa fishbone diagram, but with several differences. The fishbone defines one problem and finds its causes. Cause Mapping, on the other hand, defines problems within the context of an organization’s overall goals. The overall goals, not the problem, give the starting point. Problems are defined by how they deviate from these overall goals. The fishbone diagram reads right to left, Cause Mapping right to left. The fishbone diagram groups similar causes into categories: methods , machines, materials, etc., while the Cause Map does not, instead depicting how individual causes and effects relate.

 

After the root-cause analysis is done and we know what and why, this is the time to have a quick scan with the information customers on priority-assessment. When users can see the gap and understand the efforts, which could be needed to fill the gap (cost), they can take more informed decision on how much of the gap they want to fill-up (benefit). This helps in firming-up the approach and heightens the probability of it being accepted, when submitted for final sign-off.

 

   Data Quality Program DMA Data Quality Program Approach  
 
All Topics in: "Data Quality Program" Chapter
 Data Quality Program Initiation →  Data Quality Program DMA →  Data Quality Gaps Root Cause Analysis →  Data Quality Program Approach →  Data Quality Analysis considerations →  Data Quality Approach Finalization →  Data Quality Program Analyze Phase and Business case Closure →  Data Quality Policy →  Data Quality Organization Roles →  Data Quality Control Procedures → 
 
Relevant Links to this page
TOPIC - Customer Data Challenges → Customer Data Searching and Matching → 

Was this page helpful?
If you like it ? share it !
Digg
Digg
Reddit
Reddit
Del.icio.us
Delicious
Google
Google
Live
Live
Facebook
Facebook
Slashdot
Slashdot
Netscape
Netscape
Technorati
Technorati
Stumbleupon
Stumbleupon
Spurl
Spurl
Furl
Furl
Blogmarks
Blogmarks
Yahoo
Yahoo
Plugim
Plugim
Squidoo
Squidoo
BlinkBits
BlinkBits
 
CONTENT ZONE
Data Quality

Featured Pages
What is Data Warehouse?
Data Quality Policy
Master-Data-Management CDI Objectives
ODS- Operational Data Store

Make 'Executable' Strategy
Maximize Results
Maximize People
Manage Execution

Featured Pages
Universal names and definitions
Knowledge Discovery in Databases Program
Data Map & Assessment Report
Master Data Management vs. BI vs. Metadata