Empat Cara Mengelola Data Master
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 2 dari 6 dalam bab Data Master dan Identitas, bab 6 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Satu Sumber Kebenaran per Atribut · Berikutnya: Pencocokan, Penggabungan, dan Survivorship
Pertanyaan yang dijawab modul ini: Bagaimana organisasi mengelola data master, dan gaya mana yang cocok?
Modul 1 menyatakan bahwa otoritas ditetapkan atribut demi atribut. Sekarang: apa yang kita lakukan ketika atribut-atribut itu tinggal di beberapa sistem sekaligus? Informasi pelanggan ada di Salesforce, ERP, penagihan, dukungan, mungkin Data 360, mungkin data warehouse, masing-masing dengan versinya sendiri. Itulah masalah yang coba diselesaikan oleh manajemen data master (MDM), dan MDM bukan satu arsitektur. Anda akan mendengar empat pola: registri, konsolidasi, koeksistensi, dan terpusat. Itu bukan pengaturan produk. Itu empat jawaban atas satu pertanyaan: seberapa besar otoritas yang dimiliki lapisan pengelola master?
Mulailah dari Masalahnya, Bukan dari Produknya
Section titled “Mulailah dari Masalahnya, Bukan dari Produknya ”Orang mendengar MDM dan langsung mulai mencari produk MDM. Saya akan memulai dari masalahnya. Apakah kita hanya perlu tahu bahwa beberapa rekaman adalah pelanggan yang sama? Apakah kita butuh satu tampilan gabungan untuk analitik? Apakah kita perlu memutuskan nilai mana yang otoritatif lalu mengirimkannya kembali ke sistem lain? Atau apakah kita ingin satu sistem pusat yang membuat data master untuk semua orang? Persyaratan yang sangat berbeda, arsitektur yang sangat berbeda.
Registri: Beri Tahu Saya Siapa Adalah Siapa
Section titled “Registri: Beri Tahu Saya Siapa Adalah Siapa ”Pola yang paling ringan. Registri tidak menggantikan sumbernya. ERP tetap menyimpan pelanggannya, Salesforce akunnya, sistem penagihan pelanggannya, dan registri menentukan bahwa rekaman-rekaman ini mewakili entitas yang sama: akun Salesforce 001…, pelanggan ERP SAP-43821, dan pelanggan penagihan BILL-9127 adalah milik satu pelanggan. Sumber-sumbernya tetap di tempatnya dan tidak ditimpa. Sekarang “tunjukkan semua yang kita ketahui tentang pelanggan ini” punya jawaban.
Tetapi perhatikan apa yang tidak dijawab oleh registri. Salesforce bilang 123 Main Street, ERP 125, sistem penagihan “123 Main St., Suite 200.” Registri tahu bahwa semuanya saling terkait. Registri tidak memutuskan mana yang harus berubah. Menautkan bukanlah mengelola sebagai master.
Dalam pengalaman saya, registri adalah norma di proyek Salesforce, disusul konsolidasi dan koeksistensi; MDM terpusat yang murni jarang. Registri umum karena tidak invasif. Anda tidak merancang ulang setiap sistem operasional sebelum mendapat manfaatnya. Salesforce tetap melakukan apa yang dilakukannya, ERP tetap melakukan apa yang dilakukannya, dan Anda menambahkan lapisan identitas. Itu perubahan yang jauh lebih kecil daripada berkata kepada setiap sistem “kalian tidak lagi mengendalikan data pelanggan; sistem pusat baru inilah yang mengendalikannya.”
Registri menjawab: rekaman mana yang termasuk entitas yang sama?
Konsolidasi: Satukan Datanya
Section titled “Konsolidasi: Satukan Datanya ”Konsolidasi mengambil data dari beberapa sumber dan menggabungkannya menjadi representasi pusat, untuk pelaporan, analitik, segmentasi, dan kecerdasan pelanggan. Data warehouse adalah contoh yang akrab: Salesforce mengirim pelanggan, ERP data keuangan, sistem penagihan pembayaran, dan bisnis akhirnya bisa menganalisis pelanggan lintas sistem. Sumber-sumbernya tetap ada dan mungkin tetap otoritatif. Arahnya penting: data mengalir ke dalam sistem konsolidasi, yang biasanya tidak mengirim kembali perubahan yang sudah dikelola. Gambaran pelanggan yang lebih baik, tanpa menjadi otoritas operasionalnya.
Registri dan konsolidasi mudah tertukar. Perbedaannya adalah apa yang dipusatkan: registri memusatkan identitas (“semua ini saling terkait”); konsolidasi memusatkan lebih banyak data (“satukan atributnya agar bisa kita pakai”). Keduanya tidak mengatakan “sistem pusat ini sekarang master-nya dan setiap aplikasi harus menerima nilainya.”
Konsolidasi menyatukan data tanpa mengambil kepemilikan dari sumber-sumbernya.
Koeksistensi: Putuskan, lalu Kirim Kembali
Section titled “Koeksistensi: Putuskan, lalu Kirim Kembali ”Dalam koeksistensi, lapisan pengelola master mendapat otoritas yang nyata. Data tetap tinggal di beberapa sistem operasional, tetapi proses MDM memutuskan nilai master-nya dan menerbitkannya kembali. Salesforce, ERP, dan sistem penagihan masing-masing punya nama resmi yang berbeda; proses MDM menentukan nama yang dikelola dan mendistribusikannya ke ketiganya. Sistem-sistemnya hidup berdampingan, tetapi semuanya bergerak menuju nilai master yang sama.
Itu bentuk MDM yang jauh lebih kuat. Ia tidak sekadar mengatakan “semua ini saling terkait”; ia mengatakan “untuk atribut ini, inilah nilai yang dipakai perusahaan.” Itu butuh lebih dari pencocokan: aturan bisnis, kepemilikan, survivorship, integrasi dua arah, penanganan error, dan tata kelola, karena seseorang harus memutuskan mengapa satu nilai menang.
Koeksistensi tidak hanya menautkan rekaman. Ia memutuskan nilai master dan mengirimkannya kembali.
Terpusat: Master yang Menciptakan Kebenaran
Section titled “Terpusat: Master yang Menciptakan Kebenaran ”Pola yang paling kuat. Dalam MDM terpusat, data master yang dikelola dibuat dan dipelihara di master pusat lalu didistribusikan ke semua yang lain. Alih-alih setiap sistem membuat pelanggannya sendiri dan MDM merekonsiliasinya belakangan, Anda membuat pelanggan yang dikelola di master-nya, lalu mengirimkannya ke Salesforce, ERP, dan sistem penagihan. Tata kelola yang sangat kuat, dan perubahan yang sangat signifikan: proses yang ada membuat pelanggannya sendiri, pengguna punya alur kerjanya, integrasi berasumsi pembuatan dilakukan secara lokal, dan unit-unit bisnis mungkin bahkan tidak sepakat tentang apa itu pelanggan. Itulah sebabnya pola ini jarang di lanskap Salesforce yang saya lihat. Pola ini bisa tepat. Tetapi ini keputusan yang jauh lebih besar daripada memasang sebuah alat.
MDM terpusat memindahkan pembuatan dan otoritas ke dalam master.
Keempatnya Berdampingan
Section titled “Keempatnya Berdampingan ”| Gaya | Apa yang dipusatkan | Apakah sumber tetap ada? | Mengirim kembali nilai yang dikelola? |
|---|---|---|---|
| Registri | Identitas dan tautan | Ya | Biasanya tidak |
| Konsolidasi | Identitas ditambah data gabungan | Ya | Biasanya tidak |
| Koeksistensi | Identitas, data, dan keputusan master | Ya | Ya |
| Terpusat | Pembuatan dan otoritas | Ya, sebagai konsumen | Ya |
Makin ke bawah tabel, lapisan pengelola master mendapat makin banyak otoritas, dan organisasi biasanya harus berubah lebih banyak.
Pengetahuan untuk ujian. Ketahui empat gaya implementasi MDM: registri (menautkan identitas; sumber-sumbernya tetap menyimpan datanya), konsolidasi (menyatukan data, biasanya untuk analisis), koeksistensi (memutuskan nilai master dan menerbitkannya kembali ke sumber-sumber) dan terpusat (master yang membuat datanya; sumber-sumber memakainya).
Jadi tidak ada “terpusat adalah yang paling matang, jadi semua orang harus sampai ke sana.” Pilih pola paling ringan yang menyelesaikan masalahnya. Perlu tahu rekaman-rekaman yang saling terkait? Pikirkan registri. Tampilan gabungan untuk analitik? Konsolidasi. Nilai yang dikelola disinkronkan kembali ke beberapa sistem operasional? Koeksistensi. Satu proses yang membuat dan mengendalikan data master untuk semua? Terpusat.
Di Mana Posisi Data 360?
Section titled “Di Mana Posisi Data 360? ”Data 360 membangun profil terpadu dari banyak sumber, yang terdengar sangat mirip MDM, dan memang menyelesaikan sebagian masalahnya. Resolusi identitasnya mencocokkan profil sumber menjadi identitas terpadu dan menyimpan tautan kembali ke rekaman sumbernya (Data 360 Architecture (opens in a new tab)). Itu membuatnya paling dekat dengan registri. Ia juga bisa menampilkan nilai yang sudah direkonsiliasi pada profil terpadu. Tetapi itu tidak menjadikannya sistem golden record terpusat yang menulis ulang sumber-sumbernya. Tampilan terpadu tidak otomatis menjadi rekaman perusahaan yang dikelola sebagai master. Modul 4 sepenuhnya membahas perbedaan itu.
Model Bersama Bukanlah Kebenaran Bersama
Section titled “Model Bersama Bukanlah Kebenaran Bersama ”Anda juga akan mendengar model data kanonis (canonical data model). Akun Salesforce, business partner di ERP, dan pelanggan di sistem penagihan semuanya dipetakan ke satu konsep perusahaan yang disepakati, Pelanggan, dengan pengenal dan atribut yang disepakati, sehingga setiap integrasi tidak perlu memahami bentuk setiap sistem lain. Model data Data 360 adalah contoh harmonisasi sumber-sumber ke dalam konsep bersama. Tetapi model kanonis menjawab bagaimana kita merepresentasikan ini secara konsisten? MDM menjawab bagaimana kita mengidentifikasi, mengatur, dan mengelolanya sebagai master lintas sistem? Petakan ketiga sistem dengan sempurna ke satu bentuk Pelanggan, dan Salesforce tetap bilang 123 Main Street sementara ERP bilang 125. Anda telah menyelesaikan strukturnya, bukan otoritasnya. Harmonisasi dan pengelolaan master tidak bisa saling menggantikan.
Satu Bisnis, Beberapa Pola
Section titled “Satu Bisnis, Beberapa Pola ”Jadi “Steve Trucking butuh MDM” bukanlah sebuah persyaratan. Untuk apa? Mitra Ritel, pusat distribusi, kru, truk, Penerima adalah domain yang berbeda dengan otoritas yang berbeda: Mitra Ritel dikelola di Salesforce dan ERP keuangan, identitas truk dari FleetLink, setiap Penerima diberikan oleh mitra untuk setiap pengiriman. Domain yang berbeda bisa memakai pola yang berbeda, dan di dalam satu domain, atribut-atributnya bisa punya otoritas yang berbeda. Jadi jangan menggambar kotak berlabel MDM di tengah diagram lalu menganggapnya selesai. Tanyakan apa yang dikerjakan kotak itu.
Gayanya juga mengubah integrasinya. Registri butuh tautan identitas; konsolidasi, aliran masuk yang andal; koeksistensi, data dua arah; terpusat, distribusi dari master ditambah kontrol yang mencegah sistem lain menciptakan kebenaran tandingan. Makin besar otoritasnya, makin besar koordinasinya, dan makin besar pula penanganan kegagalannya: bagaimana jika MDM mengubah nama resmi dan ERP menolaknya? Itulah sebabnya koeksistensi dan terpusat bukan sekadar “registri dengan fitur tambahan.” Keduanya membawa tanggung jawab operasional yang berbeda.
MDM Adalah Keputusan Bisnis
Section titled “MDM Adalah Keputusan Bisnis ”Poin terpentingnya: MDM pada dasarnya bukan keputusan teknologi. MDM adalah keputusan tentang otoritas. Siapa yang membuat pelanggan, siapa yang boleh mengubahnya, siapa yang memutuskan nilai mana yang menang, sistem mana yang harus menerimanya, apa yang terjadi ketika semuanya tidak sepakat. Sebuah alat bisa mengimplementasikan keputusan-keputusan itu; alat tidak bisa membuat organisasi menyepakatinya. Itulah sebabnya proyek MDM bisa punya teknologi yang hebat dan tetap gagal: tim teknis menyelesaikan pencocokan, dan bisnis tidak pernah menyelesaikan kepemilikan.
Pelajaran umum yang saya dapat dengan cara yang pahit: ketika beberapa sistem mengelola data yang sama sebagai master, Salesforce tidak bisa merekonsiliasi apa yang tidak mereka sepakati. Ketika sebuah perusahaan menjalankan dua ERP, saya bertanya bagaimana mereka menjaga keduanya tetap sinkron. Jika mereka tidak bisa, Salesforce juga tidak bisa. Modul 5 menceritakan kisah itu (Satu Pelanggan, Dua ERP).
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Apakah masalahnya butuh tautan identitas, data gabungan, nilai master yang dikirim kembali, atau pembuatan terpusat.
- Pola mana yang cocok untuk setiap domain data, alih-alih satu pola untuk seluruh perusahaan.
- Seberapa besar otoritas yang diberikan kepada lapisan pengelola master, dan sistem mana yang harus menerima keputusannya.
- Apakah model kanonis dibutuhkan, tanpa mencampuradukkan harmonisasi dengan otoritas.
- Bagaimana pola yang dipilih mengubah arah integrasi, kepemilikan, dan penanganan kegagalan.
Ketika seseorang menaruh kotak MDM di diagram, tanyakan apa yang dikerjakannya. Apakah ia tahu rekaman mana yang saling terkait? Menggabungkan datanya? Memutuskan nilai mana yang menang? Mengirim keputusan itu kembali? Membuat datanya sejak awal? Jawabannya memberi tahu Anda arsitektur apa yang sebenarnya Anda miliki, dan di mana otoritasnya tinggal.
Jelajahi
Section titled “Jelajahi ”- Salesforce Architects, Data 360 Architecture (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).