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ı

Toplantı daha başlamamıştı. Büyük patron salona girdi ve daha yerine oturmadan “anlaşılan müşterinin kim olduğunu bilmiyormuşuz ki bizi de eğitime çağırdılar” dedi.

Videoyu biraz geriye saralım… Birkaç markası olan bir kurumun CRM müdürü, “müşteri deneyimi” konusunda eğitimler planlamış. Planlarken iyi ama hayata geçirmek için bütçe gerekiyor. Kurumlaşma yok. Tek karar verici patronlar. Sonuçta, patronların katılacağı bir toplantı düzenlendi. Sunumu ben yapacaktım.

Toplantı salonunda masalar uzun bir U oluşturacak şekilde dizilmişti. U’nun iki yanında arkalığı kısa sandalyeler, sunumun yansıtılacağı perdenin tam karşısına ise dört tane yüksek arkalıklı sandalye koyulmuştu. Kurumdaki emir-komuta katmanları arasındaki ayrım net olarak kendini gösteriyordu.

Sahneyi en çok kullanması beklenen kişi olduğum için, U masanın bir köşesine iliştim. Karşı tarafa müdürler yerleşti. İnsan kaynakları, iletişim, bilgi işlem, pazarlama… Daha sonra soyadları holding ile aynı olan 30-40 yaş arası katılımcılar geldi. Onlar da alçak arkalıklı sandalyelere fakat U’nun köşesine (dolayısıyla yüksek arkalıklı sandalyelere) en yakın yerlerde oturdular.

Hepimiz (yaklaşık yirmi orta kademe yöneticisiyle) hazır olunca patronlara haber verildi. İkisi günlük giysiler, biri ceket – gömlek – kravat giyen üç patron geldiler. Kravatlı patron kapıdan girerken “anlaşılan müşterinin kim olduğunu bilmiyormuşuz ki bizi de eğitime çağırdılar” dedi. Kendisi ortaya, diğerleri iki yana yerleşti.

Babalarından kalan küçük dükkânı büyük bir holdinge dönüştürmüş olan kardeşler yüksek arkalıklı sandalyelere kuruldular.

Ben sahneye geçtim, kendimi tanıttım ve MÜŞTERİ’nin tanımının kafa karışıklığı yaratabileceğini söyledim. İletişim ajansı ve pazarlamaya göre tanımı ile bilgi yönetimine göre tanımı arasındaki farkları anlatmaya başladım.

Brand Map’in  Ocak-Şubat 2024 sayısında bu farklar üzerinde durmuştuk. Sahnede, neden bu farkların önemli olduğundan bahsettim. “Müşterinin tanımını, bir yazılım cümlesi ile veri ambarından alacak biçimde yapamazsanız, müşteri geri kazanım projesi yapamazsınız” dedim. Bunu derken firmanın Bilgi İşlem müdürüne baktım. Bilgi İşlem Müdürü, beni onaylayan şekilde başını sallarken yüzünde “buralarda öyle olmuyor, maalesef” ifadesi vardı.

Veriye dayalı pazarlama yapmak isteyen kurumların birçoğunda, sürecin ilk aşamalarında ticari iş birimleri ile bilgi işlem çalışanları arasında çelişkiler olması kaçınılmazdır. Pazarlama teknolojisti (mar-tech expert) unvanının çıkma nedeni bu çelişkidir. Okuduğunuz yazının amacı, yeni bir aracı pozisyon yaratma gereğini ortadan kaldırmak ve kurum içinde sözel – sayısal ayrımını azaltıp ikisinin bir arada uyum içinde çalışmasını sağlamaktır.

 

Neden İşlevsel Tanım

Müşterinin tanımını, ölçülebilir ve yazılım cümlesi halinde veri ambarından alınabilir şekilde yapmazsanız bazı sorunları yaşarsınız.

“Bizimle en az bir faturalı işlemi olan” diye tanımladığınızı varsayalım. Yazılım cümlesi olarak kolay bir tanım yaptınız. Fatura bilgileri sayesinde veri ambarınıza müşteriyi kaydettiniz. “Kaç müşterimiz var?” diye sorulduğunda yanıt verebilirsiniz. Müşterileri cirosuna ve karlılığına göre sıralayabilirsiniz.

İlk adımı başarıyla geçtiniz. Alışveriş devam ediyorsa sorun yok. Her yeni işlemi sisteminize kaydedersiniz. Ciro, karlılık, ürün sayısı ve birçok ek bilgi ile müşteri bilgi dosyasını güncellersiniz.

İyi de bazı müşteriler bir süre sonra işlem yapmayabilirler. Rakiplere gidebilirler, işi kapatmış olabilirler veya sektör değiştirebilirler. Sizinle belli bir süre tekrar ilişki kurmayan müşterinize kendinizi hatırlatmak istersiniz. Acaba gerçekten kaybettiniz mi, yoksa rakipler nedeniyle sizi unuttu mu?

Müşterinin sizinle yaptığı en son işlemden bu yana uzun bir zaman geçmişse, onları hâlâ müşteriniz zannetmeniz yanlış olur. Bu durumda “en az bir faturalı işlemi olan”  tanımınız geçerliğini kaybetmeye başlar. Tanıma “en son alışveriş tarihinden bu yana şu kadar zaman geçmemiş olan” diye bir sınır eklemek istersiniz. Buradaki zaman sınırı sektörünüze, hatta müşterinin aldığı ürüne göre değişir. Supermarket zinciri için 15 gün, buzdolabı için 6-7 sene diye düşünmek yanlış olmaz.

Böyle olunca aktif müşteri, inaktif müşteri ve kayıp müşteri diye (aslında ilk yaptığınız müşteri tanımına bağlı) ek sıfatlar üretmek zorunda kalırsınız. Tanımlamalar yaparken en  kolayı “şu kadar süreden beri benimle işlem yapmamışsa onu kaybetmişimdir” diye belirlemektir. Bu cümle “hâlâ geri kazanma fırsatı olan süreyi” de tanımlar.

 

Yeni Tanımlar

Veriye dayalı pazarlama çalışmalarını şirkette hayata geçirdikçe yeni tanımlara ihtiyaç duyarsınız. Bankacılıktan bir örnek vereceğim.

Müşterinin iki ek kartı var. Biri eşinde, diğeri kızında. Dolayısıyla eşi ve kızının da tüm müşteri bilgileri sisteminizde kayıtlı. Ek kredi kartı dışında bankayla hiçbir ilişkileri yok. Bu ikisini müşteri değil kredi kartı kullanıcısı diye tanımladık.

Bir kişi, banka müşterisinin kestiği çek ile başvurdu ve parasını istiyor. Bankayla başka hiçbir ilişkisi yok. Elbette onun da tüm bilgilerini aldınız, parasını ödediniz gitti. Onu müşteri değil keşideci diye tanımladınız.

Ticari müşterinizin mağazalarında kredi kartıyla ödeme (POS) cihazınız var. En çok işlem yapan mağazanın müdürünün bazı bilgileri muhtemelen sizde kayıtlı ama hesabı yok. Tüm şahsi bankacılık işlemlerini başka bankalarla yapıyor. Onu da müşteri değil POS kullanıcısı diye tanımladınız.

“Ne mutlu ki bankacılık sektöründe değiliz. Bu kadar çok tanım gerekmiyor” diye düşünüyorsanız, GSM operatörü için örnek vermek isterim.

Müşteriler, çocukları 10 yaşına gelince cep telefonu veriyorlar. Müşterinin iki çocuğu varsa, üzerinde üç telefon olacak. Sizdeki kayıtlarda aynı müşteri adına üç telefon görünüyor. Müşteri çocuklarıyla görüştüğünde iki telefonun birbiriyle görüştüğünü biliyorsunuz. Ağır bir kişilik bölünmesi hastalığı yoksa (ki genelde pek olası değil) müşterinin bir başkasıyla konuştuğunu anlıyorsunuz. Ama bu sefer kullanıcının kim olduğundan tümden habersizsiniz. Oysa, kendi telefonunun sahibi olacağı zaman rakibinizin değil sizin müşteriniz olmasını sağlamak için şimdiden çalışmaya başlasanız iyi olur.

Petrol istasyonu için Brand Map’in  Ocak-Şubat 2024 sayısında örnek vermiştik.

Petrol şirketi bir kurum ile anlaşıyor. Bütün makam arabaları, o şirketin istasyonlarından akaryakıt satın alıyorlar. Sürekli olarak sizin istasyonunuzdan satın alması için promosyon yapıyorsunuz. Şirketin müşterisi ve istasyonun müşterisi diye katmanlar ortaya çıkıyor.

Süpermarket zincirine gelelim.

Sadakat programı yaptınız. Eskiden kart vardı ama artık telefon numarası üzerinden çalışıyorsunuz. Ciroya dayalı özendirmeler yaptınız. Müşteriniz durumu ailesi ile paylaştı. Tüm aile, alışverişlerde aynı telefon numarasını kullanıyor. Böylece ciroya dayalı indirimlerden yararlanıyorlar.

Verilere baktığınızda en az iki hatta daha fazla kişi tarafından kullanıldığını anlıyorsunuz. Aynı gün hem Kadıköy’de hem Marmaris’te kullanılmış. Ertesi gün de Kadıköy ve Marmaris alışverişleri var. Bir de araya İzmir girdi.

Onlar yolculuk yaptığında farklı kişilerin alışverişlerini ayırt edebiliyorsunuz ama hepsi eve döndüğünde aynı mağazanızı kullanıyorlar. Belki müşteriniz vegan ama kardeşleri değil. Müşteriniz hiç kahve içmiyor ama kardeşleri kahvesiz ayılamıyor.

Farkında mısınız, kimin alışveriş yaptığını bilmediğiniz gibi müşterinizi iyi tanımanızı sağlayan alışveriş verileri de bozuluyor. Keşke farklı tanımlayabilseniz de doğru müşteriye doğru teklif yapabilseniz.

Veriye dayalı pazarlama projeleri devam ettikçe, birçok farklı tanıma gerek duyarsınız. Tanımların hepsi yazılım cümlesi ile ifade edilebilir ve veri ambarında aranılabilir tanımlar olmak zorundadır.

 

Devamı var

Veriye dayalı pazarlama projelerinin amacı “doğru müşteriye, doğru zamanda, doğru ürünü, doğru teklifle sunmak”. Bunu başarabilmek için müşteriyi tanımlamak, veriyi anlamlandırmak, ayrımları (belki farklı kişilerin kullandığını) fark etmek, istisnaları ve modeli saptıran durumları belirlemek, anlamları test etmek ve derinleştirmek… gerekiyor.

Bitmedi… Müşteriyi tanımaya başlayınca, deneyim yolculuğunu da çıkarmak gerekiyor. Yolculuk haritası belirlenmezse, ayrımları saptamak ve bir sonraki olası ürünü tahmin etmek imkansızlaşır.

“Bunu yapay zekâ yapıyor, öğrenmeye ne gerek var” diye sorarsanız klişe yanıtımı söylerim: “Yapay zekâ kolay, parasını verince en iyisini alıyorsun. Sorun, gerçek zekâ bulmak”.

Biz, bir sonraki yazımızda müşteri deneyim yolculuğuna giriş yapalım. Yapay zekayı biz yönetelim.

😉

Not: Bu yazı ilk olarak BrandMap’in Temmuz-Ağustos 2024 sayısında yayınlanmıştır.

Pazar günü CRM dersimizin konuşmacısı, müşteri deneyiminin ustası Dr. Hakan Tetik idi.

Sevgiliniz sizi neden terk eder? diye bir sunum sayfası vardı. Anlatılmak istenen müşterinin terk nedeni ile sevgilininkinin aynı olduğu idi.

Hakan Tetik MBA katılımcılarından bir kaç tanesine sordu.

– Sevgilin var mı?

Hemen hepsi şu yanıtı verdi.

– Hayır ben evliyim.

MBA katılımcıları iş hayatında tecrübeli arkadaşlar. Ama evlilik süreleri daha birkaç seneyi ancak bulmuştur. Hiçbiri eşini sevgilisi olarak görmüyor. Bu yanıt arka arkaya tekrarlanınca gülmeye başladım.

Bilirsiniz, tanım konusuna düşkünümdür. Bu arkadaşların sevgili ve eş kavramlarını nasıl tanımladıklarını merak ettim.

Aklıma eski bir fıkra geldi.

Genç adam imama sormuş:

– İmam efendi. Karımı öpersem orucum bozulur mu?

İmam yanıt vermeden önce sormuş:

– Karın kaç yaşında?
– 18
– Kaç yıllık evlisin?
– Bir yıl olmadı.
– Öyleyse orucun bozulur.

Genç adam anlamayınca imam efendi açıklama yapmış.

– Ben 40 yıldır evliyim. Ha benim karıyı öpmüşüm, ha benim çarığı öpmüşüm. Ama senin durum öyle değil…

😉

Genç arkadaşlar, daha 40 yılı bulmadan…

Vah ki ne vah.

😛