Strategi Org Adalah Keputusan Lanskap

🌐 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 Memahami Data Perusahaan, bab 4 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Gambarkan Lanskap Sistem · Berikutnya: Lanskap Steve Trucking

Pertanyaan yang dijawab modul ini: Satu org atau banyak, dan di mana ia berjalan?

Saat mengajar kandidat CTA, saya bilang kepada mereka bahwa keputusan terbesar dalam sebuah skenario datang dalam lima atau sepuluh menit pertama: berapa banyak org Salesforce yang kita hadapi? Satu org besar? Org regional untuk Amerika Utara, EMEA, dan APAC? Org terpisah untuk unit bisnis yang terpisah? Org khusus untuk negara dengan aturannya sendiri? Dan langsung terkait dengannya: di mana org-org itu berjalan?

Ini bukan detail admin. Keputusan ini mengubah tempat data tinggal, integrasi, pelaporan, identitas, dan cara orang di seluruh dunia menjangkau sistem. Itulah sebabnya saya memperlakukan strategi org sebagai keputusan lanskap, dan mengapa saya mengambilnya lebih dulu.

Mulailah dengan Satu Org

Posisi awal saya sederhana: mulailah dengan satu org. Bukan karena satu org selalu benar, melainkan karena saya butuh alasan untuk menambah org lain. Satu org memberi saya satu tempat untuk data pelanggan bersama, satu model keamanan, satu tempat untuk deploy, satu set integrasi, satu tempat untuk pelaporan. Dan satu org tetap bisa mendukung unit bisnis, negara, proses, tipe rekaman, aplikasi, model berbagi, dan pengalaman yang berbeda-beda.

Jadi saya tidak menambah org karena Eropa melakukan sesuatu sedikit berbeda, atau sebuah divisi punya proses penjualannya sendiri, atau unit-unit bisnisnya tidak akur. Itu persyaratan, bukan batas org. Pertanyaannya adalah: kekuatan apa yang cukup besar untuk membenarkan org lain?

Banyak Org Ada Harganya

Pecah satu org menjadi tiga (Amerika Utara, Eropa, Asia-Pasifik) dan Anda tidak sedang menggambar tiga kotak yang rapi; Anda menciptakan pertanyaan-pertanyaan baru. Di mana pelanggan global tinggal? Bagaimana jika ia beroperasi di dua wilayah: dua salinan, dan mana yang memilikinya? Bagaimana orang membuat laporan global? Apakah ERP terintegrasi dengan ketiganya, apakah data warehouse mendapat tiga umpan data, apakah penyedia identitas terhubung ke ketiganya? Apakah kita men-deploy fungsionalitas yang sama tiga kali dan menjaga tiga model data tetap selaras? Jika sebuah agen butuh pandangan global atas seorang pelanggan, org mana yang ia tanyai?

Kembali ke lanskap dari modul 4. Satu kotak Salesforce menjadi tiga, dan setiap panah harus digambar ulang. Multi-org tidak salah. Tetapi tidak pernah gratis.

Cari Batas yang Nyata

Apa yang bisa membenarkan org lain? Batas yang cukup nyata untuk membentuk arsitektur: residensi data, regulasi, pemisahan hukum, model operasional yang benar-benar berbeda, akuisisi yang belum menyatu, kendala hosting regional, tata kelola yang sangat berbeda, kadang skala atau isolasi. Daftarnya tidak lengkap. Intinya adalah membedakan “kelompok-kelompok ini berbeda” dari “kelompok-kelompok ini butuh batas arsitektur.” Ambang yang kedua jauh lebih tinggi.

Geografi Tidak Otomatis Menjadi Strategi Org

“Kami beroperasi di 30 negara, jadi kami butuh 30 org.” Tidak. Geografi penting ketika ia membawa persyaratan arsitektur. Sebuah perusahaan bisa punya pengguna di seluruh dunia dengan satu arsitektur bersama. Jadi saya tidak menghitung negara; saya bertanya apa yang datang bersamanya. Di mana data boleh disimpan? Di mana boleh diproses? Apakah ada batasan memindahkan data pribadi lintas negara? Janji kontraktual tentang residensi? Apakah sebuah wilayah butuh layanan atau host Salesforce yang berbeda? “Ada kantor di Jerman” saja tidak cukup.

Hosting Adalah Bagian dari Gambar

Di sinilah platform modern membuat lanskap makin menarik. Hyperforce menjalankan Salesforce di infrastruktur public cloud di berbagai wilayah dunia, memberi pelanggan lebih banyak pilihan dan kendali atas tempat data mereka berada (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Jadi ketika saya memberi label sebuah kotak “Salesforce, Eropa,” lokasi itu bisa penting.

Tetapi berbicaralah dengan tepat. Memilih di mana sebuah org tinggal bukanlah janji bahwa setiap byte dari setiap layanan tetap berada di sana. Salesforce meminta pelanggan meninjau dokumentasi kepercayaan dan kepatuhan untuk Hyperforce, termasuk sub-pemroses tambahan untuk layanan yang mereka beli (sumber yang sama). Jadi jangan bilang “kami di Hyperforce di negara X, jadi semuanya tetap di negara X.” Ketahui layanan mana yang benar-benar Anda pakai, dan persyaratan mana yang sedang Anda penuhi. Dan perhatikan apa yang Anda pilih: wilayahnya, bukan cloud di bawahnya. Hyperforce berjalan di AWS, dengan Google Cloud mulai akhir 2026, dan Salesforce yang memutuskan di penyedia mana sebuah org berada; pelanggan yang punya alasan regulasi terdokumentasi untuk menghindari salah satunya berbicara dengan tim akunnya (sumber yang sama).

Jangan Berlagak Jadi Pengacara

Di sini pula arsitek perlu tahu perannya. Jika seseorang berkata, “Hukum privasi Eropa mewajibkan org terpisah,” saya tidak akan menerimanya begitu saja. Saya juga tidak akan mengangkat diri sebagai pengacara perusahaan dan menyatakan bahwa itu tidak wajib. Saya akan bertanya: persyaratan spesifik apa yang sedang kita penuhi? Di mana data disimpan, di mana diproses, transfer lintas negara, siapa yang boleh mengaksesnya untuk dukungan, sebuah kontrak, kebijakan internal? Lalu saya bekerja sama dengan tim privasi, keamanan, kepatuhan, dan hukum untuk mengubah persyaratan itu menjadi arsitektur. Jangan mengarang persyaratan hukum, dan jangan mengabaikannya. Terjemahkan.

Ketika Eropa Mendapat Org Sendiri

Inilah batas yang saya lihat dalam skenario nyata. Sebuah perusahaan punya kehadiran besar di AS dan kehadiran besar di Eropa: dua basis pelanggan besar, dua operasi penjualan dan layanan, dan program privasi Eropa yang dibangun di sekitar GDPR. GDPR tidak mengatakan “Anda butuh org Salesforce terpisah.” GDPR menetapkan aturan untuk data pribadi, termasuk kapan data itu boleh ditransfer ke luar UE (GDPR, Bab V (opens in a new tab)). Tetapi perusahaan ini, bersama tim privasi dan hukumnya, memutuskan bahwa data pribadi pelanggan Eropanya harus tinggal di org yang di-hosting di Eropa, dijalankan oleh tim Eropanya, di bawah tata kelola Eropanya. Itu persyaratan yang nyata, dan itu milik mereka, bukan milik saya.

Sekarang “satu org global yang besar” bukan lagi sekadar preferensi. Ada batas di lanskap, Salesforce AMER dan Salesforce EMEA, dan saya harus menggambarnya. Dan org kedua tidak pernah sekadar satu kotak tambahan.

Click to enlarge

Dua org, AMER dan EMEA. Warna kuning tua adalah apa yang ditambahkan org kedua: bukan satu kotak tambahan, melainkan setiap panah sekali lagi.

Susuri Panahnya Lagi

Dengan lebih dari satu org, susuri lanskapnya lagi. Apakah ERP mengirim produk ke setiap org? Apakah masing-masing mengirim pesanan kembali? Di mana pelanggan dikelola sebagai master, dan apakah datanya boleh melintasi wilayah? Apakah lapisan integrasinya global atau regional? Penyedia identitas mana yang memproses login pengguna mana? Ke mana data analitis pergi?

Tiga tempat menunjukkan harganya paling cepat:

Pelaporan. CEO menginginkan pipeline global. Dalam satu org, itu laporan Salesforce. Dalam tiga org, itu masalah pelaporan perusahaan: replikasi, kirim ke data warehouse, federasikan? Seberapa terkini datanya harus, dan apakah org-org itu bahkan mendefinisikan “pipeline” dengan cara yang sama? Di mana analitik tinggal mengikuti di mana data tinggal, dan jika Anda sengaja memecah data operasional, Anda harus merancang bagaimana wawasannya disatukan kembali.

Data master. Seorang pelanggan global membeli di AS, Jerman, dan Jepang. Tiga org, jadi kemungkinan tiga Akun. Bagaimana Anda tahu bahwa semuanya perusahaan yang sama? Apa pengenal globalnya, dan siapa pemiliknya? Jika satu wilayah mengubah alamatnya, haruskah perubahan itu menyebar? Atribut mana yang global dan mana yang regional? Strategi org tidak menyelesaikan masalah identitas; ia mengubah masalah identitasnya. Itu bab 6.

Integrasi. Satu org: Salesforce, lapisan integrasi, ERP. Tiga org: tiga koneksi ke lapisan integrasi, mungkin satu dengan host dan konektivitasnya sendiri, sebagian aliran dipakai bersama, sebagian regional, sebagian data boleh melintas dan sebagian tidak. Bahkan jaringannya bisa berubah: jika perusahaan butuh konektivitas privat khusus ke Hyperforce (di AWS, Salesforce merekomendasikan AWS Direct Connect; FAQ Hyperforce yang sama), setiap org dan host di gambar adalah satu koneksi lagi yang harus direncanakan. Di mana sebuah org berjalan bisa mengubah cara bagian lain perusahaan menjangkaunya.

Satu org atau banyak adalah keputusan yang Anda ambil sekarang, di awal, di lanskap. Bagaimana org-org itu kemudian berbagi data (Salesforce Connect lintas org, integrasi di antara keduanya, Data 360) adalah mekaniknya, dan bab 14, Satu Org atau Banyak? (coming soon), membahasnya.

Jika Anda merancang seluruh model data dan arsitektur integrasi lalu baru mendengar “omong-omong, ini harus tiga org,” Anda tidak sedang melakukan penyesuaian kecil. Anda telah mengubah arsitekturnya. Itulah sebabnya keputusan ini diambil lebih dulu.

Jangan Memecah Hanya agar Kotaknya Lebih Kecil

Org yang besar terasa rumit: banyak unit, objek, pengguna, integrasi. Seseorang berkata, “Bukankah lebih rapi kalau setiap orang punya org sendiri?” Gambarnya mungkin menjadi lebih rapi. Perusahaannya belum tentu. Anda menukar kerumitan internal dengan kerumitan terdistribusi: sinkronisasi, data duplikat, identitas lintas org, pelaporan global, beberapa pipeline rilis, integrasi dan otomatisasi yang terduplikasi, serta tata kelola atas semua itu. Kadang itu tetap pertukaran yang tepat. Tetapi terpisah tidak sama dengan sederhana.

Dan satu org juga tidak gratis. Tata kelola bersama menjadi lebih penting, tim bisa saling memengaruhi, batas keamanan perlu dirancang dengan cermat, model data harus melayani banyak kelompok, rilis butuh koordinasi, dan aturan regional bisa membatasi semua orang. Jadi ini bukan “Steve bilang selalu satu org.” Kecenderungan awal saya adalah satu org; lalu saya mencari persyaratan yang cukup kuat untuk menggeser saya dari sana.

Buat Keputusannya Terlihat

Jika strategi org itu penting, jangan menggambar awan Salesforce yang generik. Gambarkan org-org itu dan beri label (AMER, EMEA, apa pun yang nyata), catat persyaratan hosting atau residensi di balik masing-masing, dan susuri koneksinya. Arsitek lain seharusnya bisa melihat mengapa setiap batas itu ada. Jika saya tidak bisa menjelaskan mengapa ada tiga kotak Salesforce, keputusan saya belum selesai.

Steve Trucking menjalankan satu org, di AS, dan tidak ada apa pun dalam ringkasannya yang membutuhkan org lain. Tetapi ingatlah modul ini untuk proyek akhir: akuisisi yang datang dengan org-nya sendiri adalah jenis batas yang persis menguji pertanyaan-pertanyaan ini.

Di luar ujian: apa yang diubah AI. Sebuah agen bisa membuat batas org tidak terlihat bagi pengguna. Di baliknya, arsitektur tetap harus memutuskan org atau sistem mana yang boleh ditanyai agen, data apa yang boleh melintasi wilayah, dan jawaban mana yang otoritatif. AI bisa menyembunyikan kerumitan dalam pengalaman pengguna; AI tidak menghapus tata kelola atau batasnya.

Yang Diputuskan Arsitek di Sini

• Apakah ada alasan arsitektur yang sungguh-sungguh untuk lebih dari satu org, alih-alih menyelesaikan perbedaannya di dalam satu org.
• Di mana setiap org berjalan, dan persyaratan residensi, regulasi, kontraktual, atau bisnis mana yang menempatkannya di sana.
• Data mana yang boleh melintasi batas org dan wilayah, di mana data master bersifat otoritatif, dan bagaimana identitas global bekerja.
• Bagaimana integrasi, identitas, analitik, dan pelaporan berubah ketika satu kotak Salesforce menjadi beberapa.
• Apakah manfaat pemisahan sepadan dengan arsitektur terdistribusi yang diciptakannya.

Saat membaca sebuah skenario, saya mencari keputusan ini lebih dulu: satu org atau banyak, di-hosting di mana, dan dipaksa oleh apa? Jawab itu semua, dan sisa lanskapnya mulai terbentuk.

Jelajahi

• Bantuan Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• EUR-Lex, Peraturan (UE) 2016/679, General Data Protection Regulation (opens in a new tab), Bab V (transfer data pribadi ke negara ketiga), dicek 2026-10-14 (bahasa Inggris).