Siz okumaya başlamadan önce belirteyim. Bu seferki M&A öyküsü sıkça rastlanan bir durum değil. Açıkçası, pek bir esin kaynağı olmayabilir.

Bir banka satışa çıkmıştı.

Satış Öncesi (Kişisel Görüşüm ve Yaşadıklarım)

Her ne kadar birçok kişi o bankanın diğer bankalar tarafından batırıldığını söylüyorsa da ben inanamıyorum. Daha birkaç ay önce o bankada çalışıyordum. Patronun, “böyle yaparsan bankayı batırırsın” diyen deneyimli üst yönetimi kızak pozisyonlara çektiğini ve kendi sözünden çıkmayan deneyimsiz ve kişiliği oturmamış kadroyu üst yönetime getirdiğini şahsen görmüştüm. Onlar da kendileri gibi birkaç kişiyi GMY yaptılar.

Yeni gelen GMY’ler, öncekiler hakkında karalama ve küçük düşürme çalışması yaptılar. Henüz o düzeyde olmadığım halde bunlardan payımı aldım. Dehşet bir mobbinge uğradım.

Doğrudan bağlı olduğum GMY de değişmişti ve yerine banka koridorlarında görmeye alışkın olmadığımız davranışta (açık ofiste hakaretlerle ve küfürlerle bağıran) biri gelmişti. Bu GMY’nin öfke gösterilerinden biri şurada yazılı.

Bu olayın olduğu gün ayrılmak zorunda kalmıştım. Bir gün bunu da paylaşayım.

Bu GMY, şimdi bir bankanın Kurumsal Krediler ve Proje Finansmanı Direktörü. Yanında çalışanlar düşünsün.

Ben ayrıldıktan 6 ay sonra bankacılık krizi yaşandı. Bunu öngördükleri için kızağa çekilen deneyimli bankacıların söylediği gibi, o banka ilk havluyu atanlardan biriydi. Satışa çıktı. O sırada çalıştığım banka da teklif verdi. Mobbing sonucu ayrılmak zorunda kaldığım bankaya bu sefer, M&A ekibinin bir parçası olarak gittim. Bireysel bankacılık portföyünün değerlendirmesinden sorumluydum.

Mobbing ve Bumerang yazısında, ilginç bir karşılaşmayı okuyabilirsiniz.

😛

M&A Süreci

Bir kurum alenen satışa çıktığında, M&A ve Modelleme’de yazdığım gibi “Eşinize ve iş arkadaşınıza bu süreçte olduğunuzu söylemeyin” düzeyinde gizlilik olmayabilir. Elbette satın alınmaya gidilen kurum hakkındaki bilgiler gizlidir ama orada olduğunuzu çalıştığınız yerdeki birçok kişi bilir.

Bu vakada da kimlerin satın almaya niyetli olduğu biliniyordu. Hatırladığım kadarıyla 5 banka ilgileniyordu. Bunlardan ikisi daha yeni el değiştirmişlerdi. Sanırım satın almaya niyetli değillerdi. Sadece kurumsal bankacılık portföyünde bulunan kurumlarla ilgili bilgi toplamak amacındaydılar. Gördüğüm kadarıyla bireysel portföy ile hiç ilgilenmediler.

Satış sürecinde şöyle bir yöntem uygulanıyordu. Alıcı adaylarından biri, bir belge veya bilgi istediğinde bu talebin anlamlı olup olmadığına bakılıyor, eğer anlamlı bir talepse sadece isteyen bankaya değil, ortak bilgi havuzuna ekleniyordu. Böylece tüm alıcı adaylarına eşit davranılıyordu. (Bu adalet ve şeffaflık kavramının birçok işte uygulanabileceği kanaatindeyim.)

Teklif veren her bankanın çok sayıda ekibi vardı. Kurumsal, Ticari ve Bireysel bankacılık ekipleri, yatırım araçlarıyla ilgili uzmanlar, hukukçular, vb… Bizim bankamız adına da yatırım uzmanlarından biri ekiplerin başındaydı. Ona raporluyorduk.

M&A Terk Nedeni

Bankanın perakende portföyünde sadece kredi kartları ve ödeme sistemleri yok. Mevduatlar, devletin borçlanma araçları, bireysel yatırımcılar da var. Bunlarda kendimi yetkin hissetmiyorum. Dolayısıyla ekibimde bu konularda uzman arkadaşlar da bulunuyordu. (İçlerinden biri sonra banka GMY oldu.)

Diğer bankalar ve biz, satışa çıkan bankanın binasının eksi 2’inci katında çalışıyorduk. Orada telefonlar çekmiyor. Sabah işe girişiyoruz, ancak öğle yemeğine çıktığımızda dünya ile iletişime geçiyoruz. Sonra yine tecrit…

Birkaç günden beri çalışıyorduk. Dördüncü veya beşinci günümüzde öğle arası verdik. Yukarıya çıkıp telefonuna bakanlarda “Aaaaa” sesleri yükseldi. Bizim eksi 2’de bulunduğumuz yarım gün içinde bankanın değeri 20-25 milyon dolar azalmış. Ben hazine bonoları ve devlet tahvilleri konusunda (kuramsal bilgiler dışında) donanımsız olduğum için anlamadım. Hemen anlattılar.

Öğle arası bitince yine iletişimsiz ortama çalışmaya döndük. Akşam çıktığımızda bankanın değeri yine birkaç 10 milyon dolar daha azalmıştı. Aynı olay ertesi gün de tekrarlandı. Yanlış hatırlamıyorsam iki günde 120 milyon dolar değer kaybı oldu.

İkinci günün akşamı, kendi bankamıza döndüğümde doğrudan ekip liderine gittim:

– İzninle ben bireysel bankacılık ekibimi çekiyorum. Yarın biz gitmeyeceğiz” dedim.
– Ne oldu Uğur Bey?” Sanırım onun aklında “yanlış giden bir şey mi oldu?” sorusu vardı.
– 6 iş gününden beri inceleme yapıyoruz. Devlet iç borçlanma araçları haricinde her konuda gerekeni yaptık. Bize göre bireysel portföyün değeri ## milyon dolar. Daha derin inceleme yapsam belki artı-eksi %5 fark eder. Zaten daha önce bu bankanın bireysel kısmında çalışıyordum.
Son iki günde bu banka 120 milyon dolar değer kaybetti. Hata yapsam bunun %1’i kadar bile olmaz. Bence siz bonolara, tahvillere ve kurumsal kredilere odaklanın. Bizim burada harcadığımız zaman anlamsız oluyor” dedim.

Ekip lideri biraz düşündü. “Aslında…(bu arada 10-15 saniye süre var ) Haklısınız Uğur Bey” dedi.

Krizi Fırsata Çevirmek

Biz (Ürün Geliştirme Ekibi olarak) zaten krizi fırsata çevirmeyi amaçlamıştık. Kriz döneminde ürün geliştirmeye yoğunlaştık. Bankacılık krizi bittiğinde birçok banka kapanmış veya el değiştirmişti. Bizim ekibimiz ise, en geniş bankacılık ürünleri yelpazesini oluşturmuştu. Türkiye’nin en önce gelen bankalarının ürün perakende yelpazesindeki tüm ürünler bizde de vardı. Hatta fazlasıyla…

😀

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.

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.

😉