Tata Kelola Dirancang ke Dalam Org
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Berikutnya: Mencegah Data Buruk Masuk
Pertanyaan yang dijawab modul ini: Apa arti tata kelola data bagi seorang arsitek, dan siapa mengerjakan apa?
Ketika orang mendengar tata kelola data, mereka membayangkan rapat: komite, kebijakan, standar, dokumen yang menjelaskan siapa seharusnya melakukan apa dengan data. Semua itu mungkin bagian dari sebuah program tata kelola. Sebagai arsitek, saya tertarik pada pertanyaan yang berbeda: di mana kebijakan itu ditegakkan?
Jika kebijakan menyatakan hanya Keuangan yang boleh mengubah sebuah bidang, apa yang menegakkannya? Jika kebijakan menyatakan ERP memiliki rekaman pelanggan resmi, apa yang mencegah seseorang di Salesforce mengubahnya? Jika kebijakan menyatakan kru hanya melihat alamat Penerima untuk titik pemberhentian mereka sendiri, hanya di hari itu, apa yang benar-benar membuat hal itu terjadi? Jika kebijakan menyatakan simpan ini selama tujuh tahun, apa yang mengarsipkan atau menghapusnya setelah tujuh tahun? Kebijakan tanpa titik penegakan sebagian besar hanyalah harapan. Tata kelola menjadi arsitektur ketika keputusan-keputusan itu dibangun ke dalam sistem.
Tata Kelola Tidak Pernah Selesai
Section titled “Tata Kelola Tidak Pernah Selesai ”Biar saya sampaikan ini sejak awal: tata kelola tidak pernah selesai. Saya pernah melihatnya pasang surut. Sebuah perusahaan memberi perhatian sungguh-sungguh pada kualitas data, dan keadaannya membaik. Perhatian beralih ke tempat lain, dan kualitas menurun. Sebuah integrasi baru aktif, sebuah unit bisnis mengubah prosesnya, seseorang mengimpor file, perusahaan mengakuisisi perusahaan lain, sebuah agen mulai menulis rekaman, dan masalahnya berubah lagi. Tujuannya bukan keadaan khayalan di mana setiap rekaman sempurna selamanya. Tujuannya adalah menjaga data cukup tepercaya bagi bisnis dan mencegah data terburuk masuk. Itu pekerjaan yang berkelanjutan.
Ketika Salesforce sebagian besar berdiri sendiri, tata kelola berarti membersihkan data di satu tempat. Ketika ia menjadi satu simpul dalam lanskap dari bab 4, tata kelola menjadi lebih sulit, dan lebih perlu. Sekarang pelanggan tinggal di Salesforce, ERP, data warehouse, sistem mitra, Data 360. Siapa pemiliknya? Siapa yang bisa mengubahnya? Salinan mana yang otoritatif, atribut mana yang boleh berpindah, berapa lama disimpan, dan siapa yang bertanggung jawab ketika ada yang salah? Itu bukan pertanyaan konfigurasi. Itu pertanyaan tata kelola yang kemudian menjadi konfigurasi.
Pemilik Rekaman Bukanlah Pemilik Data
Section titled “Pemilik Rekaman Bukanlah Pemilik Data ”Mulailah dari kata pemilik, karena Salesforce membuatnya membingungkan. Buka sebuah akun dan Anda melihat Owner: misalnya seorang sales. Apakah sales itu memiliki data pelanggan? Belum tentu. Di Salesforce, rekaman pada objek yang punya pemilik dimiliki oleh seorang pengguna atau sebuah antrean; pemilik mendapat akses penuh, dan pemilik menentukan penugasan dan berbagi melalui hierarki peran dan aturan berbagi (Sharing and Record Access Features (opens in a new tab)). Itulah kepemilikan rekaman: sebuah mekanisme platform.
Pemilik data adalah hal lain: orang atau fungsi yang bertanggung jawab atas data sebagai aset bisnis. Keuangan mungkin memiliki informasi pelanggan dari sisi hukum, Operasional memiliki status pengiriman, SDM memiliki data karyawan. Salesforce bahkan memberi Anda tempat untuk mencatatnya: bidang klasifikasi Data Owner pada setiap bidang (Data Classification Metadata Fields (opens in a new tab)).
Di Steve Trucking, akun sebuah Mitra Ritel mungkin dimiliki oleh sales executive yang mengelola mitra itu. Tetapi identitas hukum mitra itu diatur oleh Keuangan dan dikelola sebagai master di ERP keuangan. Penjualan, layanan, operasional, dan portal mitra semuanya butuh akun itu; tidak satu pun dari itu berarti sales executive boleh mengubah identitas hukum mitra begitu Keuangan sudah menetapkannya. Saya pernah melihat tim melihat bidang Owner lalu berasumsi mereka sudah menyelesaikan kepemilikan data. Belum. Penugasan rekaman bukanlah akuntabilitas bisnis.
Pemilik, Steward, Kustodian
Section titled “Pemilik, Steward, Kustodian ”Tiga peran tata kelola, tiga pekerjaan yang berbeda.
Pemilik data menetapkan kebijakan. Mereka menjawab apa arti datanya, siapa yang boleh membuat dan mengubahnya, seberapa akurat ia harus, berapa lama disimpan, siapa yang boleh melihatnya, sistem mana yang otoritatif, dan apa yang terjadi ketika datanya salah. Arsitek tidak seharusnya mengarang jawaban-jawaban itu. Itulah salah satu posisi saya yang paling teguh: pemilik menetapkan kebijakan; arsitek menegakkannya. Jika Keuangan bilang nama resmi hanya bisa berubah melalui proses ERP begitu pelanggan aktif, itu keputusan tata kelola. Membuatnya benar secara mekanis adalah tugas saya.
Data steward menjaganya tetap berjalan. Steward dekat dengan kesehatan data sehari-hari: memantau sinyal kualitas, menyelidiki duplikat, menyelesaikan pengecualian, mengoordinasikan perbaikan, memelihara definisi, menemukan proses yang terus menghasilkan data buruk. Ada dua tugas lagi pada steward. Ketika dua tim tidak sepakat tentang arti sebuah bidang, siapa pemiliknya, atau siapa yang boleh melihatnya, steward membawa perselisihan itu kepada pemiliknya dan mengawal keputusannya sampai tuntas. Dan steward membangun literasi data: membantu orang-orang yang memasukkan dan memakai data memahami apa artinya dan mengapa aturannya ada. Seorang steward butuh lebih dari sekadar nama di bagan. Mereka butuh waktu, visibilitas, proses, dan wewenang untuk memperbaiki masalah. Jika tidak, “data steward” menjadi tanggung jawab kedelapan seseorang, yang hanya dilihat sekali per kuartal.
Kustodian menjalankan sistemnya. Admin, tim platform, tim keamanan: siapa pun yang mengoperasikan teknologi yang menyimpan dan memproses data. Pemilik bilang hanya peran-peran ini yang boleh melihatnya; kustodian mengoperasikan kontrol yang membuatnya demikian. Nama-namanya kurang penting dibandingkan membuat setiap akuntabilitas jelas, dan di organisasi kecil satu orang mungkin memakai dua topi.
Bagaimana Programnya Berjalan
Section titled “Bagaimana Programnya Berjalan ”Program tata kelola biasanya datang dalam tiga bentuk. Terpusat: satu tim menulis kebijakan dan standar untuk setiap domain. Bentuk ini konsisten, tetapi bisa menjadi hambatan, jauh dari orang-orang yang mengerjakan pekerjaannya. Terfederasi (terdesentralisasi): setiap domain, seperti keuangan, penjualan, atau operasional, mengelola datanya sendiri dalam kerangka beberapa aturan bersama. Bentuk ini dekat dengan pekerjaannya, tetapi definisi antar-domain lama-lama saling menjauh. Hibrida: sebuah tim pusat yang kecil memiliki standar dan definisi bersama, dan para pemilik serta steward domain menjalankan data mereka sendiri. Sebagian besar perusahaan besar yang pernah saya lihat berakhir di suatu titik dalam bentuk hibrida. Bagi arsitek, bentuk ini menjawab satu pertanyaan praktis: siapa yang mengesahkan sebuah kebijakan sebelum saya menegakkannya, dan di mana definisi bersama itu tinggal?
Pengetahuan untuk ujian. Ketahui tiga cara menjalankan program tata kelola, terpusat, terfederasi (terdesentralisasi), dan hibrida, serta apa arti masing-masing bagi siapa yang menetapkan kebijakan dan di mana definisi bersama tinggal.
Buat RACI Membuktikan Manfaatnya
Section titled “Buat RACI Membuktikan Manfaatnya ”RACI (siapa yang Responsible, Accountable, Consulted, dan Informed) membantu, tetapi bukan spreadsheet raksasa yang dibuat karena tata kelola “mewajibkannya.” Saya ingin RACI menjawab pertanyaan-pertanyaan arsitektur, dimulai dari tiga pertanyaan dari bab 4 (Empat Pertanyaan di Balik Kategori): di mana data dibuat, di mana ia diedit, dan di mana ia dirujuk? Itu sering kali sistem yang berbeda-beda. Ambil sebuah produk: ERP membuatnya, Salesforce merujuknya, portal menampilkannya, data warehouse menganalisisnya. Sekarang bisnis mengubah arti “produk aktif.” Di mana perubahan itu dimulai, siapa yang menyetujuinya, bagaimana ia menyebar, dan salinan mana yang read-only? Jika Anda tidak bisa menjawabnya, Anda belum punya tata kelola. Anda hanya punya salinan-salinan. RACI yang baik menyingkap persis ambiguitas itu.
Tata Kelola Harus Menjadi Mekanis
Section titled “Tata Kelola Harus Menjadi Mekanis ”Bisnis bilang hanya Keuangan yang boleh mengubah nama resmi pelanggan. Saya tidak ingin jawaban arsitekturnya adalah “kita akan membahasnya di pelatihan.” Pelatihan membantu; pelatihan bukanlah penegakan. Mungkin berupa akses tingkat bidang, aturan validasi, bidang yang hanya ditulis oleh integrasi, atau proses terkendali alih-alih suntingan langsung. Mekanismenya bergantung pada persyaratannya, tetapi harus ada satu:
| Kebijakan tata kelola | Pemilik yang memutuskan | Kemungkinan titik penegakan |
|---|---|---|
| ERP memiliki identitas hukum pelanggan | Keuangan | Bidang khusus integrasi, izin, validasi |
| Hanya orang yang membutuhkan yang melihat data pribadi | Privasi, keamanan | Berbagi, izin, akses bidang |
| Pengenal pelanggan bersifat unik | Pemilik bisnis | External ID unik, aturan duplikat |
| Rekaman yang dikelola tidak dibuat secara manual | Pemilik data | Izin, otomatisasi, integrasi |
| Data sensitif punya periode retensi yang ditetapkan | Privasi, hukum | Proses retensi atau penghapusan |
| Perubahan penting harus bisa dibuktikan | Kepatuhan | Riwayat bidang, jejak audit |
| Sumber data tetap bisa diidentifikasi | Pemilik data | Bidang sumber, metadata silsilah data |
Saya sengaja menyebut kemungkinan titik penegakan. Ini bukan tabel untuk memilih fitur. Ini urutan berpikirnya: apa kebijakannya, siapa pemiliknya, dan apa di dalam arsitektur yang membuatnya benar?
Pemilik menetapkan kebijakan; arsitek menegakkannya.
Jangan Mengandalkan Perilaku Baik
Section titled “Jangan Mengandalkan Perilaku Baik ”“Jangan pernah mengubah ID pelanggan ERP.” Semua orang tahu, sampai ada yang melakukannya: tidak sengaja, lewat muatan data, lewat otomatisasi, lewat integrasi, lewat agen. Jika mengubahnya akan merusak data perusahaan, “tolong jangan” bukanlah kontrolnya. Bangun kontrolnya. Percaya, tetapi verifikasi. Manusia, integrasi, otomatisasi, dan AI semuanya bisa salah, jadi arsitektur seharusnya berasumsi bahwa pada akhirnya sesuatu akan mencoba melakukan apa yang dilarang kebijakan. Lalu apa yang terjadi?
Tata Kelola Melintasi Batas Sistem
Section titled “Tata Kelola Melintasi Batas Sistem ”Kembali ke lanskap. ERP memiliki pelanggan; Salesforce, data warehouse, dan sebuah platform data pelanggan (customer data platform) menyimpan salinannya; sebuah mitra mendapat sebagian. Kebijakan berlaku untuk sistem yang mana? Semuanya. Salesforce mungkin dengan benar memblokir perubahan nama resmi sementara sebuah integrasi membiarkan sistem hilir menimpanya. Salesforce mungkin menghapus data pribadi yang masih disimpan data warehouse. Bidang yang diklasifikasikan sensitif di Salesforce mungkin mendarat di bidang teks yang tidak diklasifikasikan di tempat lain. Tata kelola tidak bisa berhenti di tepi org, karena datanya pun tidak berhenti di sana. Itulah sebabnya bab 4 datang lebih dulu: lanskap memberi tahu Anda seberapa jauh tata kelola harus menjangkau.
Kelola Secukupnya, Bukan Semuanya
Section titled “Kelola Secukupnya, Bukan Semuanya ”Kegagalan sebaliknya sama nyatanya. Kita menyadari tata kelola itu penting, lalu mengunci segalanya: tidak ada yang bisa membuat, setiap perubahan butuh persetujuan. Datanya terkelola, dan tidak ada yang bisa mengerjakan pekerjaannya. Tata kelola berarti kontrol yang sesuai untuk datanya: ketat untuk sebagian, ringan untuk yang lain. Sebagian rekaman bisa dibuat dengan bebas, sebagian butuh persetujuan; sebagian bidang bisa diedit hampir siapa saja, sebagian hanya oleh integrasi. Modul berikutnya membahas hal itu secara praktis.
Dan karena tata kelola tidak pernah selesai, penegakan butuh umpan balik. Apakah duplikat meningkat? Apakah bidang wajib terisi sampah? Apakah integrasi gagal, pengguna mencari jalan pintas, pengecualian bertambah, steward menghabiskan sepanjang hari untuk satu masalah? Sinyal-sinyal itu memberi tahu Anda apakah desainnya berjalan, dan kadang bahwa kontrolnya, atau kebijakannya, perlu diubah.
Di luar ujian: apa yang diubah AI. Tata kelola punya konsumen baru: agen. Pemilik data tetap memutuskan apa yang boleh dipakai dan untuk apa; arsitek tetap membuatnya bisa ditegakkan. Yang berubah adalah kecepatan dan skalanya. Sebuah agen membaca, menggabungkan, dan bertindak atas data yang dikelola jauh lebih cepat daripada manusia, jadi kebijakan yang hanya ada di dokumen bahkan lebih sedikit melindungi.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Siapa yang bertanggung jawab atas setiap domain data penting, dan bagaimana bedanya dengan kepemilikan rekaman.
- Siapa yang menjadi steward data dan siapa yang mengoperasikannya sebagai kustodian.
- Di mana data penting dibuat, diedit, dirujuk, dan dikelola sebagai master di seluruh lanskap.
- Titik penegakan apa yang membuat setiap kebijakan penting benar secara mekanis.
- Bagaimana arsitektur menunjukkan apakah tata kelola berjalan, atau mulai menurun.
Ketika mendengar sebuah persyaratan tata kelola, saya menerjemahkannya. “ERP memiliki ini.” “Hanya orang-orang ini yang bisa melihat ini.” “Kita perlu membuktikan siapa yang mengubah ini.” “Simpan ini selama tujuh tahun.” Setiap kali: tunjukkan titik penegakannya. Arsitek tidak memutuskan kebijakannya. Kita merancang sistem yang menegakkannya. Di situlah tata kelola berhenti menjadi dokumen dan menjadi arsitektur.
Jelajahi
Section titled “Jelajahi ”- Bantuan Salesforce, Sharing and Record Access Features (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
- Bantuan Salesforce, Data Classification Metadata Fields (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).