Org Stratejisi Bir Harita Kararıdır

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 4. bölümü olan Kurumsal Veriyi Anlamak bölümündeki 6 modülden 5.‘i. Her modül kendi başına okunabilir. Önceki: Sistem Haritasını Çizin · Sonraki: Steve Trucking’in Sistem Haritası

Bu modülün yanıtladığı soru: Bir org mu, çok mu ve nerede çalışıyor?

CTA adaylarına ders verdiğimde onlara bir senaryodaki en büyük kararın ilk beş on dakikada geldiğini söylerim: kaç Salesforce org’uyla uğraşıyoruz? Tek büyük bir org mu? Kuzey Amerika, EMEA ve APAC için bölgesel org’lar mı? Ayrı iş birimleri için ayrı org’lar mı? Kendi kuralları olan bir ülke için özel bir org mu? Ve doğrudan buna bağlı olarak: bu org’lar nerede çalışıyor?

Bunlar yönetici ayrıntıları değil. Verinin nerede yaşadığını, entegrasyonları, raporlamayı, kimliği ve dünyanın dört bir yanındaki insanların sisteme nasıl ulaştığını değiştirirler. Org stratejisini bir harita kararı olarak ele almamın ve onu ilk olarak vermemin nedeni bu.

Tek Org’la Başlayın

Başlangıç pozisyonum basit: tek org’la başlayın. Tek org her zaman doğru olduğu için değil, bir diğerini eklemek için bir nedene ihtiyacım olduğu için. Tek org bana paylaşılan müşteri verisi için tek bir yer, tek bir güvenlik modeli, dağıtım için tek bir yer, tek bir entegrasyon kümesi, raporlama için tek bir yer verir. Ve tek bir org yine de farklı iş birimlerini, ülkeleri, süreçleri, kayıt türlerini, uygulamaları, paylaşım modellerini ve deneyimleri destekleyebilir.

Dolayısıyla Avrupa bazı şeyleri biraz farklı yapıyor, bir bölümün kendi satış süreci var ya da iş birimleri birbirinden hoşlanmıyor diye org eklemem. Bunlar gereksinimlerdir, org sınırları değil. Soru şu: başka bir org’u haklı çıkaracak kadar güçlü olan kuvvet ne?

Birden Fazla Org’un Bir Bedeli Vardır

Tek bir org’u üçe bölün (Kuzey Amerika, Avrupa, Asya-Pasifik); üç düzgün kutu çizmemiş, yeni sorular yaratmış olursunuz. Küresel bir müşteri nerede yaşar? İki bölgede faaliyet gösteriyorsa: iki kopya ve hangisi sahibi? Biri küresel olarak nasıl raporlama yapar? ERP üçüyle de entegre mi olur, ambar üç akış mı alır, kimlik sağlayıcı üçüne de mi bağlanır? Aynı işlevselliği üç kez dağıtıp üç veri modelini uyumlu mu tutarız? Bir ajanın bir müşterinin küresel görünümüne ihtiyacı varsa hangi org’a sorar?

4. modüldeki haritaya dönün. Tek bir Salesforce kutusu üçe çıkar ve her ok yeniden çizilir. Çoklu org yanlış değildir. Hiçbir zaman bedava değildir.

Gerçek Sınırları Arayın

Başka bir org’u ne haklı çıkarabilir? Mimariyi şekillendirecek kadar gerçek sınırlar: veri yerelliği, düzenleme, yasal ayrım, gerçekten farklı işletme modelleri, henüz birleşmemiş bir satın alma, bölgesel bir barındırma kısıtı, çok farklı yönetişim, bazen ölçek ya da yalıtım. Liste tam değil. Mesele “bu gruplar farklı” ile “bu grupların mimari bir sınıra ihtiyacı var” ifadelerini birbirinden ayırmaktır. İkincisinin çıtası çok daha yüksektir.

Coğrafya Otomatik Olarak Bir Org Stratejisi Değildir

“30 ülkede faaliyet gösteriyoruz, o halde 30 org’a ihtiyacımız var.” Hayır. Coğrafya, mimari bir gereksinim getirdiğinde önemlidir. Bir şirketin dünyanın her yerinde ortak bir mimari üzerinde kullanıcıları olabilir. Bu yüzden ülkeleri saymam; onlarla birlikte ne geldiğini sorarım. Veri nerede saklanabilir? Nerede işlenebilir? Kişisel verinin sınır ötesine taşınmasında sınırlamalar var mı? Veri yerelliği konusunda sözleşmesel taahhütler var mı? Bir bölgenin farklı bir Salesforce hizmetine ya da barındırıcısına ihtiyacı var mı? “Almanya’da bir ofis var” tek başına yeterli değildir.

Barındırma Çizimin Bir Parçasıdır

Modern platformun haritayı daha ilginç hale getirdiği yer burası. Hyperforce, Salesforce’u dünyanın dört bir yanındaki bölgelerde genel bulut altyapısında çalıştırır ve müşterilere verilerinin nerede bulunacağı konusunda daha fazla seçenek ve kontrol verir (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), İngilizce). Dolayısıyla bir kutuyu “Salesforce, Avrupa” olarak etiketlediğimde o konum önemli olabilir.

Ama kesin olun. Bir org’un nerede yaşayacağını seçmek, her hizmetin her baytının orada kalacağının bir sözü değildir. Salesforce müşterilere, satın aldıkları hizmetler için ek alt işleyiciler dahil Hyperforce’un güven ve uyumluluk belgelerini incelemelerini söyler (aynı kaynak). Bu yüzden “X ülkesinde Hyperforce’tayız, o halde her şey X ülkesinde kalıyor” demeyin. Gerçekte hangi hizmetleri kullandığınızı ve hangi gereksinimi karşıladığınızı bilin. Ve neyi seçtiğinize dikkat edin: altındaki bulutu değil, bölgeyi. Hyperforce AWS üzerinde, 2026 sonundan itibaren de Google Cloud üzerinde çalışıyor ve bir org’un hangi sağlayıcıda duracağına Salesforce karar veriyor; birinden kaçınmak için belgelenmiş düzenleyici bir nedeni olan müşteri, hesap ekibiyle konuşur (aynı kaynak).

Avukatlık Taslamayın

Mimarların rollerini bilmesi gereken yer de burası. Biri “Avrupa gizlilik yasası ayrı bir org gerektiriyor” derse bunu körü körüne kabul etmem. Kendimi şirketin avukatı ilan edip gerektirmediğini de söylemem. Sorarım: hangi belirli gereksinimi karşılıyoruz? Verinin nerede saklandığı, nerede işlendiği, sınır ötesi aktarım, destek için ona kimin erişebileceği, bir sözleşme, şirket içi politika? Sonra bu gereksinimi mimariye dönüştürmek için gizlilik, güvenlik, uyumluluk ve hukuk ekipleriyle çalışırım. Yasal gereksinim uydurmayın ve görmezden de gelmeyin. Onları tercüme edin.

Avrupa Kendi Org’unu Aldığında

İşte gerçek senaryolarda gördüğüm bir sınır. Bir şirketin ABD’de güçlü bir varlığı, Avrupa’da da güçlü bir varlığı var: iki büyük müşteri tabanı, iki satış ve servis operasyonu ve GDPR etrafında kurulmuş bir Avrupa gizlilik programı. GDPR “ayrı bir Salesforce org’una ihtiyacınız var” demez. Kişisel veriler için, AB dışına ne zaman aktarılabileceği de dahil olmak üzere kurallar koyar (GDPR, Chapter V (opens in a new tab), İngilizce). Ama bu şirket, gizlilik ve hukuk ekipleriyle birlikte çalışarak, Avrupalı müşterilerinin kişisel verilerinin Avrupa’da barındırılan, Avrupa ekibi tarafından işletilen ve Avrupa yönetişimine tabi bir org’da yaşaması gerektiğine karar veriyor. Bu gerçek bir gereksinimdir ve benim değil, onlarındır.

Artık “tek büyük küresel org” bir tercih değil. Haritada bir sınır var, Salesforce AMER ve Salesforce EMEA, ve onu çizmem gerekiyor. Ve ikinci org asla yalnızca bir kutu daha değildir.

Click to enlarge

İki org, AMER ve EMEA. Kehribar renk ikinci org’un ekledikleridir: bir kutu daha değil, her ok yeniden.

Okları Yeniden Yürüyün

Birden fazla org olduğunda haritayı yeniden yürüyün. ERP her org’a ürün gönderiyor mu? Her biri siparişleri geri gönderiyor mu? Müşterilerin ana kaydı nerede ve verileri bölgeler arasında geçebilir mi? Entegrasyon katmanı küresel mi, bölgesel mi? Hangi kimlik sağlayıcı hangi kullanıcıların oturumunu açıyor? Analitik veri nereye gidiyor?

Bedeli en hızlı üç yer gösterir:

Raporlama. CEO küresel bir satış hattı (pipeline) istiyor. Tek org’da bu bir Salesforce raporudur. Üç org’da bir kurumsal raporlama sorunudur: çoğaltalım mı, ambara gönderelim mi, federasyon mu yapalım? Ne kadar güncel olmalı ve org’lar “pipeline”ı aynı şekilde tanımlıyor mu? Analitiğin yaşadığı yer verinin yaşadığı yeri izler ve operasyonel veriyi bilerek bölerseniz içgörünün nasıl yeniden bir araya geleceğini tasarlamanız gerekir.

Ana veri. Küresel bir müşteri ABD’de, Almanya’da ve Japonya’da alışveriş yapıyor. Üç org, dolayısıyla muhtemelen üç Hesap. Bunların aynı şirket olduğunu nasıl bilirsiniz? Küresel tanımlayıcı ne ve sahibi kim? Bir bölge adresi değiştirirse yayılmalı mı? Hangi öznitelikler küresel, hangileri bölgesel? Org stratejisi kimliği çözmez; kimlik sorununu değiştirir. Bu, 6. bölüm.

Entegrasyon. Tek org: Salesforce, entegrasyon katmanı, ERP. Üç org: entegrasyon katmanına üç bağlantı, belki biri kendi barındırıcısı ve bağlantısıyla; bazı akışlar paylaşılan, bazıları bölgesel; bazı verilerin geçmesine izin verilen, bazılarının verilmeyen. Ağ bile değişebilir: kurumun Hyperforce’a özel bir bağlantıya ihtiyacı varsa (AWS’de Salesforce AWS Direct Connect öneriyor; aynı Hyperforce SSS), çizimdeki her org ve barındırıcı planlanacak bir bağlantı daha demektir. Bir org’un nerede çalıştığı, kurumun geri kalanının ona nasıl ulaştığını değiştirebilir.

Tek org mu, çok org mu, şimdi verdiğiniz bir karardır; en başta, haritada. Org’ların daha sonra veriyi nasıl paylaşacağı (org’lar arası Salesforce Connect, aralarında entegrasyon, Data 360) işin mekaniğidir ve onu 14. bölüm, Tek Org mu, Çok Org mu? (coming soon), ele alıyor.

Tüm veri modelini ve entegrasyon mimarisini tasarlayıp ancak ondan sonra “bu arada, bunun üç org olması gerekiyor” diye duyarsanız küçük bir ayarlama yapmamışsınızdır. Mimariyi değiştirmişsinizdir. Kararın ilk gelmesinin nedeni bu.

Sırf Kutuları Küçültmek İçin Bölmeyin

Büyük bir org karmaşık hissettirir: çok sayıda birim, nesne, kullanıcı, entegrasyon. Biri “Herkesin kendi org’u olsa daha temiz olmaz mı?” der. Çizim daha temiz olabilir. Kurum olmayabilir. İç karmaşıklığı dağıtık karmaşıklıkla takas etmiş olursunuz: eşitleme, yinelenen veri, org’lar arası kimlik, küresel raporlama, birkaç yayın hattı, çoğaltılmış entegrasyonlar ve otomasyon ve hepsinin üzerinde yönetişim. Bazen bu yine de doğru takastır. Ama ayrı olmak basit olmakla aynı şey değildir.

Ve tek org da bedava değildir. Paylaşılan yönetişim daha önemli hale gelir, ekipler birbirini etkileyebilir, güvenlik sınırları dikkatli tasarım gerektirir, veri modeli pek çok gruba hizmet etmek zorundadır, yayınlar koordinasyon gerektirir ve bölgesel kurallar herkesi kısıtlayabilir. Yani mesele “Steve her zaman tek org diyor” değildir. Başlangıç eğilimim tek org; sonra beni ondan uzaklaştıracak kadar güçlü gereksinimi ararım.

Kararı Görünür Kılın

Org stratejisi önemliyse genel bir Salesforce bulutu çizmeyin. Org’ları çizin ve etiketleyin (AMER, EMEA, gerçek olan neyse), her birinin arkasındaki barındırma ya da veri yerelliği gereksinimini not edin ve bağlantıları yürüyün. Başka bir mimar her sınırın neden var olduğunu görebilmelidir. Neden üç Salesforce kutusu olduğunu açıklayamıyorsam kararı bitirmemişimdir.

Steve Trucking ABD’de tek bir org çalıştırıyor ve senaryo özetinde başka bir org gerektiren hiçbir şey yok. Ama bitirme projesi için bu modülü aklınızda tutun: kendi org’uyla gelen bir satın alma, tam olarak bu soruları sınayan türden bir sınırdır.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Bir ajan bir org sınırını kullanıcı için görünmez hale getirebilir. Altında mimari yine de ajanın hangi org’a ya da sisteme sorabileceğine, hangi verinin bölgeler arasında geçebileceğine ve hangi yanıtın esas olduğuna karar vermek zorundadır. Yapay zekâ karmaşıklığı deneyimde gizleyebilir; yönetişimi ya da sınırı ortadan kaldırmaz.

Mimarın Burada Karar Verdikleri

• Farklılıkları tek bir org içinde çözmek yerine birden fazla org için gerçek bir mimari neden olup olmadığı.
• Her org’un nerede çalıştığı ve onu oraya hangi veri yerelliği, düzenleme, sözleşme ya da iş gereksiniminin koyduğu.
• Hangi verinin org ve bölge sınırlarını geçebileceği, ana verinin nerede esas olduğu ve küresel kimliğin nasıl çalıştığı.
• Tek bir Salesforce kutusu birkaça çıktığında entegrasyonun, kimliğin, analitiğin ve raporlamanın nasıl değiştiği.
• Ayrılmanın faydasının yarattığı dağıtık mimariye değip değmediği.

Bir senaryoyu okuduğumda önce bu kararı ararım: bir org mu çok mu, nerede barındırılıyor ve neyin zoruyla? Bunları yanıtlayın, haritanın geri kalanı şekillenmeye başlar.

Daha Fazlası

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab) (İngilizce), Bölüm V (kişisel verilerin üçüncü ülkelere aktarılması), kontrol tarihi 2026-10-14.