👼🏽 🏼 😪 Fitur berbasis data dalam petrokimia 💪🏿 🚠 👈🏻

Saat membuat bisnis apa pun, masing-masing divisinya otomatis. Sebagai aturan, aliran data ujung ke ujung di antara keduanya tunggal. Ini mengarah pada fakta bahwa data tidak dapat dibandingkan satu sama lain, karena masing-masing departemen menganggapnya dengan caranya sendiri. Tidak masalah jika Anda mengumpulkan beberapa metrik untuk seluruh perusahaan, tetapi ketika datang untuk menghitung indikator ujung-ke-ujung, perkiraan atau penyelesaian masalah pemodelan dan optimasi, kekacauan dimulai.

Data Warehousing (DWH) bukan cerita baru. Secara tradisional, mereka telah digunakan untuk pelaporan. Tetapi pemodelan penuh dan perkiraan proses bisnis end-to-end pada data DWH mulai relatif baru-baru ini. Dengan menggunakan data yang dikumpulkan, alat analisis modern memungkinkan tidak hanya membuat dasbor dengan jendela drop-down, tetapi juga untuk mengatur peramalan dan algoritma optimasi untuk setiap atribut, untuk skala algoritma teori permainan untuk seluruh perusahaan secara keseluruhan. Dan juga membangun dan segera menguji hipotesis tentang pengembangan lebih lanjut bisnis pada data nyata.

Dan sepertinya semuanya terdengar hebat. Tetapi tidak semua perusahaan terburu-buru untuk mengambil contoh dari para ahli terkemuka (Booking.com, Amazon.com) dan terus bekerja seperti biasa. Jadi apa yang menghentikan mereka? Minimal, memahami kelayakan investasi skala besar dalam alat pengolahan data, sulitnya menerapkan proses deskripsi data, munculnya peran baru (kurator data yang bertanggung jawab untuk kualitas data, insinyur data dan arsitek, dll.), Belajar bagaimana mempertimbangkan efek ekonomi dari penerapan manajemen data , dengan jelas mengisolasi pendorong biaya, cara membuat kantor mandiri, berdamai dengan strategi perusahaan dan memilih yang akan memajukan perusahaan, dan banyak lagi.

Nama saya Victoria Krasnova, saya adalah kepala Manajemen Data Perusahaan SIBUR. Bersama dengan kolega saya, pemimpin tim Tata Kelola Data, Rinat Abdurakhmanov, kami akan memberi tahu Anda bagaimana kami melakukannya.

Ketika pengecer besar (Wallmart) mulai mendigitalkan, mereka harus menentukan jejak kaki digital dan artefak mana yang ditinggalkan satu proses bisnis dan apa yang selanjutnya diambil sebagai input. Yaitu, jelaskan proses bisnis end-to-end. Hal yang sama diperlukan untuk digitalisasi perusahaan lain mana pun. Salah satu cara untuk menjawab permintaan ini adalah konsep manajemen data dan arsitektur data.

Dalam arti terapan, ini berarti: mengumpulkan data perusahaan yang paling penting dan tidak terlalu penting di satu tempat, menggambarkannya dalam bahasa yang jelas, menghubungkan ke proses bisnis dan menciptakan metode akses yang ramah pengguna ke data ini.

Arsitektur data, di antara fungsinya yang lain, memberikan jawaban yang jelas untuk pertanyaan "di mana itu dianggap?", "Apa yang dianggap?", "Mengapa itu dianggap?", "Siapa yang bertanggung jawab atas kualitas?" dan "di mana letaknya, di sistem mana itu?".

Adalah penting bahwa jawaban atas pertanyaan-pertanyaan ini terpisah dari bisnis itu sendiri. Ini sering terjadi seperti ini: analis ingin menguji hipotesis. Untuk melakukan ini, ia harus pergi dan meminta data yang diperlukan dari pemiliknya, membuktikan mengapa dan mengapa ini perlu dan penting, menghabiskan setengah hari untuk ini. Skenario kasus terbaik. Dan akhirnya mendapat penolakan. Mengapa? Karena pemilik data bertanggung jawab untuk menyediakan akses ke data dan penyebaran selanjutnya, karena tidak diketahui bagaimana data akan ditafsirkan oleh analis dan mungkin tidak cocok untuknya, dll.

Oleh karena itu, perlu untuk membangun struktur dan logika seperti itu yang akan intuitif, bekerja sesuai dengan aturan yang seragam dan tidak akan mengalihkan perhatian analis itu sendiri atau pemilik data dari tugas-tugas langsung.

Untuk tujuan ini, model data logis sangat bagus - deskripsi data dalam bahasa bisnis yang merinci hingga detail teknis, dikombinasikan dengan model peran yang fleksibel. Dalam hal ini, analis memperoleh akses ke repositori dan kumpulan data berdasarkan perannya di perusahaan. Dan dia mengumpulkan set data yang diperlukan berdasarkan akal sehat, dan bukan pada pengetahuan bahwa pada tahun 2005 seorang kawan tertentu bekerja di perusahaan, file yang berisi data yang diperlukan.

Pendekatan penataan seperti itu memungkinkan orang untuk dengan cepat menganalisis, membuat data dapat dibandingkan, dan sebagai hasilnya memungkinkan untuk mencapai manfaat sekunder - untuk mendigitalkan seluruh bisnis secara bertahap.

Apa saja tantangan yang kita hadapi

Dalam SIBUR, beberapa proses dijitasi dengan cukup baik, misalnya, persiapan data untuk pemasaran, keuangan, manajemen rantai pasokan, data produksi, dan bypass pabrik produksi. Segala sesuatu yang lain lebih rumit, karena SIBUR adalah produksi dengan siklus di mana, dari sudut pandang bisnis, tidak perlu mengumpulkan informasi dengan kecepatan yang sama seperti yang dibutuhkan di ritel, telekomunikasi atau bank. Dengan demikian, masalah kecepatan dalam analisis data juga tidak diangkat. Tapi sulit - bukan berarti tidak mungkin. Tahun ini kami berencana untuk mengoptimalkan proses, membuat perhitungan data lebih transparan, meningkatkan kecepatan transfer data untuk pengambilan keputusan, dan juga mulai mengumpulkan trek digital di semua tahapan proses, jika memungkinkan.

Mengapa perusahaan digital sangat akurat dan cepat untuk pengambilan keputusan? Karena mereka praktis tidak memiliki margin untuk membuat kesalahan jika data tiba-tiba ternyata salah. Dalam produksi, semuanya berbeda - tidak akan berhenti, pabrik tidak akan berdiri jika ada ketidakakuratan dalam data untuk analitik. Oleh karena itu, arsitektur data adalah kekuatan utama yang, berlawanan dengan segalanya, mengarahkan produksi ke arah digital. Dan manajemen data adalah perpustakaan yang memungkinkan Anda untuk merampingkan aliran data di seluruh perusahaan.

Baru-baru ini, kami meluncurkan garis yang berkaitan dengan deskripsi data. Sementara kami sedang mencari alat untuk menggambarkan data, menyimpan dan mengakses deskripsi dengan nyaman. Jika alat untuk deskripsi tidak nyaman, dan karena ini kami tidak akan dapat membuat katalog tetap terbaru, maka menggunakannya tidak akan lagi masuk akal. Akibatnya, data itu sendiri dalam repositori mungkin tidak relevan. Mengapa kita perlu membangun sesuatu berdasarkan data yang tanggal kedaluwarsanya telah kedaluwarsa?

Di sini kita memiliki tugas lain: bagaimana memotivasi arsitek yang menyertai sistem informasi yang ada, menggambarkan data dan tetap up to date. Prinsip "Anda membangunnya, Anda menjalankannya" sangat populer di perusahaan digital. Secara historis kami mengimplementasikannya sehingga beberapa orang memperkenalkannya, tetapi yang lain mendukungnya. Seringkali dokumentasi tidak mutakhir, dan beberapa algoritma hanya hidup di benak orang-orang tua. Oleh karena itu, deskripsi sistem adalah pekerjaan yang sangat memakan waktu, terutama ketika dilakukan dari awal (seperti dalam kasus kami). Memang, dalam kenyataannya, efek dari karya ini akan datang untuk mereka jauh di kemudian hari, hanya setelah menggambarkan kumpulan data yang kritis. Tetapi pada akhirnya, ketika memperkenalkan sistem baru lain, mereka tidak perlu mencari data untuk menyalakannya. Sekarang dibutuhkan rata-rata dua minggu atau lebih untuk mencari data ini.

Data diperlukan tidak hanya untuk memperkenalkan sistem baru, tetapi juga untuk menguji hipotesis. Mereka biasanya muncul banyak, dan mereka diuji dalam batch. Dan pada kenyataannya, ternyata ada data, ada banyak dari mereka, mereka beragam, tetapi hanya banyak waktu dan uang yang dihabiskan untuk pencarian mereka.

Poin lain ketika mengubah data "tanpa peringatan" di satu tempat menyebabkan data di tempat lain menjadi salah. Misalnya, indikator "Volume Produksi" digunakan untuk memperhitungkan kerugian pada tahap redistribusi, dan kemudian berhenti. Mereka mengubah sistem, tetapi sisanya tidak mutakhir, dan terus menggunakan indikator seperti sebelumnya. Akibatnya, data untuk membuat keputusan manajemen tidak benar. Atau pada titik tertentu ternyata data tidak sebanding, orang mulai mencari kesalahan. Dan ini juga tenaga kerja, hanya tidak terlihat dan tak terhitung.

Secara umum, seperti yang Anda pahami, kami telah sepenuhnya menghadapi masalah dalam memilih alat untuk bekerja dengan data. Dan sebelum Anda pergi dan memilih instrumen, Anda perlu menulis kriteria yang memadai untuk pilihan semacam itu.

Kriteria Pemilihan Instrumen

Kami sedang mencari alat yang akan mendukung deskripsi metadata dalam bentuk model objek dengan kemampuan untuk secara mandiri menambahkan jenis objek baru. Tidak semua produk menawarkan fitur ini. Sebagai contoh, beberapa alat memungkinkan Anda untuk hanya menampilkan tabel fisik sebagai objek, tetapi tidak ada kelas objek untuk entitas konseptual atau logis.
Konfigurasi koneksi yang fleksibel antara objek sangat penting. Sebagai contoh, hari ini kita memiliki tiga level abstraksi yang logis, tetapi kita harus membatasi kemampuan kita untuk menjatuhkan atau menambahkan sejumlah level.

Kriteria penting lainnya adalah keberadaan konektor built-in ke sistem sumber, terutama ke SAP. Kami memiliki banyak SAPa (saya pikir bahwa setiap perusahaan besar, pada prinsipnya, memiliki banyak SAPa) - instalasi besar, dan menyekopnya dengan tangan Anda adalah tugas yang sama sekali tidak berterima kasih. Ideal jika ada. Jika tidak ada konektor seperti itu, maka Anda dapat menulisnya sendiri.

Jangan lupa tentang pencarian teks lengkap, pencarian semantik dengan kemampuan untuk menambahkan kamus sinonim Anda sendiri (misalnya, Elasticsearch terintegrasi).

Peran penting dimainkan oleh kemungkinan umpan balik. Selain itu, idealnya, harus ada kemungkinan mengomentari, mengevaluasi pada prinsip 1-5 bintang, komunikasi langsung dengan orang yang bertanggung jawab atas entitas atau atribut entitas tertentu, serta pengaturan bendera dan tag untuk menarik perhatian, serta menambahkan objek ke Favorit.

Selain itu, ada baiknya akan memiliki konektor asli ke SAS DQ atau alat lain yang dapat digunakan untuk menilai kualitas data dan menampilkan indeks kesehatan entitas tertentu, sehingga pengguna dapat segera melihat bahwa data dapat dipercaya, karena dijalankan melalui verifikasi. Dan berikan tanggapan Anda tentang ini.

Secara umum, Anda memerlukan sesuatu seperti ini:

Berikut adalah contoh kasus khas untuk Anda: seseorang melihat bahwa Anda dapat mempercayai data, melihat lebih dekat dan menemukan kesalahan, dan menulis langsung kepada pemiliknya memintanya untuk memperbaikinya. Ternyata showcase kesehatan data seperti itu. Keterbukaan dan ketersediaan data yang meluas secara bertahap mengurangi tingkat ketidakpercayaan baik pengguna maupun pemilik. Seorang analis bahkan dengan akses paling mendasar ke data dapat dengan cepat mendapatkan informasi yang diperlukan yang telah diverifikasi, dan pada saat yang sama, itu tidak bergantung pada pemilik data yang menyumbang informasi ini. Menang-menang.

Tetapi biasanya setiap orang memiliki segalanya di Excel, dan ini adalah masalah besar (bukan Excel itu sendiri, tentu saja, tetapi situasi seperti itu). Orang-orang menghitung indikator, kemudian mereka memperbaikinya di tablet mereka sendiri, tetapi tidak ada yang berubah dalam sistem umum. Dan analis takut untuk mengambil beberapa angka dari sumber korporat yang tersedia untuk umum, lebih mudah untuk pergi ke kolega dan meminta file. Ini cukup sulit untuk dihadapi. Bahkan, kriteria untuk keberhasilan mengimplementasikan kantor data dapat dianggap sebagai penciptaan lingkungan di mana karyawan, sebagai suatu peraturan, bergantung pada hasil analisis ketika membuat keputusan, dan lebih suka SQL dan Python dari alat.

Secara terpisah, ada baiknya menyebutkan pemeliharaan status saat ini dari data "Rahasia Komersial", "Data Publik", "Data Pribadi", "Data Perusahaan Distribusi Terbatas". Artinya, untuk seorang analis data, penting untuk mengetahui apa sebenarnya yang sedang dia telusuri dan bongkar, atau memberi tampilan pada kolega.

Lagi pula, ketika orang kebanyakan beralih ke undang-undang terkait rahasia dagang dan informasi rahasia, ia melihat informasi umum tentang apa yang dapat membahayakan perusahaan. Dalam kasus yang sering, mereka mulai menganggap sebagai data penting pada umumnya segala sesuatu yang berisi angka (tiba-tiba sesuatu). Oleh karena itu, ketika diminta untuk memberikan data untuk analisis, pemilik mulai bertanya pada dirinya sendiri: "apakah ini rahasia komersial?", "Apakah tindakan pemohon meminta kerugian?", Dan, direasuransikan, sering ditolak. Lagi pula, ia bertanggung jawab atas informasi ini, dan tidak tahu bagaimana analis akan menggunakannya.

Ada kasus lain: ketika kami mengerjakan daftar informasi rahasia untuk proyek demokratisasi data, ternyata daftar ini berisi data yang disebut pemilik rahasia, dan kami diharuskan oleh hukum untuk menyediakannya di situs web resmi. Dan, tentu saja, mereka diterbitkan di sana. Yaitu, dalam kondisi di mana tidak ada alat tunggal di mana setiap orang dapat melihat informasi yang diverifikasi dengan jelas sekaligus, banyak orang bekerja dalam mode "apa pun yang terjadi" dan sangat direasuransikan.

Jadi, ini semua tentang kriteria. Tapi dari apa yang sebenarnya kita pilih.

Cari solusinya

Kami mengatakan "memilih" karena kami belum memilih, kami masih mencari alat yang sempurna. Awalnya, kami memilih dari Collibra, SAS DG, Alation, Alteryx Connect dan Informatica. Kami juga melihat melalui proyek-proyek open-source asing, tetapi mereka menyapu mereka segera, karena tidak ada yang tahu bagaimana bekerja dengan alfabet Cyrillic.

Kemudian ada pengalaman yang gagal dengan Collibra. Kami hampir menyelesaikan kesepakatan, tetapi gagal - kami tidak menyetujui persyaratan. Dalam jangka pendek, mereka akan sepenuhnya pindah ke cloud, dan untuk perusahaan Rusia mana pun ini bukan pilihan. Bahkan, mereka tidak akan menyediakan produk, tetapi layanan: Collibra menyediakan langganan, dan kami memberikan data kami. Secara formal, ini bukan rahasia dagang, tetapi metadata, tetapi pada kenyataannya, jika terjadi kesalahan, bisnis akan lumpuh total.

Setelah cerita ini, kami menyadari bahwa kami akan memilih kotak untuk waktu yang lama: kami memiliki proses panjang, kami dengan hati-hati mendekati transaksi, kondisi, dan kontraktor, kami memeriksa semuanya berkali-kali untuk memastikan bahwa risikonya minimal. Mengetahui semua fitur ini, kami pergi ke pengembangan kami sendiri untuk membuat setidaknya solusi sementara bagi pengguna. Lagi pula, datanya menuangkan, dan tidak mungkin menggunakannya tanpa deskripsi! Secara paralel, kami melihat lebih dekat pada Alation dan Alteryx Connect dan membandingkan fungsionalitas dan biayanya dengan solusi kami.

Kami menemukan sendiri model logis penyimpanan, ini sedikit lebih rumit bagi kami di sini daripada untuk industri lain. Misalnya, untuk bank dan telekomunikasi, ada arsitektur data referensi - struktur dan rekomendasi yang diterima secara umum tentang apa dan bagaimana cara menguraikan data. Untuk petrokimia, tidak ada siklus penuh sumber untuk peminjaman kreatif dalam domain publik. Hanya butuh satu tahun untuk memahami bagaimana bisnis secara keseluruhan bekerja. SIBUR memiliki produksi yang kompleks, sejumlah besar nomenklatur, proses, bisnis, yang tercermin dalam sistem, yang berarti memerlukan analisis.

Di sini itu membantu kami bahwa ada yang disebut kepemimpinan intensif pengetahuan. Sebagai contoh, di industri lain cukup sering, manajer dan manajer tidak terlalu berpengalaman dalam industri itu sendiri. Ini terjadi, pada prinsipnya, ini bukan sesuatu yang mengerikan secara langsung, pada akhirnya, bisnis mereka adalah mengelola proyek, dan ternyata setiap tautan manajer baru biasanya tahu sedikit kurang dari yang sebelumnya. Tetapi ternyata sehingga para manajer adalah orang-orang yang mampu menjelaskan kepada Anda dengan jari semua proses yang dapat terjadi dengan butadiene di sepanjang jalur hidupnya, misalnya.

Jadi, soal keputusan. Pencarian kreatif adalah hal yang bisa memakan waktu setahun, dua, atau beberapa kehidupan. Karena itu, pencariannya bagus, tetapi Anda perlu mengerjakan sesuatu sekarang.

Jadi, kami pergi ke pengembangan kami sendiri, menyebutnya dg_light. Pengembangan front membutuhkan waktu 4 minggu (untuk mengatakan yang sebenarnya, bukan dari awal, kami menggunakan kembali alat analisis timeshare yang baru saja keluar dari jalur perakitan).

Komposisi Proyek:

Backend: Docker, Node.js, NGINX, Crossbar.io
Frontend: React, Redux, Material UI, Highcharts, Autobahn.js
Penyimpanan Data: PostgreSQL
Protokol: WAMP, WebSocket, HTTP (S)
OS: CentOS 7

Struktur fasilitas penyimpanan dan metodologi adalah masukan dari arsitek data. Untuk mempelajari desain depan, mereka menanam sejumlah analis dari berbagai tingkat kematangan dan bertanya: "Bagaimana rasanya?" Bahkan, mereka melukis untuk diri mereka sendiri.

Semua pengembangan membutuhkan waktu 6 minggu.

Sebuah pertanyaan yang masuk akal, apa yang akan kita lakukan dengan keputusan ketika kita membeli yang industri? Pada awalnya direncanakan bahwa kedua solusi akan hidup secara paralel: di DG "besar" akan ada model data, glosarium, model peran, dan dg_light akan meninggalkan chip kompleks yang tidak mudah diimplementasikan dalam solusi kotak seperti garis data. Apa yang akan terjadi di masa depan akan menunjukkan pengalaman penggunaan.

Model data

Fisika . Semuanya dimulai dengan membangun model data gudang. Kami berdebat lama tentang bagaimana membangun lapisan penyimpanan terperinci, dan memutuskan bahwa kami tidak akan mengambil satu konsep yang sudah jadi, tetapi menggabungkan Data Vault 2.0 dan Anchor (6NF). Sekali lagi, karena sumber data yang kami miliki sangat berbeda. Di satu sisi, ini adalah SAP, yang pada dasarnya adalah suatu tempat OLAP, dan di suatu tempat OLTP, dan logika bisnis yang hidup dengan hukumnya sendiri dan membutuhkan detail maksimum. Di sisi lain, mereka menjalani kehidupan penting dari sistem kontrol proses manufaktur (MES), di mana data mengalir dan sejarah nilai kunci mengalir sepanjang waktu.

Kombinasi hub, satelit, tautan dari DV2.0 dan perincian maksimum Ankor memungkinkan untuk menikahi semua ini di satu tempat. Ya, menulis pertanyaan secara manual di sistem seperti itu akan sulit, tetapi semua isinya benar. Dan kita dapat menjamin integritas sistem, bahkan jika segala sesuatu di sekitar kita tiba-tiba mulai berubah atau runtuh.

Logika. Setelah memecahkan masalah organisasi arsitektur di tingkat fisik, kami beralih ke deskripsi logisnya. Dan diskusi kami dengan rekan kerja pindah ke bidang filosofis dalam upaya untuk menentukan bagi diri kita sendiri apa esensi dan bagaimana mereka berhubungan satu sama lain. Setelah berdebat sebentar, mereka beralih ke DAMA-DMBOK, mengeluarkan definisi darinya dan menerapkannya pada konteks mereka. Sebagai hasilnya, ternyata entitas adalah kata benda yang kami operasikan dalam kerangka kerja SIBUR, yang memiliki nilai bisnis lengkap dan menjawab sejumlah pertanyaan. Masih ada perdebatan tentang apakah akan memasukkan agregat dan laporan dalam entitas. Setiap arsitek memiliki pendapatnya sendiri, perhitungannya sendiri, dan sekarang kami mencoba untuk membawa pemikiran kami ke penyebut yang sama. Ini adalah salah satu tugas yang harus kita selesaikan, termasuk orang-orang yang kita cari sebagai sebuah tim.

Tapi model logisnya tidak semuanya. Selain itu, atas dasar itu, kami juga membangun model konseptual yang manajemen perlu memahami apa yang terjadi sama sekali. Model logis untuk mereka terlalu rinci, jadi kami mengelompokkan semuanya menjadi domain data yang cocok dengan proses bisnis yang dijelaskan di perusahaan. Sekarang kami mencoba untuk bernegosiasi dengan kantor proses untuk mengikat setiap pengelompokan entitas logis untuk proses dalam ARIS.

Lebih jauh kami melangkah lebih luas dan lebih tinggi lagi: kami menciptakan model data logis tunggal, di mana kami memasukkan entitas logis dari setiap sistem, sambil menunjukkan sistem sumber dengan menunjukkan hubungan sistem satu sama lain.

Kami mengekspor pengetahuan ini ke arsitek perusahaan di Sparx Enterprise Architect, mereka memerlukannya untuk mengikat entitas dengan aliran dan antarmuka integrasi.
Organisasi arsitektur data seperti itu akan membantu orang-orang yang berencana untuk terlibat dalam analisis dampak di masa depan, dari situ akan mungkin untuk membangun Lineage Data yang lengkap. Secara umum, kami berharap bahwa solusinya akan digunakan tidak hanya oleh arsitek dari semua garis, tetapi orang-orang dari analitik dalam unit bisnis, ilmuwan data, dan semua orang yang entah bagaimana terhubung dengan analisis.

Sekarang kita menghadapi tugas yang lebih melelahkan - bagaimana mengajari karyawan untuk menggunakan semua ini.

Orang dan data

Rencana global kami adalah menjadikan SIBUR sebagai perusahaan yang didorong oleh data, ketika benar-benar ada karyawan yang dapat menganalisis sesuatu. Kami membagi strategi umum menjadi tiga bagian - tentang orang, tentang proses dan tentang alat. Dengan alat, bisa dikatakan, mereka memutuskan masalah, membuat platform mereka dengan data. Sekarang kita membutuhkan orang untuk mulai menggunakannya.

Fitur utamanya adalah mentalitas karyawan. Mereka bekerja di industri petrokimia yang berbahaya, di mana keselamatan ditulis untuk semua orang yang darahnya tertulis. Dan orang-orang dilatih untuk secara ketat mengikuti instruksi, itu benar-benar tercetak di subkorteks. Keadaan seperti itu sangat bertentangan dengan pemikiran bebas analis.

Kami memulai dari yang kecil: secara bertahap menyapih karyawan untuk membuat presentasi pada kesempatan yang kurang lebih signifikan dan mentransfernya ke dasbor. Karena orang-orang di perusahaan bertanggung jawab dan eksekutif, mereka mencoba mengambil presentasi yang sudah jadi dan menggambar semuanya dalam versi interaktif. Tetapi dasbor hidup menurut hukum yang berbeda, dan bagi seseorang ini adalah tingkat biaya tenaga kerja yang sama sekali berbeda, perlu memuat seluruh riwayat data dan memverifikasinya. Data menjadi dihitung secara otomatis dan tidak dimanipulasi - Anda tidak akan mengubahnya dengan tangan Anda kecuali jika Anda mengaturnya dengan benar.

Bahkan, semua otomatisasi proses internal diakhiri dengan sekelompok surat Excel +. Dan memindahkan orang dengan Excel adalah tugas yang hampir mustahil. Nah, benar, mengapa kita perlu Python dan SQL, karena di Excel Anda bisa melakukan semuanya! Dan sangat sulit untuk menghadapinya.

Dalam versi sebelumnya dari sistem manajemen data di SIBUR ada yang namanya pemilik arsip informasi - seorang karyawan yang memberikan akses ke data dan tahu di mana nomor mana yang benar. Pendekatan ini menciptakan hambatan yang saya tulis di atas. Untuk melanggarnya, kami mengambil keuntungan dari "praktik terbaik" dari Gartner dan secara terpisah mengidentifikasi kurator data dan petugas kualitas data.

Kurator data adalah manajer di tingkat direktur divisi yang menentukan aturan yang dengannya dia siap memberikan akses ke data. Petugas kualitas data bekerja secara langsung dengan informasi itu sendiri dan mengetahui angka mana yang benar. Sekarang kami bekerja untuk memastikan bahwa untuk setiap gambar ada orang yang bertanggung jawab atas kualitas yang akan menanggapi permintaan dari rekan kerja jika terjadi kesalahan atau ketidaktepatan. Kami sudah membagi data menjadi informasi yang tersedia untuk semua orang dalam perusahaan, informasi yang tersedia dalam unit tertentu, dan informasi yang mewakili rahasia komersial.

Dan jika ada manajer yang ingin menutup data tertentu, kami melakukan negosiasi ulang-alik dan menjelaskan bagaimana penutupan informasi akan mempengaruhi unit lain secara langsung atau tidak langsung bekerja dengannya. Dengan demikian, persentase data yang terbuka dalam perusahaan telah direvisi secara radikal. Menurut standar SIBUR, ini adalah revolusi nyata.

Kesimpulan

Kami memiliki alat yang sudah jadi, tetapi sejauh ini sangat sedikit orang yang dapat menggunakannya. Dan kami mendidik mereka. Prosesnya semakin cepat setelah kami membangun proses pelatihan penggemar, ketika setiap karyawan yang kami latih mengambil tanggung jawab untuk melatih yang berikut. Kami mengambil jalur untuk melatih karyawan kami sendiri daripada mempekerjakan analis, karena dalam kasus kami, lebih mudah untuk mengajarkan dewa-dewa makro SQL dan Python daripada kepada analis yang hebat untuk menjelaskan tentang pirolisis dan fitur-fiturnya. Dan lihatlah wajah mereka pada saat bersamaan.

Cara kami menarik orang dan memotivasi untuk belajar adalah kisah yang layak mendapat pos terpisah.

Selain mendidik analis internal, kami juga mencari arsitek, orang-orang yang memiliki pengetahuan tentang manajemen data. Ini adalah arah baru tidak hanya untuk Rusia, tetapi juga untuk dunia secara keseluruhan, dan orang-orang terus menafsirkan konsep arsitektur data sebanyak mana. Ada cerita yang dapat dimengerti dengan analitik bisnis, analitik sistem, arsitektur perusahaan.

Kami di SIBUR mendefinisikan arsitektur data sebagai disiplin di persimpangan potongan-potongan sistem dengan database dan proses yang terkait dengan bisnis. Seseorang harus memahami bagaimana organisasi tempat dia bekerja diatur, dan bagaimana proses meninggalkan data tentang diri mereka sendiri dalam sistem yang berbeda. Dan bagaimana menghubungkan yang pertama dengan yang kedua.