CRM Projesi Neden Başarısız Olur? 12 Kök Neden

CRM projesi neden başarısız olur? Çoğunlukla yazılım yüzünden değil: sponsorsuz kalan kapsam kararları, eğitimsiz devreye alma, taşınmadan önce temizlenmeyen veri ve hiç ölçülmeyen kullanım bir araya geldiğinde ekip sisteme sırtını döner. Aşağıdaki on iki kök neden, Senitix editör ekibinin derlediği bir sınıflamadır; bir araştırmanın ölçülmüş sonucu değildir, ancak Forrester’ın 2009 tarihli dört ana nedeniyle (aşağıda) örtüşür.

CRM projeleri gerçekte ne sıklıkla başarısız oluyor?

Sabit bir yüzde yoktur, çünkü her araştırma “başarısızlığı” farklı tanımlar: kimi hedefe tam ulaşamamayı sayar, kimi projenin tamamen terk edilmesini. Salesforce’un yayımladığı ve tarihi eski olan (2014 ve öncesi verilere dayanan) bir CRM makalesi, Success Accelerators ve C5 Insight’ın 2014 tarihli bulgusuna atıfla CRM projelerinin üçte birinden fazlasının hâlâ başarısız olduğunu, bazı şirketlerin art arda iki-üç kez başarısızlık yaşadığını aktarıyor; aynı sayfa Forrester’ın (2009) belirlediği dört ana nedeni sıralıyor: tutarlı bir CRM stratejisinin olmaması, sürece yeterince dikkat edilmemesi, insandan çok teknolojiye odaklanmak ve devreye alındıktan sonra benimsememe (Salesforce, “Why Do CRM Projects Fail”). Bu rakamlar on yılı aşkın eskidir ve güncel bir oran olarak okunmamalıdır; yine de dört neden, aşağıdaki on iki kök nedenin neden çoğunlukla yazılımla değil kurulum kararlarıyla ilgili olduğunu açıklıyor.

CRM projesi neden başarısız olur? 12 kök neden

On iki neden üç grupta toplanıyor: yönetim ve sponsorluk, kullanıcı ve eğitim, veri ve teknik kurulum. Bir proje genelde tek bir nedenden değil, farklı gruplardan iki-üç nedenin üst üste binmesinden başarısız olur.

Yönetim ve sponsorluk kökenli nedenler

1. Üst yönetim sponsorluğunun olmaması. Kapsam ve öncelik kararlarını verecek kimse yoksa her anlaşmazlık yapılandırmayı yürüten kişiye kalır ve karar günlerce bekler.
2. Net olmayan hedef ve başarı ölçütü. “CRM’e geçelim” bir hedef değildir; hangi sayının ne zaman, ne kadar değişmesi beklendiği yazılı değilse kimse projenin bitip bitmediğini bilemez.
3. Değişim yönetimi planının olmaması. Ekip neden değiştiğini, ne zaman geçileceğini ve eski sistemin ne zaman kapanacağını bilmiyorsa iki sistemi birden kullanmaya devam eder.
4. Kapsam kararının sahibi belirsiz olduğunda kapsam sürekli büyür. Her departman kendi isteğini eklediğinde sistem ilk hedeften uzaklaşır ve devreye alma tarihi tekrar tekrar ertelenir.

Kullanıcı ve eğitim kökenli nedenler

5. Satış ekibinin kurulum sürecine dahil edilmemesi. Alanlar ve aşamalar temsilcilerin gerçek iş akışı sorulmadan tasarlanırsa ekip sistemi kendi işini kolaylaştıran değil, yönetimin izlediği bir araç olarak görür.
6. Eğitimsiz ya da tek seferlik devreye alma. Bir günlük tanıtım toplantısı eğitim değildir; ekip kendi gerçek verisiyle pratik yapmadan canlıya geçerse ilk haftadan itibaren eski alışkanlığa döner.
7. Devreye alma sonrası takip eksikliği. En riskli dönem, ilk heyecanın geçtiği ve eski alışkanlıkların geri geldiği devreye almadan sonraki üç-altı aydır; bu dönemde kimse kullanımı izlemezse benimseme sessizce erir.
8. Sistemi önce seçip süreci sonra ona uydurmaya çalışmak. Doğru sıra tam tersidir: önce satış sürecini tek sayfada tanımlamak, sonra o sürece uyan bir sistem kurmaktır.

Veri ve teknik kurulum kökenli nedenler

9. Veri göçünün (migrasyon) ihmal edilmesi. Excel’deki dağınık ve mükerrer veri olduğu gibi yeni sisteme taşınırsa yeni sistem de aynı hızla kirlenir; mekanizma basittir: temizlenmemiş veri, taşındığı sistemi de kirletir.
10. Aşırı özelleştirme ve alan şişkinliği. Bir kayıt formunda elli alan varsa temsilci hangi on tanesinin gerçekten gerekli olduğunu anlayamaz ve formu yarım doldurmaya başlar.
11. Diğer sistemlerle entegrasyon eksikliği. E-posta, takvim ya da teklif süreci CRM’in dışında kalırsa ekip iki ayrı yerde iş takip eder ve CRM ikinci öncelik haline gelir.
12. Kullanımın hiç ölçülmemesi. Hangi alanın doldurulduğu, hangi aşamanın atlandığı izlenmezse sorun büyümeden önce fark edilmez ve düzeltme fırsatı kaçırılır.

Bu on iki neden proje takviminde hangi aşamada ortaya çıkar?

Aşağıdaki tablo dört proje aşamasını, o aşamada en sık görülen kök nedenleri ve kimin erken fark etmesi gerektiğini karşılaştırıyor.

Kök nedenler pratikte nasıl bir araya gelir?

Örnek: İzmir’de sekiz kişilik bir endüstriyel ekipman satış ekibinde CRM kararını genel müdür tek başına verdi ve kurulumu yarı zamanlı çalışan bir ofis elemanına bıraktı; sponsor rolü boş kaldı. Yapılandırma bittiğinde ekip iki saatlik tek bir toplantıda “tanıtıldı”, ayrı bir pratik oturumu yapılmadı. Eski Excel dosyasındaki üç yıllık müşteri listesi hiç temizlenmeden olduğu gibi içe aktarıldı; aynı firma dört farklı yazımla dört kez göründü. İlk ay temsilciler hem Excel’i hem CRM’i birlikte kullandı, ikinci ay çoğu yalnızca Excel’e döndü çünkü CRM’deki veriye güvenmiyorlardı. Üçüncü ayda genel müdür kullanım raporuna baktığında haftalık girilen fırsat sayısının sıfıra yakın olduğunu gördü. Burada üç neden üst üste binmişti: sponsorsuzluk, eğitimsiz devreye alma ve temizlenmemiş veri göçü. Sponsor rolü baştan atanıp veri temizliği kurulumdan önce yapılmış olsaydı, ekip muhtemelen ilk aydan itibaren CRM’e güvenmeye devam ederdi. Ekip ve rakamlar örnek amaçlı kurgulanmıştır; gerçek bir şirketi ya da Senitix müşterisini anlatmaz.

Bu on iki neden birbirini nasıl besler?

On iki neden birbirinden bağımsız çalışmaz; biri diğerini büyütür. Sponsorsuz kalan bir proje genellikle net bir hedef de belirlemez, çünkü hedefi onaylayacak kimse yoktur. Bu da kapsamın sürekli genişlemesine (dördüncü neden) zemin hazırlar. Aynı şekilde satış ekibi kurulum sürecine dahil edilmediğinde (beşinci neden) devreye alma genelde eğitimsiz kalır (altıncı neden), çünkü kimse ekibin hangi noktada takıldığını önceden bilmez. Veri tarafında da benzer bir zincir işler: veri göçü ihmal edildiğinde (dokuzuncu neden) aşırı özelleştirme çoğu zaman kirli veriyi gizlemek için eklenir (onuncu neden): form daha karmaşık hâle gelir ama veri kalitesi düzelmez. Bu yüzden tek bir nedeni düzeltmek nadiren yeterli olur; kontrol listesindeki on madde, zincirin hangi halkasının eksik olduğunu görmek için tek tek değil, birlikte işaretlenmelidir.

Ekip büyüklüğü bu nedenleri nasıl değiştirir?

Beş-on kişilik bir KOBİ ekibinde roller genelde birleşir: sponsor, sistem sorumlusu ve satın alma kararını veren kişi aynı kişi olabilir. Bu durumda asıl risk, kapsam kararlarının hiç yazılı hale gelmemesidir: karar tek kişinin kafasında kalır ve o kişi izinli olduğunda ya da işten ayrıldığında kaybolur. Elli kişiden büyük bir satış organizasyonunda roller ayrıdır ama iletişim kopar: bölge müdürleri kendi aşama adlarını ve alanlarını istediğinde, sponsor bu taleplerin hepsini tek tek onaylarsa dördüncü neden (kapsam kayması) hızla büyür. Küçük ekip tek kişinin unutkanlığına, büyük ekip koordinasyon eksikliğine karşı savunmasızdır; kontrol listesindeki sponsor ve kapsam maddeleri her iki büyüklükte de aynı nedenle kritik kalır, yalnızca riskin nereden geldiği değişir.

CRM projesi başarısızlığını önlemek için kontrol listesi

Aşağıdaki on maddeyi kurulum başlamadan önce, tek sayfada, sponsorla birlikte işaretleyin:

• Sponsor yazılı olarak atandı ve haftalık bir kontrol noktası takvimde mi?
• Başarı ölçütü (hangi sayı, ne zaman, ne kadar) tek cümlede yazılı mı?
• Kapsam kararlarını kimin vereceği net mi, yazılı mı?
• Satış ekibinden en az iki farklı çalışma tarzından kişi pilot sürece dahil mi?
• Devreye alma öncesi gerçek veriyle pratik eğitimi planlandı mı, tek toplantıdan fazla mı?
• Devreye almadan sonraki ilk 90 gün için bir takip toplantısı takvimde mi?
• Taşınacak veri temizlendi mi, mükerrer kayıtlar ayıklandı mı?
• Kayıt formundaki alan sayısı gerçekten gerekli olanla sınırlı mı?
• E-posta, takvim ve teklif süreci CRM’e mi bağlanıyor, yoksa ayrı mı kalıyor?
• Kullanım (doldurulan alan, atlanan aşama) kim tarafından, ne sıklıkla izlenecek?

Kurulum ekibini ve stratejiyi nereden başlatmalı?

CRM’in temel kavramlarına henüz aşina değilseniz CRM nedir rehberimiz iyi bir başlangıç noktasıdır. On iki nedenin çoğu, kurulum başlamadan önce verilen kararlarla ilgilidir: CRM stratejisi rehberimiz sistemi seçmeden önce kapsam, sahiplik ve başarı ölçütü gibi hangi kararların yazılı hâle getirilmesi gerektiğini ele alıyor; CRM kurulumu rehberimiz ihtiyaç tespitinden canlı kullanıma dokuz adımı ve kurulum ekibinin beş rolünü, CRM uzmanı ne iş yapar yazımız ise canlıya geçtikten sonra sistemi ayakta tutan kişinin işini anlatıyor. Devreye alma sonrası eğitimi tek seferlik bir toplantı olmaktan çıkarmak isteyen ekipler için CRM kullanıcı eğitimi yazımız, ilk haftadan sonraki eğitim planını adım adım veriyor. Kurulumu yürütecek kişileri seçmek için CRM kurulum ekibi yazısındaki rol matrisine, küçük bir ekibin ilk ay için en sade kurulumuna ise KOBİ’ler için CRM: ilk 30 gün planına bakın.

Kontrol listesini kendi verinizle denemek için Senitix CRM’e ücretsiz başlayabilirsiniz. Her aşamaya rehber metni ve anahtar alanlar, kullanımı izlemek için de raporlar ve panolar eklenebilir; plan ayrıntıları fiyatlandırma sayfasında.

Sık sorulan sorular

CRM projesinin başarısız olduğu kaç ayda anlaşılır?

Çoğu zaman devreye almadan sonraki üçüncü ile altıncı ay arasında; ilk heyecan geçer, eski alışkanlıklar geri gelir ve kimse kullanımı izlemiyorsa düşüş fark edilmeden büyür. Bu dönemde haftalık girilen fırsat sayısı ya da doldurulan zorunlu alan oranı gibi tek bir göstergeyi izlemek, düşüşü aylar sonra değil haftalar içinde fark etmeyi sağlar. Bu yüzden ilk 90 gün için ayrı bir takip toplantısı planlamak önemlidir.

Küçük bir ekipte de bu on iki neden geçerli mi?

Evet; on-on beş kişilik bir ekipte roller birleşebilir ama on iki kararın hepsinin bir sahibi olmalıdır. Sponsor ile sistem sorumlusu aynı kişi olduğunda, kapsam kararlarını kimseye danışmadan verme riski özellikle artar; bu riski dengelemek için en az bir temsilciyi kapsam tartışmalarına gözlemci olarak eklemek yardımcı olur.

Veri göçü neden bu kadar sık göz ardı edilir?

Çünkü en çok zaman alan, en az “görünür” iştir; takvim sıkıştığında ilk feda edilen adım olur. Ama temizlenmemiş veriyle başlayan bir CRM, ekibin sisteme güvenini ilk haftadan kaybettirir ve bu güveni sonradan geri kazanmak, baştan doğru yapmaktan daha uzun sürer. Temsilciler bir kez “bu veriye güvenemem” dediğinde, onları ikinci kez ikna etmek daha zordur.

Dışarıdan danışman tutmak bu riski azaltır mı?

Kısmen. Danışman veri göçünü ve teknik kurulumu hızlandırabilir ama sponsorluk ve kapsam kararlarını devralamaz; bu kararları yalnızca sonucu üstlenecek biri, şirket içinden verebilir. En sık görülen hata, sponsorun kapsam kararını danışmana bırakmasıdır, çünkü danışman ayrıldığında kapsamı sahiplenecek kimse kalmaz. Danışmanı veri temizliği ve teknik kurulumda kullanıp sponsorluğu içeride tutmak en güvenli bileşimdir.

Başarısız bir CRM projesi yeniden başlatılabilir mi?

Genelde tam bir sıfırlama gerekmez. Hangi kök nedenin (ya da nedenlerin) eksik olduğunu bu listeyle belirleyip o role bir sahip atamak, mevcut yapılandırmanın çoğunu koruyarak toparlanmayı mümkün kılar. Yeniden başlatma genellikle yalnızca veri göçü baştan hatalıysa, yani mükerrer ya da kirli veri fark edilmeden canlıya geçmişse gerekir.