MDM; kritik iş varlıkları için ortak veri modelini, kimlik eşleştirmeyi, tekilleştirmeyi, golden record kurallarını, veri sahipliğini, değişiklik onayını ve diğer sistemlere dağıtımı yönetir. CRM, ERP veya veri ambarı tek başına MDM değildir. Başarılı bir MDM programı teknoloji kadar iş kuralları, veri steward’lığı, kaynak otoritesi, kayıt yaşam döngüsü, kalite ölçümü ve istisna yönetimi gerektirir.
Ana veri, işlemlerin çevresinde tekrar kullanılan temel iş varlıklarını tanımlar
Sipariş, ödeme ve çağrı kaydı işlem verisidir. Müşteri, ürün, tedarikçi, hesap, çalışan, lokasyon ve organizasyon ise çok sayıda işlem ve sistem tarafından tekrar kullanılan ana veri alanlarıdır. Ülke kodu, para birimi veya ürün sınıfı gibi kontrollü listeler referans veridir. MDM, bu varlıkların kimliğini, temel özelliklerini, ilişkilerini ve yaşam döngüsünü kurumsal olarak yönetir.
| Veri türü | Örnek | Yönetim ihtiyacı |
|---|---|---|
| Ana veri | Müşteri, ürün, tedarikçi, lokasyon | Kimlik, tekilleştirme, sahiplik ve yaşam döngüsü |
| İşlem verisi | Sipariş, ödeme, sevkiyat, görüşme | Bütünlük, zaman ve süreç izleme |
| Referans veri | Ülke, sektör, para birimi, statü | Kontrollü liste ve sürüm |
| Metadata | Tanım, veri tipi, sahip, lineage | Keşif ve yönetişim bağlamı |
ERP, CRM, veri ambarı ve MDM farklı görevler üstlenir
ERP finansal ve operasyonel süreçleri, CRM müşteri etkileşimini, veri ambarı analitik tüketimi yönetebilir. Bu sistemlerden biri belirli veri alanı için kaynak otoritesi olabilir; fakat kurum genelinde aynı gerçek dünya varlığını eşleştirme, çakışan kayıtları çözme ve değişikliği diğer sistemlere dağıtma ihtiyacı MDM disiplinidir.
Etkileşim sistemi
Satış ve hizmet süreçlerinde müşteri kaydını kullanır.
Operasyon sistemi
Faturalama, tedarik ve finansal işlemleri yürütür.
Kimlik ve otorite
Kayıtları eşleştirir, kuralları uygular ve güvenilir ana veriyi dağıtır.
Analitik tüketim
Tarihsel veri, rapor, model ve AI kullanımını destekler.
Program tek alanla başlamalı, kurumsal modele kontrollü genişlemelidir
Müşteri MDM; kimlik, iletişim, hane veya kurum ilişkileri ve izinleri yönetir. Ürün MDM; SKU, özellik, hiyerarşi, paket, kanal ve yaşam döngüsünü düzenler. Tedarikçi MDM; tüzel kişi, banka, vergi, risk ve ilişki kayıtlarını birleştirir. Lokasyon ve organizasyon MDM ise tesis, şube, maliyet merkezi ve hiyerarşi değişikliklerini yönetir.
- İş etkisi yüksek ve veri çatışması görünür bir alan seçin.
- Varlığın tekil kimlik ve ilişki modelini tanımlayın.
- Hangi özelliğin hangi kaynaktan otorite aldığını belirleyin.
- Kişisel veri ve hassas nitelikleri ayrı sınıflandırın.
- Birleşme, bölünme, kapanma ve yeniden açılma olaylarını modelleyin.
- Altın kayıt ile kaynak kayıt arasındaki izlenebilirliği koruyun.
Golden record otomatik birleştirme değil kanıtlı karar sürecidir
Kimlik çözümleme; kesin anahtarlar, normalize edilmiş alanlar, benzerlik kuralları, ilişki sinyalleri ve gerektiğinde insan incelemesiyle yapılır. E-posta veya telefon eşleşmesi tek başına aynı kişi sonucunu her zaman desteklemez. Kurumsal müşterilerde ticaret unvanı, vergi kimliği, grup ilişkisi ve şube yapısı ayrıca ele alınmalıdır.
| Adım | Karar | Kanıt |
|---|---|---|
| Standartlaştırma | Ad, adres, telefon ve kod nasıl normalize edilir? | Dönüşüm ve kaynak değeri |
| Matching | Kayıtlar aynı varlığı mı temsil ediyor? | Kural, skor ve eşleşen alan |
| Merging | Hangi kayıtlar tek kimlik altında bağlanır? | Birleştirme kararı ve geri alma izi |
| Survivorship | Hangi alan hangi kaynaktan kazanır? | Kaynak önceliği, güncellik ve kalite |
| Stewardship | Belirsiz kayıtları kim çözer? | İş kuyruğu, gerekçe ve SLA |
Golden record kaynak kayıtlarını silmemelidir. Her alanın kaynağı, zamanı ve kuralı izlenebilir kalmalı; yanlış birleşme güvenli biçimde geri alınabilmelidir.
MDM mimarisi iş süreci ve değişiklik otoritesine göre seçilmelidir
| Yaklaşım | Özellik | Uygun durum |
|---|---|---|
| Registry | Kayıtları bağlar, kaynak sistemde tutar | Hızlı 360 görünüm ve düşük müdahale |
| Consolidation | Analitik golden view üretir | Raporlama ve müşteri analitiği |
| Coexistence | MDM ve kaynaklar çift yönlü eşitlenir | Kademeli operasyonel uyum |
| Centralized | Ana veri merkezi olarak yaratılır ve dağıtılır | Güçlü merkezi süreç ve yüksek kontrol |
Mimari seçimi yalnız ürün özelliği değildir. Kaydı kimin oluşturduğu, iş biriminin hız ihtiyacı, kaynak sistemlerin değiştirilebilirliği, gerçek zaman gereksinimi ve hata maliyeti belirleyicidir.
MDM uygulaması veri temizleme projesi değil sürekli yaşam döngüsüdür
- İş problemini ve değer göstergesini tanımlayın.
- Varlık, özellik, ilişki ve hiyerarşi modelini kurun.
- Kaynak sistem ve alan bazında otorite matrisi hazırlayın.
- Kalite, matching, survivorship ve istisna kurallarını yazın.
- Veri steward iş akışını ve SLA’larını belirleyin.
- Pilot veri kümesinde yanlış birleşme ve kaçırma oranını ölçün.
- Dağıtım API, olay veya batch akışlarını tasarlayın.
- Kaynak ve tüketici sistemlerle mutabakat kurun.
- Yeni kaynak, kural ve alan değişikliklerini yönetin.
Senaryo: Aynı kurumsal müşteri beş farklı kayıtta bulunuyor
CRM’de ticaret unvanı, faturalama sisteminde vergi numarası, destek sisteminde alan adı, etkinlik sisteminde kısa marka adı ve tahsilat sisteminde grup şirketi kaydı vardır. MDM önce tüzel kişi ile marka ve şube ilişkisini ayırır; vergi kimliğini güçlü anahtar, unvan ve adresi destekleyici sinyal olarak kullanır. Belirsiz grup ilişkisi steward onayına gider. Golden record satış görünümü sağlarken faturadaki hukuki kayıt kaynak sisteminde korunur.
Yanlış MDM uygulaması hatayı kurumsal ölçekte dağıtabilir
- Yalnız yazılım alıp sahiplik ve steward sürecini kurmamak
- Yanlış eşleşmeleri otomatik birleştirerek müşteri haklarını karıştırmak
- Kaynak otoritesini alan bazında tanımlamamak
- Golden record’u değişmez ve mutlak gerçek sanmak
- Grup, hane, ürün ailesi ve lokasyon ilişkilerini düz kayda indirgemek
- Kişisel veri ve erişim amaçlarını göz ardı etmek
- Değişikliği kaynak sistemlere kontrolsüz geri yazmak
- Çıkış ve veri taşınabilirliği planı olmadan tedarikçiye bağımlı kalmak
MDM iş birimi sahipliğinde, veri ve teknoloji ortaklığıyla yönetilmelidir
Domain owner ana veri tanımı ve politika kararından; data steward kayıt ve istisna çözümünden; veri ekibi entegrasyon, kalite ve lineage’dan; uygulama sahipleri kaynak/tüketici değişikliklerinden; güvenlik ve gizlilik ekipleri erişim ile kullanım amaçlarından sorumludur.
| KPI | Sağlıklı ölçüm | Tek başına yetersiz ölçüm |
|---|---|---|
| Tekilleştirme | Doğrulanmış duplicate azalması | Birleştirilen kayıt sayısı |
| Kalite | Kritik alan hata ve tamlık oranı | Dolu kolon yüzdesi |
| Operasyon | Steward çözüm süresi ve tekrar açılma | Kapanan görev sayısı |
| Yayılım | Tüketici sistemlerde mutabakat | Bağlı sistem sayısı |
| İş değeri | İade, yanlış fatura, onboarding veya çapraz satış etkisi | Golden record hacmi |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01IBM — What Is Master Data Management?
MDM’nin kritik veri alanlarını birleştirme, temizleme, eşleştirme ve yönetişim yaklaşımını açıklar.
- 02IBM Docs — InfoSphere MDM Product Overview
Ana veri varlıklarının yaratma, doğrulama, bakım ve silme yaşam döngüsünü açıklar.
- 03SAP Help — Master Data Governance
Ana verinin merkezi yaratılması, değiştirilmesi ve dağıtılması için yönetişim yaklaşımını açıklar.
- 04Oracle Türkiye — Ana Veri Yönetimi Nedir?
Müşteri, ürün, tedarikçi ve diğer ana veri alanlarında ortak kayıt yaklaşımını açıklar.
- 05Microsoft Learn — Dataverse as a Master Data System
Ana veri kaynağı, iş kullanıcılarının sahipliği ve diğer sistemlere dağıtım için referans mimari sunar.