<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Data Quality – who needs it!</title>
	<atom:link href="http://datavaluetalk.com/2009/03/18/data-quality-%e2%80%93-who-needs-it/feed/" rel="self" type="application/rss+xml" />
	<link>http://datavaluetalk.com/data-quality/data-quality-%e2%80%93-who-needs-it/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=data-quality-%25e2%2580%2593-who-needs-it</link>
	<description>Customer data is a valuable asset. Why not treat it that way?</description>
	<lastBuildDate>Wed, 14 Sep 2011 10:47:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Daragh O Brien</title>
		<link>http://datavaluetalk.com/data-quality/data-quality-%e2%80%93-who-needs-it/#comment-646</link>
		<dc:creator>Daragh O Brien</dc:creator>
		<pubDate>Fri, 08 May 2009 12:01:46 +0000</pubDate>
		<guid isPermaLink="false">http://datavaluetalk.com/?p=836#comment-646</guid>
		<description>Balancing the cost/impact of fixing the information quality problems against the cost/impact of living with them is a constant theme I&#039;ve come across working internally in a large company.

The cost of poor quality is often seen as the &quot;cost of doing business&quot;, and often the thinking is tightly stuck in that rut. The only approach that I&#039;ve ever seen come close to addressing the holy grail of good quality data has been to:

1) Tackle people and processes to change behaviour that causes common errors
2) Put measures in to track the changes in behaviour (profile data on the way into your systems for example)
3) Then make the changes necessary to the systems to address the causes that are inherent in the system, or are required to address other process weaknesses that cause poor quality data.
4) And then (either at the end or in parallel to 1) and 2), start working to clear out the crummy data in the systems.

Unfortunately, executives are too used to the &quot;zip bang flashing lights&quot; of IT systems delivery (for example sexy new web applications or call centre tools) to appreciate the hidden value in the unglamorous work of mucking out the database and making the processes hum along to stop crud getting in.

It&#039;s a bit like people being enamoured with &quot;slim-quick&quot; diet pills and &#039;magic potions&#039; while not recognising the real long term value of going to the gym to improve fitness. The former gives unsustainable results quickly, but the latter gives longer lasting and more far-reaching benefits.

And on that... just popping out for a run....</description>
		<content:encoded><![CDATA[<p>Balancing the cost/impact of fixing the information quality problems against the cost/impact of living with them is a constant theme I&#8217;ve come across working internally in a large company.</p>
<p>The cost of poor quality is often seen as the &#8220;cost of doing business&#8221;, and often the thinking is tightly stuck in that rut. The only approach that I&#8217;ve ever seen come close to addressing the holy grail of good quality data has been to:</p>
<p>1) Tackle people and processes to change behaviour that causes common errors<br />
2) Put measures in to track the changes in behaviour (profile data on the way into your systems for example)<br />
3) Then make the changes necessary to the systems to address the causes that are inherent in the system, or are required to address other process weaknesses that cause poor quality data.<br />
4) And then (either at the end or in parallel to 1) and 2), start working to clear out the crummy data in the systems.</p>
<p>Unfortunately, executives are too used to the &#8220;zip bang flashing lights&#8221; of IT systems delivery (for example sexy new web applications or call centre tools) to appreciate the hidden value in the unglamorous work of mucking out the database and making the processes hum along to stop crud getting in.</p>
<p>It&#8217;s a bit like people being enamoured with &#8220;slim-quick&#8221; diet pills and &#8216;magic potions&#8217; while not recognising the real long term value of going to the gym to improve fitness. The former gives unsustainable results quickly, but the latter gives longer lasting and more far-reaching benefits.</p>
<p>And on that&#8230; just popping out for a run&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tilsner, Petra</title>
		<link>http://datavaluetalk.com/data-quality/data-quality-%e2%80%93-who-needs-it/#comment-93</link>
		<dc:creator>Tilsner, Petra</dc:creator>
		<pubDate>Wed, 18 Mar 2009 16:26:17 +0000</pubDate>
		<guid isPermaLink="false">http://datavaluetalk.com/?p=836#comment-93</guid>
		<description>Nice to read :-) and interested in the second part *g*

Schöne Grüße aus Köln
Petra</description>
		<content:encoded><![CDATA[<p>Nice to read :-) and interested in the second part *g*</p>
<p>Schöne Grüße aus Köln<br />
Petra</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan Wilhelm</title>
		<link>http://datavaluetalk.com/data-quality/data-quality-%e2%80%93-who-needs-it/#comment-92</link>
		<dc:creator>Jan Wilhelm</dc:creator>
		<pubDate>Wed, 18 Mar 2009 14:06:03 +0000</pubDate>
		<guid isPermaLink="false">http://datavaluetalk.com/?p=836#comment-92</guid>
		<description>Very apt Paul.
Along our data quality project we found out, that stopping new duplicates pouring into the database isn&#039;t enough - it&#039;s just a good start as you say.
Usually there is a history of data which is already there (unchecked and terribly filthy) and of course there are business processes permanently running on this data.
So we did a three step approach:
1. stop new dublicates coming in
2. kill duplicates which have been already there without stopping the running business
3. Improve the data content and so improve finding dublicate results 
But as you said: it&#039;s along way to Tipperary (which is a pub in London as I&#039;ve heard - can you confirm?)</description>
		<content:encoded><![CDATA[<p>Very apt Paul.<br />
Along our data quality project we found out, that stopping new duplicates pouring into the database isn&#8217;t enough &#8211; it&#8217;s just a good start as you say.<br />
Usually there is a history of data which is already there (unchecked and terribly filthy) and of course there are business processes permanently running on this data.<br />
So we did a three step approach:<br />
1. stop new dublicates coming in<br />
2. kill duplicates which have been already there without stopping the running business<br />
3. Improve the data content and so improve finding dublicate results<br />
But as you said: it&#8217;s along way to Tipperary (which is a pub in London as I&#8217;ve heard &#8211; can you confirm?)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

