Yönetişim Org'un İçine Tasarlanı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 5. bölümü olan Veri Kalitesi ve Yönetişim bölümündeki 6 modülden 1.‘i. Her modül kendi başına okunabilir. Sonraki: Kötü Veriyi Dışarıda Tutmak

Bu modülün yanıtladığı soru: Veri yönetişimi bir mimar için ne anlama gelir ve kim ne yapar?

İnsanlar veri yönetişimi sözünü duyduğunda toplantıları düşünür: komiteler, politikalar, standartlar, veriyle kimin ne yapması gerektiğini açıklayan bir belge. Bunların hepsi bir yönetişim programının parçası olabilir. Bir mimar olarak benim ilgilendiğim soru farklıdır: politika nerede uygulanıyor?

Politika bir alanı yalnızca Finans’ın değiştirebileceğini söylüyorsa bunu ne uyguluyor? Yasal müşteri kaydının sahibinin ERP olduğunu söylüyorsa Salesforce’taki birinin onu değiştirmesini ne durduruyor? Ekiplerin bir Alıcının adresini yalnızca kendi durakları için, yalnızca o gün görebileceğini söylüyorsa bunu gerçekte ne doğru kılıyor? Bunu yedi yıl saklayın diyorsa yedi yıldan sonra onu ne arşivliyor ya da kaldırıyor? Uygulama noktası olmayan bir politika çoğunlukla bir dilektir. Yönetişim, bu kararlar sistemin içine inşa edildiğinde mimariye dönüşür.

Yönetişim Hiçbir Zaman Bitmez

Bunu baştan söyleyeyim: yönetişimi bitirmezsiniz. Gelgitlerle ilerlediğini gördüm. Bir şirket veri kalitesine gerçek bir ilgi gösterir ve işler düzelir. İlgi başka yere kayar ve kalite düşer. Yeni bir entegrasyon devreye girer, bir iş birimi sürecini değiştirir, biri bir dosya içe aktarır, şirket başka bir şirketi satın alır, bir ajan kayıt yazmaya başlar ve sorun yine değişir. Hedef, her kaydın sonsuza kadar kusursuz olduğu efsanevi bir durum değildir. Veriyi iş için yeterince güvenilir tutmak ve kötü verinin en kötüsünü dışarıda tutmaktır. Bu süregelen bir iştir.

Salesforce büyük ölçüde tek başına durduğunda yönetişim veriyi tek bir yerde temizlemek demektir. 4. bölümdeki haritada bir düğüm olduğunda daha zor ve daha gerekli hale gelir. Artık müşteri Salesforce’ta, ERP’de, ambarda, ortak sistemlerinde, Data 360’ta yaşıyor. Sahibi kim? Onu kim değiştirebilir? Hangi kopya esas, hangi öznitelikler taşınabilir, ne kadar süre saklanırlar ve yanlış olduklarında kim hesap verir? Bunlar yapılandırma soruları değil. Yapılandırmaya dönüşen yönetişim sorularıdır.

Kayıt Sahibi Veri Sahibi Değildir

Sahip sözcüğüyle başlayın, çünkü Salesforce onu kafa karıştırıcı hale getiriyor. Bir hesabı açın, bir Sahip görürsünüz: diyelim ki bir satış temsilcisi. Temsilci müşteri verisinin sahibi mi? Mutlaka değil. Salesforce’ta sahibi olan bir nesnedeki kaydın sahibi bir kullanıcı ya da bir kuyruktur; sahip tam erişim alır ve sahip, rol hiyerarşisi ve paylaşım kuralları aracılığıyla atamayı ve paylaşımı belirler (Sharing and Record Access Features (opens in a new tab), İngilizce). Bu kayıt sahipliğidir: bir platform mekanizması.

Veri sahibi başka bir şeydir: veriden bir iş varlığı olarak hesap veren kişi ya da işlev. Yasal müşteri bilgisinin sahibi Finans, teslimat durumunun sahibi Operasyon, çalışan verisinin sahibi İK olabilir. Salesforce bunu kaydetmeniz için bir yer bile verir: her alandaki Data Owner (veri sahibi) sınıflandırma alanı (Data Classification Metadata Fields (opens in a new tab), İngilizce).

Steve Trucking’de bir Perakende Ortağının hesabının sahibi o ortağı yöneten satış yöneticisi olabilir. Ama ortağın yasal kimliği Finans tarafından yönetilir ve ana kaydı finans ERP’sindedir. Satış, servis, operasyon ve ortak portalının hepsi hesaba ihtiyaç duyar; bunların hiçbiri, Finans onu belirledikten sonra satış yöneticisinin ortağın yasal kimliğini değiştirmesi gerektiği anlamına gelmez. Ekiplerin Sahip alanına bakıp veri sahipliğini çözdüklerini varsaydıklarını gördüm. Çözmediler. Kayıt ataması iş hesap verebilirliği değildir.

Sahip, Veri Sorumlusu, Muhafız

Üç yönetişim rolü, üç farklı iş.

Veri sahibi politikayı belirler. Verinin ne anlama geldiğini, onu kimin oluşturup değiştirebileceğini, ne kadar doğru olması gerektiğini, ne kadar süre saklanacağını, onu kimin görebileceğini, hangi sistemin esas olduğunu ve yanlış olduğunda ne olacağını yanıtlar. Bu yanıtları mimar icat etmemelidir. Bu en kesin pozisyonlarımdan biri: sahipler politikayı belirler; mimarlar uygular. Finans, müşteri etkinleştikten sonra yasal adın yalnızca ERP süreciyle değişebileceğini söylüyorsa bu bir yönetişim kararıdır. Onu mekanik olarak doğru kılmak benim işimdir.

Veri sorumlusu işin yürümesini sağlar. Veri sorumlusu (data steward) verinin günlük sağlığına yakındır: kalite sinyallerini izler, yinelenen kayıtları araştırır, istisnaları çözer, düzeltmeleri koordine eder, tanımları güncel tutar, sürekli kötü veri üreten süreci fark eder. İki iş daha veri sorumlusuna düşer. İki ekip bir alanın ne anlama geldiği, sahibinin kim olduğu ya da onu kimin görebileceği konusunda anlaşamadığında, veri sorumlusu anlaşmazlığı sahibine götürür ve kararın uygulanmasını takip eder. Ve veri sorumlusu veri okuryazarlığını geliştirir: veriyi giren ve kullanan insanların onun ne anlama geldiğini ve kuralların neden var olduğunu anlamasına yardım eder. Bir veri sorumlusunun bir şemadaki addan fazlasına ihtiyacı vardır. Zamana, görünürlüğe, bir sürece ve sorunları düzelttirme yetkisine ihtiyacı vardır. Aksi halde “veri sorumlusu” birinin çeyrekte bir bakılan sekizinci sorumluluğuna dönüşür.

Muhafız sistemi işletir. Yöneticiler, platform ekipleri, güvenlik ekipleri: veriyi saklayan ve işleyen teknolojiyi işleten kim varsa. Sahip yalnızca bu rollerin onu görebileceğini söyler; muhafız (custodian) bunu sağlayan kontrolleri işletir. Adlar, her hesap verebilirliği netleştirmekten daha az önemlidir ve küçük bir kuruluşta bir kişi iki şapka takabilir.

Program Nasıl Yürür

Yönetişim programları genellikle üç biçimde gelir. Merkezî: tek bir ekip her alan için politikaları ve standartları yazar. Tutarlıdır ve işi yapan insanlardan uzakta bir darboğaza dönüşebilir. Federe (merkeziyetsiz): finans, satış ya da operasyon gibi her alan, birkaç ortak kural içinde kendi verisini yönetir. İşe yakındır ve tanımlar alanlar arasında birbirinden uzaklaşır. Karma: küçük bir merkezî ekip standartların ve ortak tanımların sahibidir; alan sahipleri ve veri sorumluları kendi verilerini yürütür. Gördüğüm kurumların çoğu sonunda karmanın bir yerine varır. Mimar için biçim pratik bir soruyu yanıtlar: ben bir politikayı uygulamadan önce onu kim onaylar ve ortak tanımlar nerede yaşar?

Sınav bilgisi. Bir yönetişim programını yürütmenin üç yolunu, merkezî, federe (merkeziyetsiz) ve karma, ve her birinin politikayı kimin belirlediği ve ortak tanımların nerede yaşadığı açısından ne anlama geldiğini bilin.

RACI Yerini Hak Etsin

Bir RACI (kimin Sorumlu, Hesap Veren, Danışılan ve Bilgilendirilen olduğu) yardımcı olur, ama yönetişim “bir tane gerektiriyor” diye yapılmış dev bir elektronik tablo değil. Onun mimari soruları yanıtlamasını isterim; 4. bölümdeki üç sorudan başlayarak (Kategorilerin Arkasındaki Dört Soru): veri nerede oluşturuluyor, nerede düzenleniyor ve nerede başvuruluyor? Bunlar çoğu zaman farklı sistemlerdir. Bir ürünü ele alın: ERP onu oluşturur, Salesforce ona başvurur, portal onu gösterir, ambar onu analiz eder. Şimdi iş birimi “aktif ürün”ün ne anlama geldiğini değiştiriyor. Değişiklik nerede başlıyor, onu kim onaylıyor, nasıl yayılıyor ve hangi kopyalar salt okunur? Yanıtlayamıyorsanız henüz yönetişiminiz yok. Kopyalarınız var. İyi bir RACI tam olarak bu belirsizliği açığa çıkarır.

Yönetişim Mekanik Hale Gelmelidir

İş birimi yasal müşteri adını yalnızca Finans’ın değiştirebileceğini söylüyor. Mimari yanıtın “bunu eğitimde anlatırız” olmasını istemem. Eğitim yardımcı olur; uygulama değildir. Belki alan düzeyinde erişim, bir doğrulama kuralı, yalnızca entegrasyonun yazdığı bir alan ya da doğrudan düzenleme yerine kontrollü bir süreçtir. Mekanizma gereksinime bağlıdır, ama bir tane olmalıdır:

Yönetişim politikası	Sahip karar verir	Olası uygulama noktası
Yasal müşteri kimliğinin sahibi ERP’dir	Finans	Yalnızca entegrasyonun yazdığı alanlar, izinler, doğrulama
Kişisel veriyi yalnızca ihtiyacı olanlar görür	Gizlilik, güvenlik	Paylaşım, izinler, alan erişimi
Müşteri tanımlayıcıları benzersizdir	İş sahibi	Benzersiz Harici Kimlik, yinelenen kayıt kuralları
Yönetilen kayıtlar elle oluşturulmaz	Veri sahibi	İzinler, otomasyon, entegrasyon
Hassas verinin belirli bir saklama süresi vardır	Gizlilik, hukuk	Bir saklama ya da silme süreci
Önemli değişiklikler kanıtlanabilir olmalıdır	Uyumluluk	Alan geçmişi, denetim izi
Verinin kaynağı tanımlanabilir kalır	Veri sahibi	Bir kaynak alanı, köken meta verisi

Bilerek olası uygulama noktası diyorum. Bu bir özellik seçme tablosu değildir. Düşünme sırasıdır: politika ne, sahibi kim ve mimaride onu doğru kılan ne?

Click to enlarge

Sahipler politikayı belirler; mimarlar onu uygular.

İyi Davranışa Güvenmeyin

“ERP müşteri kimliğini asla değiştirmeyin.” Herkes bunu bilir, ta ki biri değiştirene kadar: kazara, bir veri yüklemesiyle, otomasyonla, bir entegrasyonla, bir ajanla. Onu değiştirmek kurumsal veriye zarar verecekse “lütfen yapmayın” kontrol değildir. Kontrolü inşa edin. Güven ama doğrula. İnsanlar, entegrasyonlar, otomasyon ve yapay zekâ hepsi hata yapar; dolayısıyla mimari, sonunda bir şeyin politikanın yasakladığını deneyeceğini varsaymalıdır. O zaman ne olur?

Yönetişim Sistem Sınırlarını Aşar

Haritaya dönün. Müşterinin sahibi ERP; Salesforce, ambar ve bir müşteri veri platformu kopya tutuyor; bir ortak bir kısmını alıyor. Politika hangi sisteme uygulanır? Hepsine. Salesforce bir yasal ad değişikliğini doğru biçimde engellerken bir entegrasyon aşağı akıştaki bir sistemin onun üzerine yazmasına izin verebilir. Salesforce ambarın hâlâ tuttuğu kişisel veriyi silebilir. Salesforce’ta hassas olarak sınıflandırılmış bir alan başka bir yerde sınıflandırılmamış bir metin alanına düşebilir. Yönetişim org’un kenarında duramaz, çünkü veri durmaz. 4. bölümün önce gelmesinin nedeni bu: harita, yönetişimin ne kadar uzağa ulaşması gerektiğini size söyler.

Yeterince Yönetin, Her Şeyi Değil

Tersi başarısızlık da aynı derecede gerçektir. Yönetişimin önemli olduğunu keşfederiz, bu yüzden her şeyi kilitleriz: kimse oluşturamaz, her değişiklik onay gerektirir. Veri yönetilir ve kimse işini yapamaz. Yönetişim veri için uygun kontrol demektir: bazıları için sıkı, diğerleri için hafif. Bazı kayıtlar serbestçe oluşturulabilir, bazıları onay gerektirir; bazı alanları neredeyse herkes düzenleyebilir, bazılarını yalnızca entegrasyon. Bir sonraki modül tam olarak bu konuda pratikleşiyor.

Ve yönetişim hiçbir zaman bitmediği için uygulamanın geri bildirime ihtiyacı vardır. Yinelenen kayıtlar artıyor mu? Zorunlu alanlar çöple mi doluyor? Entegrasyonlar başarısız mı oluyor, kullanıcılar geçici çözümler mi buluyor, istisnalar mı artıyor, veri sorumluları bütün günlerini tek bir soruna mı harcıyor? Bu sinyaller size tasarımın işe yarayıp yaramadığını ve bazen kontrolün ya da politikanın değişmesi gerektiğini söyler.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yönetişimin yeni bir tüketicisi var: ajan. Neyin ve ne için kullanılabileceğine hâlâ veri sahibi karar verir; mimar hâlâ bunu uygulanabilir kılar. Değişen hız ve ölçektir. Bir ajan yönetilen veriyi bir insandan çok daha hızlı okur, birleştirir ve ona göre harekete geçer; dolayısıyla yalnızca bir belgede var olan bir politika daha da az koruma sağlar.

Mimarın Burada Karar Verdikleri

• Her önemli veri alanından kimin hesap verdiği ve bunun kayıt sahipliğinden nasıl farklı olduğu.
• Verinin veri sorumlusunun kim olduğu ve onu muhafız olarak kimin işlettiği.
• Önemli verinin harita genelinde nerede oluşturulduğu, düzenlendiği, başvurulduğu ve ana kaydının nerede tutulduğu.
• Hangi uygulama noktasının her önemli politikayı mekanik olarak doğru kıldığı.
• Mimarinin yönetişimin işe yarayıp yaramadığını ya da gevşemeye başlayıp başlamadığını nasıl gösterdiği.

Bir yönetişim gereksinimi duyduğumda onu tercüme ederim. “Bunun sahibi ERP.” “Bunu yalnızca bu insanlar görebilir.” “Bunu kimin değiştirdiğini kanıtlamamız gerekiyor.” “Bunu yedi yıl saklayın.” Her seferinde: bana uygulama noktasını gösterin. Politikaya mimar karar vermez. Onu uygulayan sistemi tasarlarız. Yönetişimin bir belge olmaktan çıkıp mimariye dönüştüğü yer burasıdır.

Daha Fazlası

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.