CRM projelerine başlamadan önceki zamanlardan, IT ile pazarlamanın ikiz kardeş gibi çalışmaya başladığı 1980’lerden beri birlikte çalıştığım ekiplere “algoritma ile düşünmeyi” öneririm. Bunun bir nedeni (kimin söylediğini hatırlamıyorum ama bence çok doğru olan) “IT’ye pazarlamacı gibi düşünmeyi öğretmek, pazarlamacılara IT gibi düşünmeyi öğretmekten zordur” saptaması.

Profesyonel iş hayatımın son yıllarında “tecrübeli” değil mümkün olduğunca “yeni mezun” işe almaya çalıştım. İlk iş deneyimlerini doğrudan benimle yaşamalarını istedim, bildiklerimi şahsen aktarmaya çalıştım. Yıllar önce, 2000’lerin başında ilk yöneticisi olduğum bir iş arkadaşım geçenlerde bir bankanın Dijital Kanallar ve Ürünler İş Geliştirme Direktörü oldu. Gururlandım ve kutlama mesajı gönderdim. Bana

“Kariyerimin başında IT’nin dilinden iyi anlamak, süreçlerin detaylarına hakim olmak, trend’leri takip etmek gibi birçok konuda bana çok güzel vizyon kattınız ve bana güzel kapılar araladınız. Üzerimde emeğiniz büyük, sevgiler“

diye yanıt verdi. Var ya… O günüm çok güzel geçti. Ayaklarım yere değmedi.

Her zaman işe yarar ama “IT’nin dilinden anlamak” için algoritmayla düşünmek, en azından algoritmayla IT’ye anlatmak gerekir. Algoritma ile düşünmek deyince “Çok zor değil, iyi bir yemek tarifi veya iyi bir adres tarifi de algoritmadır” diye söylüyorum. Özetle yaklaşık 20 yıldan beri ben de “Algoritma ile Düşünmek” diyorum (hatta 6 sene önce yayınlamıştım bile). Ayrıca “herkes kodlama öğrenmeli” diyenlere “Hayır, herkes algoritma ile düşünmeyi öğrenmeli” [1] ve [2]  diyorum.

Bu hafta gelen mesajlar içinde Harvard Business Review (HBR) Türkiye’nin web sitesinde bu konuda bir yazı olduğunu gördüm.  Güzel bir tesadüf, yazıda da örnek olarak bir yemek tarifi yazılmış.

CRM derslerimizde [a] , [b] , [c] , [d]   işbaşı eğitimi gibi çalışıyoruz. MBA katılımcıları birer sektör seçiyorlar ve dönem boyunca o sektörde CRM projesi yapar gibi ilerliyorlar. Süreç tasarımı aşamasına geldiğimizde “müşteriye en çok dokunan süreçlerden birini ideal olması gereken duruma getirin ve IT’ye bir algoritma ile nasıl bir süreç istediğinizi anlatın” diye ödev veriyorum.

HBR Türkiye web sayfasında yazıyı okuyunca, MBA katılımcılarına mesaj gönderdim. “Lütfen o yazıyı okuyun, hatta basılı alıp saklayın. Bu konuda bir ödevimiz olacak” diye bildirdim.

😉

Yakın geçmişte yayımladığım Danışmanlık #.0 ve Danışmanlıkta Dönüşüm Sancıları yazılarında, değişim ve/veya dönüşüm önerilerinde bulunan danışmanlık şirketlerine ayna tutmaya çalıştım. Danışman ve çoban veya danışman kedi fıkralarının doğmasına neden olan danışmanlık yöntemlerinin eskidiğini anlatmak istedim.

Bilginin serbest dolaşımda olduğu bugünlerde, danışmanın temel faydası bilgiyi değil yöntemi öğretmek oluyor. Bizzat uygulama deneyimine sahip olmayanlar bocalıyor. Onların bocalaması, tüm danışmanlık sistemine zarar veriyor. Özellikle, temel uğraşılarına odaklanan ve diğer konuları dış kaynak kullanarak çözmeye çalışan kurumlara hizmet verenler, eski danışman algısından zarar görüyor.

😉

Sadece danışmanları suçlamak doğru değil. Danışmandan ne istemesi gerektiğini bilmeyen yöneticiler de var. Kendisinin ne kadar doğru düşündüğünü önaylaması için danışman tutan mı ararsınız, “sizi ne kadar iyi iş ürettiğimizi diğer iş birimlerine anlatmanız için tuttuk” diyen mi?

Elbette yazdıklarım tüm danışmanlık sistemini kapsamıyor. Kendisini bu kısır döngüden kurtarmak isteyen bir danışmanlık kurumuyla, müşteri geri bildirimi almak konusunda sohbet etmiştim. Bu sohbette konuştuklarımızı yazıya döktüm. Hem danışmanlık kurumlarına, hem de müşterilerine  yararlı olmasını umarak paylaşıyorum. [Değiştirme ve düzeltme önermek serbesttir. Böylece, en iyiye hep birlikte yaklaşabiliriz.]

😉

Danışmanlık süreci genelde 3 ana aşamadan oluşuyor:

1. Satış
2. Proje
3. Proje Sonrası

Bu aşamaları sırayla inceleyelim:

SATIŞ

Satışlar genelde, 2 şekilde gerçekleşiyor:

a) Yeni müşteri: Çoğunlukla müşteri adayından talep gelir. Danışmanlar hazırlık yapar. Müşteriye sorulacaklar belirlenir. Birkaç toplantı ve biraz yazışma sonrasında, teklif ve bütçesi sunulur.

b) Mevcut müşteri: Danışmanlar, eski müşterilerini ziyaret eder ve “Size şöyle bir proje yapalım. Şunlara yarar. Maliyetleri azaltır ve gelirleri arttırır; bilançoya faydası şudur” diyerek ikna eder ve proje kararı verilmesini sağlar.

Bu aşamada nasıl geri bildirim alınabilir:

• Sürecin başında, ilk toplantıda müşteriye tüm süreç anlatılır ve aksayan her noktada geri bildirimi özendiren bir ortam sağlanır.
• Ortada bir Teklif Talebi (Request for Proposal – RfP) varsa, bu talebi hazırlayanların beklentilerinin ne kadar karşılandığı (yöntem ve bütçeyi içeren son teklifin sunulmasından önce) her toplantı sonrasında ölçülür.
• Eğer müşteriye uygun olduğu düşünülerek sıfırdan proje geliştirilmişse, projenin yaratacağı etki ve katma değerin şirketin gündemi, stratejisi, ihtiyaçları vs ile ilgili uyumu sorgulanır.

Böylece “İstemiyoruz. Gündemimize uygun değil” yanıtını bu aşamanın son adımında duymak zorunda kalınmaz. Müşterinin hedefleri ve stratejisi öğrenilir, uygun ürün ve projeler geliştirilir.

Devamı gelecek yazılarda

Dün, World Marketing Summit‘de, pazarlama gurusu Philip Kotler konuşmalarından birinde “Pazarlama Yöneticisi, Finansman Yöneticisine yakın durmalı. Ne de olsa, parayı Finansmancı yönetiyor” dedi. Bence çok yanlış bir cümle.

Eğer birine yakın duracaksa, Teknoloji’ye yakın durmalı. 21’inci yüzyılda, dijital pazarlama çağında…

Diğer açıdan bakarsak bu cümle, kurum içi silolaşmayı çok özendiriyor. Bu açıdan da karşıyım. Birçok kurumda “C düzeyinde biri “Biz pazarlama olarak…” veya “Biz finansman olarak” diye konuşmaya başlarsa, o düzeydeki son konuşması olur. C düzeyi, siloların değil, kurumun çıkarlarını konuşmalıdır” denilmeye başlandı.

• Tek bir cümle ile yargılamayalım. Ben cımbızladım ve sadece bir cümleyi bugünün konusu olarak seçtim. Aslında çok şey konuşuldu. En çok da Philip Kotler konuştu. Zaten onu bir kez daha görmek için gitmiştim.
• Tuttuğum notları da paylaşacağım.

Bu vesileyle defalarca gördüğüm, bir o kadar da arkadaşlarımdan duyduğum bir pazarlama – IT ilişkisini anlatayım.

Teknoloji ekibi yazılımları ve ekran tasarımlarını seçmiş. İş birimleri itiraz ediyor ama onları dinleyen kim.

Bana sorduklarında, şöyle başlıyorum:

– Eyyy Teknoloji ekibi. Siz neden kendi tasarımlarınızda ısrar ediyorsunuz?
– İş birimleri anlamaz. Biz doğrusunu yaparız.
– Sizin yaptıklarınızı iş birimleri kullanmazsa kim zarar eder?
– Kullanmak zorundalar. Başka çareleri yok.
– Neden onların istediği gibi tasarlamıyorsunuz?
– O zaman maliyetli oluyor.
– Tasarım sürecine onları katsanız ve dinleseniz olmaz mı?
– O zaman proje uzuyor.

Sonuçta IT kendi kolayına gideni (iş birimlerini umursamadan) hayata geçiriyor. Sonuçta, yapılacak işler listesine “bir tık atmış” oluyor. Güya proje uzamıyor, ama iş birimleri seve seve değil diğer yöntemle kullandıkları için benimsemiyor, şikayetler azalmıyor. Müşteri ile temas edenlerin mutsuzluğu elbette müşteriye de yansıyor.

Benzer uygulamalardan birinde, Teknoloji ekibinin yaptığından memnun olmayan banka şube müdürü durumu bana şikayet etmişti. “Genel müdürlüğe şikayet etmekten korktuğunu” da söylemişti.

Aradan yıllar geçti, hâlâ iş birimlerini dışarıda bırakan IT bölümleri var.

🙁

Geçen hafta bir tane daha duydum. Dışbank’da birlikte projeler yaptığımız IT ekibine tekrar teşekkür ettim.

İyi ki vardınız ve birçok güzel projeyi birlikte tamamladık.

.