Kötü Veriyi Dışarıda Tutmak

🌐 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 2.‘si. Her modül kendi başına okunabilir. Önceki: Yönetişim Org’un İçine Tasarlanır · Sonraki: Verinizi Tanıyın

Bu modülün yanıtladığı soru: Veriyi nasıl iyi tutarsınız ve öyle kalmasını nasıl sağlarsınız?

Kötü veriyle başa çıkmanın iki yolu vardır: içeri girmeden durdurmak ya da sonradan temizlemek. Biraz ikisini de yapacaksınız. Ama seçim bana kalırsa, sorunu sonsuza kadar temizlemeye dayalı bir organizasyon kurmaktansa onu önlemeyi tercih ederim. Yinelenen kayıtlar, hatalı tanımlayıcılar, eksik bilgiler, standart dışı değerler, kullanıcıların başka bir sistemin sahip olduğu alanları değiştirmesi, entegrasyonların iyi verinin üzerine kötü veri yazması: hepsi birinin temizlik projesine dönüşür. Dolayısıyla tasarım sorusu şudur: en başta hangi kötü veriyi makul ölçüde dışarıda tutabilirim? Ve “makul ölçüde” önemlidir, çünkü yanıt sistem kullanılamaz hale gelene kadar her alanı kilitlemek değildir.

“Yeterince İyi” Bir İş Tanımıdır

Kötü veriyi önlemeden önce iyiyi tanımlayın. Tek bir tanım yoktur. İyi; süreci yürütecek kadar eksiksiz, karar verecek kadar doğru, iş yüküne yetecek kadar güncel, diğer sistemlerle birleştirilecek kadar tutarlı, hangi müşteriyi kastettiğimizi bilecek kadar benzersiz, otomasyon için yeterince standart, nereden geldiğini bilecek kadar izlenebilir anlamına gelebilir. Veriye bağlıdır. Steve Trucking bir Perakende Ortağını faturalandırıyorsa ortağın yasal kimliği doğru olmalıdır. Bir temsilci toplantıdan sonra not alıyorsa her cümleyi onaylayan bir komiteye kimsenin ihtiyacı yoktur. “Yeterince iyi” bir iş tanımıdır; mimar onu ölçülebilir ve uygulanabilir kılar.

Pahalı Hataları Önleyin

Her hatalı alan aynı ilgiyi hak etmez. En çok aşağı akışta sonuçları olan hataları önemserim. Yinelenen bir müşteri iki satış geçmişi, iki servis geçmişi, iki kişi kümesi, iki harici kimlik, aynı şirketi eşitleyen iki entegrasyon, ambarda ve Data 360’ta iki sürüm ve sonunda hangi müşterinin gerçek olduğuna karar veren bir ajan demektir. Bu, bir açıklamadaki yazım hatasından çok daha pahalıdır. Bu yüzden “her alanı nasıl doğrularız?” ile başlamayın. Hangi kötü veri en büyük iş ya da mimari sorunu yaratıyor? ile başlayın ve en güçlü kontrolleri oraya koyun.

Açık mı, Kilitli mi?

Hesap oluşturma klasik örnektir. Her satışçı hesap oluşturabilmeli mi? Yanıtım: verinin etrafındaki yönetişime bağlıdır. Küçük ve orta ölçekli org’ların çoğu için açık oluşturma sorun değildir. Bir temsilci bir potansiyel müşteriyle tanışır, hesabı oluşturur, işe koyulur; CRM bunun içindir. Yinelenen kayıt kuralları, zorunlu bilgiler ve veri sorumluluğu kaliteyi yönetir. Yönetişim kulağa sorumlu geliyor diye ağır bir onay süreci eklemem.

Şimdi haritayı değiştirin. Yasal müşterinin ana kaydı ERP’dedir, Salesforce’a bir ERP tanımlayıcısıyla akar ve esas kaynak ERP’dir. Artık açık oluşturma, aynı yönetilen varlığı oluşturmanın iki yolu demektir. ERP ve bir temsilci aynı şirketi oluşturduğunda hangisi kazanır, entegrasyonlar hangi tanımlayıcıyı kullanır, geçmişi hangi kayıt tutar? Açık oluşturma bir kullanılabilirlik sorusu olmaktan çıkar ve bir ana veri sorusuna dönüşür. Hesapların ana kaydı bir ERP’deyse ya da onunla eşitleniyorsa oluşturmayı kilitleyin.

Ama tamamen kilitlemek de başarısız olur. Temsilci ERP’de olmayan bir potansiyel müşteriyle tanıştı ve bir fırsat açmak istiyor, yönetişim modeli de “sana hesap yok” diyor. Böylece Finans için üç gün bekliyor, fırsatı yanlış hesaba bağlıyor ya da potansiyel müşteriyi bir not alanında veya bir elektronik tabloda tutuyor. Veri modelini koruduk ve işe zarar verdik.

Orta Yol: Geçici Bir Kayıt Türü

Sevdiğim orta yol şu. Satışın hesabı belirli bir kayıt türü altında, bir potansiyel ya da geçici tür altında oluşturmasına izin verin ve onun yönetilen türe dönüşümünü kontrol edin. Satış şirketi kaydeder ve satmaya başlar. Kayıt açıkça şunu söyler: henüz esas sistemde kurulmadı. Sonra kontrollü bir süreç onu dönüştürür: Finans onaylar ya da bir entegrasyon onu ERP’ye gönderir; ERP de onu var olan bir müşteriyle eşleştirir veya yeni bir müşteri oluşturup esas tanımlayıcıyı geri gönderir. Artık kayıt bir sınırı geçer, geçici → yönetilen; bu, iki sistemin her birinin ana kayıt olduğuna inandığı şeyi oluşturmasından çok farklıdır.

Öğrettiğim mekanizma kayıt türüdür. Ne kullanırsanız kullanın, durumu veride görünür kılın: kaydın nereden geldiği, sınırı geçip geçmediği, onu artık kimin değiştirebileceği ve onu esas sisteme bağlayan tanımlayıcı. Yalnızca dönüşümden sonra var olan ERP müşteri kimliği en net sinyaldir.

Her Akış İçin Bir Kayıt Türü

Akışın tamamını tek bir resme koyun, bunun neden işe yaradığını göreceksiniz. Müşteriler ve ürünler ERP’den içeri gelir. Fırsatlar ve satır kalemleri dışarı gider ve ERP’nin siparişlerine dönüşür. Peki hesaplar? Bazıları içeri gelir, bazıları dışarı gider. Bu yüzden uygulamalar boyunca gördüğüm yaygın bir kalıp, Hesap üzerinde her yön için bir tane olmak üzere iki kayıt türüdür. Bir Satış hesabı Salesforce’ta doğar: temsilciler onu oluşturur, düzenler, ona satış yapar ve müşteri olduğunda ERP’ye gönderilir. Bir ERP hesabı (ben buna Müşteri ya da sadece SAP dedim) ERP’de doğar ve entegrasyon aracılığıyla içeri gelir. O kayıt türünü entegrasyon dışında kimse oluşturmaz ve ana veri alanları (yasal ad, adresler, ödeme koşulları) kullanıcılar için salt okunurdur. Kayıt türü size kaydın hangi yöne aktığını söyler; böylece ana kaynağın yönü tam orada, kaydın üzerindedir.

Click to enlarge

Her akış için bir kayıt türü: Satış hesapları dışarı gider, ERP hesapları içeri gelir.

Zor durumu ortadan kaldırmaz. Bir temsilci Steve’s Plumbing için bir potansiyel müşteriyi dönüştürür, ama Steve’s Plumbing zaten bir ERP hesabı olarak vardır ve yinelenen kayıt kontrolü bir şekilde onu yakalamamıştır. Artık birleştiriyor, alt kayıtları yeni üst kayda bağlıyor ve hangi kaydın hayatta kalacağına karar veriyorsunuz (6. bölüm, 3. modül).

Ve kayıt türünün kendisine takılıp kalmayın. Normalde güçlü bir gerekçe olmadıkça kayıt türlerinden kaçınırım. Burada onları kullandım, çünkü Dynamic Forms’tan önce sayfa düzenini kayıt türü seçiyordu ve bir düzen ERP alanlarını salt okunur gösteriyordu. Dynamic Forms ile görünürlük kuralları alanları bir alanın değerine göre gösterip gizleyebilir, bir alan belirli bir sayfada salt okunur olabilir ve Salesforce’un kendisi Dynamic Forms’un ihtiyaç duyduğunuz sayfa düzeni ve kayıt türü sayısını azalttığını söylüyor (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab), İngilizce). Ama bir sayfada salt okunur olmak o sayfada salt okunur olmaktır: API, bir veri yüklemesi ya da bir entegrasyon alana yine de yazabilir. Gerçek uygulama alan düzeyinde güvenlik ya da bir doğrulama kuralıdır; arayüz doğrulaması veri doğrulaması değildir (3. bölüm, 9. modül). Kayıt türleri, iki tür hesabın farklı seçim listesi değerlerine ya da iş süreçlerine ihtiyaç duyduğu durumlarda hâlâ yerini hak eder. Asıl önemli olan, bir alanın kaydın nereden geldiğini açıkça söylemesidir: ERP anahtarının kendisi, bir ana veri bayrağı ya da bir kaynak seçim listesi. Sonra düzenlenebilirliği o alana göre belirleyin.

Click to enlarge

Geçiciden yönetilene: satış hemen satmaya başlar; kaydı yalnızca esas süreç yönetilen hale getirir.

Yönetilen Kaydı Koruyun

Müşteri ERP’den geri geldiğinde ERP kimliği, yasal adı, vergi numarası ve faturalama bilgileri yönetilen özniteliklerdir. Temsilci bunları değiştirmeli mi? Sahibi ERP ise hayır. Bu, 1. modülün uygulama noktasına ihtiyaç duyan politikasıdır: ERP kimliği salt okunur, yasal kimlik kontrol altında; temsilci ise bölgeyi, ilişki notlarını ve Salesforce’un kendi sınıflandırmalarını düzenlemeye devam eder. Amaç dokunulmaz bir hesap değildir. Salesforce’un sahip olduğu veri ile Salesforce’un başvurduğu veri arasında net bir çizgidir. (4. bölümdeki erp_ öneki bu çizgiyi şemada görünür kılar.)

Sonunda elinizde kalan, aslında karma olan bir altın kayıttır. ERP’nin ana veri alanları içeri gelir: yasal ad, fatura ve teslimat adresleri, ödeme koşulları. Sonra Salesforce asla geri gitmeyen kendi alanlarını ekler: bir satış derecelendirmesi, son sipariş tarihi, pazarlamanın kullandığı hemen her şey. Aynı hesap, iki tür alan ve her türün tek bir kaynağı var.

En zor şey çift yönlü akışlardır. Diyelim ki bir temsilcinin ERP’deki yasal adın Steve’s Plumbing’den Steve’s Plumbing LLC’ye değiştirilmesine ihtiyacı var. Aynı beş dakika içinde ERP’deki biri onu Steve’s Plumbing L.L.C. olarak değiştiriyor. Kimin değişikliği kazanır? Zihniyet şu: bir alanın ana kaynağı ERP ise alanı değiştirmiyorsunuz, değiştirilmesini istiyorsunuz. Talep çakıştığında ne olacağına karar verin: ERP kazanır, değer bu arada değiştiyse talep reddedilir ya da bir insanın çözmesini bekler. Ve ilişkili alanların tek bir değişiklik olarak birlikte mi yoksa tek tek mi taşınacağına karar verin. 6. bölüm çakışmaları daha ileri götürüyor (Döngüler ve Çakışmalar).

Yinelenen Kayıtları Kapıda Durdurun

Yinelenen kayıtlar katlanarak büyür. Oluşturulmadan önce yakalayın, küçük bir sorundur. İki yıl sonra, her ikisine de bağlı fırsatlar, vakalar, kişiler, faturalar, entegrasyonlar ve analitikle bulun, büyük bir sorundur. 3. bölümün 7. modülü mekanizmaları ele aldı (eşleştirme kuralları, yinelenen kayıt kuralları, benzersiz Harici Kimlikler); bu yüzden onları yeniden öğretmeyeceğim. Yönetişim sorusu şudur: yinelemeyi nerede önlemeliyiz, nerede tolere edip sonra çözeceğiz? Gelişigüzel bir pazarlama potansiyel müşterisi belirsizlikle yaşayabilir. Finansal işlemleri olan, ERP’nin yönettiği bir müşteri yaşayamaz.

Makinelerin Okuduğunu Standartlaştırın

Serbest metin insanlar için harikadır, bir sistemin onu yorumlaması gerektiğinde ise berbattır. Rota planlamayı yönlendiren bir alana Arizona, AZ, Ariz., Phoenix area ve Southwest koyun, bir kalite sorununuz olur. Bir değer otomasyonu, entegrasyonu, raporlamayı, güvenliği, atamayı ya da bir ajanın eylemini yönlendiriyorsa ne kadar standart olması gerektiğini iyice düşünün. Her metin alanı seçim listesine dönüşmez, ama insanların okuduğu bilgiyi makinelerin karar verdiği bilgiden ayırın. İkincisi daha güçlü kontrolü hak eder.

Zorunlu Alanların Sahte Veri Yaratmasına İzin Vermeyin

Bir alanın önemli olduğuna karar verip onu zorunlu yaparız. Kullanıcı yanıtı bilmiyor, sistem devam etmesine izin vermiyor; bu yüzden N/A, Unknown, 999999 ya da test@test.com yazıyor. Alan eksiksiz; veri çöp. Bir şeyi zorunlu yapmadan önce kullanıcının o noktada onu gerçekten bilip bilmediğini sorun. Bilmiyorsa süreçte daha sonra zorunlu yapın, başka bir sistemin sağlamasına izin verin, geçici durumu kullanın ya da bilinmemenin meşru bir yanıt olduğu durumlarda açık bir Bilinmiyor seçeneği sunun. Bir doğrulama kuralı bir politikayı uygulayabilir. Birine bilmediği bir şeyi bildiremez.

Her Veri Sınırının Bir Kalite Kararına İhtiyacı Vardır

Kötü verinin tek kaynağı insanlar değildir; entegrasyonlar onu daha hızlı üretir. Bir Perakende Ortağının yük listesi birkaç yüz satırla geliyor. Bir avuç satırda geçersiz posta kodları var, birkaçı bilinmeyen bir dağıtım merkezini belirtiyor, ikisi aynı sipariş referansını tekrarlıyor. Ne olur? Tüm dosyayı mı reddederiz? İyi satırları kabul edip kötüleri geri mi göndeririz? Her şeyi yükleyip sonra mı temizleriz? İstisnaları karantinaya mı alırız? Kime haber verilir ve ortak neyin başarısız olduğunu nasıl öğrenir? Evrensel bir yanıt yoktur, ama bir yanıt olmalıdır. 4. bölüm her okun bir mekanizmaya ihtiyacı olduğunu söyledi. Ekleyin: her veri sınırının bir kalite kararına ihtiyacı vardır: neyi kabul ettiğimiz, reddettiğimiz ya da karantinaya aldığımız ve istisnanın sahibinin kim olduğu.

Click to enlarge

Her veri sınırının bir kalite kararına ihtiyacı vardır.

Tarihsel Veri Farklıdır

RouteDesk, Steve Trucking’in sekiz yıllık geçmişini tutuyor ve kalitesi dağıtım merkezine göre değişiyor. Taşımadan önce sekiz yılın hepsini bugünün standardına göre temizlemeli miyiz? Muhtemelen otomatik olarak değil. Ne için: günlük operasyonlar, başvuru, talepler, raporlama, eğilim analizi? Hepsinin Salesforce’ta olması gerekiyor mu, yoksa bir kısmı başka bir yerde kalabilir mi? Taşıma bölümü derine iniyor. Yönetişim noktası şu: geçmiş otomatik olarak etkin veriyle aynı standarda ihtiyaç duymaz. Ondan karar verecekseniz kalite önemlidir. Başvuru için saklıyorsanız farklı bir standart yeterli olabilir. Geçmişi temizlemeye bir servet harcamadan önce amacı bilin.

Birinin Harekete Geçeceğini Ölçün

Yönetişim hiçbir zaman bitmez; bu yüzden kalitenin ne zaman düştüğünü görmeniz gerekir: artan yinelenen kayıt oranları, karantinada daha fazla kayıt, daha fazla entegrasyon reddi, yayılan yer tutucu değerler, daha fazla muafiyet talebi, artık birbirini tutmayan raporlar. Ama 150 metrik oluşturup 143’ünü görmezden gelmeyin. Steve Trucking için belki geçerli bir ortak referansı olmayan teslimatlar, kullanılabilir bir adresi olmayan teslimatlar, tekrarlanan sipariş referansları, reddedilen ortak mesajları, geçici durumda takılı kalan hesaplardır. Yeşil dairelerle dolu bir gösterge panosu verinin iyi olduğu anlamına gelmez. Birinin harekete geçmeye hazır olduğu şeyi ölçün.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Kötü veri giderek kötü eyleme dönüşüyor. Bir kişi aramadan önce bir telefon numarasının yanlış göründüğünü fark edebilir; bir ajan ise kendisine verilen değeri kullanır. Yinelenen müşteriler, bayat durumlar, sahte zorunlu değerler ve yanlış tanımlayıcılar doğrudan yanlış mesaja ya da yanlış güncellemeye dönüşür. Bu, önlemenin değerini artırır. Veri sorumluluğu ihtiyacını ortadan kaldırmaz.

Mimarın Burada Karar Verdikleri

• Hangi kalite başarısızlıklarının önleyici kontrolleri haklı çıkaracak kadar zarar verdiği.
• Yönetilen kayıtların serbestçe mi, yalnızca esas sistem tarafından mı, yoksa geçiciden yönetilene giden bir yol üzerinden mi oluşturulacağı.
• Hangi özniteliklerin sahibinin Salesforce olduğu, hangilerine yalnızca başvurduğu.
• Kontrollerden geçemeyen gelen veriye ne olacağı (kabul, ret ya da karantina) ve istisnanın sahibinin kim olduğu.
• Veri sorumlularının düşüşü görmesi için hangi kalite sinyallerinin ölçüleceği.

Her kötü kaydı asla önleyemezsiniz. İş kusursuz veri değil; önlenebilir kötü verinin pahalı veriye dönüşmesini engellemektir. Yinelenen kaydı iki yıllık geçmişi olmadan durdurun. On entegrasyon yanlış tanımlayıcıya bağımlı hale gelmeden tanımlayıcıyı koruyun. Satışın potansiyel müşteriyi oluşturmasına izin verin, ama o olana kadar onun yönetilen müşteri olduğunu varsaymayın. Ve kötü bir şey içeri sızdığında birinin onu görebildiğinden, sahiplenebildiğinden ve düzeltebildiğinden emin olun.

Daha Fazlası

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) ve Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.