Mevcut CRM'den Yeni CRM'e Geçiş: İnşaat Firmaları İçin Veri Göçü ve Kesintisiz Devir

CRM'den CRM'e geçişin zor kısmı veri taşımak değil, satış devam ederken taşımaktır. Excel'den geçişte durağan bir tablo aktarılır; mevcut bir CRM'den geçişte ise açık opsiyonlar, geçerlilik süresi dolmamış teklifler, devam eden ödeme planları ve bekleyen onaylar canlı hâlde taşınmak zorundadır. Bu nedenle göç projesinin başarısı, aktarılan kayıt sayısından çok geçiş gününde hiçbir işin havada kalmamasıyla ölçülür.

Bu yazı yalnızca sistemden sisteme geçişe odaklanıyor. Excel'den CRM'e geçişin adımları Excel'den CRM'e geçiş yazısında, devreye alma sorumluluklarının sözleşme öncesinde nasıl netleştirileceği CRM programı seçerken yazısında, veri temizliği ve toplam doğrulamasının temel mantığı inşaat CRM nedir yazısında ele alınmıştır.

Neden Excel'den geçişten zordur?

İki geçiş birbirine benzer görünür ama üç noktada ayrışır ve bu üç nokta projenin tamamını şekillendirir.

• Veri zengin ama şekilli. Excel'de veri serbest metindir; taşırken yorumlanır. Mevcut bir CRM'de ise veri belirli bir yapıya oturmuştur: özel alanlar, seçim listeleri, ilişkiler, aktivite kayıtları. Bu yapı hedef sistemin yapısıyla birebir eşleşmez ve eşleşmeyen her alan bir karar gerektirir.
• Canlı açık işlemler var. Excel'den geçişte en kötü senaryo bir satırın atlanmasıdır. CRM'den geçişte ise süresi işleyen bir opsiyonun, gönderilmiş bir teklifin veya vadesi yaklaşan bir taksitin kaybolması doğrudan ticari sonuç üretir.
• Ekip ikinci kez değişiyor. İlk CRM'e geçişte ekip bir boşluğu dolduruyordu; ikincisinde çalışan bir alışkanlığı bırakıyor. Direncin niteliği farklıdır ve "yine mi değişiyor" sorusu meşrudur.

Önce karar: neden değiştiriyorsunuz?

Değiştirme nedeni, göçte neyin öncelikli taşınacağını belirler. Neden yazılı değilse göç "her şeyi taşıyalım" biçiminde ilerler ve gereksiz yere uzar.

Birinci satır en sık karşılaşılan durumdur ve en çok yanlış yönetilenidir: eski sistemin yapısı hedef sisteme kopyalanmaya çalışıldığında, değiştirme nedeninin kendisi yeni sisteme taşınır. Bu durumda doğru yaklaşım alan alan kopyalama değil, yapıyı yeniden tasarlayıp veriyi ona oturtmaktır. Envanterin nasıl yapılandırılması gerektiği envanter yönetimi yazısındadır.

Kaynak sistemden ne çıkar, ne çıkmaz?

Göç planı yapmadan önce yapılacak ilk iş, eski sistemden fiilen ne alabildiğinizi görmektir. Çoğu CRM temel kayıtları dışa aktarır; asıl kayıplar ikincil katmanlarda olur.

Son üç satır göç planlarında en çok atlananlardır. Otomasyonlar, raporlar ve yetki yapısı taşınmaz; yeniden kurulur. Bu nedenle göçten önce "hangi otomasyonlar çalışıyor" ve "hangi raporlar gerçekten okunuyor" dökümünün alınması gerekir — aksi halde yeni sistemde eksik fark edildiğinde kimse eskisinde ne olduğunu hatırlamaz. Raporların hangi periyotta kimin okuduğu satış raporlama ritmi yazısında, yetki mimarisi satış onay süreçleri ve lead atama kuralları yazılarında ele alınmıştır.

Alan eşleme: eşleşmeyen alanlar nereye gider?

Göçün teknik omurgası alan eşleme tablosudur: kaynak sistemdeki her alanın hedefte karşılığının yazılı olarak belirlenmesi. Pratikte dört durum çıkar ve her birinin önceden kararlaştırılmış bir çözümü olmalıdır.

Son satırda en sık yapılan hata, karşılığı olmayan tüm alanları not alanına dökmektir. Not alanına taşınan bilgi raporlanamaz, filtrelenemez ve kurala bağlanamaz; yani fiilen arşivlenmiş olur. Bu kabul edilebilir bir karar olabilir, ancak bilinçli verilmelidir — özellikle kayıp nedeni, lead kaynağı ve daire kodu gibi sonradan analiz edilecek alanlar nota taşınmamalıdır.

Seçim listelerinin eşlenmesi ayrı bir iştir. Kaynakta on dört aşama varsa ve hedefte altı aşama kullanılacaksa, hangi eski aşamanın hangi yeni aşamaya karşılık geldiği tablo hâlinde yazılır. Bu sadeleştirme genellikle iyi bir fırsattır: zamanla çoğalmış ve kimsenin ayrımını bilmediği statüler göç sırasında temizlenir.

Açık işlemlerin devri

Göçün ticari olarak en riskli kısmı burasıdır ve yalnızca sistemden sisteme geçişte vardır. Geçiş gününde havada duran beş iş türü tek tek elden geçirilmelidir.

1. Açık opsiyonlar ve rezervasyonlar. Her birinin süresi, sahibi, hangi daireye ait olduğu ve uzatma geçmişi taşınmalıdır. Süre sayacı yeni sistemde kaldığı yerden işlemeli; sıfırlanırsa süreler fiilen uzar ve stok bloke kalır. Kurallar opsiyon ve rezervasyon yönetimi yazısındadır.
2. Geçerliliği süren teklifler. Teklifin hangi fiyat listesi versiyonundan üretildiği ve geçerlilik tarihi korunmalıdır. Müşteriye verilmiş bir teklifin koşulları göç yüzünden değişemez. Konu konut satış teklifi ve fiyat listesi versiyonlama yazılarında ele alınmıştır.
3. Devam eden ödeme planları. Taksit takvimi, ödenmiş tutarlar, kalan bakiye ve varsa gecikmeler aktarılmalı; senet ve çek kayıtları da bu kapsamdadır. Bu kalem muhasebeyle mutabakat gerektirir. Takip yapısı tahsilat takibi yazısındadır.
4. Bekleyen onay talepleri. İndirim veya plan değişikliği için onay bekleyen talepler geçiş gününde ya kapatılmalı ya da yeni sistemde elle yeniden açılmalıdır. Bu talepler genellikle taşınmaz.
5. Atanmış görevler ve randevular. Önümüzdeki iki haftanın randevu ve takip görevleri taşınmalıdır; taşınmazsa göç haftasında temas kaybı yaşanır.

Pratik yöntem, geçişten bir hafta önce bu beş kategorinin listesini çıkarıp her satırın sahibine onaylatmaktır. Danışmanın "bu opsiyon hâlâ geçerli" veya "bu teklif düştü" teyidi, verinin kendisinden daha güvenilirdir.

Kimlik sürekliliği: eski numaralar ne olacak?

Eski sistemde üretilmiş teklif numaraları, sözleşme referansları ve müşteri kodları dış dünyada dolaşımdadır: müşteriye gönderilmiş belgelerde, muhasebe kayıtlarında, banka yazışmalarında. Yeni sistem kendi numaralama mantığını kurduğunda bu referanslar karşılıksız kalır.

Çözüm basittir ama planlanması gerekir: her kayıtta eski sistem numarasını tutacak bir alan açmak ve aramada bu alanın da taranmasını sağlamak. Böylece müşteri eski teklif numarasıyla aradığında kayıt bulunabilir. Muhasebe tarafıyla eşleşmenin bozulmaması için aynı alan mutabakatta da kullanılır; muhasebe entegrasyonunun yapısı CRM muhasebe entegrasyonu yazısında ele alınmıştır.

Geçmiş veri: ne kadar geriye gidilmeli?

Tüm geçmişi taşımak ilk bakışta güvenli görünür ama göç süresini ve maliyetini büyütür, ayrıca eski ve kurgulanmamış veriyi yeni sisteme taşır. Üç yaklaşım vardır.

Üçüncü yaklaşımda arşivin nasıl saklanacağı ve gerektiğinde nasıl erişileceği yazılı olmalıdır; "eski sistemde dururuz" demek, abonelik sona erdiğinde arşivin de gitmesi anlamına gelebilir.

Taşınması tartışmasız olan kategori satış sonrası yükümlülük doğuran kayıtlardır: satılmış daireler, sözleşme bilgileri, ödeme planları, teslim ve garanti kayıtları. Bu kategoride kesinti kabul edilemez; süreç konut satış sonrası süreç yazısında ele alınmıştır.

Cutover: iki sistem aynı anda canlı kalmamalı

Excel'den geçişte bir süre paralel çalışmak makul bir yöntemdir. Sistemden sisteme geçişte ise iki CRM'in aynı anda canlı tutulması tehlikelidir: iki ayrı envanter, iki ayrı opsiyon kaydı ve iki ayrı fiyat listesi demektir. Bu kurgu çift satış ve çakışan opsiyonun en olası nedenidir.

Pratik yapı dört adımdır:

1. Dondurma penceresi. Belirlenen saatten sonra eski sistemde yeni kayıt açılmaz, mevcut kayıtlarda değişiklik yapılmaz. Pencere genellikle hafta sonuna veya satış yoğunluğunun en düşük olduğu güne konur.
2. Son göç ve doğrulama. Dondurulmuş veri aktarılır ve mutabakat kontrolleri yapılır.
3. Yeni sistemde açılış. Ekip yalnızca yeni sistemi kullanmaya başlar; eski sistem salt okunur hâle alınır.
4. Kısa gözlem dönemi. İlk hafta boyunca eski sistem salt okunur olarak erişilebilir kalır; böylece eksik fark edildiğinde kaynağa bakılabilir.

Geri dönüş planı da yazılı olmalıdır: hangi koşulda göç geri alınır, kararı kim verir ve dondurma penceresinde oluşan kayıtlar nasıl geri işlenir. Pratikte geri dönüş nadiren kullanılır ama planın varlığı, geçiş gününde alınacak kararları sakinleştirir.

Takvim seçimi tek başına risk yönetimidir: lansman haftası, fiyat artışı tarihi, fuar dönemi ve dönem sonu kapanışı göç için uygun değildir. Lansman takviminin yapısı konut projesi lansman süreci yazısındadır.

Geçiş haftasında satış durmaz

Göç planlarının çoğu veriye odaklanır ve geçiş haftasında satışın devam ettiğini hesaba katmaz. Dondurma penceresi açıkken gelen bir lead, yapılan bir görüşme veya verilen bir opsiyon bir yere kaydedilmek zorundadır.

Dört hazırlık bu haftayı sorunsuz geçirtir:

• Geçici kayıt formu. Dondurma penceresi boyunca gelen lead ve görüşmeler tek bir basit forma yazılır ve yeni sistem açıldığında oraya girilir. Form ne kadar sade olursa doldurulma oranı yükselir.
• Opsiyon yetkisinin geçici olarak daraltılması. Pencere boyunca yeni opsiyon açılması tek bir kişinin onayına bağlanır; böylece hem kayıt tek yerden tutulur hem çakışma riski azalır.
• Entegrasyonların yeniden bağlanma sırası. Portal, reklam formu ve maket bağlantıları yeni sisteme yönlendirilmelidir; bu geçiş anında lead akışının kesilmemesi için önceden planlanır. Portal tarafının yapısı proje ilan yönetimi, maket bağlantısı dijital maket ile CRM entegrasyonu yazısında ele alınmıştır.
• Müşteriye söylenecek cümle. Danışmanın "sistemimiz değişiyor, bir saat sonra dönüyorum" demesi ile "şu an bakamıyorum" demesi farklıdır. Geçiş haftası için tek bir cümle belirlenip ekibe verilmelidir.

Üçüncü madde en çok lead kaybettiren noktadır: formlar eski sisteme bağlı kaldığında gelen talepler artık kimsenin bakmadığı bir yere düşer. Bu nedenle yönlendirme değişikliği cutover kontrol listesinin maddesi olmalı, sonradan hatırlanan bir iş olmamalıdır.

Mutabakat: göç başarılı mı?

Toplamları karşılaştırmak gerekli ama yeterli değildir. Sistemden sisteme geçişte kontrol edilmesi gereken yedi set vardır ve her birinin sahibi olmalıdır.

Son set en çok hata yakalayanıdır. Toplamlar tutuyor olsa bile tek tek kayıtlarda alan kayması olabilir; yirmi kaydın elle kontrolü bunu ortaya çıkarır. Mutabakat tamamlandığında yazılı bir kabul alınması — her setin sahibinin onayı — göç sonrası tartışmaları önler.

Ekip tarafı: "yine mi değişiyor?"

İkinci sistem değişikliğinde direncin kaynağı farklıdır: ekip bir boşluğu doldurmuyor, öğrendiği bir düzeni bırakıyor. Üç müdahale işe yarar.

• Nedeni ekibe anlatmak. Değişimin gerekçesi yönetimin kararı olarak değil, ekibin yaşadığı bir problemin çözümü olarak aktarılmalıdır. Danışmanlar hangi işi iki yere girmek zorunda kalıyordu, hangi rapor elde hazırlanıyordu?
• İlk günden somut bir kolaylık. Yeni sistemin ilk haftada ekibe gözle görülür bir iş azaltması sunması, adaptasyonun en güçlü aracıdır. Bu genellikle mobil erişim veya tekrarlayan bir raporun otomatikleşmesi olur; saha kullanımı mobil CRM yazısında ele alınmıştır.
• Eski sisteme dönüşün kapatılması. Eski sistem yazma yetkisiyle açık kalırsa bir kısım ekip orada çalışmaya devam eder ve veri bölünür. Salt okunur erişim yeterlidir.

Adaptasyon tarafının genel çerçevesi ve ilk 90 günde izlenecek metrikler Excel'den CRM'e geçiş yazısında ele alınmıştır; burada eklenmesi gereken tek şey, ikinci geçişte beklentinin daha yüksek olduğudur. Ekip bir kez CRM kullandığı için yeni sistemi mevcut sistemle karşılaştıracaktır; eksik kalan her detay ilk haftada dile gelir.

Eski sistemden çıkış ve arşiv

Göç tamamlandığında eski sistemle ilişkinin nasıl sona ereceği de planın parçası olmalıdır. Dört nokta netleşmelidir: aboneliğin hangi tarihte sona ereceği, sona ermeden önce tam bir veri ve dosya yedeğinin alınmış olması, bu yedeğin hangi formatta ve nerede saklanacağı, ve saklama süresinin ne olacağı.

Yedek alınırken dosya ekleri sıklıkla atlanır; sözleşme, kimlik ve teklif belgeleri kayıt bazında indirilmezse ilişki sona erdiğinde erişilemez hâle gelir. Kişisel veri içeren bu arşivin saklama süresi ve erişim yetkisi de tanımlanmalıdır; genel çerçeve gayrimenkul satışında KVKK uyumluluğu yazısındadır. Sözleşme sonlandırma koşulları ve veri teslimine ilişkin hükümler için şirket avukatından görüş alınması uygun olur.

Sekiz haftalık plan

1. 1. hafta — Döküm. Mevcut sistemdeki alanlar, otomasyonlar, raporlar ve yetki yapısının listesi çıkarılır. Hangi raporun fiilen okunduğu tespit edilir.
2. 2. hafta — Export testi. Her veri türü için küçük bir örnek dışa aktarılır; neyin çıkmadığı somut olarak görülür.
3. 3. hafta — Alan eşleme tablosu. Karşılığı olmayan alanlar için karar verilir; seçim listeleri eşlenir.
4. 4. hafta — Hedef sistemde yapı kurulumu. Envanter, fiyat, ödeme planı ve yetki yapısı kurulur; eski yapı kopyalanmaz.
5. 5. hafta — Deneme göçü. Tam veri test ortamına aktarılır ve mutabakat setleri çalıştırılır. Bu hafta atlandığında hatalar canlıda görülür.
6. 6. hafta — Eğitim ve açık işlem listesi. Ekip eğitimi yapılır; açık opsiyon, teklif ve görev listeleri sahiplerine onaylatılır.
7. 7. hafta — Cutover. Dondurma penceresi, son göç, doğrulama, yeni sistemde açılış.
8. 8. hafta — Gözlem ve kapanış. Örneklem kontrolleri, eksiklerin giderilmesi, yazılı kabul ve eski sistemin salt okunura alınması.

Beşinci hafta en çok atlanan ve atlandığında en pahalıya çıkan adımdır. Deneme göçü yapılmadan canlıya geçen projelerde hata, satış devam ederken düzeltilmek zorunda kalır.

Hedef sistem tarafında bakılacaklar

Göçün kolay veya zor olmasını hedef sistemin veri modeli belirler. Evon'un modül listesinde Envanter Motoru, Bağımsız Bölüm Yönetimi, Blok ve Kat Yönetimi, Daire Tipleri, Durum Yönetimi, Şerefiye Yönetimi, Fiyat Listesi Yönetimi, Ödeme Planları, Tahsilat Yönetimi, Senet ve Çek Yönetimi, Rezerv Yönetimi, Aktivite Geçmişi, Doküman Yönetimi, Rol ve Yetkilendirme ile API Entegrasyonları bulunmaktadır. Bu katmanların hazır bulunması, eski sistemdeki verinin not alanlarına sıkıştırılmak yerine kendi alanlarına oturabilmesi anlamına gelir.

Buna karşılık göç projesinin kendisi bir hizmet konusudur ve her kurulumda aynı kapsamda olmayabilir. Hangi veri türlerinin aktarılabildiği, dosya eklerinin toplu taşınıp taşınamadığı, API üzerinden aktarımın mümkün olup olmadığı, deneme göçü yapılabilip yapılamayacağı ve bu işlerin kapsam ile bedelinin ne olduğu demo ve sözleşme aşamasında ayrıca netleştirilmelidir.

Göçte en sık yapılan sekiz hata

1. Eski yapıyı birebir kopyalamak. Değiştirme nedeni yeni sisteme taşınır.
2. Export testini atlamak. Neyin çıkmadığı canlı göç gününde öğrenilir.
3. Açık işlemleri listelememek. Opsiyon süreleri sıfırlanır, geçerli teklifler kaybolur.
4. Deneme göçü yapmamak. Hatalar satış devam ederken düzeltilir.
5. İki sistemi yazma yetkisiyle açık tutmak. Veri bölünür, çift satış riski doğar.
6. Otomasyon ve rapor dökümünü almamak. Yeni sistemde eksik fark edilir, eskisinde ne olduğu hatırlanmaz.
7. Dosya eklerini yedeklemeden abonelik kapatmak. Sözleşme ve kimlik belgeleri erişilemez hâle gelir.
8. Göçü yoğun döneme koymak. Lansman, zam tarihi veya fuar haftası göç için uygun değildir.

Sık Sorulan Sorular

CRM değiştirirken tüm geçmiş veri taşınmalı mı?

Zorunlu değil. Aktif kayıtların tamamı ile satış sonrası yükümlülük doğuran kayıtlar (satılmış daireler, sözleşmeler, ödeme planları, teslim ve garanti bilgileri) kesintisiz taşınmalıdır. Kapanmış eski kayıtlarda ise kesitli göç veya ayrı arşiv makul olabilir. Arşiv tercih edilirse saklama yeri ve erişim yönteminin yazılı olması gerekir; "eski sistemde dururuz" demek abonelik bitince arşivin de gitmesi anlamına gelebilir.

Açık opsiyonlar nasıl taşınır?

Her açık opsiyonun süresi, sahibi, ilgili daire ve uzatma geçmişi aktarılmalı; süre sayacı yeni sistemde kaldığı yerden işlemelidir. Süre sıfırlanırsa opsiyonlar fiilen uzar ve stok gereksiz bloke kalır. Pratik yöntem, geçişten bir hafta önce açık opsiyon listesini çıkarıp her satırı danışmanına onaylatmaktır; bazıları zaten düşmüş olabilir.

İki sistemi bir süre birlikte kullanmak mümkün mü?

Önerilmez. Envanter ve opsiyon kaydının iki yerde tutulması, çift satış ve çakışan opsiyonun en olası nedenidir. Doğru yapı, eski sistemi belirlenen saatten sonra dondurmak, son göçü yapmak ve eski sistemi salt okunur hâle almaktır. Salt okunur erişim ilk hafta boyunca açık kalabilir; bu, paralel kullanım değil referans erişimidir.

E-posta ve WhatsApp yazışmaları taşınabilir mi?

Çoğu durumda bütünüyle taşınamaz; entegrasyon üzerinden gelen yazışmalar genellikle göç kapsamı dışında kalır. Bu nedenle kritik yazışmaların kayıt bazında dosya olarak arşivlenmesi, göçten önce yapılması gereken bir iştir. Hangi yazışmaların kritik olduğu kararı danışmanlara bırakılabilir.

Göç ne kadar sürer?

Süre veri hacminden çok hazırlık kalitesine bağlıdır. Döküm, export testi, alan eşleme, deneme göçü ve mutabakat adımları atlanmadığında sekiz haftalık bir plan çoğu firma için gerçekçidir. Bu adımlar atlandığında göç daha kısa görünür ama düzeltme işi canlı döneme kayar ve toplam süre uzar.

Eski teklif ve sözleşme numaraları ne olacak?

Her kayıtta eski sistem numarasını tutan bir alan açılmalı ve aramanın bu alanı da kapsaması sağlanmalıdır. Bu referanslar müşteriye gönderilmiş belgelerde ve muhasebe kayıtlarında dolaşımdadır; karşılıksız kaldığında müşteri aramasında kayıt bulunamaz ve muhasebe mutabakatı zorlaşır.

Göçün başarılı olduğunu nasıl anlarım?

Toplam karşılaştırması tek başına yeterli değildir. Envanter, durum dağılımı, satış bedeli, tahsilat, açık işlemler ve müşteri kayıtları ayrı ayrı mutabık kılınmalı; bunlara ek olarak rastgele seçilmiş yirmi kaydın alan alan kontrolü yapılmalıdır. Toplamlar tutuyor olsa bile tek tek kayıtlarda alan kayması bulunabilir ve bunu yalnızca örneklem kontrolü yakalar. Her kontrol setinin sahibinden yazılı kabul alınması, sonraki tartışmaları önler.

Sonuç

CRM'den CRM'e geçişte başarının ölçüsü taşınan kayıt sayısı değil, geçiş gününde havada kalan iş olmamasıdır. Bunu sağlayan üç şey vardır: kaynak sistemden fiilen neyin çıktığının önceden test edilmesi, açık opsiyon ve tekliflerin tek tek sahiplerine onaylatılması, ve iki sistemin aynı anda yazma yetkisiyle canlı tutulmaması.

İki adım özellikle atlanmamalıdır. Birincisi deneme göçü: test ortamında tam veriyle çalıştırılmayan bir göçte hatalar satış devam ederken düzeltilir. İkincisi eski sistemden çıkış planı: dosya ekleri dahil tam bir yedek alınmadan abonelik kapatıldığında, sözleşme ve kimlik belgeleri geri getirilemez. Değiştirme nedeninizi yazıya dökmek ise tüm bu kararları kolaylaştırır — çünkü eski yapıyı kopyalamak yerine neyi farklı kurmanız gerektiğini gösterir.

İlgili Yazılar

Konut Projesinde Müşteri Memnuniyeti Nasıl Ölçülür? Konutta Sözleşme Devri: Müşteri Daireyi Teslimden Önce Satmak İsterse Ne Olur? Satış Kampanyası Nasıl Kurgulanır? Kapsam, Süre, Bitiş ve Ölçüm