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ı

“CRM ne işe yarıyor ki?”  [1] ve [2]  yazılarına gelen yorumlarda yoğun tartışmalar olduğunu yazmıştım. Bunlardan biri de “kendi CRM yazılımını üretmek” konusundaydı.

Şöyle bir tartışma oldu:

Pınar Demir – Bir CRM yazılımı olmadan firmanın kendi CRM yazılımını oluşturma süreçlerini yönetmek mesleki hayatımda bana en keyif veren kısım.
Uğur Özmen – Aynı fikirdeyim. IT tarafı güçlü kurumlara ben de “bir CRM yazılımı olmadan firmanın kendi CRM yazılımını oluşturmalarını” öneriyorum. Böyle bir projeyi yönetmek… paha biçilemez.
Engin Alan – … Günün sonunda içerideki konunun kendimiz mi geliştirsek, satın mı alsak noktasına gittiğini görünce şaşkın şaşkın bakıyorum. Amacımız temiz kıyafetse “hadi güzel bir çamaşır makinesi yapalım” demek amaca bir o kadar uzak kalıyor. Ucuzu pahalısı bir makine bulunur. Danışmanlık deterjanıyla belli bir ısıda (sürede) yıkanırsa pür-ü pak kıyafetler de giyilir. 🙂

Kısaltarak aktardım, tamamını yorumlardan okuyabilirsiniz.

🙂

Sayın Engin Alan’a hak verdiğim kısmın altını çizeyim. Aslında, girişimcilerde sıkça duyduğum “Dışarıda içine ne koydukları belli değil, en iyisi evde kendimiz yapalım”  mantığının çoğunlukla doğru olmadığını ben de sıkça söylüyorum. Özellikle ölçek ve güncelleme sorunlarını hatırlatıyorum.

Diğer yandan… Aksine örnekleri yaşamışlığım da var. Gerçek bir örnek de vereyim:

Dizinin ilk yazısında bahsettiğim gibi Chordiant muhteşem bir kampanya yönetimi aracıydı. Yanlış hatırlamıyorsam, istatistik doktoralı 3 kişinin başlattığı, müşterilerin sorunlarını çözerek ilerledikleri bir araçtı. “Şu da var mı?” dediğim her şey vardı. Üstüne, aklıma gelmeyen birçok özellik de barındırıyordu.

Fiyatı 1 milyon US$ civarındaydı. Bankamız bu parayı ödeyemezdi. Ne yapabilirdim?.. Tüm etkinliklerine katıldım. Yayınlanmış tüm dokümanları okudum. Chordiant’ı öylesine incelemiştim ki, Türkiye temsilciliğinde çalışanlardan daha iyi bilir durumdaydım.  Benim hazırladığım özellikler ve talepler (spec’ler) çerçevesinde Dışbank’ın değerli yazılım ekibi üretti. Elbette Chordiant kadar mükemmel olmadı ama 2 sene içinde eş zamanlı 70 kampanya yapar duruma geldik. Bana söylendiği kadarıyla bize maliyeti 60 bin US$ olmuştu.

😀

Elbette satın almak veya üretmek arasındaki seçim, zaman ve para maliyetleriyle birlikte ele alınır. Biz içeride geliştirmeyi kutsamıyoruz ama eğer içeride geliştirme yapabilecek beceri ve yetenek varsa o projeye danışmanlık yapmanın çok keyifli olduğunu söylüyoruz. Zaten teknolojisi gelişmiş kurumlar, piyasadaki yazılımları çok hızlı inceliyor ve kendilerine uyanları hemen satın alıp adapte edebiliyorlar.

“Onlar yapıyor, biz de yapalım” diye kalkışmadan önce elbette, “Profesyoneller tarafından özel alanda gerçekleştirilmiştir. Lütfen evde denemeyiniz” uyarılarını dikkate almak gerekir.

.

Bu mektubu daha önce yayınlamıştım.

Bu şikayet mektubunun yazılmasını sağlayan banka alt-yapı hataları zaten aynı yazıda yer almakta. Mektubu gönderen Seda hanım, şikayetinden sonra başına gelenleri de bizimle paylaşmıştı.

Bu yazının konusu, böyle bir mektubun tekrar alınmaması için iletişim sistemleri alt-yapısında yapılması gerekenler olacak.

Notlar:

• • • Bu yazı ilk defa 3 Aralık 2010’da yayınlanmıştı. Geçen zaman içinde hem müşteriyle temas edilen noktaların sayısı arttı, hem kredi kartı ekstrelerini posta ile gönderme zorunluğu ortadan kalktı, hem de KVKK gibi önemli yasal zorunluklar geldi. Bu nedenle yazıyı güncellemek istedim.
    • Artık, bazı yeni kampanya yönetim araçlarında iletişim tercihi cetvelleri yapısı önceden hazırlanmış geliyor. Elbette yine de ön çalışma yapılması ve bu yazıda belirtilen tabloların oluşturulması gerekiyor.
    • Bu yazıdan önce (veya hemen sonra) Müşteri İletişim Tercihi 1 ve Müşteri İletişim Tercihi 2 yazılarını okumak anlamlı olabilir.

🙂

Müşteri Temas Noktaları

Teknoloji sayesinde müşterilerle temas edilen noktalar çok arttı. Öylesine çoğaldı ki, “omnichannel mı, yoksa multichannel mı” tartışmaları yapıyoruz.

Kısaca liste yapsak, bir banka için müşterinin tek ürünü kredi kartı olsa bile, temas gerektiren şu eylemler var:

Ben banka özelinde yazdım ama siz bunu her sektöre uyarlayabilirsiniz.

• Başvuru,
• Kredi kartının teslim edilmesi,
• Hesap bildirim cetveli (ekstre),
• Kredi kartı ile her alışveriş,
• ATM ile yapılan her işlem,
• Beklenmedik tutarlarda alışveriş yapıldığında uyarı,
• Sakıncalı olduğu varsayılan yerlerde / tutarlarda alışveriş,
• E-ticaret (işlemin şifreyle yapılmadığı) işlemler,
• Müşterinin aradığı çağrı merkezi,
• Kampanya mesajları
• Hatırlatma mesajları + Push notifications (nasıl tercüme edeceğimi bilemedim)
• Müşterinin şikayetlerini ilettiği e-postalar,
• Müşterinin şikayetlerini ilettiği sosyal medya siteleri,
• Yasal uygulamaların müşteriye bildirilmesi,
• Ödeme yapılmadığı uyarısı,
• Kartın kapatılma uyarısı,
• Kartın kapatıldığı bilgisi.

Tüm temas ihtiyaçlarını ayrıntılı çıkarmak için müşteri deneyim yolculuğunu çıkarmanızı öneririm.

İşin içine diğer bankacılık ürünleri (mevduatlar, yatırımlar, otomatik ödemeler, ATM’den nakit çekişler…) de girince bankanın onlarca temas gerektiren işlemi olur. Ancak müşteri kendisi ile kurulacak temaslarda bazı kanalları kullanmak ister, bazılarını ise hiç tercih etmez.

KVKK işin içine girdiği için, müşterinin tercih etmediği iletişim kanalı artık kurumların / markaların keyfine kalmış da değil.

😉

Kurumun Tercih Ettiği Temas Noktaları

Bankalar, müşteri aksine bir talepte bulunmadıkça, kartı (mesai saatleri içinde iş yerinde bulunduğu için) iş adresine; aylık hesap ekstrelerini ise müşterinin belirlediği e-posta adresine gönderirler. Elbette hâlâ bankadan bizzat posta yoluyla hesap ekstresi isteyenler de var.

Daha çok müşteriye ulaşmak için, kurumlar (ve markalar) kampanyalarını her kanaldan duyurmak isterler. Maliyetleri azaltmak için de, basılı gönderimler yerine e-posta veya SMS ile iletişimi tercih ederler.

Ayrıca müşterinin tercihi o yönde olmasa bile, yasaların zorunlu kıldığı bazı bildirim şekilleri ve kanalları da vardır. Örneğin, bazı belgelerin iadeli taahhütlü mektup ile gönderilmesi yasa veya mevzuatlar tarafından şart koşulabilir.

Dolayısıyla bankanın tercihi olan bir iletişim cetveli söz konusudur:

(Tablo sadece örnektir. Lütfen X’lerin yerini tartışmayalım.)

Bu iletişim cetveli (iletişim matrisi) tüm müşteriler için geçerli olan kurum tercihidir. Ancak, bu çalışma tek başına yeterli değildir. Müşterinin şikayetini duyurduğu kanal sosyal mecralar ise, aleni yanıt anlamlı olmayabilir. DM ile veya bir başka kişisel iletişim kanalı kullanılabilir.

Bu yazının konusu değil ama şunu da eklemek isterim. Müşteriler “bağcı dövmek değil, üzüm yemek” ister. Olağan kanalları kapatırsanız, mecburen sosyal mecralarda yazarlar. Siz, şikayetin doğrudan size gelmesini kolaylaştırmalısınız.

Müşterinin Tercih Ettiği Temas Noktaları

Müşteri, harcamalarını herkesten gizlemek isteyebilir. Bu durumda, müşteri kredi kartı ekstresinin bankanın tercih ettiği (daha sık bakmak zorunda olduğu için iş e-posta adresi) dışında bir adrese gönderilmesini tercih eder, hatta “siz hiç ekstre göndermeyin, ben uygulamadan bakarım” der. Müşterinin tercih ettiği teslim adresinin sisteme girilmesi ve daha sonra müşterinin değişiklik talebi olmaksızın değiştirilmemesi de gerekir.

Ayrıca kurum tüm kanallardan kampanya duyurusu yapmak ister ama  müşteri, kurumun / markanın tüm kampanyalarını tüm kanallardan almak da istemeyebilir. Bazılarını e-posta olarak görmek, bazı uyarıları SMS olarak almayı tercih eder.

Pek az kurum bunu ayırt etme yeteneğine sahip. Aşağıda, 28 Eylül 2014 tarihli Berkan Bağcı’dan alıntıda göreceğiniz gibi, büyük teknolojik (??) kurumlarda bile farkındalık olduğu kanaatinde değilim.

Bu durumda, şöyle bir müşteri iletişim tercihleri cetveli oluşur:

(örnektir)

Elbette bu iki iletişim cetveli arasında KVKK’ya uygun bir filtre de olması gerekiyor. Bu filtreye ve cetvele göre, müşterinin hangi konuda, hangi kanaldan temas edilmesine izin verdiği sistemlerimize aktarılır.

Akıllı kurumların, farklı kanallardan farklı duyurular için izin alması, iletişimin tümden kopmasını engelleyecektir. Benden söylemesi.

Öncelikler

Müşteri ile iletişim noktalarının düzenlenmesi, hangi konuda hangi kanaldan iletişim yapılacağının belirlenmesi, yasal sınırlamalar ve müşteri tercihleri göz önüne alınarak alt yapının geliştirilmesi çok önemlidir.

Yasalar izin verdiği sürece, firma müşteriyi ucuz kanallara yönlendirmelidir. Örneğin, ekstrenin normal posta yerine SMS ve e-posta ile alınması özendirilmelidir.

Yukarıdaki iki tablonun birlikte nasıl çalışacağı, hangi koşulda hangisinin öncelikli olacağı önemli bir CRM süreç çalışmasıdır.

Müşterinin hangi konuda hangi kanal ile kendisiyle temas edilmesi konusuna dair tercihini mutlaka bilmeli ve sistemlerimize eklemeliyiz.

• Yukarıda anlatılan altyapıyı 2002 – 2003 yıllarında Dışbank’da kurmuştuk. Müşteri iletişim cetvelleri düzgün oluşturulmazsa, ne gibi sorunlar yaşandığını göstermek için, Berkan Bağcı’nın şikayetine ait Facebook görüntüsünü yazıya ekledim.

😉

Örnek – 28 Eylül 2014

Berkan Bağcı ^[3] , Turkcell ile sorun yaşamış.

Bir aralar “Turkcell ürün ve kampanyalarından SMS almak istemiyorum” seçeneğini tercih etmiş. Bunun üzerine “internet paketimin kotasını tüketmek üzere olduğu” uyarısı ona gönderilmemiş ^[4] .

Okuma malzemesi: Anlamlı, tutarlı ve sürekli iletişim

😉