Membangun perusahaan impian: manajemen kualitas data

Kesalahan termahal dalam sejarah, yang disebabkan oleh data awal yang salah, dianggap sebagai jatuhnya roket Ariane 5. Kerusakan total akibat insiden ini diperkirakan mencapai $ 0,5 miliar pada harga awal tahun 1996.



Hal lainnya, mungkin yang paling membuat penasaran, adalah kesalahan dalam pesanan besar dari jalur kereta api Prancis SNCF sebanyak 2 ribu kereta pada tahun 2014. Tim yang membentuk persyaratan teknis secara pribadi mengukur dimensi celemek di beberapa lusin stasiun. Ingin meningkatkan kenyamanan, mereka menyetel lebar komposisi kembali ke semaksimal mungkin. Mereka melakukan pengukuran di sekitar Paris - dan bahwa di wilayah di banyak stasiun, apron lebih dekat ke trek, mereka sudah mempelajarinya selama pengujian. Harga kesalahan adalah modernisasi seluruh infrastruktur seharga ratusan juta euro. Mereka akan berada di sana MDM dengan karakteristik stasiun ...



gambar



Ini diikuti oleh sejumlah besar kesalahan pertukaran dan perbankan, ketika data yang salah dalam detail, dalam jumlah dan nilai saham yang ditempatkan menyebabkan kerugian miliaran dolar atau bahkan kebangkrutan.



Artikel ini melanjutkan artikel " data master dan integrasi " - dan secara lebih rinci membahas masalah pengendalian kualitas data, terutama - data master. Artikel ini akan menjadi minat khusus bagi para eksekutif IT, arsitek, integrator, serta semua orang yang bekerja di perusahaan yang cukup besar.



Kandungan



1. Kamus, jenis data bisnis: data master, informasi referensi regulasi, data operasional.

2. Secara singkat tentang kesalahan apa saja.

3. Arsitektur solusi DQS.

4. Metode teknis dan non-teknis untuk menangani kesalahan:

4.1. NSI.

4.2. Data master.

4.3. Sistem operasi.

5. Apa yang harus dilakukan jika semua hal di atas tidak membantu - menerapkan DQS.

6. Dan bagaimana berbagi tanggung jawab?



Jika Anda sudah terbiasa dengan terminologi dan masalah, langsung saja ke Bagian 3, pada arsitektur DQS.



1. Kamus, jenis data bisnis



Selama beberapa dekade sekarang, penginjil TI telah meyakinkan kami bahwa data adalah minyak baru. Bahwa bisnis apa pun semakin bergantung pada informasi yang dimilikinya. Departemen analitik dan data muncul tidak hanya di perusahaan IT, tetapi juga di sektor industri dan industri sejauh mungkin dari "gambar".



Banyak orang sudah muak dengan contoh bagaimana General Electric dan Boeing membuat anak perusahaan "digital" dan mendapatkan sejumlah besar informasi yang dikumpulkan dari pemilik peralatan mereka - pesawat terbang, turbin, pembangkit listrik. Data ini memungkinkan mereka untuk meningkatkan keandalan peralatan, memprediksi kemungkinan kegagalan, sangat menghemat potensi kerusakan, dan akhirnya, menyelamatkan nyawa orang!



Data menjadi semakin banyak, dan akumulasinya bergantung secara nonlinier pada pertumbuhan bisnis, pertumbuhan melampaui batas. Setiap perusahaan yang sedang tumbuh pada tahap perkembangannya (kira-kira pada level 6-7 pada skala dari artikel sebelumnya ) menghadapi masalah dengan data yang salah, dan selalu ada beberapa kasus ketika biaya kesalahan ini ternyata cukup tinggi.



gambar

Gambaran tradisional tentang pertumbuhan data hampir selalu eksponensial.



Dalam perjalanan bisnis, tiga jenis data sangat penting bagi perusahaan:



  • - β€” , , . , ( : , , ), , , ..;
  • - () β€” -, . , : () , , , ;
  • data operasional (alias transaksional) - fakta penjualan produk tertentu ke klien tertentu, faktur dan tindakan, kursus yang diambil, pesanan kurir, dan naik taksi - tergantung pada apa yang dilakukan perusahaan Anda.


Jika NSI dapat dibandingkan dengan kerangka penyangga, master data dengan vena dan arteri, maka sistem operasinya adalah darah yang mengalir melalui vena tersebut.



Diferensiasi jenis data bisnis diperlukan karena masing-masing memiliki pendekatan sendiri untuk menangani kesalahan, tentang hal ini di bawah ini.



gambar



2. Secara singkat tentang kesalahan apa saja



Kesalahan tidak bisa dihindari, kesalahan muncul selalu dan di mana-mana, dan, tampaknya, mencerminkan sifat alam semesta yang kacau balau itu sendiri. Anda dapat menganggap mereka sebagai sesuatu yang buruk, menjadi kesal karenanya, tetapi pikirkanlah: kesalahan adalah inti dari evolusi! Ya, setiap spesies berikutnya adalah spesies sebelumnya dengan beberapa kesalahan acak pada DNA, hanya konsekuensi kesalahan ini yang ternyata berguna dalam kondisi tertentu.


Jenis kesalahan utama yang diderita bisnis:



  • faktor manusia. Semua jenis kesalahan ketik, bidang yang membingungkan, dan informasi yang salah tempat. Tindakan dan langkah yang terlupa atau tidak sengaja terlewat saat memasukkannya (Anda juga memiliki 50 bidang di kartu pelanggan Anda?) Secara statis, ini adalah jenis kesalahan yang paling mungkin terjadi, sehingga frekuensi dan efeknya mungkin menjadi yang terbesar. Untungnya, sejumlah besar metode telah ditemukan untuk memerangi mereka;
  • . , , . , β€” , . , , . … , , ? , , , CRM : ! !
  • kesalahan yang disengaja. Karyawan itu dengan sengaja mentransfer beberapa juta untuk dirinya sendiri - dan menghilang. Ini, tentu saja, contoh ekstrem, kejahatan, tetapi ada banyak langkah yang harus ditempuh untuk menanganinya. Misalnya, salah satu pelanggan di CRM diberi diskon tinggi yang tidak semestinya atau biaya item ditetapkan di bawah harga biaya.


Dan jika yang ketiga adalah subjek dari layanan keamanan informasi, ia memiliki metodenya sendiri, maka kami akan bekerja secara substantif dengan faktor manusia dan ketidaklengkapan.



3. Arsitektur solusi DQS



DQM - manajemen kualitas data, manajemen kualitas data.

DQS - sistem kualitas data, sistem kualitas [manajemen] data.


Sebelum berbicara langsung tentang sistem manajemen kualitas data (DQS bukan perangkat lunak khusus sebagai pendekatan untuk bekerja dengan data), saya akan menjelaskan arsitektur TI.



Biasanya, pada saat masalah manajemen kualitas data muncul, lanskap TI adalah sebagai berikut:



gambar

(diagram dari artikel sebelumnya)



Di mana MDM adalah sistem untuk memelihara data master dan peraturan, dan ESB adalah bus data perusahaan tunggal. Situasi yang sering terjadi adalah ketika tidak semua aliran data dan informasi antar sistem masih terlibat dalam loop bersama, dan beberapa sistem berkomunikasi secara langsung satu sama lain - ini perlu diselesaikan, jika tidak sejumlah proses akan menjadi "titik buta" untuk DQS.



Secara tradisional, pada tahap pertama, DQS dihubungkan ke sistem MDM, karena manajemen kualitas data master dianggap sebagai prioritas yang lebih tinggi daripada sistem operasi. Namun, di masa mendatang, ini dimasukkan dalam bus data umum sebagai salah satu tahapan proses, atau menyajikan "layanan" -nya dalam format API. Dalam gambar konkret, ada kira-kira perbedaan sepuluh kali lipat dalam jumlah data antara skema pertama dan kedua, atau satu tingkat pada skala dari artikel sebelumnya.



4. Metode teknis dan non-teknis untuk menangani kesalahan.



Kalimat berikutnya akan berisi pemikiran paling menyedihkan dari artikel ini. Tidak ada peluru perak. Tidak ada tombol atau sistem seperti itu yang Anda masukkan dan kesalahan akan hilang. Secara umum, tidak ada solusi sederhana dan tidak ambigu untuk masalah kompleks ini. Apa yang berfungsi dengan baik untuk satu tampilan atau kumpulan data tidak akan berguna untuk tampilan atau kumpulan data lainnya.



Namun, kabar baiknya adalah rangkaian metode teknis dan organisasi yang diuraikan dalam artikel di bawah ini akan mengurangi kesalahan secara drastis. Perusahaan yang menerapkan pendekatan DQM mengurangi jumlah kesalahan yang terdeteksi sebanyak 50-500 kali. Angka spesifik adalah hasil dari keseimbangan yang wajar antara efek, biaya, dan kegunaan.



4.1. Informasi referensi.



Dalam kasus informasi normatif dan referensi (pada kenyataannya, pengklasifikasi negara), ada solusi kategoris maksimal, dan bersifat universal: Anda tidak harus memelihara dokumen normatif sendiri! Tidak pernah, dalam keadaan apa pun!



Standar harus selalu dan secara ketat dimuat dari sumber eksternal, dan tugas utama Anda adalah menerapkan pemuatan tersebut dan menetapkan pemantauan operasional jika terjadi kegagalan.



#1. . : ( ), ( ), ( ).



, , ( - ) . , β€” ( ).



, : . - , . , . , , … .



( β€” ), (), (), (), , ( ) β€” API , .


Sebagai hasil dari langkah-langkah ini, tidak seorang pun di perusahaan Anda boleh berpikir untuk memasukkan, misalnya, nilai tukar dolar / rubel untuk kemarin secara manual. Hanya pilihan dari panduan yang diunduh dari sumber resmi.



gambar



Sifat kategoris dari poin ini disebabkan oleh kenyataan bahwa implementasinya menghilangkan hampir semua kesalahan dalam norma. Dan jika kesalahan dalam data master tidak dapat diatasi sepenuhnya, maka dalam NSI dengan cara ini dimungkinkan untuk mengurangi jumlah kesalahan menjadi satu atau dua per tahun - dan ini bukan lagi kesalahan Anda, tetapi kesalahan dalam data negara.



4.2. Data master



Strategi utama untuk data master mungkin terdengar paradoks: mengubahnya menjadi normatif!



#2. β€” , ( 5-6 β€” , ).



MDM, : , . β€” .



, . . . (, , ) β€” (). β€” . -, (, -). , , .



, . , .
#3. , . , , . , , .



- . ? β€” . . : . , .



Kelanjutan alami dari cerita ini adalah aliran dokumen personel elektronik - buku kerja elektronik, cuti sakit elektronik, dll., Yang secara signifikan akan menghemat biaya tenaga kerja untuk petugas personalia. Dalam batas, ini akan memungkinkan satu petugas personel untuk melayani bukan 200-300 karyawan, tetapi 1000+.



Selain itu, semua karyawan secara otomatis menerima kunci tanda tangan elektronik - dan akan dapat menggunakannya baik dalam proses bisnis internal maupun dalam manajemen dokumen dengan klien.



Informasi tentang hutang, keyakinan, dll. tersedia dalam bentuk terbuka melalui API acc. layanan pemerintah, integrasi dengan mereka sangat sederhana, dan akan memungkinkan perusahaan Anda menutup sejumlah besar risiko sekaligus.


4.3. Sistem operasi



Sudah ada lebih banyak pendekatan di sini. Yang pertama mirip dengan yang sebelumnya - untuk menghubungkan sumber informasi eksternal.



#4. β€” , β€” , β€” β€” . - ? .



. . , β€” , . , , .. .



β€” -. , . ( , !)



(, ).



, - - ? ( , ) β€” . , -, , .
#5. : , .



β€” , , -, ( , ). -, API , . β€” , . .. , .


Ya, tidak dalam semua proses, sumber informasi yang diperlukan dapat ditemukan dengan cepat; diperlukan penelusuran dan analitik. Selain itu, sumber mungkin ternyata dibayar, dan kemudian pro dan kontranya dipertimbangkan, tetapi pendekatannya berhasil dan telah berulang kali diuji dalam praktiknya.



Informasi (data) adalah minyak baru, dan semua negara bagian berusaha keras untuk mendapatkan informasi sebanyak mungkin tentang subjek mereka, termasuk bisnis, tentang semua proses di mana mereka berpartisipasi.



Bahkan sulit bagi kami untuk membayangkan informasi apa yang dikumpulkan negara, saya hanya dapat mengatakan bahwa pada saat penulisan ini, sekitar 20 ribu set data disajikan di portal data terbuka Rusia. Dan Rusia baru berada di awal jalur ini, jadi, di portal serupa di Uni Eropa, lebih dari satu juta set data terbuka tersedia!



gambar

www.europeandataportal.eu/en



- Di manakah DQS di sini, - pembaca yang cermat akan bertanya?



Dan belum ada apa-apa tentang dia.



Faktanya, semua hal di atas adalah alat dan metode standar untuk mengatur proses bisnis dengan jumlah kesalahan minimum.



5. Apa yang harus dilakukan jika semua hal di atas tidak membantu - menerapkan DQS



Sun Tzu mengajarkan bahwa pertempuran terbaik adalah yang dihindari.


Situasi dengan implementasi DQS agak mirip.



Tugas Anda adalah mencoba memaksimalkan transformasi data master dan bahkan sistem operasi menjadi data referensi, dan di beberapa industri, terutama di sektor jasa, ini hampir 100% mungkin. Yang terpenting di sektor perbankan, oleh karena itu, tingkat otomatisasi proses bisnis di dalamnya jauh lebih besar daripada yang lainnya.



Meski demikian, jika pertempuran tidak dapat dihindari, Anda perlu mempersiapkannya sebaik mungkin.



Pada tingkat pengembangan perusahaan manakah DQS harus diperkenalkan? Sebagai proses DQM - dengan 4-5 (lebih awal dari sistem MDM!), Sebagai fungsi khusus organisasi - di 7-8.



5.1. DQM sebagai proses



Jika perusahaan Anda memiliki sistem akuntansi atau personalia, maka Anda akan memiliki proses DQM dalam beberapa bentuk. Semua sistem ini memiliki seperangkat aturan bawaan untuk data masukan. Misalnya, format tanggal lahir yang wajib dan ketat untuk karyawan, nama wajib untuk rekanan.



Tugas Anda pada tahap ini adalah membangun proses DQM. Dia selanjutnya:



  • buat aturan;
  • menguji aturan untuk penerapan dan kecukupan, mengujinya pada kasus-kasus;
  • mengembangkan regulasi untuk penerapan aturan, berkomunikasi dengan pengguna, membenarkan;
  • diimplementasikan ke dalam produksi;
  • memantau upaya untuk menghindari aturan tersebut.


Jika Anda telah berhasil menerapkan MDM di perusahaan, maka poin dari kedua dan seterusnya seharusnya tidak menimbulkan kesulitan khusus bagi Anda, ini adalah pekerjaan sistematis saat ini.



Kesulitan terbesar dalam kasus ini muncul dengan membuat aturan baru.



5.2. aturan



Jika untuk entitas seperti nama lengkap, imajinasi Anda terbatas pada nama wajib dan nama belakang, dan untuk tanggal - untuk memeriksa "tidak lebih dari seratus tahun", jangan berkecil hati!



Ada teknik hebat untuk mengembangkan aturan baru guna menguji data yang paling tak terbayangkan. Untuk menguasainya, Anda tidak perlu berada tujuh inci di dahi - dan, seperti yang diperlihatkan oleh praktik, setiap sistem pemula atau analis bisnis, bahkan operator yang memasukkan data master, dapat menguasainya.



Sebenarnya, ini adalah skrip langkah demi langkah, yang pada input memiliki definisi data Anda, dan pada output - serangkaian aturan untuk semua kesempatan. Teknik tersebut, yang dikenal sebagai taksonomi data kotor, dikembangkan oleh sekelompok ilmuwan data Eropa pada awal abad ke-21.



Inti dari pendekatan, serta contoh praktis, diberikan dalam artikel sistem mereka, untungnya sudah diterbitkan dalam terjemahan di sini di HabrΓ© - habr.com/ru/post/548164



Jika masalah kualitas data bukan frasa kosong untuk Anda , kemudian setelah membaca artikel itu dengan cermat, Anda akan menemukan diri Anda dalam keadaan hampir mencapai nirwana :)



Contoh # 6 . Pengetikan yang kuat. Jika tipe data "tanggal" digunakan dalam referensi, maka struktur tanggal harus dibuat sejelas mungkin. Jika Anda memutuskan untuk menghemat dua detik untuk operator, dan membuat template seperti β€œ__.__.__” dengan petunjuk β€œhari, bulan, tahun”, pastikan pada hari pertama mencatat β€œ18.04.21”, β€œ 21.04.18 "dan" 04.18.21 ".


Cara yang baik untuk memasukkan tanggal adalah tiga bidang dengan sebutan eksplisit (hari, bulan, tahun) dan lompatan cepat saat memasukkan dua angka di setiap bidang. Jika Anda pernah membayar sesuatu dengan kartu di Internet, Anda akan mengerti.



Contoh # 7 . Karakter terlarang dalam daftar bidang seluas mungkin, pemeriksaan kamus. Misalnya, jika kita berbicara tentang pendidikan (posisi), dan pengklasifikasi spesialisasi tidak membantu, Anda mengizinkan pengguna untuk memasukkan data di bidang teks, meskipun titik, tanda kutip, dan tanda hubung bebas dilarang di sana ( daftar tidak lengkap). Contoh informasi yang kualitasnya semakin meningkat: β€œDoctor of Technical Sciences”, β€œDoctor of Technical Sciences”, β€œDTN”, β€œDr. sains ”, dll.




#8. (NULL) β€” . , / , / β€” , . β€” β€œ ”.



, , . , β€œβ€, β€œβ€, β€œβ€, β€œβ€ ( .) , , . (β€œ ”, β€œ, ”) (β€œ ”, β€œ-”, β€œ ”). β€” . , , β€œβ€ β€œβ€ β€” , β€” . β€œβ€, β€œβ€β€¦



, , . , , , .


6. DQS?



Dalam masalah manajemen dan tanggung jawab, tidak ada jawaban yang benar; sebaliknya, semuanya tergantung pada tim dan individu tertentu. Seorang insinyur roket mungkin menjadi kepala akuntan, seorang seniman mungkin menjadi direktur keuangan, dan seorang guru sekolah dasar mungkin menjadi kepala keamanan.



Pertanyaan tentang tanggung jawab untuk proses DQM sebenarnya lebih umum: siapa yang bertanggung jawab atas kualitas data di perusahaan? Secara tradisional, pengguna bisnis dan departemen TI bertindak sebagai antagonis dalam menjawab pertanyaan ini.



Bisnis sering memulai dialog dengan pernyataan "kami melihat ada kesalahan dalam sistem data meteor Anda".



Layanan TI, di sisi lain, percaya bahwa tugasnya adalah memastikan kelancaran sistem, dan data spesifik apa yang dimasukkan pengguna bisnis ke dalam sistem adalah tanggung jawab bisnis.



Menetapkan proses DQM yang berfungsi dan menjalankan DQS adalah kompromi yang memuaskan kedua belah pihak. Tantangan bagi TI dan analis adalah mengembangkan sebanyak mungkin aturan dan batasan pada input data untuk meminimalkan risiko kesalahan.



Sikap β€œbisnis” biasanya disebabkan oleh kurangnya transparansi dalam proses DQM. Namun, jika Anda menguranginya menjadi demonstrasi kesalahan yang jelas, posisi melunak. Dan itu bisa mencapai kesepakatan dalam hal mendemonstrasikan konsekuensi kepada orang yang memasukkan data primer.



Contoh luar biasa dari motivasi dan bahkan visualisasi konsekuensi kesalahan diberikan dalam artikel habr.com/ru/post/347838 - dalam contoh ini, layanan TI dengan kompetensi analisis bisnis tingkat lanjut bertanggung jawab atas proses DQM. Selain itu, kompetensi DQM itu sendiri tidak sulit, dan dapat dikembangkan oleh analis mana pun dalam beberapa bulan.



Contoh lain yang menarik karena proses DQM juga mencakup manajemen kualitas proses bisnis, dapat dilihat pada artikel habr.com/ru/company/otus/blog/526174 .



Hasil



Kesimpulan umum dari artikel ini bersifat paradoks.



Jika perusahaan Anda telah ditanyai pertanyaan "siapa yang bertanggung jawab atas kualitas data," maka Anda telah jatuh ke dalam perangkap. Tidak ada jawaban yang benar untuk itu, tk. pertanyaannya sendiri salah. Jika Anda mencoba menempuh jalan ini, Anda akhirnya akan menyadari bahwa satu-satunya jawaban yang tepat untuk pertanyaan ini ("segala sesuatu") tidak akan memberi Anda apa pun dalam praktiknya.



Pendekatan yang benar adalah dengan membagi pertanyaan menjadi dua blok.



Yang pertama adalah membangun DQM sebagai sebuah proses, mengimplementasikan DQS, membentuk aturan (bukan secara ad hoc, tetapi sebagai proses yang berkelanjutan). Unit ini hidup di mana fungsi analisis kuat, biasanya di TI, tetapi tidak harus.



Blok kedua - masukan dari data primer itu sendiri - adalah tempat di mana keputusan dibuat tentang data tertentu, tetapi tidak secara acak, tetapi atas dasar semua aturan. Dengan demikian, penerapan DQS merupakan langkah penting menuju perusahaan yang didorong oleh data.



Saya mengundang Anda untuk berdiskusi!



All Articles