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ı

Bir şirkette Sosyal CRM workshop’ı yapıyorduk. Eğer yeterli zamanım varsa, önce kısaca CRM’i anlatıp, veriye dayalı düşünme konusundan bahseder sonra Sosyal CRM’e geçiş yaparım. Burada da CRM’den giriş yaptık.

Veriye Dayalı Düşünme

Sosyal CRM eğitimlerine, önce veriye dayalı düşünme ile başlarım. Bunu da açıkça söylemem. Burada da, veri kısmını anlatırken tahtaya

yazdım.

Sonra “Hedef kitlenizdekilerin hangi bilgilerini öğrenmek istersiniz?” diye sordum. Sektörden bağımsız olarak, perakende kurumlarda hemen her zaman aynı yanıtlar gelir. Onlar da aşağıdaki listeyi tekrarladılar.

• Adı – Soyadı
• Doğum tarihi (veya Yaşı)
• Cinsiyeti
• Medeni Durumu
• Eğitimi (aslında Bitirdiği Okul olması gerekir)
• Mesleği
• Adresi

Söylenenleri tahtada Veri’nin altına gelen bölüme yazdım.

Sonra CRM projesinin amaçlarını sordum.

• Hangi ürün grupları kime daha iyi satar?
• En sık gelen müşterilerim kimler ve ne alıyorlar?
• Sunulan teklife cevap verme ihtimali yüksek olan müşteriler kimlerdir?
• Hangi müşterilerimi kaybetme ihtimalim var?
• Hangi müşterilerime hangi sıklıkta ve nasıl yaklaşmalıyım?

gibi cümleler söylendi. Bu sefer söylenilenleri İhtiyaç’ın altına yazdım.

Tahtada şöyle bir görüntü oldu.

Kendilerinin söyledikleri ihtiyaçları karşılamak için hangi verilerin gerekli olduğunu sorgulayınca… kırmızıyla yazılı olanların pek azına dokunduğunu gördüler. Kısa sürede bambaşka noktalara geldik. Amacım veriye dayalı düşünmeyi anlatmaktı. Veriden değil ihtiyaçlardan yola çıkılması gerektiğini böylece anlatabildim. (Daha ayrıntılı isterseniz şurada)

Daha sonra “Hiç bu gözle bakmamıştık. Devasa sosyal veri dağında ne yapacağımızı düşünüp duruyorduk. Şimdi hedefimizi daha kolay saptayabiliriz” dediler.

Veri var ama…

Bunu blog yazısı olarak yayınladığımda, sayın Ibrahim Gokcen yorum yazmış ve senaryo ile başlamak gerektiğini söylemişti. İhtiyaçlar, senaryolardan sonra ortaya çıkıyor. İbrahim bey yüzde yüz haklıydı ama bir workshop’ta bunu anlatmakta zorlandığım için oraya hiç gir(e)memiştim. Nasıl oldu da yeniden gündeme geldi, anlatayım.

Segmentasyon’un dönüşümünü tartıştığım blog yazısına yorum yazan sevgili Burcu Tüzün Altınkeser yazıda konaklama sektörü üzerinden örnek verdiğim için, aynı sektördeki sorunların küçük bir kısmını dile getirmiş. (“… bir kısmını…” diye yazdım. Konaklama sektörü, hak ettiği veri yönetiminin çok gerisinde çalışıyor.)

Biz CRM’in ana öğesi segmentasyonu ne kadar derinleştirirsek derinleştirelim, veri taşıma sorunu çözülmeden ilerleyemiyoruz. Yani sert yastık isteyen müşteri, bir iş adamı da olabiliyor, boyun fıtığından mustarip bir yazılımcı da, geçmişindeki bir kazada boyun omur hasarı almış bir ev hanımı da olabiliyor.

Bu kadar ayrıntılı datayı ilk alan ise aslında müşteri ile ilk temasta olan resepsiyon, oda servisi, kat görevlisi vs. Yani asıl sorunu verinin taşınmasında yaşıyoruz. Çünkü o veri sisteme kadar iletilmiyor, havada kalıyor. Bu nedenle İngiliz sigorta şirketlerine ödeme iadesi yapan çok otel var.

Odaya tamir amaçlı teknik ekip gidip gitmediği bilgisi sisteme iletilmediğinden, otel kendisini savunamıyor ve para iadesine kadar gidiyor iş. Pek çok yabancı turist bunu bilip, buna göre tatilini yapıyor ve dönünce şirketinden parasını iade istiyor.

Bu veriyi taşımayı başaran da, bireye ait bir hizmet sunmak istemiyor.

Burcu’nun yorumunu yanıtlarken, bu blog yazısını oluşturmak aklıma geldi.

İhtiyaç’tan önce Senaryo

2022 senesinde, 6-7 tesisi olan bir tatil köyü zincirinin CRM projesinde danışmanlık yaptım.

Orada veri ve süreç ihtiyaçlarını bulmanın en iyi yolunun senaryolar üretmek olduğunu anlatma fırsatım oldu.
Yukarıdaki örneği senaryolaştırırsak:

• Müşteri bir önceki gelişinde sert yastık istediğini söylemiştir. Bu talep oda hizmetlerine iletilirken müşteri bilgi dosyasına (MBD) da girilir. → Demek ki

1 – Müşterinin sert yastık talebini yapabileceği noktalardaki ekranlarda, benzer müşteri taleplerinin sisteme girileceği bir saha oluşturulacak;

2 – MBD’de yastık tercihi sahası olacak

• Müşterinin bir sonraki rezervasyonunda sistem otomatik olarak “yine sert yastık” talep edilip edilmediğini sorar. → Demek ki

a – Müşteri tekilleştirmesi yapılmış olacak. Daha önce konaklamış müşteriyi tanıyacak.

a1 – Bazı konaklama yazılımlarında yapay zeka kullanılarak “yüzde # olasılıkla şu müşteri” diye eşleştirme yapılıyormuş.

b – MBD’ler rezervasyon sistemine bağlı bir şekilde çalışacak. Daha önce konaklamış bir müşterinin farklı bilgileri rezervasyon noktası (muhtemelen çağrı merkezi) ekranına gelecek

c – Rezervasyon kaydını alan kişi, “bir rezervasyon daha yaptım” ile yetinmeyecek. Sistemde “eski müşteri benzerliği” söz konusu ise, bir-iki soru ile daha önce gelen (mevcut) müşteri olup olmadığını öğrenecek ve sisteme ona göre girecek.

b1 – Müşteri temas noktalarında çalışanlara eğitim verilmesi gerekir

b2 – Müşteri temas noktalarında çalışanların performans kriterlerine (KPI) bilgi doğruluğu oranı eklenir.

• Müşteri tesise geldiğinde, talepleri ve (varsa özel durumu) doğrulanacak. → Demek ki

d – Ön-büro ve misafir ilişkileri ekranlarında farklı talepler (sadece yastık değil, alerji, dini gereklerle odada istenmeyenler, vb. bilgileri) tekrar yer alacak,

e – Bu müşterinin ekranı açıldığında, “şu bilgileri doğrula” diye uyarı ekrana gelecek,

f – Rezervasyon sonrasında müşterinin odası önceden belirlenmemiş ve gerekli düzenleme yapılmamışsa, oda hizmetlerine “ACİL – sert yastık” bildirimi gidecek

…

• Varsayalım ki müşterinin talebini tatmin olacağı şekilde karşılayamadınız ve şikayet geldi. Sonrasında ne yapacaksınız (2014 senesi, CRM dersi final sorularından biri bu konudaydı. Çözümleri oradan okuyabilirsiniz.)

Daha senaryoya yeni başladık… Böylece gidiyor.

😉

Sevgili Burcu, teknik servis konusunda da bir örnek vermiş. Müşterinin klima arızası şikayetiyle kimse ilgilenmediğinde ne olduğunu (yatağını otelin lokantasına taşıyıp “Burası serin. Burada uyunur” dediğini ve eşinin videoya aldığını) tüm Türkiye öğrenmişti. (Videoyu seyretmek için resme tıklayın)

Burada sadece iş akışı hatası değil, iletişim noksanlığı da var. Bu da senaryo geliştirirken dikkate almamız gereken unsurlardan biri olarak düşünülmeli.

Teknik servis için de senaryo geliştireceksek, müşterinin şikayetiyle (sıfır noktası) başlayan ve olası (istisnai durumlar dışındaki) sonuçları dikkate alan tasarımı yaparız.

• • Senaryo ve süreç tasarımı aşamalarını daha ayrıntılı öğrenmek isterseniz, CRM’de Süreç Tasarımı yazısı yardımcı olabilir.
  • Bankada yaptığımız çalışmadan bir aşamayı da Bankada Süreç Tasarımı‘nda bulabilirsiniz.

😉

Bizzat yaşadığım ve konaklama sektörü için senaryolaştırdığım bir vakayı da şuradan okuyabilirsiniz.

Makul İdeal

Senaryo oluştururken, “tüm alt-yapıyı şimdi kursak ve ideal durumu hedeflesek neler yapardık” diye düşünmek gerekir. Makul ideal denilmesinin nedeni, ışınlama gibi uçuk idealler değil, piyasada olanlar arasından, makul bütçe ile satın alınabilecek veya hayata geçirilebilecek hedeflerin seçilmesidir. Elbette rakipler ve dünyadaki en iyi uygulamalar araştırılarak yapılır.

• • Makul ideal konusunda kargo sektörü için yapılan çalışmadan bir örnek burada
  • Neden ideal süreç ile başlanır
  • İdeal ve Benchmark
  • İdeal’i Öğren Tonton

Ben ısrarla, “İdeal durumu hedefleyin ve oraya doğrudan ulaşmaya çalışın” diyorum. (Gerekçeleri yukarıdaki referans yazılarda)

Biliyorum hiç kolay değil.

• Araştırma yapacaksınız. Başkaları değil, bizzat siz yapacaksınız. Danışmanlara bırakmayacaksınız. Dünyadaki en iyiyi inceleyeceksiniz. O “en iyi” denilenin eksik olduğu yönleri bulup, onu da aşacak bir süreç tasarlayacaksınız.
• Sürekli gelişmeyi hedefleyeceksiniz. Şikayetleri bile “mükemmelleşmek için fırsat” diye niteleyeceksiniz. Yanlışı müşteride değil kendinizde arayacaksınız.
• Müşteri deneyimini anlayacaksınız. Hem verilerle yaşamayı öğreneceksiniz, hem de verilerin yetersiz olduğunu bileceksiniz. Verileri anlamlandırarak müşteri deneyimini “ne yapılıyor ve nasıl yapılıyor” ötesinde NEDEN öyle yapılıyor noktasına kadar anlayacaksınız.
• Başka kurumlarla iş birlikleri oluşturacaksınız. Onlarla birlikte şeffaf bir bilgi akışı oluşturacaksınız.
• Siloları yıkacaksınız. Birlikte çalışmayı öğreneceksiniz.
• Personel idaresi değil yetenek yönetimi yapacaksınız. Bunca yıldır bildiğiniz “Gideni işe geri almam” kuralını yıkacaksınız.
• Ayrı kanal stratejileri uygulamayacaksınız. Müşteri deneyimine dayalı bütünleşik iletişim stratejisini tüm kanallara yayacaksınız.
• Ve buraya yazmadığım daha birçok değişiklik…

Bunları yaparak makul ideal’i tasarlayabilirsiniz.

Ez Cümle…

Tüm çalışanların bilgileri kolayca aktarabileceği iş akış tasarımlarını yapmak ve hayata geçirmek aslında çok maliyetli değil. Müşteri odaklı süreçler, hem maliyetleri azaltır hem de müşteri memnuniyetini artırır. Muhtemelen, konaklama tesislerinin bir çoğunun İngiliz turistlere ödedikleri tazminatlar ile kısa sürede yatırımı geri ödeyecektir.

🙂

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.

😉