Sayın Ozan Kaan KARAMIK, Linkedin’de “Çok acil, olmazsa olmaz denilip iş listesinin en önüne konan ama geliştirildikten sonra kimsenin kullanmadığı özellikler…” konulu bir mesaj iletmiş. Lütfen önce mesajın tamamını ve benim birkaç satırlık yorumumu okuyunuz.

Çok önemli bir konu olduğu için, mesajın altına uzun yorum yazmak yerine kendisinden blog yazısıyla yanıtlama izni istedim.

Bir blog yazısına sığdırmak için, aslında veri ambarı nasıl hazırlanır konulu kitap olmaması amacıyla bu yazıyı kısa tutmaya çalıştım. Çok önemli ve kapsamlı bir konu olduğundan, daha fazla ayrıntı öğrenmek istiyorsanız yazıda geçen her referans bağlantıya tıklayıp okumanızı öneririm. (Sonra yine bu yazıya geri dönmeyi unutmayın. Bağlantılar labirentinde kaybolmayın. 😊 )

Teşhis

Ozan Kaan KARAMIK’ı desteklememim nedeni şudur: “Çok acil”, “olmazsa olmaz” diye iş listesinin başına koyulan ama neredeyse hiç kullanılmayan özellikler, CRM ve BI projelerinin (IT değil) iş birimi tarafını yöneten kişi olduğumda benim de çok rahatsız olduğum konulardan biriydi.

Sorunun nedenleri şunlardır:

1. İş birimlerinin çoğunluğu IT’den bekler ama verinin bilgiye dönüştürülmesinin sorumluluğu IT’de değil, bilgiyi talep eden iş birimindedir. (Plaza ingilişcesinde göre “business unit”)
2. Verinin sahibi farklı birim olabilir ama bilginin sahibi talep eden iş birimidir. (Ozan Kaan beyin dediği gibi “Verinin sahibi ile bilginin sahibinin ayrışması meselesi az konuşulan ama sahada çok yaşanan bir durumdur.”
3. Bilgiyi talep edenin, o bilgiyi nerede ve nasıl kullanacağına dair bir taahhüdü olmalıdır.

😉

Çözüm

Yukarıdaki paragraftaki konuları sırayla ele alalım.

İş birimi, hangi bilgiye ihtiyacı varsa önce o bilginin tanımını yapar. Aşağıda vereceğim örnek için aktif, inaktif ve kayıp müşteri tanımlarının yapılmış olması gerekiyor. (İlgili yazılar: [1] , [2] )

Bu tanımlar, en azından verilerin bilgiye dönüşmüş halidir. İş birimi bilginin hangi verilerin bir araya getirilerek oluşturulması gerektiğini de bilmek zorundadır. Bunu IT’den talep ederken, gerekli ayrıntıları belirtir.

Aşağıda yangın sigortası için hazırlanmış bir örnek var.

Dikkat etmişsinizdir. Güncelleme sıklığı da iş biriminin kararıdır. Tanımlar oluşturulurken elbette IT ile birlikte çalışılır ama son karar iş birimine ait olmalıdır.

😉

Bazı ürünler, karmaşık özelliklere sahip olabilir. Örneğin BES ödemeleri aylık olmak zorunda değildi. Farklı zaman dilimlerinde ödeme yapılıyordu. Bu durumda tanımlar uzayabilir.

Evet Ama Yetmez

Yukarıdaki (ayrıntılı görünen) tanımların en sağ tarafına (veya bu tanımların ayrılmaz parçası olan ayrı bir dosyada) bu bilginin ne amaçla istendiği de yazılmalıdır.

Bir dönemlerin ürün özelliklerini Türkiye’ye tanıtmak için hazırlanan reklamında “Ne yapacaksın bununla?” sorusu vardı. Bu soru, müşteri odaklı veri ambarı (MOVA) oluşturmanın en temel sorusudur. Unutmayın, veri ambarına çöp doldurursanız çöp alırsınız.

İş birimi “Bu bilgiyi

• Müşteri ekranında kullanacağız,
• Ödeme gecikmesi olduğunda hatırlatma mesajı göndereceğiz,
• Aktif olmaktan çıkarsa müşteri geri kazanım projesi yapacağız [a] , [b],
• Sigorta süresi bitmeden önce uzatma mesajı göndereceğiz,
• Sigortalanan ürün doğrultusunda müşterinin gelir / varlık potansiyelini hesaplayacağız,
• Çapraz satış teklifinde bulunacağız,
• Raporlarımızda kaç yangın sigortası müşterimiz var kısmında göreceğiz,
• vb… (muhtemelen siz daha fazlasını eklersiniz)

amaçları doğrultusunda kullanacağız” diye taahhütte bulunmalıdır.

Böylece hem kendilerine bir yapılacak işler listesi, hem de diğer ilgili taraflara önceliklendirme gerekçesi sunmuş olur.

Bilginin sahibi olması gereken birim/bölüm, bilginin ne zaman ve ne kadar gerekli olduğunu analiz edecek birikime sahip olmak zorundadır. Bu hazırlık sayesinde sadece bir defa gerekli olan bilgiyi hep gerekli sanmaz.

Kurumun IT Yürütme Komitesi’nde kullanımların tartışılması ve “Madem kullanmayacaktın, öyleyse neden bu kadar ısrarla istedin. Bunca emek harcanmasına neden oldun” diye hesap sorulması gerekir. Pahalı bir kaynak olan IT emeğinin etkin kullanılması sağlanır.

Projedeki Yeri

Yukarıda anlattıklarım, müşteri odaklı veri ambarını (MOVA) oluşturma sürecinin resimdeki ARINDIRMA ve ANLAMLANDIRMA aşamasının küçük bir parçasıdır.

ARINDIRMA ve ANLAMLANDIRMA çok önemlidir. Bir şehrin suyunu kaynağında arındırırsanız, herkes evine su arıtma cihazı koymak zorunda kalmaz. Benzer şekilde, veriyi kaynağında (işletim sistemlerinden MOVA’ya aktarırken) arındırıp anlamlandırırsanız, her departman / silo kendi excel tablolarını üretmek zorunda kalmaz, herkesin aynı dili konuşacağı ve aynı doğruyu bulacağı raporlar oluşur.

Yukarıdaki şekil, MOVA eğitiminde kullandığım 4 sayfanın birleştirilmiş hâlidir.

MOVA hakkında daha geniş bilgi arıyorsanız:

[A] – İşlevsel veri ambarları ile MOVA farkı
[B] – MOVA oluşturmaya nasıl başlanıldığı
[C] – MOVA’nın neden önemli olduğu
[D] – 2013’de MOVA olmadan Sosyal CRM olmayacağına dair alıntıyı
[E] – 2016’da MOVA olmadan Dijital Dönüşüm olmayacağına dair alıntıyı

okuyabilirsiniz.

Dahası Var

Şurada Sn. Ömer Mert, Gartner’ın Market Guide for Agentic Analytics raporu nu özetliyor ve “Dönüşümde kalıcı başarı yalnızca güçlü modellerle mümkün değil.

• Güvenilir veri mimarisi,
• tutarlı bir semantik yapı ve
• sağlam yönetişim

bu dönüşümün temelini oluşturuyor” diyor.

====================

Burada Sn. Sibel Akoğlu hazırladığı infografiği açıklarken “Bütün bu mimari yaklaşımın, çoğu kaynakta CDP olmadan sağlıklı çalışmadığını okuyacaksınız. Silolaşmış veri malesef başımızın belası. Agent’ı doğru zamanda doğru müşteriye yönlendirmek istiyorsanız, bu kurgu için iyi bir CDP yapısı şart.” diyor. (CDP = MOVA)

Reklamlar

CRM eğitimlerime katılanlar, çeşitli sektör gruplarına ayrılırlar. Seçilen sektörde CRM projesi yapıyor gibi ilerleriz. Ödevlerden biri o sektörde veri sözlüğü hazırlamaktır. Elbette bir derste tüm bir kurumsal MOVA sözlüğü hazırlanamaz ama temel kavramlar oluşturulur.

Yıllardan beri CRM eğitimi verdiğim için, çok sayıda sektörün veri sözlüğünün ilk aşamalarına ait bilgiler bulunuyor.

====================

Ayrıca, CRM ve/veya BI projesi yapan bazı kurumlarda

• IT ekiplerine “İş birimleriyle çalışma”
• İş birimlerine “IT ile birlikte çalışma”

eğitimleri vermiştim. Bu eğitimlere ihtiyacı olan çok sayıda şirket olduğunu düşünüyorum. Büyük bir veri veya dönüşüm projesi yapacaksanız, aklınızda olsun.

😉

Linkedin’de yayınlandı

Bu yazı, kendi başına önemli bir çalışmayı anlatıyor. Bununla birlikte, müşteri kazanımı konulu önceki iki yazıyla birlikte ele alınırsa,  geniş bir çerçeve sunduğunu da söylemeliyim.

BrandMap dergisinin 60’ıncı (2025 – Temmuz-Ağustos-Eylül) sayısında yayımlanan Müşteri Aktivasyonunun Ölçülmesi  başlıklı ilk yazıda (Blog’da okumak isterseniz burada) müşteri sayısının artmasının aldatıcı olabileceğinden bahsetmiştim. Özellikle büyüyen pazarlarda, yeni müşteri kazanırken eski müşterilerin ne kadarının kaybedildiğini de görmek gerektiğini ve segment ve kârlılık kırılımlarına inilmeden müşteri kaybının yanlış değerlendirilebileceğini vurgulamıştım. Bu yazı, sadece dilek-ve-temenniler yazısı değil, kurumun kendi gerçeklerini nasıl görebileceğini gösteren bir yöntem de içermektedir.

Müşteri Terk Etmesinin Tasarımı yazısında, müşterinin terk etme deneyimini de yeni müşteri kazanımı gibi (hatta daha fazla) titizlikle kurgulamak gerektiğine değinmiştim. İstemeden kaybettiğimiz  müşteriyi gelecekte geri kazanmak istiyorsak önce ayrılış deneyiminin nasıl yaşandığını anlamamız ve bunu tasarlamamız gerektiğini yazmıştım.

Bu üçüncü yazıda, geri kazanım çalışmasının ilk aşamalarını ve bazı önemli ayrıntılarını konuşacağız.

Müşteri Kimdir?

Sürekli olarak “eski müşteriyi geri kazanmaktan” bahsediyoruz. Öyleyse, müşteriyi ve eski müşteriyi, hatta bir de kayıp müşteriyi tanımlamamız gerekir. Zaten CRM eğitimine, müşterinin tanımıyla başlıyoruz.

Bu yazıda müşteri derken iletişim ajanslarının “müşteriniz kimdir” sorusunun yanıtı olarak kampanyanızdaki hedef kitleyi değil, geçmişte en az bir kez işlem veya alışveriş yapmış, en azından sözleşme veya kullanım ilişkisi kurmuş kişi veya kurumu kastediyorum.

Müşterinin tanımı konusunda (yine ilk olarak BrandMap dergisinde yayımlanan) Farklı Müşteri Tanımları   yazısı bize gerekli bilgiyi verecektir.

 

Kimi Arayacağız?

“Müşteri geri kazanımı çalışması yapacağız. Eskiden aktif olan müşterilerimizin verimli olanlarından bugünlerde pek göremediklerimize ulaşmak istiyoruz” dersiniz. Bu çalışamaya başlamak için, kimleri arayacağınıza karar vermeniz gerekir.

“Eskiden verimli olan” ve “bugünlerde bizimle etkileşimi olmayan” tanımını, açık ve anlaşılır şekilde yapmamışsanız, kimleri arayacağınızı bilemezsiniz.

• Verimli dediğinizde neyi kastediyorsunuz? Kaç TL verim olmalı? Ürün kârlılık analizini yaptınız mı?
• “Eskiden” dediğinizde… son işleminden bu yana 3 ay mı, 6 ay mı, yoksa 2 sene geçmiş olanı mı arayacaksınız?

Bu zaman ve değer ölçüsü sektöre göre değişmekle birlikte, şunu iyi bilmekte yarar var. “Aktif, inaktif ve kayıp  müşterinin tanımını, bir yazılım cümlesi ile veri ambarından alacak biçimde yapmamışsanız, müşteri geri kazanım projesi de yapamazsınız”.

Önemli Not: Aktif, inaktif ve kayıp tanımlarını yapabilmek için hem işi bilmek, hem de müşterinin deneyimini anlamak gerekir. Aklınıza CRISP-DM kuralları (Cross-Industry Standart Process for Data Mining) gelmişse haklısınız.

Örnek – Banka

Bunu örnekleyelim. İlk örnek bankacılıktan gelsin. Yıllardır su, elektrik, doğal gaz, internet, telefon, vergi ödemelerini hesabına bağladığı otomatik talimatla yaparken, bir anda hepsini iptal etmişse ve yeni bir ödeme tanımlamamışsa… muhtemelen müşteriyi kaybetmişsinizdir.

Not: Taşınma sırasında da müşteriler otomatik ödemeleri kaldırırlar. Çok kısa süre içinde yenilerini tanımlarlar.

Müşterinin otomatik ödemeleri kaldırması, banka için bir alarm olmalıdır. Hemen müşteriye ulaşmak ve sorunu anlamaya çalışmak amaçlanmalıdır. Taşınma söz konusu olsa bile “sizin için yapabileceğimiz bir şey var mı?” sorusu müşteriye “zor zamanda yanımda” duygusu yaşatabilir.

Bu durumda, “tüm otomatik ödemeleri iptal edildiğinde bir uyarı oluşturmak” için yazılıma talimat verirsiniz.

Önemli Not: Bankalardaki otomatik ödemelerin kaldırılması gibi erken uyarı noktaları birçok sektörde vardır.

Örnek – Kahve Zinciri

Diğer bir örneği, kahve mağazaları zincirinden vermek istiyorum.

Oluşumunda veri ve ödeme sistemi danışmanı olarak çalıştığım uygulamayı, kötü hizmetten ötürü 4 sene önce kullanmamaya karar verdim. (Kötü hizmet cümlesini özellikle vurguluyorum.) Önce hesapta birkaç lira kalana kadar kullandım. Son işlem öncesinde kalan tutar çok düşüktü. Bu nedenle o zamana kadar hiç satın almadığım en ucuz ürünü aldım. Peşinde koşmaya değmeyecek 1,75 TL kaldı.

Hesabımda kullanmadığım 8 yıldız bakiyesi kaldığı için ve/veya uygulamayı telefonumdan silmediğim için beni hâlâ aktif müşteri sanıyorsa, çok yanılır. İşte size erken uyarı sistemi. En son alışverişime baksa, aradan geçen zamanı ve normal alışveriş sıklığımı bilse terk etmeye karar verdiğimi anlayabilirdi.

Not: CRM eğitiminde bir katılımcı “Neden bu tanımlar üzerinde bu kadar çok duruyorsunuz? Çok mu önemli?” demişti. Yanıtı burada.

 

Kimleri Aramayacağız?

Müşteri kaybının kötü olduğu sıkça söylenir. Genelde doğrudur. Ne var ki, bazı müşterileri geri kazanmak istemezsiniz. Hatta “keşke kendileri gitseler” diye gözlerinin içine bakarsınız.

20/80’i herkes bilir  yazısındaki şekle bu gözle baktığımızda, yeşil çerçevede yer alan müşterileri elde tutmaya çalışmanın verimli olmadığını görürüz. Bunların rakibinize gitmesinde hiçbir sakınca yoktur. Önemli olan, müşterinin potansiyelini (yani yaşam boyu değerini) iyi ölçmektir. Geçmişe değil geleceğe yönelik hesaplamalarda bazı varsayım yanlışları olması kaçınılmaz. Yeter ki, vahim hatalar olmasın.

Not: Yeni müşteri kazanımı ve eskiyi elde tutma maliyeti karşılaştırmasını yaptığımız tartışmaya yorum yazan sayın Senih Özkiper “Bazı şirketlerin belli müşterileri rakibe gitmesi için teşvik ettiği/yönlendirdiği ya da buna bilerek göz yumduğu hikayeleri anlatılırdı. Doğru mudur bilmiyorum. Uzmanından duymak gerek 🙂 ” diye sormuştu. Doğrudur. 😉

 

Sakın Ha!

Çok olumsuz ayrıldığınız, sizi sosyal mecralarda yerden yere vuran, şikayet sitelerinde söylemediğini bırakmayan müşterilerinizi bu çalışma sırasında aramayın. Arama listesini oluşturmadan önce müşteri odaklı veri ambarınızı düzgün hazırlamışsanız, zaten bu hatayı yapmazsınız.

 

Devamı Var

Bu yazı, müşteri geri kazanımı sürecini anlatan üçüncü yazıydı. “Neden bizi terk ettiniz?” aramalarını anlatacağımız yazı ile devam edecek.

😉

Eş zamanlı olarak Linkedin’de yayınlandı.

.

Veriye dayalı pazarlama giderek daha fazla kurum tarafından önemsendi. Bazı kurumlar, verileri etkin kullanarak rakiplerinden sıyrıldılar. Daha az maliyetle, daha verimli işler yapmaya başladılar. Böyle olunca, (bir dönemim altına hücum akımı gibi) veriye hücum başladı.

Veri hevesi, sadece kurumlarda değil bireylerde de etkin oldu. Hayatında veriye dayalı hiçbir iş yapmamış kişiler, sadece okuyarak veri yönetimi uzmanı oldular. Çeşitli vesilelerle bloglarda [a] ve [b] bunlardan bahsettik.

Bugünkü konumuz, bireyler değil kurumlarla ilgili. Veri sayesinde öne çıkan şirketler ve onlara özenen kurumlar sayesinde bazı yeni rahatsızlıklar / saplantılar türedi.

• Yabancı dillerde kitap ile ilgili iki ayrı saplantıdan bahsedilir: Kitapseverlik (bibliyofili) ve kitap biriktirme tutkusu (bibliyomani).

Kaynakçada şöyle yazıyor. Kitapseverlerin büyük, özel kitap koleksiyonları olabilir. Eski baskılara, imzalı kopyalara veya resimli versiyonlara çok değer verebilirler. Bibliyomani ise, kişilerarası ilişkileri veya sağlığı etkileyebilecek kitap toplamaya yönelik kompulsif bir takıntıdır. Konu veya içerik fark etmeksizin kitap toplarlar.

Benzer saplantılar, veri tutkunlarında da vardır. Kendimi veri psikoloğu ilan etmeyeyim ama bu konularda görüştüğüm çok sayıda kişi ve/veya kurumda fark ettiğim saplantıları da yazmak istedim.

Veri Biriktirme Saplantısı

Bu saplantılardan en çok rastlanılanı, ne işe yaradığını bilmesen de müşteri hakkında bütün verileri toplamak. Sanki, sosyal mecralar ile daha belirgin olan FOMO (Fear of missing out – Bir şeyleri kaçırma korkusu)’nun bir türevi gibi olduğunu düşünüyorum.

😉

Bir anı:

Yıllar önce, danışmanlık yaptığım bir bankada MOVA (müşteri odaklı veri ambarı) oluşturuyorduk. Bireysel Bankacılık Direktörü ile hangi verileri MOVA’ya kaydedeceğimizi tartışırken “ayakkabı numarasını bile kaydetmek isterim” demişti.

– Müşterinizin ayakkabı numarasını bildiğinizde size daha fazla verim sağlayacak bir senaryonuz mu var?” diye sordum.

– Bir ayakkabı markasıyla birlikte promosyon yapabiliriz”.

– Müşteriye yapacağınız kıyak, ayakkabı numarasıyla bağlantılı mı olacak. 43 numara giyenler, 37 numara giyenlerden daha fazla mı kazanacak?” diye sorunca yanıt alamadım.

Veri ambarı oluştururken, “şu veriyi de tutalım” diyen ürün yöneticilerine “o veri ile ne yapacağımızı, nasıl verim artıracağımızı ve/veya müşteriyi nasıl daha iyi tanıyacağımızı ve/veya sadakati nasıl artıracağımızı ve/veya hangi kampanyada kullanacağımızı anlatan bir senaryonuz yoksa, veriyi tutmamızın bir anlamı olmaz” demiştim.

Veri ambarı projesinin Ticari Bankacılık tarafında olan arkadaşımız “15 yıllık bankacıyım. Senin yüzünden senaryo kelimesini de bankacılık terimi olarak kullanmaya başladım” demişti.

Bu senaryolar çok önemlidir. O veriyi alınca ne yapacağınıza dair bir taahhüt gibidir. Müşteri odaklı veri ambarının (MOVA) çöplük olmasını engellersiniz. Sakladığınız her verinin kullanılabilir olmasını sağlarsınız.

“Müşterinin tüm verilerini toplamak önemli midir” diye sorduğumuzda, birçok sektörde ELBETTE diye yanıtlanır.

Ankastre mutfak üretimi yapan bir şirket olduğunuzu varsayalım. Müşteri geldi, anlaştınız. İşinizi yapıp bitirdikten sonra, yeniden size gelmesi en az 7-8 sene sonra olabilir. Onun dışında sadece tamir ve bakım için gelecektir.

Bu durumda en gerekli olan veriler müşteri bilgileri değil, sizin ankastre mutfak tasarlarken ve montajı yaparken, elektrik ve tesisat bağlantılarını nasıl yaptığınızla ilgili verilerdir. Yani sizin imalat ve montaj verilerinizi tutmanız, müşteri yeniden size gelene kadar eskiyecek verilerden çok daha önemlidir.

===============================================

Verileri anlamlandırmadan ve hangi amaçla kullanacağını saptamadan veri toplamaya çalışanları, “bir gün lazım olur” diye her şeyi toplayan bir türlü atmaya kıyamadığı için evi çöplüğe çevirenlere benzetebiliriz. Zaten veri ambarları için “GIGO” (garbage in, garbage out = çöp koyarsan çöp alırsın) sözünün çıkma nedeni de budur.

Bu veri toplama rahatsızlığının tedavisi, gerekçeli veri sözlüğü (veya veri kataloğu da deniyor) oluşturmaktır. Veri sözlüğü yazılırken o veri ile neler yapılacağını yazılmalıdır. Ankastre mutfak gibi durumlarda veri sözlüğüne “verinin son kullanma tarihi” diye bir kolon eklemeyi unutmamalısınız.

Zaten her işlem verisi işletim sistemlerinizde vardır. Hepsini MOVA’ya aktarmak zorunda değilsiniz. İşin ustalık kısmı da buradadır.

• • Meraklısına, MOVA (müşteri odaklı veri ambarı) esasları için [1] , [2] , [3] , [4] , [5] .

 

Veri Sarhoşluğu

Verilerle yakından ilgilenmeye başladıktan kısa bir süre sonra, ne kadar çok şeyi öngörebileceğinizi fark edersiniz.

CRM’e başlangıç öykümde bahsetmiştim. Nişantaşı’nda bir mağazayı hava parası vererek devir almadan önce “orada ne satılırsa daha çok para kazanılır” bilgisinin, kredi kartları verilerinden elde edilebileceğini anlamıştım. Bu duygu, ilginç bir saplantıya neden olabiliyor.

Okuduklarım ve/veya bizzat deneyimlediklerim sayesinde, zamanla verinin ne kadar çok konuda önceden uyarı sağladığını da gördüm. Müşterinin yaşam tarzındaki ve/veya yaşam evresindeki değişikliğin en hızlı nasıl anlaşılabileceği konusunda modeller geliştirmeye de çalıştım.

Bu duygu insanı esir alabilir. Verilere ulaşma beceriniz varsa dedektiflik yapabilirsiniz.

😉

Bir örnek:

Kredi kartları bölümüne yeni atanan Genel Müdür Yardımcısının, birkaç gün önce tüm gününü Genel Müdür’ün eşiyle birlikte geçirdiğini, aynı anda aynı kuaförde olduklarını, aynı mağazalardan aynı zamanda alışveriş yaptıklarını izleyebilirsiniz. Daha sonra size “tanıdık olduğum için değil, liyakat…” gibi cümleler söylediğinde anlayışlı bir gülümseme için kendinizi hazırlayabilirsiniz.

😛

Diğer bir örnek:

Hazine bonosunun sık kullanılan bir bankacılık aracı olduğu dönemde, MOVA oluşturuyorduk. Gerekçeli senaryolarımızı oluştururken şu kararı verdik: Müşterimizin en yakın iki itfa (paraya dönüştürme) tarihini de tutalım, kendisine bir iki gün önce bildirim yapacağız. Bir de en ileri tarihli olanı tutalım, en azından o tarihe kadar hâlâ müşterimiz. (Bu nedenle sadece 2-3 tarihi MOVA’da tutacağız. Diğerleri zaten işletim sistemlerinde duruyor. Zamanı gelince aktarırız.)

Yatırım ve tasarruf ürünlerine bakan ürün yöneticisi arkadaşımız ilginç bir istekle geldi. “Müşterilerin itfa tarihlerinin seçim tarihine yakınlığına da bakalım”  Nedenini sorduğumda “Yaklaşan seçimle ilgili kaygılarını, kısmen de olsa anlayabiliriz. Gelecekten umutluysa, yatırımın paraya dönüştürülmesi daha ileri tarihlere yayılacaktır; umutlu değilse seçimden hemen önce veya sonra nakite dönüşmeye çalışacaktır”

Önermenin tahmin kısmı doğru olabilir, müşterilerimizin seçimlerle ilgili endişelerini kısmen tahmin edebiliriz. Ama biz bir bankayız, politik araştırmalar şirketi değiliz ve bu izlenimi müşteri odaklı bir projede kullanamayız. Ürün Yöneticisine “Önermeyi doğru kabul ediyorum. Bunu banka için verim üreten bir senaryo haline getirirsen, tüm itfa tarihlerini MOVA’ya almayı kabul edeceğim. Aksi koşulda ilk belirlediğimiz üç tarih kalacak” demiştim. Banka için verim sağlayacak bir senaryo üretilemedi.

Veriler gerçekten size birçok gizli kök nedeni söyleyebilir. Bunu öğrenince insan daha çok derine inmeye çalışır. kendi varsayımlarınızı yine veriler sayesinde test edip, doğruluğunu ölçebilirsiniz. Sürekli varsayım – test – varsayım – test diye ilerleyerek birçok model geliştirebilirsiniz.

Bunlar doğru ama unutmayın ki mükemmel iyinin düşmanıdır. MOVA oluşturuyorsanız, verime dayalı senaryolar ve veri sözlüğü oluşturmanız bu nedenle önemlidir. Amacınız dedektiflik yapmak değil kurumun işine yarayacak verileri, en hızlı biçimde bilgiye dönüştürmektir.

 

Komşunun Verisi Saplantısı

“Komşunun tavuğu komşuya kaz görünür” diye bir atasözü var. “Elimizde bulunanın değerini yeterince bilmeyiz, başkasına bulunanı daha değerli ve bizimkinden daha üstün görürüz” anlamında söyleniyor.

Veri ambarı oluşturmaya başlandığında, bir aşamada bu düşünce yapısı ortaya çıkar.

😉

Bir örnek:

Yıllar önce, bir market zincirinin CRM müdürüyle sohbet ederken, ikimizde de benzer bir düşünce olduğu ortaya çıkmıştı. Müşteri iki demet maydanoz, bir demet roka, laktozsuz süt, yağsız yoğurt… satın alıyorsa, market zinciri o kişinin diyet yaptığını, belki de et yemediğini bulabiliyor. [Veri anlamlandırma konusunda oldukça ayrıntılı bir yazı hazırlıyorum. İlgileniyorsanız, bilgim olsun.]

Biz (banka olarak) müşterinin alışverişindeki her bir malzemeyi bilemiyoruz. Sadece alışveriş sonunda kasaya ödediği toplam tutarı bildiğimizden, müşteriyi ayrıntılı tanımayı sağlayan market verilerine çok özeniyoruz.

Bazı müşteriler sadakat kartı numarasını aile üyeleriyle paylaşıyor. Alışverişi kimin yaptığı belli olmuyor. Marketin verileri kirleniyor, bazı müşterileri tanımak olanaksızlaşıyor. Market zinciri ise, müşteri tekilleştirmedeki yasal avantajımız nedeniyle bize özeniyor.

😀

Zaman içinde gördüm ki kurumların büyük çoğunluğu diğerinin verilerine özeniyor.

Bu rahatsızlığın tedavisi basittir. “Keşke” metodunu bırakıp, elimizdekilerle en iyi ne yapabiliriz diye modeller üretmeye çalışmak yeterlidir. Yukarıda sözünü ettiğim ayrıntılı senaryoları içeren veri sözlüğü size yardımcı olacaktır.

 

Belki Fazlası Vardır

Benim gördüğüm “veriye dayalı rahatsızlıklar” bunlar. Sizin başka teşhisleriniz varsa yorumlara yazın, üzerinde tartışalım. Çok keyifli olabilir.

😉