Mengapa E dalam singkatan EHD adalah tentang proses bisnis

Gudang Data tanpa E

Saat ini, di perusahaan mana pun yang terkait dengan bisnis besar dan menengah, ketersediaan gudang data adalah standar perusahaan de facto. Tidak masalah di mana industri perusahaan beroperasi, tanpa menganalisis data yang tersedia tentang pelanggan, pemasok, keuangan, tidak mungkin untuk mempertahankan keunggulan kompetitif. Dengan pengembangan otomatisasi dan optimalisasi pada setiap tingkat produksi suatu produk atau layanan, organisasi menggunakan semakin banyak sistem TI yang menghasilkan data - produksi, akuntansi, perencanaan, manajemen personalia, dan lainnya.

Cara membangun proses pembuatan data warehouse paling efektif dari sudut pandang optimalisasi global sumber daya perusahaan, kebutuhan bisnis baru dan saat ini, dan mengapa memelihara metadata itu penting.

Tugas untuk menggunakan data yang terakumulasi paling sering digunakan untuk kelas tugas berikut:

• pelaporan peraturan
• akuntansi keuangan
• perencanaan dan kontrol
• penganggaran
• analisis basis pelanggan
• manajemen risiko

Seringkali untuk tujuan yang paling mendesak, cukup menggunakan satu sumber - misalnya, jika kita berbicara tentang memberikan kepada regulator beberapa detail dari sistem tertentu, atau mengirimkan kepada klien seluruh sejarah pesanannya menggunakan CRM. Bahkan ketika mengubah sistem informasi, biasanya tidak ada kesulitan dalam memperoleh pelaporan.

Metode dan jenis penyimpanan data

Namun, ketika ukuran organisasi menjadi cukup besar, atau jika Anda ingin meningkatkan keunggulan kompetitif Anda, itu tidak lagi cukup untuk membuat produk dan membawanya ke pasar. Tren saat ini - dalam studi komprehensif konsumen untuk meningkatkan kesetiaannya. Anda perlu menganalisis bisnis dari berbagai sudut dan mempelajari cara mengevaluasi biaya dengan lebih akurat. Tugas-tugas khas dari kategori must have adalah sebagai berikut:

• bagaimana mengalokasikan biaya untuk unit penambangan bisnis
• Cara memperkirakan permintaan tergantung pada faktor internal atau eksternal
• Bagaimana mengelola risiko di organisasi keuangan dan asuransi
• Cara meningkatkan pemeriksaan rata-rata pelanggan (penargetan)

Setiap contoh di atas membutuhkan penggunaan lebih dari satu sumber data. Selain itu, adalah penting bahwa metode untuk membandingkan data antar sumber konsisten. Kalau tidak, suatu situasi pasti akan muncul ketika organisasi, katakanlah, direktur strategi dan direktur penjualan akan membawa informasi yang sama kepada direktur umum, tetapi dengan jumlah yang berbeda. Dan kemudian sebulan mereka mencari tahu siapa yang "ke kanan", menggunakan hampir setengah dari personil yang mereka miliki.

Cara paling primitif untuk mengatur data warehouse adalah apa yang disebut "data lake" (atau data lake), ketika kita hanya mengambil dan menumpuk data dari sumber yang berbeda. Dalam hal ini, kami memiliki platform teknis tunggal untuk bekerja dengan data dan mengisolasi pertanyaan analitis kompleks dari tugas utama sistem informasi. Gudang data seperti itu bisa sangat tidak rasional. Namun, dalam hal ini, Anda bisa melupakan analisis kompleks, dan beroperasi hanya dengan kueri sederhana. Selain itu, orang yang bekerja dengan data harus memiliki pengetahuan tidak hanya tentang area bisnis, tetapi juga tentang model data dari sistem sumber.

Selanjutnya, sesuai dengan tingkat organisasi dari data warehouse, penyimpanan mengikuti, menurut apa yang disebut Klasifikasi Kimball (Kimpball). Pengukuran dari sistem yang berbeda disatukan, dan dengan cara ini kita mendapatkan sesuatu seperti jaringan dengan dua jenis tabel - fakta dan pengukuran. Ini adalah pengayaan utama direktori, ketika kami, menggunakan beberapa kunci alami umum dalam tabel yang sama dari sumber yang berbeda, misalnya, TIN dalam direktori organisasi, mendapatkan referensi tunggal.

Berikutnya dalam kompleksitas dan keandalan adalah gudang data dengan model data tunggal yang mencerminkan objek paling penting yang menggambarkan kegiatan organisasi. Keandalan terletak pada kenyataan bahwa data, yang disajikan dalam bentuk yang mendekati yang normal ketiga, dengan model yang disusun dengan benar, adalah cara universal untuk menggambarkan kehidupan seluruh bisnis, dan dengan demikian, model data dapat dengan mudah diadaptasi tidak hanya untuk pelaporan analitis dan peraturan, tetapi dan untuk pengoperasian beberapa sistem perusahaan.

E - Satu

Berbicara tentang tesis artikel ini, saya akan membuat daftar masalah utama yang dihadapi oleh mereka yang bertanggung jawab untuk membangun gudang data:

" Kuda dalam ruang hampa ." Repositori dibuat, tetapi tidak ada yang menggunakannya.

Kotak hitam . Penyimpanan dibangun, tetapi apa yang ada di dalamnya dan cara kerjanya tidak bisa dipahami. Karena hal ini, kesalahan terus-menerus terjadi, dan jika bagian dari tim pengembangan telah berhenti juga, maka sebagai hasilnya, kita menggulung ke poin a.

" Kalkulator ". Penyimpanan dibangun, tetapi hanya memenuhi permintaan primitif, perubahan bisnis jauh lebih cepat daripada penerapan persyaratan, permintaan bisnis baru tidak diperhitungkan di dalamnya. Selain itu, beberapa data mungkin sudah usang atau jarang diperbarui.

" Vas Kristal ". Banyak kontrol manual, pemeriksaan, dan tindakan kontrol manual diperlukan untuk penyimpanan, jika salah satu peserta dukungan tidak bekerja, ada risiko besar menerima data yang tidak valid atau tidak menerimanya sama sekali.

Kami akan menganalisis keempat kasus secara lebih rinci.

"Seekor kuda dalam ruang hampa." Jika Anda mendapatkan hasil ini, maka ini terjadi karena salah satu dari dua alasan:

1. Lebih kecil kemungkinannya. Anda tidak mengumpulkan persyaratan dari unit bisnis (atau, yang sama, mereka dirancang dengan buruk). Situasi yang tampaknya absurd seperti itu muncul jika ide untuk membuat repositori tidak berasal dari bisnis, tetapi dari departemen TI, yang hanya memiliki anggaran "ekstra", dan repositori itu disusun karena semua orang memilikinya. Kami akan mencari pelanggan nanti (bahkan lebih baik adalah opsi "mereka akan berlari dengan tangan terentang") - jika kami meletakkan semuanya di sana. Orang-orang yang bertanggung jawab untuk mengalokasikan anggaran menganggap ini sebagai sesuatu yang perlu, mereka membaca dan mendengar dalam buku, ini seperti modernisasi, dan mereka mengangguk setuju.
2. Lebih mungkin. Pelanggan dari data warehouse telah diidentifikasi, misalnya, ini adalah departemen penjualan, dan inilah ide cemerlang: "mari kita membuat sedikit usaha di delta, mengarahkan keuangan, personel ke dalamnya dan sedikit lagi dan seluruh perusahaan akan menggunakan penyimpanan". Gudang telah dibangun, tetapi hanya digunakan oleh departemen penjualan, meskipun semuanya indah di sana dan saya tidak ingin mengambil pantai susu, tetapi tidak, rekan-rekan saya tidak punya waktu untuk bank ciuman, mereka perlu menggali sepotong data ke dalam tambang dari pagi hingga malam. Lagi pula, ini adalah bagian yang diperoleh dengan keringat dan darah (baca: menghabiskan waktu).

Dalam kedua kasus, tidak ada unsur mengambil tanggung jawab pada manajer puncak dan menurunkannya ke hierarki. Ini seperti dengan budaya perusahaan. Jika gen. Jika direktur perusahaan adalah 2 wakil, maka hanya gen itu sendiri yang dapat menggunakan penyimpanan di tingkat perusahaan. rusa, atau penyimpanan sedang dibangun untuk bagian dari perusahaan - yang diawasi oleh kepala posisi tertinggi, yang menyadari perlunya memperkenalkan EDM.

Untuk menghilangkan situasi seperti itu, berikut ini diperlukan:

1. Tentukan secara resmi sponsor proyek gudang data - siapa yang akan bertanggung jawab atas hasilnya baik secara finansial maupun spiritual
2. Menyetujui ruang lingkup proyek, mungkin bertahap, menunjukkan perkiraan tanggal
3. Berkoordinasi dengan semua departemen - lebih disukai, dengan pembangunan proses bisnis sebagaimana adanya dan yang akan terjadi

Hanya setelah ini kita dapat mulai mengimplementasikan proyek - mengumpulkan persyaratan, merancang arsitektur, dll.

Kotak hitam . Jadi, Anda mengklaim bahwa Anda membangun repositori, bahwa semua persyaratan diperhitungkan, namun, tidak ada yang mengerti cara menggunakannya, apalagi, jika salah satu pengembang utama pergi, menjadi hampir mustahil untuk memahami apa yang telah dilakukan dan bagaimana.

Dalam kasus ini, jelas, proses dokumentasi pengembangan tidak diatur. Prinsip "dokumentasi pertama", maka pengembangan harus ditingkatkan, jika tidak ke Mutlak, kemudian ke kontrol yang cukup ketat. Dan tidak hanya dari tim yang bertanggung jawab untuk pengembangan data warehouse. Idealnya, pengembang pelaporan tambahan (analitis, regulasi) perlu, pemilik sistem informasi internal perusahaan, dan, tentu saja, konsumen itu sendiri terhubung dengan proses dokumentasi yang berkelanjutan dan terbaru.

Selain itu, proses dokumentasi harus memenuhi prinsip-prinsip berikut:

• Relevansi - keadaan saat ini dari kode program sepenuhnya ditentukan oleh komposisi dokumentasi
• Versi - kemampuan untuk menganalisis dokumentasi rilis masa lalu dan merencanakan modifikasi untuk rilis mendatang
• Pemisahan - banyak orang dapat mengerjakan dokumen pada saat yang bersamaan
• Penerapan Dikatakan bahwa untuk setiap jenis dokumentasi penyimpanan, penting untuk memilih struktur yang paling baik dipahami oleh pengguna target: misalnya, struktur tabel paling baik digambarkan dalam bentuk tabel, proses bisnis dalam bentuk notasi, interaksi antara sistem informasi dalam bentuk diagram, bisnis - kamus dalam bentuk sistem wiki, dll.

Sekarang ada produk perangkat lunak yang secara serius menyederhanakan kehidupan, mis. untuk menghubungkan desain dan pengembangan, tetapi sementara belum ada solusi lengkap untuk gudang data, ini adalah:

• Bagan ER
• Produk BPMN
• Solusi ETL

Tanpa dokumentasi terbaru, kompleksitas pengembangan persyaratan baru akan meningkat, dan dengan dokumentasi yang kompeten, itu akan berkurang.

" Kalkulator ". Jika kita berasumsi bahwa kita belum menerima "kuda dalam ruang hampa", maka situasi ini adalah tentang ketika persyaratan tampaknya dipenuhi, tetapi mereka dipenuhi secara formal. Anda ingin menghitung sisa hari - tolong. Apakah Anda ingin mendapatkannya menurut wilayah rekanan - ini tidak ada dalam persyaratan, Anda perlu mengunggah untuk unggul, kemudian ambil dari unggahan sistem X ke kontraktor dengan pilihan bidang Y, dan kemudian VPR-ite.

Situasi saat ini menunjukkan kurangnya pengalaman dengan tim, tanpa pandangan arsitektur dari perkembangan repositori berikutnya, bahkan tanpa model data primitif. Biasanya, repositori semacam itu menjadi sementara, atau mereka dengan cepat dilupakan. Dalam cara yang baik, toko harus memiliki kekuatan bola salju yang bergulir dari gunung. Pada awalnya, ketika benjolan masih kecil, dan ada salju longgar di depan, Anda sendiri tidak akan perlu mengumpulkan dan mendorongnya. Pada suatu saat, ketenaran tentang produk Anda akan menyebar, dan pengguna akan semakin sering melihat di toko.

Jadi, agar penyimpanan tidak berubah menjadi kalkulator, perlu untuk memastikan:

1. personel yang berkualifikasi - arsitek, analis, EtL, dan pengembang SQL
2. Piagam proyek, yang akan menunjukkan tujuan penyimpanan tidak hanya untuk periode anggaran berikutnya, tetapi juga untuk tahun-tahun berikutnya
3. Kriteria kuantitatif dan kualitatif untuk gudang data. Jika tidak ada cukup staf, disarankan untuk menarik konsultan
4. Bayangkan dengan jelas apa yang akan membantu mengoptimalkan data warehouse di masa depan - biaya staf, perangkat lunak, peningkatan kecepatan pengembangan laporan, dll.

" Vas Kristal ". Penyimpanan dibangun, tampaknya sedang mengatasi tugas-tugasnya, tetapi perlu banyak upaya untuk mendukungnya: mempertahankan beberapa jenis direktori manual, terus memuat ulang beberapa sumber, kegagalan dalam memuat, duplikat data, dll.

Situasi ini dapat terjadi karena alasan berikut:

1. Tentang itu telah dikatakan di atas - kurangnya personil yang berkualitas;
2. Konsep Unarchitectural - ketika berbagai bagian penyimpanan dibuat oleh orang atau tim yang berbeda tanpa konsep yang disetujui bersama, sebagai akibatnya kami memiliki banyak cara untuk mengekstrak, mengubah, dan memuat data;
3. Situasi yang sangat umum adalah "pengembangan outsourcing", dukungannya sendiri, sementara penerimaan pekerjaan dilakukan dengan buruk
4. Pada tahap tertentu dalam pengembangan repositori, "anggaran sudah berakhir." Dan kemudian penyimpanan sedang diselesaikan (didukung) bukan oleh tim yang menciptakannya, tetapi oleh mereka yang membutuhkan data

Untuk mencegah situasi ini, tindakan berikut disarankan:

1. Poin-poin di atas termasuk personil yang memenuhi syarat, piagam proyek, rencana dan anggaran jangka panjang, dan orang yang tertarik dari manajer puncak.
2. Bukan outsourcing yang memimpin proses, tetapi karyawan internal (kepala analis atau arsitek) yang mengawasi outsourcing.
3. Segala situasi yang gagal harus diserahkan ke pertemuan untuk dipertimbangkan oleh arsitek gudang. Jika ada beberapa arsitek, maka panitia arsitektur.
4. Dianjurkan untuk memperkenalkan metrik kualitas untuk gudang data, Anda dapat menggunakan metrik ini untuk mengikat ke perintah KPI.

Seperti dapat dilihat, dalam semua kasus ini, terlepas dari kenyataan bahwa pembuatan data warehouse adalah kegiatan proyek, proses pembuatannya sendiri harus diatur untuk menciptakan hasil yang berkualitas tinggi.

Transisi dari gudang data ke satu

Seperti disebutkan di atas, keberhasilan proyek untuk membuat data warehouse ditentukan oleh cukup banyak data input (anggaran, sponsor, tim, tujuan, pelanggan). Namun, kami praktis tidak menyentuh proses bisnis yang bertujuan untuk mengembangkan dan memelihara CD itu sendiri. Di bawah ini saya akan mencoba merumuskan proses bisnis utama, yang dirancang untuk membuat proses bekerja dengan data di perusahaan benar-benar menyatu:

1. Proses untuk memperbarui dokumentasi teknis dan pengguna
2. Proses untuk memperbarui kamus bisnis (glosarium) data
3. Proses Kontrol Kualitas Data
4. Proses pengumpulan dan pengelolaan persyaratan untuk CD dan sistem pelaporan
5. Proses Manajemen Infrastruktur Penyimpanan
6. Proses untuk mengoptimalkan penyimpanan dan pengumpulan data

Dalam paradigma modern, rangkaian proses bisnis ini membentuk dasar dari konsep Tata Kelola Data.

Sangat sering, ketika mencoba menerapkan proses ini melalui upaya tim pembuat dan pelaporan CD, resistensi aktif akan diambil, atau mengabaikan proses. Dapat dimengerti, karena dalam pengertian lokal itu adalah perpanjangan dari pembangunan.

Karena itu, akan berguna untuk mengambil tindakan berikut:

• Pengenalan struktur tanggung jawab horisontal (setiap peserta mungkin bertanggung jawab untuk area kecil)
• Representasi grafis dari semua alur kerja yang mungkin untuk semua karyawan (formalisasi proses)
• Penerapan persentase dan kualitas tanggung jawab dalam sistem KPI

Terlepas dari kenyataan bahwa dalam pengertian lokal, proses transisi tampaknya secara signifikan "birokratis" dan berat, dalam arti global itu memberikan keuntungan yang signifikan dan menghemat waktu. Karena hilangnya waktu utama - ketika menemukan dari awal solusi yang sudah ada karena ketidakmungkinan atau kurangnya keinginan untuk memahami mekanisme yang ada.

Sedikit tentang solusi arsitektur target

Terlepas dari kenyataan bahwa arsitektur EDS mengacu pada artikel besar yang terpisah, atau bahkan sebuah buku, saya juga akan menunjukkan persyaratan teknis utama untuk gudang data yang matang:

1. Paradigma data lake tidak menggantikan data warehouse perusahaan, tetapi hidup berdampingan dengannya
2. EDS harus memiliki berbagai antarmuka penyajian data: bi tools, kemampuan untuk mengeksekusi kueri ad-hoc sql, penyediaan data standar dalam json, xml, dll.
3. Model peran akses data harus diimplementasikan.
4. Kecepatan respons saat mengakses data: 90% kueri tipikal - kurang dari 1 detik, 99% kueri - kurang dari 10 detik. Harus ada persediaan sumber daya yang cukup baik
5. Kehadiran lapisan pusat tunggal dan terhubung HD (lebih disukai - metodologi Inmon)

Akibatnya, data warehouse disebut unified bukan oleh ketersediaan sumber, tetapi oleh ketersediaan data konsumen. Dan ini jauh lebih rumit daripada menulis ETL universal dan menyesuaikan memori petabyte.