Cum să implementați un proces de calitate a datelor

Calitatea datelor (DQ) în sistemele de depozit de date devine din ce în ce mai importantă. Creșterea cerințelor de reglementare, dar și complexitatea tot mai mare a soluțiilor de depozit de date, obligă companiile să intensifice (sau să demareze) o inițiativă de calitate a datelor.

Accentul principal al acestui articol va fi pe depozitarea de date „tradițională”, dar calitatea datelor este, de asemenea, o problemă în conceptele mai „moderne”, cum ar fi lacurile de date. Acesta va arăta câteva puncte principale de luat în considerare și, de asemenea, câteva capcane comune de evitat atunci când implementați o strategie de calitate a datelor. Nu acoperă partea referitoare la alegerea tehnologiei/instrumentului potrivit pentru a construi un cadru DQ.

Una dintre cele mai obstructive probleme ale unui proiect DQ este faptul că, la prima vedere, creează multă muncă pentru unitățile de afaceri fără a oferi nicio funcționalitate suplimentară. O inițiativă privind calitatea datelor are de obicei susținători puternici numai dacă:

• Există probleme de calitate a datelor cu un impact sever asupra afacerii.
• Organismele de reglementare aplică standardele de calitate a datelor (de exemplu, BCBS 239 în industria financiară).

Tratamentul DQ este similar cu cel al testării în dezvoltarea de software - dacă un proiect epuizează timpul și/sau bugetul, această parte tinde să fie mai întâi redusă.

Acesta, desigur, nu este întregul adevăr. Un sistem bun de calitate a datelor ajută la detectarea precoce a erorilor, accelerând astfel procesul de livrare a datelor de calitate „destul de bună” către utilizatori.

Definitia termenilor

Înainte de a discuta subiectul, este importantă o înțelegere comună a termenilor folosiți.

Depozit de date (DWH)

Un depozit de date (DWH) este un sistem neoperațional utilizat în principal pentru suport decizional. Consolidează datele sistemelor operaționale (toate sau un subset mai mic) și oferă date optimizate pentru interogări pentru utilizatorii sistemului DWH. Depozitul de date ar trebui să ofere „o singură versiune a adevărului” în cadrul întreprinderii. Un depozit de date este de obicei construit din etape/straturi:

Datele operaționale sunt stocate în cea mai mare parte neschimbate într-un strat intermediar . Stratul de bază conține date consolidate și unificate. Următoarea etapă opțională este o zonă de derivare , care furnizează date derivate (de exemplu, un scor client pentru vânzări) și agregari. Stratul data mart conține date optimizate pentru un anumit grup de utilizatori. Data mart-urile conțin adesea agregari și o mulțime de valori derivate. Utilizatorii depozitului de date lucrează adesea doar cu stratul data mart.

Între fiecare etapă are loc un fel de transformare a datelor. De obicei, un depozit de date este încărcat periodic cu extracții delta ale datelor operaționale și conține algoritmi pentru păstrarea datelor istorice.

Calitatea datelor

Calitatea datelor este, de obicei, definită ca o măsură a cât de bine un produs îndeplinește cerințele utilizatorului. Utilizatorii diferiți pot avea cerințe diferite pentru un produs, astfel încât implementarea depinde de perspectiva utilizatorului și este important să identificați aceste nevoi.

Calitatea datelor nu înseamnă că datele trebuie să fie complet sau aproape fără erori - depinde de cerințele utilizatorilor. O abordare „destul de bună” este o alegere bună pentru început. În zilele noastre, companiile mai mari au „o politică guvernamentală privind datele (sau informațiile)”, iar calitatea datelor este o parte a acesteia. O politică guvernamentală de date ar trebui să descrie modul în care compania dumneavoastră tratează datele și cum se asigură că datele au calitatea potrivită și că regulile de confidențialitate a datelor nu sunt încălcate.

Calitatea datelor este un subiect în curs de desfășurare. Trebuie implementată o buclă de circuit DQ (vezi capitolul următor). Cerințele de reglementare și regulile de conformitate au, de asemenea, un impact asupra calității datelor necesare, cum ar fi TCPA (US Telephone Consumer Protection Act) sau GDPR în Europa pentru probleme de confidențialitate, dar și reguli specifice industriei precum Solvency II pentru asigurări în UE, BCBS 239. iar altele pentru bancare, și așa mai departe.

Circuitul de calitate a datelor

Ca și în cazul tuturor subiectelor de calitate, DQ este o activitate continuă menită să mențină o calitate satisfăcătoare. Ca rezultat al unui proiect DQ, trebuie implementată o buclă de circuit similară celei de mai jos:

Pașii din această buclă vor fi descriși în capitolele următoare.

Roluri de calitate a datelor

Pentru a implementa o inițiativă de succes DQ, sunt necesare următoarele roluri:

• Proprietarul datelor. Un proprietar de date este responsabil pentru calitatea datelor, dar și pentru protecția confidențialității datelor. Proprietarul datelor „deține” un domeniu de date, controlează accesul și este responsabil pentru asigurarea calității datelor și pentru a lua măsuri pentru a remedia constatările. În organizațiile mai mari, este obișnuit să găsiți mai mulți proprietari de date. Domeniile de date ar putea fi, de exemplu, date de marketing, date de control etc. Dacă într-o companie există mai mult de un proprietar de date, ar trebui să existe o persoană (un proprietar de date sau altcineva) responsabilă pentru procesul general de calitate a datelor. Un proprietar de date ar trebui să aibă o autoritate puternică pentru a impune calitatea datelor și a sprijini procesul DQ; prin urmare, proprietarii de date sunt adesea părți interesate seniori. O bună înțelegere a domeniului de afaceri, împreună cu bune abilități de comunicare sunt importante.
• Administrator de date. Un administrator de date ajută la implementarea calității datelor în cadrul unei întreprinderi, sprijinind utilizatorii de date cu privire la întrebările despre modul de interpretare a datelor/modelului de date, probleme de calitate a datelor etc. Administratorii de date sunt adesea personalul proprietarului datelor sau pot fi organizați într-un centru de competență privind calitatea datelor. sau o echipă DQ. Administratorii de date pot avea cunoștințe IT sau de afaceri, dar ar trebui să cunoască ambele părți. Abilitățile analitice, împreună cu o bună înțelegere a domeniului de afaceri pe care îl sprijină, combinate cu abilități puternice de comunicare, sunt premisele principale pentru un administrator de date de succes.
• Utilizator de date. Aceștia sunt utilizatori de depozit de date care lucrează cu date. Utilizatorii de date lucrează în mod obișnuit cu stratul data mart și sunt responsabili pentru rezultatele muncii cu datele. Utilizatorii de date se asigură că există verificări adecvate ale calității datelor pentru nivelul de calitate de care au nevoie. Utilizatorii de date au nevoie de o înțelegere puternică a datelor lor, a domeniului de afaceri și a abilităților analitice necesare pentru interpretarea datelor. Este rezonabil să găsiți câțiva oameni printre utilizatorii de date din fiecare unitate de afaceri care vor fi responsabili pentru problemele legate de calitatea datelor.

Pentru a asigura succesul, este important să aveți aceste roluri clar definite și acceptate pe scară largă în cadrul organizației dvs. în primele etape ale proiectului DQ. Este la fel de important să găsiți specialiști în date competenți pentru aceste roluri, care sprijină proiectul.

Definiți regulile

Găsiți și implementați controale/reguli utile DQ. Definirea regulilor DQ necesită o bună înțelegere a depozitului de date și a utilizării acestuia.

Cum să găsiți regulile DQ?

După cum sa discutat mai devreme, utilizatorii de date (și proprietarul datelor) sunt responsabili pentru utilizarea datelor și, prin urmare, și pentru nivelul necesar de calitate a datelor. Utilizatorii de date ar trebui să aibă o bună înțelegere a datelor lor, astfel încât să poată oferi cea mai bună intrare pentru reguli utile de calitate a datelor.

De asemenea, ei sunt cei care analizează rezultatele regulilor de calitate a datelor, așa că este întotdeauna o idee bună să-i lăsați să-și definească propriile reguli. Acest lucru îmbunătățește și mai mult acceptarea de a verifica și evalua rezultatul regulilor DQ atribuite unei unități de utilizator de date (a se vedea capitolul „Analizare”).

Dezavantajul acestei abordări este că utilizatorii de date cunosc în mod normal doar stratul data mart, nu straturile anterioare ale depozitului de date. Dacă datele au fost corupte în etapele „inferioare”, acest lucru nu va fi detectat verificând doar stratul „superior” al depozitului de date.

Abordarea erorilor

Ce fel de erori cunoscute pot apărea într-un depozit de date?

• Logica de transformare greșită în depozitul de date
  • Cu cât peisajul IT este mai complex, cu atât logica transformării tinde să fie mai complexă. Acestea sunt cele mai frecvente probleme DQ, iar efectul unor astfel de erori poate fi date „pierdute”, duplicate, valori incorecte etc.
• Proces de încărcare instabil sau manipulare greșită a încărcăturilor
  • Încărcarea unui depozit de date poate fi un proces complex care ar putea include erori în definirea orchestrației jobului (lucrări care încep prea devreme sau prea târziu, joburi neexecutate etc.). Erorile datorate intervenției manuale (de exemplu, unele lucrări sunt omise, unele lucrări sunt începute cu o dată scadentă greșită sau cu fișierele de date de ieri) apar adesea când procesul de încărcare este epuizat din cauza unor întreruperi.
• Transfer de date greșit al surselor de date
  • Transferul de date este adesea implementat ca sarcină a sistemului sursă. Anomalii sau întreruperi în fluxurile de locuri de muncă pot cauza livrarea de date goale sau incomplete.
• Date operaționale greșite
  • Datele din sistemul operațional conțin erori nerecunoscute până acum. Poate suna ciudat, dar este o platitudine în proiectele de depozit de date că calitatea datelor operaționale nu este adesea văzută până când datele sunt incluse într-un DWH.
• Interpretarea greșită a datelor
  • Datele sunt corecte, dar utilizatorii nu știu să le interpreteze corect. Aceasta este o „eroare” foarte comună, care nu este strict o problemă de calitate a datelor, ci ceva care are de-a face cu guvernanța datelor și este o sarcină pentru administratorii de date.

Aceste probleme sunt adesea cauzate de oameni care nu au cunoștințele și abilitățile adecvate pentru a defini, implementa, rula și lucra cu o soluție de depozit de date.

Dimensiuni de calitate a datelor

Dimensiunile DQ sunt o modalitate obișnuită de a identifica și grupa verificările DQ. Există multe definiții, iar numărul de dimensiuni variază considerabil: s-ar putea să găsiți 16 sau chiar mai multe dimensiuni. Dintr-o perspectivă practică, este mai puțin confuz să începeți cu câteva dimensiuni și să găsiți o înțelegere generală a acestora în rândul utilizatorilor dvs.

• Completitudine: Sunt toate datele necesare disponibile și accesibile? Sunt toate sursele necesare disponibile și încărcate? S-au pierdut datele între etape?
• Consecvență: Există date eronate/conflictuale/incoerente? De exemplu, data de reziliere a unui contract în stare „Încheiat” trebuie să conțină o dată valabilă mai mare sau egală cu data de începere a contractului.
• Unicitate: există duplicate?
• Integritate: toate datele sunt conectate corect? De exemplu, există comenzi care se leagă la ID-uri de clienți inexistente (o problemă clasică de integritate referențială)?
• Promptitudine: sunt datele actuale? De exemplu, într-un depozit de date cu actualizări zilnice, m-aș aștepta ca datele de ieri să fie disponibile astăzi.

Datele generate de procesul de încărcare a depozitului de date pot fi de asemenea utile.

• Tabele cu date aruncate. Depozitul dvs. de date ar putea avea procese pentru a omite/întârzia datele care nu pot fi încărcate din cauza unor probleme tehnice (de exemplu, conversia formatului, lipsa valorilor obligatorii etc.).
• Informații de înregistrare. Problemele vizibile pot fi scrise în tabelele de jurnal sau în fișierele jurnal.
• Bill de livrare. Unele sisteme folosesc „facturi de livrare” pentru datele furnizate de sistemele operaționale (de exemplu, numărul de înregistrări, numărul de chei distincte, sumele de valori). Acestea pot fi folosite pentru verificări de reconciliere (vezi mai jos) între depozitul de date și sistemele operaționale.

Rețineți că fiecare verificare a calității datelor trebuie să fie analizată de cel puțin un utilizator de date (vezi capitolul „Analizare”) în cazul în care se găsesc erori, pentru care veți avea nevoie de cineva responsabil și disponibil să se ocupe de fiecare verificare implementată.

Într-un depozit de date complex, s-ar putea să ajungeți cu multe (uneori mii) reguli DQ. Procesul de executare a regulilor de calitate a datelor ar trebui să fie suficient de robust și de rapid pentru a gestiona acest lucru.

Nu verificați faptele care sunt garantate de implementarea tehnică. De exemplu, dacă datele sunt stocate într-un SGBD relațional, nu este necesar să se verifice dacă:

• Coloanele definite ca obligatorii conțin valori NULL.
• Valorile câmpurilor cheie primară sunt unice într-un tabel.
• Nu există chei străine existente într-un tabel cu verificările integrității relaționale activate.

Acestea fiind spuse, rețineți întotdeauna că un depozit de date este în continuă schimbare și că definiția datelor câmpurilor și tabelelor se poate modifica în timp.

Curățenia este foarte importantă. Regulile definite de diferite unități de utilizatori de date se pot suprapune și ar trebui consolidate. Cu cât organizația dvs. este mai complexă, cu atât va fi nevoie de mai multă întreținere. Proprietarii de date ar trebui să implementeze un proces de consolidare a regulilor ca un fel de „calitatea datelor pentru regulile de calitate a datelor”. De asemenea, verificările calității datelor ar putea deveni inutile dacă datele nu mai sunt utilizate sau dacă definiția lor s-a schimbat.

Clasele de reguli de calitate a datelor

Regulile de calitate a datelor pot fi clasificate în funcție de tipul de test.

• Verificarea calității datelor. Cazul „normal”, verificarea datelor dintr-un strat de depozit de date (vezi Figura 1), fie într-un tabel, fie într-un set de tabele.
• Reconciliere. Reguli care verifică dacă datele au fost transportate corect între straturile de depozit de date (vezi Figura 1). Aceste reguli sunt utilizate în principal pentru a verifica dimensiunea DQ a „Completitudinii”. Reconcilierea poate folosi un singur rând sau o abordare rezumată. Verificarea rândurilor individuale este mult mai granulară, dar va trebui să reproduceți pașii de transformare (filtrarea datelor, modificări ale valorilor câmpului, denormalizare, îmbinări etc.) între straturile comparate. Cu cât săriți peste mai multe straturi, cu atât trebuie implementată logica de transformare mai complexă. Prin urmare, este o alegere bună să faceți o reconciliere între fiecare strat și predecesorul său, în loc să comparați punerea în scenă cu stratul data mart. Dacă transformările trebuie implementate în regulile de reconciliere, utilizați specificația, nu codul depozitului de date! Pentru o reconciliere rezumată, găsiți câmpuri semnificative (de exemplu, rezumare, numărarea valorilor distincte etc.).
• Monitorizarea. Un depozit de date conține de obicei date istorice și este încărcat cu extrase delta de date operaționale. Există pericolul unui decalaj care crește încet între depozitul de date și datele operaționale. Construirea unor serii cronologice rezumate de date ajută la identificarea problemelor de acest fel (de exemplu, compararea datelor lunii trecute cu datele lunii curente). Utilizatorii de date cu o bună cunoaștere a datelor lor pot oferi măsuri și praguri utile pentru regulile de monitorizare.

Cum se cuantifică o problemă de calitate a datelor

Odată ce ați definit ce să verificați, va trebui să specificați cum să cuantificați problemele identificate. Informații precum „cinci rânduri de date încalcă regula DQ cu ID 15” nu au niciun sens pentru calitatea datelor.

Lipsesc următoarele părți:

• Cum se cuantifică/numărează erorile detectate. Puteți număra „numărul de rânduri”, dar puteți utiliza și o scară monetară (de exemplu, expunerea). Rețineți că valorile monetare pot avea semne diferite, așa că va trebui să investigați cum să le rezumați în mod semnificativ. Ați putea lua în considerare utilizarea ambelor unități de cuantificare (număr de rânduri și rezumare) pentru o regulă de calitate a datelor.
• Populația. Care este numărul de unități verificate de regula de calitate a datelor? „Cinci rânduri de date din cinci” are o calitate diferită de „cinci din 5 milioane”. Populația ar trebui măsurată folosind aceleași cuantificări ca și pentru erori. Este obișnuit să afișați rezultatul unei reguli de calitate a datelor ca procent. Populația nu trebuie să fie identică cu numărul de rânduri dintr-un tabel. Dacă o regulă DQ verifică doar un subset de date (de exemplu, numai contractele încheiate în tabelul de contracte), același filtru ar trebui aplicat pentru a măsura populația.
• Definiția rezultatului. Chiar dacă o verificare a calității datelor găsește probleme, aceasta nu trebuie să provoace întotdeauna o eroare. Pentru calitatea datelor, un sistem de semafor (roșu, galben, verde) care utilizează valori de prag pentru a evalua constatările este de mare ajutor. De exemplu, verde: 0-2%, galben: 2-5%, roșu: peste 5%. Rețineți că, dacă unitățile utilizatorilor de date au aceleași reguli, acestea pot avea praguri foarte diferite pentru o anumită regulă. O unitate de marketing ar putea să nu deranjeze pierderea de câteva comenzi, în timp ce o unitate de contabilitate ar putea să nu deranjeze chiar și cenți. Ar trebui să fie posibil să se definească praguri pe procente sau pe cifre absolute.
• Colectați mostre de rânduri de eroare. Este de ajutor dacă o regulă de calitate a datelor oferă o mostră a erorilor detectate - în mod normal, cheile (de afaceri!) și valorile datelor verificate sunt suficiente pentru a ajuta la examinarea erorii. Este o idee bună să limitați numărul de rânduri de eroare scrise pentru o regulă de calitate a datelor.
• Uneori, este posibil să găsiți „erori cunoscute” în datele care nu vor fi remediate, dar care sunt găsite prin verificări utile de calitate a datelor. Pentru aceste cazuri, se recomandă utilizarea listelor albe (chei ale înregistrărilor care ar trebui sărite printr-o verificare a calității datelor).

Alte metadate

Metadatele sunt importante pentru a ruta „Analiza” și pentru a monitoriza fazele buclei de control al calității datelor.

• Articole bifate. Ajută să atribuiți tabelele și câmpurile verificate unei reguli de calitate a datelor. Dacă aveți un sistem de metadate îmbunătățit, acest lucru ar putea ajuta la atribuirea automată a utilizatorilor de date și a unui proprietar de date la această regulă. Din motive de reglementare (cum ar fi BCBS 239), este, de asemenea, necesar să se dovedească modul în care datele sunt verificate de către DQ. Cu toate acestea, atribuirea automată a regulilor utilizatorilor de date/proprierilor de date prin intermediul descendenței datelor (*) poate fi o sabie cu două tăișuri (vezi mai jos).
• Utilizator de date. Fiecare regulă DQ trebuie să aibă cel puțin o unitate de utilizator de date/utilizator de date alocată pentru a verifica rezultatul în timpul fazei de „Analiza” și pentru a decide dacă și cum o constatare le influențează munca cu datele.
• Proprietarul datelor. Fiecare regulă DQ trebuie să aibă un proprietar de date alocat.

(*) Linia de date arată fluxul de date între două puncte. Cu generația de date, puteți găsi toate elementele de date care influențează un anumit câmp țintă din depozitul dvs.

Utilizarea descendenței datelor pentru a atribui utilizatorilor regulilor poate fi problematică. După cum am menționat anterior, utilizatorii de afaceri cunosc de obicei doar stratul de data mart (și sistemul de operare), dar nu și nivelurile inferioare ale depozitului de date. Prin maparea prin linia de date, utilizatorilor de date li se vor atribui reguli cu care nu sunt familiarizați. Pentru nivelurile inferioare, personalul IT poate fi necesar pentru a evalua o constatare a calității datelor. În multe cazuri, o mapare manuală sau o abordare mixtă (cartare prin linia de date numai în cadrul data mart) poate ajuta.

Măsurarea calității datelor

Măsurarea calității datelor înseamnă executarea regulilor de calitate a datelor disponibile, care ar trebui să se facă automat , declanșate de procesele de încărcare ale depozitului de date. După cum am văzut anterior, ar putea exista un număr remarcabil de reguli de calitate a datelor, astfel încât verificările vor consuma mult timp.

Într-o lume perfectă, un depozit de date ar fi încărcat numai dacă toate datele sunt fără erori. În lumea reală, acesta este rareori cazul (în mod realist, aproape niciodată nu este cazul). În funcție de strategia generală de încărcare a depozitului dvs. de date, procesul de calitate a datelor ar trebui sau nu ar trebui (cel din urmă este mult mai probabil) să conducă procesul de încărcare. Este un design bun să existe procese de calitate a datelor (rețele de locuri de muncă) paralele și legate de procesele „obișnuite” de încărcare a depozitului de date.

Dacă există acorduri de nivel de serviciu definite, asigurați-vă că nu împiedicați încărcările depozitului de date cu verificările calității datelor. Erorile/abendurile în procesele de calitate a datelor nu ar trebui să oprească procesul obișnuit de încărcare. Erorile neașteptate din cadrul proceselor de calitate a datelor trebuie raportate și afișate pentru faza „Analiza” (vezi capitolul următor).

Rețineți că o regulă de calitate a datelor se poate bloca din cauza unor erori neașteptate (poate că regula în sine a fost implementată greșit sau structura de bază a datelor s-a schimbat în timp). Ar fi de ajutor dacă sistemul dvs. de calitate a datelor ar furniza un mecanism pentru a dezactiva astfel de reguli, mai ales dacă compania dvs. are puține lansări pe an.

Procesele DQ ar trebui să fie executate și raportate cât mai devreme posibil - în mod ideal, imediat după ce datele verificate au fost încărcate. Acest lucru ajută la detectarea erorilor cât mai devreme posibil în timpul încărcării depozitului de date (unele încărcări complexe ale sistemului de depozit au o durată de câteva zile).

A analiza

În acest context, „analiza” înseamnă reacția la constatările privind calitatea datelor. Aceasta este o sarcină pentru utilizatorii de date alocate și proprietarul datelor.

Modul de reacție ar trebui să fie clar definit de proiectul dvs. de calitate a datelor. Utilizatorii de date ar trebui să fie obligați să comenteze o regulă cu constatări (cel puțin reguli cu lumină roșie), explicând ce măsuri sunt luate pentru a gestiona constatarea. Proprietarul datelor trebuie informat și ar trebui să decidă împreună cu utilizatorul(i) datelor.

Sunt posibile următoarele acțiuni:

• Problemă gravă: problema trebuie remediată și încărcarea datelor trebuie repetată.
• Problema este acceptabilă: încercați să o remediați pentru încărcările viitoare de date și să rezolvați problema în depozitul de date sau în raportare.
• Regula DQ defectuoasă: remediați regula DQ problematică.

Într-o lume perfectă, orice problemă de calitate a datelor ar fi rezolvată. Cu toate acestea, lipsa resurselor și/sau a timpului duce adesea la soluții alternative.

Pentru a putea reacționa la timp, sistemul DQ trebuie să informeze utilizatorii de date despre regulile „lor” cu constatări. Utilizarea unui tablou de bord pentru calitatea datelor (poate cu trimiterea de mesaje că a apărut ceva) este o idee bună. Cu cât utilizatorii sunt informați mai devreme despre constatări, cu atât mai bine.

Tabloul de bord al calității datelor ar trebui să conțină:

• Toate regulile atribuite unui anumit rol
• Rezultatele regulilor (semafor, măsuri și exemple de rânduri) cu posibilitatea de a filtra regulile după rezultat și domeniul de date
• Un comentariu obligatoriu pe care utilizatorii de date trebuie să îl introducă pentru constatări
• O caracteristică care opțional „anulează” rezultatul (dacă regula de calitate a datelor raportează erori din cauza unei implementări defectuoase, de exemplu). Dacă mai mult de o unitate de afaceri are aceeași regulă de calitate a datelor atribuită, „anularea” este valabilă numai pentru unitatea de afaceri a utilizatorului de date (nu pentru întreaga companie).
• Afișarea regulilor care nu au fost executate sau care au fost încălcate

Tabloul de bord ar trebui să arate, de asemenea, starea actuală a procesului recent de încărcare a depozitului de date, oferind utilizatorilor o vedere la 360 de grade asupra procesului de încărcare a depozitului de date.

Proprietarul datelor este responsabil să se asigure că fiecare constatare a fost comentată și că starea calității datelor (originală sau anulată) este cel puțin galbenă pentru toți utilizatorii de date.

Pentru o privire de ansamblu rapidă, ar ajuta să construiți un fel de KPI (indicatori cheie de performanță) simpli pentru utilizatorii de date/proprietarul de date. A avea un semafor general pentru rezultatele tuturor regulilor asociate este destul de ușor dacă fiecărei reguli i se acordă aceeași pondere.

Personal, cred că calcularea unei valori generale a calității datelor pentru un anumit domeniu de date este destul de complexă și tinde să fie cabalistică, dar ați putea să arătați cel puțin numărul de reguli generale grupate după rezultat pentru un domeniu de date (de exemplu, „100 de reguli DQ cu rezultate 90% verde, 5% galben și 5% roșu”).

Este sarcina proprietarului datelor să se asigure că rezultatele vor fi remediate și că calitatea datelor va fi îmbunătățită.

Îmbunătățirea proceselor

Deoarece procesele din depozitul de date se schimbă adesea, mecanismul de calitate a datelor necesită și întreținere.

Un proprietar de date ar trebui să aibă întotdeauna grijă de următoarele puncte:

• Ține-l la zi. Modificările din depozitul de date trebuie să fie cuprinse în sistemul calității datelor.
• Spori. Implementați reguli noi pentru erorile care nu sunt încă acoperite de regulile de calitate a datelor.
• Raționalizați. Dezactivați regulile de calitate a datelor care nu mai sunt necesare. Consolidați regulile care se suprapun.

Monitorizarea proceselor de calitate a datelor

Monitorizarea întregului proces de calitate a datelor ajută la îmbunătățirea acestuia în timp.

Lucruri care merită urmărite ar fi:

• Acoperirea datelor dvs. cu reguli de calitate a datelor
• Procentul de constatări privind calitatea datelor în cadrul regulilor active de-a lungul timpului
• Numărul de reguli active de calitate a datelor (Fii cu ochii pe el – am văzut utilizatorii de date rezolvându-și constatările pur și simplu dezactivând din ce în ce mai multe reguli de calitate a datelor.)
• Timpul necesar într-o încărcare de date pentru a avea toate constatările evaluate și fixate

Concluzie

Multe dintre următoarele puncte sunt importante în orice fel de proiect.

Anticipați rezistența. După cum am văzut, dacă nu există o problemă urgentă de calitate, calitatea datelor este adesea privită ca o povară suplimentară, fără a oferi noi funcționalități. Rețineți că ar putea crea o sarcină de lucru suplimentară pentru utilizatorii de date. În multe cazuri, cerințele de conformitate și de reglementare vă pot ajuta să convingeți utilizatorii să o vadă ca pe o cerință inevitabilă.

Găsiți un sponsor. După cum s-a menționat mai sus, DQ nu este un articol care se vând rapid, așa că este nevoie de un sponsor/părți interesate puternice - cu cât managementul este mai înalt, cu atât mai bine.

Găsiți aliați. Ca și în cazul sponsorului, oricine împărtășește ideea unei calități puternice a datelor ar fi de mare ajutor. Bucla de circuit DQ este un proces continuu și are nevoie de oameni pentru a menține bucla de circuit în viață.

Începe mic. Dacă nu a existat o strategie DQ până acum, căutați o unitate de afaceri care are nevoie de o calitate mai bună a datelor. Construiți un prototip pentru a le arăta beneficiile unor date mai bune. Dacă sarcina dvs. este să îmbunătățiți sau chiar să înlocuiți o anumită strategie de calitate a datelor, uitați-vă la lucrurile care funcționează bine/acceptate în organizație și păstrați-le.

Nu pierde din vedere întreaga imagine. Deși pornește de la mic, reține că unele puncte, în special rolurile, sunt premise pentru o strategie de DQ de succes.

Odată implementat, nu lăsați drumul. Procesul de calitate a datelor trebuie să facă parte din utilizarea depozitului de date. În timp, concentrarea asupra calității datelor tinde să se piardă puțin și depinde de tine să o menții.