İçindekiler
Canlıya geçişin üzerinden altı ay geçmiş. Yönetim toplantısında satış fırsatları raporu ekrana geliyor ve biri, rakamların CRM’den değil satış müdürünün kendi Excel dosyasından geldiğini söylüyor. Temsilciler müşteri görüşmelerini yine kendi listelerinde tutuyor; CRM’e ay sonunda, zorunlu alanlar kadar giriliyor. Yönetim raporu yine elle hazırlanıyor. Lisans faturası ise her ay düzenli olarak geliyor. Sonunda masadaki biri herkesin aklındaki cümleyi söylüyor: “Bu yazılım bize uymadı.”
Bu cümle rahatlatıcıdır, çünkü kimseyi suçlamaz. Ne proje ekibi hata yapmıştır ne satış ekibi ne de yönetim; sadece yanlış ürün seçilmiştir. Bir sonraki adım da bellidir: başka bir yazılım. Ama yazılımı değiştirmek çoğu zaman sorunu da yeni sisteme taşır ve birkaç yıl sonra aynı toplantı, yeni sistemin adıyla yeniden yapılır.
Bu yazıda yazılımı sanık sandalyesine oturtuyorum. Ama adil bir yargılama için projeyi en başından, karar anından canlıya geçişten sonraki ilk altı aya kadar aşama aşama izlemek gerekiyor. Her aşamada ne olduğuna, neden olduğuna, işe neye mal olduğuna ve nasıl yapılması gerektiğine bakacağız. Her aşamanın sonunda da bir ara karar vereceğiz: Suçlu yazılım mı?
Yazı CRM üzerinden ilerliyor; ama aynı aşamalar bir ERP’de, bir raporlama platformunda ya da herhangi bir kurumsal yazılım projesinde de neredeyse aynen yaşanır.
1. Karar: “Rakiplerimiz de kullanıyor”
Çoğu CRM projesi bir toplantıda doğar. Bir yönetici bir konferanstan döner, bir rakip yeni sistemini duyurur ya da yeni gelen bir yönetici önceki şirketinde kullandığı sistemi önerir. Projenin hedefi kısa sürede bir slogana dönüşür: “Müşteriyi 360 derece görmek”, “Satışı dijitalleştirmek”.
Bunlar amaç değil, yön tarifidir. Sorun tanımlanmadan bir çözüm seçilmiştir. Başarının tanımı olmadığı için her paydaş projeden farklı bir şey bekler: Satış müdürü tahmin doğruluğu, finans tahsilat takibi, pazarlama kampanya listesi ister. Kapsam her toplantıda biraz daha büyür. Başarının tanımı olmayan bir proje ya hiç bitmez ya da herkesin farklı bir gerekçeyle başarısız saydığı bir noktada durur.
Nasıl yapılmalı:
- Projeyi bir yazılım adıyla değil, bir iş sorunuyla başlatın. “CRM projesi” değil: “Teklif sürecimiz üç hafta sürüyor ve kaybettiğimiz fırsatların neden kaybedildiğini bilmiyoruz.”
- Başarıyı en fazla iki üç rakamla tanımlayın ve bugünkü değerlerini ölçün. Tekliften satışa geçen süre, fırsat kazanma oranı, sözleşmesi yaklaşan müşterilerin ne kadar önceden görüldüğü. Bugünkü değeri ölçemiyorsanız projenin ilk işi bu olsun; yoksa altı ay sonra neyin iyileştiğini kimse gösteremez.
- Bu rakamlardan sorumlu, iş tarafında bir yönetici belirleyin. Projeyi bilgi işlem yürütebilir; ama hedefin sahibi iş tarafında oturmalı.
Sorulacak soru: Bu proje bittiğinde hangi bir iki rakam değişmiş olacak?
Ara karar: Yazılım masum. Bu aşamada ortada henüz bir yazılım bile yok.
2. Seçim: “Demoda en iyi görünen kazanır”
Seçim süreci genelde bir özellik tablosuyla başlar. Üç dört satıcı davet edilir, her biri bir demo yapar. Demolar hazırlanmış verilerle ve kusursuz bir senaryo üzerinden ilerler: Panolar renkli, raporlar tek tıkla hazır, mobil uygulama etkileyici. Sonunda en uzun özellik listesine ya da en parlak demoya sahip ürün seçilir.
Bu süreçte iki şey eksiktir. Birincisi, seçimi sistemi her gün kullanacak kişiler değil, satın alacak kişiler yapar. İkincisi, değerlendirilen şey ürünün neler yapabildiğidir; sizin ekibinizin bir gününde neye ihtiyaç duyduğu değil. Sonuç, ihtiyacın küçük bir kısmı için büyük, pahalı ve karmaşık bir sistemdir. Kullanılmayan her özellik ekranda bir kalabalık, eğitimde bir saat ve lisansta bir maliyettir.
Nasıl yapılmalı:
- Demoyu satıcının senaryosuyla değil, kendi senaryonuzla yaptırın. Bir temsilcinin sıradan bir gününü yazın: sabah yapılacak aramalar, bir görüşmenin kaydı, bir teklifin hazırlanması ve onaya gitmesi. Her satıcıdan bu günü kendi ürününde baştan sona canlandırmasını isteyin.
- Seçim ekibine sistemi her gün kullanacak kişileri alın. En deneyimli temsilci ile en yeni temsilci, aynı demo hakkında birbirinden çok farklı ve çok değerli şeyler söyler.
- Özellikleri değil, uyumu puanlayın: mevcut sistemlerinizle entegrasyon, veri taşımanın kolaylığı, dil ve yerel ihtiyaçlar, birkaç yıllık toplam maliyet.
- Ürünün, özelleştirme gerektirmeden ihtiyacınızın ne kadarını karşıladığına bakın. Özelleştirme arttıkça her sürüm yükseltmesi ayrı bir projeye dönüşür.
Sorulacak soru: Satış temsilcimizin sıradan bir gününü bu sistemde baştan sona canlandırdık mı?
Ara karar: Yazılım kısmen suçlu olabilir; gerçekten yanlış ürün seçilmiş olabilir. Ama ürünü seçen yazılım değildi.
3. Kurulum: “Herkesin her isteği”
Kurulum başladığında her bölüm masaya kendi listesiyle gelir. Satış yeni alanlar ister, finans yeni bir onay adımı, pazarlama kampanya kodları, yönetim de her biri farklı kırılımda bir düzine rapor. Proje ekibi kimseyi kırmak istemez; her istek “olur” diye listeye eklenir. Bir müşteri kaydının ekranı birkaç ay içinde onlarca alana, bir teklifin akışı onlarca adıma büyür.
Bunun iki kök nedeni vardır. Birincisi, süreç önceden tasarlanmamıştır: Bir fırsat hangi aşamalardan geçer, ne zaman “kaybedildi” sayılır, teklif hangi tutarın üstünde onaya gider? Bu soruların yazılı cevabı olmadığı için mevcut dağınık alışkanlıklar olduğu gibi sisteme kopyalanır. İkincisi, “hayır” diyebilecek yetkiye sahip, iş tarafında bir karar verici yoktur.
Kötü bir süreci otomatiğe bağlamak onu düzeltmez, sadece hızlandırır. Faturası da gecikmeden gelir: Bir kaydı girmek dakikalar sürer, her değişiklik pahalı ve riskli hale gelir, sürüm yükseltmeleri ertelenir.
Nasıl yapılmalı:
- Önce süreci tasarlayın, sonra sistemi kurun. Satış sürecinin aşamalarını, her aşamaya geçiş kuralını ve sorumlusunu tek bir sayfada yazın. İş tarafı bu sayfayı onaylamadan kuruluma başlamayın.
- Her alan ve her rapor için “bunu kim, hangi kararda kullanacak?” diye sorun. Cevabı olmayan alan eklenmesin. Bir alan eklemek kolaydır; içi hiç doldurulmayan bir alanı sistemden çıkarmak zordur.
- Talepler için tek bir karar mekanizması kurun. Yeni istekler bir listeye girer, değeri ve maliyetiyle birlikte değerlendirilir. “Olur” demek kadar “şimdi değil” demek de bu mekanizmanın işidir.
- Ürünün standart akışına uyum sağlamayı ilk seçenek yapın. Özelleştirme, ancak sizi gerçekten rakiplerinizden ayıran bir süreç için yapılmaya değer.
Sorulacak soru: Bu alan olmasa hangi karar verilemez? Ve bir talebe kim “hayır” diyebiliyor?
Ara karar: Yazılım hantal görünüyor; ama onu hantallaştıran, kurulum sırasında verilen ya da hiç verilmeyen kararlar. Yazılım masum.
4. Veri aktarımı: “Her şeyi taşıyalım”
Canlıya geçişten birkaç hafta önce veri aktarımı başlar. Eski sistemdeki müşteri kayıtları, muhasebedeki cari hesaplar ve satış ekibinin yıllar içinde biriktirdiği Excel listeleri tek bir yerde toplanır ve olduğu gibi yeni sisteme taşınır. Takvim sıkışmıştır; “temizliği canlıya geçtikten sonra yaparız” denir.
Canlıya geçişin ilk haftası, bir CRM’in kaderini belirler. Bir temsilci sistemi açar, en önemli müşterisini arar ve üç kayıt bulur: biri şirketin eski unvanıyla, biri iki yıl önce ayrılmış bir yetkiliyle, biri de çoktan kapanmış bir teklifle. Hangisinin doğru olduğunu bilmez. O andan itibaren CRM onun gözünde güvenilmez bir kaynaktır ve kendi listesine döner. Güven bir kez gidince geri getirmek, sistemi kurmaktan daha zordur.
Veri temizliği projenin en sıkıcı, en az görünen ve takvimde en çok sıkıştırılan işidir; bir sunumda gösterilecek ekranı yoktur. Ama bir CRM’in değerini ekranları değil, içindeki verinin doğruluğu belirler. Taşımaya başlamadan önce şu dört sorunun cevabı hazır olmalı:
Veriniz ne kadar temiz? Basit bir test yapın: En büyük yirmi müşterinizi bugünkü sistemlerinizde arayın. Kaç tanesi birden fazla kayıtla çıkıyor, kaç tanesinin yetkili bilgisi güncel? Yarım gün süren bu test, veri kalitesi hakkında uzun toplantılardan daha net bir resim verir.
Tekilleştirme kuralınız ne? Bir müşteriyi tekil yapan şey nedir: vergi numarası mı, e-posta adresi mi, telefon numarası mı? Aynı vergi numarasına sahip iki şube ayrı müşteri midir? İki kayıt çakıştığında hangisinin bilgisi kazanır: en yenisi mi, en eksiksizi mi, yoksa belirli bir sistemden geleni mi? Bunlar teknik değil, iş kararlarıdır. Yazılı değillerse, aktarımı yapan kişi kendi tahminine göre karar verir.
Müşterinin ana kaydı hangi sistemde? Müşteri bilgisi genelde birden fazla sistemde yaşar: CRM’de, ERP’de, muhasebede. Adres değiştiğinde nerede düzeltilir, diğer sistemler bunu nereden öğrenir? Bu sorunun cevabı yoksa sistemler birkaç ay içinde birbirinden kopar ve aynı müşteri her sistemde farklı görünür.
Geçmişin ne kadarını taşıyacaksınız? Her şeyi taşımak, kiri de taşımaktır. On yıllık teklif geçmişinin çoğu, kimsenin bakmayacağı ama herkesin arama sonuçlarında karşısına çıkacak bir yüktür.
Nasıl yapılmalı:
- Taşımadan önce bir veri sağlık kontrolü yapın: mükerrer kayıt oranı, boş ya da geçersiz alanlar, en büyük müşterilerdeki tutarsızlıklar. Sonuçları rakamla raporlayın; “veri biraz kirli” bir bulgu değildir.
- Tekilleştirme ve ana kayıt kurallarını iş tarafıyla birlikte yazılı hale getirin ve aktarımı bu kurallara göre yapın. Aynı kurallar canlıya geçtikten sonra da geçerli olsun; yoksa sistem birkaç ay içinde yeniden kirlenir.
- Her şeyi değil, aktif müşterileri ve son birkaç yılı taşıyın. Gerisi arşivde, gerektiğinde ulaşılabilir biçimde kalsın.
- Canlıya geçmeden önce iş tarafına “bu veriye güveniyoruz” diye onay verdirin. Bu onay bir formalite değildir; verinin sahibinin kim olduğunun ilk göstergesidir.
Sorulacak soru: Canlıya geçmeden önce bu veriye kim kefil olacak?
Ara karar: Yazılım masum. Yazılım kendisine verilen veriyi gösterir; kirli veriyi temiz gösteren bir CRM henüz icat edilmedi.
5. Canlıya geçiş: “Kutlama ve dağılma”
Canlıya geçiş günü geldiğinde proje planındaki son kutucuk işaretlenir. Kısa bir kutlama yapılır, proje kapanır, danışmanlar ayrılır, proje ekibi bir sonraki işe geçer. Kullanıcılar iki saatlik bir eğitim almış, ellerine bir kullanım kılavuzu verilmiştir.
Bu tablo, projenin bir bilgi işlem projesi gibi yönetildiğini gösterir: Başarı kriteri “zamanında ve bütçesinde canlıya geçmek”tir. Oysa bir CRM’in asıl hayatı canlıya geçtiği gün başlar. İlk haftalarda yüzlerce küçük soru ve aksaklık çıkar: Bir alan nasıl doldurulur, bir rapor neden farklı bir rakam gösterir, bir onay neden takılır? Bu sorular cevapsız kaldığında her küçük aksaklık “sistem çalışmıyor” algısına dönüşür. Bu algı, gerçek sorunlardan çok daha hızlı yayılır.
Nasıl yapılmalı:
- Başarı kriterini “canlıya geçtik”ten “kullanılıyor ve işe yarıyor”a taşıyın. İlk aşamada belirlediğiniz iki üç rakamı, canlıya geçişten sonraki üç ay boyunca izleyin.
- İlk haftalar için bir destek planı yapın: her ekipte sistemi iyi bilen bir yerel uzman, hızlı cevap veren bir destek kanalı ve haftada bir kısa bir geri bildirim toplantısı.
- Kullanımı ölçün. Kim sisteme giriyor, hangi kayıtlar güncel, hangi ekranlar hiç açılmıyor? Hiç açılmayan bir ekran ya gereksizdir ya da bir sorunun işaretidir.
- Sistemin iş tarafında kalıcı bir sahibi olsun: satış sürecini bilen, sistemdeki değişikliklere karar veren ve hedefleri CRM’in başarısına bağlı olan biri.
Sorulacak soru: Canlıya geçtikten sonra bu sistemin iş tarafındaki sahibi kim ve başarısı onun hedeflerinde yer alıyor mu?
Ara karar: Yazılım masum. Yazılım hala çalışıyor; onu yalnız bırakan, proje ekibinin dağılması.
6. İlk altı ay: “Excel’e dönüş”
Ve girişteki toplantıya geliyoruz. Temsilciler sisteme sadece zorunlu oldukları kadar giriyor, asıl takibi kendi dosyalarında yapıyor. CRM’deki fırsatların bir kısmı aylardır güncellenmemiş, bir kısmı hiç girilmemiş. Yönetim raporu yine elle hazırlanıyor, çünkü CRM’den çıkan rakama kimse güvenmiyor.
Temsilcinin gözünden bakalım. Bir müşteriyle görüşmüş, ofise dönmüş ve şimdi bu görüşmeyi on iki alanlık bir forma girmesi gerekiyor. Bu formdan kendisi ne kazanıyor? Çoğu projede cevap: hiçbir şey. Girdiği veri yönetime akıyor, raporlar yönetim için üretiliyor; temsilci ise sadece veri giren kişi. Üstüne bir de bu verinin performansını izlemek için kullanıldığını hissediyor.
İnsanlar kendilerine fayda sağlamayan bir sistemi, zorunlu tutuldukları kadar kullanır. Zorunluluk verinin miktarını artırır, kalitesini değil: Alanlar doldurulur ama doğru doldurulmaz.
Nasıl yapılmalı:
- Sistemi önce kullanıcı için değerli kılın. Görüşmeden önce müşterinin tek ekranlık özeti, takip hatırlatmaları, hazır teklif şablonları: Temsilcinin işini kolaylaştıran her özellik, girilen verinin kalitesini de artırır.
- Veri girişi yükünü azaltın. Zorunlu alanları en aza indirin. E-posta ve takvim entegrasyonuyla, sistemin kendiliğinden toplayabileceği bilgiyi kullanıcıya bir daha yazdırmayın.
- Toplantıları CRM’deki rakamla yapın. Yönetim toplantısına CRM’den çıkan rapor geliyorsa veri de CRM’e girilir. Toplantıya Excel geliyorsa sistem fiilen terk edilmiştir.
- Geri bildirimi düzenli toplayın ve görünür biçimde uygulayın. Kullanıcı önerisiyle yapılan her küçük iyileştirme, sistemin “onların” değil “bizim” olduğunu hissettirir.
Sorulacak soru: Sahadaki kişi bu sistemden ilk hafta ne kazanıyor?
Ara karar: Çoğu zaman yine yazılım değil. Hiçbir yazılım, kendisini kullanmak için bir nedeni olmayan bir kullanıcıyı ikna edemez.
Karar: Peki suçlu kim?
Altı aşamanın ara kararlarını yan yana koyalım:
- 1. KararRakiplerimiz de kullanıyorYazılım masum
- 2. SeçimDemoda en iyi görünen kazanırKısmen suçlu
- 3. KurulumHerkesin her isteğiYazılım masum
- 4. Veri aktarımıHer şeyi taşıyalımYazılım masum
- 5. Canlıya geçişKutlama ve dağılmaYazılım masum
- 6. İlk altı ayExcel'e dönüşYazılım masum
Altı aşamanın yalnızca birinde, seçimde, yazılımın kısmen sorumlu olduğunu söyleyebiliriz. Diğer beşinde sorun yazılımda değil, iş ile yazılım arasındaki boşlukta: tanımlanmamış amaçta, tasarlanmamış süreçte, sahipsiz veride, dağılan ekipte ve kendisine değer sunulmayan kullanıcıda. Bu kararların hiçbiri teknik değil; ama hepsi bir yazılım projesinin içinde, kimsenin tam olarak sahiplenmediği bir yerde bekliyor.
Bu yüzden yazılımı değiştirmek çoğu zaman sorunu çözmez. Aynı amaçsızlık, aynı süreç, aynı veri ve aynı alışkanlıklar yeni sisteme taşınır.
CRM bir yazılım projesi değil, bir iş dönüşümü projesidir. Yazılım bu dönüşümün aracıdır; sahibi ise iş tarafında oturmalıdır. Bilgi işlem sistemi kurar ve ayakta tutar. Satış ekibinin sistemi nasıl kullanacağına, hangi verinin doğru sayılacağına ve başarının nasıl ölçüleceğine ise iş tarafı karar verir.
Altı aşama, altı soru
Bir CRM projesine başlamadan ya da yarım kalmış bir projeyi yeniden canlandırmadan önce, yönetim toplantısına şu altı soruyla girin:
- Karar: Bu proje bittiğinde hangi bir iki rakam değişmiş olacak?
- Seçim: Satış temsilcimizin sıradan bir gününü bu sistemde baştan sona canlandırdık mı?
- Kurulum: Bir talebe kim “hayır” diyebiliyor?
- Veri aktarımı: Canlıya geçmeden önce bu veriye kim kefil olacak?
- Canlıya geçiş: Canlıya geçtikten sonra sistemin iş tarafındaki sahibi kim?
- İlk altı ay: Sahadaki kişi bu sistemden ilk hafta ne kazanıyor?
Bu altı sorunun hiçbiri yazılımla ilgili değil. Belki de bu yazının asıl cevabı bu.
CRM projelerinde suçlu nadiren yazılımdır. Ama yazılım, suçlanması en kolay olan taraftır.