Have you built your DQ trust today?

May 10, 2010 by · 7 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In the last time, there have been quite a few posts on using “shame” as a tool for improving data quality. Here are just three from the top of my head:

Picture by Okinawa Soba, taken from flickr with a cc license

I’ve added some comments to these posts that I think that they are missing something. I wasn’t quite able to put my finger to it, not sure how to grab the “missing thing”, not really able to give it a name. In order to move the discussion forward, I’ve decided to go with “DQ trust” and try to explain my thinking a bit more. Let me know in the comments what you think!

The problem I see with the “public humiliation” aspect of what Rob and Jim are describing: It will only work in a certain environment – when the “riot act” gets what I would call a “wink wink, nudge nudge” aspect.  The “culprit” understands why the reaction is coming, but the whole thing is so much over the top that it can’t really be taken seriously. This results in taking the sting out of the “public humiliation” aspect and the riot act achieves its purpose.

In order for this to work, there has to be one of two things: Either you have to be a really good comedian (and I’m certainly not) so that you can spring this on a person you’ve hardly ever dealt with before. If your act backfires, you’ll also have to deal with that person’s boss, and I have found humor to decline when moving up the corporate ladder. Pretty risky to rely on that.

That leaves the second option: Your riot act has to have a background to it, and you must have built a reputation as a fervent defender of data quality in your organization – you must have built a trust in your data quality judgment. This way, a person or his boss can understand that your reaction is aimed at improving data quality, and not at public humiliating data quality villains.

Too often I find that people do not take enough time to build this data quality trust. As they say it takes a long time to build trust, but only a moment to destroy it forever. Here are some ideas of what to do to build the trust:

  • reserve judgment on someone’s actions for as long as possible – try to find out why people do things a certain way before telling them they are idiots
  • admit that you don’t know everything and try to learn constantly by interacting with different people from different departments to get a 360° view on the issues
  • help people to solve their problems – then they will be much more willing to help you when you need their support
  • make sure to explain data quality in terms the person understands – a business user doesn’t care too much about referential integrity unless you can explain how it affects his daily work
  • don’t be too academic in your data quality requirements – it doesn’t make sense to require perfect data quality for data that is never used

Even with this, whenever a new data quality issue comes and I’m shaking my head why anyone would come up with this harebrained scheme, I ask myself whether I’ve built enough trust to shame the person about it or not. Almost always, I come out on the side of caution and try to be firm on the issue, but avoid assigning personal blame. In the short term, this may not be quite as satisfying as “venting”, but has a much better chance of long-term success.

Heute schon das Vertrauen in DQM erhöht?

May 10, 2010 by · 1 Comment
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

In der letzten Zeit wurde einige Blogposts veröffentlicht, in denen ein Pranger als Mittel zur Verbesserung der Datenqualität diskutiert wurden. Hier sind einige englisch-sprachige Beispiele:

  • A Data Quality Riot Act von Rob Paller
  • The Poor Data Quality Jar
  • The Scarlet DQ, beide von Jim Harris auf OCDQBlog
  •  

      Picture by Okinawa Soba, taken from flickr with a cc license

    Bei diesen Beiträge hatte ich das Gefühl, dass die Reaktion zwar menschlich verständlich ist, aber der Sache eher schadet. Um die Diskussion dazu weiter zu führen, möchte ich meine Gedanken zum “Vertrauen in DQM” etwas weiter ausführen und freue mich über Kommentare und andere Sichtweisen.

    Das Problem, das ich mit dem “öffentlichen Anprangern” aus den Posts von Rob und Jim sehe: Ein solches Vorgehen wird nur unter engen Bedingungen funktionieren – wenn das Anprangern mit einem Augenzwinkern erfolgt. Am einfachsten ist es, wenn der “Beschuldigte” von sich aus versteht, was falsch gelaufen ist – dann kann der “Anschiss” so übertrieben sein, dass er nicht ernst genommen werden kann und es so zu keinem persönlichen Angriff kommt, aber der Hinweis trotzdem aufgegriffen wird.

    Damit das funktioniert, sehe ich zwei Möglichkeiten: Man ist so witzig, dass ein “Anschiss” an einen neuen Kollegen zu einem Schmunzeln führt – ich selbst bekomme das mit Sicherheit nicht hin. Zudem birgt es das Risiko, dass das Ganze nach hinten losgeht und man dann sein Verhalten mit dem Vorgesetzten des Kollegen besprechen muss. Nach meinen Erfahrungen werden solche Gespräche immer humorloser, je weiter es in der Firmenhierarchie nach oben geht. Insgesamt sehr riskant, sich auf sein komödiantisches Talent zu verlassen.

    Damit bleibt die zweite Möglichkeit – das Anprangern erfolgt nur in Ausnahmefällen und erst, nachdem man Vertrauen in DQM aufgebaut und den Beteiligten klar ist, das es um die Verbesserung der Datenqualität geht und nicht darum, jemandem die Schuld für Probleme in die Schuhe zu schieben.

    Leider nimmt man sich selten genug Zeit zum Aufbau des dafür erforderlichen Vertrauens, vielmehr kann mühselig aufgebautes Vertrauen mit einer unbedachten Äußerung wieder verspielt werden. Hier sind ein paar Ideen, Vertrauen in DQM zu schaffen:

    • eine Beurteilung sollte so spät wie möglich erfolgen – man sollte erst versuchen herauszufinden, warum Leute bestimmte Vorgehen gewählt haben, bevor man sie als Idioten bezeichnet
    • Man kann gerne zugeben, auch nicht alles zu wissen und laufend dazuzulernen, in dem man mit so vielen Leuten wie möglich spricht, die verschiedene Blickwinkel auf ein Thema haben
    • Unterstützen Sie die Leute bei der Lösung derer Probleme – dann ist die Bereitschaft größer, auch bei DQ Problemen zu helfen
    • Datenqualität muss abhängig vom Zuhörer erklärt werden – ein Fachbereich interessiert sich nicht für referentielle Integrität, wenn man ihm nicht erklärt, was das in seiner täglichen Arbeit bedeutet
    • Seien Sie nicht zu akademisch in Ihren DQ Anforderungen – es macht keinen Sinn, bei kaum verwendeten Daten eine perfekte Datenqualität zu verlangen

    Selbst mit dieser Grundeinstellung muss ich oft erst einmal den Kopf darüber schütteln, auf welche schwachsinnigen Dinge einige Benutzer kommen. Dann frage ich mich aber, welche Reaktion ich ernten würde, den Benutzer damit ein wenig aufzuziehen. In den meisten Fällen gehe ich dann etwas vorsichtiger vor und diskutiere über die Auswirkungen der Fehler anstatt persönliche Schuld zu suchen. Das ist kurzfristig nicht ganz so befriedigend wie “Luft abzulassen”, hat aber langfristig viel bessere Erfolgsaussichten. Wie reagieren Sie in solchen Situationen, welche Erfahrungen haben Sie gesammelt?