Satu Sumber Kebenaran per Atribut

🌐 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 1 dari 6 dalam bab Data Master dan Identitas, bab 6 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Berikutnya: Empat Cara Mengelola Data Master

Pertanyaan yang dijawab modul ini: Apa sebenarnya arti “satu sumber kebenaran”?

Ada satu ungkapan yang terus-menerus saya dengar: “Kita butuh satu sumber kebenaran.” Oke. Untuk apa? Pelanggan? Itu belum cukup spesifik. Ambil sebuah akun. Siapa pemilik nama pelanggan, alamat penagihan, batas kredit, account executive, tingkat dukungan, preferensi pemasaran? Jawaban-jawaban itu tidak menunjuk ke sistem yang sama. ERP mungkin mengendalikan nama resmi, alamat penagihan, dan status kredit; Salesforce mengendalikan pemilik hubungan dan atribut penjualan; platform lain mengendalikan persetujuan. Jadi ketika seseorang berkata kepada saya “Salesforce adalah satu sumber kebenaran kami untuk pelanggan,” pertanyaan saya berikutnya adalah: kebenaran yang mana?

Kebenaran Dimiliki oleh Atribut

Prinsip pertama data master adalah ini: otoritas ditetapkan per atribut, bukan per rekaman. Sebuah akun bisa tinggal di Salesforce tanpa Salesforce menjadi otoritatif untuk setiap bidangnya. Tujuh bidang dalam satu rekaman, dua otoritas:

Atribut	Sistem otoritatif
Nama resmi, alamat penagihan, ID pelanggan ERP, batas kredit	ERP
Account executive, penanda akun strategis, tingkat success	Salesforce

Satu rekaman; kebenarannya tersebar. Itu wajar. “System of record = Salesforce” tidak menggambarkannya. Model otoritaslah yang menggambarkannya.

Dibuat, Diedit, Dirujuk, dan Seberapa Cepat?

Saat mengajarkan data master, saya terus kembali ke pertanyaan yang sama untuk setiap potongan data penting: di mana ia dibuat, di mana ia diedit, di mana ia dirujuk, dan berapa latensi perubahannya? Pertanyaan-pertanyaan itu menyingkap arsitektur dengan cepat. (Anda sudah bertemu tiga yang pertama di bab 4, saat memilah jenis-jenis data; di sinilah ketiganya melakukan pekerjaan yang sesungguhnya.)

Ambil contoh sebuah aset. Seorang pelanggan memesan tiga sepeda. Salesforce memiliki peluangnya beserta item barisnya, dan pesanannya dikirim ke ERP. ERP memenuhi pesanan itu, dan di sanalah aset-asetnya dibuat: tiga sepeda, tiga nomor seri, dikirim kembali ke Salesforce. Berbulan-bulan kemudian pelanggan itu menelepon tentang salah satunya, dan tim dukungan merujuk aset itu dalam sebuah kasus. Sekarang seseorang perlu mengoreksi sebuah atribut. Atribut mana yang boleh diedit oleh Salesforce, dan mana yang milik ERP yang membuatnya? Dan ketika ERP mengubah salah satunya, seberapa cepat Salesforce perlu tahu? Satu aset, empat pertanyaan, dan jawabannya tidak sama untuk setiap bidang.

Misalkan nama resmi dibuat di ERP dan dirujuk di Salesforce, lalu seorang sales menyadari bahwa nama itu salah. Haruskah ia memperbaikinya di Salesforce? Jika ERP memiliki bidang itu, mengubah salinannya tidak memperbaiki apa pun. Paling bagus, sinkronisasi berikutnya akan menimpanya; paling buruk, kedua sistem kini tidak sepakat dan tidak ada yang tahu mana yang bisa dipercaya. Jika bisnis ingin sales memulai koreksinya, itu lain cerita: Salesforce menyediakan pengalamannya, mengirim permintaan ke ERP, ERP melakukan atau menyetujui perubahannya, dan nilai otoritatifnya kembali. Itu arsitektur yang sangat berbeda dari membiarkan Salesforce mengedit bidang itu sendiri.

Latensi juga bagian dari kebenaran. ERP mengubah status kredit pelanggan pukul 10.00; Salesforce menyinkronkannya setiap malam; pukul 15.00 seorang sales melihat Salesforce. Apakah nilainya salah? Nilainya basi. Jika nilai itu berubah setahun sekali dan keterlambatan sehari tidak merugikan apa pun, sinkronisasi malam sudah cukup. Jika nilai itu menentukan apakah Anda menerima pesanan satu juta dolar hari ini, tidak cukup. Otoritas menyatakan dari mana kebenaran datang; latensi menyatakan seberapa cepat pihak lain harus tahu bahwa ia berubah. Dua keputusan yang terpisah.

System of Record, Engagement, Reference

Kosakata dari bab 4 membantu di sini. System of record memelihara versi otoritatif. System of engagement adalah tempat orang bekerja dengannya. System of reference menyediakan data yang dipakai sistem lain tetapi tidak dimilikinya. Salesforce bisa menjadi system of engagement untuk hubungan pelanggan sementara ERP tetap menjadi system of record untuk atribut hukum dan keuangannya. Itu bukan kelemahan arsitektur; itulah arsitekturnya. Kesalahannya adalah berpura-pura satu sistem harus memiliki segalanya agar diagramnya terlihat lebih sederhana.

Golden Record Hibrida

Itu mengubah arti “golden record.” Bab 5 memperkenalkan gagasan ini saat membahas cara menjauhkan data buruk; di sini ia menjadi inti desainnya. Orang membayangkan satu rekaman ajaib dengan setiap bidang dikelola sebagai master di satu tempat. Kadang memang itu desainnya. Di Salesforce, lebih sering saya melihat yang hibrida: sebagian akun dikelola sebagai master di tempat lain lalu disalin masuk (nama resmi, nomor pelanggan ERP, alamat penagihan, status kredit), dan sebagian lagi ada hanya karena Salesforce membutuhkannya (account executive, strategi peluang, tingkat success, catatan hubungan). Bidang-bidang ERP masuk agar orang bisa memakainya. Bidang-bidang Salesforce tidak pernah dikirim balik, karena ERP tidak peduli pada bidang-bidang itu. Sangat wajar, selama semua orang tahu mana yang mana.

Buat Otoritas Terlihat

Jadi saya membuat otoritas eksternal terlihat jelas di skema. Jika SAP mengendalikan sebuah bidang, bidang itu diberi awalan: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Gagasannya sama dengan awalan erp_ di bab 4. Pakai nama sistemnya ketika otoritas itu spesifik dan stabil, dan awalan generik ketika maknanya lebih penting daripada vendor saat ini. Intinya, enam bulan kemudian, siapa pun yang membaca model bisa melihat: ini bukan sekadar bidang Salesforce biasa; sistem lain memiliki nilai ini. Jangan membuat orang menemukan ulang otoritas dengan membongkar integrasi.

Bangun Peta Otoritas

Untuk data master yang penting, saya ingin sebuah peta otoritas: untuk setiap atribut kunci, siapa yang membuatnya, siapa pemilik keputusan bisnisnya, sistem mana yang otoritatif, dan siapa atau apa yang boleh mengubahnya. Empat pertanyaan yang berbeda:

Atribut	Dibuat oleh	Pemilik bisnis	Sistem otoritatif	Boleh mengubahnya
Nama resmi	Keuangan	Keuangan	ERP	Proses keuangan
Batas kredit	Keuangan	Keuangan	ERP	Tim kredit
Account executive	Operasional penjualan	Penjualan	Salesforce	Manajemen penjualan
Tingkat dukungan	Operasional layanan	Layanan	Salesforce	Manajemen layanan
Persetujuan	Pelanggan	Privasi	Platform persetujuan	Pelanggan, proses yang disetujui

Perhatikan bahwa pemilik bisnis dan sistem otoritatif bukanlah hal yang sama. Sistem tidak memiliki kebijakan; oranglah yang memilikinya. Sistem menyimpan dan menegakkan hasilnya. Itu bab 5 lagi: pemilik menetapkan kebijakan; arsitek menegakkannya.

Click to enlarge

Satu pelanggan. Banyak atribut. Satu otoritas untuk masing-masing.

Otoritas Berubah Sepanjang Siklus Hidup

Seorang sales bertemu prospek yang belum pernah dikenal ERP dan membuat akunnya di Salesforce. Pada saat itu Salesforce otoritatif untuk nama, alamat, kontak, dan kualifikasinya. Prospek itu menjadi pelanggan; ERP membuat pelanggan resmi dan menetapkan nomor pelanggan, nama resmi, alamat penagihan, dan kreditnya. Otoritasnya berpindah. Salesforce tidak salah sebelumnya; siklus hidupnya yang berubah. Ini pola dari sementara ke terkelola di bab 5: sebelum konversi, Salesforce memiliki prospek; sesudahnya, ERP memiliki atribut yang terkelola, dan Salesforce tetap memiliki atributnya sendiri. Jadi “sistem mana yang memiliki akun ini?” adalah pertanyaan yang lemah. Tanyakan: sistem mana yang memiliki atribut ini, pada titik ini dalam siklus hidupnya?

Salinan Bukanlah Otoritas

Kita menyalin data ERP ke Salesforce karena orang terus-menerus membutuhkannya. Itu menjadikan Salesforce salinan lokal yang praktis, bukan master-nya, dan arsitekturnya harus berperilaku sesuai dengan itu: read-only bagi pengguna, diperbarui oleh integrasi, diberi label sumbernya, diubah hanya melalui permintaan, dan diperiksa lewat rekonsiliasi ketika salinannya melenceng. Salinannya berguna. Otoritasnya tidak berpindah.

Kepercayaan Butuh Lebih dari Sekadar Nilai

“Alamat penagihan: 123 Main Street.” Haruskah Anda memercayainya? Saya ingin sinyal kepercayaan: dari mana asalnya, kapan terakhir dikonfirmasi, sistem mana yang menyediakannya, dan siapa atau apa yang terakhir mengubahnya: seseorang, sebuah integrasi, sebuah agen? Sekarang ERP bilang 123 Main Street, Salesforce bilang 125, dan sebuah file mitra bilang “123 Main St., Suite 200.” Mana yang benar? Jangan menjawab “pakai yang paling baru.” Mungkin saja. Tetapi “paling baru” itu sendiri adalah sebuah aturan yang berasumsi bahwa siapa pun yang terakhir mengubahnya layak menang. Itu bisa benar, atau mengerikan. Modul 3 membahas hal ini. Kepercayaan datang dari otoritas dan asal-usul data, bukan dari menemukan bidang yang terisi.

Steve Trucking: Kebenaran Milik Siapa?

Sebuah Mitra Ritel mengirim sebuah pengiriman, dan beberapa kebenaran bersembunyi dalam satu transaksi itu. Referensi pesanan mitra adalah milik mitra; Steve Trucking menyimpannya untuk mencocokkan pembaruan, tetapi tidak menjadi master-nya. Status pengiriman (tiba, terkirim, terpasang, pengecualian) adalah milik Steve Trucking; mitra menerimanya, tetapi menerima status tidak menjadikan mitra otoritatif atas apa yang terjadi di truk. Dan Penerima adalah pelanggan mitra. Mitra menyediakan nama, alamat, telepon, dan catatan pengiriman karena Steve Trucking membutuhkannya untuk mengirim. Itu tidak menjadikan Steve Trucking master atas identitas orang itu, dan pembedaan itulah yang menentukan desain Penerima di checkpoint.

Click to enlarge

Satu pengiriman, dua otoritas.

Di mana data tinggal dan siapa pemilik kebenarannya adalah pertanyaan yang berbeda. Salesforce bisa menyimpan nomor pelanggan ERP tanpa memilikinya; Snowflake bisa menyimpan status pengiriman tanpa menjadi master operasionalnya; sebuah platform data pelanggan bisa menyatukan identitas tanpa memiliki setiap atributnya. Sebuah agen bisa membaca ketiganya, dan itu jelas tidak membuat agen berhak memutuskan mana yang benar.

Di luar ujian: apa yang diubah AI. Agen mengubah otoritas atribut menjadi aturan eksekusi. Seseorang melihat alamat penagihan yang salah dan tahu “itu datang dari SAP; saya tidak seharusnya mengubahnya di sini.” Agen yang disuruh “perbarui alamat penagihan pelanggan” tidak akan tahu kecuali kita merancangnya. Ia butuh peta otoritas yang sama dengan yang dimiliki arsitek: akses ke sebuah bidang tidak menjadikan bidang itu tempat yang tepat untuk menulis.

Yang Diputuskan Arsitek di Sini

• Sistem mana yang otoritatif untuk setiap atribut penting, alih-alih satu sistem untuk seluruh rekaman.
• Di mana setiap atribut dibuat, diedit, dan dirujuk, dan seberapa cepat perubahannya harus berpindah.
• Siapa yang menetapkan kebijakan untuk setiap atribut, dan orang, integrasi, atau agen mana yang boleh mengubahnya.
• Bagaimana otoritas eksternal terlihat di model: awalan penamaan, izin, perilaku integrasi.
• Bagaimana otoritas bergeser sepanjang siklus hidup, seperti prospek yang menjadi pelanggan yang dikelola ERP.

Satu sumber kebenaran tidak berarti satu org, satu ERP, satu platform MDM, atau satu rekaman raksasa. Itu berarti bahwa untuk setiap potongan informasi yang dikelola, arsitektur bisa menyatakan di mana nilai otoritatifnya berada, dan setiap sistem lain tahu bagaimana harus berperilaku karenanya. Itu bukan satu sumber kebenaran. Itu sebuah arsitektur kebenaran.

Jelajahi

• Salesforce Architects, Data 360 Architecture (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).