Mencegah Data Buruk Masuk

🌐 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)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 2 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Tata Kelola Dirancang ke Dalam Org · Berikutnya: Kenali Data Anda

Pertanyaan yang dijawab modul ini: Bagaimana Anda menjaga data tetap baik, dan mempertahankannya?

Ada dua cara menangani data buruk: hentikan sebelum masuk, atau bersihkan sesudahnya. Anda akan melakukan sedikit dari keduanya. Tetapi jika boleh memilih, saya lebih suka mencegah masalahnya daripada membangun organisasi di sekitar pekerjaan membersihkannya selamanya. Duplikat, pengenal yang buruk, informasi yang hilang, nilai yang tidak standar, pengguna mengubah bidang yang dimiliki sistem lain, integrasi menimpa data baik dengan data buruk: semuanya menjadi proyek pembersihan seseorang. Jadi pertanyaan desainnya adalah data buruk apa yang secara wajar bisa saya cegah masuk sejak awal? Dan “secara wajar” itu penting, karena jawabannya bukan mengunci setiap bidang sampai sistemnya tidak bisa dipakai.

“Cukup Baik” Adalah Definisi Bisnis

Sebelum mencegah data buruk, definisikan data yang baik. Tidak ada satu definisi. Baik bisa berarti cukup lengkap untuk menjalankan proses, cukup akurat untuk mengambil keputusan, cukup terkini untuk beban kerjanya, cukup konsisten untuk digabungkan dengan sistem lain, cukup unik untuk tahu pelanggan mana yang kita maksud, cukup standar untuk otomatisasi, cukup tertelusuri untuk tahu dari mana asalnya. Itu bergantung pada datanya. Jika Steve Trucking menagih sebuah Mitra Ritel, identitas hukum mitra itu harus benar. Jika seorang sales mencatat sesuatu setelah rapat, tidak ada yang butuh komite untuk menyetujui setiap kalimatnya. “Cukup baik” adalah definisi bisnis; arsitek membuatnya bisa diukur dan ditegakkan.

Cegah Kesalahan yang Mahal

Tidak setiap bidang yang buruk layak mendapat perhatian yang sama. Saya paling peduli pada kesalahan yang punya konsekuensi di hilir. Pelanggan duplikat berarti dua riwayat penjualan, dua riwayat layanan, dua kumpulan kontak, dua ID eksternal, dua integrasi yang menyinkronkan perusahaan yang sama, dua versi di data warehouse dan di Data 360, dan akhirnya sebuah agen yang memutuskan pelanggan mana yang asli. Itu jauh lebih mahal daripada salah ketik di sebuah deskripsi. Jadi jangan mulai dengan “bagaimana kita memvalidasi setiap bidang?” Mulailah dengan data buruk mana yang menimbulkan masalah bisnis atau arsitektur terbesar? dan taruh kontrol terkuat di sana.

Terbuka atau Dikunci?

Pembuatan akun adalah contoh klasiknya. Haruskah setiap tenaga penjual bisa membuat akun? Jawaban saya: tergantung tata kelola di sekitar datanya. Untuk sebagian besar org kecil dan menengah, pembuatan yang terbuka tidak masalah. Seorang sales bertemu prospek, membuat akunnya, mulai bekerja; untuk itulah CRM ada. Aturan duplikat, informasi wajib, dan stewardship mengelola kualitasnya. Saya tidak menambahkan proses persetujuan yang berat hanya karena tata kelola terdengar bertanggung jawab.

Sekarang ubah lanskapnya. Pelanggan resmi dikelola sebagai master di ERP, mengalir ke Salesforce dengan pengenal ERP, dan ERP otoritatif. Sekarang pembuatan yang terbuka berarti ada dua cara untuk membuat entitas terkelola yang sama. Ketika ERP dan seorang sales sama-sama membuat perusahaan yang sama, mana yang menang, pengenal mana yang dipakai integrasi, rekaman mana yang menyimpan riwayatnya? Pembuatan yang terbuka tidak lagi sekadar soal kemudahan penggunaan dan menjadi soal data master. Ketika akun dikelola sebagai master di ERP atau disinkronkan dengannya, kunci pembuatannya.

Tetapi mengunci sepenuhnya juga gagal. Sales sudah bertemu prospek yang belum ada di ERP dan ingin membuka sebuah peluang, dan model tata kelolanya berkata “tidak ada akun untuk Anda.” Jadi mereka menunggu tiga hari untuk Keuangan, atau menempelkan peluangnya ke akun yang salah, atau menyimpan prospeknya di bidang catatan atau spreadsheet. Kita melindungi model datanya dan merusak bisnisnya.

Jalan Tengah: Tipe Rekaman Sementara

Inilah jalan tengah yang saya sukai. Biarkan tim penjualan membuat akun dengan tipe rekaman tertentu, tipe prospek atau sementara, dan kendalikan konversinya menjadi tipe yang dikelola. Tim penjualan mencatat perusahaannya dan mulai menjual. Rekaman itu menyatakan dengan jelas: belum ditetapkan di sistem otoritatif. Lalu sebuah proses terkendali mengonversinya: Keuangan menyetujuinya, atau sebuah integrasi mengirimkannya ke ERP, yang mencocokkannya dengan pelanggan yang sudah ada atau membuat pelanggan baru lalu mengirim kembali pengenal otoritatifnya. Sekarang rekaman itu melintasi sebuah batas, sementara → dikelola, yang sangat berbeda dari dua sistem yang masing-masing membuat apa yang mereka yakini sebagai rekaman master.

Tipe rekaman adalah mekanisme yang saya ajarkan. Apa pun yang Anda pakai, buat statusnya terlihat di data: dari mana rekaman itu berasal, apakah ia sudah melintasi batas, siapa yang boleh mengubahnya sekarang, dan pengenal yang mengikatnya ke sistem otoritatif. ID pelanggan ERP yang baru ada setelah konversi adalah sinyal yang paling jelas.

Satu Tipe Rekaman untuk Setiap Alur

Taruh seluruh alurnya dalam satu gambar dan Anda akan melihat mengapa ini berhasil. Pelanggan dan produk datang masuk dari ERP. Peluang beserta item barisnya pergi keluar dan menjadi pesanan di ERP. Lalu akun? Sebagian masuk, sebagian keluar. Jadi pola umum yang pernah saya lihat di berbagai implementasi adalah dua tipe rekaman pada Akun, satu untuk setiap arah. Akun Sales (penjualan) lahir di Salesforce: para sales membuatnya, mengeditnya, menjual kepadanya, dan ketika ia menjadi pelanggan, ia dikirim keluar ke ERP. Akun ERP (saya pernah menamainya Customer, atau langsung SAP) lahir di ERP dan masuk melalui integrasi. Tidak ada yang membuat tipe rekaman itu selain integrasi, dan bidang-bidang data masternya (nama resmi, alamat, syarat pembayaran) bersifat read-only bagi pengguna. Tipe rekaman memberi tahu Anda ke arah mana rekaman itu mengalir, jadi arah kepemilikan master-nya terlihat langsung di rekamannya.

Click to enlarge

Satu tipe rekaman untuk setiap alur: akun Sales keluar, akun ERP masuk.

Ini tidak menghilangkan kasus yang sulit. Seorang sales mengonversi prospek untuk Steve’s Plumbing, tetapi Steve’s Plumbing sudah ada sebagai akun ERP, dan entah bagaimana pemeriksaan duplikat tidak menangkapnya. Sekarang Anda sedang menggabungkan, memindahkan induk rekaman-rekaman anaknya, dan memutuskan rekaman mana yang bertahan (bab 6, modul 3).

Dan jangan terpaku pada tipe rekamannya sendiri. Biasanya saya menghindari tipe rekaman kecuali ada alasan kuat untuk memakainya. Saya memakainya di sini karena, sebelum ada Dynamic Forms, tipe rekaman menentukan tata letak halaman, dan satu tata letak menampilkan bidang-bidang ERP sebagai read-only. Dengan Dynamic Forms, aturan visibilitas bisa menampilkan dan menyembunyikan bidang berdasarkan nilai sebuah bidang, sebuah bidang bisa dibuat read-only di halaman tertentu, dan Salesforce sendiri mengatakan bahwa Dynamic Forms mengurangi jumlah tata letak halaman dan tipe rekaman yang Anda butuhkan (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). Tetapi read-only di sebuah halaman hanya berarti read-only di halaman itu: API, pemuatan data, atau integrasi tetap bisa menulis ke bidang tersebut. Penegakan yang sesungguhnya adalah keamanan tingkat bidang (field-level security) atau aturan validasi; validasi UI bukanlah validasi data (bab 3, modul 9). Tipe rekaman tetap layak dipakai ketika kedua jenis akun membutuhkan nilai daftar pilihan atau proses bisnis yang berbeda. Yang benar-benar penting adalah ada bidang yang dengan jelas menyatakan dari mana rekaman itu berasal: kunci ERP itu sendiri, penanda data master, atau daftar pilihan sumber. Lalu kendalikan bisa-tidaknya diedit dari bidang itu.

Click to enlarge

Dari sementara menjadi dikelola: penjualan langsung mulai berjualan; hanya proses yang otoritatif yang menjadikan rekaman itu dikelola.

Lindungi Rekaman yang Dikelola

Begitu pelanggan kembali dari ERP, ID ERP, nama resmi, pengenal pajak, dan detail penagihannya adalah atribut yang dikelola. Haruskah sales mengubahnya? Tidak, jika ERP yang memilikinya. Itulah kebijakan dari modul 1 yang membutuhkan titik penegakannya: ID ERP read-only, identitas hukum dikendalikan, sementara sales tetap mengedit teritori, catatan hubungan, dan klasifikasi milik Salesforce sendiri. Tujuannya bukan akun yang tidak bisa disentuh. Tujuannya adalah garis yang jelas antara data yang dimiliki Salesforce dan data yang dirujuk Salesforce. (Awalan erp_ dari bab 4 membuat garis itu terlihat di skema.)

Yang akhirnya Anda dapatkan adalah golden record yang sebenarnya hibrida. Bidang-bidang data master dari ERP masuk: nama resmi, alamat penagihan dan pengiriman, syarat pembayaran. Lalu Salesforce menambahkan bidang-bidangnya sendiri yang tidak pernah dikirim balik: peringkat penjualan, tanggal pesanan terakhir, kurang lebih apa saja yang dipakai tim pemasaran. Akun yang sama, dua jenis bidang, dan setiap jenis punya satu sumber.

Yang paling sulit adalah alur dua arah. Misalkan seorang sales perlu mengubah nama resmi di ERP dari Steve’s Plumbing menjadi Steve’s Plumbing LLC. Dalam lima menit yang sama, seseorang di ERP mengubahnya menjadi Steve’s Plumbing L.L.C. Perubahan siapa yang menang? Inilah pola pikirnya: jika sebuah bidang di-master-kan di ERP, Anda tidak sedang mengubah bidang itu, Anda sedang meminta untuk mengubahnya. Putuskan apa yang terjadi ketika permintaan itu bertabrakan: ERP menang, permintaan ditolak jika nilainya sudah berubah sementara itu, atau permintaan menunggu seseorang menyelesaikannya. Dan putuskan apakah bidang-bidang yang saling terkait berpindah bersama sebagai satu perubahan atau satu per satu. Bab 6 membahas tabrakan lebih jauh (Putaran dan Tabrakan).

Hentikan Duplikat di Pintu Masuk

Duplikat itu berlipat ganda. Tangkap satu sebelum dibuat dan itu masalah kecil. Temukan dua tahun kemudian, dengan peluang, kasus, kontak, faktur, integrasi, dan analitik yang melekat pada keduanya, dan itu masalah besar. Modul 7 di bab 3 sudah membahas mekanismenya (aturan pencocokan, aturan duplikat, External ID yang unik), jadi saya tidak akan mengajarkannya ulang. Pertanyaan tata kelolanya adalah di mana kita harus mencegah duplikasi, dan di mana kita menoleransinya lalu menyelesaikannya nanti? Prospek pemasaran yang santai bisa hidup dengan ambiguitas. Pelanggan yang dikelola ERP dengan transaksi keuangan tidak bisa.

Standarkan Apa yang Dibaca Mesin

Teks bebas itu luar biasa bagi manusia dan buruk sekali ketika sebuah sistem harus menafsirkannya. Taruh Arizona, AZ, Ariz., Phoenix area, dan Southwest di bidang yang menggerakkan perutean, dan Anda punya masalah kualitas. Jika sebuah nilai menggerakkan otomatisasi, integrasi, pelaporan, keamanan, penugasan, atau tindakan agen, pikirkan baik-baik seberapa standar ia harus. Tidak setiap bidang teks menjadi daftar pilihan, tetapi bedakan informasi yang dibaca manusia dari informasi yang menjadi dasar keputusan mesin. Yang kedua layak mendapat kontrol yang lebih kuat.

Jangan Biarkan Bidang Wajib Menciptakan Data Palsu

Kita memutuskan sebuah bidang penting dan menjadikannya wajib. Pengguna tidak tahu jawabannya, sistem tidak membiarkannya melanjutkan, jadi ia mengetik N/A, Unknown, 999999, atau test@test.com. Bidangnya lengkap; datanya sampah. Sebelum mewajibkan sesuatu, tanyakan apakah pengguna benar-benar tahu jawabannya pada titik itu. Jika tidak, wajibkan belakangan dalam prosesnya, biarkan sistem lain menyediakannya, pakai status sementara, atau sediakan pilihan Tidak diketahui yang eksplisit ketika tidak diketahui memang jawaban yang sah. Aturan validasi bisa menegakkan kebijakan. Ia tidak bisa membuat seseorang tahu apa yang tidak ia ketahui.

Setiap Batas Data Butuh Keputusan Kualitas

Manusia bukan satu-satunya sumber data buruk; integrasi menghasilkannya lebih cepat. Manifes sebuah Mitra Ritel tiba dengan beberapa ratus baris. Segelintir punya kode pos yang tidak valid, beberapa menyebut pusat distribusi yang tidak dikenal, dua mengulang referensi pesanan yang sama. Apa yang terjadi? Tolak seluruh filenya? Terima baris yang baik dan kembalikan yang buruk? Muat semuanya lalu bersihkan nanti? Karantina pengecualiannya? Siapa yang diberi tahu, dan bagaimana mitra mengetahui apa yang gagal? Tidak ada jawaban universal, tetapi harus ada satu jawaban. Bab 4 bilang setiap panah butuh mekanisme. Tambahkan: setiap batas data butuh keputusan kualitas: apa yang kita terima, tolak, atau karantina, dan siapa pemilik pengecualiannya.

Click to enlarge

Setiap batas data butuh keputusan kualitas.

Data Historis Itu Berbeda

RouteDesk menyimpan riwayat delapan tahun Steve Trucking, dan kualitasnya bervariasi per pusat distribusi. Haruskah kita membersihkan kedelapan tahun itu sesuai standar hari ini sebelum memindahkannya? Kemungkinan besar tidak secara otomatis. Untuk apa data itu: operasional harian, referensi, klaim, pelaporan, analisis tren? Apakah semuanya perlu ada di Salesforce, atau sebagian bisa tetap di tempat lain? Bab migrasi membahasnya secara mendalam. Poin tata kelolanya: riwayat tidak otomatis butuh standar yang sama dengan data aktif. Jika Anda akan mengambil keputusan berdasarkan data itu, kualitasnya penting. Jika Anda menyimpannya untuk referensi, standar yang berbeda mungkin cukup. Ketahui tujuannya sebelum Anda menghabiskan banyak uang untuk membersihkan masa lalu.

Ukur Apa yang Akan Ditindaklanjuti Seseorang

Tata kelola tidak pernah selesai, jadi Anda perlu melihat ketika kualitas menurun: tingkat duplikat naik, lebih banyak rekaman di karantina, lebih banyak penolakan integrasi, nilai pengganti menyebar, lebih banyak permintaan jalan pintas, laporan yang tidak lagi cocok satu sama lain. Tetapi jangan membuat 150 metrik lalu mengabaikan 143 di antaranya. Untuk Steve Trucking, mungkin berupa pengiriman tanpa referensi mitra yang valid, pengiriman tanpa alamat yang bisa dipakai, referensi pesanan yang berulang, pesan mitra yang ditolak, akun yang tertahan di status sementara. Dasbor penuh lingkaran hijau tidak berarti datanya baik. Ukur apa yang benar-benar siap ditindaklanjuti seseorang.

Di luar ujian: apa yang diubah AI. Data buruk makin sering menjadi tindakan buruk. Seseorang mungkin menyadari sebuah nomor telepon terlihat salah sebelum meneleponnya; agen langsung memakai nilai yang diberikan kepadanya. Pelanggan duplikat, status basi, nilai wajib palsu, dan pengenal yang salah langsung berubah menjadi pesan yang salah atau pembaruan yang salah. Itu menaikkan nilai pencegahan. Itu tidak menghapus kebutuhan akan stewardship.

Yang Diputuskan Arsitek di Sini

• Kegagalan kualitas mana yang cukup merugikan untuk membenarkan kontrol pencegahan.
• Apakah rekaman yang dikelola dibuat dengan bebas, hanya oleh sistem otoritatif, atau melalui jalur dari sementara ke dikelola.
• Atribut mana yang dimiliki Salesforce dan mana yang hanya dirujuknya.
• Apa yang terjadi pada data masuk yang gagal pemeriksaan (terima, tolak, atau karantina) dan siapa pemilik pengecualiannya.
• Sinyal kualitas mana yang diukur, agar steward melihat penurunannya.

Anda tidak akan pernah mencegah setiap rekaman buruk. Tugasnya bukan data yang sempurna; tugasnya adalah mencegah data buruk yang bisa dihindari menjadi data yang mahal. Hentikan duplikat sebelum ia punya riwayat dua tahun. Lindungi pengenal sebelum sepuluh integrasi bergantung pada pengenal yang salah. Biarkan tim penjualan membuat prospek, tetapi jangan berpura-pura itu pelanggan yang dikelola sampai ia benar-benar menjadi pelanggan yang dikelola. Dan ketika sesuatu yang buruk lolos, pastikan seseorang bisa melihatnya, memilikinya, dan memperbaikinya.

Jelajahi

• Bantuan Salesforce, Things to Know About Duplicate Rules (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Break Up Your Record Details with Dynamic Forms (opens in a new tab) dan Required and Read-Only Fields in Dynamic Forms (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).