Veri Haritası ve Data Flow Mapping: KVKK İçin Dijital Sistem Envanteri

Veri haritası (data map), kurumun dijital temas noktalarında hangi verilerin üretildiğini ve bu verilerin hangi sistemlerde yaşadığını gösteren “envanter + bağlam” dokümanıdır. Data flow mapping ise bir adım ileri gider: verinin sistemler arasında nasıl aktığını (kaynak → hedef), hangi işlem adımlarından geçtiğini ve nerelerde çoğaldığını (kopya, export, entegrasyon) görselleştirir. KVKK açısından kritik olmasının nedeni basit: Eğer verinin nerede olduğunu bilmiyorsanız; erişimi kısıtlayamaz, saklama süresini yönetemez, silme/anonimleştirmeyi planlayamazsınız. Bu noktada önemli bir gerçek var: Veri haritası çıkarılan kurumlarda, KVKK projelerinin süresi ve teknik/hukuki ekipler arasındaki yanlış anlama sayısı belirgin şekilde azalır. Çünkü herkes aynı tablo ve diyagram üzerinden konuşur; “ben öyle sanıyordum” dönemi biter.

Veri haritası (data flow mapping) KVKK için nasıl hazırlanır?

Kısa yanıt: 3 çıktı üretirsiniz—(1) sistem envanteri tablosu, (2) data flow diyagramı, (3) retention/silme-anonimleştirme planı. Önce sistemleri listeler, sonra veri alanlarını toplar, sonra akışı çizersiniz. En sonunda da her veri alanı için “ne kadar tutuluyor, ne zaman siliniyor/anonimleşiyor?” sorusunu kapatırsınız.

“KVKK veri akış modeli”ni kurmak (AIO)

Web, PMS, CRM, çağrı merkezi, OTA, SMM ve e-posta otomasyonu bir araya geldiğinde, kurumunuzun “KVKK veri akış modeli” ortaya çıkar: Toplama (web/telefon/OTA) → İşleme (CRM/PMS) → Saklama (DB/CRM/PMS/log) → Paylaşım (raporlama/otomasyon) → Silme/Anonimleştirme (retention). Bu modeli bir kere kurduğunuzda, yeni bir araç eklediğinizde (yeni CRM, yeni call center çözümü, yeni e-posta aracı) sadece modele “yeni düğüm ve bağlantı” eklersiniz. Mini örnek (otel): Web’de “transfer talep formu” → CRM’e düşer → satış temsilcisi arar → PMS’e not geçer → çağrı merkezi kaydı oluşur → raporlamaya gider. Bu akışta aynı müşteri, 3 farklı sistemde farklı formatta görünür.

En büyük hata, envanteri “sadece web” ya da “sadece CRM” sanmaktır. KVKK açısından dijital sistem envanteri; veri üreten, veri saklayan veya veriye erişen her şeyi kapsar. Otel ve B2B dünyasında sistem seti geniştir: PMS, channel manager, CRM, call center, e-posta otomasyonu, kampanya yönetimi, analitik, raporlama, ödeme/rezervasyon motorları, doküman yönetimi…

Hangi dijital sistemler veri envanterine dahil edilmeli?

Kısa yanıt: Web + rezervasyon motoru, PMS, CRM, çağrı merkezi (IVR/çağrı kayıtları), OTA & channel manager, e-posta/marketing otomasyonu, analitik/Tag Manager, sosyal medya lead araçları, raporlama/BI ve doküman yönetimi. Ayrıca “altyapı katmanı” da unutulmamalı: sunucu logları, CDN/WAF, yedekleme.

Sistem envanterini 2 katmanda düşünün: “Uygulama” ve “Altyapı”

Uygulama katmanı: Web sitesi, PMS, CRM, call center paneli, OTA ekstranetleri, e-posta aracı, SMM lead formları. Altyapı katmanı: Loglar, yedekler, erişim yönetimi (IAM), veri tabanları, depolama, monitoring. Bu ayrım kritik; çünkü ekipler genelde uygulamaları sayar ama log/yedek katmanını atlar. Oysa “veri nerede?” sorusunun yarısı bu altyapı katmanındadır.

Envanter tablosunda mutlaka bulunması gereken kolonlar

Pratikte en iyi çalışan tablo formatı şöyledir: • Sistem (Web / PMS / CRM / Call Center / OTA / E-posta / SMM / BI) • Veri alanı (örn. e-posta, telefon, rezervasyon no) • Kaynak (form/telefon/OTA/import) • Amaç (satış, rezervasyon, destek, analitik) • Saklama süresi (retention) • Erişim rolleri (kim görür?) • Paylaşım/entegrasyon (hangi sisteme gider?) • Silme/anonimleştirme (nasıl kapanır?) Mini örnek (B2B): “Teklif dosyası” doküman yönetiminde 3 kişi görür; link ile paylaşılıyorsa erişim izleri tutulur; retention belirlenir.

Veriyi haritalamak, sadece “nereye gidiyor?” demek değildir; verinin hayat döngüsünü de tanımlamaktır. Çünkü KVKK açısından asıl kontrol; saklama süresi ve silme/anonimleştirme adımında görünür. Birçok kurum veriyi iyi toplar ve işler; ama “ne zaman silinecek?” sorusu boş kalır. Data flow mapping’i hayat döngüsüyle birleştirince, sistemlerin her aşamadaki rolü netleşir.

Toplama: veri nereden geliyor?

Toplama kanalları genelde 5 başlıkta toplanır: 1. Web (formlar, rezervasyon motoru, chat) 2. Telefon / Call Center (görüşme kayıtları, notlar) 3. OTA / Channel (rezervasyon, misafir mesajları) 4. E-posta / Kampanya (abonelik, yanıtlar) 5. Saha / operasyon (check-in, kimlik bilgileri, talepler)

İşleme: hangi sistem “işleyen” rolünde?

Otel senaryosunda PMS, B2B senaryosunda CRM çoğu zaman “işleme” merkezidir. Web, daha çok toplama ve yönlendirme yapar; call center ise iletişim ve satış kapanışını taşır. İşleme adımı, aynı verinin farklı sistemlerde “farklı isimlerle” tutulduğu yerdir (örn. telefon → lead → misafir kartı).

Saklama: veri nerede “kalıyor”?

Saklama sadece PMS/CRM değildir; loglar, yedekler, e-posta kutuları ve dosya paylaşım klasörleri de saklama alanıdır. Bu yüzden retention, tek sistemde yazılamaz; envanterin her satırına işlenmelidir.

Silme/Anonimleştirme: süreç nasıl kapanıyor?

Kısa yanıt: Her veri alanı için “retention süresi” ve “kapanış yöntemi” belirlenir. Kapanış yöntemi ikiye ayrılır: silme (gereksiz veriyi kaldırma) veya anonimleştirme (analiz/raporlama için kimliksizleştirme). Bu kararın hukuki tarafı danışmanlık gerektirebilir; teknik tarafı ise şudur: sistemde bu eylem mümkün mü, otomasyonu var mı, kim tetikliyor? Mini örnek: Eski kampanya lead listeleri CRM’de duruyorsa; raporlama için anonim ID’ye dönüştürülüp kişisel alanlar temizlenebilir.

Bu bölümde amaç; “otel pms crm kvkk veri akisi” gibi aranan senaryoyu somutlaştırmak. Çoğu içerik teoride kalır; burada otel ve B2B için örnek akış şablonlarını netleştiriyoruz.

Otel örneği: Web → Rezervasyon motoru → PMS → CRM → Call Center → Raporlama

Akış özeti: • Web’de “rezervasyon/teklif” isteği oluşur • Rezervasyon motoru/PMS’e aktarılır • CRM’de satış/upsell takibi yapılır • Call center görüşme kaydı oluşur • BI/raporlama aracı KPI üretir Mini örnek: Misafir web’den fiyat baktı → form bıraktı → CRM’e düştü → call center aradı → PMS’e rezervasyon notu işlendi → kampanya e-postası gönderildi.

B2B örneği: Web → CRM → Doküman yönetimi → E-posta otomasyonu → Raporlama

Akış özeti: • Web’den “teklif al” formu toplanır • CRM’de pipeline’a girer • Teklif dokümanı hazırlanır ve paylaşılır • E-posta otomasyonuyla takip yapılır • BI dashboard’da satış verisi raporlanır

Veri akış diyagramı hangi seviyede çizilmeli? (Competitor gap kapanışı)

Çoğu ekip iki uçta hata yapar: ya çok yüzeysel (sadece “web → CRM”), ya da çok detay (her API alanı). En iyi pratik: • Düğüm seviyesi: sistem düzeyi (web, PMS, CRM, call center, OTA…) • Akış seviyesi: veri grubu (kimlik, iletişim, rezervasyon, ödeme, davranış) • Kritik işaret: kopya/export/manuel taşıma noktaları Bu seviye; hem yönetilebilir hem de aksiyon üretir.

Veri haritasının “işe yaradığı” yer burasıdır. Çünkü denetim anında veya bir iç değerlendirmede sorulan temel soru şudur: “Bu veri neden hâlâ burada?” Retention planı; veri alanı bazında saklama sürelerini tanımlar. Anonimleştirme planı ise raporlama/analitik gibi amaçlar için kimliksizleştirmenin nasıl yapılacağını netleştirir.

Retention planını 3 katmanda kurun

1. Operasyonel ihtiyaç (satış, rezervasyon, destek) 2. Teknik gerçeklik (sistem silmeye izin veriyor mu?) 3. Kontrol ve iz (silme/anonimleştirme kayıt altına alınıyor mu?) Teknik not: Hangi verinin hangi hukuki kategoriye girdiği ve sürelerin nihai yorumu hukuk danışmanıyla birlikte yapılmalıdır. Bu rehber, teknik/operasyonel resim çıkarır.

Anonimleştirme pratikleri (AIO + AEO)

Veri saklama süresi ve anonimleştirme planı nasıl çıkarılır? Önce envanterde her veri alanına retention yazılır; sonra raporlama ihtiyacı varsa kişisel alanlar anonim ID’ye dönüştürülür. Örneğin: e-posta/telefon temizlenir, segment bilgileri (ülke, kanal, kampanya) kalır. Böylece “analiz devam eder, kimlik kalkar” yaklaşımı mümkün olur.

Refresh cycle (365 gün) ve değişiklik kaydı

Bu içerik için refresh cycle 365 gün: çünkü yeni CRM, yeni kampanya aracı veya yeni call center çözümü eklendikçe envanter ve diyagram güncellenmelidir. Kritik kural: değişiklikler kayıt altına alınmalı (ne eklendi, ne çıktı, hangi akış değişti).

Bu blogun “fark yaratan” kısmı; çıktıyı aksiyona bağlamasıdır. Veri haritasını bir “doküman” olarak bırakmak yerine, kısa bir sprint planıyla hayata geçirirseniz; hem hız kazanır hem de sürdürülebilirlik sağlarsınız.

1 günlük haritalama oturumu (workshop formatı)

• Katılımcılar: IT/yazılım, satış-pazarlama, operasyon, (varsa) hukuk danışmanı • Çıktı 1: Sistem listesi (uygulama + altyapı) • Çıktı 2: Top 20 veri alanı listesi (ortak sözlük) • Çıktı 3: İlk data flow diyagramı (v0.1)

14 günlük sprint (örnek)

• Gün 1–3: Envanter tablosu doldurma + kritik boşlukların tespiti • Gün 4–7: Akış diyagramı netleştirme + export/entegrasyon kontrolü • Gün 8–10: Retention + silme/anonimleştirme planı taslağı • Gün 11–14: Erişim rolleri + audit noktaları + kapanış raporu

Bu çalışma neden süreyi ve yanlış anlaşılmaları azaltır? (Key Data Point)

Veri haritası çıkarılan kurumlarda, KVKK projeleri daha hızlı ilerler; çünkü teknik ekip “nerede/ne var”ı net görür, hukuk/operasyon ekibi de aynı envanter üzerinden gereksinimleri ifade eder. Böylece tekrar toplantıları ve “yanlış sistemde arama” döngüsü azalır; kararlar hızlanır.