“Yapay zeka gelince …” diye başlayan soruları sıkça duyuyorum. Bir ara çok sayıda “YZ geldi, CRM öldü” diyenler vardı. Kısa yanıtını [1] – [2] kere verdim.

Bunları niye tekrar yazdım. Son zamanlarda okuduğum çeşitli makalelerde ve Linkedin paylaşımlarında YZ’nın ürettiği raporların doğruyu göstermediği, arka arkaya alınan raporlarda bile farklılık olduğu, vb. üzerinde duruluyor. Bu durumun çözüm yolları öneriliyor.

10-15 sene önceye gidersek… Danışmanlık vesilesiyle tanıdığım birkaç şirkette, farklı iş birimlerinin her birinde sadece raporlamayla uğraşan 4 – 5 kişilik gruplar vardı.  Bir bankada bu konu abartılmıştı. Bireysel Bankacılık, KOBİ bankacılığı, Ticari bankacılık, Kurumsal bankacılık, Özel bankacılık, Alternatif dağıtım kanalları, vb… her birinin ayrı raporlama birimleri vardı.

Yani 35 – 40 kişi, tüm mesailerini farklı kaynaklardan, faklı sistemlerden rakamlar bulup yönetim kademelerine rapor yazmaya ayırıyorlardı. Her bir departman farklı kaynakları ve farklı tanımları kullandığı için, aynı konudaki raporlar bile farklı rakamlar gösteriyorlardı. Aslında, yönetimin elinde sağlam ve tutarlı raporlar da olamıyordu.

Yapay Zeka Gelince

Yapay zeka ile yapılabilecekler konusunda senaryolar üretmek ve hayaller kurmak çok güzel. Bu senaryo ve hayalleri mercek altına alıp, olası sorunları aklımıza getirdiğimizde ise, bambaşka noktaları dikkate almamız gerektiğini görüyoruz.

• Serkan KAV‘ın “Bir Yapay Zeka Kararının Delili Nedir?” yazısı, bir yapay zeka kararının katmanlarına ışık tutuyor.
• İsmail Yaman‘ın  “Bazı Anlar Hâlâ Bir İnsana İhtiyaç Duyar” yazısı, havaalanlarında yapay zeka uygulamalarının senaryolarından yola çıkıp, olası sapmaların sonuçlarını incelemiş.
• Sibel Akoğlu‘nun mesajları ama özellikle “YZ destekli dinamik pazarlama kurguları” konulu yazısı.
• Bir de McKinsey makalesi ekleyeyim. AI data readiness: The key to scaling impact.

Bu dört yazıyı da, geçmişte benden eğitim almış (ve gelecekte alacak) arkadaşlara öneriyorum.

Ercüment Büyükşener‘in Linkedin’de paylaştığı yazıları ve sohbetleri de izlenmeli.

Bir de Alper Bayraklı‘nın Linkedin paylaşımları var. Yurt dışına da hizmet veren bir ajansın AI ile yolculuğunun güncesi gibi… Çoğunluğu “mutlaka okunmalı” dediğim yazılar. Bazı yazılarından seçtiğim cümleler şöyle:

• “Bunu Ahmet yaptı, ben bilmiyorum” cümlesi teknik borcun dokümante edilmemiş halidir.
• “Hafta sonu bir bakarız” cümlesi benim için sessiz bir krizdir.
• AI çağı, her şeyi yeniden yıkıp yeniden yaptığımız ilk çağ değildi. Waterfall’dan Agile’a, Monolith’ten Microservices’e geçişleri (ve zaman zaman geri dönüşleri) düşündüğümde, AI’ın bizi zorladığı yerin aynı olduğunu görüyorum: zihniyet değişikliği.

Doğru Raporlamak İçin

Mevcut durumda yaptığınız işleri (ve raporları) aynen dijitalleştirirseniz… hızını artırırsınız ve sabitlersiniz. Zaten yaptığınız yanlışı daha hızlı ve geri alınmaz büyük bir yanlış hâline getirirsiniz.

Bu kadar uzun giriş paragrafları ve referanslar yazmamın nedeni, bu cümledir.

Şimdi çözümü konuşalım.

İlk yapmanız gereken çalışma, mevcut raporları gözden geçirmektir.

 

Tıpkı “Veriden Önce Yanıtlanması Gereken Soru” yazısında vurguladığım gibi “Ne yapacaksın bununla?” sorusuyla başlanmalıdır.

• Bu raporu kim üretiyor?
• Neden bu rapor üretiliyor? Hangi belirsizliği azaltıyor?
• Kim kullanıyor?
• Nerede kullanıyor?
• Hesaplama yöntemi nedir?
• Bu yöntem gerçekten amaca hizmet ediyor mu?
• Başka bilgilerle desteklenirse, daha doğru karar verilebilir mi? (Hangi başka bilgiler?)
• Bu rapora dayalı kararlarda nasıl sonuçlar elde edildi? (Gerçekten işe yarıyor mı?)
• Bu rapor hâlâ geçerli mi? (Hangi durumlarda bu raporu dikkate almamamız lazım?)

Bu soruların bir kısmının yanıtını yapay zekadan alabilirsiniz. Hiç sakıncası yok, hatta yararı var. Yeter ki ilk soruları kendiniz yanıtlamaya çalışın.

Bu soruları yanıtlamaya kalkıştığınızda kendinizi “Veriden Önce Yanıtlanması Gereken Soru” yazısında anlattığım veri sözlüğünün karşısında bulacaksınız. Bu noktada “yapay zeka varken buna gerek yok” demeyin.

• Ömer KORKMAZ, Linkedin’deki yazısında şu noktalara değinmiş. “Verisini yönetemeyen bir otel, yapay zekâyı nasıl yönetecek?“, “Yoksa mevcut dijital karmaşanın üzerine eklediğimiz daha pahalı bir katman mı?“, “Daha kaliteli veri. Ve mümkünse tek bir doğruluk kaynağı.” (Aradan işime gelen cümleleri çekip aldığımı düşünürseniz, tamamını okuyuverin.)
• Sibel Akoğlu‘nun yukarıda referans verdiğim yazısı, müşteri odaklı veri ambarının önemine değiniyor.
• McKinsey’in AI data readiness: The key to scaling impact makalesinde, tekrar kullanılabilecek verilerin önemine değiniliyor.
• Elinizde veri olabilir ama bağlam ve müşteri deneyimi konusunda yeterli tecrübeniz yoksa, felaket yanlışlar yapabilirsiniz. O dönemlerde bunun sorumluluğunu insanlar üstleniyordu. Artık “Ben yapmadım, yapay zeka yaptı” mı diyeceksiniz.

Envanter yönetiminde FIFO (First in first out) ilk giren ilk çıkar – LIFO (Last in first out) son giren ilk çıkar gibi yöntemler vardır. Veri yönetiminde GIGO (garbage in garbage out) çöp koyarsan çöp alırsın değişmez bir gerçektir.

Yapay zeka bunu azaltmaz ama hızlandırır.

Özetle

“Yapay zekayı raporlama için kullanıyorum. “Şu müşterideki son durumu bana şu şekilde özetle” diyorum. Şipşak görüntü alıyorum” diyorsanız… kişisel kullanım için ehh… idare eder. Ama kurumsal boyutta böyle düşünüyorsanız.

Birkaç sene sonra anılarınızı ve hüznünüzü paylaşacağınızı şimdiden söyleyebilirim.

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

.

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ı

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.

😉