CRM projelerinde en çok konuşulan konu genelde hangi yazılımın seçileceğidir. Oysa projenin süresini, bütçesini ve ekibin sisteme ısınma hızını belirleyen asıl karar daha sonra, kapsam masaya yatırıldığında verilir. İlk fazda neyin kurulacağı ve neyin bilinçli olarak ertelendiği netleşmeden başlayan projeler, teknik olarak doğru kurgulansalar bile canlıya geç çıkar.
Kapsam, projenin ilk gerçek kararıdır
Bir CRM projesinde yazılım seçimi aslında bir eleme kararıdır. İhtiyaçlarınızı karşılayan birkaç aday arasından birini seçersiniz ve bu seçim projenin tavanını belirler. Kapsam kararı ise projenin zeminini belirler. Hangi süreçlerin sisteme gireceği, hangi ekranların kullanıcının karşısına çıkacağı, hangi raporun ilk günden çalışır durumda olacağı bu kararla şekillenir.
Bu kararın zor tarafı, karar anında elinizde yeterli bilgi olmamasıdır. Şirket CRM'i henüz kullanmamıştır, ekibin sistemle nasıl çalışacağı tahminden ibarettir, süreçlerin yazılı hali çoğu zaman yoktur. Dolayısıyla kapsam, bilinen her ihtiyacı tek seferde kapsayacak şekilde değil, öğrenmeye izin verecek şekilde çizilmelidir.
Pratikte şu ayrımı yapmak işe yarar. Bir talebin ilk faza girip girmeyeceğini belirleyen soru, o talebin önemli olup olmadığı değildir. Neredeyse her talep bir yerde önemlidir. Doğru soru şudur: bu olmadan ekip sistemi günlük işinde kullanabilir mi? Cevap evetse o talep ikinci faza bırakılabilir.
Her şeyi tek seferde kurma isteğinin görünmeyen maliyeti
Kapsamı geniş tutmanın mantığı ilk bakışta sağlamdır. Madem danışman geldi, madem bütçe ayrıldı, madem ekip zaten konuyla ilgileniyor, bir kerede bitsin. Bu yaklaşımın maliyeti üç yerde ortaya çıkar ve üçü de proje sırasında değil, sonrasında görünür.
Birincisi, canlıya geçiş gecikir. Sistem ne kadar uzun süre kurulum halinde kalırsa, projeye başlarken var olan heves o kadar azalır. Kurulumun başında istekli olan satış ekibi, aylar sonra gelen eğitimde aynı ilgiyi göstermez. Bu yüzden canlıya geçişi geciktiren her ek kapsam, sadece takvimi değil benimsemeyi de pahalıya mal eder.
İkincisi, kullanılmayacak yapılar kurulur. CRM'i hiç kullanmamış bir ekip, hangi alanın işine yarayacağını kurulum aşamasında bilemez. Bu aşamada talep edilen özel alanların ve raporların bir kısmı altı ay sonra hiç dolmamış halde durur. Boş alanlar sadece ekranı kalabalıklaştırmakla kalmaz, kullanıcıya sistemin kendi işine ait olmadığı hissini verir.
Üçüncüsü, geri dönmek zorlaşır. Baştan karmaşık kurulan bir yapıda bir alanı kaldırmak, bir aşamayı birleştirmek veya bir otomasyonu kapatmak, o yapının üzerine binmiş diğer kurgular yüzünden ayrı bir iş haline gelir. Sade kurulan bir sistemi büyütmek, karmaşık kurulan bir sistemi sadeleştirmekten her zaman kolaydır.
Bu üç maliyetin ortak noktası, hiçbirinin proje sırasında görünmemesidir. Proje devam ederken geniş kapsam iyi bir karar gibi durur, çünkü her talep sisteme giriyor ve kimse hayır cevabı almıyordur. Fatura, canlıya geçtikten birkaç ay sonra, kullanılmayan alanlar ve ekibin sisteme girmeme alışkanlığı olarak kesilir.
İlk faza girmesi gereken dört başlık
Aşağıdaki dört başlık, hangi sektörde olursanız olun ilk fazın dışında bırakılmaması gereken konulardır. Bunlar olmadan sistem canlıya alınabilir ama günlük işin parçası olmaz.
1. Sahada gerçekten işleyen satış akışı
İdeal süreci değil, bugün işleyen süreci kurun. İlk fazda amaç süreci düzeltmek değil, görünür kılmaktır. Ekip bugün teklifi gönderdikten sonra ne yapıyorsa, aşamalar onu yansıtmalıdır. Süreci iyileştirme işi, sistemde birkaç aylık gerçek veri biriktikten sonra çok daha sağlam temele oturur.
Bu noktada sık yapılan hata, aşama sayısını olduğundan fazla tutmaktır. Her ara adımın ayrı bir aşama olması gerekmez. Bir aşamanın var olması için o aşamada fırsatın gerçekten beklediği ve yönetimin o bekleyen fırsatlarla ilgili bir karar verdiği bir durum olmalıdır.
Mevcut süreci kurmanın bir faydası daha vardır. Ekip sistemde kendi çalışma biçimini gördüğünde CRM'i kendisine dayatılan bir yük olarak değil, zaten yaptığı işin kaydı olarak algılar. Süreci kurulum sırasında değiştirirseniz, ekip aynı anda hem yeni bir yazılım hem de yeni bir çalışma biçimi öğrenmek zorunda kalır. Bu iki değişikliği aynı haftaya sıkıştırmak, ikisinin de yarım kalmasına yol açar.
2. Veri modelinin omurgası
Firma, kişi, fırsat ve ürün arasındaki ilişkinin doğru kurulması ilk fazın en kritik teknik işidir. Bunun sebebi, bu ilişkinin sonradan değiştirilmesinin en pahalı değişiklik olmasıdır. Alan eklemek, ekran değiştirmek, rapor düzenlemek her zaman mümkündür. Ancak bir yıl veri biriktikten sonra firma ile fırsat arasındaki ilişkiyi yeniden kurgulamak, pratikte yeni bir proje demektir.
Omurgayı kurarken şu soruya net cevap verin: aynı müşteriyle birden fazla iş yapıyorsanız, bu işlerin her biri ayrı bir kayıt mı, yoksa tek kaydın farklı satırları mı? Cevap sektöre göre değişir ve veri modelinin tamamını belirler.
3. Kullanıcının günlük işini bitiren ekranlar
Satış temsilcisi günde en çok hangi işi yapıyorsa, o iş CRM içinde en az tıklamayla yapılabiliyor olmalıdır. Çoğu projede bu iş görüşme sonrası not girmek, bir sonraki aktiviteyi planlamak ve fırsatın aşamasını güncellemektir. Bu üçü akıcı çalışmıyorsa, geri kalan her şey ne kadar iyi kurulursa kurulsun ekip sisteme girmez.
Kullanıcı ekranlarını tasarlarken yöneticinin değil, temsilcinin bakış açısını temel alın. Yöneticinin ihtiyacı rapordur ve rapor zaten temsilcinin doldurduğu veriden üretilir. Temsilci doldurmuyorsa rapor da yoktur.
4. Yönetimin karar vereceği birkaç rapor
İlk fazda on beş rapora ihtiyacınız yok. Yönetimin haftalık toplantıda gerçekten baktığı iki üç rapor yeterlidir. Bunlar genelde açık fırsatların aşamalara göre dağılımı, bu ay kapanması beklenen işler ve temsilci bazında aktivite yoğunluğudur.
Raporu az tutmanın bir faydası daha vardır. Yönetim az sayıda rapora bakarsa, o raporların beslendiği alanların doğru doldurulması ekip için somut bir beklentiye dönüşür. Otuz raporun olduğu bir sistemde hiçbir alanın doldurulması gerçek anlamda takip edilemez.
İkinci faza rahatlıkla bırakabilecekleriniz
Aşağıdaki başlıklar önemsiz oldukları için değil, ilk fazda kurulduklarında karşılığını veremeyecekleri için ertelenir. Hepsinin ortak özelliği, doğru kurgulanabilmeleri için sistemde gerçek veri bulunmasını gerektirmeleridir.
• Müşteri adayı puanlama kuralları: Hangi davranışın gerçekten satışa dönüştüğünü görmeden konulan puanlar tahmine dayanır.
• Gelişmiş otomasyon zincirleri: Süreç sahada oturmadan kurulan otomasyonlar, süreç değiştiğinde tek tek sökülmek zorunda kalır.
• Tahminleme ve olasılık modelleri: Kapanma olasılığı, geçmiş veriden beslenmediği sürece sadece bir yüzde işaretidir.
• Sektöre özel ileri seviye ekranlar: Temel kullanım oturmadan eklenen özel ekranlar, kullanıcıya iki farklı çalışma biçimi öğrenme yükü getirir.
• Birden fazla departmanın aynı anda devreye alınması: Satış oturmadan pazarlama ve destek ekiplerini eklemek, üç ekibin birden eksik kurulmuş bir sistemle tanışması demektir.
Erteleme kararını ekibe doğru anlatmak da işin bir parçasıdır. Bir talebin ikinci faza bırakılması, o talebin reddedilmesi değildir. Talep listede durur, tarihi vardır ve ilk faz canlıya alındıktan sonra sırası gelir. Bu netlik olmazsa ekip kapsam dışında kalan her maddeyi kayıp olarak algılar.
Kapsamı büyüten tipik talepler ve nasıl karşılanmalı
Kapsam genelde tek bir büyük kararla değil, makul görünen küçük eklemelerle büyür. En sık karşılaşılan üç tanesi şunlardır.
Birincisi, hazır başlamışken diğer sistemi de bağlayalım talebidir. Entegrasyon ilk fazda yalnızca bir koşulda yapılmalıdır: o entegrasyon olmadan kullanıcı aynı veriyi iki yere girmek zorunda kalıyorsa. Diğer tüm entegrasyonlar bekleyebilir. Hangi verinin hangi sistemde yaşayacağı kararı, iki sistem de canlıdayken çok daha isabetli verilir.
İkincisi, geçmiş verinin tamamını taşıyalım talebidir. Veri taşıma kararı hacimle değil, kullanımla verilmelidir. Satış ekibinin bugün gerçekten baktığı dönem neyse, ilk fazda taşınacak veri odur. Arşiv niteliğindeki eski kayıtlar ikinci fazda, hatta çoğu zaman hiç taşınmadan ayrı bir yerde tutulabilir.
Üçüncüsü, raporda şu kırılım da olsun talebidir. Bu talep neredeyse her zaman yeni bir alan açılması anlamına gelir ve yeni alan, onu dolduracak kullanıcı için yeni bir yük demektir. Rapor kırılımı istemek kolaydır, o kırılımı besleyecek veriyi her gün girmek zordur. Talebi karşılarken ikinci kısmı da konuşun.
Dördüncüsü, yönetimden gelen ve tartışmaya kapalı görünen taleptir. Bu talepler genelde bir yöneticinin önceki şirketinde gördüğü bir kurguyla gelir ve ekip bunu sorgulamaz. Burada yapılması gereken talebi reddetmek değil, talebin hangi kararı besleyeceğini sormaktır. Cevap netse talep ilk faza girer. Cevap belirsizse, o kurgunun ikinci fazda gerçek veriyle tasarlanması hem daha isabetli hem de daha ucuz olur.
Bu dört talebin ortak noktası, hiçbirinin kötü niyetle gelmemesidir. Hepsi şirketin işine yarayacağı düşünülerek istenir. Kapsamı korumak, bu taleplere hayır demek değil, hepsine bir sıra numarası vermektir.
Fazlar arasında ne kadar beklemeli
Burada net bir takvim vermiyoruz, çünkü doğru aralığı belirleyen şey geçen süre değil, biriken bilgidir. İkinci faza başlamak için üç işaretin oluşmasını bekleyin.
• Ekip sistemi hatırlatma olmadan kullanıyor: Yöneticinin uyarısıyla doldurulan bir CRM, henüz günlük işin parçası olmamıştır.
• Raporlar güvenilir sonuç veriyor: Rapordaki sayının doğruluğu tartışılıyorsa, sorun raporda değil veri girişindedir ve bu sorun ikinci fazla çözülmez.
• Talepler tahmin değil, deneyim üzerinden geliyor: Kullanıcı artık şu alan da olsun demiyor, şu işi yaparken şurada takılıyorum diyor. Bu ikinci tür talep, ikinci fazın gerçek gündemidir.
Bu üç işaret oluşmadan ikinci faza geçilirse, ikinci faz birinci fazın eksiklerini kapatmaya çalışan bir onarım çalışmasına dönüşür. Oysa amacı yeni yetenek eklemektir.
Zoho CRM Proje ve Süreç Yönetiminde Faz Stratejileri
Zoho CRM, fazlı kurulumu zorlaştırmayan bir yapıya sahiptir. Modüller, alanlar ve ekran düzenleri sistem canlıdayken değiştirilebilir, dolayısıyla ilk fazda sade kurulan bir yapıyı büyütmek için sistemi durdurmanız gerekmez. İş akışları ve süreç kuralları da aynı şekilde sonradan eklenebilir, bu da otomasyonu ikinci faza bırakma kararını teknik olarak maliyetsiz hale getirir.
Pratikte ilk fazı satış modülü, temel veri modeli, kullanıcı ekranları ve birkaç raporla sınırlı tutmak, ikinci fazda otomasyon, puanlama ve ek departmanlarla genişletmek işleyen bir düzendir. Kurulum sürecinin adım adım nasıl ilerlediğini ve hangi kararların hangi aşamada verildiğini Zoho kurulum ve devreye alma sayfamızda ayrıntılı anlattık.
Projenin hangi çalışma modeliyle yürütüleceği de kapsam kararıyla doğrudan bağlantılıdır. Kapsamı net çizilmiş bir ilk faz ile açık uçlu ilerleyen bir iyileştirme çalışması farklı modellerle yürütülür, bu modelleri ve hangi durumda hangisinin tercih edildiğini çalışma modelleri sayfamızda şeffaf biçimde paylaşıyoruz.
Öne Çıkanlar
• Kapsam kararı, yazılım seçiminden daha fazla etkiler projenin süresini ve ekibin sisteme ısınma hızını.
• Bir talebin ilk faza girip girmeyeceğini belirleyen soru, o talep olmadan ekibin sistemi günlük işinde kullanıp kullanamayacağıdır.
• İlk fazın değişmez dört başlığı: sahadaki gerçek satış akışı, veri modelinin omurgası, kullanıcının günlük işini bitiren ekranlar ve yönetimin baktığı birkaç rapor.
• Puanlama, gelişmiş otomasyon ve tahminleme ikinci faza bırakılır, çünkü doğru kurgulanmaları için sistemde gerçek veri gerekir.
• İkinci faza geçiş takvimle değil üç işaretle belirlenir: ekip hatırlatmasız kullanıyor, raporlar güvenilir, talepler deneyimden geliyor.
Sıkça Sorulan Sorular
İlk faz ne kadar sürer?
Süre, kapsamın genişliğine, karar vericilerin erişilebilirliğine ve taşınacak verinin durumuna göre değişir. Bu yüzden sayfalarımızda örnek süre vermiyoruz. Süreyi en çok etkileyen üç kalem şunlardır: kaç farklı satış sürecinin sisteme gireceği, başka bir sistemden veri taşınıp taşınmayacağı ve kurulum sırasında kararların ne hızda verilebildiği.
İkinci faz ek maliyet anlamına mı geliyor?
İkinci faz ayrı bir çalışmadır ve kendi eforu vardır. Ancak kapsamı baştan geniş tutmanın maliyeti de ortadan kalkmaz, sadece tek faturada görünür. Fazlı ilerlemenin avantajı, ikinci fazda yapılacak işin tahmine değil gerçek kullanıma dayanması ve bu sayede boşa kurulan yapıya ödeme yapılmamasıdır.
Kapsam dışı bıraktığımız bir konu kritik çıkarsa ne yapıyoruz?
Kapsam bir sözleşme metni değil, bir öncelik sıralamasıdır. İlk faz sırasında kritik olduğu anlaşılan bir konu öne alınabilir, karşılığında başka bir madde ikinci faza kayar. Önemli olan toplam kapsamın kontrolsüz büyümemesidir, sıranın hiç değişmemesi değil.
Küçük bir ekibiz, yine de fazlara bölmemiz gerekir mi?
Ekip küçüldükçe fazlı ilerlemenin önemi artar. Küçük ekiplerde CRM'i kurgulayacak ayrı bir sistem yöneticisi genelde yoktur, kurulum sırasında verilen kararları aynı kişiler günlük işlerinin arasında verir. Kapsamı dar tutmak bu durumda karar yükünü de azaltır.