Bagaimana Menerapkan Proses Kualitas Data

Kualitas Data (DQ) dalam sistem gudang data menjadi semakin penting. Meningkatnya persyaratan peraturan, tetapi juga semakin kompleksnya solusi gudang data, memaksa perusahaan untuk mengintensifkan (atau memulai) inisiatif kualitas data.

Fokus utama artikel ini adalah pada pergudangan data "tradisional", tetapi kualitas data juga menjadi masalah dalam konsep yang lebih "modern" seperti data lake. Ini akan menunjukkan beberapa poin utama untuk dipertimbangkan dan juga beberapa perangkap umum yang harus dihindari saat menerapkan strategi kualitas data. Itu tidak mencakup bagian dalam memilih teknologi/alat yang tepat untuk membangun kerangka kerja DQ.

Salah satu masalah yang paling mengganggu dari proyek DQ adalah kenyataan bahwa pada pandangan pertama, itu menciptakan banyak pekerjaan untuk unit bisnis tanpa menyediakan fungsionalitas tambahan. Inisiatif kualitas data biasanya hanya memiliki pendukung kuat jika:

• Ada masalah kualitas data dengan dampak parah pada bisnis.
• Badan pengatur menegakkan standar kualitas data (misalnya, BCBS 239 di industri keuangan).

Perlakuan DQ mirip dengan pengujian dalam pengembangan perangkat lunak—jika suatu proyek kehabisan waktu dan/atau anggaran, bagian ini cenderung dikurangi terlebih dahulu.

Ini, tentu saja, bukan seluruh kebenaran. Sistem kualitas data yang baik membantu mendeteksi kesalahan sejak dini, sehingga mempercepat proses pengiriman data dengan kualitas “cukup baik” kepada pengguna.

Definisi istilah

Sebelum membahas topik, pemahaman umum tentang istilah yang digunakan adalah penting.

Gudang Data (DWH)

Sebuah gudang data (DWH) adalah sistem non-operasional terutama digunakan untuk mendukung keputusan. Ini mengkonsolidasikan data sistem operasional (semuanya atau subset yang lebih kecil) dan menyediakan data yang dioptimalkan untuk kueri bagi pengguna sistem DWH. Gudang data harus menyediakan "satu versi kebenaran" di dalam perusahaan. Sebuah gudang data biasanya dibangun dari tahapan/lapisan:

Data operasional disimpan sebagian besar tidak berubah menjadi lapisan pementasan . Lapisan inti berisi data yang terkonsolidasi dan terpadu. Tahap opsional berikutnya adalah area derivasi , menyediakan data turunan (misalnya, skor pelanggan untuk penjualan) dan agregasi. Lapisan data mart berisi data yang dioptimalkan untuk sekelompok pengguna tertentu. Data mart sering berisi agregasi dan banyak metrik turunan. Pengguna gudang data sering kali hanya bekerja dengan lapisan data mart.

Di antara setiap tahap, beberapa jenis transformasi data terjadi. Biasanya, gudang data secara berkala dimuat dengan ekstraksi delta dari data operasional dan berisi algoritma untuk menyimpan data historis.

Kualitas data

Kualitas data biasanya didefinisikan sebagai metrik tentang seberapa baik suatu produk memenuhi persyaratan pengguna. Pengguna yang berbeda mungkin memiliki persyaratan yang berbeda untuk suatu produk sehingga penerapannya bergantung pada perspektif pengguna, dan penting untuk mengidentifikasi kebutuhan ini.

Kualitas data tidak berarti data harus sepenuhnya atau hampir bebas dari kesalahan—itu tergantung pada kebutuhan pengguna. Pendekatan "cukup baik" adalah pilihan yang baik untuk memulai. Saat ini, perusahaan besar memiliki “kebijakan data (atau informasi) pemerintah”, dan kualitas data adalah bagian darinya. Kebijakan pemerintah data harus menjelaskan bagaimana perusahaan Anda menangani data dan bagaimana memastikan bahwa data memiliki kualitas yang tepat dan bahwa aturan privasi data tidak dilanggar.

Kualitas data adalah topik yang sedang berlangsung. Sebuah loop sirkuit DQ harus diimplementasikan (lihat bab berikutnya). Persyaratan regulasi dan aturan kepatuhan juga berdampak pada kualitas data yang dibutuhkan, seperti TCPA (US Telephone Consumer Protection Act) atau GDPR di Eropa untuk masalah privasi, tetapi juga aturan khusus industri seperti Solvency II untuk asuransi di UE, BCBS 239 dan lain-lain untuk perbankan, dan sebagainya.

Loop Sirkuit Kualitas Data

Seperti semua topik kualitas, DQ adalah aktivitas berkelanjutan yang dirancang untuk mempertahankan kualitas yang memuaskan. Sebagai hasil dari proyek DQ, loop sirkuit yang mirip dengan yang di bawah ini harus diimplementasikan:

Langkah-langkah dalam loop ini akan dijelaskan dalam bab-bab berikutnya.

Peran Kualitas Data

Untuk mengimplementasikan inisiatif DQ yang sukses, peran berikut diperlukan:

• Pemilik Data. Pemilik data bertanggung jawab atas kualitas data, tetapi juga untuk perlindungan privasi data. Pemilik data “memiliki” domain data, mengontrol akses, dan bertanggung jawab untuk memastikan kualitas data dan mengambil tindakan untuk memperbaiki temuan. Di organisasi yang lebih besar, menemukan beberapa pemilik data adalah hal yang biasa. Domain data dapat berupa, misalnya, data pemasaran, data pengontrol, dll. Jika ada lebih dari satu pemilik data di sebuah perusahaan, harus ada satu orang (pemilik data atau orang lain) yang bertanggung jawab atas keseluruhan proses kualitas data. Pemilik data harus memiliki otoritas yang kuat untuk menegakkan kualitas data dan mendukung proses DQ; oleh karena itu, pemilik data seringkali merupakan pemangku kepentingan senior. Pemahaman yang baik tentang domain bisnis bersama dengan keterampilan komunikasi yang baik adalah penting.
• Penata Data. Penatalayan data membantu menerapkan kualitas data dalam suatu perusahaan, mendukung pengguna data pada pertanyaan tentang bagaimana menafsirkan data/model data, masalah kualitas data, dll. Penatalayan data sering kali adalah staf pemilik data atau dapat diatur di pusat kompetensi kualitas data atau tim DQ. Penatalayan data dapat memiliki latar belakang TI atau bisnis tetapi harus mengetahui kedua belah pihak. Keterampilan analitis bersama dengan pemahaman yang baik tentang domain bisnis yang mereka dukung, dikombinasikan dengan keterampilan komunikasi yang kuat, merupakan prasyarat utama untuk pengelola data yang sukses.
• Pengguna Data. Ini adalah pengguna gudang data yang bekerja dengan data. Pengguna data biasanya bekerja dengan lapisan data mart dan bertanggung jawab atas hasil kerja dengan data tersebut. Pengguna data memastikan ada pemeriksaan kualitas data yang memadai untuk tingkat kualitas yang mereka butuhkan. Pengguna data memerlukan pemahaman yang kuat tentang data mereka, domain bisnis, dan keterampilan analitis yang diperlukan untuk menafsirkan data. Masuk akal untuk menemukan beberapa orang di antara pengguna data di setiap unit bisnis yang akan bertanggung jawab atas masalah kualitas data.

Untuk memastikan kesuksesan, penting untuk memiliki peran ini dengan jelas dan diterima secara luas dalam organisasi Anda pada tahap awal proyek DQ Anda. Sama pentingnya untuk menemukan spesialis data yang kompeten untuk peran ini yang mendukung proyek.

Tentukan Aturan

Temukan dan terapkan pemeriksaan/aturan DQ yang berguna . Mendefinisikan aturan DQ membutuhkan pemahaman yang baik tentang gudang data Anda dan penggunaannya.

Bagaimana Menemukan Aturan DQ?

Seperti dibahas sebelumnya, pengguna data (dan pemilik data) bertanggung jawab atas penggunaan data dan oleh karena itu juga untuk tingkat kualitas data yang dibutuhkan. Pengguna data harus memiliki pemahaman yang baik tentang data mereka sehingga mereka dapat memberikan masukan terbaik untuk aturan kualitas data yang berguna.

Mereka juga yang menganalisis hasil aturan kualitas data, jadi sebaiknya biarkan mereka menentukan aturan mereka sendiri. Ini semakin meningkatkan penerimaan untuk memeriksa dan menilai hasil aturan DQ yang ditetapkan ke unit pengguna data (lihat bab "Analisis").

Kelemahan dari pendekatan ini adalah bahwa pengguna data biasanya hanya mengetahui lapisan data mart, bukan lapisan sebelumnya dari gudang data. Jika data rusak pada tahap "bawah", ini tidak akan terdeteksi dengan hanya memeriksa lapisan "atas" dari gudang data Anda.

Mengatasi Kesalahan

Apa jenis kesalahan yang diketahui mungkin terjadi di gudang data?

• Logika transformasi yang salah di gudang data
  • Semakin kompleks lanskap TI Anda, semakin kompleks logika transformasinya. Ini adalah masalah DQ yang paling umum, dan efek dari kesalahan tersebut dapat berupa data "hilang", duplikat, nilai yang salah, dll.
• Proses pemuatan yang tidak stabil atau penanganan muatan yang salah
  • Beban gudang data dapat menjadi proses kompleks yang mungkin mencakup kesalahan dalam definisi orkestrasi pekerjaan (pekerjaan dimulai terlalu dini atau terlambat, pekerjaan tidak dieksekusi, dll.). Kesalahan karena intervensi manual (misalnya, beberapa pekerjaan dilewati, beberapa pekerjaan dimulai dengan tanggal jatuh tempo yang salah atau dengan file data kemarin) sering terjadi ketika proses pemuatan kehabisan pita karena beberapa gangguan.
• Transfer data sumber data yang salah
  • Transfer data sering diimplementasikan sebagai tugas sistem sumber. Anomali atau gangguan dalam alur pekerjaan dapat menyebabkan pengiriman data kosong atau tidak lengkap.
• Data operasional salah
  • Data dalam sistem operasional mengandung kesalahan yang sejauh ini tidak dikenali. Ini mungkin terdengar aneh, tetapi merupakan hal yang tidak masuk akal dalam proyek-proyek gudang data bahwa kualitas data operasional seringkali tidak terlihat sampai data tersebut dimasukkan ke dalam DWH.
• Salah interpretasi data
  • Datanya benar, tetapi pengguna tidak tahu bagaimana menafsirkannya dengan benar. Ini adalah "kesalahan" yang sangat umum yang tidak sepenuhnya merupakan masalah kualitas data tetapi sesuatu yang berkaitan dengan tata kelola data dan merupakan tugas bagi pengelola data.

Masalah ini sering disebabkan oleh orang yang tidak memiliki pengetahuan dan keterampilan yang tepat untuk mendefinisikan, mengimplementasikan, menjalankan, dan bekerja dengan solusi gudang data.

Dimensi Kualitas Data

Dimensi DQ adalah cara umum untuk mengidentifikasi dan mengelompokkan pemeriksaan DQ. Ada banyak definisi, dan jumlah dimensi sangat bervariasi: Anda mungkin menemukan 16, atau bahkan lebih banyak dimensi. Dari perspektif praktis, tidak akan terlalu membingungkan untuk memulai dengan beberapa dimensi dan menemukan pemahaman umum tentang dimensi tersebut di antara pengguna Anda.

• Kelengkapan: Apakah semua data yang dibutuhkan tersedia dan dapat diakses? Apakah semua sumber yang dibutuhkan tersedia dan dimuat? Apakah data hilang di antara tahapan?
• Konsistensi: Apakah ada data yang salah/bertentangan/tidak konsisten? Misalnya, tanggal pemutusan kontrak dalam status "Dihentikan" harus berisi tanggal valid yang lebih tinggi atau sama dengan tanggal mulai kontrak.
• Keunikan: Apakah ada duplikat?
• Integritas: Apakah semua data terhubung dengan benar? Misalnya, apakah ada pesanan yang tertaut ke ID pelanggan yang tidak ada (masalah integritas referensial klasik)?
• Ketepatan waktu: Apakah data terkini? Misalnya, di gudang data dengan pembaruan harian, saya berharap data kemarin tersedia hari ini.

Data yang dihasilkan oleh proses pemuatan gudang data juga dapat membantu.

• Tabel dengan data yang dibuang. Gudang data Anda mungkin memiliki proses untuk melewati/menunda data yang tidak dapat dimuat karena masalah teknis (misalnya, konversi format, nilai wajib yang hilang, dll.).
• Informasi pencatatan. Masalah yang terlihat mungkin ditulis ke dalam tabel logging atau file log.
• Tagihan pengiriman. Beberapa sistem menggunakan "tagihan pengiriman" untuk data yang disediakan oleh sistem operasional (misalnya, jumlah catatan, jumlah kunci yang berbeda, jumlah nilai). Ini dapat digunakan untuk pemeriksaan rekonsiliasi (lihat di bawah) antara gudang data dan sistem operasional.

Ingatlah bahwa setiap pemeriksaan kualitas data harus dianalisis oleh setidaknya satu pengguna data (lihat bab "Analisis") jika kesalahan ditemukan, di mana Anda memerlukan seseorang yang bertanggung jawab dan tersedia untuk menjaga setiap pemeriksaan yang diterapkan.

Dalam gudang data yang kompleks, Anda mungkin berakhir dengan banyak (terkadang ribuan) aturan DQ. Proses untuk mengeksekusi aturan kualitas data harus kuat dan cukup cepat untuk menangani hal ini.

Jangan memeriksa fakta yang dijamin oleh implementasi teknis. Misalnya, jika data disimpan dalam DBMS relasional, tidak perlu memeriksa apakah:

• Kolom yang didefinisikan sebagai wajib berisi nilai NULL.
• Nilai bidang kunci utama bersifat unik dalam sebuah tabel.
• Tidak ada kunci asing yang ada dalam tabel dengan pemeriksaan integritas relasional yang diaktifkan.

Karena itu, selalu ingat bahwa gudang data selalu berubah dan definisi data bidang dan tabel mungkin berubah seiring waktu.

Tata graha sangat penting. Aturan yang ditentukan oleh unit pengguna data yang berbeda mungkin tumpang tindih dan harus digabungkan. Semakin kompleks organisasi Anda, semakin banyak housekeeping yang dibutuhkan. Pemilik data harus menerapkan proses konsolidasi aturan sebagai semacam "kualitas data untuk aturan kualitas data". Selain itu, pemeriksaan kualitas data mungkin menjadi tidak berguna jika data tidak lagi digunakan atau jika definisinya telah berubah.

Kelas Aturan Kualitas Data

Aturan kualitas data dapat diklasifikasikan berdasarkan jenis tesnya.

• Pemeriksaan kualitas data. Kasus "normal", memeriksa data dalam satu lapisan gudang data (lihat Gambar 1) baik dalam satu tabel atau satu set tabel.
• Rekonsiliasi. Aturan yang memeriksa apakah data diangkut dengan benar di antara lapisan gudang data (lihat Gambar 1). Aturan-aturan ini sebagian besar digunakan untuk memeriksa dimensi DQ dari "Kelengkapan." Rekonsiliasi dapat menggunakan satu baris atau pendekatan yang diringkas. Memeriksa satu baris jauh lebih terperinci, tetapi Anda harus mereproduksi langkah-langkah transformasi (pemfilteran data, perubahan nilai bidang, denormalisasi, penggabungan, dll.) di antara lapisan yang dibandingkan. Semakin banyak lapisan yang Anda lewati, semakin kompleks logika transformasi yang harus diterapkan. Oleh karena itu, merupakan pilihan yang baik untuk melakukan rekonsiliasi antara setiap lapisan dan pendahulunya daripada membandingkan staging dengan lapisan data mart. Jika transformasi harus diimplementasikan dalam aturan rekonsiliasi, gunakan spesifikasinya, bukan kode gudang datanya! Untuk rekonsiliasi yang diringkas, temukan bidang yang bermakna (misalnya, peringkasan, jumlah nilai yang berbeda, dll.).
• Pemantauan. Sebuah gudang data biasanya berisi data historis dan dimuat dengan ekstrak delta data operasional. Ada bahaya kesenjangan yang perlahan meningkat antara gudang data dan data operasional. Membuat ringkasan data deret waktu membantu mengidentifikasi masalah seperti ini (misalnya, membandingkan data bulan lalu dengan data bulan ini). Pengguna data dengan pengetahuan yang baik tentang data mereka dapat memberikan ukuran dan ambang batas yang berguna untuk aturan pemantauan.

Bagaimana Mengukur Masalah Kualitas Data

Setelah Anda menentukan apa yang harus diperiksa, Anda harus menentukan bagaimana mengukur masalah yang diidentifikasi. Informasi seperti "lima baris data melanggar aturan DQ dengan ID 15" tidak masuk akal untuk kualitas data.

Bagian-bagian berikut tidak ada:

• Bagaimana mengukur/menghitung kesalahan yang terdeteksi. Anda mungkin menghitung "jumlah baris", tetapi Anda juga dapat menggunakan skala moneter (misalnya, eksposur). Ingatlah bahwa nilai moneter mungkin memiliki tanda yang berbeda, jadi Anda harus menyelidiki cara meringkasnya secara bermakna. Anda dapat mempertimbangkan untuk menggunakan kedua unit kuantifikasi (jumlah baris dan ringkasan) untuk aturan kualitas data.
• Populasi. Berapa jumlah unit yang diperiksa oleh aturan kualitas data? "Lima baris data dari lima" memiliki kualitas yang berbeda dari "lima dari 5 juta." Populasi harus diukur menggunakan kuantifikasi yang sama seperti untuk kesalahan. Adalah umum untuk menampilkan hasil aturan kualitas data sebagai persentase. Populasi tidak boleh identik dengan jumlah baris dalam sebuah tabel. Jika aturan DQ hanya memeriksa sebagian data (misalnya, hanya kontrak yang dihentikan dalam tabel kontrak), filter yang sama harus diterapkan untuk mengukur populasi.
• Definisi hasil. Meskipun pemeriksaan kualitas data menemukan masalah, hal ini tidak selalu menyebabkan kesalahan. Untuk kualitas data, sistem lampu lalu lintas (merah, kuning, hijau) yang menggunakan nilai ambang batas untuk menilai temuan sangat membantu. Misalnya, hijau: 0-2%, kuning: 2-5%, merah: di atas 5%. Perlu diingat bahwa jika unit pengguna data memiliki aturan yang sama, mereka mungkin memiliki ambang batas yang sangat berbeda untuk aturan tertentu. Unit bisnis pemasaran mungkin tidak keberatan kehilangan beberapa pesanan, sedangkan unit akuntansi mungkin keberatan bahkan sen. Seharusnya dimungkinkan untuk menentukan ambang batas berdasarkan persentase atau angka absolut.
• Kumpulkan contoh baris kesalahan. Ini membantu jika aturan kualitas data memberikan contoh kesalahan yang terdeteksi—biasanya, kunci (bisnis!) dan nilai data yang diperiksa cukup untuk membantu memeriksa kesalahan. Sebaiknya batasi jumlah baris kesalahan tertulis untuk aturan kualitas data.
• Terkadang, Anda mungkin menemukan "kesalahan yang diketahui" dalam data yang tidak akan diperbaiki tetapi ditemukan dengan pemeriksaan kualitas data yang berguna. Untuk kasus ini, penggunaan daftar putih (kunci catatan yang harus dilewati oleh pemeriksaan kualitas data) direkomendasikan.

Metadata lainnya

Metadata penting untuk mengarahkan "Analisis" dan memantau fase loop kontrol kualitas data.

• Item yang diperiksa. Ini membantu untuk menetapkan tabel dan bidang yang dicentang ke aturan kualitas data. Jika Anda memiliki sistem metadata yang disempurnakan, ini mungkin membantu untuk secara otomatis menetapkan pengguna data dan pemilik data ke aturan ini. Untuk alasan regulasi (seperti BCBS 239), perlu juga dibuktikan bagaimana data diperiksa oleh DQ. Namun, menetapkan aturan secara otomatis ke pengguna data/pemilik data melalui garis keturunan data (*) mungkin merupakan pedang bermata dua (lihat di bawah).
• pengguna data. Setiap aturan DQ harus memiliki setidaknya satu pengguna data/unit pengguna data yang ditugaskan untuk memeriksa hasil selama fase "Analisis" dan memutuskan apakah dan bagaimana temuan memengaruhi pekerjaan mereka dengan data.
• pemilik data. Setiap aturan DQ harus memiliki pemilik data yang ditetapkan.

(*) Garis keturunan data menunjukkan aliran data antara dua titik. Dengan garis keturunan data, Anda dapat menemukan semua elemen data yang memengaruhi bidang target tertentu di dalam gudang Anda.

Menggunakan garis keturunan data untuk menetapkan pengguna ke aturan bisa menjadi masalah. Seperti disebutkan sebelumnya, pengguna bisnis biasanya hanya mengetahui lapisan data mart (dan sistem operasi), tetapi tidak pada tingkat yang lebih rendah dari gudang data. Dengan memetakan melalui garis keturunan data, pengguna data akan diberi aturan yang tidak mereka ketahui. Untuk tingkat yang lebih rendah, staf TI mungkin diperlukan untuk mengevaluasi temuan kualitas data. Dalam banyak kasus, pemetaan manual atau pendekatan campuran (pemetaan melalui garis keturunan data hanya dalam data mart) dapat membantu.

Mengukur Kualitas Data

Mengukur kualitas data berarti menjalankan aturan kualitas data yang tersedia, yang harus dilakukan secara otomatis , dipicu oleh proses pemuatan data warehouse. Seperti yang telah kita lihat sebelumnya, mungkin ada sejumlah besar aturan kualitas data, sehingga pemeriksaan akan memakan waktu.

Di dunia yang sempurna, gudang data akan dimuat hanya jika semua data bebas dari kesalahan. Di dunia nyata, ini jarang terjadi (secara realistis, hampir tidak pernah terjadi). Bergantung pada strategi pemuatan keseluruhan gudang data Anda, proses kualitas data harus atau tidak (yang terakhir jauh lebih mungkin) mengatur proses pemuatan. Ini adalah desain yang baik untuk memiliki proses kualitas data (jaringan pekerjaan) paralel dan terkait dengan proses pemuatan gudang data "biasa".

Jika ada perjanjian tingkat layanan yang ditentukan, pastikan untuk tidak menggagalkan pemuatan gudang data dengan pemeriksaan kualitas data. Kesalahan/kelebihan dalam proses kualitas data seharusnya tidak menghentikan proses pemuatan reguler. Kesalahan tak terduga dalam proses kualitas data harus dilaporkan dan ditampilkan untuk fase "Analisis" (lihat bab berikutnya).

Ingatlah bahwa aturan kualitas data mungkin macet karena kesalahan yang tidak terduga (mungkin aturan itu sendiri salah diterapkan, atau struktur data yang mendasarinya berubah seiring waktu). Akan membantu jika sistem kualitas data Anda menyediakan mekanisme untuk menonaktifkan aturan tersebut, terutama jika perusahaan Anda memiliki sedikit rilis per tahun.

Proses DQ harus dijalankan dan dilaporkan sedini mungkin — idealnya, tepat setelah data yang diperiksa dimuat. Ini membantu mendeteksi kesalahan sedini mungkin selama pemuatan gudang data (beberapa beban sistem gudang yang kompleks memiliki durasi beberapa hari).

Menganalisa

Dalam konteks ini, "menganalisis" berarti bereaksi terhadap temuan kualitas data. Ini adalah tugas untuk pengguna data yang ditetapkan dan pemilik data.

Cara bereaksi harus ditentukan dengan jelas oleh proyek kualitas data Anda. Pengguna data harus berkewajiban untuk mengomentari aturan dengan temuan (setidaknya aturan dengan lampu merah), menjelaskan tindakan apa yang diambil untuk menangani temuan tersebut. Pemilik data perlu diberi tahu dan harus memutuskan bersama dengan pengguna data.

Tindakan berikut dimungkinkan:

• Masalah serius: Masalah harus diperbaiki dan pemuatan data diulang.
• Masalah dapat diterima: Coba perbaiki untuk pemuatan data di masa mendatang dan tangani masalah dalam gudang data atau pelaporan.
• Aturan DQ yang rusak: Perbaiki aturan DQ yang bermasalah.

Di dunia yang sempurna, setiap masalah kualitas data akan diperbaiki. Namun, kurangnya sumber daya dan/atau waktu sering kali menghasilkan solusi.

Agar dapat bereaksi tepat waktu, sistem DQ harus memberi tahu pengguna data tentang aturan "mereka" dengan temuan. Menggunakan dasbor kualitas data (mungkin dengan mengirim pesan bahwa ada sesuatu yang muncul) adalah ide yang bagus. Semakin awal pengguna diberitahu tentang temuan, semakin baik.

Dasbor kualitas data harus berisi:

• Semua aturan yang ditetapkan untuk peran tertentu
• Hasil aturan (lampu lalu lintas, ukuran, dan baris contoh) dengan kemampuan untuk memfilter aturan berdasarkan domain hasil dan data
• Komentar wajib yang harus dimasukkan pengguna data untuk temuan
• Fitur untuk "mengabaikan" hasil secara opsional (jika aturan kualitas data melaporkan kesalahan karena penerapan yang salah, misalnya). Jika lebih dari satu unit bisnis memiliki aturan kualitas data yang sama, "pengesampingan" hanya berlaku untuk unit bisnis pengguna data (bukan seluruh perusahaan).
• Menampilkan aturan yang tidak dijalankan atau yang diubah

Dasbor juga harus menunjukkan status terkini dari proses pemuatan gudang data terkini, memberikan pengguna pandangan 360 derajat tentang proses pemuatan gudang data.

Pemilik data bertanggung jawab untuk memastikan bahwa setiap temuan telah dikomentari dan status kualitas data (asli atau ditolak) setidaknya berwarna kuning untuk semua pengguna data.

Untuk gambaran singkat, akan membantu untuk membangun semacam KPI sederhana (indikator kinerja utama) untuk pengguna data/pemilik data. Memiliki lampu lalu lintas keseluruhan untuk semua hasil aturan terkait cukup mudah jika setiap aturan diberi bobot yang sama.

Secara pribadi, saya pikir menghitung nilai keseluruhan kualitas data untuk domain data tertentu agak rumit dan cenderung kabalis, tetapi Anda setidaknya dapat menunjukkan jumlah aturan keseluruhan yang dikelompokkan berdasarkan hasil untuk domain data (mis., “100 aturan DQ dengan hasil 90% hijau, 5% kuning, dan 5% merah").

Adalah tugas pemilik data untuk memastikan bahwa temuan akan diperbaiki dan kualitas data ditingkatkan.

Meningkatkan Proses

Karena proses data warehouse sering berubah, mekanisme kualitas data juga membutuhkan pemeliharaan.

Pemilik data harus selalu memperhatikan hal-hal berikut:

• Tetap perbarui. Perubahan dalam gudang data perlu ditangkap dalam sistem kualitas data.
• Meningkatkan. Terapkan aturan baru untuk kesalahan yang belum tercakup dalam aturan kualitas data.
• Mempersingkat. Nonaktifkan aturan kualitas data yang tidak lagi diperlukan. Konsolidasi aturan yang tumpang tindih.

Memantau Proses Kualitas Data

Memantau seluruh proses kualitas data membantu meningkatkannya dari waktu ke waktu.

Hal-hal yang layak ditonton adalah:

• Cakupan data Anda dengan aturan kualitas data
• Persentase temuan kualitas data dalam aturan aktif dari waktu ke waktu
• Jumlah aturan kualitas data yang aktif (Awasi terus—Saya telah melihat pengguna data memecahkan temuan mereka hanya dengan menonaktifkan lebih banyak aturan kualitas data.)
• Waktu yang diperlukan dalam pemuatan data agar semua temuan dinilai dan diperbaiki

Kesimpulan

Banyak dari poin-poin berikut ini penting dalam segala jenis proyek.

Antisipasi resistensi. Seperti yang telah kita lihat, jika tidak ada masalah kualitas yang mendesak, kualitas data sering dianggap sebagai beban tambahan tanpa menawarkan fungsionalitas baru. Perlu diingat bahwa itu mungkin membuat beban kerja tambahan untuk pengguna data. Dalam banyak kasus, kepatuhan dan tuntutan peraturan dapat membantu Anda meyakinkan pengguna untuk melihatnya sebagai persyaratan yang tidak dapat dihindari.

Cari sponsor. Seperti disebutkan di atas, DQ bukanlah barang yang cepat laku, sehingga diperlukan sponsor/stakeholder yang kuat—semakin tinggi manajemennya, semakin baik.

Temukan sekutu. Seperti halnya sponsor, siapa pun yang berbagi gagasan tentang kualitas data yang kuat akan sangat membantu. Loop sirkuit DQ adalah proses yang berkelanjutan dan membutuhkan orang untuk menjaga agar loop sirkuit tetap hidup.

Mulai dari yang kecil. Jika selama ini belum ada strategi DQ, carilah unit bisnis yang membutuhkan kualitas data yang lebih baik. Bangun prototipe untuk menunjukkan kepada mereka manfaat dari data yang lebih baik. Jika tugas Anda adalah meningkatkan atau bahkan mengganti strategi kualitas data yang diberikan, lihat hal-hal yang berfungsi dengan baik/diterima di organisasi, dan pertahankan.

Jangan lupakan keseluruhan gambar. Meskipun memulai dari yang kecil, perlu diingat bahwa beberapa poin, terutama peran, merupakan prasyarat untuk strategi DQ yang sukses.

Setelah diterapkan, jangan lepaskan. Proses kualitas data perlu menjadi bagian dari penggunaan data warehouse. Seiring waktu, fokus pada kualitas data cenderung sedikit hilang, dan terserah Anda untuk mempertahankannya.