Hiyerarşiler ve Çift Yönlü Veri

🌐 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 6. bölümü olan Ana Veri ve Kimlik bölümündeki 6 modülden 5.‘i. Her modül kendi başına okunabilir. Önceki: Harita Karar Değildir · Sonraki: 1. Kontrol Noktası: Steve Trucking

Bu modülün yanıtladığı soru: Birden fazla sistemin tuttuğu veriyi nasıl yönetirsiniz?

Kolay mimari: müşterinin sahibi ERP, Salesforce bir kopya alır, tamam. Gerçek kurumlar bu kadar temiz değildir. Yasal müşterinin sahibi ERP, satış ilişkisinin sahibi Salesforce’tur; bir bölüm SAP’ta yaşar, satın alınmış bir diğeri farklı bir ERP’de; potansiyel müşteriler yalnızca Salesforce’ta vardır. Sonra biri Salesforce kullanıcılarının ERP’nin kontrol ettiği bir alanı güncellemesini ister ve oklar iki yönü göstermeye başlar. Bunu öğretirken dediğim gibi: “En zor şey çift yönlü olanlardır.” Veriyi iki yöne göndermek teknik olarak zor olduğu için değil, iki sistem de değişikliğe katıldığında yetki konusunda son derece kesin olmanız gerektiği için.

İki Yönlü Veri İki Ana Kaynak Demek Değildir

Fatura adresinin sahibi ERP ve Salesforce’a kopyalanıyor. Bir temsilci müşteriden adresin değiştiğini öğreniyor ve iş birimi onun Salesforce’tan çıkmadan güncellemesini istiyor. Makul. Artık veri ERP → Salesforce ve Salesforce → ERP yönünde akıyor. Salesforce artık fatura adresinin ortak sahibi mi? Hayır. Bir entegrasyonun yönü yetkiye karar vermez. Temsilci Salesforce’un kopyasını değiştirmiyor. Mimari olarak esas değeri değiştirmeyi talep ediyor. ERP’nin alanını değiştirmiyorsunuz; onu değiştirmeyi talep ediyorsunuz. Arayüz Salesforce’tur; ana kaynak hâlâ ERP’dir.

Bu tasarımı değiştirir. Alanın sahibi Salesforce olsaydı kaydet ve tamam. Sahibi ERP ise “kaydet” şu anlama gelir: Salesforce önerilen adresi gönderir, ERP onu doğrular ve kabul eder, ana kaydını günceller ve esas değeri geri gönderir. Yönetilen değer ancak o zaman değişmiştir: talep → doğrulama → kabul → yayımlama; “iki sistemi de güncelle ve eşit kalmalarını um” değil.

Click to enlarge

Çift yönlü bir entegrasyon çift yönlü yetki yaratmaz.

Ana Kaynak Hayır Dediğinde

ERP değişikliği reddediyor: müşteri pasif, adres bir ERP kuralını ihlal ediyor, kullanıcının yasal adresleri değiştirme yetkisi yok, ERP çökmüş ya da bu arada başka biri müşteriyi değiştirmiş. Salesforce yeni adresi zaten gösterdiyse artık iki doğrumuz var ve 1. modül hangisinin kazanacağını zaten söyledi: ERP’ninki. Bu yüzden mimarinin talep edildi, henüz kabul edilmedi durumuna ihtiyacı vardır: ayrı bir önerilen değer, bir “bekleyen değişiklik” işareti ya da göstermeden önce teyit beklemek. Mekanizma kullanım senaryosuna bağlıdır. Kural değişmez: reddedilen bir talebin rakip bir doğruya dönüşmesine asla izin vermeyin.

Döngüler ve Çakışmalar

İşte klasik bir örnek. ERP Salesforce’u günceller; Salesforce’un entegrasyonu bir değişiklik görür ve onu ERP’ye gönderir; ERP bir güncelleme görür ve onu geri gönderir. Çok pahalı bir döngü kurdunuz. İyi bir iki yönlü tasarım bir değişikliğin nerede başladığını, ana kaynağın onu kabul edip etmediğini ve bunun yeni bir iş değişikliği mi yoksa zaten işlenmiş birinin yankısı mı olduğunu bilir: kaynak tanımlayıcılar, zaman damgaları, entegrasyon meta verisi, idempotent işleme. Entegrasyon bölümü derine iniyor. Ana veri ilkesi basit: bir değişikliği başlatıyor musunuz, yoksa yansıtıyor musunuz, bilin.

Sonra çakışmalar. 5. bölümde birini gördünüz: bir temsilci Steve’s Plumbing LLC isterken ERP’deki biri Steve’s Plumbing L.L.C. yazıyor (Yönetilen Kaydı Koruyun). İşte bir tane daha. Salesforce 125 Main Street öneriyor; neredeyse aynı anda bir ERP kullanıcısı adresi 130 olarak değiştiriyor. Hangisi kazanır? Evrensel bir teknik yanıt yoktur. Belki alanın sahibi olduğu için ERP her zaman kazanır; belki Salesforce talebi bir inceleme kuyruğuna gider; belki daha sonra kabul edilen değişiklik kazanır; belki ERP başlangıç değeri değişmiş her güncellemeyi reddeder. Bu eşzamanlılıktır, ama altında bir yetki kararı yatar ve kimse esas değişikliği kimin yapabileceğine karar vermediyse hiçbir entegrasyon kalıbı sizi kurtaramaz.

Ve tek bir alan basit durumdur. Bir adres bir sokak, bir şehir, bir posta kodudur. Salesforce yeni bir sokak gönderirken ERP şehri az önce değiştirmiştir. Sokağın tek başına geçmesine izin verir misiniz? Yoksa adresi tek bir işlem olarak mı ele alırsınız; alanların hepsi birlikte gider ya da hiçbiri gitmez ve tüm değişikliği reddedersiniz? Hangi alanların grup olarak taşınacağına ilk çakışmadan önce karar verin, sonra değil.

İki yönlü bir entegrasyon gördüğümde iki taraf da aynı veriyi değiştirdiğinde ne olur? diye sorarım. Yanıt “muhtemelen olmaz” ise işimiz bitmemiştir. Hangisi kazanır, reddeder miyiz, kuyruğa mı alırız, sürümleri mi karşılaştırırız, inceler miyiz? Alan iki yerde de düzenlenebilir olmalı mı? Bazen en iyi iki yönlü tasarım belirli bir öznitelik için bir yönü kaldırır: Salesforce talep edebilir; kabul edilen değeri yalnızca ERP yayımlar. Veri yine iki yönde hareket eder, ama alanın ana kaydını yalnızca bir sistem tutar. Bu fark her şeydir.

Hiyerarşiler de Ana Veridir

İlişkiler de ana veri olabilir. Kuzey Amerika ve Avrupa bölgeleri, her birinde ülke iştirakleri olan küresel bir ana şirket: hiyerarşinin kendisi anlam taşır. Ana şirket kim? Hangi iştirak hangi tüzel kişiliğin altında? Hangi hesaplar küresel müşteriye toplanıyor? Bu, raporlamayı, bölgeleri, fiyatlandırmayı, sözleşmeleri, kredi riskini, servisi, veri erişimini ve analitiği yönlendirir. Bir hiyerarşi içindeki kayıtlar kadar önemli olabilir ve aynı yönetişime ihtiyaç duyar. (Sınav hiyerarşi yönetimini adıyla anıyor; unutmak kolay.)

Salesforce’ta hesap hiyerarşileri Üst Hesap (Parent Account) alanıyla kurulur. Lightning hiyerarşi görünümü en fazla 2.000 hesap gösterir ve yalnızca kullanıcının görebildiklerini; kişi hesapları hiyerarşide desteklenmez; ve Hesap Sitesi (Account Site) bir şirketin konumlarını ayırt eder (Considerations for Using Account Hierarchy (opens in a new tab), İngilizce). Ama Üst Hesap alanı mimari soruyu yanıtlamaz: hiyerarşinin sahibi kim?

Sınav bilgisi. Hesap hiyerarşisinin temellerini bilin: Parent Account (Üst Hesap) ile kurulur; Lightning görünümü en fazla 2.000 hesap gösterir, yalnızca kullanıcının görebildiklerini; kişi hesapları desteklenmez; ve Account Site bir şirketin konumlarını birbirinden ayırır.

Tek Hiyerarşi, Birkaç Ana Kaynak

Deneyimime göre hiyerarşilerin ana kaydı bölünmüştür. Kuzey Amerika tüzel kişilikleri SAP’tan, Avrupa’dakiler başka bir ERP’den gelir, yeni potansiyel müşteriler Salesforce’ta kurulur ve satın alınmış bir iştirak henüz taşınmamıştır. Hiyerarşinin sahibi kim? Dala bağlıdır. Her ERP kendi dalını kontrol eder; Salesforce potansiyel müşteri ilişkilerini dönüşene kadar kontrol eder. Herkes sınırların nerede olduğunu bildiği sürece bu meşru bir mimaridir. Dal başına karar verin.

Click to enlarge

Hiyerarşi yetkisi dal dal atanabilir.

Bu yüzden Üst Hesap alanının yetkiyi gizlemesine izin vermeyin. Bir kullanıcı Salesforce’ta bir iştirakin üst kaydını değiştiriyor. Teknik olarak önemsiz. Mimari olarak, az önce şirketin yasal yapısını mı değiştirdi? O dalın ana kaydı ERP’deyse muhtemelen hayır; dolayısıyla Salesforce bunu engellemeli ya da bir değişiklik talebine dönüştürmelidir. Ya da belki Salesforce meşru olarak bir ticari hiyerarşi tutarken ERP yasal olanı tutuyordur. O zaman belki aynı ilişki olmamaları gerekir.

Bir şirketin birkaç geçerli hiyerarşisi olabilir: yasal, faturalama, satış, servis, coğrafi. Küresel ana şirket sözleşmeyi imzalar, bölgeler kendi başlarına servis alır, faturalama ortak bir finans tüzel kişiliği üzerinden yürür, satış bölgeye göre yönetir. Gerçek hiyerarşi hangisi? Hepsi; farklı soruları yanıtlarlar. Hata, tek bir hiyerarşi olması gerektiğini varsaymaktır. Her ilişki türü için net bir yetki olmalıdır: 1. modülün öznitelik ilkesinin ilişkilere uygulanması.

Ve her üst-alt ilişkisi ana veri değildir. Bugünkü teslimatları tek bir rotada gruplamak bir ilişkidir, ama işlemseldir, operasyonel bir olaydır. Bir müşteri hiyerarşisi kalıcı bir iş ilişkisini tanımlar. İkisi de bir modelde üst-alt gibi görünür; aynı yaşam döngüsünü paylaşmazlar. İlişkinin ne anlama geldiğini ve bu anlamın ne kadar sürdüğünü sorun.

Tek Müşteri, İki ERP

Bunu öğretirken sınıfa sorarım: kim tek bir Salesforce’u ve birden fazla ERP’si olan bir müşteriyle çalıştı? Her seferinde eller kalkar. Nedenini sorun, ERP’lerin bölgesel olarak (biri Kuzey Amerika, biri Avrupa için), işlevsel olarak (bir tesisat şirketi bir elektrik şirketi satın alır ve her biri kendi ERP’sini korur) ya da sadece tarihsel olarak bölündüğü ortaya çıkar: işletme satın alınmıştır ve henüz kimse onu taşımamıştır.

Müşteri olarak Steve’s Plumbing’i ele alın. Kuzey Amerika’da iş yapıyor, bu yüzden Kuzey Amerika ERP’sinde onun için bir müşteri kaydı var. Sonra Münih’te bir ofis açıyor ve Avrupa ERP’si kendi müşteri numarasıyla kendi müşteri kaydını oluşturuyor. Aynı şirket, iki kayıt, iki kimlik. Bunu tek bir Salesforce org’unda nasıl temsil ederim? Üç yol gördüm.

Bir hesap hiyerarşisi. Steve’s Plumbing üst kayıttır; Steve’s Plumbing North America ve Steve’s Plumbing Europe alt hesaplardır ve her alt hesap bir ERP’nin kaydını temsil eder. Püf noktası: alt kayıtlar artık gerçekten Steve’s Plumbing değildir. Bir bölgede iş yapan Steve’s Plumbing’dir ve az önce gördüğümüz gibi bir hiyerarşi anlam taşır.

Eş hesaplar. Yan yana iki hesap, her birinde hangi ERP’ye ait olduğunu söyleyen bir alan: bir şirket kodu, bir bölge. Hiçbir şey gizlenmez. Bedeli raporlamada ortaya çıkar: Steve’s Plumbing’i dünya genelinde görmek için bu iki hesabın aynı şirket olduğunu söyleyen bir şeye ihtiyacınız vardır.

ERP başına bir alt kaydı olan tek bir hesap. Tek bir Steve’s Plumbing ve her ERP için o ERP’nin müşteri kimliğini tutan bir kaydı olan bir alt nesne. İki ERP ya da on. Satışçılar tek bir müşteri görür ve tek bir sipariş verir; perde arkasında Flow’lar her satırın hangi ERP’ye gideceğine karar verir: elektrik işleri elektrik ERP’sine, tesisat tesisat ERP’sine. Ama artık ad ve adres gibi ortak değerler için hangi ERP’nin birincil olduğuna ve müşteri bir ERP’de varken diğerinde yoksa ne olacağına karar vermeniz gerekir.

Click to enlarge

Tek müşteri, iki ERP: onu Salesforce’ta temsil etmenin üç yolu.

ERP’leri Nasıl Senkronize Tuttuklarını Sorun

Peki hangisi? Önce: satışçılar ERP yapısının ne kadarını görmeli? Kuzey Amerika ile Avrupa’nın ayrı işletmeler olduğunu hep bildilerse, çünkü birine ya da diğerine oturum açıyorlar, bunu onlardan gizlemeyin. O yapıyı Salesforce’a eşler olarak taşıyın. İş birimi satışın önünde tek bir Steve’s Plumbing istiyorsa, ERP başına bir alt kaydı olan tek bir hesaba bakıyorsunuz demektir.

Sonra gerçekten karar veren soru gelir ve buna Salesforce’ta karar verilmez. Müşteriye sorarım: bu iki kaydı ERP’leriniz arasında nasıl senkronize tutuyorsunuz? Bakiye gibi her ERP’ye yerel olan şeyleri değil; o işlem verisidir. Ana veriyi kastediyorum: yasal ad, adresler. İki ERP’yi senkronize tutan bir ekipleri varsa onları tek bir hesapta bir araya getirebiliriz. Kendi ERP’lerinde senkronize tutamıyorlarsa, bizim Salesforce’ta senkronize tutmamızı nasıl bekleyecekler? O zaman eşler ya da bir hiyerarşi.

Bir ERP’nin ne olduğunu hatırlayın. Bunlar kurulması yıllar süren devasa sistemlerdir ve ana veriyi yönetmenin kendi yollarıyla gelirler. Onları Salesforce yönlendirmeyecek. ERP’leri biz kontrol edemeyiz. Onları Salesforce’ta nasıl temsil ettiğimizi kontrol ederiz.

Ortada MDM

Bazı müşteriler biz gelmeden bunu çözmüştür. Büyük bir şirket, uzun yıllardır işte, birkaç ERP: bu sorunla Salesforce’tan çok önce karşılaşmışlar ve ERP’ler arasında aracılık yapması için ortaya özel bir MDM ürünü koymuşlardır. Bu, 2. modüldeki birlikte var olma ya da merkezî MDM’dir. Artık Salesforce kendini her ERP’ye bağlamaz. Tek bir yeri, MDM merkezini işaret eder ve müşterinin tek bir temsilini alır. Yine de sık karşılaşmayı beklemeyin. Bunlar başlı başına büyük uygulamalardır; bunca yılda yalnızca iki üç kez biriyle çalıştım. Ve merkez olsa bile, her siparişin hangi ERP’ye gideceğini bilmesi için o alt nesneye yine de ihtiyacınız olabilir.

Click to enlarge

Ortada MDM: Salesforce tek bir yeri işaret eder.

Steve Trucking: Kimin Hiyerarşisi?

Bir Perakende Ortağının kendi yapısı vardır: kurumsal ana şirket, bölgesel birimler, dağıtım merkezleri, mağazalar. Steve Trucking bu hiyerarşinin sahibi mi? Hayır; ortak kendi organizasyonunun yetkilisidir. Ama Steve Trucking’in sözleşmeler, hesap yönetimi, servis ve raporlama için aynı konumların kendi ticari görünümüne ihtiyacı olabilir; belki ortağın altında her DC için bir alt hesap. İki meşru hiyerarşi, iki yetki. Onlara ad verin ve tek bir ağacın her ilişkiyi temsil ettiğini varsaymayın.

Sınırları Görünür Kılın

Yetki bölündüğünde sınırın görünür olmasını isterim: alan adlandırma, kayıt meta verisi, kaynak sistem tanımlayıcıları, izinler, entegrasyon davranışı, belgeleme. İstemediğim şey, bir geliştiricinin “bu Üst Hesap değerleri SAP’tan geliyor, potansiyel müşteriler hariç, Avrupa hariç” bilgisini keşfetmek için beş entegrasyonu okumasıdır. Bu sürdürülebilir bir yetki modeli değildir. Hiyerarşinin ana kaydı bölünmüşse bölünmeyi belgeleyin. Yetki dönüşümde değişiyorsa değişikliği belgeleyin. Salesforce bir değişikliği talep edebiliyor ama yapamıyorsa bunu deneyimde apaçık hale getirin.

Salesforce’ta bu tek bir alanla başlar. Bunun ana veri olduğunu açıkça söyleyen bir alan olmalıdır: ERP’nin anahtarı ya da bir “ana veri mi” bayrağı. Alan düzenlenebilirliğini bir kayıt türüne göre değil, o alana göre belirleyin; Dynamic Forms ile ERP alanlarını salt okunur göstermek için artık bir kayıt türüne ihtiyacınız yok (5. bölüm, Her Akış İçin Bir Kayıt Türü). Kayıtların ana kaynak dışında oluşturulmasına izin verebilirsiniz, ama düzenlemeleri izleyin.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Bir müşteri bir ajana “fatura adresimizi 125 Main Street olarak değiştirin” diyor. Alan Salesforce’ta tam orada. Ajan onu güncellemeli mi? Sahibi ERP ise hayır. Bir ajanın yalnızca alan erişimine değil, yazma yetkisine ihtiyacı vardır: eylemi onaylı yolu kodlamalıdır; bir değişiklik talebi gönderip “Değişikliği işleme alınması için gönderdim” demeli, yanlışlıkla “Fatura adresinizi güncelledim” diye bildirmemelidir.

Mimarın Burada Karar Verdikleri

• Bir Salesforce düzenlemesinin esas veriyi mi değiştirdiği yoksa sahibi olan sistemden bir değişiklik mi talep ettiği.
• İki yönlü akışların başlatılan değişiklikleri yankılardan nasıl ayırdığı ve reddi, çakışmaları, gecikmeyi ve başarısızlığı nasıl ele aldığı.
• Gerekirse dal dal, her hiyerarşinin sahibinin kim olduğu.
• Birkaç ERP’de tutulan tek bir müşteri için: bir hiyerarşi, eşler ya da ERP başına bir alt kaydı olan tek bir hesap; buna müşterinin ERP’lerini ne kadar iyi senkronize tuttuğu karar verir.
• Rakip hiyerarşilerin gerçekte farklı meşru ilişkiler olup olmadığı: yasal, faturalama, satış, servis.
• Yetki sınırlarının ve onaylı yazma yollarının kullanıcılara, entegrasyonlara, geliştiricilere ve ajanlara nasıl görünür kılındığı.

Paylaşılan yetki sorun değildir. Belirsiz yetki sorundur. Birkaç ERP farklı dalların ana kaydını tutabilir, Salesforce bazı özniteliklerin ana kaydını tutup diğerlerinde değişiklik talep edebilir ve birkaç hiyerarşi tek bir kurumu tanımlayabilir. Her önemli öznitelik ve ilişki için sahibinin kim olduğunu, onu kimin değiştirebileceğini, esas değişikliğin nerede yapıldığını ve sistemler çeliştiğinde ne olacağını söyleyebildiğiniz sürece bunların hepsi işe yarar. Söyleyemiyorsanız diyagrama bir çift yönlü ok daha eklemek bunu düzeltmez.

Daha Fazlası

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.