Hierarki dan Data Dua Arah

🌐 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 5 dari 6 dalam bab Data Master dan Identitas, bab 6 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Peta Bukanlah Keputusan · Berikutnya: Checkpoint 1: Steve Trucking

Pertanyaan yang dijawab modul ini: Bagaimana Anda mengelola data yang dipelihara oleh lebih dari satu sistem?

Arsitektur yang mudah: ERP memiliki pelanggan, Salesforce mendapat salinannya, selesai. Perusahaan yang nyata tidak serapi itu. ERP memiliki pelanggan dari sisi hukum dan Salesforce memiliki hubungan penjualannya; satu divisi tinggal di SAP, divisi hasil akuisisi di ERP lain; prospek hanya ada di Salesforce. Lalu seseorang ingin pengguna Salesforce memperbarui bidang yang dikendalikan ERP, dan panah-panahnya mulai menunjuk ke dua arah. Seperti yang saya katakan saat mengajarkan ini: “Yang paling sulit adalah yang dua arah.” Bukan karena mengirim data dua arah itu sulit secara teknis, melainkan karena begitu kedua sistem ikut serta dalam perubahan, Anda harus sangat tepat soal otoritas.

Data Dua Arah Tidak Berarti Dua Master

ERP memiliki alamat penagihan, yang disalin ke Salesforce. Seorang sales mendengar dari pelanggan bahwa alamatnya berubah, dan bisnis ingin ia memperbaruinya tanpa meninggalkan Salesforce. Masuk akal. Sekarang data mengalir ERP → Salesforce dan Salesforce → ERP. Apakah Salesforce sekarang ikut memiliki alamat penagihan? Tidak. Arah sebuah integrasi tidak menentukan otoritas. Sales itu tidak sedang mengubah salinan di Salesforce. Secara arsitektur, ia sedang meminta perubahan atas nilai yang otoritatif. Anda tidak mengubah bidang milik ERP; Anda memintanya diubah. Salesforce adalah antarmukanya; ERP tetap master-nya.

Itu mengubah desainnya. Jika Salesforce memiliki bidang itu, simpan lalu selesai. Jika ERP yang memilikinya, “simpan” berarti Salesforce mengirim alamat yang diusulkan, ERP memvalidasi dan menerimanya, memperbarui master-nya, lalu mengirim kembali nilai otoritatifnya. Baru saat itulah nilai yang dikelola berubah: minta → validasi → terima → terbitkan, bukan “perbarui kedua sistem dan berharap keduanya tetap sinkron.”

Click to enlarge

Integrasi dua arah tidak menciptakan otoritas dua arah.

Ketika Master Berkata Tidak

ERP menolak perubahannya: pelanggannya tidak aktif, alamatnya melanggar aturan ERP, pengguna tidak boleh mengubah alamat resmi, ERP sedang mati, atau orang lain mengubah pelanggan itu sementara itu. Jika Salesforce sudah menampilkan alamat baru, sekarang kita punya dua kebenaran, dan modul 1 sudah memberi tahu kita mana yang menang: milik ERP. Jadi arsitekturnya butuh status untuk diminta, belum diterima: nilai usulan yang terpisah, penanda “perubahan tertunda”, atau menunggu konfirmasi sebelum menampilkannya. Mekanismenya bergantung pada kasus penggunaannya. Aturannya tidak: jangan pernah biarkan permintaan yang ditolak berubah menjadi kebenaran tandingan.

Putaran dan Tabrakan

Ini contoh klasik. ERP memperbarui Salesforce; integrasi Salesforce melihat ada perubahan dan mengirimkannya ke ERP; ERP melihat ada pembaruan dan mengirimkannya kembali. Anda telah membangun putaran yang sangat mahal. Desain dua arah yang baik tahu di mana sebuah perubahan dimulai, apakah master sudah menerimanya, dan apakah ini perubahan bisnis yang baru atau hanya gema dari perubahan yang sudah diproses: pengenal sumber, stempel waktu, metadata integrasi, pemrosesan idempoten. Bab Integrasi membahasnya secara mendalam. Prinsip data master-nya sederhana: ketahui apakah Anda sedang memulai sebuah perubahan atau memantulkannya.

Lalu tabrakan. Anda sudah bertemu satu di bab 5: seorang sales meminta Steve’s Plumbing LLC sementara seseorang di ERP mengetik Steve’s Plumbing L.L.C. (Lindungi Rekaman yang Dikelola). Ini satu lagi. Salesforce mengusulkan 125 Main Street; hampir pada saat yang sama seorang pengguna ERP mengubahnya menjadi 130. Mana yang menang? Tidak ada jawaban teknis yang universal. Mungkin ERP selalu menang karena ia memiliki bidangnya; mungkin permintaan Salesforce masuk antrean tinjauan; mungkin perubahan yang diterima paling akhir menang; mungkin ERP menolak setiap pembaruan yang nilai awalnya sudah berubah. Itu konkurensi, tetapi di baliknya ada keputusan otoritas, dan tidak ada pola integrasi yang bisa menyelamatkan Anda jika tidak ada yang memutuskan siapa yang boleh membuat perubahan otoritatif.

Dan satu bidang saja masih kasus yang sederhana. Sebuah alamat terdiri dari jalan, kota, dan kode pos. Salesforce mengirim nama jalan baru sementara ERP baru saja mengubah kotanya. Apakah Anda membiarkan nama jalan itu lewat sendirian? Atau Anda memperlakukan alamat sebagai satu transaksi, sehingga semua bidangnya bergerak bersama atau tidak sama sekali, dan menolak seluruh perubahannya? Putuskan bidang mana yang bergerak sebagai satu kelompok sebelum tabrakan pertama, bukan sesudahnya.

Setiap kali saya melihat integrasi dua arah, saya bertanya apa yang terjadi ketika kedua sisi mengubah data yang sama? Jika jawabannya “kemungkinan besar itu tidak akan terjadi,” pekerjaan kita belum selesai. Mana yang menang, apakah kita menolak, mengantrekan, membandingkan versi, meninjau? Apakah bidang itu memang boleh diedit di kedua tempat? Kadang desain dua arah terbaik justru menghapus satu arah untuk atribut tertentu: Salesforce boleh meminta; hanya ERP yang menerbitkan nilai yang diterima. Data tetap berpindah dua arah, tetapi hanya satu sistem yang mengelola bidang itu sebagai master. Perbedaan itulah segalanya.

Hierarki Juga Data Master

Hubungan juga bisa menjadi data master. Induk global dengan wilayah Amerika Utara dan Eropa, masing-masing dengan anak perusahaan per negara: hierarkinya sendiri membawa makna. Siapa induknya? Anak perusahaan mana berada di bawah badan hukum mana? Akun mana yang menggulung ke pelanggan global? Itu menggerakkan pelaporan, teritori, harga, kontrak, eksposur kredit, layanan, akses data, dan analitik. Sebuah hierarki bisa sama pentingnya dengan rekaman-rekaman di dalamnya, dan butuh tata kelola yang sama. (Ujian menyebut manajemen hierarki secara eksplisit; ini mudah terlupakan.)

Di Salesforce, hierarki akun dibangun dengan bidang Parent Account (Akun Induk). Tampilan hierarki di Lightning menampilkan hingga 2.000 akun, dan hanya yang boleh dilihat pengguna; akun pribadi tidak didukung dalam hierarki; dan Account Site membedakan lokasi-lokasi sebuah perusahaan (Considerations for Using Account Hierarchy (opens in a new tab)). Tetapi bidang Parent Account tidak menjawab pertanyaan arsitekturnya: siapa pemilik hierarki itu?

Pengetahuan untuk ujian. Ketahui dasar-dasar hierarki akun: hierarki dibangun dengan Akun Induk (Parent Account); tampilan Lightning menampilkan hingga 2.000 akun, hanya yang bisa dilihat pengguna; akun pribadi tidak didukung; dan Account Site membedakan lokasi-lokasi sebuah perusahaan.

Satu Hierarki, Beberapa Master

Dalam pengalaman saya, hierarki dikelola oleh beberapa master sekaligus. Entitas Amerika Utara datang dari SAP, entitas Eropa dari ERP lain, prospek baru dibangun di Salesforce, dan anak perusahaan hasil akuisisi belum dimigrasikan. Siapa pemilik hierarkinya? Tergantung cabangnya. Setiap ERP mengendalikan cabangnya; Salesforce mengendalikan hubungan prospek sampai mereka dikonversi. Itu arsitektur yang sah, selama semua orang tahu di mana batas-batasnya. Putuskan per cabang.

Click to enlarge

Otoritas atas hierarki bisa ditetapkan cabang demi cabang.

Jadi jangan biarkan bidang Parent Account menyembunyikan otoritasnya. Seorang pengguna memindahkan induk sebuah anak perusahaan di Salesforce. Secara teknis sepele. Secara arsitektur, apakah ia baru saja mengubah struktur hukum perusahaan? Jika ERP mengelola cabang itu sebagai master, kemungkinan besar tidak, jadi Salesforce seharusnya memblokirnya, atau mengubahnya menjadi permintaan perubahan. Atau mungkin Salesforce secara sah memelihara hierarki komersial sementara ERP memelihara hierarki hukum. Kalau begitu, mungkin keduanya memang tidak seharusnya menjadi hubungan yang sama.

Sebuah perusahaan bisa punya beberapa hierarki yang sah: hukum, penagihan, penjualan, layanan, geografis. Induk global menandatangani kontrak, wilayah-wilayah mendapat layanan sendiri-sendiri, penagihan berjalan melalui entitas keuangan bersama, penjualan dikelola per wilayah. Mana hierarki yang benar? Semuanya; masing-masing menjawab pertanyaan yang berbeda. Kesalahannya adalah berasumsi harus ada satu saja. Harus ada otoritas yang jelas untuk setiap jenis hubungan: prinsip atribut dari modul 1, diterapkan pada hubungan.

Dan tidak setiap hubungan induk-anak adalah data master. Mengelompokkan pengiriman hari ini ke dalam satu rute adalah sebuah hubungan, tetapi bersifat transaksional, sebuah kejadian operasional. Hierarki pelanggan menggambarkan hubungan bisnis yang tahan lama. Keduanya terlihat seperti induk-anak dalam sebuah model; keduanya tidak berbagi siklus hidup. Tanyakan apa arti hubungan itu dan berapa lama arti itu bertahan.

Satu Pelanggan, Dua ERP

Saat mengajarkan ini, saya bertanya kepada peserta di ruangan: siapa yang pernah bekerja dengan klien yang punya satu Salesforce dan lebih dari satu ERP? Tangan selalu terangkat. Tanyakan mengapa, dan ternyata ERP-ERP itu terbagi per wilayah (satu untuk Amerika Utara, satu untuk Eropa), per fungsi (sebuah perusahaan pipa membeli perusahaan kelistrikan, dan masing-masing mempertahankan ERP-nya sendiri), atau sekadar karena sejarah: bisnis itu diakuisisi, dan belum ada yang memigrasikannya.

Ambil Steve’s Plumbing sebagai pelanggannya. Ia berbisnis di Amerika Utara, jadi ERP Amerika Utara punya rekaman pelanggan untuknya. Lalu ia membuka kantor di München, dan ERP Eropa membuat rekaman pelanggannya sendiri, dengan nomor pelanggannya sendiri. Perusahaan yang sama, dua rekaman, dua ID. Bagaimana saya merepresentasikannya dalam satu org Salesforce? Saya sudah melihat tiga cara.

Hierarki akun. Steve’s Plumbing adalah induknya, dengan Steve’s Plumbing North America dan Steve’s Plumbing Europe sebagai akun anak, masing-masing mewakili rekaman di satu ERP. Masalahnya: akun-akun anak itu sebenarnya bukan lagi Steve’s Plumbing. Mereka adalah Steve’s Plumbing yang berbisnis di sebuah wilayah, dan seperti yang baru saja kita lihat, sebuah hierarki membawa makna.

Akun yang setara (peer). Dua akun berdampingan, masing-masing dengan sebuah bidang yang menyatakan ERP mana pemiliknya: kode perusahaan, wilayah. Tidak ada yang disembunyikan. Harganya muncul di pelaporan: untuk melihat Steve’s Plumbing di seluruh dunia, Anda butuh sesuatu yang menyatakan bahwa kedua akun ini adalah perusahaan yang sama.

Satu akun, dengan satu rekaman anak per ERP. Satu Steve’s Plumbing, dan sebuah objek anak dengan satu rekaman untuk setiap ERP yang menyimpan ID pelanggan ERP itu. Dua ERP atau sepuluh. Para sales melihat satu pelanggan dan membuat satu pesanan; di balik layar, flow memutuskan ke ERP mana setiap baris pesanan dikirim: pekerjaan listrik ke ERP kelistrikan, pekerjaan pipa ke ERP perpipaan. Tetapi sekarang Anda harus memutuskan ERP mana yang menjadi utama untuk nilai-nilai bersama, seperti nama dan alamat, dan apa yang terjadi ketika pelanggan ada di satu ERP tetapi tidak di ERP lainnya.

Click to enlarge

Satu pelanggan, dua ERP: tiga cara merepresentasikannya di Salesforce.

Tanyakan Bagaimana Mereka Menjaga ERP Tetap Sinkron

Jadi yang mana? Pertama: seberapa banyak struktur ERP yang perlu dilihat para sales? Jika mereka sejak dulu tahu bahwa Amerika Utara dan Eropa adalah bisnis yang terpisah, karena mereka login ke ERP yang satu atau yang lain, jangan sembunyikan itu dari mereka. Bawa struktur itu ke Salesforce sebagai akun yang setara. Jika bisnis ingin satu Steve’s Plumbing di hadapan tim penjualan, yang Anda pertimbangkan adalah satu akun dengan satu rekaman anak per ERP.

Lalu pertanyaan yang benar-benar menentukannya, dan itu tidak diputuskan di Salesforce. Saya bertanya kepada klien: bagaimana Anda menjaga kedua rekaman itu tetap sinkron di antara ERP Anda? Bukan hal-hal yang lokal bagi setiap ERP, seperti saldo; itu transaksional. Yang saya maksud adalah data master: nama resmi, alamat-alamat. Jika mereka punya tim yang menjaga kedua ERP tetap sinkron, kita bisa menyatukannya menjadi satu akun. Jika mereka tidak bisa menjaganya tetap sinkron di ERP mereka sendiri, bagaimana mereka bisa berharap kita menjaganya tetap sinkron di Salesforce? Kalau begitu, pilihannya akun yang setara, atau hierarki.

Ingat apa itu ERP. Ini sistem-sistem raksasa yang butuh bertahun-tahun untuk diterapkan, dan masing-masing datang dengan caranya sendiri dalam mengelola data master. Salesforce tidak akan mengendalikannya. Kita tidak bisa mengendalikan ERP-nya. Yang bisa kita kendalikan adalah cara kita merepresentasikannya di Salesforce.

MDM di Tengah

Sebagian klien sudah menyelesaikan masalah ini sebelum kita datang. Perusahaan besar, bertahun-tahun berbisnis, beberapa ERP: mereka sudah menghadapi masalah ini jauh sebelum Salesforce dan menaruh produk MDM khusus di tengah sebagai perantara di antara ERP-ERP itu. Itulah MDM koeksistensi atau terpusat dari modul 2. Sekarang Salesforce tidak perlu menyambungkan dirinya ke setiap ERP. Ia menunjuk ke satu tempat, hub MDM, dan mendapat satu representasi pelanggan. Tetapi jangan berharap sering bertemu yang seperti ini. Ini implementasi besar tersendiri; selama bertahun-tahun saya bekerja, saya hanya dua atau tiga kali menanganinya. Dan bahkan dengan hub itu, Anda mungkin tetap butuh objek anak tadi, agar setiap pesanan tahu ke ERP mana ia dikirim.

Click to enlarge

MDM di tengah: Salesforce menunjuk ke satu tempat.

Steve Trucking: Hierarki Milik Siapa?

Sebuah Mitra Ritel punya strukturnya sendiri: induk korporat, divisi regional, pusat distribusi, toko. Apakah Steve Trucking memiliki hierarki itu? Tidak; mitralah otoritas atas organisasinya sendiri. Tetapi Steve Trucking mungkin butuh pandangan komersialnya sendiri atas lokasi-lokasi yang sama, untuk kontrak, pengelolaan akun, layanan, dan pelaporan, mungkin akun anak untuk setiap DC di bawah mitra. Dua hierarki yang sah, dua otoritas. Beri nama keduanya, dan jangan berpura-pura satu pohon mewakili setiap hubungan.

Buat Batas-Batasnya Terlihat

Setiap kali otoritas terbagi, saya ingin batasnya terlihat: penamaan bidang, metadata rekaman, pengenal sistem sumber, izin, perilaku integrasi, dokumentasi. Yang tidak saya inginkan adalah seorang developer harus membaca lima integrasi untuk menemukan bahwa “nilai Parent Account ini datang dari SAP, kecuali prospek, kecuali Eropa.” Itu bukan model otoritas yang bisa dipelihara. Jika hierarkinya dikelola oleh beberapa master, dokumentasikan pembagiannya. Jika otoritas berubah saat konversi, dokumentasikan perubahannya. Jika Salesforce bisa meminta tetapi tidak bisa membuat perubahan, buat hal itu jelas dalam pengalaman pengguna.

Di Salesforce, itu dimulai dari satu bidang. Harus ada sebuah bidang yang dengan jelas menyatakan bahwa ini data master: kunci dari ERP, atau penanda “is master data”. Kendalikan bisa-tidaknya bidang diedit dari bidang itu, bukan dari tipe rekaman; dengan Dynamic Forms Anda tidak lagi butuh tipe rekaman untuk menampilkan bidang-bidang ERP sebagai baca-saja (bab 5, Satu Tipe Rekaman untuk Setiap Alur). Anda boleh mengizinkan rekaman dibuat di luar master, tetapi awasi pengeditannya.

Di luar ujian: apa yang diubah AI. Seorang pelanggan berkata kepada agen, “ubah alamat penagihan kami menjadi 125 Main Street.” Bidangnya ada di sana, di Salesforce. Haruskah agen memperbaruinya? Tidak, jika ERP yang memilikinya. Agen butuh otoritas menulis, bukan sekadar akses ke bidang: tindakannya harus menyandikan jalur yang disetujui, yaitu mengajukan permintaan perubahan dan berkata “Saya sudah mengajukan perubahannya untuk diproses,” bukan melaporkan secara keliru “Saya sudah memperbarui alamat penagihan Anda.”

Yang Diputuskan Arsitek di Sini

• Apakah suntingan di Salesforce mengubah data otoritatif atau meminta perubahan dari sistem yang memilikinya.
• Bagaimana aliran dua arah membedakan perubahan asli dari gema, serta menangani penolakan, tabrakan, latensi, dan kegagalan.
• Siapa pemilik setiap hierarki, cabang demi cabang jika perlu.
• Untuk satu pelanggan yang tersimpan di beberapa ERP: hierarki, akun yang setara, atau satu akun dengan satu rekaman anak per ERP, tergantung seberapa baik klien menjaga ERP-ERP-nya tetap sinkron.
• Apakah hierarki-hierarki yang bersaing sebenarnya adalah hubungan sah yang berbeda: hukum, penagihan, penjualan, layanan.
• Bagaimana batas otoritas dan jalur penulisan yang disetujui dibuat terlihat bagi pengguna, integrasi, developer, dan agen.

Otoritas yang dibagi bukanlah masalahnya. Otoritas yang ambigu-lah masalahnya. Beberapa ERP bisa mengelola cabang yang berbeda, Salesforce bisa mengelola sebagian atribut dan meminta perubahan atas yang lain, dan beberapa hierarki bisa menggambarkan satu perusahaan. Semua itu berjalan, selama untuk setiap atribut dan hubungan penting Anda bisa menyebutkan siapa pemiliknya, siapa yang boleh mengubahnya, di mana perubahan otoritatif dilakukan, dan apa yang terjadi ketika sistem-sistem tidak sepakat. Jika tidak bisa, satu panah dua arah lagi di diagram tidak akan memperbaikinya.

Jelajahi

• Bantuan Salesforce, Considerations for Using Account Hierarchy (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).